[RFC] Requiring trust for server connections

[Augie Fackler]

On Sun, Apr 10, 2016 at 08:34:02PM +0900, Yuya Nishihara wrote:
> On Sat, 9 Apr 2016 11:45:38 -0700, Gregory Szorc 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.
>
> +1 for making insecure connection opt-in. It might break some ancient
> environments, but IMHO they should be broken. We've provided "certificate
> not verified" warning since 1.7, which seems good enough to make a BC.

I concur.

> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel