[RFC] Requiring trust for server connections

[Gregory Szorc]

On Mon, Apr 11, 2016 at 8:46 AM, Kevin Bullock <
kbullock+mercurial at ringworld.org> wrote:

> > On Apr 9, 2016, at 13:45, Gregory Szorc <gregory.szorc at gmail.com> wrote:
> >
> > Currently, when Mercurial establishes a TLS connection with a HTTPS or
> SMTP server and we are unable to verify trust in the remote x509
> certificate (no CA certs loaded or no SHA-1 certificate fingerprint
> defined), we print a warning and continue connecting. e.g.
> >
> > $ hg clone https://hg.mozilla.org/mozilla-central
> > warning: hg.mozilla.org certificate with fingerprint
> af:27:b9:34:47:4e:e5:98:01:f6:83:2b:51:c9:aa:d8:df:fb:1a:27 not verified
> (check hostfingerprints or web.cacerts config setting)
> > destination directory: mozilla-central
> > ...
> >
> > *This behavior is insecure.* Yes, bits are encrypted in transit. But
> there is no trust in the remote certificate. It could be a self-signed
> certificate. There could be a MITM attack. This could lead to credential
> stealing (in the case of HTTP basic auth). It could lead to repo poisoning
> and e.g. build automation pulling and distributing malicious code.
> >
> > What's more is that Python versions without the revamped ssl module
> (normally 2.7.9+ but distros like RHEL/CentOS have backported the modern
> ssl goodies to e.g. 2.7.5) are unable to load the system CA store. This
> means a large amount of Mercurial installs have this insecure behavior by
> default.
> >
> > I would like to propose changing the connection behavior to fail unless
> trust can be established with the remote x509 certificate. In short, we
> would require a CA store or a pinned fingerprint to establish a TLS
> connection.
> >
> > This is a massive backwards incompatible change and will break many
> things in the wild. But I think it is the correct thing to do because,
> well, it actually provides security.
> >
> > This insecure behavior has always bothered me. But with the recent
> security vulnerabilities that could lead to local code execution when
> pulling from a malicious remote, I think we should provide defense in depth
> against this type of attack in the future by refusing to connect to servers
> unless we can establish trust in their x509 certificate.
> >
> > Thoughts?
>
> I see plenty of benefit in doing it and no convincing reason not to.
>
> I think we'll want to craft our error message carefully to point users to
> a minimum-resistance (but still secure) fix for their environment. That
> also probably means some research on what the easiest way is in modern
> environments to enable SSL on Python with the system cert store.
>

For Unixen, we probably could code a table of known paths to the system CA
store based on distro name. Practically every Unix machine I've used has a
ca-certificates or ca-certs or similar package installed pull in from e.g.
installing curl.

We could also consider distributing our own CA store/file. Practically the
entire world repackages Mozilla's CA store verbatim already.

Of course, I expect distros will want to define web.cacerts in their system
hgrc file. But that will be done by downstream packagers, not us.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160411/ca78454d/attachment.html>