Nmap Development mailing list archives
Re: Ncat's ca-bundle.crt file
From: Daniel Miller <bonsaiviking () gmail com>
Date: Fri, 9 Jan 2015 23:56:52 -0600
On Fri, Jan 9, 2015 at 10:46 PM, Daniel Miller <bonsaiviking () gmail com> wrote:
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/TLSmode.This file has not been updated since at least November 2011, andcontainsseveral out-of-date certs (and probably some revoked ones). Theprocedures inthe associated README file are out-of-date since Windows versions afterXP gettheir certificates dynamically from Microsoft as needed, so the listpresent onany system is not the complete list. I see a few alternatives: 1. We abandon the effort to keep an updated trust list and insteadsupportOS-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 flagtospecify 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
A couple more notes I forgot: * nmap-update uses libsvn, so the trust issues are not really exposed to us. It appears, though, that on Windows, libsvn does use CryptoAPI calls for certificate verification. Source is in subversion/libsvn_subr/win32_crypto.c * I added an issue over at Github for this: https://github.com/nmap/nmap/issues/42 * OS X solution may involve the Certificate, Key, and Trust Services API ( https://developer.apple.com/library/mac/documentation/Security/Conceptual/CertKeyTrustProgGuide/02concepts/concepts.html). Here's a bug report on Mumble which discusses the various keystores available and which may be a helpful starting place for research: https://github.com/mumble-voip/mumble/issues/1483 Dan
_______________________________________________ Sent through the dev mailing list http://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Re: Ncat's ca-bundle.crt file Daniel Miller (Jan 09)
- Re: Ncat's ca-bundle.crt file David Fifield (Jan 09)
- Re: Ncat's ca-bundle.crt file Daniel Miller (Jan 09)