Support per site ECH config in caddyfile

[christaikobo]

It seems that currently the ECH config can only be set globally, there are certain cases where I do not want to enable ECH for all my sites. It is possible via json config, but it would be very helpful if it is supported in caddyfile as well.

Something like

blog.mydomain.com {
	ech ech.mydomain.com {
                dns cloudflare {token}
	}
}

Thank you!

[mholt]

Sure; do you have a specific proposal? Once we figure out the specifics, a pull request would be welcomed.

I might suggest putting it in the tls directive.

[christaikobo]

Yeah you are right, it is better in tls, maybe like

example.com {
        tls [internal|<email>] | [<cert_file> <key_file>] {
                ech <public_names...> {
                        dns <provider> ...
                }
        }
}

There doesn't seem to be a lot of configurable options revolving around ech.

[mholt]

Yeah, something like that might be better.

I'm a little mixed on whether the public_name should be designated on a per-site basis. ECH is most effective when you maximize the size of your anonymity set. So if there's any disparity of public_names between sites, it reduces privacy. i.e. in general, we want to encourage users to use exactly one public name.

There doesn't seem to be a lot of configurable options revolving around ech.

Yeah, that's kind of intentional. At least for now. There doesn't seem to be any reason to allow configuration of the actual ECH config, and it's still early days.

[christaikobo]

I understand your concern. But since this will not break anything, unlike the empty public SNI we discussed a couple of weeks back, I feel there isn't as strong of a counter argument to not provide the option. Worst case scenario it's as if user haven't got ECH enabled at all. Besides, I think it's fair to say it doesn't always bring the maximum privacy benefits to use a single public SNI, like if I have 2 domains and I don't want them to be mixed up for instance.

…

On Sat, Apr 19, 2025, 16:00 Matt Holt ***@***.***> wrote: Yeah, something like that might be better. I'm a little mixed on whether the public_name should be designated on a per-site basis. ECH is most effective when you maximize the size of your anonymity set <https://caddyserver.com/docs/automatic-https#anonymity-set>. So if there's any disparity of public_names between sites, it reduces privacy. i.e. in general, we want to encourage users to use exactly one public name. There doesn't seem to be a lot of configurable options revolving around ech. Yeah, that's kind of intentional. At least for now. There doesn't seem to be any reason to allow configuration of the actual ECH config, and it's still early days. — Reply to this email directly, view it on GitHub <#6971 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFY26LBVD72TRUV32XBRXMD22LIQPAVCNFSM6AAAAAB3O4PKXSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMJWHA4TMNJZGU> . You are receiving this because you authored the thread.Message ID: ***@***.***> *mholt* left a comment (caddyserver/caddy#6971) <#6971 (comment)> Yeah, something like that might be better. I'm a little mixed on whether the public_name should be designated on a per-site basis. ECH is most effective when you maximize the size of your anonymity set <https://caddyserver.com/docs/automatic-https#anonymity-set>. So if there's any disparity of public_names between sites, it reduces privacy. i.e. in general, we want to encourage users to use exactly one public name. There doesn't seem to be a lot of configurable options revolving around ech. Yeah, that's kind of intentional. At least for now. There doesn't seem to be any reason to allow configuration of the actual ECH config, and it's still early days. — Reply to this email directly, view it on GitHub <#6971 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFY26LBVD72TRUV32XBRXMD22LIQPAVCNFSM6AAAAAB3O4PKXSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMJWHA4TMNJZGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mholt]

Worst case scenario it's as if user haven't got ECH enabled at all.

That's a pretty bad worst case though.

like if I have 2 domains and I don't want them to be mixed up for instance.

Can you elaborate on what you mean by "mixed up"?

unlike the empty public SNI we discussed a couple of weeks back

By the way, about that... turns out the spec requires a length of at least 1, as far as I can tell:

opaque public_name<1..255>;

Caddy technically supports an empty one, as does Chrome, which apparently will use an ECH config with an empty public_name, but Firefox does not, and most crucially, Go does not. Which means Caddy won't work for ECH configs with an empty public name.

[christaikobo]

That's a pretty bad worst case though.

It's definitely not ideal. I was trying to say at least it doesn't break TLS connection.

Can you elaborate on what you mean by "mixed up"?

Of course. My (rudimentary) understanding regarding the essence of ECH is about "what kind information is observable to third party watching on the link". The third party can be state censorship, cooperate firewall, ISP monitoring, etc.. You always have source IP, destination IP, ports and protocol, that is a given. For HTTPS we have SNI and ECH is trying to hide the true SNI with an "fake" SNI, and under most circumstances user wants to hide as many true SNIs behind as few "fake" SNIs as possible, which is an anonymity set.

Suppose I have 2 domains, a.com and b.com, and a.com is used to serve sites like blog.a.com, plex.a.com for users in country A, while b.com is used to serve sites like drive.b.com photo.b.com for users in country B. And my server is located in country C. For censorship machine in country A, I think is beneficial to serve all my *.a.com sites behind public SNI ech.a.com, and same applies for *.b.com behind ech.b.com for country B. It is possible b.com is flagged in country A while a.com is flagged in country B.

Essentially I want to create 2 anonymity sets and IMO this maximizes privacy benefit in this particular scenario.

By the way, about that... turns out the spec requires a length of at least 1, as far as I can tell:

opaque public_name<1..255>;

Caddy technically supports an empty one, as does Chrome, which apparently will use an ECH config with an empty public_name, but Firefox does not, and most crucially, Go does not. Which means Caddy won't work for ECH configs with an empty public name.

That is very interesting. Thanks for sharing these insights.

[mholt]

Okay, fair enough. I will make sure we document that users know what they're doing if they use multiple public names.

Want to make a PR?

[christaikobo]

I'm sorry I don't know the first thing about coding in GO...If it's just document I can try to do it, but...

[diamand2k22]

hi, can anyone help, i get this error, when i activate ech in my caddy config, version is v2.10:

caddy caddy[5741]: Error: adapting config using caddyfile: parsing caddyfile tokens for 'tls': unknown subdirective: ech, at /etc/caddy/Caddyfile:25

my config look like this:

example.com {
tls {
ech exampel.com
dns cloudflare {token}
resolvers xxx.xxx.xxx.xx
}
reverse_proxy http://xxx.xxx.xxx.xxx
}

[christaikobo]

@diamand2k22 you should put ech config in global options, not in site block.

If this issue is resolved by a PR in the future you will be able to use your current config, but not now.