| ▲ | simiones 4 days ago |
| 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 3 days ago | parent | next [-] |
| 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 4 days ago | parent | prev | next [-] |
| >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 4 days ago | parent | next [-] | | 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. | | | |
| ▲ | Ajedi32 4 days ago | parent | prev [-] | | GP means unencrypted at the wire level. ClientHelloOuter is still unencrypted even with HSTS. | | |
|
|
| ▲ | jiveturkey 4 days ago | parent | prev [-] |
| 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 3 days ago | parent [-] | | 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 3 days ago | parent | next [-] | | 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 3 days ago | parent | prev [-] | | 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! |
|
|
