On 2015/12/02 14:53, Uwe Werler wrote: > On 25. Nov 8:02:17, Stuart Henderson wrote: > > On 2015-11-24, Uwe Werler <uwe.wer...@retiolum.eu> wrote: > > > Hello, > > > > > > I'm just testing ssl interception and noticed the following problem. > > > Sometimes the Subject/Subject Alternative Name of the cert is altered > > > with a different name than the one the original cert has: > > > > When relayd connects to the server to find out what names to use in > > the subject/SAN, it doesn't send the requested hostname (SNI) in > > the ClientHello, so it only has the information from the server's > > "default" certificate to include in the new generated certificate. > > > > You can see this for yourself with openssl s_client -connect hostname:443 > > compared with openssl s_client -connect hostname:443 -servername hostname. > > > > Hello Stuart, > > thanks! Ok, got it. > > Only for my understanding: is there a reason (probably security related?) for > not using the host name from ClientHello in relayd for fetching the target > cert? > > And if not - is it planned to implement it in relayd? > > Thanks in advance! > > Regards Uwe
AFAIK it's just not implemented yet, I don't see a security reason for not doing this. (if you need this now, squid can do it, but config is more complex - there's also sslsplit in ports but that's not really a normal proxy). Setting a hostname in an outgoing request is pretty simple (SSL_set_tlsext_host_name) but you need to get it from the request first and that's a little more complicated, afaik you need to setup a callback (with SSL_CTX_set_tlsext_servername_callback and SSL_CTX_set_tlsext_servername_arg) to point at a function which will do a SSL_get_tlsext_host_name call to fetch the hostname and store it for later use in the request.
