4 ms·
In practice, I reckon you might be the only person in the world - or maybe one of a dozen - who has this problem. And in that context that's not snark at all, i
by vertex-four 6y ago
In practice, I reckon you might be the only person in the world - or maybe one of a dozen - who has this problem. And in that context that's not snark at all, it's an accurate description of what is most likely the cause of the error.
- DarkWiiPlayer 6y ago> an accurate description except it's a lie. SNI isn't "more secure", it leaks information to a possible MITM.
- AnthonyMouse 6y agoSo use ESNI.
- mnot 6y agoIt's actually a relic of when I was testing to see how broad SNI adoption was -- see https://www.mnot.net/blog/2014/05/09/if_you_can_read_this_youre_sniing https://www.mnot.net/blog/2014/05/09/if_you_can_read_this_yo...
- jorams 6y agoNote that the message isn't saying SNI is more secure. It just says the site needs SNI to operate securely.
- DarkWiiPlayer 6y agoThe website does not support the more secure ECH nor the more secure option of just not using SNI at all. It's the website that doesn't support a fully secure connection and it shouldn't be blaming the user agent for that.
- vertex-four 6y agoESNI is not supported by common software yet. Can you tell me your alternative to SNI in this configuration: [nix-shell:~]$ nslookup redbot.org Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: Name: redbot.org Address: 45.79.113.165 Name: redbot.org Address: 2600:3c01::f03c:92ff:fe89:3e33 [nix-shell:~]$ nslookup www.mnot.net Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: www.mnot.net canonical name = cloud.mnot.net. Name: cloud.mnot.net Address: 45.79.113.165 Name: cloud.mnot.net Address: 2600:3c01::f03c:92ff:fe89:3e33
- DarkWiiPlayer 6y agoWithout any tunnelling like VPN or TOR, the safest option would be to have several unrelated services share one certificate, when only looking at MITM vulnerability. This would in theory ensure that any attacker could only assume the client is accessing at least one service on the target machine. Setting aside the obvious risk that one of the services could claim to be one of the others, this obviously comes with some other technical limitations. Again, it's not like the site is doing anything wrong, it just shouldn't be blaming the user for something that's obviously just a technical limitation of the technology being used.
- account42 6y ago> Setting aside the obvious risk that one of the services could claim to be one of the others Not much additional risk there when both site's TLS connections are already handled by the same process.
- deleted 6y ago[deleted]
- 1vuio0pswjnm7 6y ago"Can you tell me your alternative to SNI in this configuration?" ESNI-enabled lighttpd, nginx or apache: https://185.24.233.103 https://185.24.233.103 ESNI-enabled CDN: https://www.cloudflare.com/ssl/encrypted-sni/ https://www.cloudflare.com/ssl/encrypted-sni/
- tialaramex 6y agoEncrypted Client Hello isn't even at Working Group Last Call yet, let alone actually published, so it won't make sense for most people to offer whatever the current draft state is. Not using SNI isn't a more secure option. By definition you can't be doing standards compliant TLS 1.3 - which would be the most secure option - since sending SNI for host names is mandatory in TLS 1.3. Also, in assuming that multiple hosts can instead be distinguished down in/ up in the HTTP layer you actually do make some things less secure. The TLS session binding doesn't apply to the application layer, so when you write Host: www.example.com in HTTP that does not bind your TLS session to the name www.example.com, whereas if you send SNI for www.example.com then the remote server needs to actively decide by policy if it's safe not to bind that. Are you actually going to get exploited this way? Probably not, but neither are bad guys anxious to find out somehow which of the services on Mark's server you wanted.
- vertex-four 6y agoIt requires a more modern browser to operate securely; it says nothing about whether it is perfectly secure against all threat models, and this particular website is hosted on the same IP as at least one other so requires SNI to operate securely indeed, and will hopefully in future support ESNI as the software implements it. BTW - if this site did not use SNI, and only served one website at https://www.mnot.net https://www.mnot.net, then connecting to www.mnot.net's IP address at port 443 would be plenty good evidence that you're accessing https://www.mnot.net https://www.mnot.net. The SNI privacy leak only really comes into play when you're accessing something behind a CDN or a shared hosting provider, which put enough sites behind each IP that simply accessing that IP isn't a privacy leak in itself.
- YakBizzarro 6y agoI don't see how not sending the SNI can improve leaking. If the server has only one hostname associated, it's trivial to get it from the IP and then reverse DNS. This issue is discussed in detail in multiple drafts about SNI encryption
- yrro 6y agoSNI doesn't make the TLS handshake process and more or less secure. The ServerHello and Certificate messages sent by the TLS server are still sent unencrypted.
- 1vuio0pswjnm7 6y ago"The ServerHello and Certificate messages sent by the TLS server are still sent unencrypted." RFC 8446, page 7: "All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtensions message allows various extensions previously sent in the clear in the ServerHello to also enjoy confidentiality protection."