Example Sins

Interestingly, despite the fact that this sin is extremely widespread (at one point or another, the problem has affected at least 90 percent of all applications using SSL but not HTTPS), as of this writing, there are no entries for this risk in the Common Vulnerabilities and Exposures database (CVE) at http://cve.mitre.org. Nor are there entries in similar databases. CVE tends to have listings of vulnerabilities in widely distributed applications, and this problem tends to occur more often in single-instance custom applications. But, we still have examples.

E-mail Clients

Protocols for sending and checking mail have supported SSL extensions for quite a while. There are multiple such extensions for Post Office Protocol3 (POP3), Internet Message Access Protocol (IMAP), and Simple Mail Transfer Protocol (SMTP). With these extensions, the client logs in the way it normally would, except that it is done over an SSL tunnel. Of course, the client should validate the server before using that tunnel.

When these protocols first came out, many mail clients failed to implement certificate validation. Those that did implement some validation usually did not check the hostname, making attacks possible. To this date, most mailers lack support for CRLs or OCSP (even optional support).

When the Mac OS X operating system came out in 2001, their mail program lacked SSL support altogether. Support for SSL showed up the next year in 10.1, but it was susceptible to the kinds of attacks we have discussed. It wasnt until 10.3 was released that they began doing reasonable authentication of server certificates (including checking the DN field and the subjectAltName extension).

Safari Web Browser

HTTPS provides more built-in certificate validation than generic SSL by default, primarily because the specification for the protocol dictates it. Specifically, the protocol forces checking the date against the certificate validity period, tracing the certificate to a trusted root and comparing the hostname to the data in the certificate (though there are some exceptions to this checking).

But, the Web is a pretty dynamic place. With things like redirects and JavaScript, a browser cant always ensure the intent of the person driving it. They generally validate the hostname pulled from the final URL, so there is still some room to fool the web browser. For example, if you were to buy an airline ticket off united.com, you would silently get redirected to itn.net, and the SSL certificate would come from there, without any warning dialog.

For this reason, proper validation when using a web browser requires a user to click on the lock and look at the certificate, to make sure the hostname in the certificate matches the hostname the user intended. Its the user s responsibility to make sure that, for example, itn.net really is the right server. For this reason and others, human failures are common. (People will generally keep connecting even when a warning dialog is thrown.)

In Apples Safari, however, the human never gets the chance to make a bad decision, because the browser never lets the user look at the certificate! In most browsers, when you click on the lock, the certificate will appear. With Safari, nothing happens. This can have bad consequences, such as making phishing attacks a bit easier.

According to Apple product security, they intentionally avoid showing a certificate because they dont want to confuse users. They believe that, in pretty much all of the cases where a warning dialog pops up, people will ignore the dialog anyway, so why detract from the user experience with the cryptic presentation of a certificate?

All Apple really would need to do is, when the user clicks the lock, have a dialog box that shows the hostname that is in the certificate (and, if its known to be different, highlight the host that the user wanted). The details of the certificate are largely irrelevant, though a details button could be used to satisfy true geeks .

The Stunnel SSL Proxy

Lets say you have a really nice mail program you want to use securely, but it doesnt support SSL. You can point your client to the Stunnel SSL proxy running on your local machine, and have the proxy do all the SSL talk for you. The end result will, ideally , be a secure connection.

Unfortunately, thats hard to get with Stunnel. By default, Stunnel does no validation. If you do request validation, you can either validate optionally (that is, if it doesnt validate, connect anyway, which is a bad idea), validate against an allow list (reasonable, but not always appropriate), or validate the date and chain of trust, without actually checking the proper certificate fields.

That makes Stunnel pretty close to worthless for achieving its stated goals!



19 Deadly Sins of Software Security. Programming Flaws and How to Fix Them
Writing Secure Code
ISBN: 71626751
EAN: 2147483647
Year: 2003
Pages: 239

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net