Enable http3 for a subset of domains

Thu Jun 27 10:26:13 UTC 2024

Hi,

> On 27 Jun 2024, at 10:17 AM, Riccardo Brunetti Host <riccardo.brunetti at host.it> wrote:
> 
> 
> 
>> On 26 Jun 2024, at 17:56, Roman Arutyunyan <arut at nginx.com <mailto:arut at nginx.com>> wrote:
>> 
>> Hi,
>> 
>>> On 26 Jun 2024, at 7:21 PM, Riccardo Brunetti Host <riccardo.brunetti at host.it <mailto:riccardo.brunetti at host.it>> wrote:
>>> 
>>> Hello, thanks for the answer.
>>> 
>>>> On 26 Jun 2024, at 16:45, Roman Arutyunyan <arut at nginx.com <mailto:arut at nginx.com>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>>> On 26 Jun 2024, at 6:15 PM, Riccardo Brunetti Host <riccardo.brunetti at host.it <mailto:riccardo.brunetti at host.it>> wrote:
>>>>> 
>>>>> Hello.
>>>>> 
>>>>> I have a Nginx server which acts as a reverse proxy for a given number of different domains and I’m trying to enable http3 for a subset of them.
>>>>> 
>>>>> I placed the directives:
>>>>> 
>>>>>>     http3 on;
>>>>>>     listen xx.xx.xx.xx:443 default_server quic reuseport;
>>>>>>     quic_retry on;
>>>>> 
>>>>> in the default.conf file and then, only for those domains which I want http3 enabled I also add in the corresponding virtual host:
>>>>> 
>>>>>>         http3 on;
>>>>>>         listen xx.xx.xx.xx:443 quic;
>>>>>>         quic_retry on;
>>>>> 
>>>>> In the server section and 
>>>>> 
>>>>>> add_header Alt-Svc 'h3=":8443"; ma=86400';
>>>>> 
>>>>> Inside the location.
>>>>> 
>>>>> Now, what happens is that if I try to open the sites *with* http3 enabled, everything works as expected. If I try to open a site *without* http3 enabled, sometimes I have an SSL error because the server returns the “default virtual host” certificate.
>>>>> It seems related to the type of browser.
>>>>> 
>>>>> Is it an expected behaviour or I am doing something wrong with the server configuration?
>>>> 
>>>> If you use http/3 to access a virtual server that does not support http/3, the default http/3 server will be used.
>>>> 
>>>> Make sure the above add_header does not affect the servers which do not support http/3.
>>> 
>>> I add the header above only on the virtual hosts which I want to support http/3, thus it should not interfere with the other non http/3 domains.
>>> Nevertheless, if I try with curl:
>>> 
>>> 1) Site http/3 enabled:
>>> 
>>>> # curl --http3 -I -v https://<fqdn>
>>>> * Host <fqdn>t:443 was resolved.
>>>> * IPv6: (none)
>>>> * IPv4: <ip>
>>>> * WARNING: no socket in pollset, transfer may stall!
>>>> *   Trying <ip>:443...
>>>> * Server certificate:
>>>> *  subject: CN=<fqdn>
>>>> *  start date: May 14 07:39:37 2024 GMT
>>>> *  expire date: Aug 12 07:39:36 2024 GMT
>>>> *  subjectAltName: host “<fqdn>" matched cert's “<fqdn>"
>>>> *  issuer: C=US; O=Let's Encrypt; CN=R3
>>>> *  SSL certificate verify ok.
>>>> * Connected to <fqdn> (<ip>) port 443
>>>> * using HTTP/3
>>>> * [HTTP/3] [0] OPENED stream for https://<fqdn>/
>>> …
>>> …
>>> 
>>> So it gets the correct certificate and it goes on using http/3
>>> 
>>> 2) Site non http/3 enabled:
>>> 
>>>> # curl --http3 -I -v https://<fqdn>
>>> 
>>>> * Host <fqdn>:443 was resolved.
>>>> * IPv6: (none)
>>>> * IPv4: <ip>
>>>> * WARNING: no socket in pollset, transfer may stall!
>>>> *   Trying <ip>:443...
>>>> * SSL certificate problem: unable to get local issuer certificate
>>>> * connect to <ip> port 443 failed: SSL peer certificate or SSH remote key was not OK
>>>> * Failed to connect to<fqdn> port 443 after 33 ms: SSL peer certificate or SSH remote key was not OK
>>>> *   Trying <ip>:443...
>>>> * Connected to<fqdn> (<ip>) port 443
>>>> * ALPN: curl offers h2,http/1.1
>>>> * TLSv1.2 (OUT), TLS handshake, Client hello (1):
>>>> * TLSv1.2 (IN), TLS handshake, Server hello (2):
>>>> * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
>>>> * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
>>>> * TLSv1.3 (IN), TLS handshake, Certificate (11):
>>>> * TLSv1.3 (IN), TLS handshake, CERT verify (15):
>>>> * TLSv1.3 (IN), TLS handshake, Finished (20):
>>>> * TLSv1.3 (OUT), TLS handshake, Finished (20):
>>>> * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF
>>>> * ALPN: server accepted h2
>>>> * Server certificate:
>>>> *  subject: CN=<fqdn>
>>>> *  start date: Apr 16 08:36:25 2024 GMT
>>>> *  expire date: Jul 15 08:36:24 2024 GMT
>>>> *  subjectAltName: host "<fqdn>" matched cert's "<fqdn>"
>>>> *  issuer: C=US; O=Let's Encrypt; CN=R3
>>>> *  SSL certificate verify ok.
>>>> * using HTTP/2
>>>> * [HTTP/2] [1] OPENED stream for https://<fqdn>/
>>> 
>>> 
>>> So it tries with http/3, gets a wrong certificate (the server default one), then it switches to http/2 and goes on. 
>>> The first attempt with http/3 probably gives problems with some browsers?
>>> If this is the case, is there a way to avoid this or should I simply configure http/3 on all domains?
>> 
>> Why would you (or client) connect to an http/3 port for a server which does not support http/3?
>> What would be your expectation in this case? The same will happen for http/1 and http/2 as well.
>> You can connect to an http/1 ssl port, request a missing server and receive a default server certificate.
>> It's just there is no fallback for http/1 and client will just give up.
>> 
>> The add_header suggests that http/3 is supported for a certain server.
>> It should not be sent for servers which do not support http/3, and clients should not use http/3 for them.
> 
> I agree with you, mine was an example just to show with curl what seems to happen with some browsers.
> It seems to me that they try http/3 even if the server doesn’t advertise the header and then stop because of the error on the certificate.
> I don’t know if this is something known.
> Anyway, I think I will bypass this by enabling http/3 on all sites.

