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 :

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.

Recommendations  / FAQ


pete said... @ 27 October, 2011 13:22

It requires a bit of artistic license to get security controls to work together in balance. Nearly every control increases the attack surface of the target it is put in place to protect. SSL is no different. The key is Defense in Width (or what is part of the Möbius Defense). A variety of controls working together need to be applied to prevent harm when interacting with a threat, especially in areas where the threat cannot be differentiated from authorized use. For example, the use of caching, reverse proxies, round robin DNS, and other load balancing techniques need to be deployed to counter resource starvation attacks, probably the most common attack which may also occur incidentally as opposed to purely maliciously.

So while there's not much more to be said about this topic, there's boat-loads more which can be said about thinking wide as opposed to deep.

EAP-TTLS said... @ 11 December, 2012 14:06

The 802.1x standard is an authentication standard with per user and per session encryption with these supported EAP types: EAP-TLS, LEAP, PEAP, EAP-FAST, EAP-TTLS and EAP-SIM. User network authentication credentials have nothing to do with the client computer configuration. Any loss of computer equipment doesn't affect security.

Post a Comment