Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

They should do this anyways. It's well known to the technical elite that dragnet surveillance is going on— but it's not known to the general public.

It's arguably immoral that the site doesn't switch to https by default and give the public the privacy they think they already have.



That's a very good point. The majority of people have no idea that many Governments are already monitoring and data mining everything they say or do online. Websites should already start switching to HTTPS (or SPDY) to protect their users against this stealth monitoring, of which they know nothing about.

But if they don't and if this law passes (I hope it doesn't) maybe some good will come out of it, and it will jumpstart a trend for switching to encrypted connections.


So what do you guys do to counter this? Do you use encrypted VPNs? Any specific ones you'd recommend?



check mullvad. you can pay with cash over mail, bitcoin or whatever. no logs, two external ip's for thousands of customers. google it


Looks interesting, but who is to say they don't keep logs?

A VPN on VPS provider, whom accepts similar payment options is an alternative option.


Even if they did keep logs, there's only 2 external IPs.


What makes you believe that?

Not that I necessarily think you are wrong.


What makes you think that those with the resources to implement dragnet surveillance do not have access to properly signed certificates, which let them Man-In-The-Middle the connection without triggering a browser warning?


As you say, some of the parties engaging in the drags absolutely do have the capability. But not all and stopping them has value. More importantly:

A man in the middle attack is _highly_ detectable and will leave irrefutable evidence when detected. So it can only be used secretly if it's used very sparingly. And highly overt interception, if its even tolerated by the public, at least solves the problem of people having no idea (being in denial) they're being watched.

Moreover, because MITM can be defeated by de-trusting the rogue CA or via key pinning using it for "mere" surveillance would destroy a valuable and potent weapon, so they won't do it. It simply isn't suitable for dragnet use.

Its also practically much more costly to scale. (E.g. instead of passive optical taps and cheap packet sampling for targeting they must fully intercept all the traffic and decrypt/reencrypt before they even know if its "interesting") Simply making the watchers have to spend a lot more money per unit of traffic monitored is a win for civil rights because it should result in more conservative use of the capability. Without the crypto the surveillance is maximally cheap and undetectable... anything is an improvement even if it can still be compromised.


The cost of decryption is practically 0, though. Certainly not a relevant budgetary factor.


It really isn't. It's only "zero" because you're greatly overestimating the cost of intercepting the traffic at all.

To do dragnet surveillance you need an optical tap, an expensive phy, and a fairly modest number of gates to apply a stateless filter purely from onchip memory to capture 100% of interesting flows and grab some small fraction of all other traffic, and some modest switch fabric to carry captured data to a modest amount of storage and processing to deal with it. Programmed correctly commodity network processors for switches have all the right logic already, we're talking in the <$200 per 10G port parts-cost level. Detailed analysis of the sample data and the known-interesting data gives tells you about new hosts you should be matching for detailed inspection (and you update the can filter with 50ms latencies or so). The cost of maintaining a cheap military aircraft gets your terabits of sampling capacity.

Adding a MITM attack on top of the model used for dragnet surveillance currently, which involves intercepting 100% of the potentially interesting traffic at all times, performing a costly public key operation per every single connection, and then reencrypting the results is insanely expensive by comparison. Before you even get killed by the crypto costs you've long since run out of memory bandwidth.


gah. _in_expensive phy.


To expand on what aidenn0 said:

It's possible to do client-side known-public-key verification, which would detect a MITM attack. The idea is basically maintaining a local trusted cert list (other than the broad ones in the OS), but using known site public keys instead of root signing certificates (which I will admit are a security nightmare for SSL).

Chrome does this for Google-controlled domains; they call it "public key pinning." I'm not sure if any of the other major browsers do it, but it would be pretty simple to implement.

Even if the government had a root CA-signed cert for "mail.google.com", Chrome would throw an error because the government's signed cert public key would not match the public key pinned inside the Chrome browser source code. Chrome would barf with a certificate error.


you can pin domains yourself in your own Chrome/chromium as well at chrome://net-internals/#hsts


The fact that this would get noticed if they did this for dragnet surveillance. They can (and likely do) do targeted MITM, but doing it across the board would be noticed quickly.


http://perspectives-project.org/ - it checks the certificate fingerprint against other users, so a targetted attack is detectable.

(there is also a beta for chrome)


If you're worried, just download a dump of wikipedia and browse local (http://dumps.wikimedia.org/)



I used HTTPS Everywhere and HTTPS Finder extensions. That forces your browser to use HTTPS on every server that supports it.


These should be default browser features.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: