> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4