Message154973
| Author |
colinmarc |
| Recipients |
colinmarc |
| Date |
2012年03月05日.20:20:58 |
| SpamBayes Score |
5.8462347e-06 |
| Marked as misclassified |
No |
| Message-id |
<1330978861.96.0.148487272162.issue14204@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Recent versions of OpenSSL (1.0.1 and greater) support a new extension to SSL/TLS called Next Protocol Negotiation, defined here: http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-02.
The extension allows servers and clients to advertise which protocols they support (for example, both HTTP and SPDY) and then agree on one during the handshake according to a simple algorithm.
This patch to 2.7 adds support for the NPN extension via another parameter to ssl.wrap_socket, called 'npn_protocols', and by using the OpenSSL API. It should fail gracefully if the linked version of OpenSSL has no support for NPN, using a macro guard. Once the handshake is completed, SSLSocket.selected_protocol() returns whatever was agreed upon.
Although I included client/server tests with the patch, testing this functionality in real-life situations proved difficult. Google chrome has SPDY and NPN functionality baked in, so I wrote a simple socket server that advertises SPDY/2 in addition to HTTP/1.1. Chrome, pointed at this server, correctly completed the handshake and started merrily sending SPDY control frames. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2012年03月05日 20:21:02 | colinmarc | set | recipients:
+ colinmarc |
| 2012年03月05日 20:21:01 | colinmarc | set | messageid: <1330978861.96.0.148487272162.issue14204@psf.upfronthosting.co.za> |
| 2012年03月05日 20:21:01 | colinmarc | link | issue14204 messages |
| 2012年03月05日 20:21:00 | colinmarc | create |
|