Repository navigation
Change default signature algorithms for context in the ssl library #88974
Description
| BPO | 44811 |
|---|---|
| Nosy | @tiran, @anisgandoura, @ramikg |
| PRs |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/tiran'
closed_at = None
created_at = <Date 2021-08-02.12:25:20.022>
labels = ['expert-SSL', 'type-feature', '3.11']
title = 'Change default signature algorithms for context in the ssl library'
updated_at = <Date 2021-10-01.14:03:30.841>
user = 'https://github.com/anisgandoura'bugs.python.org fields:
activity = <Date 2021-10-01.14:03:30.841>
actor = 'ramikg'
assignee = 'christian.heimes'
closed = False
closed_date = None
closer = None
components = ['SSL']
creation = <Date 2021-08-02.12:25:20.022>
creator = 'anis.gandoura'
dependencies = []
files = []
hgrepos = []
issue_num = 44811
keywords = ['patch']
message_count = 4.0
messages = ['398762', '398769', '398772', '403016']
nosy_count = 4.0
nosy_names = ['christian.heimes', 'python-dev', 'anis.gandoura', 'ramikg']
pr_nums = ['27550']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue44811'
versions = ['Python 3.11']
Activity
anisgandoura commentedon Aug 2, 2021
Expose the OpenSSL function SSL_CTX_set1_sigalgs_list to allow the user to modify the supported signature algorithms for a given SSL Context.
OpenSSL documentation: https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_set1_sigalgs_list.html
tiran commentedon Aug 2, 2021
Thanks for your PR. Before we move forward, let's discuss reasoning and API design first.
Why should a Python application be able to modify the signature algorithms? The default settings are safe and sane. Security properties should rather be set system-wide with a crypto policy in OpenSSL's global config file. Application specific settings can cause security or compatibility issues.
**If** there is a solid reason to expose the feature, then
anisgandoura commentedon Aug 2, 2021
Hello, thank you for your message.
The default signatures list is very different from what a usual Internet Browser (like Chrome or Firefox) displays.
Here is an example:
With Chrome I have:
SHA256/ECDSA, RSA_PSS_SHA256, SHA256/RSA, SHA384/ECDSA, RSA_PSS_SHA384, SHA384/RSA, RSA_PSS_SHA512, SHA512/RSA
With default SSL settings:
SHA256/ECDSA, SHA384/ECDSA, SHA512/ECDSA, Ed25519, Ed448, Unknown (0x8)/Unknown (0x9), Unknown (0x8)/Unknown (0xa), Unknown (0x8)/Unknown (0xb), RSA_PSS_SHA256, RSA_PSS_SHA384, RSA_PSS_SHA512, SHA256/RSA, SHA384/RSA, SHA512/RSA, SHA224/ECDSA, SHA1/ECDSA, SHA224/RSA, SHA1/RSA, SHA224/DSA, SHA1/DSA, SHA256/DSA, SHA384/DSA, SHA512/DSA
You can use this website for testing: https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html
We are building a security suite in Python to protect websites from DDOS attacks and we are not able to run "Chrome like" tests due to this limitation.
ramikg commentedon Oct 1, 2021
As a side note, while the ideal solution would be for Python to expose the appropriate API, there exists a hacky solution using ctypes:
https://github.com/ramikg/ssl-context-configurator
bantu commentedon May 2, 2023
@tiran
One of our applications needs to support two types of TLS connections:
i) Connections made to web resources. In this case, using the Python defaults is fine.
ii) Connections made using a TLS-based protocol with its own specification. In order to be spec-compliant, we need to explicitly enforce: TLS version, ciphersuites, ECDHE curves (e.g. BrainpoolP256r1 is mandatory), handshake signature algorithms, compression, renegotiation, etc.
I don't see how that approach could be used to support i) and ii) within the same application.
pinterior commentedon Mar 14, 2025
At least one embedded SSL library rejects signature_algorithms extension with more than 16 elements, which can occur with the current default settings.
This compatibility issue can be avoided by setting maximum_version to TLSv1_1, but it would be better to have an alternative solution.
ronf commentedon Sep 8, 2025
The changes mentioned in #138252 to get/set signature algorithms are now merged into python:main.