There is nothing new in this post. I just got fed up of tracking all the SSL/TLS bugs that seem to come out every month, nowadays. I don't even remember which bug does what, how hard the exploit is and what needs to be done to fix it. And everytime I have to Google. Every. Single. Time. And I'm sick of it.
So, this page. Anything that is a problem with TLS configuration, that I'd report when I do a penetration test for a client, I'll try and briefly touch upon. If there's something new that comes up, I'll update this page. In a 2nd post I cover attacks. When an SSL/TLS attack comes around, I'm just going to update that page.
And no, I'm not claiming this is some pioneering, wonderful, one-stop page. It is just so I can go to a single place and remind myself on what some SSL/TLS misconfiguration is.
Weak SSL/TLS ciphers (Strength less than 128 bit)
The way SSL/TLS works is that the client and server negotiate what key size to use to bi-directionally encrypt communication. If both the client and the server have their first choice as a 40 bit key, it means that until negotiation happens again, they're going to encrypt traffic using a shared 40 bit key.
If someone gets hold of an encrypted traffic dump of this communication, they could go through all 2^40 keys, each time decrypting the traffic. When it makes sense, they'd stop and that's the key... for THAT session. Not for every session between that client and server.
That is still bad, and no one should even support ciphers that use anything less than a 128 bit key, which today is considered safe. Although this Wiki snippet says that this could be bad too, under certain conditions. For now though, its fine. Start thinking though, of supporting ciphers that are at least 256 bits long.
RC4
The only reason this is mentioned here, separately was because it was a very popular choice and the preferred cipher for all client-server communication for a long time. If I remember right, even Google had that as their preferred cipher for a long time. I'm "guessing" because it was a really fast symmetric key cipher.
Since then though lots has changed and numerous vulnerabilities have been discovered in RC4. So in short, if this is still a preferred cipher, its wrong. Please disable it on every host+service that supports SSL.
Also, thankfully browser vendors are also moving away from it, so that's good.
Really Really old protocols (SSLv1, SSLv2)
I don't think I've seen anyone use either of these protocols for a while now, even on test servers, but you never know. So yeah, just just disable support for both these. Its ridiculous to have support for either of these.
SSLv1 was apparently never public, which explains why I always saw only SSLv2 enabled even on badly broken servers :)
SSLv2 had numerous vulnerabilities which have their own RFC, which is a fairly strong reason to completely avoid it. Jump straight to Section 2 of the RFC to see some of the vulnerabilities. These affect Confidentiality, Integrity and Availability for any client-server traffic. That's bad.. please never use it.
MD5/SHA1 signed things
A signature for any digital content (like certificates) means that you trust the person who signed the content. So no 2 messages should ever have the same signature. Because, if they did - it'd mean that the person reading the message wouldn't know which message is the real one. Since both appear to be signed by the same person. And could be valid...
Meaning any hash function, where it is possible (practically speaking) to find 2 messages that have the same hash at the end ((hash-collisions) should be avoided. And there's a known attack against MD5 that does exactly this. And its possible to do this with SHA1 as well.
Migrate to SHA256 or SHA512 for all your signing needs at the earliest.
Insecure Renegotiation
Renegotiation in an SSL/TLS context effectively says, 'Can we please decide again...what protocols and ciphers we're going to use to communicate?'. If a client can do this and the server supports it, it means a man-in-the-middle can inject traffic (details here or originally here) and force a client to renegotiate.
Then by getting the timing right, they could somehow piggyback on a client's request, use the client's credentials and do things that the client can do.. without the client's knowledge. Can't ever see a thing but can still do it. Sort of like CSRF inside an SSL/TLS connection.
There's also another exploit discovered that lets attackers DOS the server. There's also a tool by THC to do so. It's a bug, sure but doesn't fix the overall DOS problem as such. It defends against 1 technique. That's it. There's even arguments that this is by design.
The fix is to not let the client renegotiate at all. If a client does try, the server should just reject it. The process is different for different servers.
Lack of OCSP stapling
Clients need a way to decide whether a certificate is valid or not. If it isn't, the client shouldn't let a user visit a site. So, initially there were revocation-lists (CRLs). But those were updated only once every X days, so there was always a chance of a user being owned, in-between. Hence OCSP where the user verifies if the certificate is valid, before connecting to it.
The problem with this though is that the destination server, specially if its very busy could get overwhelmed if clients keep hitting it to check certificate validity all the time. And it consumes client resources as well.
Hence OCSP stapling. A server will do the querying-for-cert-validity and return the stapled response, when the client queries it. So no runtime queries from the client directly to the guys who signed the certificate. There isn't a security issue here, unless you think of a DOS against the guys who signed the cert.
If you can though, specially if you have a low capacity internal CA server, its good to enable OCSP stapling.
Lack of HSTS
HSTS if configured right on the server, tells the browser to always send traffic over a HTTPS connection. Its relevant only if the server supports both HTTP (for some legacy reason) as well as HTTPS. So, if its done right and I type http://site the browser will look at the HSTS header and force the traffic over HTTPS. Which is great.
Note though, that the absolute first request before the HSTS response reaches the browser is still over HTTP, and hence open to an attacker man-in-the-middling the connection and owning a user.
And that's not good either, which is why you should try and notify browser vendors in advance that you plan to implement HSTS. Or at least as soon as you implement it, to reduce the exposure to this attack.
If you only support HTTPS and port 80 isn't even open on your web-server, you can still configure HSTS, but it doesn't improve your security in any way.
No Forward Secrecy cipher support
Lets say an encrypted traffic dump is captured. Now that communication was encrypted using a specific session key, generated using the server's private key...that's how SSL works.
So if the server's private key somehow got stolen, the attacker could use it to decrypt all the traffic she captured earlier.
Lets now say that a client-server communication is encrypted using a cipher that support forward secrecy. Even if the private key is stolen, the attacker can't use it to decrypt any of the encrypted traffic she had.
So ideally, ensure you support some strong ciphers that support forward secrecy and make one of them your preferred cipher of communication.
So, this page. Anything that is a problem with TLS configuration, that I'd report when I do a penetration test for a client, I'll try and briefly touch upon. If there's something new that comes up, I'll update this page. In a 2nd post I cover attacks. When an SSL/TLS attack comes around, I'm just going to update that page.
And no, I'm not claiming this is some pioneering, wonderful, one-stop page. It is just so I can go to a single place and remind myself on what some SSL/TLS misconfiguration is.
Weak SSL/TLS ciphers (Strength less than 128 bit)
The way SSL/TLS works is that the client and server negotiate what key size to use to bi-directionally encrypt communication. If both the client and the server have their first choice as a 40 bit key, it means that until negotiation happens again, they're going to encrypt traffic using a shared 40 bit key.
If someone gets hold of an encrypted traffic dump of this communication, they could go through all 2^40 keys, each time decrypting the traffic. When it makes sense, they'd stop and that's the key... for THAT session. Not for every session between that client and server.
That is still bad, and no one should even support ciphers that use anything less than a 128 bit key, which today is considered safe. Although this Wiki snippet says that this could be bad too, under certain conditions. For now though, its fine. Start thinking though, of supporting ciphers that are at least 256 bits long.
RC4
The only reason this is mentioned here, separately was because it was a very popular choice and the preferred cipher for all client-server communication for a long time. If I remember right, even Google had that as their preferred cipher for a long time. I'm "guessing" because it was a really fast symmetric key cipher.
Since then though lots has changed and numerous vulnerabilities have been discovered in RC4. So in short, if this is still a preferred cipher, its wrong. Please disable it on every host+service that supports SSL.
Also, thankfully browser vendors are also moving away from it, so that's good.
Really Really old protocols (SSLv1, SSLv2)
I don't think I've seen anyone use either of these protocols for a while now, even on test servers, but you never know. So yeah, just just disable support for both these. Its ridiculous to have support for either of these.
SSLv1 was apparently never public, which explains why I always saw only SSLv2 enabled even on badly broken servers :)
SSLv2 had numerous vulnerabilities which have their own RFC, which is a fairly strong reason to completely avoid it. Jump straight to Section 2 of the RFC to see some of the vulnerabilities. These affect Confidentiality, Integrity and Availability for any client-server traffic. That's bad.. please never use it.
MD5/SHA1 signed things
A signature for any digital content (like certificates) means that you trust the person who signed the content. So no 2 messages should ever have the same signature. Because, if they did - it'd mean that the person reading the message wouldn't know which message is the real one. Since both appear to be signed by the same person. And could be valid...
Meaning any hash function, where it is possible (practically speaking) to find 2 messages that have the same hash at the end ((hash-collisions) should be avoided. And there's a known attack against MD5 that does exactly this. And its possible to do this with SHA1 as well.
Migrate to SHA256 or SHA512 for all your signing needs at the earliest.
Insecure Renegotiation
Renegotiation in an SSL/TLS context effectively says, 'Can we please decide again...what protocols and ciphers we're going to use to communicate?'. If a client can do this and the server supports it, it means a man-in-the-middle can inject traffic (details here or originally here) and force a client to renegotiate.
Then by getting the timing right, they could somehow piggyback on a client's request, use the client's credentials and do things that the client can do.. without the client's knowledge. Can't ever see a thing but can still do it. Sort of like CSRF inside an SSL/TLS connection.
There's also another exploit discovered that lets attackers DOS the server. There's also a tool by THC to do so. It's a bug, sure but doesn't fix the overall DOS problem as such. It defends against 1 technique. That's it. There's even arguments that this is by design.
The fix is to not let the client renegotiate at all. If a client does try, the server should just reject it. The process is different for different servers.
Lack of OCSP stapling
Clients need a way to decide whether a certificate is valid or not. If it isn't, the client shouldn't let a user visit a site. So, initially there were revocation-lists (CRLs). But those were updated only once every X days, so there was always a chance of a user being owned, in-between. Hence OCSP where the user verifies if the certificate is valid, before connecting to it.
The problem with this though is that the destination server, specially if its very busy could get overwhelmed if clients keep hitting it to check certificate validity all the time. And it consumes client resources as well.
Hence OCSP stapling. A server will do the querying-for-cert-validity and return the stapled response, when the client queries it. So no runtime queries from the client directly to the guys who signed the certificate. There isn't a security issue here, unless you think of a DOS against the guys who signed the cert.
If you can though, specially if you have a low capacity internal CA server, its good to enable OCSP stapling.
Lack of HSTS
HSTS if configured right on the server, tells the browser to always send traffic over a HTTPS connection. Its relevant only if the server supports both HTTP (for some legacy reason) as well as HTTPS. So, if its done right and I type http://site the browser will look at the HSTS header and force the traffic over HTTPS. Which is great.
Note though, that the absolute first request before the HSTS response reaches the browser is still over HTTP, and hence open to an attacker man-in-the-middling the connection and owning a user.
And that's not good either, which is why you should try and notify browser vendors in advance that you plan to implement HSTS. Or at least as soon as you implement it, to reduce the exposure to this attack.
If you only support HTTPS and port 80 isn't even open on your web-server, you can still configure HSTS, but it doesn't improve your security in any way.
No Forward Secrecy cipher support
Lets say an encrypted traffic dump is captured. Now that communication was encrypted using a specific session key, generated using the server's private key...that's how SSL works.
So if the server's private key somehow got stolen, the attacker could use it to decrypt all the traffic she captured earlier.
Lets now say that a client-server communication is encrypted using a cipher that support forward secrecy. Even if the private key is stolen, the attacker can't use it to decrypt any of the encrypted traffic she had.
So ideally, ensure you support some strong ciphers that support forward secrecy and make one of them your preferred cipher of communication.
1 comment:
Good readingg this post
Post a Comment