Full Disclosure mailing list archives
Five Ways to Screw Up SSL
From: "Ginsu Rabbit" <ginsurabbit () hotmail com>
Date: Sun, 21 May 2006 15:26:05 +0000
Five Ways to Screw Up SSL SSL is a wonderful protocol, but it is frequently used badly. This note is intended to point out some of the more common errors made by applications using SSL. This checklist should be useful for application developers, system administrators, and the occasional penetration tester. This note assumes you have at least a casual knowledge of SSL, but is not a paper about cryptography. If you know enough to write an SSL library, you will know every single one of the mistakes I mention below, plus a few more. Still, I hope that those of you who are writing SSL toolkits will consider why these mistakes are made. Perhaps it will help you design your toolkits so that novices use them correctly. SSL Mistake #1 - Trusting too many Certificate Authorities Most SSL servers do not have this problem, since it only affects those applications that need to verify certificates. If you are dealing with an SSL client application, or your SSL server expects clients to authenticate using certificates, you need to consider which certificate authorities you trust to sign certificates. Somewhere on your system there is probably a file containing a few dozen trusted CA certificates, belonging to big names like Verisign, RSA, and Entrust. All of these certificate authorities are businesses. Someone pays them money, and they give that someone a signed certificate. Verisign has several hundred thousand customers. For some applications, such as a web browser, it might make sense to trust those several hundred thousand people simply because they have paid Verisign money. For an application with tighter security requirements, accepting every certificate signed by major CA is a horribly bad idea. If you trust everyone with one of those certificates, you run the risk of an attacker paying $50 to a CA, getting a certificate, and using that certificate to authenticate to your application. The CA is not to blame when that happens: they publish descriptions of exactly what they do to verify identities before issuing certificates. If a CA's level of identity verification is not acceptable for your business, you should not trust that CA. It may be that there is no public CA sufficiently trustworthy for your purposes. In that case, you should use self-signed certificates, or you could even create your own CA to issue certificates to the people you want to use your application. Most applications trust all of the major root CA certificates by default. Administrators, you need to correct that situation by deleting all of those certificates, and adding back only the CA certificates you intend to trust. This should not need to be said, but some applications include demonstration or test certificates. Never trust those certificates for anything. Everyone and their little brother has a copy, which means those certificates provide no identity verification whatsoever. Throw them away. Now. I'll wait. SSL Mistake #2 - Assuming a signed certificate is the right certificate Again, you can skip this section if your application does not need to verify certificates. Many applications use the following algorithm to verify certificates: - Did the SSL toolkit think the certificate was valid? - If so, allow access. That system has a serious flaw: it performs authentication, but not authorization. Just because someone has a valid certificate doesn't mean you want to let them use your application. Would you grant everyone with a valid user-id and password administrative access to the system? Probably not. Don't grant everyone with a valid certificate the same rights. Consider who they are, and what you want them to do. Many HTTP clients perform the authorization step by comparing the common name (CN) attribute of the certificate to the host name of the URL they are trying to access. If the host name and the CN match, the client completes the connection. If the host name and the CN don't match, someone is trying to impersonate the HTTP server, and the client needs to abort the connection. Some SSL clients skip the authorization step entirely. Other clients try to do the SSL verification properly, but fall back to an insecure connection if the SSL verification fails. That brings us to the next common error. SSL Mistake #3 - Falling back to TCP A surprising number of SSL client applications use the following "logic": - Try to make an SSL connection. - If the SSL connection succeeds, great! - Otherwise, the administrator probably made a mistake. Go ahead and use a TCP connection instead. This is great for usability, but it completely defeats the purpose of using SSL. If your application falls back to a TCP connection, you have none of the security provided by SSL. If an application is supposed to establish an SSL connection but can't, then the application needs to abort the connection and report an error. Falling back to TCP is not a good idea. For some examples of why falling back to TCP is not a good idea, please search the web for "promiscuous mode", "DNS cache poisoning", "ARP cache poisoning", or "IP spoofing". The internet is not a friendly place. SSL was invented for a reason. SSL Mistake #4 - Allowing insecure SSL ciphers Of all the mistakes listed in this note, perhaps only this one is really the fault of the SSL toolkit used. Certain SSL ciphers provide little or no security. Most application developers do not have the knowledge to select an appropriate set of acceptable SSL ciphers, so the SSL implementation should only use strong ciphers unless explicitly instructed otherwise. This is not a paper about cryptography, and I am not going to tell you which SSL ciphers are safe. If you are uncertain which SSL ciphers are acceptable for your purposes, ask an expert. You can test your application for some of the more blatantly insecure ciphers using the openssl s_server and s_client applications with the '-cipher aNULL' or '-cipher eNULL' options. SSL Mistake #5 - Thinking SSL is magic Avoiding all of the other mistakes mentioned in this note does not make your application secure. When everything is done properly, SSL provides strong authentication and privacy. Those are both good things, but they are not the same thing as a secure application. You need to understand the threats that are relevant to you, and defend against those threats. SSL is an important tool for secure applications. It is not a magic wand. _________________________________________________________________Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Five Ways to Screw Up SSL Ginsu Rabbit (May 21)
- Re: Five Ways to Screw Up SSL Michal Zalewski (May 21)
- Re: Five Ways to Screw Up SSL Ginsu Rabbit (May 21)
- Re: Five Ways to Screw Up SSL Dude VanWinkle (May 21)
- Re[2]: Five Ways to Screw Up SSL Thierry Zoller (May 21)
- Re: Re[2]: Five Ways to Screw Up SSL Dude VanWinkle (May 22)
- Re: Five Ways to Screw Up SSL Michael Holstein (May 22)
- Re: Five Ways to Screw Up SSL Dude VanWinkle (May 22)
- Re: Five Ways to Screw Up SSL Valdis . Kletnieks (May 22)
- Re: Five Ways to Screw Up SSL Brian Dessent (May 22)
- Re: Five Ways to Screw Up SSL Dude VanWinkle (May 23)
- Re: Five Ways to Screw Up SSL Ginsu Rabbit (May 21)
- Re: Five Ways to Screw Up SSL Michal Zalewski (May 21)