On Fri, May 16, 2014 at 10:12:08AM +0100, Jeremy Harris wrote:
> >ASN.1 strings can contain NUL octets, and are not C strings. This
> >implementation leaves the potential problem unchecked.
>
> We do not support names with embedded NULs.
Of course not, but certificates created by CAs potentially have
them, because strings in certificates are ASN.1 strings, not C
strings. If a CA issues "*.google.com\0www.mallory.org" to
mallory.org, C implementations that don't check for embedded NUL
bytes can be fooled. I put checks for this into Postfix in 2006.
Moxie publically demonstrated the problem by obtaining a "CN=*"
wildcard certificate from a CA in 2009.
http://www.theregister.co.uk/2009/07/30/universal_ssl_certificate/
I don't know whether all CAs have been remediated, but all verifiers
should be.
> The implementation here either converts NULs to #-sequences,
> per rfc4514, or treats it as terminating the string. Both
> ways are safe.
The "by terminating the string" variant is not safe. Sure Exim
won't crash, but it will allow impersonation.
> >Later, for DANE, you'll need to allow multiple names any one of
> >which might match the peer certificate.
>
> This isn't DANE. Do you see it as potentially part of a DANE
> implementation?
I know it is not DANE yet, but because you'll need multiple names
for DANE, and they are also useful outside of DANE, I thought they
should there as part of the interface from the outset.
> > You also should probably
> >support wildcards "*.example.com".
>
> Agreed. The later-version GnuTLS implementation probably does
> already as it uses the builtin library routine, but the others
> need to.
OpenSSL 1.0.2 introduces X509_check_host() (for which a patch from
me improving the implementation is in Steve Henson's queue). This
takes a "flags" argument that controlls wildcard support among
other things.
One option is to wait a bit and make support for this in Exim
conditional on OpenSSL 1.0.2. The code in the OpenSSL 1.0.2
implementation detects embedded NULs and does not match offending
certificates.
--
Viktor.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim
details at http://www.exim.org/ ##
