4 ms·
For what it's worth, the network doesn't really provide privacy like that. Anyone monitoring your connection will still see requests to HN, and then to cryptom
by djcapelis 11y ago
For what it's worth, the network doesn't really provide privacy like that. Anyone monitoring your connection will still see requests to HN, and then to cryptome transmitting the same amount of data that is in that PDF. The only privacy related thing https would buy you here is the contents of the document could remain secret... but the entire world can know the content of it now, and even before then the U.S. government definitely knew it, since it is their document and all.
The one thing it would buy you is more certainty that the copy of the document you receive is the same one cryptome is distributing. Which is a good thing, but isn't really about privacy.
- nitrogen 11y agoHTTPS would help if you went on to browse other areas of the site.
- dogma1138 11y agoAnd what exactly would you think would happen if the "Government" knew that you were browsing Cryptome. Heck with spooky "HTTPS" they can claim you've been browsing encrypted "dark web" sites containing classified material just as easily if we were living in some bizzaro world in which they would actually give a fuck. Want to piss of the NSA? print out your browsing history every week and wait for it FAX it to (443) 479-3612, save them the trouble ;)
- nitrogen 11y agoThere are many more parties interested in one's browsing history than just one's own government. There are foreign governments, advertisers, data brokers, hackers, etc. HTTPS at least reduces the attack surface.
- chrisfosterelli 11y agoGood point, you could possibly correlate the PDF size to determine what document it was. Didn't think of that. It still doesn't make HTTPS a bad idea though :)
- rjsw 11y agoSending a known source text using encryption isn't usually a good idea if you want to keep the key secret.
- djcapelis 11y agoIf it were that easy to get keys HTTPS would be fucked.
- nitrogen 11y agoHTTPS uses a new key for every session.
- dogma1138 11y agoMost web servers out there implement one form of another of key reuse usually via a dedicated SSL Session Cache otherwise their CPU's would melt ;) One of the main reasons that SSL is relatively cheap right now is that not only you have some level of hardware acceleration, but web servers are now every good at managing and reusing SSL sessions. On NGINX the default TTL for an SSL session is 5min without constant keep alive, however on most installations that I've seen this has been extended significantly. You can store about 4000 sessions in 1 MB of data, that vs the amount of CPU cycles a handshake will take is a no brainier for most server owners. You can however configure your clients not to reuse an existing session, not sure how well servers will behave in that scenario, some servers which implement TLS actually use that feature as a security measure. mod_tls by default iirc only accepts SSL data sessiona with the same key as the SSL control session while the SSL session is in cache which makes some clients (old curl for example) actually incompatible with it so you might have issues when you trying to pull a file from an HTTPS or FTPS/SFTP service.
- e12e 11y agoReusing the session key implies that the client already knows the shared secret. Sure, if a client goes through his work-place, ssl-stripping proxy, then you might see that minitor@proxy.nsa.gov retrieved documentX, and that drone@proxy.nsa.gov retrieved the same document with the same session - but the traffic would be different unless all response headers were the same. And the proxy could just log the access anyway.
- fiatmoney 11y agoSending encrypted data increases the likelihood that the encrypted data will have to be stored and analysed rather than immediately discarded, which increases the burden on someone monitoring all internet traffic.