sslutil: require TLS 1.1+ when supported
Currently, Mercurial will use TLS 1.0 or newer when connecting to
remote servers, selecting the highest TLS version supported by both
peers. On older Pythons, only TLS 1.0 is available. On newer Pythons,
TLS 1.1 and 1.2 should be available.
Security professionals recommend avoiding TLS 1.0 if possible.
PCI DSS 3.1 "strongly encourages" the use of TLS 1.2.
Known attacks like BEAST and POODLE exist against TLS 1.0 (although
mitigations are available and properly configured servers aren't
vulnerable).
I asked Eric Rescorla - Mozilla's resident crypto expert - whether
Mercurial should drop support for TLS 1.0. His response was
"if you can get away with it." Essentially, a number of servers on
the Internet don't support TLS 1.1+. This is why web browsers
continue to support TLS 1.0 despite desires from security experts.
This patch changes Mercurial's default behavior on modern Python
versions to require TLS 1.1+, thus avoiding known security issues
with TLS 1.0 and making Mercurial more secure by default. Rather
than drop TLS 1.0 support wholesale, we still allow TLS 1.0 to be
used if configured. This is a compromise solution - ideally we'd
disallow TLS 1.0. However, since we're not sure how many Mercurial
servers don't support TLS 1.1+ and we're not sure how much user
inconvenience this change will bring, I think it is prudent to ship
an escape hatch that still allows usage of TLS 1.0. In the default
case our users get better security. In the worst case, they are no
worse off than before this patch.
This patch has no effect when running on Python versions that don't
support TLS 1.1+.
As the added test shows, connecting to a server that doesn't
support TLS 1.1+ will display a warning message with a link to
our wiki, where we can guide people to configure their client to
allow less secure connections.
[This file is here for historical purposes, all recent contributors
should appear in the changelog directly]
Andrea Arcangeli <andrea at suse.de>
Thomas Arendsen Hein <thomas at intevation.de>
Goffredo Baroncelli <kreijack at libero.it>
Muli Ben-Yehuda <mulix at mulix.org>
Mikael Berthe <mikael at lilotux.net>
Benoit Boissinot <bboissin at gmail.com>
Brendan Cully <brendan at kublai.com>
Vincent Danjean <vdanjean.ml at free.fr>
Jake Edge <jake at edge2.net>
Michael Fetterman <michael.fetterman at intel.com>
Edouard Gomez <ed.gomez at free.fr>
Eric Hopper <hopper at omnifarious.org>
Alecs King <alecsk at gmail.com>
Volker Kleinfeld <Volker.Kleinfeld at gmx.de>
Vadim Lebedev <vadim at mbdsys.com>
Christopher Li <hg at chrisli.org>
Chris Mason <mason at suse.com>
Colin McMillen <mcmillen at cs.cmu.edu>
Wojciech Milkowski <wmilkowski at interia.pl>
Chad Netzer <chad.netzer at gmail.com>
Bryan O'Sullivan <bos at serpentine.com>
Vicent Seguí Pascual <vseguip at gmail.com>
Sean Perry <shaleh at speakeasy.net>
Nguyen Anh Quynh <aquynh at gmail.com>
Ollivier Robert <roberto at keltia.freenix.fr>
Alexander Schremmer <alex at alexanderweb.de>
Arun Sharma <arun at sharma-home.net>
Josef "Jeff" Sipek <jeffpc at optonline.net>
Kevin Smith <yarcs at qualitycode.com>
TK Soh <teekaysoh at yahoo.com>
Radoslaw Szkodzinski <astralstorm at gorzow.mm.pl>
Samuel Tardieu <sam at rfc1149.net>
K Thananchayan <thananck at yahoo.com>
Andrew Thompson <andrewkt at aktzero.com>
Michael S. Tsirkin <mst at mellanox.co.il>
Rafael Villar Burke <pachi at mmn-arquitectos.com>
Tristan Wibberley <tristan at wibberley.org>
Mark Williamson <mark.williamson at cl.cam.ac.uk>