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 <[email protected]>: > > On Wed, Jun 17, 2015 at 8:21 AM, Stefan Eissing > <[email protected]> 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 > [email protected] <green/>bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
