Le 07/11/2013 19:13, Christian Heimes a écrit :
Hi,
I'd like to simplify, unify and tighten SSL handling and verification
code in Python 3.5.
Therefore I propose to deprecate some features for
Python 3.4. SSLContext objects are going to be the central instance for
configuration.
In order to archive the goal I propose to
- deprecate the key_file, cert_file and check_hostname arguments in
various in favor of context. Python 3.5 will no longer have these
arguments in http.client, smtplib etc.
I'm in favour but I think 3.5 is too early. Keep in mind SSLContext is
quite young.
- deprecate implicit verify_mode=CERT_NONE. Python 3.5 will default
to CERT_REQUIRED.
-0.9. This breaks compatibility and doesn't achieve anything, since
there's no reliable story for CA certs.
- enforce hostname matching in CERT_OPTIONAL or CERT_REQUIRED mode
by default in Python 3.5.
Service matching is an application protocol level thing, it isn't
strictly part of SSL. I'd feel warmer if you removed the "by default" part.
- add ssl.get_default_context() to acquire a default SSLContext object
if the context argument is None. (Python 3.4)
I think I'm against it, for two reasons:
1. It will in the long term create compatibility and/or security issues
(we'll have to keep fragile legacy settings if we want to avoid breaking
existing uses of the default context)
2. SSLContexts are mutable, which means some code can affect other
code's behaviour without even knowing. It's a recipe for subtle bugs and
security issues.
Applications and/or higher-level libraries should be smart enough to
choose their own security preferences, and it's the better place to do
so anyway.
- add check_cert option to SSLContext and a check_cert() function to
SSLSocket in order to unify certificate validation and hostname
matching. (Python 3.4)
The check_cert() function wouldn't achieve anything besides calling
match_hostname(), right?
I'm against calling it check_cert(), it's too generic and only induces
confusion.
The SSLContext's check_cert option will support four values:
None (default)
use match_hostname() if verify_mode is CERT_OPTIONAL or
CERT_REQUIRED
True
always use match_hostname()
False
never use match_hostname()
What is the hostname that the cert is matched against?
callable function:
call func(sslsock, hostname, initiator, **kwargs)
The initiator argument is the object that has initiated the
SSL connection, e.g. http.client.HTTPSConnection object.
sslsock.context points to its SSLContext object
Where does the "hostname" come from?
And why is there an "initiator" object? Personally I prefer to avoid
passing opaque user data, since the caller can use a closure anyway.
And what are the **kwargs?
A connect method may look like this:
def connect(self):
hostname = self.hostname
s = socket.create_connection((hostname, self.port))
sock = self.context.wrap_socket(sock,
server_hostname=hostname)
sock.check_cert(hostname, initiator=self)
So what does this bring compared to the statu quo? I thought at least
sock.check_cert() would be called automatically, but if you have to call
it yourself it starts looking pointless, IMO.
Regards
Antoine.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
