[RFC] Requiring trust for server connections

[Matt Mackall]

On Sun, 2016-04-10 at 12:18 -0400, Augie Fackler wrote:
> 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.

I'm fine with this, provided:

- we do it more than a week from the code freeze (so not 3.8)
- we have decent docs on the wiki including advice for packagers
- those docs include py2.6
- the error message includes a link to the docs

-- 
Mathematics is the supreme nostalgia of our time.