7 ms·
Those two are pretty big already to be honest. I guess a third one would be avoiding eavesdropping on public wi-fis.
by zer0tonin 1y ago
Those two are pretty big already to be honest. I guess a third one would be avoiding eavesdropping on public wi-fis.
- justapassenger 1y agoWith TLS being everywhere, and just few clicks away from having DNS over TLS, I really don't get eavesdropping on public wifi prop value.
- octo888 1y agoTLS doesn't hide which websites (hostnames) you visit
- IggleSniggle 1y agoIt does if you do DNS over TLS or HTTPS, although I guess that information would still be knowable to your DNS provider if they terminate your TLS behind the scenes
- optimalquiet 1y agoNot quite. In order to make TLS certs work on a per-site basis, requests sent over HTTPS also include a virtual host indicator in cleartext that shows the hostname of the site you’re trying to connect to, so if the IP on the other end is hosting multiple domains it can find the right cert. For this reason some people feel that DNS over TLS is pretty pointless as a privacy measure.
- MrOwen 1y agoI think this is only true if SNI is disabled. Otherwise you really only get the IP of SRC and DEST.
- appointment 1y agoSNI relies on the client specifying the host name in the unencrypted ClientHello message that initiates a TLS handshake. Encrypted Client Hello involves extra configuration that most websites don't implement.
- ahlCVA 1y agoSNI leakage is what encrypted client hello (ECH) tries to solve: https://blog.cloudflare.com/announcing-encrypted-client-hello/ https://blog.cloudflare.com/announcing-encrypted-client-hell... It's still not perfect since you're still leaking information about the privacy set implied by the outer ClientHello, but this possibly isn't much worse than the destination IP address you're leaking anyway.
- pfexec 1y agoWhich is more likely, your barista collecting this data for nefarious purposes, or your ISP?
- bigiain 1y agoOr that dude in the black hoodie in the corner who always seems to be camped at whatever cafe you and your cow orkers are using as your startup "office"?
- numpad0 1y agoVPN unifies all destination IPs to server.ip.addr.ess. IP reverse lookups tells some stories if you are to be so paranoid
- michaelt 1y ago1. example.com is not on the HSTS preload list 2. Because you normally visit example.com using an incognito window, your browser hasn't cached the redirect to SSL, or the address bar suggestion, and you haven't bookmarked the site. 3. You key in example.com, the browser connects over http, and the evil wifi MITMs your unencrypted connection - removing the redirect to SSL and messing with the page however the evildoer wants. Obviously a VPN provider can also do this, but you might hope they're less likely to.
- sciencejerk 1y agoWill Chromium generate a "Your connection is not private" warning in this scenario, that the user has to click through to proceed? And the user would have to type example.com in the browser bar; https://example.com https://example.com would also trigger a warning, correct?
- extraduder_ire 1y agoYou connect to an access point, and your browser/OS tries to open one of http://detectportal.firefox.com/canonical.html http://detectportal.firefox.com/canonical.html, http://www.msftconnecttest.com/connecttest.txt http://www.msftconnecttest.com/connecttest.txt, http://connectivitycheck.gstatic.com/generate_204 http://connectivitycheck.gstatic.com/generate_204, https://captive.apple.com/hotspot-detect.html https://captive.apple.com/hotspot-detect.html and loads/displays whatever unencrypted web page is served. Getting someone to open an unencrypted webpage is almost trivial. It's often one of the only web pages you can open on a device.
- Dylan16807 1y agoThe problem isn't getting you to open a page, it's putting that page behind a known legitimate URL.
- TZubiri 1y ago"Obviously a VPN provider can also do this, but you might hope they're less likely to." So you have identified some marginal privacy issue, and have identified that a VPN doesn't solve it, but rather that it moves the risk to a third party actor you subjectively feel is better. Well I feel that, subjectively, introducing a third party generally decreases security. I believe that not all privacy and security considerations can or should be solved technically, but rather we have extra-technical mechanisms like law and social norms that provide some protection on the edge cases. For example, an employee cannot lookup information for personal reasons on a system they are entrusted to in a professional capacity. I'm no expert, but you probably have first laws that prohibit that, second corporate policy that prohibits that, and thirdly social pressure that prohibits that to some extent. Are they perfect? Not necessarily which is why for the most part we rely on technical encryption and security mechanisms. But at some point these examples become so contrived and the medicine becomes the poison, so you enter into territory that is pretty standard in other industries, what's to stop a waiter from spitting into a cup? There's no spit filter in place of McDonalds, there's other mechanisms protecting us. On a similar note, logic and debate is not the only way to convey this phenomenon, so here's some more artistic retort to privacy schizophrenia. https://www.youtube.com/watch?v=jf9I04Oa-hU https://www.youtube.com/watch?v=jf9I04Oa-hU
- TZubiri 1y agoAdditionally, if ConsumerVPNs provide encryption, don't they provide encryption from the stretch between the consumer to the proxy? The stretch between the proxy to the destination would not have additional encryption, and there is no reason to believe that the second transit would be shorter.