4 ms·
SNI is not a good argument, there is work being done to encrypt that as well in TLS 1.3 with Encrypted SNI[1]. [1] https://blog.cloudflare.com/encrypted-sni/ h
by j0057 7y ago
SNI is not a good argument, there is work being done to encrypt that as well in TLS 1.3 with Encrypted SNI[1].
[1] https://blog.cloudflare.com/encrypted-sni/ https://blog.cloudflare.com/encrypted-sni/
- the8472 7y agoESNI only helps if you're fronting through things like cloudflare, again putting more eggs and information into a single basket and making them a more valuable target for TLAs.
- comex 7y agoTrue, centralization is a downside. But the alternative is having no privacy from government agencies. Even if you somehow believe your ISP won't be subject to these hypothetical interception orders that CloudFlare would be subject to (why?), there are plenty of points to tap in between your ISP and the website you're visiting.
- throw0101a 7y agoThere's a tcp/443 connection to 208.80.153.224, what site could it be? $ whois 208.80.153.224 NetRange: 208.80.152.0 - 208.80.155.255 CIDR: 208.80.152.0/22 NetName: WIKIMEDIA NetHandle: NET-208-80-152-0-1 Parent: NET208 (NET-208-0-0-0-0) NetType: Direct Assignment OriginAS: AS14907 Organization: Wikimedia Foundation Inc. (WIKIM) RegDate: 2007-07-23 Updated: 2014-01-29 Comment: http://www.wikimediafoundation.org http://www.wikimediafoundation.org Ref: https://rdap.arin.net/registry/ip/208.80.152.0 https://rdap.arin.net/registry/ip/208.80.152.0
- mike-cardwell 7y agomike@blob:~$ host 208.80.153.224 224.153.80.208.in-addr.arpa domain name pointer text-lb.codfw.wikimedia.org. mike@blob:~$ openssl s_client -connect 208.80.153.224:443 2>&1 | openssl x509 -text|grep Subject: Subject: C = US, ST = California, L = San Francisco, O = "Wikimedia Foundation, Inc.", CN = *.wikipedia.org Yeah, our ISPs are going to be totally in the dark thanks to DoH. /s
- growse 7y ago> mike@blob:~$ host 208.80.153.224 224.153.80.208.in-addr.arpa domain name pointer text-lb.codfw.wikimedia.org. mike@blob:~$ openssl s_client -connect 208.80.153.224:443 2>&1 | openssl x509 -text|grep Subject: Subject: C = US, ST = California, L = San Francisco, O = "Wikimedia Foundation, Inc.", CN = *.wikipedia.org Yeah, our ISPs are going to be totally in the dark thanks to DoH. /s minjiexin.com resolves to the same IP. So, you see an HTTPS connection to 208.80.153.224, what's the user doing?
- mike-cardwell 7y agoIn this particular case, the ISPs db entry could simply be "customer visited either wikipedia.org or minjiexin.com", and that would be practically as good as before DoH. Or the ISPs database could simply be of IP addresses connected to, and the purchaser of that database could apply identification based on which other IPs were connected to around a similar time. If it's your argument that mapping IPs to "websites visited" is not 100% accurate, then of course you're correct... So what we need to do is figure out how accurate it is. Because if the answer to that question is 95%, then the whole value proposition of DoH flys out of the window. Why massively centralise DNS to just make a tiny dent in the problem? If the answer to that question is 5% rather than 95%, then I guess that would mean we've centralised the web so far already behind gatekeepers like Cloudflare+Google+AWS+Microsoft, that it doesn't really matter if we go and centralise DNS for web usage in the same way, as the web is already fucked.
- throw0101a 7y ago> ... what's the user doing? $ telnet minjiexin.com 80 Trying 208.80.153.224... Connected to minjiexin.com. Escape character is '^]'. GET / HTTP/1.0 HTTP/1.1 400 [...] <!DOCTYPE html> <html lang="en"> <meta charset="utf-8"> <title>Wikimedia Error</title> [...] Big mystery.
- gsich 7y agoIt is since ESNI is only a draft right now. Implementations matter.