211–219 of 219 posts
Earlier quoted context omitted.
When I visit a more local website only my ISP and the site's ISP will see the domain name. With default browser setting some, probably overseas, entity that I didn't trust and didn't choose gets my request, ignoring my system configuration and without asking.
The entities that can see the domain you're visiting with ECH are a strict subset of those that can without ECH.
Earlier quoted context omitted.
This wouldn't be possible with dnssec right?
Yes, however it defeats one of the main point of ECH, that is encrypting the SNI. Since the domain is leaked in plaintext DNS.
Earlier quoted context omitted.
> plaintext DNS is avoided in order to prevent a MITM on the ClientHelloInner key. Is MiTM possible unless the attacker is in possession of a sufficiently advanced quantum computer? What's published as HTTPS/SVCB record is the public part of the key. Afaik, DNSSEC isn't even a requirement for zones publishing HTTPS/SVCB ECH records? > Doing so prevents ISPs and governments from analyzing your traffic . Don't think tr…
I think the remark is because: MITM would allow them to spoof the DNS response entirely, so they can replace it with whatever key they want. Doesn't matter what level of security the key claims at that point, it's attacker-controlled and they can just read whatever you send next.
Earlier quoted context omitted.
Yes, however it defeats one of the main point of ECH, that is encrypting the SNI. Since the domain is leaked in plaintext DNS.
Why? You can just use DNS-over-TLS/HTTPS + dnssec + ECH + TLSv1.3 and then you should have a unblockable website(outside of IP address bans).
Earlier quoted context omitted.
It's harder to block.
You can run DoT on any port, including 443. Then blocking it gonna be the same as blocking DoH. Why wrap it into HTTP request layer?
If you contend that you can match the DoH SNI with a known DoH server and block that, fair enough. However, there's always another unknown DoH server you haven't blocked. Blocking DoT is trivial in comparison, because of its signature on the wire.
Earlier quoted context omitted.
The hope is that the CDNs explicitly refuse to do that, so that the collateral damage leads to pressure that forces the censor to relent.
Narrator: they didn't relent. Do you think for a second anyone in power in China, Russia, or North Korea care if some random 20-year-old kid can access English-language sites or not?
Earlier quoted context omitted.
This explanation makes sense, thanks! I mean other than the fact you’re still trusting cloudflare not to mess with the data since it’s terminating ssl =) but i agree that makes this somewhat cleaner from client perspective
As a visitor to the site, I need to decide whether or not to trust the site's operator. As the operator of a site, I need to work out which vendors I can trust. Cloudflare takes the role of a vendor here, it's exceptionally common for vendors to terminate SSL. And it's quite challenging to run a CDN without access to the plain-text request. Cloudflare at least offers mutual TLS from the edge to your origin, I've yet…
This is going to make it even more of a pain to do egress filtering on networks/systems we administer. I want to be able to allow list sites with dynamic IPs. The existing solutions for doing this by examining SNI are already often bypassable by forging the SNI (looking at you, AWS Network Firewall).
[1] https://chasersystems.com/blog/disabling-encrypted-clienthel... [2] https://chasersystems.com/discriminat/comparison/aws-network...