caddy: Doesn't seem possible to disable ALPN
Hello again. Caddy’s ALPN configuration is a part of TLS connection policy. I would like to be able to turn it off, which is to say, pass an empty uh… this thing to golang stdlib:
// NextProtos is a list of supported application level protocols, in // order of preference. If both peers support ALPN, the selected // protocol will be one from this list, and the connection will fail // if there is no mutually supported protocol. If NextProtos is empty // or the peer doesn’t support ALPN, the connection will succeed and // ConnectionState.NegotiatedProtocol will be empty. NextProtos []string
Unfortunately, I don’t seem to be able to do this, because of this line (58): https://github.com/caddyserver/caddy/blob/2b3046de36bad70bd7e48478c99a8a030fb35b98/modules/caddytls/connpolicy.go#L56-L59
Maybe allow passing null explicitly as value for "alpn": json key?
In any case it doesn’t say in the documentation that empty array means default values: https://caddyserver.com/docs/json/apps/http/servers/tls_connection_policies/alpn/
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 38 (17 by maintainers)
Commits related to this issue
- Check for nil ALPN; close #5470 — committed to caddyserver/caddy by mholt a year ago
- Check for nil ALPN; close #5470 — committed to caddyserver/caddy by mholt a year ago
I’ll be happy to explain further. As I’ve said I use Caddy as a universal TLS termination endpoint with built-in certificate management. Suppose there’s an existing client-server communication in use – I don’t know, Postgres replication. Both the client and the server know the next protocols they want (we assume ALPN is in use, otherwise the example doesn’t work). Client lists its protocols, server checks if there’s an intersection with its protocols. Crucially, if there isn’t one, server closes the connection and doesn’t allow the client in – that’s how ALPN works.
Now I need to proxy this connection through Caddy. I can’t realistically modify the client to require it to not send ALPN anymore. I can’t realistically go through every such connection, list every protocol they use, and then maintain this list in the future, it’s just too much of a hassle. Now we’re at an impasse: the client sends ALPN list, but the server – Caddy – doesn’t know what to do with it. Caddy will not accept the client’s connection, unless the client happens to request http/1.1 and/or h2. As a side note, Caddy will accept h2 even if it can’t serve it later in the handlers – it manifests as an empty answer, and I believe you have had issues with this already.
There’s a really simple test case:
$ openssl s_client -alpn something -connect .... Try to serve it without explicitly configuring"alpn": ["something"].As for testing new logic, I’m afraid it would be difficult for me. I’m not at all a golang developer. I was able to hack around, and even made my own plugin, but it took me several days to build Caddy with it. I can of course edit the file, but I don’t know what to do with this edited file, and golang proficiency is not among my life goals. That said, I’ll try to do it on Monday.
Connection policies can match by
sni(and caddy-l4 adds analpnmatcher if you plug it in) but not during HTTP routes (because by that point the TLS handshake completed, and it’s very very rarely needed, and nobody has requested it before). See https://caddyserver.com/docs/json/apps/http/servers/tls_connection_policies/match/But yeah you could use an expression matcher to match a specific value from those placeholders if you do need it in routing.