Re: Host mismatch SNI?
Date: Fri, 8 May 2020 15:59:01 -0400
On Fri, May 8, 2020 at 3:35 PM Jeffrey Walton <noloader_at_gmail.com> wrote:
>
> On Fri, May 8, 2020 at 3:20 PM Felipe Gasper via curl-library
> <curl-library_at_cool.haxx.se> wrote:
> >
> > Is it possible with libcurl to send an HTTP/1.1 request whose Host header mismatches the TLS SNI string?
> >
> > Also, if anyone knows: what are the “perils” of making such a request? Does Apache or nginx reject such requests?
>
> I don't know how to do it with cURL.
>
> With OpenSSL, the test is fairly simple:
>
> $ echo -e 'GET HTTP/1.1\r\nHost:foo.bar\r\n\r/n' | openssl s_client
> -connect www.google.com:443 -servername www.google.com -CAfile
> /etc/cacerts/cacert.pem
> CONNECTED(00000005)
> depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
> verify return:1
> depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1
> verify return:1
> depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN
> = www.google.com
> verify return:1
> ...
>
> What is happening above is, at the network level, SNI is being used to
> setup the TLS channel via -servername. Then, at the application layer,
> a HTTP request is being made on foo.bar. By the time the HTTP header
> is seen the TLS channel is already setup. The HTTP server (at the
> application layer) will do what it wants in response to the incorrect
> Host: header.
My bad... That should be 'GET / HTTP/1.1'.
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-05-08