Fwd: PEP 3156: getting the socket or peer name from the transport
It's been a few years so my memory must be rusty, but where is the https protocol dependent on the transport/SSL setup in that way? Sent from my iPad Begin forwarded message:
From: Umbrella Code
Date: January 27, 2013, 9:06:48 AM PST To: Guido van Rossum Subject: Re: [Python-ideas] PEP 3156: getting the socket or peer name from the transport It's been a few years so my memory must be rusty, but where is the https protocol dependent on the transport/SSL setup in that way?
Sent from my iPad
On Jan 27, 2013, at 8:28 AM, Guido van Rossum
wrote: On Sun, Jan 27, 2013 at 4:16 AM, Antoine Pitrou
wrote: Le dimanche 27 janvier 2013 à 14:12 +0200, Yuval Greenfield a écrit :
On Sun, Jan 27, 2013 at 1:21 PM, Antoine Pitrou
wrote: Most protocols should be written independent of transport. But it seems to me that a user might write an entire app as a "protocol".
Well, such an assumption can fall flat. For example, certificate checking in HTTPS expects that the transport is some version of TLS or SSL: http://tools.ietf.org/html/rfc2818.html#section-3.1
I'm not sure I understood your reply. You'd be for an api that exposes the underlying transport? I meant to thsay that "an entire app" entails control over the subtleties of the underlying transport. What I meant is that the HTTP protocol needs to know that it is running over a secure transport, and it needs to fetch the server certificate from that transport (or, alternatively, it needs to have one of its callbacks called by the transport when the certificate is known). That's not entirely transport-agnostic.
Yeah, it sounds like in the end having access to the socket itself (if there is one) may be necessary. I suppose there are a number of different ways to handle that specific use case, but it seems clear that we can't anticipate all use cases. I'd rather have a simpler abstraction with an escape hatch than attempting to codify more use cases into the abstraction. We can always iterate on the design after Python 3.4, if there's a useful generalization we didn't anticipate.
-- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On Sun, Jan 27, 2013 at 7:11 PM, Umbrella Code
It's been a few years so my memory must be rusty, but where is the https protocol dependent on the transport/SSL setup in that way?
Sent from my iPad
Begin forwarded message:
I can't speak for Antoine but I'm guessing he's talking about SNI: * a VPS server hosts 2 sites with 2 certificates for "mysite.com" and " yoursite.com" * the original TCP server has no idea which cert to use as both sites share the same IP address and port. * the solution is the client sends the hostname in the TLS handshake. So the DNS or HTTP line "host: mysite.com" is also used in the TLS layer. This example agrees with Antoine but it's in the reverse direction, so maybe he has another one in mind. http://en.wikipedia.org/wiki/Transport_Layer_Security#Support_for_name-based... http://en.wikipedia.org/wiki/HTTP_Secure#Limitations http://en.wikipedia.org/wiki/Server_Name_Indication Yuval
Thanks Yuval, that's a good example and explanation.
Sent from my iPad
On Jan 27, 2013, at 9:41 AM, Yuval Greenfield
On Sun, Jan 27, 2013 at 7:11 PM, Umbrella Code
wrote: It's been a few years so my memory must be rusty, but where is the https protocol dependent on the transport/SSL setup in that way?
Sent from my iPad
Begin forwarded message:
I can't speak for Antoine but I'm guessing he's talking about SNI:
* a VPS server hosts 2 sites with 2 certificates for "mysite.com" and "yoursite.com" * the original TCP server has no idea which cert to use as both sites share the same IP address and port. * the solution is the client sends the hostname in the TLS handshake.
So the DNS or HTTP line "host: mysite.com" is also used in the TLS layer. This example agrees with Antoine but it's in the reverse direction, so maybe he has another one in mind.
http://en.wikipedia.org/wiki/Transport_Layer_Security#Support_for_name-based... http://en.wikipedia.org/wiki/HTTP_Secure#Limitations http://en.wikipedia.org/wiki/Server_Name_Indication
Yuval
Could it be handled as a context given to the protocol, and maybe accommodate the other information we'd been discussing? Ultimately the socket could also be part of the context information available as the escape hatch, but generally pre-populated to buffer from hardware. It could include address information, SSL data assigned by the server, etc. Populating it at the right places could also be more efficient.
Sent from my iPad
On Jan 27, 2013, at 9:41 AM, Yuval Greenfield
On Sun, Jan 27, 2013 at 7:11 PM, Umbrella Code
wrote: It's been a few years so my memory must be rusty, but where is the https protocol dependent on the transport/SSL setup in that way?
Sent from my iPad
Begin forwarded message:
I can't speak for Antoine but I'm guessing he's talking about SNI:
* a VPS server hosts 2 sites with 2 certificates for "mysite.com" and "yoursite.com" * the original TCP server has no idea which cert to use as both sites share the same IP address and port. * the solution is the client sends the hostname in the TLS handshake.
So the DNS or HTTP line "host: mysite.com" is also used in the TLS layer. This example agrees with Antoine but it's in the reverse direction, so maybe he has another one in mind.
http://en.wikipedia.org/wiki/Transport_Layer_Security#Support_for_name-based... http://en.wikipedia.org/wiki/HTTP_Secure#Limitations http://en.wikipedia.org/wiki/Server_Name_Indication
Yuval
participants (2)
-
Umbrella Code
-
Yuval Greenfield