QUIC/HTTP3 seems not working on my WLAN

1. The problem I’m having:

Hi, im trying to use a custom Version of QUIC, forked by me from the original go-quic repo. I don’t know if this is possible. I am kinda new with Caddy. I am trying to set up a Caddy server in my wlan where i can access to my local server from the other device. I am having problem with the certificate and with the setup for the use of QUIC.
I start reading doc and following other post in the community about the use of http3 and other.
My question is about how implement a Caddy server that use QUIC/http3 and futhermore use my custum version of the official Quic repo.

Using Wireshark i saw that isnt using QUIC but only TCP and TLS1.3

2. Error messages and/or full log output:

menny@menny ~/D/r/caddy (main)> sudo caddy run --config Caddyfile
2024/05/06 16:50:37.011	INFO	using provided configuration	{"config_file": "Caddyfile", "config_adapter": ""}
2024/05/06 16:50:37.018	INFO	admin	admin endpoint started	{"address": "localhost:2019", "enforce_origin": false, "origins": ["//localhost:2019", "//[::1]:2019", "//127.0.0.1:2019"]}
2024/05/06 16:50:37.019	INFO	tls.cache.maintenance	started background certificate maintenance	{"cache": "0xc0003bbb80"}
2024/05/06 16:50:37.022	WARN	tls	stapling OCSP	{"error": "no OCSP stapling for [localhost]: no OCSP server specified in certificate"}
2024/05/06 16:50:37.022	INFO	http.auto_https	enabling automatic HTTP->HTTPS redirects	{"server_name": "srv0"}
2024/05/06 16:50:37.023	INFO	http	enabling HTTP/3 listener	{"addr": ":443"}
2024/05/06 16:50:37.023	INFO	http.log	server running	{"name": "srv0", "protocols": ["h1", "h2", "h3"]}
2024/05/06 16:50:37.024	INFO	http.log	server running	{"name": "remaining_auto_https_redirects", "protocols": ["h1", "h2", "h3"]}
2024/05/06 16:50:37.024	INFO	autosaved config (load with --resume flag)	{"file": "/root/.local/share/caddy/autosave.json"}
2024/05/06 16:50:37.024	INFO	serving initial configuration
2024/05/06 16:50:37.028	WARN	tls	storage cleaning happened too recently; skipping for now	{"storage": "FileStorage:/root/.local/share/caddy", "instance": "dd39ef14-e4fe-4e38-b3ef-cdaa34068d4f", "try_again": "2024/05/07 16:50:37.028", "try_again_in": 86399.999998518}
2024/05/06 16:50:37.028	INFO	tls	finished cleaning storage units


3. Caddy version:

v2.7.6

4. How I installed and ran Caddy:

I followed this guide

a. System environment:

Ubuntu 22.04 LTS, no docker.

b. Command:

sudo caddy run --config Caddyfile

d. My complete Caddy config:

:443 {
	tls cert.pem key.pem
	respond "Hello, HTTP/3!"
}

5. Links to relevant resources:

You should test with curl -Lv --http3 https://xxxxx. It may be that your udp port isnt open in firewall or properly forwarded.

3 Likes

Thanks for responding,

This is the output

menny@menny ~/D/r/caddy (main)> curl -Lv --http3 https://10.42.0.1
*   Trying 10.42.0.1:443...
* QUIC cipher selection: TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_CCM_SHA256
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* SSL certificate problem: self-signed certificate
* QUIC connect to 10.42.0.1 port 443 failed: SSL peer certificate or SSH remote key was not OK
* Failed to connect to 10.42.0.1 port 443 after 98 ms: SSL peer certificate or SSH remote key was not OK
*   Trying 10.42.0.1:443...
* Connected to 10.42.0.1 (10.42.0.1) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self-signed certificate
* Closing connection
curl: (60) SSL certificate problem: self-signed certificate
More details here: https://curl.se/docs/sslcerts.html

Instead if i add the --insecure option in the curl command all works fine.

menny@menny ~/D/r/caddy (main)> curl -Lv --http3 --insecure https://10.42.0.1
*   Trying 10.42.0.1:443...
* QUIC cipher selection: TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_CCM_SHA256
*   Trying 10.42.0.1:443...
* Skipped certificate verification
* Connected to 10.42.0.1 (10.42.0.1) port 443
* using HTTP/3
* [HTTP/3] [0] OPENED stream for https://10.42.0.1/
* [HTTP/3] [0] [:method: GET]
* [HTTP/3] [0] [:scheme: https]
* [HTTP/3] [0] [:authority: 10.42.0.1]
* [HTTP/3] [0] [:path: /]
* [HTTP/3] [0] [user-agent: curl/8.7.1]
* [HTTP/3] [0] [accept: */*]
> GET / HTTP/3
> Host: 10.42.0.1
> User-Agent: curl/8.7.1
> Accept: */*
> 
* Request completely sent off
< HTTP/3 200 
< server: Caddy
< content-type: text/plain; charset=utf-8
< date: Tue, 07 May 2024 08:46:34 GMT
< content-length: 14
< 
* Connection #0 to host 10.42.0.1 left intact
Hello, HTTP/3!⏎  

As i expect auto-generate certificate can be a problem. But idk other method on how i can establish a HTTP3/QUIC connnection.

With the flag --insecure with Wireshark i capture the che correct QUIC handshake and packets.
So why with firefox and other browser send me to a TCP connection?
Maybe the certificate isn’t valid and the browser work as curl did without the flag --insecure.

Instead have u some advice to implement my own version of quic?

Quick Edit

I added the Certificate manually to the trusted browser certificate and seems QUIC is correctly working.

Thanks for ur respond.

Otherwise i don’t know how can i customize the QUIC functionality using a custom QUIC repo o custom Command that use QUIC module.

Browsers almost always try TCP first and only try UDP if they see the Alt-Svc header signaling that the server supports HTTP/3. Browsers don’t reliably choose HTTP/3, if they deem HTTP/2 to be fast enough they’ll just use that. Especially if you’re on your LAN, it’s so fast that it doesn’t need to.

There might be ways to configure the browser to force it to use HTTP/3, but this has nothing to do with Caddy, clearly HTTP/3 works as you can see from using curl.

1 Like

Thanks, i didnt know that.

Really Helpfull.

Maybe you know how to force the browser on use HTTP/3 when possible?

1 Like

There is a HTTPS DNS record that can be used to tell browsers that this domain has a https support as well as supported protocol versions via alpn="h3,h2,http/1.1". This can be improved with ipv4hint="1.2.3.4" ipv6hint="1234:4567::1"

https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/

Apparently this became RFC 9460, but it’s still poorly supported by browsers. See Add support for DNS RRs, like HTTPS and SVCB · Issue #6091 · Fyrd/caniuse · GitHub and this article detailing it Use of HTTPS Resource Records

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.