6 ms·
Not true. HTTPS encrypts the URL as well as the content of the communication. Someone surveilling the conversation with the ability to observe all network traf
by mcherm 10y ago
Not true.
HTTPS encrypts the URL as well as the content of the communication. Someone surveilling the conversation with the ability to observe all network traffic but without the ability to decrypt SSL traffic would be able to tell that the end user had viewed something at a particular website (technically, at a particular server), but would NOT be able to tell WHICH article was viewed.
- detaro 10y agoI wonder how much that actually gains for this specific case ("which article did IP $x view?"). With more effort, it should be fairly easy to match the traffic pattern to the article, e.g. by matching the size of subsequent requests for the images. But more complicated than a simple filter that just grabs all URLs from HTTP.
- ethbro 10y ago> With more effort That's the new key point for 2017 pro-privacy architectures. Proof of work surveillance doesn't scale because requiring it leverages the disparity between the total level of Internet traffic and intelligence agency resources. Kill the dragnets as step 1, then worry about step 2.
- deathhand 10y agoIt would be helpful to have a website to display a random image of differing sizes for every page load. This would prevent fingerprinting https.
- pixl97 10y agoUm, I don't believe that would help. You either inline the images as data, or better, get rid of all images and have random length non-printing text to hide the real data. This kills caching and performance though.
- btown 10y agohttps://github.com/technion/mod_randpad https://github.com/technion/mod_randpad (an Nginx module that injects padding as a comment into returned HTML documents) is likely the correct layer to add random padding; the performance hit would be negligible.
- fowlslegs 10y agoSD dev here. You might be interested to check out https://github.com/freedomofpress/fingerprint-securedrop https://github.com/freedomofpress/fingerprint-securedrop (note: still in experimental stages). We're going to be using the framework/ ML pipeline to evaluate server-side defenses (e.g., https://petsymposium.org/2017/papers/issue2/paper54-2017-2-source.pdf https://petsymposium.org/2017/papers/issue2/paper54-2017-2-s...), and are also working w/ Tor dev Mike Perry who is working on a solution or set of solutions to the problems of website & circuit fingerprinting with regards to Tor at the protocol level. Edit: What Mike is trying to implement is based on https://arxiv.org/pdf/1512.00524.pdf https://arxiv.org/pdf/1512.00524.pdf.
- epmaybe 10y agoCould you as the host send out random extra bytes that make it hard to match up?
- leni536 10y ago> but would NOT be able to tell WHICH article was viewed. What about inspecting traffic pattern? I suspect that each article has different size.
- mtgx 10y agoI noticed some sites use a subdomain for securedrop. Does that reveal that they're visiting the securedrop page, or not?
- jnbiche 10y ago> Does that reveal that they're visiting the securedrop page, or not? Potentially, if they're using TLS/SSL with SNI.
- fennecfoxen 10y agoJust as true if they're using the real domain with a dedicated IP, right?
- deleted 10y ago[deleted]
- jnbiche 10y agoNope, if they're not using SNI, you'd just see the IP address. Fire up Wireshark some time when you're browsing and watch what comes through.
- fennecfoxen 10y ago> Nope, if they're not using SNI, you'd just see the IP address. but that's my point... if you're not using SNI, there's only one SSL server on that IP address, and if reverse-DNS fails you, you can connect on port 443 and ask it for its certificate and it will give it to you...
- detaro 10y agoYes, both through DNS requests (although one maybe could somewhat mitigate that by having each visit to the main domain trigger requests to the subdomain, a) creating traffic and b) putting it in peoples' DNS caches) and HTTPS (All modern browsers include the domain via SNI). It still might be a better choice, given that the main domain for many sites goes through CDNs and more complex systems in general, increasing the risk of compromise there (which also would expose network details about the submitter, and possibly even more)? A dedicated securedrop site hopefully has dedicated infrastructure and better security.
- jsnell 10y ago> at a particular website (technically, at a particular server) You got it right the first time around, the parenthetical correction is wrong. The SNI is transmitted in plain text during the TLS handshake.
- fosco 10y agoI have a palo alto networks firewall with URL filtering.I can observe destination URL's on https sites without performing SSL decryption. please see eff website showing certain information that can be observed by onlookers[0] when you are using Tor or HTTPS or both https encrypts the contents... not things like source/destination often only a destination IP address is required to get URL categories for many Proxy/URL filtering technologies. [0] https://www.eff.org/pages/tor-and-https https://www.eff.org/pages/tor-and-https
- enzanki_ars 10y agoIf you go to https://example.com/some/directory?param=something https://example.com/some/directory?param=something, the firewall will only see a request to https://example.com https://example.com. Everything else is encrypted. In this case, with SSL, a government agency not doing a MITM will only see https://www.niemanlab.org https://www.niemanlab.org, and http://www.niemanlab.org/2017/01/how-easy-is-it-to-securely-leak-information-to-some-of-americas-top-news-organizations-this-easy/ http://www.niemanlab.org/2017/01/how-easy-is-it-to-securely-... if they were doing a MITM.
- hueving 10y agoYou are confusing URLs with Domains. The only plaintext part of an SSL connection is the SNI, which is the domain.
- grey-area 10y agoOk, so they'd only know that you visited a domain like this at a given time? securedrop.ap.org That still gives away a lot, many of these secure drop sites are on a subdomain.