Man-In-the-Middle Vulnerability For SSL and TLS

imbaczek writes "The SSL 3.0+ and TLS 1.0+ protocols are vulnerable to a set of related attacks which allow a man-in-the-middle (MITM) operating at or below the TCP layer to inject a chosen plaintext prefix into the encrypted data stream, often without detection by either end of the connection. This is possible because an 'authentication gap' exists during the renegotiation process, at which the MitM may splice together disparate TLS connections in a completely standards-compliant way. This represents a serious security defect for many or all protocols which run on top of TLS, including HTTPS."

Re:How does this compromise SSL?

[Anonymous Coward]

Actually, this isn't true. This attack only allows for injecting data into the request from the client to the server. The attacker doesn't even get to see the result, much less modify it.

Basically, the only thing the attacker gets is the ability to make the client's browser request whatever the attacker wants. You know, the kind of thing you could do with a simple injected IMG tag.

Re:This is news? Come on!

[bluefoxlucid]

The funny part is a lot of people argue, strongly, that self-signed certs aren't any less secure than CA-signed certs.

When routing, you have a default gateway IP... no, that's wrong. You configure such a thing; but what you have is an ARP request finding the MAC of the default gateway (say 10.0.0.1 -> 00:11:22:AA:BB:CC). Not sending to the local network? Slap that MAC as the target packet; the router interface gets the packet, reads the IP, says "Hmm that's not my IP address," checks routing table, slaps a new MAC on, and transmits out the appropriate interface.

Well, if I'm at a point where I can eaves drop your packet (self-signed certs protect against eavesdropping), say on your Wifi AP, I can send a spoofed ARP response at you. Knock off your ARP table entry, replace 10.0.0.1's entry with DD:EE:FF:11:23:45 (mine). Now you'll send the packet to me; I MitM you; then I slap on 00:11:22:AA:BB:CC as the destination addr of the new packet and it routes as normal.

ALL SSL attacks are MitM attacks. An eaves drop attack is a lazy MitM that could become an active MitM if he cared. Mitigation is complex and prone to causing catastrophic breakage; in uncontrolled environments it causes breakage immediately, and in huge controlled environments (corporate LAN) it becomes impossible to reconfigure things on the fly without causing a network storm and outages-- and mistakes require manually walking to each affected machine to undo them.

Note that many people, of course, don't understand SSL. Many programmers get the implementation wrong (it supplies encryption; ignore all these weird certificate anomaly bullshits, shit's encrypted so it's fine). Users don't know what they're worrying about. Notice further that SSL is very well designed, but on like version 4? (SSL3.0 -> TLS1.0) The designers are well aware that the issue is hard to understand, and that they've not gotten it quite right yet; they are, however, intelligent, and managing a pretty fucking good job.

Client certificates only? is this important?

[Xylantiel]

The linked articles only discuss authentication via client certificates, which seems pretty rare currently. How does this vulnerability actually impact the "usual" web commerce usages of SSL, which involves a server certificate? Also it does not appear that there is any way to force a re-negotiation from outside. And while re-negotiation appears common for client certs, I would expect it to be somewhat uncommon for server certs except for the initial up-negotiation to a secure connection for TLS. How important is this for the common-use cases of e-commerce and banking?