User: Password:
|
|
Subscribe / Log in / New account

checking is not as simple as it seams

checking is not as simple as it seams

Posted Nov 1, 2012 22:28 UTC (Thu) by noxxi (subscriber, #4994)
Parent article: Holes discovered in SSL certificate validation

In theory, it is not the task of a plain TLS library to check the name in the certificate, because these checks are application specific:
There is RFC2818 for https (used for XMPP and FTP too), which allows something like www*.domain or even w*w.domain, and forbids checking of common name if a subjectAltName is specified. Then there is RFC4513 for ldaps (used also for POP3, IMAP and NNTP), which contrary to RFC2818 does not allow wildcards in common name, but will check common name even if there are subjectAltNames, and allows only wildcards like *.domain. RFC3207 for SMTP doesn't have any real specification at all on how the certificate should be checked.
Another problem is, that these TLS libraries often only care about the TLS connection itself, e.g. have no access to the hostname to do the checking.
Given this chaos it is no wonder, that the names are not checked correctly, if they are checked at all.

As a maintainer of IO::Socket::SSL it took me some time to accept, that a TLS library should at least provide ways to make hostname verification easy. In IO::Socket::SSL you now just need to set the verification scheme to something like 'http','ldap'... and maybe provide the hostname.
Sadly Perl was not mentioned in the paper at all, but from what I see major libraries like LWP, Net::LDAP or Mojo all implement correct name checking by using the functionality provided by IO::Socket::SSL.

A similar problem is checking against the trusted certificate agencies (CA).
Most libraries expect the CA store to be provided by the user. If none are given no checking will be done. Only few have at least some sensible defaults: pythons httplib2 comes with a minimal CA store with only few CAs, while Perls LWP uses Mozilla::CA to get the CAs mozilla trusts.

Another problem is the verification of certificate revocations.
OpenSSL provides hooks for local certificate revocation lists (CRL), so most libraries using OpenSSL (like the default libs from Perl, Python or Ruby) offer an option to give a CRL path, but don't have a default. And they don't care about keeping the CRLs current. And while OpenSSL has itself an OCSP implementation to check the revocation status online, it does not have a (documented) API for it, so no libraries on top of OpenSSL provide such functionality. Other Implementations like mono don't even offer simple CRL checking.

In summary: The APIs of TLS libraries are broken in lots of other ways.
German readers might have a look at a talk I gave last year about these issues: http://noxxi.de/pws/2011/https.pdf


(Log in to post comments)

checking is not as simple as it seams

Posted Nov 5, 2012 13:14 UTC (Mon) by mirabilos (subscriber, #84359) [Link]

Ah, so that's where the wildcard specs come from. I hadn't realised there were different RFCs for them, even. Refer http://lists.nongnu.org/archive/html/lynx-dev/2012-11/msg... to why I am interested… damn, now need to go back to that code and review it.

But I’ll definitely have a look at your linked PDF, thanks!


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds