On SSLcontext, security callback has prototype
/* Security callback */
int (*sec_cb) (const SSL *s, const SSL_CTX *ctx, int op, int bits, int nid,
void *other, void *ex);
if one calls that function, with context passed in, "op" set to
SSL_SECOP_VERSION, "bits" set to zero,
I've read through this bug and I don't see a good way forward with a
solution here. OpenSSL 1.1.1 doesn't provide the exact API that is
required to solve it, which would probably be 3) as suggested above, but
I don't think Ubuntu should change the meaning of the value returned by
that API.
Ubuntu
2) and 3) would never return 0, which is what the upstream OpenSSL
version returns now.
2) would make it return TLS1_VERSION for the minimum and TLS1_3_VERSION
for the maximum with default build options. If you enable SSlv3 support
at compile time, the minimum would return SSL3_VERSION. Note that
In upstream OpenSSL, (3) is the same as (1) for a pristine
SSL_CTX_new(TLS_method()) context.
As far as I can see, the Ubuntu patch effectively sets the minimum
version to TLS 1.2 and prevents users from setting TLS 1.0 and 1.1. I
propose that the patch also changes the value of minimum protocol o
There are 3 things that can possibly returned by such a function:
1) The value that's set as minimum/maximum
2) The minimum and maximum version that's supported by the library, not
depending on settings
3) The minimum and maximum version that's supported by the library, depending
on current setti
Actually, I don't want to enable TLS 1.0 and 1.1 when these versions are
disabled by crypto policy or openssl.cnf. It's totally ok that these
versions are disabled and don't work any more! I just need a reliable
way to *detect* that the versions are disabled at runtime.
The feature detection logic
My understanding of things is that Ubuntu does this:
- Set the default security level to 2 (at compile time)
- Disable TLS 1.0 and 1.1 at security level 2, only keeping TLS 1.2 by default
This is what Debian does:
- Set the default security level to 2 (using a config file)
- Set the minimum versio
I was expecting SSL_CTX_get_min_proto_version() to return the default
value (TLS1_2_VERSION). It's currently documented that 0 means the
lowest supported by the library. If it returns 0 and the library
supports TLS 1.0, it should be able to negotiate TLS 1.0.
On reflection, I'm not sure that for t
> I'm not sure how this is related to anything of the above, can you
please open a new bug report with details?
It looks like both issues are caused by the same patch. I have filed
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1917625 for the
internal error message and uploaded a Dockerfi
(Short answer, I'm in meetings for the rest of the day)
Python's ssl module doesn't support TLS over UDP. DTLS is not an issue
for CPython. I have limited experience with DTLS and cannot contribute
much to that part of the discussion. Python's test suite uses its own
set of certificates for testin
Please disregard comment #9, this is a different issue.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1899878
Title:
Python's test_ssl fails starting from Ubuntu 20.04
To manage notifications about
The python2.7 security updates that will be released today will fix this
issue.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1899878
Title:
Python's test_ssl fails starting from Ubuntu 20.04
To ma
But Debian & Fedora implementation are buggy, because they break 1.0.2x
users & they do not prohibit DTLSv1.1 whilst enforcing TLSv1.2+.
So although Debian & Fedora look "nice" they are security vulnerable
configurations.
I can set min_version to TLSv1.2, in addition to security level 2 but
that
CC Kurt Roeckx
Kurt, could you please take a look? An Ubuntu's downstream patch for
OpenSSL causes TLS1_AD_INTERNAL_ERROR internal error in OpenSSL's state
machine and breaks CPython's test suite. Debian is not affected. It's
the same problem I mentioned in my gist a couple of months ago.
--
You
PS: Ultimately it is your call how you want to handle the issue. You can
either treat it as a bug in Ubuntu's downstream patch or close the issue
as WONTFIX. In the latter case I'll add some hacks to our test suite and
update our documentation that some legacy TLS features are not working
on Ubuntu
This is really just a problem with Ubuntu 20.04 and 20.10 (and maybe
older/newer releases). The same tests are passing fine on latest Debian
testing as well as Fedora. Debian testing and Fedora use a crypto policy
that raises security level to 2 and disallows TLS 1.0 and 1.1. Python's
test suite in
Fedora & Debian & Ubuntu implement openssl differently.
In Ubuntu, as an Ubuntu-specific patch, we set default security level to
2, and prohibit protocols lower than TLSv1.2 / DTLSv1.2.
This is documented in the Ubuntu manpages for OpenSSL
http://manpages.ubuntu.com/manpages/hirsute/en/man3/SSL_
FYI, yesterday GitHub Actions moved "ubuntu-latest" to 20.04. This
caused breakage in CPython's CI, https://bugs.python.org/issue43382
** Bug watch added: Python Roundup #43382
http://bugs.python.org/issue43382
--
You received this bug notification because you are a member of Ubuntu
Bugs, whi
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: openssl (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1899878
Title:
Py
Sorry, this is the correct link:
https://bugs.python.org/issue41561#msg378103
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1899878
Title:
Python's test_ssl fails starting from Ubuntu 20.04
To mana
20 matches
Mail list logo
