Hacker Neue

Preferences
simiones parent
Connections never start as encrypted, they always start as plain text. There are multiple ways of impersonating an IP even if you don't control DNS, especially if you are in the same local network.
Gigachad
Double especially if it's the ISP or government involved. They can just automatically MITM and reencrypt every connection if there is no identity checks.
gruez
>Connections never start as encrypted, they always start as plain text

Not "never", because of HSTS preload, and browsers slowly adding scary warnings to plaintext connections.

https://preview.redd.it/1l4h9e72vp981.jpg?width=640&crop=sma...

simiones OP
TCP SYN is not encrypted, and neither is Client Hello. Even with TCP cookies and TLS session resumption, the initial packet is still unencrypted, and can be intercepted.
haiku2077
Client Hello can be encrypted: https://support.mozilla.org/en-US/kb/understand-encrypted-cl...
simiones OP
Oh, right, thanks for the correction!

However, ECH relies on a trusted 3rd party to provide the key of the server you are intending to talk to. So, it won't work if you have no way of authenticating the server beforehand the way GP was thinking about.

EE84M3i
Yes but this still depends on identity. It's not unauthenticated.
ekr____
The situation is actually somewhat more complicated than this.

ECH gets the key from the DNS, and there's no real authentication for this data (DNSSEC is rare and is not checked by the browser). See S 10.2 [0] for why this is reasonable.

[0] https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.ht...

Ajedi32
GP means unencrypted at the wire level. ClientHelloOuter is still unencrypted even with HSTS.
jiveturkey
Chrome started doing https-first since April 2021 (v90).

Safari did some half measures starting in Safari 15 (don't know the year) and now fully defaults to https first.

Firefox 136 (2025) now does https first as well.

simiones OP
That is irrelevant. All TCP connections start as a TCP SYN, that can be trivially intercepted and MITMd by anyone. So, if you don't have an out-of-band reason to trust the server certificate (such as trust in the CA that PKI defines, or knowing the signature of the server certificate), you can never be sure your TLS session is secure, regardless of the level of encryption you're using.
gruturo
After the TCP handshake, the very first payload will be the HTTPS negotiation - and even if you don't use encrypted client hello / encrypted SNI, you still can't spoof it because the certificate chain of trust will not be intact - unless you somehow control the CAs trusted by the browser.

With an intact trust chain, there is NO scenario where a 3rd party can see or modify what the client requests and receives beyond seeing the hostname being requested (and not even that if using ECH/ESNI)

Your "if you don't have an out-of-band reason to trust the server cert" is a fitting description of the global PKI infrastructure, can you explain why you see that as a problem? Apart from the fact that our OSes and browser ship out of the box with a scary long list of trusted CAs, some from fairly dodgy places?

let's not forget that BEFORE that TCP handshake there's probably a DNS lookup where the FQDN of the request is leaked, if you don't have DoH.

jiveturkey
well yes! that is the entire point / methodology of TLS. Because you have a trust anchor, you can be sure that at the app layer the connection is "secure".

of course the L3/L4 can be (non) trivially intercepted by anyone, but that is exactly what TLS protects you against.

if simple L4 interception were all that is required, enterprises wouldn't have to install a trust root on end devices, in order to MITM all TLS connections.

the comment you were replying to is

> How is an attacker going to MITM an encrypted connection they don't have the keys for

of course they can intercept the connection, but they can't MITM it in the sense that MITM means -- read the communications. the kind of "MITM" / interception that you are talking about is simply what routers do anyway!

This item has no comments currently.