> Yes, you're right. Of course, STARTTLS is properly regarded as a > terrible hack :-).
I know you mean that jokingly - but I think it is considered as the *proper* usage of TLS, with all these "let's use a different well-known port for TLS over X" being those protocols that are hacks. I believe it's official IETF policy (although I can't find the RFC right now) that future protocols should prefer connection upgrades for TLS over introducing separate protocols. > The actual functionality exported from _ssl.c is still the "ssl" > wrapper, but with more arguments to control its behavior. So to do > STARTTLS, server-side, you'd do something like > > mooring = socket.socket() > mooring.bind() > mooring.listen() > [... connection request comes in ...] > fd = mooring.accept() # normal socket > [... read request for TLS upgrade over socket ...] > sslobj = socket.ssl(fd, ..., server=True) > fd = socket.SSLSocket(..., ssl_protocol=PROTOCOL_TLSv1, _sock=fd, > _sslobj=sslobj) > > and continue on with normal use of the socket. Do you see an easier > way to do it? If you have use cases where you need to pass _sock, anyway, why not always require a wrapper object (i.e. not support the family/type/proto arguments). I think there are also cases where you need to set socket options on the "raw" socket. I view TLS as a wrapper around / layer on top of TCP, and so I think the API should look like, as well. Whatever you design, it will either be complicated to use or insufficient in reasonable use cases. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
