5 ms·
For all those wo are not aware what HTTPS encrypts: HTTPs encrypts basically the whole protocol, this includes your request (the URL, your fingerprint -- e.g.
by Matt3o12_ 9y ago
For all those wo are not aware what HTTPS encrypts:
HTTPs encrypts basically the whole protocol, this includes your request (the URL, your fingerprint -- e.g. browser, plugins installed, preferred languages) and the response (the content, type of the response (text, video, audio file), and some other not some important things).
What HTTPs does not encrypt is the domain and ip. The domain is leaked through DNS. DNSSec will not help either because it will not encrypt the DNS request. It rather signs it so that you can be sure it is authentic (not tempered with) but everyone can read it. This includes the wifi hotspot you use, your ISP, your government and anyone who tampers with the wires (theoretically even your neighbor and nearby people if you use mobile data since the connection from your device to your ISP is not really strong[1]).
Even if you would encrypt the DNS traffic (or you use just use the host's ip directly), the person who intercepts your traffic could just build a database with IP addresses that correspond to DNS entries (or do a reverse lookup, however, not every IP address has a reverse lookup configured to the domain you are visiting).
In wikipedia's example, this can still be pretty bad. For instance, if an oppressive government realizes that you visit wikipedia version of a particular language pretty frequently (compared to the rest of the population), they might make assumptions about you and profile you. When you visit the German wikipedia site, you are actually visiting de.wikipedia.org instead of en.wikipedia.org which can be intercepted and seen.
This gets worse for static file servers which serve different images at different subdomains (e.g. static512.domain.tld). So, if a DNS request is made to static523, static123, static721, and static132, an attack might be able to guess which article you are reading (or narrow down the choice) because their will not be many articles which have images served by those particular file servers. Thankfully wikipedia does not do that. Everything is served through upload.wikimedia.org but newpapers/forums, etc might not do that or they even have a unique domain for that article (e.g. embedded chart/video, which comes from a unique their party and is loaded automatically).
So all in all, HTTPs is pretty good but you still leave a lot of metadata (the DNS requests are just the tip of the iceberg) that can be used to learn a lot about you. If you want to be safe, use Tor or a VPN. If you use a VPN be aware that you just shift the trust from your current location to another one (so that the VPN provider, their ISP, and the government where the VPN server is located can read all those metadata, which might be not a big deal or even worse, depending where you actually life. Furthermore some VPNs have been known to be broken easily and your ISP/government still sees that you are using a VPN or even Tor).
[1]: One exception is LTE internet but you could still downgrade the connection to 3G or edge to intercept the domain
- schoen 9y ago> What HTTPs does not encrypt is the domain and ip. The domain is leaked through DNS. Currently also with SNI. https://en.wikipedia.org/wiki/Server_Name_Indication https://en.wikipedia.org/wiki/Server_Name_Indication This is important for some censorship circumvention schemes and also because some people have suggested that encrypting SNI is useless because DNS leaks the hostname [however, not necessarily along the same network path!!], while some people have also suggested that encrypting DNS queries is useless because SNI leaks the hostname.