sni+alpn, vhost+certs

[Stefan Eissing <st...@greenbytes.de>]

Seems like a good idea to not place the ALPN patches into 2.4 - yet.

During my tests, I discovered that the order of my vhost definitions affected the certificate chosen - when ALPN was in play. After some analysis, the following seems to occur. This is to make the mod_ssl people here aware and get their opinion on a workaround.

1. connection, setup for base server and defaults
2. client hello arrives
3. ALPN callback is invoked by openssl
4. ALPN protocol is chosen, this triggers the server answer
5. SNI callback is invoked by openssl and sets up vhost info and configs
6. Oops.

Lacking the SNI name and vhost setups, the sendback in 4 seems to fallback to the default vhost selection and that certificate is used to answer the call.

The issue has been reported by me on the openssl dev list. As a workaround for now and compatibility to older openssl versions, I propose to add to the ALPN patch something that
a) checks in ALPN callback if vhost has been setup by SNI callback
b) if not, retrieves SNI servername via SSL_get_servername()
c) if servername is returned, setup vhost just like in SNI callback
d) if SNI callback is invoked and vhost has been setup already, nop

Sounds reasonable?

//Stefan

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: sni+alpn, vhost+certs

[Yann Ylavic <yl...@gmail.com>]

On Thu, Jun 18, 2015 at 11:07 AM, Stefan Eissing
<st...@greenbytes.de> wrote:
>
> It retrieves SNI servername via ssl_var_lookup, creates a fake request_rec
> incokes ap_update_vhost_from_headers().
>
> Not very elegant.
>
> a) is there another way?

Maybe define a new ap_get_vhost_from_name() and use it in both
ap_update_vhost_from_headers() and your code.

> b) if not, should the server_rec be a parameter to the alpn callback functions

If that's enough, it looks like a simpler change, though.

> c) or, alternatively, should the conn_rec carry that information somewhere?

Such a base struct is not very easy to change without breaking
compatibility (ABI), that would make any backport to 2.4.x less
acceptable...

Regards,
Yann.

Re: sni+alpn, vhost+certs

[Stefan Eissing <st...@greenbytes.de>]

I have a patch for this now, but discovered that mod_h2 needs some more:

In the ALPN propose callback, the module needs to know which vhost the
connection is about. And not only that, it needs the server_rec of that
to check its config. If the module is disabled in that vhost, it should
not propose anything.

Since mod_ssl stores the selected server only in its internal context and
leaves the base server at the conn_rec untouched, mod_h2 has to make
a workaround to get it.

It retrieves SNI servername via ssl_var_lookup, creates a fake request_rec
incokes ap_update_vhost_from_headers(). 

Not very elegant.

a) is there another way?
b) if not, should the server_rec be a parameter to the alpn callback functions
c) or, alternatively, should the conn_rec carry that information somewhere?

Thanks for the help.


> Am 17.06.2015 um 14:23 schrieb Eric Covener <co...@gmail.com>:
> 
> On Wed, Jun 17, 2015 at 8:21 AM, Stefan Eissing
> <st...@greenbytes.de> wrote:
>> 1. connection, setup for base server and defaults
>> 2. client hello arrives
>> 3. ALPN callback is invoked by openssl
>> 4. ALPN protocol is chosen, this triggers the server answer
>> 5. SNI callback is invoked by openssl and sets up vhost info and configs
>> 6. Oops.
>> 
>> Lacking the SNI name and vhost setups, the sendback in 4 seems to fallback to the default vhost selection and that certificate is used to answer the call.
>> 
>> The issue has been reported by me on the openssl dev list. As a workaround for now and compatibility to older openssl versions, I propose to add to the ALPN patch something that
>> a) checks in ALPN callback if vhost has been setup by SNI callback
>> b) if not, retrieves SNI servername via SSL_get_servername()
>> c) if servername is returned, setup vhost just like in SNI callback
>> d) if SNI callback is invoked and vhost has been setup already, nop
>> 
>> Sounds reasonable?
> 
> 
> Seems fair
> 
> -- 
> Eric Covener
> covener@gmail.com

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: sni+alpn, vhost+certs

[Eric Covener <co...@gmail.com>]

On Wed, Jun 17, 2015 at 8:21 AM, Stefan Eissing
<st...@greenbytes.de> wrote:
> 1. connection, setup for base server and defaults
> 2. client hello arrives
> 3. ALPN callback is invoked by openssl
> 4. ALPN protocol is chosen, this triggers the server answer
> 5. SNI callback is invoked by openssl and sets up vhost info and configs
> 6. Oops.
>
> Lacking the SNI name and vhost setups, the sendback in 4 seems to fallback to the default vhost selection and that certificate is used to answer the call.
>
> The issue has been reported by me on the openssl dev list. As a workaround for now and compatibility to older openssl versions, I propose to add to the ALPN patch something that
> a) checks in ALPN callback if vhost has been setup by SNI callback
> b) if not, retrieves SNI servername via SSL_get_servername()
> c) if servername is returned, setup vhost just like in SNI callback
> d) if SNI callback is invoked and vhost has been setup already, nop
>
> Sounds reasonable?


Seems fair

-- 
Eric Covener
covener@gmail.com