[RFC] Requiring trust for server connections

[Simon King]

On Mon, Apr 11, 2016 at 4:58 PM, Gregory Szorc <gregory.szorc at gmail.com>
wrote:

> 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.
>
>
There is a python package that bundles the Mozilla CA store:

https://certifi.io/en/latest/

...but I suppose operating system packages are easier for the sysadmin to
keep up to date.

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160412/6c016739/attachment.html>