[issue35045] test_min_max_version (test.test_ssl.ContextTests) fails on Fedora 29+ and openssl 1.1.1
Change by Alan Huang : -- pull_requests: +11509, 11510 ___ Python tracker <https://bugs.python.org/issue35045> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35045] test_min_max_version (test.test_ssl.ContextTests) fails on Fedora 29+ and openssl 1.1.1
Change by Alan Huang : -- pull_requests: +11509 ___ Python tracker <https://bugs.python.org/issue35045> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33995] test_min_max_version in test_ssl.py fails when Python is built against LibreSSL; {min,max}imum_version behavior differs from OpenSSL
New submission from Alan Huang :
LibreSSL's implementation of the function used to get the minimum and maximum
SSL versions supported differs from OpenSSL's.
In short, the issue is in the implementations of `SSL_CTX_new` - OpenSSL
initializes variables `ret->{min,max}_proto_version` to 0, while LibreSSL
initializes corresponding variables to those of the `SSL_METHOD` given.
As such, when Python is built with LibreSSL, the default values for an instance
of ssl.SSLContext are, in the case of ssl.SSLContext(), ctx.minimum_version =
; ctx.maximum_version = .
This is NOT what test_ssl.py expects; it expects OpenSSL's behavior of
initializing the version variables to zero, which _ssl.c then translates to
PY_PROTO_{MIN,MAX}IMUM_SUPPORTED -> ssl.TLSVersion.{MIN,MAX}IMUM_SUPPORTED.
Additionally, LibreSSL, when `SSL_CTX_set_{min,max}_proto_version` is called
with `version` equal to zero, explicitly sets the minimum / maximum values
equal to the minimum / maximum values for the `SSL_METHOD` it was called with
(namely, 769/770/771, in the case of `TLS_method()`), not the minimum / maximum
values supported by the library.
I have sent an email to the LibreSSL mailing list asking for clarification on
this point, namely, if this is intended behavior. If it is, there are two ways
that come to mind to work around this behavior. Both ways would only be
necessary if `IS_LIBRESSL`.
1. Skip `test_min_max_version`.
2. Instead of testing that ctx is equal *to* the extremes after it's been set
to one of the extremes, test that it's equal to the actual constants.
There are two ways this could be accomplished as well:
a. Use PY_PROTO_{MIN,MAX}IMUM_AVAILABLE, defined in _ssl.c (this may
require the addition of another call to `PyModule_AddIntConstant` to provide
access to the constant from _ssl). The downside to this approach is that it
assumes that `TLS_method()`, or whatever `SSL_METHOD` test_ssl.py uses has
lower and upper bounds equal to PY_PROTO_{MIN,MAX}IMUM_AVAILABLE, which may not
always be the case.
b. Access and store the values for ctx.{min,max}imum_value on creation,
then reference them after setting.
Either of these approaches would likely also have the benefit of removing
the need for `self.assertIn(ctx.minimum_version, {ssl.TLSVersion.TLSv1_2,
ssl.TLSVersion.TLSv1_3})`.
The test that failed was:
==
FAIL: test_min_max_version (test.test_ssl.ContextTests)
--
Traceback (most recent call last):
File "/home/alan/src/cpython/Lib/test/test_ssl.py", line 1066, in
test_min_max_version
ctx.minimum_version, ssl.TLSVersion.MINIMUM_SUPPORTED
AssertionError: !=
Addendum:
I found the documentation for ssl.TLSVersion.{MAX,MIN}IMUM_SUPPORTED confusing
at first - it took me quite a while to realize what the purpose of the
constants were; I would have expected them to contain the maximum and minimum
protocol versions supported by the library; I see why it was phrased that way,
after having boned up on ssl.py, _ssl.c, and OpenSSL/LibreSSL, but think it
could could be made clearer.
--
assignee: docs@python
components: Documentation, SSL, Tests
messages: 320703
nosy: Alan.Huang, alex, christian.heimes, docs@python, dstufft, janssen
priority: normal
severity: normal
status: open
title: test_min_max_version in test_ssl.py fails when Python is built against
LibreSSL; {min,max}imum_version behavior differs from OpenSSL
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue33995>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34001] LibreSSL does not tolerate setting minimum_version greater than maximum_version
New submission from Alan Huang :
LibreSSL has a function called `ssl_clamp_version_range` that is called before
attempting to set the minimum and maximum protocol versions in
`ssl_version_set_{min,max}`. The function disallows setting ranges that are
invalid (i.e., where minimum_version > maximum_version). OpenSSL does not
disallow this behavior.
As a result, attempting to set a minimum_version greater than a maximum_version
results in a ValueError when Python is built with LibreSSL.
There are two things that might need fixing here:
1. Replace the ValueError "Unsupported protocol version 0x%x" message with a
more generic one. The assumption that the only way the operation can fail is if
the underlying library does not support the protocol version is incorrect.
This can be done by either making the message more generic or by introducing
another error message to handle this case.
2. Change test_min_max_version lines 3575-3576 to set the maximum_version
before the minimum_version.
Here's some Python code to reproduce the above-mentioned error:
```
import ssl
ctx = ssl.SSLContext()
ctx.maximum_version = ssl.TLSVersion.TLSv1_1
ctx.minimum_version = ssl.TLSVersion.TLSv1_2
Traceback (most recent call last):
File "", line 1, in
File "/home/alan/src/cpython/Lib/ssl.py", line 491, in minimum_version
super(SSLContext, SSLContext).minimum_version.__set__(self, value)
ValueError: Unsupported protocol version 0x303
```
Here's some example C code:
```
#include
#include
#include
int main(){
SSL_CTX *ctx = NULL;
ctx = SSL_CTX_new(TLS_method());
printf("setting max to TLSv1.1: ");
if(SSL_CTX_set_max_proto_version(ctx, TLS1_1_VERSION)){
printf("success\n");
}
else{
printf("failure\n");
}
printf("setting min to TLSv1.2: ");
if(SSL_CTX_set_min_proto_version(ctx, TLS1_2_VERSION)){
printf("success\n");
}
else{
printf("failure\n");
}
printf("min ver: %d\n", SSL_CTX_get_min_proto_version(ctx));
printf("max ver: %d\n", SSL_CTX_get_max_proto_version(ctx));
return 0;
}
```
Under LibreSSL 2.7.4, this produces:
```
setting max to TLSv1.1: success
setting min to TLSv1.2: failure
min ver: 769
max ver: 770
```
Under OpenSSL 1.1.0g, this produces:
```
setting max to TLSv1.1: success
setting min to TLSv1.2: success
min ver: 771
max ver: 770
```
The test that failed:
==
ERROR: test_min_max_version (test.test_ssl.ThreadedTests)
--
Traceback (most recent call last):
File "/home/alan/src/cpython/Lib/test/test_ssl.py", line 3575, in
test_min_max_version
server_context.minimum_version = ssl.TLSVersion.TLSv1_2
File "/home/alan/src/cpython/Lib/ssl.py", line 491, in minimum_version
super(SSLContext, SSLContext).minimum_version.__set__(self, value)
ValueError: Unsupported protocol version 0x303
--
assignee: christian.heimes
components: SSL, Tests
messages: 320722
nosy: Alan.Huang, alex, christian.heimes, dstufft, janssen
priority: normal
severity: normal
status: open
title: LibreSSL does not tolerate setting minimum_version greater than
maximum_version
type: behavior
versions: Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue34001>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33995] test_min_max_version in test_ssl.py fails when Python is built against LibreSSL; {min,max}imum_version behavior differs from OpenSSL
Change by Alan Huang : -- components: -Documentation versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue33995> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34001] LibreSSL does not tolerate setting minimum_version greater than maximum_version
Alan Huang added the comment: Strangely, LibreSSL's `ssl_clamp_version_range` function is perfectly happy to accept minimum protocol versions lower than the lowest supported protocol version, and likewise is happy to accept maximum protocol versions higher than the highest supported protocol version. In said case, the minimum/maximum protocol version is set to clamp_min/clamp_max (i.e., the minimum/maximum protocol version supported by the internal method). As such, the assertion test `ctx.minimum_version = 42` on line 1127 in test_min_max_version in test_ssl.py fails. A possible fix would be to add another check in `set_min_max_proto_version` _ssl.c that checks if the current set protocol version is equal to the value passed (with exceptions for the magic constants of `MINIMUM_SUPPORTED` and `MAXIMUM_SUPPORTED`), and if not, raise a ValueError as well. One dilemma is whether to reset the respective version back to what it was before the attempt, which I think should be done. -- ___ Python tracker <https://bugs.python.org/issue34001> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33995] test_min_max_version in test_ssl.py fails when Python is built against LibreSSL; {min,max}imum_version behavior differs from OpenSSL
Change by Alan Huang : -- keywords: +patch pull_requests: +7658 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33995> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33995] test_min_max_version in test_ssl.py fails when Python is built against LibreSSL; {min,max}imum_version behavior differs from OpenSSL
Alan Huang added the comment:
PR 8050 implements option 2a (use PY_PROTO_{MIN,MAX}IMUM_AVAILABLE).
--
___
Python tracker
<https://bugs.python.org/issue33995>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34001] LibreSSL does not tolerate setting minimum_version greater than maximum_version
Change by Alan Huang : -- keywords: +patch pull_requests: +7663 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34001> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33808] ssl.get_server_certificate fails with openssl 1.1.0 but works with 1.0.2g for self-signed certificate
Alan Huang added the comment: This is an issue of cipher support, not a Python bug. mail.mani.pt supports the following (outdated) ciphers: RC4-SHA (0x05) RC4-MD5 (0x04) DES-CBC3-SHA (0x0a) EXP1024-DES-CBC-SHA (0x62) DES-CBC-SHA (0x09) EXP1024-RC4-SHA (0x64) EXP-RC2-CBC-MD5 (0x06) EXP-RC4-MD5 (0x03) OpenSSL 1.0.2k supports RC4-SHA, RC4-MD5, and DES-CBC3-SHA. OpenSSL 1.1.0g supports none of the above ciphers. As such, OpenSSL 1.1.0 cannot negotiate a shared cipher suite, but OpenSSL 1.0.2g can. Update your mailserver to use modern cipher suites and protocols. -- nosy: +Alan.Huang ___ Python tracker <https://bugs.python.org/issue33808> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
