Full Disclosure mailing list archives
Re: Five Ways to Screw Up SSL
From: "Ginsu Rabbit" <ginsurabbit () hotmail com>
Date: Sun, 21 May 2006 21:49:07 +0000
Michal Zalewski <lcamtuf () dione ids pl> wrote:
You claim that this is a practical checklist for five very common problems with SSL deployments... but to me, they seem to be arbitrarily chosen, partly inaccurate (see #3), and otherwise very much random.
Inaccurate? Not to my knowledge. Incomplete, certainly, but not inaccurate. If you have additions or corrections please send them through. Random? Slightly. =) Arbitrary? Not really. Major applications have made and continue to make these errors. For example: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6249270 Note the default setting of validate-server-cert. http://www-128.ibm.com/developerworks/websphere/techjournal/0502_benantar/0502_benantar.html Check the section "Endpoint validation." http://e-docs.bea.com/wls/docs81/config_xml/SSL.html#HostnameVerificationIgnored BEA gets the default configuration correct, but a fair number of administrators will set this to true.
> SSL Mistake #1 - Trusting too many Certificate Authorities > Most SSL servers do not have this problem [...] So why is it #1?
The numbers *are* completely arbitrary. They don't indicate any kind of priority.
> SSL Mistake #2 - Assuming a signed certificate is the right > certificate I don't understand what you're trying to say here: it seems to me that you're suggesting that allowing all users with a valid certificate the same privileges is a bad idea. Probably, but this has little to do with certificates or SSL - the same may be true for passwords or any other scheme.
Agreed. However, application developers and administrators generally have an intuitive understanding of password authentication. They don't understand client certificates as well, and so they screw this up. As an example of how easy it is to do, check out the IIS documentation for requiring client certificates. There are two steps: the first is setting "Require client certificates." The second is setting up a mapping from client certificates to accounts. Other web servers have similar configuration options. People forget to do the second step, or they do it badly. And so they treat all valid client certificates as identical. Microsoft's documentation for this is clearer than most. Other applications make it really difficult to configure this mapping, and so administrators and developers get it wrong.
> 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. > > [...] > > 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. You are very, very seriously confused about the relation between SSL, TCP, and just about everything else.
I think my reference to a TCP connection instead of an SSL connection may have been confusing. I was referring to the difference between sending data in clear-text over a TCP connection vs establishing SSL over the TCP connection and sending the data encrypted. I've seen multiple applications where, if an SSL connection failed, would try for an unencrypted connection instead. The conversation that prompted this recommendation went something like this. "You can't fall back to an http connection here, if https doesn't work you have to give up." "Why?" "Because an attacker could be eavesdropping, or they could force you to talk to the wrong server." "Huh? If someone doesn't want to use http, they shouldn't have a server running on port 80." Some application developers have been told "use SSL for these connections," but they don't understand why. They put too much faith in the privacy of TCP connections, and in the authenticity of the IP addresses they use. Because they don't know of any methods to attack unencrypted TCP connections, they assume it can't be done. Does this clear up why I included mistake #3 in the list?
> SSL Mistake #4 - Allowing insecure SSL ciphers > > This is not a paper about cryptography, and I am not going to tell you > which SSL ciphers are safe. Kind of defeats the purpose of a checklist, then?
No. The goal of this particular recommendation is to make people aware that they need to think about the SSL ciphers they use. Different applications have different legal and policy requirements for SSL ciphers, and unfortunately in many cases application developers are not aware of those requirements. They need to find out what policies apply to their applications, and make sure that they enforce those policies. -- GR _________________________________________________________________Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/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 Brian Eaton (May 23)
- 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)