How secure is SSL?

Question

I am just wondering, how secure is SSL? As in, how much will it take to crack a password sent though 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

From the mathematical standpoint, assuming you have a proper implementation and ignoring the possibility of currently unknown side-channel attacks, or currently unknown mathematical vulnerabilities, it should take vastly longer than the age of the universe to brute force a private key.

However, side-channel attacks and other forms of attacks against the implementation are very real and need to be taken seriously. That includes things like man in the middle attacks, lousy SSL cert authorities, physical attacks to the host, etc.

Answer 3

Depends on the key length, the algorithm and the server farm to decrypt it.

Answer 4

Well, SSL v2 had some flaws, SSL v3 is quite secure. The time would depend on the certificate key length, and how fast are you able to decipher SHA-1 with RSA Encryption.

Quite secure I would say :)

Answer 5

till some bright spark sees a hole.

We thought that ssl was secure till the end of time - sorry altCognito => then recently some realised that md5 can be insecure.

Your only as secure as the crypto used to secure it and just because its is considered computational hard ie takes along time to brute force that doesnt factor for innvovation see the ps3 link.

Remember this is always thought about by humans, implemented by humans then run by computers.

Can you see the 2 issues there?

Also recently

http://www.schneier.com/blog/archives/2008/12/forging_ssl_cer.html

and for a discussion on SSL3 read the experts - http://www.schneier.com/paper-ssl.html

http://www.darkreading.com/security/attacks/showArticle.jhtml?articleID=212700234

Answer 6

Provided what "we" know about certain crypto fundamentals is correct (e.g., that it's Very Difficult to factor very large numbers), modern SSL is way secure.

The realistic threat ain't that somebody is going to crack SSL -- it's a much better bet that some other way of getting at the interesting data will be found.

Answer 7

You mentioned "send a password" trough SSL.

Maybe the question here is how do you

1. Protect the passwords (are the stored as hash, plaintext etc)
2. Rate limit the login attempts (e.g. if you allow max 1 per second brute force from external sources will take a very long time)
3. An important thing about SSL: Where and how is your private key stored (encrypted on disk, inside special non readable hardware)?

Because an often overlooked fact is that the threats from local attacks might be much higher than an attack at the cipher level.

E.g. if someone breaks into your server and obtains the private key (worst case if it is unencrypted on the disk) - with the private key it then might be possible to decrypt stored communications depending on the key exchange mechanism used.

Also as soon as someone obtains your private key it is easy to setup a server which seems to the user as there original server because it has the correct certificate.

So I guess the security of established protocols shouldn't be the first point to worry about.

Answer 8

Steve Gibson explained exactly how the protocol works on a recent Security Now podcast. If you're interested in the specifics, it's definitely worth a listen.

Answer 9

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

SSLv3/TLSv1 effectivly solved the negotiation issue and soon after many of the weaker quality ciphers have since been removed from avaliability 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 avaliable and negotiated so any analysis of the quality of encrypted sessions themselves need to take cipher selection into concideration or focus on machinary 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 ususally 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 "trustworthyness" 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 todays 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 effectivly compromise the entire trust anchor (effectivly planet earth). This can and has been done: sometimes accidently, sometimes intentionally. If your using IE see for yourself:

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

There are mitigating factors: cert expiration dates, recovation 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.