[RFC] Requiring trust for server connections

[Kevin Bullock]

> 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.

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock