Re: Ncat's ca-bundle.crt file

[Daniel Miller <bonsaiviking () gmail com>]

On Sun, Nov 16, 2014 at 5:11 PM, David Fifield <david () bamsoftware com>
wrote:

> On Fri, Nov 14, 2014 at 11:23:58PM -0600, Daniel Miller wrote:
> > Ncat comes with a bundle of trusted CA certificates [1] for its SSL/TLS
> mode.
> > This file has not been updated since at least November 2011, and contains
> > several out-of-date certs (and probably some revoked ones). The
> procedures in
> > the associated README file are out-of-date since Windows versions after
> XP get
> > their certificates dynamically from Microsoft as needed, so the list
> present on
> > any system is not the complete list.
> >
> > I see a few alternatives:
> >
> > 1. We abandon the effort to keep an updated trust list and instead
> support
> > OS-specific ways of obtaining a trust list (doesn't work on Linux,
> according to
> > [2])
> >
> > 2. We use Mozilla's list, either downloaded from [3] or using the tool
> > mentioned in the README
> >
> > 3. (Not exclusive of the other options) We support a command-line flag to
> > specify a trust store.
>
> I think trying to maintain a CA list is a losing game. There are no
> incentives on Ncat's side to keep it up to date, so it will always fall
> out of date.
>
> We already trust the default OpenSSL trust store (/etc/ssl/certs) by
> calling SSL_CTX_set_default_verify_paths in ncat_posix.c. This works
> fine on Debian. I think some distros (e.g. Fedora) automatically sync
> the OpenSSL and NSS stores. As far as I know though,
> SSL_CTX_set_default_verify_paths only does anything on GNU/Linux.
>
> There is already --ssl-trustfile for #3.

Update:

I did some checking, and it looks like the situation is not so hopeless. As
David pointed out, we already trust OpenSSL's trust store. This is empty in
the package coming directly from OpenSSL, since they don't maintain a list
of trusted CA's, but most Linux distros (and hopefully other *nix-style
systems) will keep it up-to-date with some form of package management.

The biggest hole this leaves is Windows, where we build our own OpenSSL,
devoid of trusted certs, and rely solely on Ncat's ca-bundle.crt. However,
we are not the first ones to run into this issue! Here are a few references
that could help someone (perhaps a GSOC student?) build a verifier that
uses Windows' own CryptoAPI to check against the OS's trust store:

*
http://msdn.microsoft.com/en-us/library/windows/desktop/aa377163%28v=vs.85%29.aspx
- CertVerifyCertificateChainPolicy function from the CryptoAPI
* http://sourceforge.net/p/openvpn/mailman/message/8343543/ - A message
thread from the OpenVPN development mailing list in which someone tries to
do exactly what we want: verify a certificate using CryptoAPI calls within
an application built with OpenSSL. I see at least 4 versions of the patch,
and I don't know what they ended up with, but it looks like a good research
starting point.
* http://www.mail-archive.com/openssl-dev () openssl org/msg26956.html - A
different approach (entire thread contains rebuttals and code changes),
building a lookup method for pulling in certs for a different
*_set_default_verify_paths function to use.


In addition to these Windows possibilities, it would be good to find out
how well things are handled in some other OSs: OS X in particular, I don't
know if they populate the OpenSSL cert store.

Dan

_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/