Author colinmarc
Recipients colinmarc
Date 2012-03-05.20:20:58
SpamBayes Score 5.84623e-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:02colinmarcsetrecipients: + colinmarc
2012-03-05 20:21:01colinmarcsetmessageid: <1330978861.96.0.148487272162.issue14204@psf.upfronthosting.co.za>
2012-03-05 20:21:01colinmarclinkissue14204 messages
2012-03-05 20:21:00colinmarccreate