688
this post was submitted on 17 Jan 2024
688 points (98.2% liked)
Technology
57455 readers
4582 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I'm not sure if it's part of a TLS standard yet but I was talking about encrypted SNI (ECH, formerly called ESNI).
Today, early on in a TLS connection, the client actually tells the server, in plain text, the domain name it's intending to communicate with. The server then presents a response that only the owner of that domain can produce, then keys are exchanged and the connection progresses, encrypted. This was required to allow a single server to serve traffic on multiple domains. Before this, a server on an IP:Port combo could only serve traffic on a single domain.
But because of this, a man in the middle can just read the ClientHello and learn the domain you're intending to connect to. They can't intercept any encapsulated data (e.g. at the HTTP level, in the case of web traffic) but they can learn the domains you're accessing.
ECH promises to make the real ClientHello encrypted by proceeding it with a fake ClientHello. The response will contain enough information to fetch a key that can be used to encrypt the real ClientHello. Only the server will be able to decrypt this.