Maybe I'm missing something, but I think the theory behind DNS rebinding attacks is actually pretty easy to explain; see the paper "Protecting Browsers from DNS Rebinding Attacks" by Jackson et.al., it's quite understandable. (It's the second Google result for "DNS rebinding"). The authors propose a defense which doesn't require SSL/TLS but rather involves the use of DNS records to allow servers (i.e., the ones to be defended) to specify which hostnames are valid for their IP addresses, as described in section 5.4 of the paper referenced. This requires action by the owners of IP addresses and some extra code in the browser to implement checks of the relevant DNS records, but no change in Apache or IIS, and no need to switch to TLS for all traffic.

However independent of the DNS rebinding issue I do agree it's a shame that SNI support hasn't been added to the industry-leading web servers.

The best non-patchy solution to this problem is secure property titles (Google that phrase) to names.

The problem isn't so much SNI but TLS extensions. I haven't seen a recent survey done, but one done when the RFC was still at the draft stage indicated that whoever turns these on by default is in for a world of pain from user complaints over sites breaking. If it took 15 years for SSLv2 to die, imagine how long it'll take before vendors will risk enabling TLS-ext in their browsers.

"The authors propose a defense which doesn't require SSL/TLS but rather involves the use of DNS records to allow servers (i.e., the ones to be defended) to specify which hostnames are valid for their IP addresses,"

I do not understand how this will work with caches, Akami, and other legitimate re-directs.

The system we are working on keeps your history, and shares history with your friends. There are also some thind party providers. Locally, the truncated IP address, the hash of the cert, and the domain name are stored. When there are changes in these, then the system indicates to the user that there is a MITM or pharming. So a change in IP address will not cause an immediate alarm, but repeatedly getting the same IP address will. Well, this is the part we are working on so its not in the working code. So this allows companies and people to protect themselves.

thanks,
Jean

Frank, Jean's response more or less matches what I recall of the Kaminsky talk. In theory there are lots of possible patches, but (in the opinion of DK) they suffer from sufficient deviations from current practice that they likely won't work.