This makes every SSL site vulnerable to serious man-in-middle (MITM) attacks related to renegotiation.
This vulnerability is due to the design of "session resumption" feature of SSL protocol.
Who Gets affected?
The impact of this issue is potentially significant. below are some points extracted from issue details,
- This attack has been demonstrated against recent versions of Apache httpd and Microsoft IIS, with a variety of clients.
- Most existing installations which currently rely on client certificates for authentication appear to be vulnerable.
- Shared hosting environments which allow untrusted customers served from the same IP to configure any aspect of their encryption parameters appear to be vulnerable.
- Most or all server applications built on TLS(Transport Layer Security) implementations which honor client-initiated renegotiation are vulnerable.
- Early research suggests that digital certificates embedded on smart cards are equally vulnerable to the client certificate authentication attacks.
What is a Man-in-the-middle (MITM) Attack?
A man in the middle attack is one in which the attacker intercepts messages in a public key exchange and then retransmits them, substituting his own public key for the requested one, so that the two original parties still appear to be communicating with each other.
Though MITM attacks are very common on HTTP, these could also be done over an https connection using the same technique; the only difference consists in the establishment of two independent SSL sessions, one over each TCP connection. The browser sets a SSL connection with the attacker, and the attacker establishes another SSL connection with the web server. In general the browser warns the user that the digital certificate used is not valid, but the user may ignore the warning because he doesn’t understand the threat. In some specific contexts it’s possible that the warning doesn’t appear, as for example, when the Server certificate is compromised by the attacker or when the attacker certificate is signed by a trusted CA and the CN is the same of the original web site.
Below is a simple example of a successful MITM attack in simple terms (extracted from Wikipedia)
Suppose Alice wishes to communicate with Bob. Meanwhile, Mallory wishes to eavesdrop on the conversation, or possibly deliver a false message to Bob
1/ Alice sends a message to Bob, which is intercepted by Mallory
Alice --hi bob, it's alice, give me your key--> Mallory Bob
2/ Mallory relays this message to Bob; Bob can't tell it's not
really from Alice
Alice Mallory --hi bob, it's alice, give me your key--> Bob
3/ Bob responds with his encryption key
Alice Mallory <--ok, here is bob's key:bob's key-- Bob
4/ Mallory replaces bob's key with his own, and relays this to
Alice, claiming that it is Bob's key
Alice <--ok, here is bob's key:MALLORY's key-- Mallory Bob
5/ Alice now encrypts a message with what she believes to
be Bob's key, thinking that only Bob can read it...
Alice --msg encrypted with Mallory's key--> Mallory Bob
6/ However, as it was actually encrypted with Mallory's key,
Mallory can decrypt it, read it, modify it (if desired),
re-encrypt with Bob's key, and forward it to Bob
Alice Mallory --msg encrypted with Bob's key--> Bob
7/ Bob thinks that this message is a secure communication
from Alice.
What is the Solution/Mitigation?
First of all judging from recent experience, it is anticipated that the problem domain will continue to evolve in the coming weeks. Therefore there is no clear fool-proof solution suggested by researchers yet.
Mitigation of the HTTPS client certificate attacks is difficult and involves tradeoffs.
One scenario for mitigation involves web developers reorganizing their sites to strictly separate areas of each site into zones based on their differing requirements for authentication, with zones being served from distinct IP addresses. One can imagine the high costs of such a transition, although there are ways to partially or fully automate this separation.
Other mitigations involve protocol changes, but again, they generally have their own issues.In some cases, compatibility with old client software is broken completely.
The right long-term solution to the renegotiation problem involves a much more careful binding between TLS(Transport Layer Security) and upper protocol layers. This could be handled in a variety of ways, including breaking and backwards-compatible changes.
Some Helpful References & Resources
Posts
