4 ms·

The 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 c

The 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 ago
ESNI 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 ago
  Without 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 ago
Encrypted 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 ago

ESNI 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 ago
Without 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 ago

Encrypted 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.