Preamble :

During my research on TLS/SSL Compatibility across different Operation Systems and Browsers I created supporting tools for myself and later decided to release them for the public.

"SSL Audit" remotely scans web servers for SSL support - unlike other tools it is not limited to ciphers supported by underlying SSL engines such as "OpenSSL" or "NSS" but can detect cipher suites based on it's own (simplistic) SSL/TLS engine. As a gimmick it features an innovative Fingerprinting engine that is based on behavioral heuristics.

Surprisingly I had positive feedback about the tool and hence think it's worthwhile to update it.

Updates:

• Added an option to export the results (CSV)
• Adjusted documentation

Download:

• Documentation
• SSL Audit

Documentation:


Video:

Fullscreen view

Final release for my paper explaining the different attack vectors and impacts for (CVE-2009-3555) "TLS / SSL renegotiation vulnerability".

• Added comments and corrections by Alun Jones (Who I hereby thank for his time)
• Changed FTPS description
• Better PDF output

I profit from the update to stress particular impacts that seem to be forgotten about, in addition to the plain-text injection described everywhere (Please refer to the paper to know more)

Additional Impacts

• Potentially allows to downgrade from HTTPS to HTTP (à la SSLstrip)
• Potentially allows to inject XSS into Trace requests

Available Tools (2011)

• My own 2 Proof of concepts
• Red-Team Pentesting Proof of Concept
• Openssl (How-to available in the paper)

I have been delighted by the interest given to this paper at the time, the paper is referenced by the US-CERT, DFN-CERT, BELNET-CERT, SWITCH-cert, Nessus, Qualys, c't Heise and the book "IPhone and IOS Forensics: Investigation, Analysis and Mobile Security" covers the analysis on Page 110

Download "TLS/SSL Session Renegotiation Vulnerability Explained"

A colleague of mine spotted the below while we were doing our expenses - The photograph below shows two separate receipts from two parking buildings that are not far away from each other in central Luxembourg (est. 1km). Both were paid by credit card / debit card.

Can you spot the issue ?

Spotted it? While the first receipt masks everything except the last four digits, the second receipt masks everything except the first digits and leaves the last digits visible. While the example above shows a Debit and a Credit card, I can assure you that if you use a VISA credit card, both together show your complete PAN.
 
There are multiple reasons on why this might be an issue, PCI compliance obviously is one. My interest in this goes further. Two different systems use what they believe is good enough privacy/security and it works as long as they are in their separate world. Put both into the same public place and it becomes apparent it's no longer the case.

This might pose a problem for those that collect tickets and them throw them in the bin, or expense them, like in our case.

Thanks for Opale Security to point out the relevant VISA Guidance on the matter :

As some regulars might have noticed I restructed this blog a bit trying to get rid of some clutter. At the same time I updated a few specific pages I wanted to point out :

• Vulnerability Coordination Policy ( More backround on the "why" )
• About Me (For those interested I added a bit of backround on myself, removed a lot of clutter..)
• Tools / Whitepapers / Vulnerabilities (Added most of what I released, not complete yet)

Since this is a rather old topic with both sides having valid points I will keep this post short and sweet. I have had no time to measure of investigate in depth and I don't think I will find any.

Both have understandable view points, so let's have a look.


Secure renegotiation makes it easier - THC-SSL DoS
Short non technical background story, when SSL connections are setup they require server-side computational effort (RSA decryption), if you try to setup connections repeatedly this will consume a lot of ressources on the server and might lead to Denial of Service.

THC makes use of the secure renegotiation feature recently introduced to setup ssl connections repeatably, in fact they are using a security feature for abuse.

On the word press site it is claimed that :

Interesting here is that a security feature that was supposed to make SSL more secure makes it indeed more vulnerable to this attack:

URLs :

• http://www.thc.org/thc-ssl-dos/ 
• Wordpress (not sure under which control)

By Design (Eric Rescorla)

Eric takes a very factual systematic approach to this issue, particularly with regards to the claim that the renegotiation feature makes it "more vulnerable to this attack". (Errata: I previously attributed the blog to Marsh Ray)

The holistic view point by Eric includes the total costs for the attacker to achieve this attack, this is a standard approach to weight whether a certain path an attacker can take is more costly for him and hence less likely to be chosen :

If I want to mount the old, multiple connection attack, I need to incur the following costs:

1. Do the TCP handshake (3 packets)
2. Send the SSL/TLS ClientHello (1 packet). This can be a canned message.
3. Send the SSL/TLS ClientKeyExchange, ChangeCipherSpec, Finished messages (1 packet). These can also be canned.

 His viewpoint on the same exhaustion attack using the secure renegotiation mechanism that is claimed to be make it "more vulnerable" :

Now let's look at the "new" single connection attack based on renegotiation. I need to incur the following costs

1. Do the TCP handshake (3 packets) [once per connection.]
2. Send the SSL/TLS ClientHello (1 packet). This can be a canned message.
3. Receive the server's messages and parse the server's ServerHello to get the ServerRandom (1-3 packets).
4. Send the SSL/TLS ClientKeyExchange and ChangeCipherSpec messages (1 packet).
5. Compute the SSL/TLS PRF to generate the traffic keys.
6. Send a valid Finished message.
7. Repeat steps 2-7 as necessary.

Eric goes on with :

Briefly then, we've taken an attack which was previously limited by network bandwidth and slightly reduced the bandwidth (by a factor of about 2 in packets/sec and less than 10% in number of bytes) at the cost of significantly higher computational effort on the attacker's client machines. Depending on the exact characteristics of your attack machines, this might be better or worse, but it's not exactly a huge improvement in any case.

and finally concludes with :

All the known defenses are about trying to make it easier to distinguish legitimate users from attackers before you've invested a lot of resources in them, but this turns out to be inherently difficult and we don't have any really good solutions

 I for one rest my case, there isn't anything more to say on this particular subject.

URL :

•  http://www.educatedguesswork.org/2011/10/ssltls_and_computational_dos.html

Recommendations  / FAQ
http://orchilles.com/2011/04/ssl-renegotiation-dos-faq.html