facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-07 15:27:13 +03:00
Code Issues Projects Releases Wiki Activity
3601cf654f
sapling/tests/test-https.t

556 lines
27 KiB
Perl
Raw Normal View History

tests: replace exit 80 with #require
2014-08-06 20:43:59 +04:00
#require serve ssl
serve: fix https mode and add test The https mode failed in super because BaseRequestHandler is an old-style class. This introduces the first test of https client/server functionality - and "hghave ssl". The test is currently only run on Python 2.6.
2010-10-17 06:13:35 +04:00
tests: replace exit 80 with #require
2014-08-06 20:43:59 +04:00
Proper https client requires the built-in ssl from Python 2.6.
serve: fix https mode and add test The https mode failed in super because BaseRequestHandler is an old-style class. This introduces the first test of https client/server functionality - and "hghave ssl". The test is currently only run on Python 2.6.
2010-10-17 06:13:35 +04:00
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
Make server certificates:
serve: fix https mode and add test The https mode failed in super because BaseRequestHandler is an old-style class. This introduces the first test of https client/server functionality - and "hghave ssl". The test is currently only run on Python 2.6.
2010-10-17 06:13:35 +04:00
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
$ CERTSDIR="$TESTDIR/sslcerts"
$ cat "$CERTSDIR/priv.pem" "$CERTSDIR/pub.pem" >> server.pem
serve: fix https mode and add test The https mode failed in super because BaseRequestHandler is an old-style class. This introduces the first test of https client/server functionality - and "hghave ssl". The test is currently only run on Python 2.6.
2010-10-17 06:13:35 +04:00
$ PRIV=`pwd`/server.pem
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
$ cat "$CERTSDIR/priv.pem" "$CERTSDIR/pub-not-yet.pem" > server-not-yet.pem
$ cat "$CERTSDIR/priv.pem" "$CERTSDIR/pub-expired.pem" > server-expired.pem
test-https: test basic functions of client certificate authentication Because hgweb doesn't support client certificates, I just patched it to require client certificates that are signed and verified by the server certificate. This won't be ideal for production servers, but should be okay for the test. The encrypted key file will be used by future patches. I couldn't figure out a way to redirect a password prompt provided by OpenSSL, so it isn't tested for now.
2015-05-07 11:38:22 +03:00
serve: fix https mode and add test The https mode failed in super because BaseRequestHandler is an old-style class. This introduces the first test of https client/server functionality - and "hghave ssl". The test is currently only run on Python 2.6.
2010-10-17 06:13:35 +04:00
$ hg init test
$ cd test
$ echo foo>foo
$ mkdir foo.d foo.d/bAr.hg.d foo.d/baR.d.hg
$ echo foo>foo.d/foo
$ echo bar>foo.d/bAr.hg.d/BaR
$ echo bar>foo.d/baR.d.hg/bAR
$ hg commit -A -m 1
adding foo
adding foo.d/bAr.hg.d/BaR
adding foo.d/baR.d.hg/bAR
adding foo.d/foo
$ hg serve -p $HGPORT -d --pid-file=../hg0.pid --certificate=$PRIV
$ cat ../hg0.pid >> $DAEMON_PIDS
cacert: improve error report when web.cacert file does not exist
2011-03-06 19:27:07 +03:00
cacert not found
$ hg in --config web.cacerts=no-such.pem https://localhost:$HGPORT/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
cacert: improve error report when web.cacert file does not exist
2011-03-06 19:27:07 +03:00
abort: could not find web.cacerts: no-such.pem
[255]
serve: fix https mode and add test The https mode failed in super because BaseRequestHandler is an old-style class. This introduces the first test of https client/server functionality - and "hghave ssl". The test is currently only run on Python 2.6.
2010-10-17 06:13:35 +04:00
Test server address cannot be reused
test-http and test-https: partially adapt for Windows
2012-06-19 21:45:00 +04:00
#if windows
$ hg serve -p $HGPORT --certificate=$PRIV 2>&1
tests: remove glob from output lines containing no glob character
2013-02-14 01:05:30 +04:00
abort: cannot start server at ':$HGPORT':
test-http and test-https: partially adapt for Windows
2012-06-19 21:45:00 +04:00
[255]
#else
serve: fix https mode and add test The https mode failed in super because BaseRequestHandler is an old-style class. This introduces the first test of https client/server functionality - and "hghave ssl". The test is currently only run on Python 2.6.
2010-10-17 06:13:35 +04:00
$ hg serve -p $HGPORT --certificate=$PRIV 2>&1
abort: cannot start server at ':$HGPORT': Address already in use
[255]
test-http and test-https: partially adapt for Windows
2012-06-19 21:45:00 +04:00
#endif
serve: fix https mode and add test The https mode failed in super because BaseRequestHandler is an old-style class. This introduces the first test of https client/server functionality - and "hghave ssl". The test is currently only run on Python 2.6.
2010-10-17 06:13:35 +04:00
$ cd ..
sslutil: add devel.disableloaddefaultcerts to disable CA loading There are various tests for behavior when CA certs aren't loaded. Previously, we would pass --insecure to disable loading of CA certs. This has worked up to this point because the error message for --insecure and no CAs loaded is the same. Upcoming commits will change the error message for --insecure and will change behavior when CAs aren't loaded. This commit introduces the ability to disable loading of CA certs by setting devel.disableloaddefaultcerts. This allows a testing backdoor to disable loading of CA certs even if system/default CA certs are available. The flag is purposefully not exposed to end-users because there should not be a need for this in the wild: certificate pinning and --insecure provide workarounds to disable cert loading/validation. Tests have been updated to use the new method. The variable used to disable CA certs has been renamed because the method is not OS X specific.
2016-06-02 05:57:20 +03:00
Our test cert is not signed by a trusted CA. It should fail to verify if
we are able to load CA certs.
serve: fix https mode and add test The https mode failed in super because BaseRequestHandler is an old-style class. This introduces the first test of https client/server functionality - and "hghave ssl". The test is currently only run on Python 2.6.
2010-10-17 06:13:35 +04:00
tests: better testing of loaded certificates Tests were failing on systems like RHEL 7 where loading the system certificates results in CA certs being reported to Python. We add a feature that detects when we're able to load *and detect* the loading of system certificates. We update the tests to cover the 3 scenarios: 1) system CAs are loadable and detected 2) system CAs are loadable but not detected 3) system CAs aren't loadable
2016-07-02 05:27:34 +03:00
#if sslcontext defaultcacerts no-defaultcacertsloaded
serve: fix https mode and add test The https mode failed in super because BaseRequestHandler is an old-style class. This introduces the first test of https client/server functionality - and "hghave ssl". The test is currently only run on Python 2.6.
2010-10-17 06:13:35 +04:00
$ hg clone https://localhost:$HGPORT/ copy-pull
sslutil: emit warning when no CA certificates loaded If no CA certificates are loaded, that is almost certainly a/the reason certificate verification fails when connecting to a server. The modern ssl module in Python 2.7.9+ provides an API to access the list of loaded CA certificates. This patch emits a warning on modern Python when certificate verification fails and there are no loaded CA certificates. There is no way to detect the number of loaded CA certificates unless the modern ssl module is present. Hence the differences in test output depending on whether modern ssl is available. It's worth noting that a test which specifies a CA file still renders this warning. That is because the certificate it is loading is a x509 client certificate and not a CA certificate. This test could be updated if anyone is so inclined.
2016-06-30 05:43:27 +03:00
(an attempt was made to load CA certificates but none were loaded; see https://mercurial-scm.org/wiki/SecureConnections for how to configure Mercurial to avoid this error)
test-https: glob error messages more so we pass on Python 2.7.9 Python 2.7.9 cleans up how it stringifies SSL errors, so we have to look only for the important bit (certificate verify failed) rather than looking for specific ssl module goop (which is now unstable).
2015-01-13 23:15:37 +03:00
abort: error: *certificate verify failed* (glob)
ssl: on OS X, use a dummy cert to trick Python/OpenSSL to use system CA certs This will give PKI-secure behaviour out of the box, without any configuration. Setting web.cacerts to any value or empty will disable this trick. This dummy cert trick only works on OS X 10.6+, but 10.5 had Python 2.5 which didn't have certificate validation at all.
2014-09-26 04:19:48 +04:00
[255]
tests: better testing of loaded certificates Tests were failing on systems like RHEL 7 where loading the system certificates results in CA certs being reported to Python. We add a feature that detects when we're able to load *and detect* the loading of system certificates. We update the tests to cover the 3 scenarios: 1) system CAs are loadable and detected 2) system CAs are loadable but not detected 3) system CAs aren't loadable
2016-07-02 05:27:34 +03:00
#endif
#if no-sslcontext defaultcacerts
$ hg clone https://localhost:$HGPORT/ copy-pull
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
sslutil: try to find CA certficates in well-known locations Many Linux distros and other Nixen have CA certificates in well-defined locations. Rather than potentially fail to load any CA certificates at all (which will always result in a certificate verification failure), we scan for paths to known CA certificate files and load one if seen. Because a proper Mercurial install will have the path to the CA certificate file defined at install time, we print a warning that the install isn't proper and provide a URL with instructions to correct things. We only perform path-based fallback on Pythons that don't know how to call into OpenSSL to load the default verify locations. This is because we trust that Python/OpenSSL is properly configured and knows better than Mercurial. So this new code effectively only runs on Python <2.7.9 (technically Pythons without the modern ssl module).
2016-07-07 07:16:00 +03:00
(using CA certificates from *; if you see this message, your Mercurial install is not properly configured; see https://mercurial-scm.org/wiki/SecureConnections for how to configure Mercurial to avoid this message) (glob) (?)
tests: better testing of loaded certificates Tests were failing on systems like RHEL 7 where loading the system certificates results in CA certs being reported to Python. We add a feature that detects when we're able to load *and detect* the loading of system certificates. We update the tests to cover the 3 scenarios: 1) system CAs are loadable and detected 2) system CAs are loadable but not detected 3) system CAs aren't loadable
2016-07-02 05:27:34 +03:00
abort: error: *certificate verify failed* (glob)
[255]
#endif
sslutil: handle default CA certificate loading on Windows See the inline comment for what's going on here. There is magic built into the "ssl" module that ships with modern CPython that knows how to load the system CA certificates on Windows. Since we're not shipping a CA bundle with Mercurial, if we're running on legacy CPython there's nothing we can do to load CAs on Windows, so it makes sense to print a warning. I don't anticipate many people will see this warning because the official (presumed popular) Mercurial distributions on Windows bundle Python and should be distributing a modern Python capable of loading system CA certs.
2016-07-04 20:04:11 +03:00
#if no-sslcontext windows
$ hg clone https://localhost:$HGPORT/ copy-pull
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info
sslutil: handle default CA certificate loading on Windows See the inline comment for what's going on here. There is magic built into the "ssl" module that ships with modern CPython that knows how to load the system CA certificates on Windows. Since we're not shipping a CA bundle with Mercurial, if we're running on legacy CPython there's nothing we can do to load CAs on Windows, so it makes sense to print a warning. I don't anticipate many people will see this warning because the official (presumed popular) Mercurial distributions on Windows bundle Python and should be distributing a modern Python capable of loading system CA certs.
2016-07-04 20:04:11 +03:00
(unable to load Windows CA certificates; see https://mercurial-scm.org/wiki/SecureConnections for how to configure Mercurial to avoid this message)
abort: error: *certificate verify failed* (glob)
[255]
#endif
sslutil: issue warning when unable to load certificates on OS X Previously, failure to load system certificates on OS X would lead to a certificate verify failure and that's it. We now print a warning message with a URL that will contain information on how to configure certificates on OS X. As the inline comment states, there is room to improve here. I think we could try harder to detect Homebrew and MacPorts installed certificate files, for example. It's worth noting that Homebrew's openssl package uses `security find-certificate -a -p` during package installation to export the system keychain root CAs to etc/openssl/cert.pem. This is something we could consider adding to setup.py. We could also encourage packagers to do this. For now, I'd just like to get this warning (which matches Windows behavior) landed. We should have time to improve things before release.
2016-07-07 06:46:05 +03:00
#if no-sslcontext osx
$ hg clone https://localhost:$HGPORT/ copy-pull
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info
sslutil: issue warning when unable to load certificates on OS X Previously, failure to load system certificates on OS X would lead to a certificate verify failure and that's it. We now print a warning message with a URL that will contain information on how to configure certificates on OS X. As the inline comment states, there is room to improve here. I think we could try harder to detect Homebrew and MacPorts installed certificate files, for example. It's worth noting that Homebrew's openssl package uses `security find-certificate -a -p` during package installation to export the system keychain root CAs to etc/openssl/cert.pem. This is something we could consider adding to setup.py. We could also encourage packagers to do this. For now, I'd just like to get this warning (which matches Windows behavior) landed. We should have time to improve things before release.
2016-07-07 06:46:05 +03:00
(unable to load CA certificates; see https://mercurial-scm.org/wiki/SecureConnections for how to configure Mercurial to avoid this message)
abort: localhost certificate error: no certificate received
tests: regenerate x509 test certificates The old x509 test certificates were using cryptographic settings that are ancient by today's standards, namely 512 bit RSA keys. To put things in perspective, browsers have been dropping support for 1024 bit RSA keys. I think it is important that tests match the realities of the times. And 2048 bit RSA keys with SHA-2 hashing are what the world is moving to. This patch replaces all the x509 certificates with new versions using modern best practices. In addition, the docs for generating the keys have been updated, as the existing docs left out a few steps, namely how to generate certs that were not active yet or expired.
2016-07-13 08:26:04 +03:00
(set hostsecurity.localhost:certfingerprints=sha256:20:de:b3:ad:b4:cd:a5:42:f0:74:41:1c:a2:70:1e:da:6e:c0:5c:16:9e:e7:22:0f:f1:b7:e5:6e:e4:92:af:7e config setting or use --insecure to connect insecurely)
sslutil: issue warning when unable to load certificates on OS X Previously, failure to load system certificates on OS X would lead to a certificate verify failure and that's it. We now print a warning message with a URL that will contain information on how to configure certificates on OS X. As the inline comment states, there is room to improve here. I think we could try harder to detect Homebrew and MacPorts installed certificate files, for example. It's worth noting that Homebrew's openssl package uses `security find-certificate -a -p` during package installation to export the system keychain root CAs to etc/openssl/cert.pem. This is something we could consider adding to setup.py. We could also encourage packagers to do this. For now, I'd just like to get this warning (which matches Windows behavior) landed. We should have time to improve things before release.
2016-07-07 06:46:05 +03:00
[255]
#endif
tests: better testing of loaded certificates Tests were failing on systems like RHEL 7 where loading the system certificates results in CA certs being reported to Python. We add a feature that detects when we're able to load *and detect* the loading of system certificates. We update the tests to cover the 3 scenarios: 1) system CAs are loadable and detected 2) system CAs are loadable but not detected 3) system CAs aren't loadable
2016-07-02 05:27:34 +03:00
#if defaultcacertsloaded
$ hg clone https://localhost:$HGPORT/ copy-pull
sslutil: try to find CA certficates in well-known locations Many Linux distros and other Nixen have CA certificates in well-defined locations. Rather than potentially fail to load any CA certificates at all (which will always result in a certificate verification failure), we scan for paths to known CA certificate files and load one if seen. Because a proper Mercurial install will have the path to the CA certificate file defined at install time, we print a warning that the install isn't proper and provide a URL with instructions to correct things. We only perform path-based fallback on Pythons that don't know how to call into OpenSSL to load the default verify locations. This is because we trust that Python/OpenSSL is properly configured and knows better than Mercurial. So this new code effectively only runs on Python <2.7.9 (technically Pythons without the modern ssl module).
2016-07-07 07:16:00 +03:00
(using CA certificates from *; if you see this message, your Mercurial install is not properly configured; see https://mercurial-scm.org/wiki/SecureConnections for how to configure Mercurial to avoid this message) (glob) (?)
tests: better testing of loaded certificates Tests were failing on systems like RHEL 7 where loading the system certificates results in CA certs being reported to Python. We add a feature that detects when we're able to load *and detect* the loading of system certificates. We update the tests to cover the 3 scenarios: 1) system CAs are loadable and detected 2) system CAs are loadable but not detected 3) system CAs aren't loadable
2016-07-02 05:27:34 +03:00
abort: error: *certificate verify failed* (glob)
[255]
#endif
#if no-defaultcacerts
tests: test case where default ca certs not available I'm not a fan of TLS tests not testing both branches of a possible configuration. While we have test coverage of the inability to validate a cert later in this file, I insist that we add this branch so our testing of security code is extra comprehensive.
2016-06-30 05:49:39 +03:00
$ hg clone https://localhost:$HGPORT/ copy-pull
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
sslutil: issue warning when unable to load certificates on OS X Previously, failure to load system certificates on OS X would lead to a certificate verify failure and that's it. We now print a warning message with a URL that will contain information on how to configure certificates on OS X. As the inline comment states, there is room to improve here. I think we could try harder to detect Homebrew and MacPorts installed certificate files, for example. It's worth noting that Homebrew's openssl package uses `security find-certificate -a -p` during package installation to export the system keychain root CAs to etc/openssl/cert.pem. This is something we could consider adding to setup.py. We could also encourage packagers to do this. For now, I'd just like to get this warning (which matches Windows behavior) landed. We should have time to improve things before release.
2016-07-07 06:46:05 +03:00
(unable to load * certificates; see https://mercurial-scm.org/wiki/SecureConnections for how to configure Mercurial to avoid this message) (glob) (?)
tests: test case where default ca certs not available I'm not a fan of TLS tests not testing both branches of a possible configuration. While we have test coverage of the inability to validate a cert later in this file, I insist that we add this branch so our testing of security code is extra comprehensive.
2016-06-30 05:49:39 +03:00
abort: localhost certificate error: no certificate received
tests: regenerate x509 test certificates The old x509 test certificates were using cryptographic settings that are ancient by today's standards, namely 512 bit RSA keys. To put things in perspective, browsers have been dropping support for 1024 bit RSA keys. I think it is important that tests match the realities of the times. And 2048 bit RSA keys with SHA-2 hashing are what the world is moving to. This patch replaces all the x509 certificates with new versions using modern best practices. In addition, the docs for generating the keys have been updated, as the existing docs left out a few steps, namely how to generate certs that were not active yet or expired.
2016-07-13 08:26:04 +03:00
(set hostsecurity.localhost:certfingerprints=sha256:20:de:b3:ad:b4:cd:a5:42:f0:74:41:1c:a2:70:1e:da:6e:c0:5c:16:9e:e7:22:0f:f1:b7:e5:6e:e4:92:af:7e config setting or use --insecure to connect insecurely)
tests: test case where default ca certs not available I'm not a fan of TLS tests not testing both branches of a possible configuration. While we have test coverage of the inability to validate a cert later in this file, I insist that we add this branch so our testing of security code is extra comprehensive.
2016-06-30 05:49:39 +03:00
[255]
ssl: on OS X, use a dummy cert to trick Python/OpenSSL to use system CA certs This will give PKI-secure behaviour out of the box, without any configuration. Setting web.cacerts to any value or empty will disable this trick. This dummy cert trick only works on OS X 10.6+, but 10.5 had Python 2.5 which didn't have certificate validation at all.
2014-09-26 04:19:48 +04:00
#endif
sslutil: per-host config option to define certificates Recent work has introduced the [hostsecurity] config section for defining per-host security settings. This patch builds on top of this foundation and implements the ability to define a per-host path to a file containing certificates used for verifying the server certificate. It is logically a per-host web.cacerts setting. This patch also introduces a warning when both per-host certificates and fingerprints are defined. These are mutually exclusive for host verification and I think the user should be alerted when security settings are ambiguous because, well, security is important. Tests validating the new behavior have been added. I decided against putting "ca" in the option name because a non-CA certificate can be specified and used to validate the server certificate (commonly this will be the exact public certificate used by the server). It's worth noting that the underlying Python API used is load_verify_locations(cafile=X) and it calls into OpenSSL's SSL_CTX_load_verify_locations(). Even OpenSSL's documentation seems to omit that the file can contain a non-CA certificate if it matches the server's certificate exactly. I thought a CA certificate was a special kind of x509 certificate. Perhaps I'm wrong and any x509 certificate can be used as a CA certificate [as far as OpenSSL is concerned]. In any case, I thought it best to drop "ca" from the name because this reflects reality.
2016-06-08 06:29:54 +03:00
Specifying a per-host certificate file that doesn't exist will abort
$ hg --config hostsecurity.localhost:verifycertsfile=/does/not/exist clone https://localhost:$HGPORT/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
sslutil: per-host config option to define certificates Recent work has introduced the [hostsecurity] config section for defining per-host security settings. This patch builds on top of this foundation and implements the ability to define a per-host path to a file containing certificates used for verifying the server certificate. It is logically a per-host web.cacerts setting. This patch also introduces a warning when both per-host certificates and fingerprints are defined. These are mutually exclusive for host verification and I think the user should be alerted when security settings are ambiguous because, well, security is important. Tests validating the new behavior have been added. I decided against putting "ca" in the option name because a non-CA certificate can be specified and used to validate the server certificate (commonly this will be the exact public certificate used by the server). It's worth noting that the underlying Python API used is load_verify_locations(cafile=X) and it calls into OpenSSL's SSL_CTX_load_verify_locations(). Even OpenSSL's documentation seems to omit that the file can contain a non-CA certificate if it matches the server's certificate exactly. I thought a CA certificate was a special kind of x509 certificate. Perhaps I'm wrong and any x509 certificate can be used as a CA certificate [as far as OpenSSL is concerned]. In any case, I thought it best to drop "ca" from the name because this reflects reality.
2016-06-08 06:29:54 +03:00
abort: path specified by hostsecurity.localhost:verifycertsfile does not exist: /does/not/exist
[255]
A malformed per-host certificate file will raise an error
$ echo baddata > badca.pem
sslutil: display a better error message when CA file loading fails Before, sslcontext.load_verify_locations() would raise a ssl.SSLError which would be caught further up the stack and converted to a urlerror. By that time, we lost track of what actually errored. Trapping the error here gives users a slightly more actionable error message. The behavior between Python <2.7.9 and Python 2.7.9+ differs. This is because our fake SSLContext class installed on <2.7.9 doesn't actually do anything during load_verify_locations: it defers actions until wrap_socket() time. Unfortunately, a number of errors can occur at wrap_socket() time and we're unable to ascertain what the root cause is. But that shouldn't stop us from providing better error messages to people running a modern and secure Python version.
2016-06-30 05:37:38 +03:00
#if sslcontext
$ hg --config hostsecurity.localhost:verifycertsfile=badca.pem clone https://localhost:$HGPORT/
abort: error loading CA file badca.pem: * (glob)
(file is empty or malformed?)
[255]
#else
sslutil: per-host config option to define certificates Recent work has introduced the [hostsecurity] config section for defining per-host security settings. This patch builds on top of this foundation and implements the ability to define a per-host path to a file containing certificates used for verifying the server certificate. It is logically a per-host web.cacerts setting. This patch also introduces a warning when both per-host certificates and fingerprints are defined. These are mutually exclusive for host verification and I think the user should be alerted when security settings are ambiguous because, well, security is important. Tests validating the new behavior have been added. I decided against putting "ca" in the option name because a non-CA certificate can be specified and used to validate the server certificate (commonly this will be the exact public certificate used by the server). It's worth noting that the underlying Python API used is load_verify_locations(cafile=X) and it calls into OpenSSL's SSL_CTX_load_verify_locations(). Even OpenSSL's documentation seems to omit that the file can contain a non-CA certificate if it matches the server's certificate exactly. I thought a CA certificate was a special kind of x509 certificate. Perhaps I'm wrong and any x509 certificate can be used as a CA certificate [as far as OpenSSL is concerned]. In any case, I thought it best to drop "ca" from the name because this reflects reality.
2016-06-08 06:29:54 +03:00
$ hg --config hostsecurity.localhost:verifycertsfile=badca.pem clone https://localhost:$HGPORT/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
tests: increase test-https malform error glob The recently introduced (fd348a6ace5a157c) test around malformed pem files hard codes an error message which doesn't appear to be cross platform agnostic. On our machines (centos6 if it matters) the test output differs: - abort: error: unknown error* (glob) + abort: error: _ssl.c:330: error:00000000:lib(0):func(0):reason(0) This patch increases the glob to cover the entire error message.
2016-06-15 04:14:42 +03:00
abort: error: * (glob)
sslutil: per-host config option to define certificates Recent work has introduced the [hostsecurity] config section for defining per-host security settings. This patch builds on top of this foundation and implements the ability to define a per-host path to a file containing certificates used for verifying the server certificate. It is logically a per-host web.cacerts setting. This patch also introduces a warning when both per-host certificates and fingerprints are defined. These are mutually exclusive for host verification and I think the user should be alerted when security settings are ambiguous because, well, security is important. Tests validating the new behavior have been added. I decided against putting "ca" in the option name because a non-CA certificate can be specified and used to validate the server certificate (commonly this will be the exact public certificate used by the server). It's worth noting that the underlying Python API used is load_verify_locations(cafile=X) and it calls into OpenSSL's SSL_CTX_load_verify_locations(). Even OpenSSL's documentation seems to omit that the file can contain a non-CA certificate if it matches the server's certificate exactly. I thought a CA certificate was a special kind of x509 certificate. Perhaps I'm wrong and any x509 certificate can be used as a CA certificate [as far as OpenSSL is concerned]. In any case, I thought it best to drop "ca" from the name because this reflects reality.
2016-06-08 06:29:54 +03:00
[255]
sslutil: display a better error message when CA file loading fails Before, sslcontext.load_verify_locations() would raise a ssl.SSLError which would be caught further up the stack and converted to a urlerror. By that time, we lost track of what actually errored. Trapping the error here gives users a slightly more actionable error message. The behavior between Python <2.7.9 and Python 2.7.9+ differs. This is because our fake SSLContext class installed on <2.7.9 doesn't actually do anything during load_verify_locations: it defers actions until wrap_socket() time. Unfortunately, a number of errors can occur at wrap_socket() time and we're unable to ascertain what the root cause is. But that shouldn't stop us from providing better error messages to people running a modern and secure Python version.
2016-06-30 05:37:38 +03:00
#endif
sslutil: per-host config option to define certificates Recent work has introduced the [hostsecurity] config section for defining per-host security settings. This patch builds on top of this foundation and implements the ability to define a per-host path to a file containing certificates used for verifying the server certificate. It is logically a per-host web.cacerts setting. This patch also introduces a warning when both per-host certificates and fingerprints are defined. These are mutually exclusive for host verification and I think the user should be alerted when security settings are ambiguous because, well, security is important. Tests validating the new behavior have been added. I decided against putting "ca" in the option name because a non-CA certificate can be specified and used to validate the server certificate (commonly this will be the exact public certificate used by the server). It's worth noting that the underlying Python API used is load_verify_locations(cafile=X) and it calls into OpenSSL's SSL_CTX_load_verify_locations(). Even OpenSSL's documentation seems to omit that the file can contain a non-CA certificate if it matches the server's certificate exactly. I thought a CA certificate was a special kind of x509 certificate. Perhaps I'm wrong and any x509 certificate can be used as a CA certificate [as far as OpenSSL is concerned]. In any case, I thought it best to drop "ca" from the name because this reflects reality.
2016-06-08 06:29:54 +03:00
A per-host certificate mismatching the server will fail verification
sslutil: emit warning when no CA certificates loaded If no CA certificates are loaded, that is almost certainly a/the reason certificate verification fails when connecting to a server. The modern ssl module in Python 2.7.9+ provides an API to access the list of loaded CA certificates. This patch emits a warning on modern Python when certificate verification fails and there are no loaded CA certificates. There is no way to detect the number of loaded CA certificates unless the modern ssl module is present. Hence the differences in test output depending on whether modern ssl is available. It's worth noting that a test which specifies a CA file still renders this warning. That is because the certificate it is loading is a x509 client certificate and not a CA certificate. This test could be updated if anyone is so inclined.
2016-06-30 05:43:27 +03:00
(modern ssl is able to discern whether the loaded cert is a CA cert)
#if sslcontext
$ hg --config hostsecurity.localhost:verifycertsfile="$CERTSDIR/client-cert.pem" clone https://localhost:$HGPORT/
(an attempt was made to load CA certificates but none were loaded; see https://mercurial-scm.org/wiki/SecureConnections for how to configure Mercurial to avoid this error)
abort: error: *certificate verify failed* (glob)
[255]
#else
sslutil: per-host config option to define certificates Recent work has introduced the [hostsecurity] config section for defining per-host security settings. This patch builds on top of this foundation and implements the ability to define a per-host path to a file containing certificates used for verifying the server certificate. It is logically a per-host web.cacerts setting. This patch also introduces a warning when both per-host certificates and fingerprints are defined. These are mutually exclusive for host verification and I think the user should be alerted when security settings are ambiguous because, well, security is important. Tests validating the new behavior have been added. I decided against putting "ca" in the option name because a non-CA certificate can be specified and used to validate the server certificate (commonly this will be the exact public certificate used by the server). It's worth noting that the underlying Python API used is load_verify_locations(cafile=X) and it calls into OpenSSL's SSL_CTX_load_verify_locations(). Even OpenSSL's documentation seems to omit that the file can contain a non-CA certificate if it matches the server's certificate exactly. I thought a CA certificate was a special kind of x509 certificate. Perhaps I'm wrong and any x509 certificate can be used as a CA certificate [as far as OpenSSL is concerned]. In any case, I thought it best to drop "ca" from the name because this reflects reality.
2016-06-08 06:29:54 +03:00
$ hg --config hostsecurity.localhost:verifycertsfile="$CERTSDIR/client-cert.pem" clone https://localhost:$HGPORT/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
sslutil: per-host config option to define certificates Recent work has introduced the [hostsecurity] config section for defining per-host security settings. This patch builds on top of this foundation and implements the ability to define a per-host path to a file containing certificates used for verifying the server certificate. It is logically a per-host web.cacerts setting. This patch also introduces a warning when both per-host certificates and fingerprints are defined. These are mutually exclusive for host verification and I think the user should be alerted when security settings are ambiguous because, well, security is important. Tests validating the new behavior have been added. I decided against putting "ca" in the option name because a non-CA certificate can be specified and used to validate the server certificate (commonly this will be the exact public certificate used by the server). It's worth noting that the underlying Python API used is load_verify_locations(cafile=X) and it calls into OpenSSL's SSL_CTX_load_verify_locations(). Even OpenSSL's documentation seems to omit that the file can contain a non-CA certificate if it matches the server's certificate exactly. I thought a CA certificate was a special kind of x509 certificate. Perhaps I'm wrong and any x509 certificate can be used as a CA certificate [as far as OpenSSL is concerned]. In any case, I thought it best to drop "ca" from the name because this reflects reality.
2016-06-08 06:29:54 +03:00
abort: error: *certificate verify failed* (glob)
[255]
sslutil: emit warning when no CA certificates loaded If no CA certificates are loaded, that is almost certainly a/the reason certificate verification fails when connecting to a server. The modern ssl module in Python 2.7.9+ provides an API to access the list of loaded CA certificates. This patch emits a warning on modern Python when certificate verification fails and there are no loaded CA certificates. There is no way to detect the number of loaded CA certificates unless the modern ssl module is present. Hence the differences in test output depending on whether modern ssl is available. It's worth noting that a test which specifies a CA file still renders this warning. That is because the certificate it is loading is a x509 client certificate and not a CA certificate. This test could be updated if anyone is so inclined.
2016-06-30 05:43:27 +03:00
#endif
sslutil: per-host config option to define certificates Recent work has introduced the [hostsecurity] config section for defining per-host security settings. This patch builds on top of this foundation and implements the ability to define a per-host path to a file containing certificates used for verifying the server certificate. It is logically a per-host web.cacerts setting. This patch also introduces a warning when both per-host certificates and fingerprints are defined. These are mutually exclusive for host verification and I think the user should be alerted when security settings are ambiguous because, well, security is important. Tests validating the new behavior have been added. I decided against putting "ca" in the option name because a non-CA certificate can be specified and used to validate the server certificate (commonly this will be the exact public certificate used by the server). It's worth noting that the underlying Python API used is load_verify_locations(cafile=X) and it calls into OpenSSL's SSL_CTX_load_verify_locations(). Even OpenSSL's documentation seems to omit that the file can contain a non-CA certificate if it matches the server's certificate exactly. I thought a CA certificate was a special kind of x509 certificate. Perhaps I'm wrong and any x509 certificate can be used as a CA certificate [as far as OpenSSL is concerned]. In any case, I thought it best to drop "ca" from the name because this reflects reality.
2016-06-08 06:29:54 +03:00
A per-host certificate matching the server's cert will be accepted
$ hg --config hostsecurity.localhost:verifycertsfile="$CERTSDIR/pub.pem" clone -U https://localhost:$HGPORT/ perhostgood1
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
sslutil: per-host config option to define certificates Recent work has introduced the [hostsecurity] config section for defining per-host security settings. This patch builds on top of this foundation and implements the ability to define a per-host path to a file containing certificates used for verifying the server certificate. It is logically a per-host web.cacerts setting. This patch also introduces a warning when both per-host certificates and fingerprints are defined. These are mutually exclusive for host verification and I think the user should be alerted when security settings are ambiguous because, well, security is important. Tests validating the new behavior have been added. I decided against putting "ca" in the option name because a non-CA certificate can be specified and used to validate the server certificate (commonly this will be the exact public certificate used by the server). It's worth noting that the underlying Python API used is load_verify_locations(cafile=X) and it calls into OpenSSL's SSL_CTX_load_verify_locations(). Even OpenSSL's documentation seems to omit that the file can contain a non-CA certificate if it matches the server's certificate exactly. I thought a CA certificate was a special kind of x509 certificate. Perhaps I'm wrong and any x509 certificate can be used as a CA certificate [as far as OpenSSL is concerned]. In any case, I thought it best to drop "ca" from the name because this reflects reality.
2016-06-08 06:29:54 +03:00
requesting all changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 4 changes to 4 files
A per-host certificate with multiple certs and one matching will be accepted
$ cat "$CERTSDIR/client-cert.pem" "$CERTSDIR/pub.pem" > perhost.pem
$ hg --config hostsecurity.localhost:verifycertsfile=perhost.pem clone -U https://localhost:$HGPORT/ perhostgood2
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
sslutil: per-host config option to define certificates Recent work has introduced the [hostsecurity] config section for defining per-host security settings. This patch builds on top of this foundation and implements the ability to define a per-host path to a file containing certificates used for verifying the server certificate. It is logically a per-host web.cacerts setting. This patch also introduces a warning when both per-host certificates and fingerprints are defined. These are mutually exclusive for host verification and I think the user should be alerted when security settings are ambiguous because, well, security is important. Tests validating the new behavior have been added. I decided against putting "ca" in the option name because a non-CA certificate can be specified and used to validate the server certificate (commonly this will be the exact public certificate used by the server). It's worth noting that the underlying Python API used is load_verify_locations(cafile=X) and it calls into OpenSSL's SSL_CTX_load_verify_locations(). Even OpenSSL's documentation seems to omit that the file can contain a non-CA certificate if it matches the server's certificate exactly. I thought a CA certificate was a special kind of x509 certificate. Perhaps I'm wrong and any x509 certificate can be used as a CA certificate [as far as OpenSSL is concerned]. In any case, I thought it best to drop "ca" from the name because this reflects reality.
2016-06-08 06:29:54 +03:00
requesting all changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 4 changes to 4 files
Defining both per-host certificate and a fingerprint will print a warning
tests: regenerate x509 test certificates The old x509 test certificates were using cryptographic settings that are ancient by today's standards, namely 512 bit RSA keys. To put things in perspective, browsers have been dropping support for 1024 bit RSA keys. I think it is important that tests match the realities of the times. And 2048 bit RSA keys with SHA-2 hashing are what the world is moving to. This patch replaces all the x509 certificates with new versions using modern best practices. In addition, the docs for generating the keys have been updated, as the existing docs left out a few steps, namely how to generate certs that were not active yet or expired.
2016-07-13 08:26:04 +03:00
$ hg --config hostsecurity.localhost:verifycertsfile="$CERTSDIR/pub.pem" --config hostsecurity.localhost:fingerprints=sha1:ecd87cd6b386d04fc1b8b41c9d8f5e168eef1c03 clone -U https://localhost:$HGPORT/ caandfingerwarning
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
sslutil: per-host config option to define certificates Recent work has introduced the [hostsecurity] config section for defining per-host security settings. This patch builds on top of this foundation and implements the ability to define a per-host path to a file containing certificates used for verifying the server certificate. It is logically a per-host web.cacerts setting. This patch also introduces a warning when both per-host certificates and fingerprints are defined. These are mutually exclusive for host verification and I think the user should be alerted when security settings are ambiguous because, well, security is important. Tests validating the new behavior have been added. I decided against putting "ca" in the option name because a non-CA certificate can be specified and used to validate the server certificate (commonly this will be the exact public certificate used by the server). It's worth noting that the underlying Python API used is load_verify_locations(cafile=X) and it calls into OpenSSL's SSL_CTX_load_verify_locations(). Even OpenSSL's documentation seems to omit that the file can contain a non-CA certificate if it matches the server's certificate exactly. I thought a CA certificate was a special kind of x509 certificate. Perhaps I'm wrong and any x509 certificate can be used as a CA certificate [as far as OpenSSL is concerned]. In any case, I thought it best to drop "ca" from the name because this reflects reality.
2016-06-08 06:29:54 +03:00
(hostsecurity.localhost:verifycertsfile ignored when host fingerprints defined; using host fingerprints for verification)
requesting all changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 4 changes to 4 files
sslutil: add devel.disableloaddefaultcerts to disable CA loading There are various tests for behavior when CA certs aren't loaded. Previously, we would pass --insecure to disable loading of CA certs. This has worked up to this point because the error message for --insecure and no CAs loaded is the same. Upcoming commits will change the error message for --insecure and will change behavior when CAs aren't loaded. This commit introduces the ability to disable loading of CA certs by setting devel.disableloaddefaultcerts. This allows a testing backdoor to disable loading of CA certs even if system/default CA certs are available. The flag is purposefully not exposed to end-users because there should not be a need for this in the wild: certificate pinning and --insecure provide workarounds to disable cert loading/validation. Tests have been updated to use the new method. The variable used to disable CA certs has been renamed because the method is not OS X specific.
2016-06-02 05:57:20 +03:00
$ DISABLECACERTS="--config devel.disableloaddefaultcerts=true"
sslutil: abort when unable to verify peer connection (BC) Previously, when we connected to a server and were unable to verify its certificate against a trusted certificate authority we would issue a warning and continue to connect. This is obviously not great behavior because the x509 certificate model is based upon trust of specific CAs. Failure to enforce that trust erodes security. This behavior was defined several years ago when Python did not support loading the system trusted CA store (Python 2.7.9's backports of Python 3's improvements to the "ssl" module enabled this). This commit changes behavior when connecting to abort if the peer certificate can't be validated. With an empty/default Mercurial configuration, the peer certificate can be validated if Python is able to load the system trusted CA store. Environments able to load the system trusted CA store include: * Python 2.7.9+ on most platforms and installations * Python 2.7 distributions with a modern ssl module (e.g. RHEL7's patched 2.7.5 package) * Python shipped on OS X Environments unable to load the system trusted CA store include: * Python 2.6 * Python 2.7 on many existing Linux installs (because they don't ship 2.7.9+ or haven't backported modern ssl module) * Python 2.7.9+ on some installs where Python is unable to locate the system CA store (this is hopefully rare) Users of these Pythongs will need to configure Mercurial to load the system CA store using web.cacerts. This should ideally be performed by packagers (by setting web.cacerts in the global/system hgrc file). Where Mercurial packagers aren't setting this, the linked URL in the new abort message can contain instructions for users. In the future, we may want to add more code for finding the system CA store. For example, many Linux distributions have the CA store at well-known locations (such as /etc/ssl/certs/ca-certificates.crt in the case of Ubuntu). This will enable CA loading to "just work" on more Python configurations and will be best for our users since they won't have to change anything after upgrading to a Mercurial with this patch. We may also want to consider distributing a trusted CA store with Mercurial. Although we should think long and hard about that because most systems have a global CA store and Mercurial should almost certainly use the same store used by everything else on the system.
2016-06-25 17:26:43 +03:00
Inability to verify peer certificate will result in abort
ssl: on OS X, use a dummy cert to trick Python/OpenSSL to use system CA certs This will give PKI-secure behaviour out of the box, without any configuration. Setting web.cacerts to any value or empty will disable this trick. This dummy cert trick only works on OS X 10.6+, but 10.5 had Python 2.5 which didn't have certificate validation at all.
2014-09-26 04:19:48 +04:00
sslutil: add devel.disableloaddefaultcerts to disable CA loading There are various tests for behavior when CA certs aren't loaded. Previously, we would pass --insecure to disable loading of CA certs. This has worked up to this point because the error message for --insecure and no CAs loaded is the same. Upcoming commits will change the error message for --insecure and will change behavior when CAs aren't loaded. This commit introduces the ability to disable loading of CA certs by setting devel.disableloaddefaultcerts. This allows a testing backdoor to disable loading of CA certs even if system/default CA certs are available. The flag is purposefully not exposed to end-users because there should not be a need for this in the wild: certificate pinning and --insecure provide workarounds to disable cert loading/validation. Tests have been updated to use the new method. The variable used to disable CA certs has been renamed because the method is not OS X specific.
2016-06-02 05:57:20 +03:00
$ hg clone https://localhost:$HGPORT/ copy-pull $DISABLECACERTS
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
sslutil: abort when unable to verify peer connection (BC) Previously, when we connected to a server and were unable to verify its certificate against a trusted certificate authority we would issue a warning and continue to connect. This is obviously not great behavior because the x509 certificate model is based upon trust of specific CAs. Failure to enforce that trust erodes security. This behavior was defined several years ago when Python did not support loading the system trusted CA store (Python 2.7.9's backports of Python 3's improvements to the "ssl" module enabled this). This commit changes behavior when connecting to abort if the peer certificate can't be validated. With an empty/default Mercurial configuration, the peer certificate can be validated if Python is able to load the system trusted CA store. Environments able to load the system trusted CA store include: * Python 2.7.9+ on most platforms and installations * Python 2.7 distributions with a modern ssl module (e.g. RHEL7's patched 2.7.5 package) * Python shipped on OS X Environments unable to load the system trusted CA store include: * Python 2.6 * Python 2.7 on many existing Linux installs (because they don't ship 2.7.9+ or haven't backported modern ssl module) * Python 2.7.9+ on some installs where Python is unable to locate the system CA store (this is hopefully rare) Users of these Pythongs will need to configure Mercurial to load the system CA store using web.cacerts. This should ideally be performed by packagers (by setting web.cacerts in the global/system hgrc file). Where Mercurial packagers aren't setting this, the linked URL in the new abort message can contain instructions for users. In the future, we may want to add more code for finding the system CA store. For example, many Linux distributions have the CA store at well-known locations (such as /etc/ssl/certs/ca-certificates.crt in the case of Ubuntu). This will enable CA loading to "just work" on more Python configurations and will be best for our users since they won't have to change anything after upgrading to a Mercurial with this patch. We may also want to consider distributing a trusted CA store with Mercurial. Although we should think long and hard about that because most systems have a global CA store and Mercurial should almost certainly use the same store used by everything else on the system.
2016-06-25 17:26:43 +03:00
abort: unable to verify security of localhost (no loaded CA certificates); refusing to connect
tests: regenerate x509 test certificates The old x509 test certificates were using cryptographic settings that are ancient by today's standards, namely 512 bit RSA keys. To put things in perspective, browsers have been dropping support for 1024 bit RSA keys. I think it is important that tests match the realities of the times. And 2048 bit RSA keys with SHA-2 hashing are what the world is moving to. This patch replaces all the x509 certificates with new versions using modern best practices. In addition, the docs for generating the keys have been updated, as the existing docs left out a few steps, namely how to generate certs that were not active yet or expired.
2016-07-13 08:26:04 +03:00
(see https://mercurial-scm.org/wiki/SecureConnections for how to configure Mercurial to avoid this error or set hostsecurity.localhost:fingerprints=sha256:20:de:b3:ad:b4:cd:a5:42:f0:74:41:1c:a2:70:1e:da:6e:c0:5c:16:9e:e7:22:0f:f1:b7:e5:6e:e4:92:af:7e to trust this server)
sslutil: abort when unable to verify peer connection (BC) Previously, when we connected to a server and were unable to verify its certificate against a trusted certificate authority we would issue a warning and continue to connect. This is obviously not great behavior because the x509 certificate model is based upon trust of specific CAs. Failure to enforce that trust erodes security. This behavior was defined several years ago when Python did not support loading the system trusted CA store (Python 2.7.9's backports of Python 3's improvements to the "ssl" module enabled this). This commit changes behavior when connecting to abort if the peer certificate can't be validated. With an empty/default Mercurial configuration, the peer certificate can be validated if Python is able to load the system trusted CA store. Environments able to load the system trusted CA store include: * Python 2.7.9+ on most platforms and installations * Python 2.7 distributions with a modern ssl module (e.g. RHEL7's patched 2.7.5 package) * Python shipped on OS X Environments unable to load the system trusted CA store include: * Python 2.6 * Python 2.7 on many existing Linux installs (because they don't ship 2.7.9+ or haven't backported modern ssl module) * Python 2.7.9+ on some installs where Python is unable to locate the system CA store (this is hopefully rare) Users of these Pythongs will need to configure Mercurial to load the system CA store using web.cacerts. This should ideally be performed by packagers (by setting web.cacerts in the global/system hgrc file). Where Mercurial packagers aren't setting this, the linked URL in the new abort message can contain instructions for users. In the future, we may want to add more code for finding the system CA store. For example, many Linux distributions have the CA store at well-known locations (such as /etc/ssl/certs/ca-certificates.crt in the case of Ubuntu). This will enable CA loading to "just work" on more Python configurations and will be best for our users since they won't have to change anything after upgrading to a Mercurial with this patch. We may also want to consider distributing a trusted CA store with Mercurial. Although we should think long and hard about that because most systems have a global CA store and Mercurial should almost certainly use the same store used by everything else on the system.
2016-06-25 17:26:43 +03:00
[255]
$ hg clone --insecure https://localhost:$HGPORT/ copy-pull
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
sslutil: abort when unable to verify peer connection (BC) Previously, when we connected to a server and were unable to verify its certificate against a trusted certificate authority we would issue a warning and continue to connect. This is obviously not great behavior because the x509 certificate model is based upon trust of specific CAs. Failure to enforce that trust erodes security. This behavior was defined several years ago when Python did not support loading the system trusted CA store (Python 2.7.9's backports of Python 3's improvements to the "ssl" module enabled this). This commit changes behavior when connecting to abort if the peer certificate can't be validated. With an empty/default Mercurial configuration, the peer certificate can be validated if Python is able to load the system trusted CA store. Environments able to load the system trusted CA store include: * Python 2.7.9+ on most platforms and installations * Python 2.7 distributions with a modern ssl module (e.g. RHEL7's patched 2.7.5 package) * Python shipped on OS X Environments unable to load the system trusted CA store include: * Python 2.6 * Python 2.7 on many existing Linux installs (because they don't ship 2.7.9+ or haven't backported modern ssl module) * Python 2.7.9+ on some installs where Python is unable to locate the system CA store (this is hopefully rare) Users of these Pythongs will need to configure Mercurial to load the system CA store using web.cacerts. This should ideally be performed by packagers (by setting web.cacerts in the global/system hgrc file). Where Mercurial packagers aren't setting this, the linked URL in the new abort message can contain instructions for users. In the future, we may want to add more code for finding the system CA store. For example, many Linux distributions have the CA store at well-known locations (such as /etc/ssl/certs/ca-certificates.crt in the case of Ubuntu). This will enable CA loading to "just work" on more Python configurations and will be best for our users since they won't have to change anything after upgrading to a Mercurial with this patch. We may also want to consider distributing a trusted CA store with Mercurial. Although we should think long and hard about that because most systems have a global CA store and Mercurial should almost certainly use the same store used by everything else on the system.
2016-06-25 17:26:43 +03:00
warning: connection security to localhost is disabled per current settings; communication is susceptible to eavesdropping and tampering
serve: fix https mode and add test The https mode failed in super because BaseRequestHandler is an old-style class. This introduces the first test of https client/server functionality - and "hghave ssl". The test is currently only run on Python 2.6.
2010-10-17 06:13:35 +04:00
requesting all changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 4 changes to 4 files
updating to branch default
4 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg verify -R copy-pull
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
4 files, 1 changesets, 4 total revisions
$ cd test
$ echo bar > bar
$ hg commit -A -d '1 0' -m 2
adding bar
$ cd ..
https: use web.cacerts configuration from local repo to validate remote repo
2010-12-27 19:49:58 +03:00
pull without cacert
serve: fix https mode and add test The https mode failed in super because BaseRequestHandler is an old-style class. This introduces the first test of https client/server functionality - and "hghave ssl". The test is currently only run on Python 2.6.
2010-10-17 06:13:35 +04:00
$ cd copy-pull
$ echo '[hooks]' >> .hg/hgrc
tests: simplify printenv calls Make printenv executable so that we don't need python, TESTDIR, or quoting.
2015-06-08 23:10:15 +03:00
$ echo "changegroup = printenv.py changegroup" >> .hg/hgrc
sslutil: add devel.disableloaddefaultcerts to disable CA loading There are various tests for behavior when CA certs aren't loaded. Previously, we would pass --insecure to disable loading of CA certs. This has worked up to this point because the error message for --insecure and no CAs loaded is the same. Upcoming commits will change the error message for --insecure and will change behavior when CAs aren't loaded. This commit introduces the ability to disable loading of CA certs by setting devel.disableloaddefaultcerts. This allows a testing backdoor to disable loading of CA certs even if system/default CA certs are available. The flag is purposefully not exposed to end-users because there should not be a need for this in the wild: certificate pinning and --insecure provide workarounds to disable cert loading/validation. Tests have been updated to use the new method. The variable used to disable CA certs has been renamed because the method is not OS X specific.
2016-06-02 05:57:20 +03:00
$ hg pull $DISABLECACERTS
serve: fix https mode and add test The https mode failed in super because BaseRequestHandler is an old-style class. This introduces the first test of https client/server functionality - and "hghave ssl". The test is currently only run on Python 2.6.
2010-10-17 06:13:35 +04:00
pulling from https://localhost:$HGPORT/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
sslutil: abort when unable to verify peer connection (BC) Previously, when we connected to a server and were unable to verify its certificate against a trusted certificate authority we would issue a warning and continue to connect. This is obviously not great behavior because the x509 certificate model is based upon trust of specific CAs. Failure to enforce that trust erodes security. This behavior was defined several years ago when Python did not support loading the system trusted CA store (Python 2.7.9's backports of Python 3's improvements to the "ssl" module enabled this). This commit changes behavior when connecting to abort if the peer certificate can't be validated. With an empty/default Mercurial configuration, the peer certificate can be validated if Python is able to load the system trusted CA store. Environments able to load the system trusted CA store include: * Python 2.7.9+ on most platforms and installations * Python 2.7 distributions with a modern ssl module (e.g. RHEL7's patched 2.7.5 package) * Python shipped on OS X Environments unable to load the system trusted CA store include: * Python 2.6 * Python 2.7 on many existing Linux installs (because they don't ship 2.7.9+ or haven't backported modern ssl module) * Python 2.7.9+ on some installs where Python is unable to locate the system CA store (this is hopefully rare) Users of these Pythongs will need to configure Mercurial to load the system CA store using web.cacerts. This should ideally be performed by packagers (by setting web.cacerts in the global/system hgrc file). Where Mercurial packagers aren't setting this, the linked URL in the new abort message can contain instructions for users. In the future, we may want to add more code for finding the system CA store. For example, many Linux distributions have the CA store at well-known locations (such as /etc/ssl/certs/ca-certificates.crt in the case of Ubuntu). This will enable CA loading to "just work" on more Python configurations and will be best for our users since they won't have to change anything after upgrading to a Mercurial with this patch. We may also want to consider distributing a trusted CA store with Mercurial. Although we should think long and hard about that because most systems have a global CA store and Mercurial should almost certainly use the same store used by everything else on the system.
2016-06-25 17:26:43 +03:00
abort: unable to verify security of localhost (no loaded CA certificates); refusing to connect
tests: regenerate x509 test certificates The old x509 test certificates were using cryptographic settings that are ancient by today's standards, namely 512 bit RSA keys. To put things in perspective, browsers have been dropping support for 1024 bit RSA keys. I think it is important that tests match the realities of the times. And 2048 bit RSA keys with SHA-2 hashing are what the world is moving to. This patch replaces all the x509 certificates with new versions using modern best practices. In addition, the docs for generating the keys have been updated, as the existing docs left out a few steps, namely how to generate certs that were not active yet or expired.
2016-07-13 08:26:04 +03:00
(see https://mercurial-scm.org/wiki/SecureConnections for how to configure Mercurial to avoid this error or set hostsecurity.localhost:fingerprints=sha256:20:de:b3:ad:b4:cd:a5:42:f0:74:41:1c:a2:70:1e:da:6e:c0:5c:16:9e:e7:22:0f:f1:b7:e5:6e:e4:92:af:7e to trust this server)
sslutil: abort when unable to verify peer connection (BC) Previously, when we connected to a server and were unable to verify its certificate against a trusted certificate authority we would issue a warning and continue to connect. This is obviously not great behavior because the x509 certificate model is based upon trust of specific CAs. Failure to enforce that trust erodes security. This behavior was defined several years ago when Python did not support loading the system trusted CA store (Python 2.7.9's backports of Python 3's improvements to the "ssl" module enabled this). This commit changes behavior when connecting to abort if the peer certificate can't be validated. With an empty/default Mercurial configuration, the peer certificate can be validated if Python is able to load the system trusted CA store. Environments able to load the system trusted CA store include: * Python 2.7.9+ on most platforms and installations * Python 2.7 distributions with a modern ssl module (e.g. RHEL7's patched 2.7.5 package) * Python shipped on OS X Environments unable to load the system trusted CA store include: * Python 2.6 * Python 2.7 on many existing Linux installs (because they don't ship 2.7.9+ or haven't backported modern ssl module) * Python 2.7.9+ on some installs where Python is unable to locate the system CA store (this is hopefully rare) Users of these Pythongs will need to configure Mercurial to load the system CA store using web.cacerts. This should ideally be performed by packagers (by setting web.cacerts in the global/system hgrc file). Where Mercurial packagers aren't setting this, the linked URL in the new abort message can contain instructions for users. In the future, we may want to add more code for finding the system CA store. For example, many Linux distributions have the CA store at well-known locations (such as /etc/ssl/certs/ca-certificates.crt in the case of Ubuntu). This will enable CA loading to "just work" on more Python configurations and will be best for our users since they won't have to change anything after upgrading to a Mercurial with this patch. We may also want to consider distributing a trusted CA store with Mercurial. Although we should think long and hard about that because most systems have a global CA store and Mercurial should almost certainly use the same store used by everything else on the system.
2016-06-25 17:26:43 +03:00
[255]
$ hg pull --insecure
pulling from https://localhost:$HGPORT/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
sslutil: abort when unable to verify peer connection (BC) Previously, when we connected to a server and were unable to verify its certificate against a trusted certificate authority we would issue a warning and continue to connect. This is obviously not great behavior because the x509 certificate model is based upon trust of specific CAs. Failure to enforce that trust erodes security. This behavior was defined several years ago when Python did not support loading the system trusted CA store (Python 2.7.9's backports of Python 3's improvements to the "ssl" module enabled this). This commit changes behavior when connecting to abort if the peer certificate can't be validated. With an empty/default Mercurial configuration, the peer certificate can be validated if Python is able to load the system trusted CA store. Environments able to load the system trusted CA store include: * Python 2.7.9+ on most platforms and installations * Python 2.7 distributions with a modern ssl module (e.g. RHEL7's patched 2.7.5 package) * Python shipped on OS X Environments unable to load the system trusted CA store include: * Python 2.6 * Python 2.7 on many existing Linux installs (because they don't ship 2.7.9+ or haven't backported modern ssl module) * Python 2.7.9+ on some installs where Python is unable to locate the system CA store (this is hopefully rare) Users of these Pythongs will need to configure Mercurial to load the system CA store using web.cacerts. This should ideally be performed by packagers (by setting web.cacerts in the global/system hgrc file). Where Mercurial packagers aren't setting this, the linked URL in the new abort message can contain instructions for users. In the future, we may want to add more code for finding the system CA store. For example, many Linux distributions have the CA store at well-known locations (such as /etc/ssl/certs/ca-certificates.crt in the case of Ubuntu). This will enable CA loading to "just work" on more Python configurations and will be best for our users since they won't have to change anything after upgrading to a Mercurial with this patch. We may also want to consider distributing a trusted CA store with Mercurial. Although we should think long and hard about that because most systems have a global CA store and Mercurial should almost certainly use the same store used by everything else on the system.
2016-06-25 17:26:43 +03:00
warning: connection security to localhost is disabled per current settings; communication is susceptible to eavesdropping and tampering
serve: fix https mode and add test The https mode failed in super because BaseRequestHandler is an old-style class. This introduces the first test of https client/server functionality - and "hghave ssl". The test is currently only run on Python 2.6.
2010-10-17 06:13:35 +04:00
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
hooks: add HG_NODE_LAST to txnclose and changegroup hook environments Sometimes a txnclose or changegroup hook wants to iterate through all the changesets in transaction: in that situation usually the revset `$HG_NODE:` is used to select the revisions. Unfortunately this revset sometimes may contain too many changesets because we don't have the write lock while the hook runs newer changes may be added to repository in the meantime. That's why there is a need for extra variable carrying the information about the last change in the transaction.
2016-01-06 04:37:59 +03:00
changegroup hook: HG_NODE=5fed3813f7f5e1824344fdc9cf8f63bb662c292d HG_NODE_LAST=5fed3813f7f5e1824344fdc9cf8f63bb662c292d HG_SOURCE=pull HG_TXNID=TXN:* HG_URL=https://localhost:$HGPORT/ (glob)
serve: fix https mode and add test The https mode failed in super because BaseRequestHandler is an old-style class. This introduces the first test of https client/server functionality - and "hghave ssl". The test is currently only run on Python 2.6.
2010-10-17 06:13:35 +04:00
(run 'hg update' to get a working copy)
$ cd ..
test-https: test web.cacerts functionality
2010-10-17 06:13:50 +04:00
https: use web.cacerts configuration from local repo to validate remote repo
2010-12-27 19:49:58 +03:00
cacert configured in local repo
test-https: test web.cacerts functionality
2010-10-17 06:13:50 +04:00
https: use web.cacerts configuration from local repo to validate remote repo
2010-12-27 19:49:58 +03:00
$ cp copy-pull/.hg/hgrc copy-pull/.hg/hgrc.bu
$ echo "[web]" >> copy-pull/.hg/hgrc
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
$ echo "cacerts=$CERTSDIR/pub.pem" >> copy-pull/.hg/hgrc
https: use web.cacerts configuration from local repo to validate remote repo
2010-12-27 19:49:58 +03:00
$ hg -R copy-pull pull --traceback
test-https: test web.cacerts functionality
2010-10-17 06:13:50 +04:00
pulling from https://localhost:$HGPORT/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
test-https: test web.cacerts functionality
2010-10-17 06:13:50 +04:00
searching for changes
no changes found
https: use web.cacerts configuration from local repo to validate remote repo
2010-12-27 19:49:58 +03:00
$ mv copy-pull/.hg/hgrc.bu copy-pull/.hg/hgrc
url: expand path for web.cacerts
2011-01-02 16:30:12 +03:00
cacert configured globally, also testing expansion of environment
variables in the filename
https: use web.cacerts configuration from local repo to validate remote repo
2010-12-27 19:49:58 +03:00
$ echo "[web]" >> $HGRCPATH
url: expand path for web.cacerts
2011-01-02 16:30:12 +03:00
$ echo 'cacerts=$P/pub.pem' >> $HGRCPATH
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
$ P="$CERTSDIR" hg -R copy-pull pull
https: use web.cacerts configuration from local repo to validate remote repo
2010-12-27 19:49:58 +03:00
pulling from https://localhost:$HGPORT/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
https: use web.cacerts configuration from local repo to validate remote repo
2010-12-27 19:49:58 +03:00
searching for changes
no changes found
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
$ P="$CERTSDIR" hg -R copy-pull pull --insecure
url: add --insecure option to bypass verification of ssl certificates If --insecure specified, it behaves in the same way as no web.cacerts configured. Also shows hint for --insecure option when _verifycert() failed. But currently the hint isn't displayed on SSLError, because it needs a certain level of changes.
2011-01-29 17:23:24 +03:00
pulling from https://localhost:$HGPORT/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
sslutil: move and change warning when cert verification is disabled A short time ago, validatesocket() didn't know the reasons why cert verification was disabled. Multiple code paths could lead to cert verification being disabled. e.g. --insecure and lack of loaded CAs. With the recent refactorings to sslutil.py, we now know the reasons behind security settings. This means we can recognize when the user requested security be disabled (as opposed to being unable to provide certificate verification due to lack of CAs). This patch moves the check for certificate verification being disabled and changes the wording to distinguish it from other states. The warning message is purposefully more dangerous sounding in order to help discourage people from disabling security outright. We may want to add a URL or hint to this message. I'm going to wait until additional changes to security defaults before committing to something.
2016-05-30 23:15:53 +03:00
warning: connection security to localhost is disabled per current settings; communication is susceptible to eavesdropping and tampering
url: add --insecure option to bypass verification of ssl certificates If --insecure specified, it behaves in the same way as no web.cacerts configured. Also shows hint for --insecure option when _verifycert() failed. But currently the hint isn't displayed on SSLError, because it needs a certain level of changes.
2011-01-29 17:23:24 +03:00
searching for changes
no changes found
https: use web.cacerts configuration from local repo to validate remote repo
2010-12-27 19:49:58 +03:00
tests: add test for empty CA certs file smf reported that an environment with no loaded CA certs resulted in a weird error. I'd like to detect this a bit better so we can display an actionable error message. The actual error being globbed over in this patch is "unknown error" with a ssl.c line number. That isn't useful at all.
2016-06-30 04:15:28 +03:00
empty cacert file
$ touch emptycafile
sslutil: display a better error message when CA file loading fails Before, sslcontext.load_verify_locations() would raise a ssl.SSLError which would be caught further up the stack and converted to a urlerror. By that time, we lost track of what actually errored. Trapping the error here gives users a slightly more actionable error message. The behavior between Python <2.7.9 and Python 2.7.9+ differs. This is because our fake SSLContext class installed on <2.7.9 doesn't actually do anything during load_verify_locations: it defers actions until wrap_socket() time. Unfortunately, a number of errors can occur at wrap_socket() time and we're unable to ascertain what the root cause is. But that shouldn't stop us from providing better error messages to people running a modern and secure Python version.
2016-06-30 05:37:38 +03:00
#if sslcontext
$ hg --config web.cacerts=emptycafile -R copy-pull pull
pulling from https://localhost:$HGPORT/
abort: error loading CA file emptycafile: * (glob)
(file is empty or malformed?)
[255]
#else
tests: add test for empty CA certs file smf reported that an environment with no loaded CA certs resulted in a weird error. I'd like to detect this a bit better so we can display an actionable error message. The actual error being globbed over in this patch is "unknown error" with a ssl.c line number. That isn't useful at all.
2016-06-30 04:15:28 +03:00
$ hg --config web.cacerts=emptycafile -R copy-pull pull
pulling from https://localhost:$HGPORT/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
tests: add test for empty CA certs file smf reported that an environment with no loaded CA certs resulted in a weird error. I'd like to detect this a bit better so we can display an actionable error message. The actual error being globbed over in this patch is "unknown error" with a ssl.c line number. That isn't useful at all.
2016-06-30 04:15:28 +03:00
abort: error: * (glob)
[255]
sslutil: display a better error message when CA file loading fails Before, sslcontext.load_verify_locations() would raise a ssl.SSLError which would be caught further up the stack and converted to a urlerror. By that time, we lost track of what actually errored. Trapping the error here gives users a slightly more actionable error message. The behavior between Python <2.7.9 and Python 2.7.9+ differs. This is because our fake SSLContext class installed on <2.7.9 doesn't actually do anything during load_verify_locations: it defers actions until wrap_socket() time. Unfortunately, a number of errors can occur at wrap_socket() time and we're unable to ascertain what the root cause is. But that shouldn't stop us from providing better error messages to people running a modern and secure Python version.
2016-06-30 05:37:38 +03:00
#endif
tests: add test for empty CA certs file smf reported that an environment with no loaded CA certs resulted in a weird error. I'd like to detect this a bit better so we can display an actionable error message. The actual error being globbed over in this patch is "unknown error" with a ssl.c line number. That isn't useful at all.
2016-06-30 04:15:28 +03:00
https: use web.cacerts configuration from local repo to validate remote repo
2010-12-27 19:49:58 +03:00
cacert mismatch
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
$ hg -R copy-pull pull --config web.cacerts="$CERTSDIR/pub.pem" \
> https://127.0.0.1:$HGPORT/
tests: add (glob) annotations to output lines with 127.0.0.1
2016-07-10 06:03:45 +03:00
pulling from https://127.0.0.1:$HGPORT/ (glob)
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to 127.0.0.1 using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
tests: add (glob) annotations to output lines with 127.0.0.1
2016-07-10 06:03:45 +03:00
abort: 127.0.0.1 certificate error: certificate is for localhost (glob)
tests: regenerate x509 test certificates The old x509 test certificates were using cryptographic settings that are ancient by today's standards, namely 512 bit RSA keys. To put things in perspective, browsers have been dropping support for 1024 bit RSA keys. I think it is important that tests match the realities of the times. And 2048 bit RSA keys with SHA-2 hashing are what the world is moving to. This patch replaces all the x509 certificates with new versions using modern best practices. In addition, the docs for generating the keys have been updated, as the existing docs left out a few steps, namely how to generate certs that were not active yet or expired.
2016-07-13 08:26:04 +03:00
(set hostsecurity.127.0.0.1:certfingerprints=sha256:20:de:b3:ad:b4:cd:a5:42:f0:74:41:1c:a2:70:1e:da:6e:c0:5c:16:9e:e7:22:0f:f1:b7:e5:6e:e4:92:af:7e config setting or use --insecure to connect insecurely) (glob)
test-https: test web.cacerts functionality
2010-10-17 06:13:50 +04:00
[255]
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
$ hg -R copy-pull pull --config web.cacerts="$CERTSDIR/pub.pem" \
> https://127.0.0.1:$HGPORT/ --insecure
tests: add (glob) annotations to output lines with 127.0.0.1
2016-07-10 06:03:45 +03:00
pulling from https://127.0.0.1:$HGPORT/ (glob)
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to 127.0.0.1 using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
tests: add (glob) annotations to output lines with 127.0.0.1
2016-07-10 06:03:45 +03:00
warning: connection security to 127.0.0.1 is disabled per current settings; communication is susceptible to eavesdropping and tampering (glob)
url: add --insecure option to bypass verification of ssl certificates If --insecure specified, it behaves in the same way as no web.cacerts configured. Also shows hint for --insecure option when _verifycert() failed. But currently the hint isn't displayed on SSLError, because it needs a certain level of changes.
2011-01-29 17:23:24 +03:00
searching for changes
no changes found
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
$ hg -R copy-pull pull --config web.cacerts="$CERTSDIR/pub-other.pem"
pull: print "pulling from foo" before accessing the other repo 1. This is consistent with pushing. 2. This allows to see the URL of the other repo in case accessing the repo fails, e.g. wrong ssh path or issues with the https certificate, without using --debug or showconfig paths. Additionally add test for this in the context of ssh with a wrong path.
2015-02-24 12:55:24 +03:00
pulling from https://localhost:$HGPORT/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
test-https: glob error messages more so we pass on Python 2.7.9 Python 2.7.9 cleans up how it stringifies SSL errors, so we have to look only for the important bit (certificate verify failed) rather than looking for specific ssl module goop (which is now unstable).
2015-01-13 23:15:37 +03:00
abort: error: *certificate verify failed* (glob)
test-https: test web.cacerts functionality
2010-10-17 06:13:50 +04:00
[255]
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
$ hg -R copy-pull pull --config web.cacerts="$CERTSDIR/pub-other.pem" \
> --insecure
url: add --insecure option to bypass verification of ssl certificates If --insecure specified, it behaves in the same way as no web.cacerts configured. Also shows hint for --insecure option when _verifycert() failed. But currently the hint isn't displayed on SSLError, because it needs a certain level of changes.
2011-01-29 17:23:24 +03:00
pulling from https://localhost:$HGPORT/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
sslutil: move and change warning when cert verification is disabled A short time ago, validatesocket() didn't know the reasons why cert verification was disabled. Multiple code paths could lead to cert verification being disabled. e.g. --insecure and lack of loaded CAs. With the recent refactorings to sslutil.py, we now know the reasons behind security settings. This means we can recognize when the user requested security be disabled (as opposed to being unable to provide certificate verification due to lack of CAs). This patch moves the check for certificate verification being disabled and changes the wording to distinguish it from other states. The warning message is purposefully more dangerous sounding in order to help discourage people from disabling security outright. We may want to add a URL or hint to this message. I'm going to wait until additional changes to security defaults before committing to something.
2016-05-30 23:15:53 +03:00
warning: connection security to localhost is disabled per current settings; communication is susceptible to eavesdropping and tampering
url: add --insecure option to bypass verification of ssl certificates If --insecure specified, it behaves in the same way as no web.cacerts configured. Also shows hint for --insecure option when _verifycert() failed. But currently the hint isn't displayed on SSLError, because it needs a certain level of changes.
2011-01-29 17:23:24 +03:00
searching for changes
no changes found
test-https: test web.cacerts functionality
2010-10-17 06:13:50 +04:00
Test server cert which isn't valid yet
tests: reorder hg serve commands chg currently does not support hg serve -d. It has a quick path testing if the command is hg serve -d and fallbacks to hg if so. But the test only works if "serve" is the first argument since the test wants to avoid false positives (for example, "-r serve" is different). This patch reorders "hg server" commands in tests, making them chg friendly.
2016-03-15 12:51:54 +03:00
$ hg serve -R test -p $HGPORT1 -d --pid-file=hg1.pid --certificate=server-not-yet.pem
test-https: test web.cacerts functionality
2010-10-17 06:13:50 +04:00
$ cat hg1.pid >> $DAEMON_PIDS
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
$ hg -R copy-pull pull --config web.cacerts="$CERTSDIR/pub-not-yet.pem" \
> https://localhost:$HGPORT1/
pull: print "pulling from foo" before accessing the other repo 1. This is consistent with pushing. 2. This allows to see the URL of the other repo in case accessing the repo fails, e.g. wrong ssh path or issues with the https certificate, without using --debug or showconfig paths. Additionally add test for this in the context of ssh with a wrong path.
2015-02-24 12:55:24 +03:00
pulling from https://localhost:$HGPORT1/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
test-https: glob error messages more so we pass on Python 2.7.9 Python 2.7.9 cleans up how it stringifies SSL errors, so we have to look only for the important bit (certificate verify failed) rather than looking for specific ssl module goop (which is now unstable).
2015-01-13 23:15:37 +03:00
abort: error: *certificate verify failed* (glob)
test-https: test web.cacerts functionality
2010-10-17 06:13:50 +04:00
[255]
Test server cert which no longer is valid
tests: reorder hg serve commands chg currently does not support hg serve -d. It has a quick path testing if the command is hg serve -d and fallbacks to hg if so. But the test only works if "serve" is the first argument since the test wants to avoid false positives (for example, "-r serve" is different). This patch reorders "hg server" commands in tests, making them chg friendly.
2016-03-15 12:51:54 +03:00
$ hg serve -R test -p $HGPORT2 -d --pid-file=hg2.pid --certificate=server-expired.pem
test-https: test web.cacerts functionality
2010-10-17 06:13:50 +04:00
$ cat hg2.pid >> $DAEMON_PIDS
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
$ hg -R copy-pull pull --config web.cacerts="$CERTSDIR/pub-expired.pem" \
> https://localhost:$HGPORT2/
pull: print "pulling from foo" before accessing the other repo 1. This is consistent with pushing. 2. This allows to see the URL of the other repo in case accessing the repo fails, e.g. wrong ssh path or issues with the https certificate, without using --debug or showconfig paths. Additionally add test for this in the context of ssh with a wrong path.
2015-02-24 12:55:24 +03:00
pulling from https://localhost:$HGPORT2/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
test-https: glob error messages more so we pass on Python 2.7.9 Python 2.7.9 cleans up how it stringifies SSL errors, so we have to look only for the important bit (certificate verify failed) rather than looking for specific ssl module goop (which is now unstable).
2015-01-13 23:15:37 +03:00
abort: error: *certificate verify failed* (glob)
test-https: test web.cacerts functionality
2010-10-17 06:13:50 +04:00
[255]
url: 'ssh known host'-like checking of fingerprints of HTTPS certificates Known fingerprints of HTTPS servers can now be configured in the hostfingerprints section. That makes it possible to verify the identify of web servers without configuring and trusting the CA chain. Limitations: * Portnumbers are ignored, just like with ordinary certificates. * Host name matching is case sensitive.
2011-01-28 04:57:59 +03:00
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
Disabling the TLS 1.0 warning works
$ hg -R copy-pull id https://localhost:$HGPORT/ \
> --config hostsecurity.localhost:fingerprints=sha1:ecd87cd6b386d04fc1b8b41c9d8f5e168eef1c03 \
> --config hostsecurity.disabletls10warning=true
5fed3813f7f5
url: 'ssh known host'-like checking of fingerprints of HTTPS certificates Known fingerprints of HTTPS servers can now be configured in the hostfingerprints section. That makes it possible to verify the identify of web servers without configuring and trusting the CA chain. Limitations: * Portnumbers are ignored, just like with ordinary certificates. * Host name matching is case sensitive.
2011-01-28 04:57:59 +03:00
Fingerprints
sslutil: allow fingerprints to be specified in [hostsecurity] We introduce the [hostsecurity] config section. It holds per-host security settings. Currently, the section only contains a "fingerprints" option, which behaves like [hostfingerprints] but supports specifying the hashing algorithm. There is still some follow-up work, such as changing some error messages.
2016-05-28 22:37:36 +03:00
- works without cacerts (hostkeyfingerprints)
tests: regenerate x509 test certificates The old x509 test certificates were using cryptographic settings that are ancient by today's standards, namely 512 bit RSA keys. To put things in perspective, browsers have been dropping support for 1024 bit RSA keys. I think it is important that tests match the realities of the times. And 2048 bit RSA keys with SHA-2 hashing are what the world is moving to. This patch replaces all the x509 certificates with new versions using modern best practices. In addition, the docs for generating the keys have been updated, as the existing docs left out a few steps, namely how to generate certs that were not active yet or expired.
2016-07-13 08:26:04 +03:00
$ hg -R copy-pull id https://localhost:$HGPORT/ --insecure --config hostfingerprints.localhost=ec:d8:7c:d6:b3:86:d0:4f:c1:b8:b4:1c:9d:8f:5e:16:8e:ef:1c:03
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
url: 'ssh known host'-like checking of fingerprints of HTTPS certificates Known fingerprints of HTTPS servers can now be configured in the hostfingerprints section. That makes it possible to verify the identify of web servers without configuring and trusting the CA chain. Limitations: * Portnumbers are ignored, just like with ordinary certificates. * Host name matching is case sensitive.
2011-01-28 04:57:59 +03:00
5fed3813f7f5
sslutil: allow fingerprints to be specified in [hostsecurity] We introduce the [hostsecurity] config section. It holds per-host security settings. Currently, the section only contains a "fingerprints" option, which behaves like [hostfingerprints] but supports specifying the hashing algorithm. There is still some follow-up work, such as changing some error messages.
2016-05-28 22:37:36 +03:00
- works without cacerts (hostsecurity)
tests: regenerate x509 test certificates The old x509 test certificates were using cryptographic settings that are ancient by today's standards, namely 512 bit RSA keys. To put things in perspective, browsers have been dropping support for 1024 bit RSA keys. I think it is important that tests match the realities of the times. And 2048 bit RSA keys with SHA-2 hashing are what the world is moving to. This patch replaces all the x509 certificates with new versions using modern best practices. In addition, the docs for generating the keys have been updated, as the existing docs left out a few steps, namely how to generate certs that were not active yet or expired.
2016-07-13 08:26:04 +03:00
$ hg -R copy-pull id https://localhost:$HGPORT/ --config hostsecurity.localhost:fingerprints=sha1:ecd87cd6b386d04fc1b8b41c9d8f5e168eef1c03
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
sslutil: allow fingerprints to be specified in [hostsecurity] We introduce the [hostsecurity] config section. It holds per-host security settings. Currently, the section only contains a "fingerprints" option, which behaves like [hostfingerprints] but supports specifying the hashing algorithm. There is still some follow-up work, such as changing some error messages.
2016-05-28 22:37:36 +03:00
5fed3813f7f5
tests: regenerate x509 test certificates The old x509 test certificates were using cryptographic settings that are ancient by today's standards, namely 512 bit RSA keys. To put things in perspective, browsers have been dropping support for 1024 bit RSA keys. I think it is important that tests match the realities of the times. And 2048 bit RSA keys with SHA-2 hashing are what the world is moving to. This patch replaces all the x509 certificates with new versions using modern best practices. In addition, the docs for generating the keys have been updated, as the existing docs left out a few steps, namely how to generate certs that were not active yet or expired.
2016-07-13 08:26:04 +03:00
$ hg -R copy-pull id https://localhost:$HGPORT/ --config hostsecurity.localhost:fingerprints=sha256:20:de:b3:ad:b4:cd:a5:42:f0:74:41:1c:a2:70:1e:da:6e:c0:5c:16:9e:e7:22:0f:f1:b7:e5:6e:e4:92:af:7e
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
sslutil: allow fingerprints to be specified in [hostsecurity] We introduce the [hostsecurity] config section. It holds per-host security settings. Currently, the section only contains a "fingerprints" option, which behaves like [hostfingerprints] but supports specifying the hashing algorithm. There is still some follow-up work, such as changing some error messages.
2016-05-28 22:37:36 +03:00
5fed3813f7f5
sslutil: allow multiple fingerprints per host Certificate pinning via [hostfingerprints] is a useful security feature. Currently, we only support one fingerprint per hostname. This is simple but it fails in the real world: * Switching certificates breaks clients until they change the pinned certificate fingerprint. This incurs client downtime and can require massive amounts of coordination to perform certificate changes. * Some servers operate with multiple certificates on the same hostname. This patch adds support for defining multiple certificate fingerprints per host. This overcomes the deficiencies listed above. I anticipate the primary use case of this feature will be to define both the old and new certificate so a certificate transition can occur with minimal interruption, so this scenario has been called out in the help documentation.
2016-03-14 00:03:58 +03:00
- multiple fingerprints specified and first matches
tests: regenerate x509 test certificates The old x509 test certificates were using cryptographic settings that are ancient by today's standards, namely 512 bit RSA keys. To put things in perspective, browsers have been dropping support for 1024 bit RSA keys. I think it is important that tests match the realities of the times. And 2048 bit RSA keys with SHA-2 hashing are what the world is moving to. This patch replaces all the x509 certificates with new versions using modern best practices. In addition, the docs for generating the keys have been updated, as the existing docs left out a few steps, namely how to generate certs that were not active yet or expired.
2016-07-13 08:26:04 +03:00
$ hg --config 'hostfingerprints.localhost=ecd87cd6b386d04fc1b8b41c9d8f5e168eef1c03, deadbeefdeadbeefdeadbeefdeadbeefdeadbeef' -R copy-pull id https://localhost:$HGPORT/ --insecure
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
sslutil: allow multiple fingerprints per host Certificate pinning via [hostfingerprints] is a useful security feature. Currently, we only support one fingerprint per hostname. This is simple but it fails in the real world: * Switching certificates breaks clients until they change the pinned certificate fingerprint. This incurs client downtime and can require massive amounts of coordination to perform certificate changes. * Some servers operate with multiple certificates on the same hostname. This patch adds support for defining multiple certificate fingerprints per host. This overcomes the deficiencies listed above. I anticipate the primary use case of this feature will be to define both the old and new certificate so a certificate transition can occur with minimal interruption, so this scenario has been called out in the help documentation.
2016-03-14 00:03:58 +03:00
5fed3813f7f5
tests: regenerate x509 test certificates The old x509 test certificates were using cryptographic settings that are ancient by today's standards, namely 512 bit RSA keys. To put things in perspective, browsers have been dropping support for 1024 bit RSA keys. I think it is important that tests match the realities of the times. And 2048 bit RSA keys with SHA-2 hashing are what the world is moving to. This patch replaces all the x509 certificates with new versions using modern best practices. In addition, the docs for generating the keys have been updated, as the existing docs left out a few steps, namely how to generate certs that were not active yet or expired.
2016-07-13 08:26:04 +03:00
$ hg --config 'hostsecurity.localhost:fingerprints=sha1:ecd87cd6b386d04fc1b8b41c9d8f5e168eef1c03, sha1:deadbeefdeadbeefdeadbeefdeadbeefdeadbeef' -R copy-pull id https://localhost:$HGPORT/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
sslutil: allow fingerprints to be specified in [hostsecurity] We introduce the [hostsecurity] config section. It holds per-host security settings. Currently, the section only contains a "fingerprints" option, which behaves like [hostfingerprints] but supports specifying the hashing algorithm. There is still some follow-up work, such as changing some error messages.
2016-05-28 22:37:36 +03:00
5fed3813f7f5
sslutil: allow multiple fingerprints per host Certificate pinning via [hostfingerprints] is a useful security feature. Currently, we only support one fingerprint per hostname. This is simple but it fails in the real world: * Switching certificates breaks clients until they change the pinned certificate fingerprint. This incurs client downtime and can require massive amounts of coordination to perform certificate changes. * Some servers operate with multiple certificates on the same hostname. This patch adds support for defining multiple certificate fingerprints per host. This overcomes the deficiencies listed above. I anticipate the primary use case of this feature will be to define both the old and new certificate so a certificate transition can occur with minimal interruption, so this scenario has been called out in the help documentation.
2016-03-14 00:03:58 +03:00
- multiple fingerprints specified and last matches
tests: regenerate x509 test certificates The old x509 test certificates were using cryptographic settings that are ancient by today's standards, namely 512 bit RSA keys. To put things in perspective, browsers have been dropping support for 1024 bit RSA keys. I think it is important that tests match the realities of the times. And 2048 bit RSA keys with SHA-2 hashing are what the world is moving to. This patch replaces all the x509 certificates with new versions using modern best practices. In addition, the docs for generating the keys have been updated, as the existing docs left out a few steps, namely how to generate certs that were not active yet or expired.
2016-07-13 08:26:04 +03:00
$ hg --config 'hostfingerprints.localhost=deadbeefdeadbeefdeadbeefdeadbeefdeadbeef, ecd87cd6b386d04fc1b8b41c9d8f5e168eef1c03' -R copy-pull id https://localhost:$HGPORT/ --insecure
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
sslutil: allow multiple fingerprints per host Certificate pinning via [hostfingerprints] is a useful security feature. Currently, we only support one fingerprint per hostname. This is simple but it fails in the real world: * Switching certificates breaks clients until they change the pinned certificate fingerprint. This incurs client downtime and can require massive amounts of coordination to perform certificate changes. * Some servers operate with multiple certificates on the same hostname. This patch adds support for defining multiple certificate fingerprints per host. This overcomes the deficiencies listed above. I anticipate the primary use case of this feature will be to define both the old and new certificate so a certificate transition can occur with minimal interruption, so this scenario has been called out in the help documentation.
2016-03-14 00:03:58 +03:00
5fed3813f7f5
tests: regenerate x509 test certificates The old x509 test certificates were using cryptographic settings that are ancient by today's standards, namely 512 bit RSA keys. To put things in perspective, browsers have been dropping support for 1024 bit RSA keys. I think it is important that tests match the realities of the times. And 2048 bit RSA keys with SHA-2 hashing are what the world is moving to. This patch replaces all the x509 certificates with new versions using modern best practices. In addition, the docs for generating the keys have been updated, as the existing docs left out a few steps, namely how to generate certs that were not active yet or expired.
2016-07-13 08:26:04 +03:00
$ hg --config 'hostsecurity.localhost:fingerprints=sha1:deadbeefdeadbeefdeadbeefdeadbeefdeadbeef, sha1:ecd87cd6b386d04fc1b8b41c9d8f5e168eef1c03' -R copy-pull id https://localhost:$HGPORT/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
sslutil: allow fingerprints to be specified in [hostsecurity] We introduce the [hostsecurity] config section. It holds per-host security settings. Currently, the section only contains a "fingerprints" option, which behaves like [hostfingerprints] but supports specifying the hashing algorithm. There is still some follow-up work, such as changing some error messages.
2016-05-28 22:37:36 +03:00
5fed3813f7f5
sslutil: allow multiple fingerprints per host Certificate pinning via [hostfingerprints] is a useful security feature. Currently, we only support one fingerprint per hostname. This is simple but it fails in the real world: * Switching certificates breaks clients until they change the pinned certificate fingerprint. This incurs client downtime and can require massive amounts of coordination to perform certificate changes. * Some servers operate with multiple certificates on the same hostname. This patch adds support for defining multiple certificate fingerprints per host. This overcomes the deficiencies listed above. I anticipate the primary use case of this feature will be to define both the old and new certificate so a certificate transition can occur with minimal interruption, so this scenario has been called out in the help documentation.
2016-03-14 00:03:58 +03:00
- multiple fingerprints specified and none match
tests: use --insecure instead of web.cacerts=! --insecure is the proper and documented way to do this. The end result is the same: dispatch will set web.cacerts to ! when --insecure is passed. This patch is necessary to refactor handling of web.cacerts in upcoming patches.
2016-04-10 20:54:53 +03:00
$ hg --config 'hostfingerprints.localhost=deadbeefdeadbeefdeadbeefdeadbeefdeadbeef, aeadbeefdeadbeefdeadbeefdeadbeefdeadbeef' -R copy-pull id https://localhost:$HGPORT/ --insecure
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
tests: regenerate x509 test certificates The old x509 test certificates were using cryptographic settings that are ancient by today's standards, namely 512 bit RSA keys. To put things in perspective, browsers have been dropping support for 1024 bit RSA keys. I think it is important that tests match the realities of the times. And 2048 bit RSA keys with SHA-2 hashing are what the world is moving to. This patch replaces all the x509 certificates with new versions using modern best practices. In addition, the docs for generating the keys have been updated, as the existing docs left out a few steps, namely how to generate certs that were not active yet or expired.
2016-07-13 08:26:04 +03:00
abort: certificate for localhost has unexpected fingerprint ec:d8:7c:d6:b3:86:d0:4f:c1:b8:b4:1c:9d:8f:5e:16:8e:ef:1c:03
sslutil: allow fingerprints to be specified in [hostsecurity] We introduce the [hostsecurity] config section. It holds per-host security settings. Currently, the section only contains a "fingerprints" option, which behaves like [hostfingerprints] but supports specifying the hashing algorithm. There is still some follow-up work, such as changing some error messages.
2016-05-28 22:37:36 +03:00
(check hostfingerprint configuration)
[255]
$ hg --config 'hostsecurity.localhost:fingerprints=sha1:deadbeefdeadbeefdeadbeefdeadbeefdeadbeef, sha1:aeadbeefdeadbeefdeadbeefdeadbeefdeadbeef' -R copy-pull id https://localhost:$HGPORT/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
tests: regenerate x509 test certificates The old x509 test certificates were using cryptographic settings that are ancient by today's standards, namely 512 bit RSA keys. To put things in perspective, browsers have been dropping support for 1024 bit RSA keys. I think it is important that tests match the realities of the times. And 2048 bit RSA keys with SHA-2 hashing are what the world is moving to. This patch replaces all the x509 certificates with new versions using modern best practices. In addition, the docs for generating the keys have been updated, as the existing docs left out a few steps, namely how to generate certs that were not active yet or expired.
2016-07-13 08:26:04 +03:00
abort: certificate for localhost has unexpected fingerprint sha1:ec:d8:7c:d6:b3:86:d0:4f:c1:b8:b4:1c:9d:8f:5e:16:8e:ef:1c:03
sslutil: reference appropriate config section in messaging Error messages reference the config section defining the host fingerprint. Now that we have multiple sections where this config setting could live, we need to point the user at the appropriate one. We default to the new "hostsecurity" section. But we will still refer them to the "hostfingerprint" section if a value is defined there. There are some corner cases where the messaging might be off. e.g. they could define a SHA-1 fingerprint in both sections. IMO the messaging needs a massive overhaul. I plan to do this as part of future refactoring to security settings.
2016-05-28 22:58:46 +03:00
(check hostsecurity configuration)
sslutil: allow multiple fingerprints per host Certificate pinning via [hostfingerprints] is a useful security feature. Currently, we only support one fingerprint per hostname. This is simple but it fails in the real world: * Switching certificates breaks clients until they change the pinned certificate fingerprint. This incurs client downtime and can require massive amounts of coordination to perform certificate changes. * Some servers operate with multiple certificates on the same hostname. This patch adds support for defining multiple certificate fingerprints per host. This overcomes the deficiencies listed above. I anticipate the primary use case of this feature will be to define both the old and new certificate so a certificate transition can occur with minimal interruption, so this scenario has been called out in the help documentation.
2016-03-14 00:03:58 +03:00
[255]
url: 'ssh known host'-like checking of fingerprints of HTTPS certificates Known fingerprints of HTTPS servers can now be configured in the hostfingerprints section. That makes it possible to verify the identify of web servers without configuring and trusting the CA chain. Limitations: * Portnumbers are ignored, just like with ordinary certificates. * Host name matching is case sensitive.
2011-01-28 04:57:59 +03:00
- fails when cert doesn't match hostname (port is ignored)
tests: regenerate x509 test certificates The old x509 test certificates were using cryptographic settings that are ancient by today's standards, namely 512 bit RSA keys. To put things in perspective, browsers have been dropping support for 1024 bit RSA keys. I think it is important that tests match the realities of the times. And 2048 bit RSA keys with SHA-2 hashing are what the world is moving to. This patch replaces all the x509 certificates with new versions using modern best practices. In addition, the docs for generating the keys have been updated, as the existing docs left out a few steps, namely how to generate certs that were not active yet or expired.
2016-07-13 08:26:04 +03:00
$ hg -R copy-pull id https://localhost:$HGPORT1/ --config hostfingerprints.localhost=ecd87cd6b386d04fc1b8b41c9d8f5e168eef1c03
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
tests: regenerate x509 test certificates The old x509 test certificates were using cryptographic settings that are ancient by today's standards, namely 512 bit RSA keys. To put things in perspective, browsers have been dropping support for 1024 bit RSA keys. I think it is important that tests match the realities of the times. And 2048 bit RSA keys with SHA-2 hashing are what the world is moving to. This patch replaces all the x509 certificates with new versions using modern best practices. In addition, the docs for generating the keys have been updated, as the existing docs left out a few steps, namely how to generate certs that were not active yet or expired.
2016-07-13 08:26:04 +03:00
abort: certificate for localhost has unexpected fingerprint f4:2f:5a:0c:3e:52:5b:db:e7:24:a8:32:1d:18:97:6d:69:b5:87:84
sslutil: more helpful fingerprint mismatch message This will aid debugging for users of sites that renew certs.
2012-01-26 21:23:15 +04:00
(check hostfingerprint configuration)
url: 'ssh known host'-like checking of fingerprints of HTTPS certificates Known fingerprints of HTTPS servers can now be configured in the hostfingerprints section. That makes it possible to verify the identify of web servers without configuring and trusting the CA chain. Limitations: * Portnumbers are ignored, just like with ordinary certificates. * Host name matching is case sensitive.
2011-01-28 04:57:59 +03:00
[255]
test-https.t: stop using kill `cat $pidfile`
2013-02-09 15:26:16 +04:00
url: 'ssh known host'-like checking of fingerprints of HTTPS certificates Known fingerprints of HTTPS servers can now be configured in the hostfingerprints section. That makes it possible to verify the identify of web servers without configuring and trusting the CA chain. Limitations: * Portnumbers are ignored, just like with ordinary certificates. * Host name matching is case sensitive.
2011-01-28 04:57:59 +03:00
- ignores that certificate doesn't match hostname
tests: regenerate x509 test certificates The old x509 test certificates were using cryptographic settings that are ancient by today's standards, namely 512 bit RSA keys. To put things in perspective, browsers have been dropping support for 1024 bit RSA keys. I think it is important that tests match the realities of the times. And 2048 bit RSA keys with SHA-2 hashing are what the world is moving to. This patch replaces all the x509 certificates with new versions using modern best practices. In addition, the docs for generating the keys have been updated, as the existing docs left out a few steps, namely how to generate certs that were not active yet or expired.
2016-07-13 08:26:04 +03:00
$ hg -R copy-pull id https://127.0.0.1:$HGPORT/ --config hostfingerprints.127.0.0.1=ecd87cd6b386d04fc1b8b41c9d8f5e168eef1c03
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to 127.0.0.1 using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
url: 'ssh known host'-like checking of fingerprints of HTTPS certificates Known fingerprints of HTTPS servers can now be configured in the hostfingerprints section. That makes it possible to verify the identify of web servers without configuring and trusting the CA chain. Limitations: * Portnumbers are ignored, just like with ordinary certificates. * Host name matching is case sensitive.
2011-01-28 04:57:59 +03:00
5fed3813f7f5
tests: test https through http proxy These tests fails for me with Python 2.6(.nothing)
2011-02-16 06:28:11 +03:00
sslutil: config option to specify TLS protocol version 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-minded people may want to not take any risks running TLS 1.0 (or even TLS 1.1). This patch gives those people a config option to explicitly control which TLS versions Mercurial should use. By providing this option, one can require newer TLS versions before they are formally deprecated by Mercurial/Python/OpenSSL/etc and lower their security exposure. This option also provides an easy mechanism to change protocol policies in Mercurial. If there is a 0-day and TLS 1.0 is completely broken, we can act quickly without changing much code. Because setting the minimum TLS protocol is something you'll likely want to do globally, this patch introduces a global config option under [hostsecurity] for that purpose. wrapserversocket() has been taught a hidden config option to define the explicit protocol to use. This is queried in this function and not passed as an argument because I don't want to expose this dangerous option as part of the Python API. There is a risk someone could footgun themselves. But the config option is a devel option, has a warning comment, and I doubt most people are using `hg serve` to run a production HTTPS server (I would have something not Mercurial/Python handle TLS). If this is problematic, we can go back to using a custom extension in tests to coerce the server into bad behavior.
2016-07-15 06:47:22 +03:00
Ports used by next test. Kill servers.
$ killdaemons.py hg0.pid
$ killdaemons.py hg1.pid
$ killdaemons.py hg2.pid
#if sslcontext
Start servers running supported TLS versions
$ cd test
$ hg serve -p $HGPORT -d --pid-file=../hg0.pid --certificate=$PRIV \
> --config devel.serverexactprotocol=tls1.0
$ cat ../hg0.pid >> $DAEMON_PIDS
$ hg serve -p $HGPORT1 -d --pid-file=../hg1.pid --certificate=$PRIV \
> --config devel.serverexactprotocol=tls1.1
$ cat ../hg1.pid >> $DAEMON_PIDS
$ hg serve -p $HGPORT2 -d --pid-file=../hg2.pid --certificate=$PRIV \
> --config devel.serverexactprotocol=tls1.2
$ cat ../hg2.pid >> $DAEMON_PIDS
$ cd ..
Clients talking same TLS versions work
$ P="$CERTSDIR" hg --config hostsecurity.minimumprotocol=tls1.0 id https://localhost:$HGPORT/
5fed3813f7f5
$ P="$CERTSDIR" hg --config hostsecurity.minimumprotocol=tls1.1 id https://localhost:$HGPORT1/
5fed3813f7f5
$ P="$CERTSDIR" hg --config hostsecurity.minimumprotocol=tls1.2 id https://localhost:$HGPORT2/
5fed3813f7f5
Clients requiring newer TLS version than what server supports fail
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.
2016-07-14 07:35:54 +03:00
$ P="$CERTSDIR" hg id https://localhost:$HGPORT/
(could not negotiate a common protocol; see https://mercurial-scm.org/wiki/SecureConnections for how to configure Mercurial to avoid this error)
abort: error: *unsupported protocol* (glob)
[255]
sslutil: config option to specify TLS protocol version 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-minded people may want to not take any risks running TLS 1.0 (or even TLS 1.1). This patch gives those people a config option to explicitly control which TLS versions Mercurial should use. By providing this option, one can require newer TLS versions before they are formally deprecated by Mercurial/Python/OpenSSL/etc and lower their security exposure. This option also provides an easy mechanism to change protocol policies in Mercurial. If there is a 0-day and TLS 1.0 is completely broken, we can act quickly without changing much code. Because setting the minimum TLS protocol is something you'll likely want to do globally, this patch introduces a global config option under [hostsecurity] for that purpose. wrapserversocket() has been taught a hidden config option to define the explicit protocol to use. This is queried in this function and not passed as an argument because I don't want to expose this dangerous option as part of the Python API. There is a risk someone could footgun themselves. But the config option is a devel option, has a warning comment, and I doubt most people are using `hg serve` to run a production HTTPS server (I would have something not Mercurial/Python handle TLS). If this is problematic, we can go back to using a custom extension in tests to coerce the server into bad behavior.
2016-07-15 06:47:22 +03:00
$ P="$CERTSDIR" hg --config hostsecurity.minimumprotocol=tls1.1 id https://localhost:$HGPORT/
(could not negotiate a common protocol; see https://mercurial-scm.org/wiki/SecureConnections for how to configure Mercurial to avoid this error)
abort: error: *unsupported protocol* (glob)
[255]
$ P="$CERTSDIR" hg --config hostsecurity.minimumprotocol=tls1.2 id https://localhost:$HGPORT/
(could not negotiate a common protocol; see https://mercurial-scm.org/wiki/SecureConnections for how to configure Mercurial to avoid this error)
abort: error: *unsupported protocol* (glob)
[255]
$ P="$CERTSDIR" hg --config hostsecurity.minimumprotocol=tls1.2 id https://localhost:$HGPORT1/
(could not negotiate a common protocol; see https://mercurial-scm.org/wiki/SecureConnections for how to configure Mercurial to avoid this error)
abort: error: *unsupported protocol* (glob)
[255]
The per-host config option overrides the default
$ P="$CERTSDIR" hg id https://localhost:$HGPORT/ \
> --config hostsecurity.minimumprotocol=tls1.2 \
> --config hostsecurity.localhost:minimumprotocol=tls1.0
5fed3813f7f5
The per-host config option by itself works
$ P="$CERTSDIR" hg id https://localhost:$HGPORT/ \
> --config hostsecurity.localhost:minimumprotocol=tls1.2
(could not negotiate a common protocol; see https://mercurial-scm.org/wiki/SecureConnections for how to configure Mercurial to avoid this error)
abort: error: *unsupported protocol* (glob)
[255]
$ killdaemons.py hg0.pid
tests: drop explicit $TESTDIR from executables $TESTDIR is added to the path, so this is superfluous. Also, inconsistent use of quotes means we might have broken on tests with paths containing spaces.
2015-06-08 22:44:30 +03:00
$ killdaemons.py hg1.pid
sslutil: config option to specify TLS protocol version 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-minded people may want to not take any risks running TLS 1.0 (or even TLS 1.1). This patch gives those people a config option to explicitly control which TLS versions Mercurial should use. By providing this option, one can require newer TLS versions before they are formally deprecated by Mercurial/Python/OpenSSL/etc and lower their security exposure. This option also provides an easy mechanism to change protocol policies in Mercurial. If there is a 0-day and TLS 1.0 is completely broken, we can act quickly without changing much code. Because setting the minimum TLS protocol is something you'll likely want to do globally, this patch introduces a global config option under [hostsecurity] for that purpose. wrapserversocket() has been taught a hidden config option to define the explicit protocol to use. This is queried in this function and not passed as an argument because I don't want to expose this dangerous option as part of the Python API. There is a risk someone could footgun themselves. But the config option is a devel option, has a warning comment, and I doubt most people are using `hg serve` to run a production HTTPS server (I would have something not Mercurial/Python handle TLS). If this is problematic, we can go back to using a custom extension in tests to coerce the server into bad behavior.
2016-07-15 06:47:22 +03:00
$ killdaemons.py hg2.pid
#endif
tests: test https through http proxy These tests fails for me with Python 2.6(.nothing)
2011-02-16 06:28:11 +03:00
tests: fix startup/shutdown races in test-https tinyproxy now writes its own pid when it's ready to accept connections
2012-03-29 04:23:25 +04:00
Prepare for connecting through proxy
tests: test https through http proxy These tests fails for me with Python 2.6(.nothing)
2011-02-16 06:28:11 +03:00
sslutil: config option to specify TLS protocol version 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-minded people may want to not take any risks running TLS 1.0 (or even TLS 1.1). This patch gives those people a config option to explicitly control which TLS versions Mercurial should use. By providing this option, one can require newer TLS versions before they are formally deprecated by Mercurial/Python/OpenSSL/etc and lower their security exposure. This option also provides an easy mechanism to change protocol policies in Mercurial. If there is a 0-day and TLS 1.0 is completely broken, we can act quickly without changing much code. Because setting the minimum TLS protocol is something you'll likely want to do globally, this patch introduces a global config option under [hostsecurity] for that purpose. wrapserversocket() has been taught a hidden config option to define the explicit protocol to use. This is queried in this function and not passed as an argument because I don't want to expose this dangerous option as part of the Python API. There is a risk someone could footgun themselves. But the config option is a devel option, has a warning comment, and I doubt most people are using `hg serve` to run a production HTTPS server (I would have something not Mercurial/Python handle TLS). If this is problematic, we can go back to using a custom extension in tests to coerce the server into bad behavior.
2016-07-15 06:47:22 +03:00
$ hg serve -R test -p $HGPORT -d --pid-file=hg0.pid --certificate=$PRIV
$ cat hg0.pid >> $DAEMON_PIDS
$ hg serve -R test -p $HGPORT2 -d --pid-file=hg2.pid --certificate=server-expired.pem
$ cat hg2.pid >> $DAEMON_PIDS
tinyproxy.py doesn't fully detach, so killing it may result in extra output
from the shell. So don't kill it.
tests: drop explicit $TESTDIR from executables $TESTDIR is added to the path, so this is superfluous. Also, inconsistent use of quotes means we might have broken on tests with paths containing spaces.
2015-06-08 22:44:30 +03:00
$ tinyproxy.py $HGPORT1 localhost >proxy.log </dev/null 2>&1 &
tests: use 'do sleep 0' instead of 'do true', also on first line of command 2cd44a791e66 established that '... do true ...' shouldn't be used, but that was only enforced on continued lines.
2012-04-23 03:56:48 +04:00
$ while [ ! -f proxy.pid ]; do sleep 0; done
tests: test https through http proxy These tests fails for me with Python 2.6(.nothing)
2011-02-16 06:28:11 +03:00
$ cat proxy.pid >> $DAEMON_PIDS
$ echo "[http_proxy]" >> copy-pull/.hg/hgrc
$ echo "always=True" >> copy-pull/.hg/hgrc
$ echo "[hostfingerprints]" >> copy-pull/.hg/hgrc
$ echo "localhost =" >> copy-pull/.hg/hgrc
Test unvalidated https through proxy
$ http_proxy=http://localhost:$HGPORT1/ hg -R copy-pull pull --insecure --traceback
pulling from https://localhost:$HGPORT/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
sslutil: move and change warning when cert verification is disabled A short time ago, validatesocket() didn't know the reasons why cert verification was disabled. Multiple code paths could lead to cert verification being disabled. e.g. --insecure and lack of loaded CAs. With the recent refactorings to sslutil.py, we now know the reasons behind security settings. This means we can recognize when the user requested security be disabled (as opposed to being unable to provide certificate verification due to lack of CAs). This patch moves the check for certificate verification being disabled and changes the wording to distinguish it from other states. The warning message is purposefully more dangerous sounding in order to help discourage people from disabling security outright. We may want to add a URL or hint to this message. I'm going to wait until additional changes to security defaults before committing to something.
2016-05-30 23:15:53 +03:00
warning: connection security to localhost is disabled per current settings; communication is susceptible to eavesdropping and tampering
tests: test https through http proxy These tests fails for me with Python 2.6(.nothing)
2011-02-16 06:28:11 +03:00
searching for changes
no changes found
Test https with cacert and fingerprint through proxy
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
$ http_proxy=http://localhost:$HGPORT1/ hg -R copy-pull pull \
> --config web.cacerts="$CERTSDIR/pub.pem"
tests: test https through http proxy These tests fails for me with Python 2.6(.nothing)
2011-02-16 06:28:11 +03:00
pulling from https://localhost:$HGPORT/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
tests: test https through http proxy These tests fails for me with Python 2.6(.nothing)
2011-02-16 06:28:11 +03:00
searching for changes
no changes found
tests: regenerate x509 test certificates The old x509 test certificates were using cryptographic settings that are ancient by today's standards, namely 512 bit RSA keys. To put things in perspective, browsers have been dropping support for 1024 bit RSA keys. I think it is important that tests match the realities of the times. And 2048 bit RSA keys with SHA-2 hashing are what the world is moving to. This patch replaces all the x509 certificates with new versions using modern best practices. In addition, the docs for generating the keys have been updated, as the existing docs left out a few steps, namely how to generate certs that were not active yet or expired.
2016-07-13 08:26:04 +03:00
$ http_proxy=http://localhost:$HGPORT1/ hg -R copy-pull pull https://127.0.0.1:$HGPORT/ --config hostfingerprints.127.0.0.1=ecd87cd6b386d04fc1b8b41c9d8f5e168eef1c03
tests: add (glob) annotations to output lines with 127.0.0.1
2016-07-10 06:03:45 +03:00
pulling from https://127.0.0.1:$HGPORT/ (glob)
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to 127.0.0.1 using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
tests: test https through http proxy These tests fails for me with Python 2.6(.nothing)
2011-02-16 06:28:11 +03:00
searching for changes
no changes found
Test https with cert problems through proxy
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
$ http_proxy=http://localhost:$HGPORT1/ hg -R copy-pull pull \
> --config web.cacerts="$CERTSDIR/pub-other.pem"
pull: print "pulling from foo" before accessing the other repo 1. This is consistent with pushing. 2. This allows to see the URL of the other repo in case accessing the repo fails, e.g. wrong ssh path or issues with the https certificate, without using --debug or showconfig paths. Additionally add test for this in the context of ssh with a wrong path.
2015-02-24 12:55:24 +03:00
pulling from https://localhost:$HGPORT/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
test-https: glob error messages more so we pass on Python 2.7.9 Python 2.7.9 cleans up how it stringifies SSL errors, so we have to look only for the important bit (certificate verify failed) rather than looking for specific ssl module goop (which is now unstable).
2015-01-13 23:15:37 +03:00
abort: error: *certificate verify failed* (glob)
url: merge BetterHTTPS with httpsconnection to get some proxy https validation
2011-02-16 06:36:36 +03:00
[255]
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
$ http_proxy=http://localhost:$HGPORT1/ hg -R copy-pull pull \
> --config web.cacerts="$CERTSDIR/pub-expired.pem" https://localhost:$HGPORT2/
pull: print "pulling from foo" before accessing the other repo 1. This is consistent with pushing. 2. This allows to see the URL of the other repo in case accessing the repo fails, e.g. wrong ssh path or issues with the https certificate, without using --debug or showconfig paths. Additionally add test for this in the context of ssh with a wrong path.
2015-02-24 12:55:24 +03:00
pulling from https://localhost:$HGPORT2/
sslutil: print a warning when using TLS 1.0 on legacy Python Mercurial now requires TLS 1.1+ when TLS 1.1+ is supported by the client. Since we made the decision to require TLS 1.1+ when running with modern Python versions, it makes sense to do something for legacy Python versions that only support TLS 1.0. Feature parity would be to prevent TLS 1.0 connections out of the box and require a config option to enable them. However, this is extremely user hostile since Mercurial wouldn't talk to https:// by default in these installations! I can easily see how someone would do something foolish like use "--insecure" instead - and that would be worse than allowing TLS 1.0! This patch takes the compromise position of printing a warning when performing TLS 1.0 connections when running on old Python versions. While this warning is no more annoying than the CA certificate / fingerprint warnings in Mercurial 3.8, we provide a config option to disable the warning because to many people upgrading Python to make the warning go away is not an available recourse (unlike pinning fingerprints is for the CA warning). The warning appears as optional output in a lot of tests.
2016-07-14 07:49:17 +03:00
warning: connecting to localhost using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
test-https: glob error messages more so we pass on Python 2.7.9 Python 2.7.9 cleans up how it stringifies SSL errors, so we have to look only for the important bit (certificate verify failed) rather than looking for specific ssl module goop (which is now unstable).
2015-01-13 23:15:37 +03:00
abort: error: *certificate verify failed* (glob)
url: merge BetterHTTPS with httpsconnection to get some proxy https validation
2011-02-16 06:36:36 +03:00
[255]
test-https: test basic functions of client certificate authentication Because hgweb doesn't support client certificates, I just patched it to require client certificates that are signed and verified by the server certificate. This won't be ideal for production servers, but should be okay for the test. The encrypted key file will be used by future patches. I couldn't figure out a way to redirect a password prompt provided by OpenSSL, so it isn't tested for now.
2015-05-07 11:38:22 +03:00
tests: drop explicit $TESTDIR from executables $TESTDIR is added to the path, so this is superfluous. Also, inconsistent use of quotes means we might have broken on tests with paths containing spaces.
2015-06-08 22:44:30 +03:00
$ killdaemons.py hg0.pid
test-https: test basic functions of client certificate authentication Because hgweb doesn't support client certificates, I just patched it to require client certificates that are signed and verified by the server certificate. This won't be ideal for production servers, but should be okay for the test. The encrypted key file will be used by future patches. I couldn't figure out a way to redirect a password prompt provided by OpenSSL, so it isn't tested for now.
2015-05-07 11:38:22 +03:00
#if sslcontext
hgweb: use sslutil.wrapserversocket() This patch transitions the built-in HTTPS server to use sslutil for creating the server socket. As part of this transition, we implement developer-only config options to control CA loading and whether to require client certificates. This eliminates the need for the custom extension in test-https.t to define these. There is a slight change in behavior with regards to protocol selection. Before, we would always use the TLS 1.0 constant to define the protocol version. This would *only* use TLS 1.0. sslutil defaults to TLS 1.0+. So this patch improves the security of `hg serve` out of the box by allowing it to use TLS 1.1 and 1.2 (if available).
2016-07-13 09:12:03 +03:00
Start hgweb that requires client certificates:
test-https: test basic functions of client certificate authentication Because hgweb doesn't support client certificates, I just patched it to require client certificates that are signed and verified by the server certificate. This won't be ideal for production servers, but should be okay for the test. The encrypted key file will be used by future patches. I couldn't figure out a way to redirect a password prompt provided by OpenSSL, so it isn't tested for now.
2015-05-07 11:38:22 +03:00
$ cd test
$ hg serve -p $HGPORT -d --pid-file=../hg0.pid --certificate=$PRIV \
hgweb: use sslutil.wrapserversocket() This patch transitions the built-in HTTPS server to use sslutil for creating the server socket. As part of this transition, we implement developer-only config options to control CA loading and whether to require client certificates. This eliminates the need for the custom extension in test-https.t to define these. There is a slight change in behavior with regards to protocol selection. Before, we would always use the TLS 1.0 constant to define the protocol version. This would *only* use TLS 1.0. sslutil defaults to TLS 1.0+. So this patch improves the security of `hg serve` out of the box by allowing it to use TLS 1.1 and 1.2 (if available).
2016-07-13 09:12:03 +03:00
> --config devel.servercafile=$PRIV --config devel.serverrequirecert=true
test-https: test basic functions of client certificate authentication Because hgweb doesn't support client certificates, I just patched it to require client certificates that are signed and verified by the server certificate. This won't be ideal for production servers, but should be okay for the test. The encrypted key file will be used by future patches. I couldn't figure out a way to redirect a password prompt provided by OpenSSL, so it isn't tested for now.
2015-05-07 11:38:22 +03:00
$ cat ../hg0.pid >> $DAEMON_PIDS
$ cd ..
without client certificate:
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
$ P="$CERTSDIR" hg id https://localhost:$HGPORT/
test-https: test basic functions of client certificate authentication Because hgweb doesn't support client certificates, I just patched it to require client certificates that are signed and verified by the server certificate. This won't be ideal for production servers, but should be okay for the test. The encrypted key file will be used by future patches. I couldn't figure out a way to redirect a password prompt provided by OpenSSL, so it isn't tested for now.
2015-05-07 11:38:22 +03:00
abort: error: *handshake failure* (glob)
[255]
with client certificate:
$ cat << EOT >> $HGRCPATH
> [auth]
> l.prefix = localhost
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
> l.cert = $CERTSDIR/client-cert.pem
> l.key = $CERTSDIR/client-key.pem
test-https: test basic functions of client certificate authentication Because hgweb doesn't support client certificates, I just patched it to require client certificates that are signed and verified by the server certificate. This won't be ideal for production servers, but should be okay for the test. The encrypted key file will be used by future patches. I couldn't figure out a way to redirect a password prompt provided by OpenSSL, so it isn't tested for now.
2015-05-07 11:38:22 +03:00
> EOT
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
$ P="$CERTSDIR" hg id https://localhost:$HGPORT/ \
> --config auth.l.key="$CERTSDIR/client-key-decrypted.pem"
test-https: test basic functions of client certificate authentication Because hgweb doesn't support client certificates, I just patched it to require client certificates that are signed and verified by the server certificate. This won't be ideal for production servers, but should be okay for the test. The encrypted key file will be used by future patches. I couldn't figure out a way to redirect a password prompt provided by OpenSSL, so it isn't tested for now.
2015-05-07 11:38:22 +03:00
5fed3813f7f5
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
$ printf '1234\n' | env P="$CERTSDIR" hg id https://localhost:$HGPORT/ \
ssl: prompt passphrase of client key file via ui.getpass() (issue4648) This is necessary to communicate with third-party tools through command-server channel. This requires SSLContext backported to Python 2.7.9+. It doesn't look nice to pass ui by sslkwargs, but I think it is the only way to do without touching various client codes including httpclient (aka http2). ui is mandatory if certfile is specified, so it has no default value. BTW, test-check-commit-hg.t complains that ssl_wrap_socket() has foo_bar naming. Should I bulk-replace it to sslwrapsocket() ?
2015-05-07 11:15:24 +03:00
> --config ui.interactive=True --config ui.nontty=True
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
passphrase for */client-key.pem: 5fed3813f7f5 (glob)
ssl: prompt passphrase of client key file via ui.getpass() (issue4648) This is necessary to communicate with third-party tools through command-server channel. This requires SSLContext backported to Python 2.7.9+. It doesn't look nice to pass ui by sslkwargs, but I think it is the only way to do without touching various client codes including httpclient (aka http2). ui is mandatory if certfile is specified, so it has no default value. BTW, test-check-commit-hg.t complains that ssl_wrap_socket() has foo_bar naming. Should I bulk-replace it to sslwrapsocket() ?
2015-05-07 11:15:24 +03:00
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
2016-05-27 16:40:09 +03:00
$ env P="$CERTSDIR" hg id https://localhost:$HGPORT/
ssl: prompt passphrase of client key file via ui.getpass() (issue4648) This is necessary to communicate with third-party tools through command-server channel. This requires SSLContext backported to Python 2.7.9+. It doesn't look nice to pass ui by sslkwargs, but I think it is the only way to do without touching various client codes including httpclient (aka http2). ui is mandatory if certfile is specified, so it has no default value. BTW, test-check-commit-hg.t complains that ssl_wrap_socket() has foo_bar naming. Should I bulk-replace it to sslwrapsocket() ?
2015-05-07 11:15:24 +03:00
abort: error: * (glob)
[255]
test-https: test basic functions of client certificate authentication Because hgweb doesn't support client certificates, I just patched it to require client certificates that are signed and verified by the server certificate. This won't be ideal for production servers, but should be okay for the test. The encrypted key file will be used by future patches. I couldn't figure out a way to redirect a password prompt provided by OpenSSL, so it isn't tested for now.
2015-05-07 11:38:22 +03:00
#endif
Reference in New Issue Copy Permalink