How secure is SSL?

Question

How secure is SSL (Secure Socket Layer)? As in, how much will it take to crack a password sent through SSL?

Answer 1

Assuming everything is setup/secured properly and we're talking about 128-bit keys, significantly longer than the age of the universe.

I would note that previous cracks in SSL relied on "hole" in MD5, which caused some the method of validation to change..

I would also note, this doesn't free you from man-in-the-middle attacks, or even someone hijacking the private cert of the target company (note that private keys should be protected via a strong password though to mitigate such a risk and then the key revoked if such an event occurs). Read a high level overview on how SSL works here.

Answer 2

SSLv2 had issues with MITM attacks able to cause lower quality ciphers to be negotiated. In those days this usually included a laundry list of "export quality" ciphers who were intentionally weak and could be feasibly cracked via brute force alone.

SSLv3/TLSv1 effectively solved the negotiation issue and soon after many of the weaker quality ciphers have since been removed from availability now that the export restrictions in the US were lifted and the advent of various compliance scanners.

PRF generation in SSL uses both MD5 and SHA1 in a bid to prevent the system from being compromised if one of the hash algorithms were sufficiently compromised. One avenue of attack against SSL is to sufficiently compromise both algorithms as used in the PRF function.. IIRC its just some sort of XOR of the input going through both.

Encryption ciphers are dynamically available and negotiated so any analysis of the quality of encrypted sessions themselves need to take cipher selection into consideration or focus on machinery leading up to the establishment of the initial session encryption key.

(You can compromise a cipher (RSA,AES..etc) but this does not necessarily translate into SSL itself being broken)

In my view the most practical crypto attacks on SSL are side-channel attacks against specific ciphers. AES in particular is known to be vulnerable against timing attacks. These usually require high quality low latency networks to perform (local ethernet) .. There are "blinding" facilities in many systems which simply add artifical delay to the process to mitigate the possibility of timing attacks being successful. (Basically the length of time it takes for certain sequences of code to execute can be used to recover enough information to compromise the system)

And finally my personal favorite weakness of SSL is attacks against "trustworthiness" of the system. Regardless of the algorithms/ciphers used encryption is useless without trust.

Sure you can establish a secure encrypted session but if you don't know if your talking to a legitimate person or an attacker all of that security becomes a useless paperweight.

In today's day and age we have a situation where dozens of certificate authorities are listed in virtually every browser on the planet. Under each one of those are several intermediate signing authorities operated by each of the CAs/downlines.

There have been incidents where system bugs or just plain lazy CAs and resellers have caused the system to be wide open enabling signing of certificate requests for domains that should not have been authorized.

It only takes a compromise of any one CA, intermediate, reseller...etc to effectively compromise the entire trust anchor (effectively planet earth). This can and has been done: sometimes accidentally, sometimes intentionally. If your using IE see for yourself:

Tools-Internet Options-Certificates-Untrusted Publishers.. Oops...

There are mitigating factors: cert expiration dates, revocation lists..etc but in my opinion the trust issue remains the top vulnerability of the entire system.

A determined individual or group with good social engineering skills or automatic weapons I think are more likely than not to get any cert they want signed.