httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: ALPN patch comments
Date Wed, 22 Apr 2015 16:45:59 GMT

> Am 22.04.2015 um 17:49 schrieb Kaspar Brand <httpd-dev.2014@velox.ch>:
> 
>> On 22.04.2015 10:52, Stefan Eissing wrote:
>> I made two small patches based on the feedback from Kaspar. One for
>> the code and one for the documentation.
> 
> Thanks. In the patch for ssl_private.h, the complete NPN block should
> actually be dropped - the same block is are already part of
> ssl_private.h, just 10 lines above

Yes. Not my change though. ;-)

>> However there are a lot of openssl 1.0.1 installations out there 
>> where httpd 2.4 is deployed which already talk NPN
> 
> "a lot of... which already talk NPN"? I have a bit a hard time in
> following this argument: since mod_ssl in 2.4 doesn't have NPN, this
> suggests that these installations currently rely on custom patches in
> any case - so I wouldn't expect there to be "a lot of" (or I might be
> missing the real point)

The openssl 1.0.1 which is out there talks NPN. That's what I meant. 

I understand your argument. My pov is of someone trying to bring http/2 to the people. While
bringing a new httpd on an existing system seems easy, installing a new system openssl is
more challenging with its dependencies and the changes in hiding non public parts of their
API. 

My original patch was replacing the mod_ssl NPN registration with the ALPN ones, but using
the NPN internally when linking against an openssl without ALPN. It was not completely hidden
since both work slightly different, though. 

Just my €0.02. I will be happy if "just" the ALPN parts make their way into the next 2.4.

//stefan


>> and it might take some time for getting ALPN support from the
>> distros. Which would mean more people building and deploying their
>> own SSL libraries/patching mod_ssl and having no auto update, if they
>> want to use SPDY or HTTP/2.
> 
> I don't find this reasoning very convincing... if we look at
> distributions with long term support (which is the sort of thing to
> consider for running a production HTTP server), then we see that they
> are now at 2.4.6 (RHEL), 2.4.7 (Ubuntu), 2.4.10 (SLES) or similar. And
> they usually stay with these versions for the whole OS release lifetime,
> only security fixes are backported (new features only in exceptional
> cases). I.e., it's highly unlikely that admins could rely on the
> vendor-supplied httpd package to get NPN in the next, say, 12 months.
> "auto update" typically means "security fixes only".
> 
> OTOH, if a distributor is really going from 2.4.x to 2.4-latest this or
> next year, then I'd say that chances are quite high that he also
> upgrades to OpenSSL 1.0.2 at the same time (in particular given the
> increased pace for new OpenSSL releases and the faster EOL timelines,
> see https://www.openssl.org/about/releasestrat.html).
> 
> For me the time seems right to rip NPN out of trunk and only backport
> the ALPN code to 2.4.
> 
> Kaspar

Mime
View raw message