On Wed, Nov 18, 2015 at 5:19 AM, Bert Huijben <[email protected]> wrote:
> Hi William, > > > > Is any commonly used client actually implementing this spec in a way that > makes this RFC relevant for httpd? > > Note httpd already implements this correctly, it's simply a matter of not breaking it. My quick checks indicate that 2.4.18-dev is working well. Next check is the protocols patch in the queue. My checks with -starttls ftp indicate we broke mod_ftp auth over explicit tls connections some time back in 2.4.13-dev when we had fixed error document response to speaking plain http over https. Need to see how many other ways mod_ftp tls has been corrupted recently, but will probably leverage mod_ssl's internal upgrade handling for the mod_ftp use case. The major peering for this upgrade logic has been CUPS printing. Outside of this case there has been fairly little traction. SNI and ALPN both solve issues that this spec was designed to solve (host, then tls handshake, upgrade to a specific protocol etc). What it now solves is limited to consolidating on port 80, and very few clients ever picked this up. > Sure we could implement this… Perhaps we already did but once you switch > to TLS there are so many security related things to account for. > > > > Ignoring the server certificate case, what about SNI and ALPN? > > > > Is there really a specific upgrade to tls/1.0, 1.1 and 1.2. Or is one > upgrade enough as the handshake does the rest. > The spec suggests it is called out, but you are correct, in this tool we begin at the appropriate -tls1_2 provided (fixing Yann's observation) but perform a normal handshake. Does this also allow switching to http/2 in one step via ALPN? > > > > Or is that explicitly forbidden? > There is an interesting thread http://www.ietf.org/mail-archive/web/httpbisa/current/msg24147.html and further discussion about ALPN vs Upgrade and the coexistence of the two schemas.