One more thing you can do is to reject handshake for default server:

https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_reject_handshake

> 
> Thanks a lot for you help
> 
> Riccardo 
> 
>> 
>>>> If it does, this will mislead clients by offering them to switch to unsupported http/3.
>>>> 
>>>>> Nginx version: nginx/1.26.1 on ubuntu 22.04
>>>>> 
>>>>> Thanks.
>>>>> Riccardo
>>>>> _______________________________________________
>>>>> nginx mailing list
>>>>> nginx at nginx.org <mailto:nginx at nginx.org>
>>>>> https://mailman.nginx.org/mailman/listinfo/nginx
>>>> 
>>>> ----
>>>> Roman Arutyunyan
>>>> arut at nginx.com <mailto:arut at nginx.com>
>>>> 
>>> 
>>> Riccardo
>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> nginx mailing list
>>>> nginx at nginx.org <mailto:nginx at nginx.org>
>>>> https://mailman.nginx.org/mailman/listinfo/nginx
>>> 
>>> _______________________________________________
>>> nginx mailing list
>>> nginx at nginx.org <mailto:nginx at nginx.org>
>>> https://mailman.nginx.org/mailman/listinfo/nginx
>> 
>> ----
>> Roman Arutyunyan
>> arut at nginx.com <mailto:arut at nginx.com>
>> 
>> 
>> 
>> 
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org <mailto:nginx at nginx.org>
>> https://mailman.nginx.org/mailman/listinfo/nginx
> 
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx

----
Roman Arutyunyan
arut at nginx.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20240627/8ca8da8f/attachment.htm>