How bad is this SSL/TLS vulnerability? Amazingly horrid! Listen Up! (MP3 - 1MB) Click here to download Ron Nutter's interview with Steve Dispensa (or grab the .zip file here) - one of the PhoneFactor guys who demonstrated the vulnerability to a working group of affected vendors and representatives of various standards committees.
Read Up!
Steve Dispensa and Marsh Ray of PhoneFactor wrote an 8-page overview of the issue which is based on the TLS renegotiation process. The figure below shows the basic SSL/TLS handshake process.
In Wireshark, the display filte
r ssl.record.content_type == 22 extracts SSL/TLS handshake packets.The document written by Steve and Ray defines the security issues demonstrated against recent Microsoft IIS and Apache httpd versions. In essence, the renegotiate attack method defined is used to inject malicious code into the "secure" connection.
One of the most interesting areas of the document focuses on the use of request splicing in which two HTTP requests are combined. The first request triggers the renegotiation while the second request effectively comments out the first request and overrides it with the malicious one.
Analyze the Attacks Yourself
Download the PhoneFactor document, numerous trace files (including decryption keys), protocol diagrams and details here.
Hint: In Wireshark, disable the Preferences > TCP > Allow Subdissector to Reassemble TCP Streams to view the SSL/TLS handshake more clearly.
Step 1: Get the Traces/Keys
Download and extract the files into a directory called "ugly". (Again - download from here.)
Step 2: Set up SSL with Keys
Private keys to decrypt the traces are in the 'caps' and 'certs' directories. For simplicity sake, I recommend you create a \keys directory and copy all the keys there.To decrypt the client_init_renego.pcap file, I used Preferences > Protocols > SSL and entered the following value:
192.168.80.125,443,http,c:\users\laura\keys\ws01.mogul.test.key
When you have successfully set up decry
ption, your traffic should indicate HTTP in the protocol column and, if colorization is enabled, the lovely lime-green color of HTTP traffic.Step 3: Follow the SSL Stream
Once you have applied the decryption, you can right-click on one of the HTTP packets and select Follow SSL Stream to reassemble the traffic as shown below.
In the
figure at left we can see the request to GET /evil.html and the x-ignore line for GET /index.html. This process of using the ignore header prefix is described on page 3 of the Renegotiating TLS.pdf document.Inside the SSL/TLS Handshake - Another "Must Read"
Jeff Moser penned an impressive blog entry entitled "The First Few Milliseconds of an HTTP Connection" which analyzes the handshake process, selection of a cipher suite and use of the RSA algorithm. Read Jeff's blog here.
What's the Solution?
The document written by Marsh Ray and Steve Dispensa paints a pretty gloomy picture of possible remedies.
"There appear to be few silver bullets to address these issues."
Ultimately, the fix will require protocol changes - a laboriously painful process that can have unforeseen consequences related to compatibility problems. The paper forthrightly defines the possibility of 'breaking' as well as backwards-compatible protocol changes. It takes serious 01's to throw that 'breaking' term in there. It's no fun being the bearer of such bad news. What a hassle.
In the meantime, I imagine the efforts to exploit vulnerable SSL/TLS connections is underway - those malicious teams might be working longer hours than the vendor/committee teams focused on a resolution.
Big money is at stake.
Enjoy life one bit at a time!
Laura
Well... with a title like that you just have to read this, don't ya?