Add ssl.CERT_REQUIRED_NO_VERIFY as possible value for ssl.SSLContext.verify_mode

[freundTech]

BPO	46779
Nosy	@tiran, @freundTech

^{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 2022-02-17.16:53:40.117>
labels = ['expert-SSL', 'type-feature', '3.11']
title = 'Add ssl.CERT_REQUIRED_NO_VERIFY as possible value for ssl.SSLContext.verify_mode'
updated_at = <Date 2022-02-17.16:53:40.117>
user = 'https://github.com/freundTech'

bugs.python.org fields:

activity = <Date 2022-02-17.16:53:40.117>
actor = 'freundTech'
assignee = 'christian.heimes'
closed = False
closed_date = None
closer = None
components = ['SSL']
creation = <Date 2022-02-17.16:53:40.117>
creator = 'freundTech'
dependencies = []
files = []
hgrepos = []
issue_num = 46779
keywords = []
message_count = 1.0
messages = ['413416']
nosy_count = 2.0
nosy_names = ['christian.heimes', 'freundTech']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue46779'
versions = ['Python 3.11']

[freundTech]

Some networked applications might require connecting to client with invalid certificates but still requiring the client to send a certificate.

ssl.SSLContext.verify_mode currently supports the following options:
ssl.CERT_NONE: Don't require the client to send a certificate and don't validate it if they send one anyways.
ssl.CERT_OPTIONAL: Don't require the client to send a certificate but validate it if they send one.
ssl.CERT_REQUIRED: Require the client to send a certificate and validate it.

There is currently no option for servers that want to require the client to send a certificate but don't validate it.

This would for example be needed it a server should accept clients with self-signed certificates and then store their certificates to recognize them again later.

A concrete example is the KDEConnect protocol.

An alternative solution would be bpo-31242. That would also solve this problem is a more general, but also more complicated way.

I think that the solution proposed here this issue is better for it's simplicity and also solves most usecases for bpo-31242.

Note that a ssl.CERT_REQUIRED_NO_VERIFY was already proposed in bpo-18293, but that issue was closed because it was specifically in relation to a deprecated api. The mentioned values are however also used in modern asyncio apis.