Change default signature algorithms for context in the ssl library

[anisgandoura]

BPO	44811
Nosy	@tiran, @anisgandoura, @ramikg
PRs	bpo-44811: Set Signature Algorithms for a given SSL Context #27550

^{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']

[anisgandoura]

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]

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

• the API should be modeled after SSLContext.set_alpn_protocols() and accept a sequence of strings.
• the API should also be able to return currently enabled and perhaps currently available algorithms.
• the ssl module should get an enum of common algorithms with names based on IANA's TLS parameter list.
• the PR needs tests and documentation

[anisgandoura]

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]

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]

@tiran

Why should a Python application be able to modify the signature algorithms? The default settings are safe and sane.

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.

Security properties should rather be set system-wide with a crypto policy in OpenSSL's global config file.

I don't see how that approach could be used to support i) and ii) within the same application.

[pinterior]

Why should a Python application be able to modify the signature algorithms?

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]

The changes mentioned in #138252 to get/set signature algorithms are now merged into python:main.