Extended Subset

• SteveD has posted an experimental patch for GNUTLS
• Unfortunately, it appears that D-Link routers implement a protocol which allows router reconfiguration via SOAP and don’t authenticate it properly. Mix in a little DNS rebinding and this likely results in a remote-MitM vulnerability.

The IESG has approved a fix for TLS! The accepted proposal is substantially the same as that proposed by the Sept. 29 meeting of the Project Mogul activity.

Over the coming weeks, the document itself navigates the RFC Editor publication process picking up an RFC number, normative references, and review along the way. But no further technical changes are expected at this point.

Vendors may now deliver to their customers patches which implement the fix blessed by the IETF.

Most vendors have had the details of the fix (with only minor differences) for over three months now. Some are known to have working (and interoperable) implementations internally, so I expect we will see some patches shipping shortly. Since vendors are no longer “blocking on the IETF”, now is when we get to find out which of them are the most responsive when it comes to keeping their customers secure. In all fairness, this has been a rather difficult security problem to address and larger vendors with many products to support have disproportionately more work to do, particularly in the testing process.

One aspect of this fix is that both the client and the server must be patched in order to restore the full security guarantees advertised by TLS. This obviously will not happen tomorrow, but eventually clients and servers will have to start refusing connections with unpatched endpoints (just like they do with ancient versions of SSL today). I.e., their configuration needs to go from “insecure/compatible mode” to “secure/strict mode”. Unfortunately, as long as there is a single unpatched client and a single compatible-mode server in the world (or a compatible-mode client and an unpatched server) there exists a potential vulnerability. Note that some attacks do not require the victim client and server to be expecting to talk the same protocol on the same port!

To this end, in the coming months we will need client applications to begin warning users if they are connecting to an unpatched server. After all, wouldn’t you expect your browser to warn you if your connection could be hijacked because the (supposedly) secure site to which you were connecting was not maintained well enough to apply critical security patches on a regular basis?

In related news:

• IEEE Internet Computing has a nice article on the bug.
• Steve and I will be speaking at Shmoocon 2010 and TROOPERS10 about both the technical aspects of the bug and the some of the meta-disclosure issues we’ve encountered along the way.

November turned out to be quite a month! A few updates to catch us up:

• Several people have done good write-ups on the SSL/TLS bug.
  • Eric Rescorla
  • Thierry Zoller
  • Frank Breedijk
  • Anil Kurmus
• I’ve started with Twitter. https://twitter.com/marshray
• Nasko has set up a nice test for client-initiated renegotiation on his blog. This is probably the most pervasive, and simplest to exploit, form of the SSL/TLS vulnerability for web sites. Two teeny tiny little limitations with it:
  • When it can’t connect to the site it says “Failed to connect/renegotiate, site doesn’t seem vulnerable.” Seems to me like these two conditions are important to distinguish
  • When it correctly determines that the site does not support client-initiated renegotiation it also says “site doesn’t seem vulnerable”. This is a pretty common oversimplification, the site can still be vulnerable to server-initiated renegotiation. Proving that negative (the server will never request renegotiation) can be quite difficult and often requires inspection of the actual server code and/or detailed configuration.
• The SSL/TLS attack has nothing to do with EV “Extended Validation” certificates. Lack of EV is not the cause of this problem, nor does EV offer any solution to it. In my opinion, some articles in the supposedly “mainstream” industry press read as if someone’s getting paid to promote EV as the solution to everything.
• The IETF has put the proposed TLS protocol fix to “In Last Call” state. My understanding is that this will allow the IANA to set aside the numbers for the two protocol elements needed for the proposal. However, the true picture may be significantly more complicated.
• Leviathan Security came up with a way to use an HTTP redirect to turn the limited plaintext injection capability into an sslstrip scenario (or to drive the user to a phishing site with a valid cert).
• At PhoneFactor we’re trying to keep the Status of Patches page up-to-date. Drop me an email if you have any info to add, it can be as general as “we’re working on some code”.
• I really hope the fix for renegotiation is available soon enough that people don’t end up patching everything to disable it (and inspecting firewalls to shoot it down on sight). It is extremely useful for HTTPS client certificates, it would be a shame if it ended up on the Island of Lost Toys along with IP source routing and half of ICMP.
• My prediction is that the HTTP TRACE verb can be used to take the limited blind plaintext prefix injection of the SSL/TLS attack and leverage it to full arbitrary script execution with the origin of the secure site. If so, it’s game over for that user. The good news is that IIS disables TRACE by default. The bad news is that Apache enables it by default (apparently they like it that way). Stay tuned, probably more will be written about this.

More to come as I get a chance.