Extended Subset

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.

OK, so the blog is back. Just for reference, here’s the content from the temporary static page:

Renegotiating TLS

Marsh Ray

Steve Dispensa

PhoneFactor, Inc.

v1.1 November 4, 2009

Summary

Transport Layer Security (TLS, RFC 5246 and previous, including SSL v3 and previous) is subject to a number of serious man-in-the-middle (MITM) attacks related to renegotiation. In general, these problems allow an MITM to inject an arbitrary amount of chosen plaintext into the beginning of the application protocol stream, leading to a variety of abuse possibilities. In particular, practical attacks against HTTPS client certificate authentication have been demonstrated against recent versions of both Microsoft IIS and Apache httpd on a variety of platforms and in conjunction with a variety of client applications. Cases not involving client certificates have been demonstrated as well. Although this research has focused on the implications specifically for HTTP as the application protocol, the research is ongoing and many of these attacks are expected to generalize well to other protocols layered on TLS.

There are three general attacks against HTTPS discussed here, each with slightly different characteristics, all of which yield the same result: the attacker is able to execute an HTTP transaction of his choice, authenticated by a legitimate user (the victim of the MITM attack). Some attacks result in the attacker-supplied request generating a response document which is then presented to the client without any certificate warning or other indication to the user. Other techniques allow the attacker to forward or re-purpose client certificate authentication credentials.

Notes

2009-11-06 15:25 -600 Michael D’Errico has an implementation of draft-rescorla-tls-renegotiate at https://www.mikestoolbox.net . Interop test!

2009-11-06 12:08 -600 I’ve finally gotten around to registering on Twitter. Status updates are happening faster, will be putting them there (and possibly here, too).

2009-11-05 18:24 -600 Eric Rescorla has posted the text for an Internet Draft that we are proposing as a fix: msg03963.html

2009-11-05 17:56 -600 Client certificate authentication is not required for vulnerabilities to be present.

The full document in pdf format: Renegotiating_TLS.pdf

Some helpful protocol diagrams: Renegotiating_TLS_pd.pdf

Packet captures: renegotiating_tls_20091104_pub.zip

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.

I first began to suspect the existence of this category of bug in related software while doing code review on some third-party software in support of the solution we provide at my work, PhoneFactor. That was early August. Many late nights and weekends later, I had enough evidence to talk about, and at the beginning of September, I had a working exploit and demoed it to Steve Dispensa (PhoneFactor CTO).

We realized this situation needed to be handled with a good measure of care. Over the first part of September, 2009, we began disclosing the initial group of independent security consultants for independent verification and advice on how to proceed. An initial group of vendors, which included members of ICASI, the IETF, and multiple open-source SSL implementations were disclosed with technical details over the week of September 21 - 25. A meeting was held at a helpful company’s headquarters in Mountain View, CA on September 29, where tentative agreement was reached on a preliminary solution in the form of a protocol extension. The remediation efforts for this bug have been conducted under the code name “Project Mogul”.

At that meeting, it was pointed out that the proposed solution had many similarities with work being done in the IETF TLS Channel Bindings working group. Indeed, over the coming weeks while vendors made their preparations, we followed the discussions on the IETF mailing list to see how close they might come to uncovering the problem there.

Today, an MitM attack on TLS was proposed by Martin Rex in the public forum. Martin’s early proposal may differ in a few details and lack the research time and working exploit that Steve and I had developed, but it clearly identifies the core problem and effectively represents public knowledge of the bug.  Noted security researcher HD Moore tweeted about the possible attack, and it was quickly re-tweeted by 10 others. Vendors (e.g. PhoneFactor) and security researchers began to get independent requests for more information.

For these reasons, Steve and I feel that public disclosure has now occurred, and the results of our research should be available to all interested parties. I expect some other announcements shortly, including an Internet Draft proposal for the fix.

Technical details are in the attached .zip archive.

renegotiating_tls_20091104_pub.zip

More posts to come on this topic, and I’ll try to be available for whatever questions arise.

I’ll be posting contact info for the multi-vendor coordination efforts as well.

Looks like the issue has been uncovered by someone on an IETF public list. HD Moore has Tweeted it and it’s been re-Tweeted 10 times. Any reasonable person must agree that that constitutes a crossing of the Rubicon on this news. A lack of information at this point would only serve to increase misunderstandings, so we’re completing the public disclosure process at this time.