8 ms·

It's not safe to assume the NSA doesn't log DDG searches. Look at the PRISM logo - it's a beam splitter. Read the slide, look at the "Upstream" portion. http:/

It's not safe to assume the NSA doesn't log DDG searches. Look at the PRISM logo - it's a beam splitter. Read the slide, look at the "Upstream" portion. http://commons.wikimedia.org/wiki/File:Upstream_slide_of_the_PRISM_presentation.jpg http://commons.wikimedia.org/wiki/File:Upstream_slide_of_the... They're logging all your URLs and headers. How much are you willing to bet they can't decrypt https? I dont understand all the hubbub _is focused solely_ on direct server access (the bottom half of the slide), when "Upstream" access is just as big a concern. EDIT: rephrased my concern about direct vs upstream

nwh 13y ago
If you're using HTTPS, they can't even see your URLs or headers. That's sort of the point.
- lurkinggrue 13y ago
  Email is unencrypted in transit.
  - eridius 13y ago
    What does that have to do with using a search engine? I'm pretty sure you aren't emailing them your queries.
    - skeletonjelly 13y ago
      Maybe that's all Stallman's queries
  - diminoten 13y ago
    ...unless you encrypt it.
  - bigiain 13y ago
    That's not universally true - there's a remarkable amount of TLS/SSL encrypted email-in-transit, either via STARTTLS ESMTP commands or SSL over port 465 (and 993/995 for IPAM and POP3). I don't think there's a way to guarantee your mail always travels over TLS/SSL secured connections, but I suspect more of it does than you think.
    - dllthomas 13y ago
      There's a straightforward way to make sure your email is always encrypted in transit: encrypt it before you send. No promises about making sure your email can always be read by the recipient, though...
      - bigiain 13y ago
        And here's the problem. Email needs to be able to be read by the recipient, so until a significant portion of email recipients can handle encrypted mail - the NSA doesn't need to attack my encrypted email storage, because enough of my correspondence ends up in cleartext in gmail/hotmail/yahoo et al. This is a hard one to solve. GPGmail seems to get broken with every Mac Mail.app release. Vast numbers of people rely on webmail - which'd need server-side or in-browser GPG decryption. My Mom's not going to use command like gpg tools. How the hell do we bootstrap our way up to ubiquitous encrypted email?
        SilasX 13y ago
        Hm, should be easy enough to have some browser plugin that lets you select a text/data field and recipient list field and encrypt it with the appropriate key; and to do something similar for recognition and decryption of fields. If I implement this, will I become famous?
        bigiain 13y ago
        If you get it right you will. I think there are complications though - you need to be very sure that rogue javascript can't dig around in your plugin and extract my private key. I'm not sure how securely sandboxed plugins can be.
        SilasX 13y ago
        What's the normal procedure for making a call whose output depends on a file that must be kept secret? Is there a typical OS API pattern that's seen in the various programs like ssh, scp, and so on?
  - deno 13y ago
    In transit it’s actually pretty good bet it is encrypted. Now at rest it’s entirely different.
gtaylor 13y ago
> I dont understand all the hubbub about direct server access It's upsetting. It's a breach of trust for the provider and the government. It's more principle than technical. Both the "upstream" and "direct" methods are upsetting, just in different ways and for different reasons.
diminoten 13y ago
Spoiler alert: They can't decrypt it. That's why they have to ask these companies for the info, rather than just take it from the ISPs.
- smaili 13y ago
  Doesn't necessarily mean they don't have the ability to decrypt, it just means that they have a process in place so in case shit ever hit the fan (like it just did) they can come back and say "what's the big deal? we have a process in place"
  - diminoten 13y ago
    Okay, tinfoil.
- iguana 13y ago
  If they can decrypt some SSL (maybe low bit) it is likely a very intense process that requires vast hardware resources, so even if they can do it, it is not likely it is being done for all traffic, but could be applied to some traffic.
- dredmorbius 13y ago
  It could just as easily come down to simple costs. If it's less expensive to ask someone to hand over the data (in bulk) rather than burn CPU cycles cracking SSL (again: in bulk), then go for it. Even if it's feasible to crack SSL for a few crucial messages, it's likely not so for the volumes of data the NSA are capturing.
jerf 13y ago
"How much are you willing to bet they can't decrypt https?" I'd bet quite a bit, though not "my life", that they do not have a generalized "read everything" ability for all forms of SSL. They may have what cryptographers would call "a crack", but that's a low bar, and doesn't prove they have a practical attack. However, DDG is currently using 128-bit RC4, which is very weak. [1] I wouldn't care to bet anything that the NSA doesn't have an RC4 cipher crack that is practical to run on wide swathes of traffic. RC4 is very popular, which I believe is because some people claimed it was a defense against the BEAST attack. I researched this for work, and I couldn't find anyone whom I trusted saying that was a good mitigation. The people I trusted merely observed that RC4 was not vulnerable, but never said you should switch to it. Only secondary sources ever suggested that. My conclusion was that there was a reason for the primary sources never suggesting that; in response to a theoretical break of the rest of SSL, the correct move was not to move to a solution that had much more practical attacks already known than what BEAST demonstrated. But now it's even sillier; BEAST has been either entirely or almost entirely mitigated in browsers (there's no server-side defense against BEAST, but there's a client-side one you can use, and browsers now have it). As far as I can tell, RC4 should be abandoned and we should resume using stronger ciphers for SSL. Anyone still concerned about BEAST should update their browser. [1]: http://nakedsecurity.sophos.com/2013/03/16/has-https-finally-been-cracked/ http://nakedsecurity.sophos.com/2013/03/16/has-https-finally...
- dllthomas 13y ago
  I might bet my life on HTTPS depending on what my alternate choices are. I'm loathe to bet my life on anything, though.
- icebraining 13y ago
  OTOH, if they can get a CA - any CA - to cooperate, they can MITM anyone without having to break SSL.
  - nwh 13y ago
    Only for targeted traffic though. They can't record, go back, and break it.
leoc 13y ago
There's no question that they're monitoring upstream traffic. In fact they may still be doing the old ECHELON trick in which the US eavesdrops on non-Americans, the rest of the world spies on Americans (among others) - and then everyone swaps the data received. But in the light of the PRISM documents it's even more likely than it was before that the NSA doesn't have the ability to decrypt HTTPS, or at the minimum that the US considers it too important to risk giving it away by using it on routine Top Secret signals intelligence. (And/or maybe too resource-intensive to use for that.) The strongest evidence for this is that we haven't heard anything about such a capacity yet from Snowden, Greenwald et al., who all have the full PRISM deck (along with other documents) in their possession and would surely tell us about it if they knew of it. So either 1) the PRISM slides do mention the ability to decrypt SSL or SSH streams but Snowden and the journalists haven't picked up on it (not impossible given the apparent incompetence they displayed over "direct access"), 2) it's too sensitive to mention in a self-aggrandising Top Secret overview of upstream and "direct collection" Internet signals intelligence, which probably means it's not in use (or at least not in regular use) for upstream collection or 3) they really don't have it. A supporting reason to think that they don't have it, or hardly ever use it, is the apparent emphasis on "direct collection" in the PowerPoint. Why go to the hassle of dancing the frenemy minuet with Google and other fairly-anti-surveillance Silicon Valley firms when you can just get what you want from upstream collection at the apparently more-accommodating telcos? This isn't conclusive because even if you could understand all the traffic into and out of someone's Facebook account you'd still like to be able to see the internal state of the account, in particular so that you'd know what they'd been doing before the upstream surveillance began. But I think it's at least as likely that the whole new focus on direct collection is a workaround for the fact that, thanks to SSL and SSH, upstream collection just isn't what it used to be back in the days of ECHELON. As the slide said, You Should Use Both: direct collection to give you access to US-company servers, probably bypassing the HTTPS problem, and upstream access to give you data, probably only unencrypted data (email!), that passes through the US without going to a US-company server. (If you want an exotic alternative theory, you could speculate that the PRISM document is a fake, a limited hangout http://en.wikipedia.org/wiki/Limited_hangout http://en.wikipedia.org/wiki/Limited_hangout by the US spooks, maybe precisely to direct attention away from their ability to decrypt HTTPS streams. But this now seems unlikely, for example because DNI Clapper would surely have to have approved a managed release of a set of documents that both gave away the Verizon metadata surveillance and so also implicated him in perjury.)
headstorm 13y ago
While I haven't heard explicitly about Amazon being part of PRISM, the duckduckgo ips all point to amazon's EC2 platform.
- leoc 13y ago
  PRISM doesn't matter that much, anyway - the NSA doesn't need a workflow automation system in place to send DDG or Amazon a NSL or a FISA order.
  - mhartl 13y ago
    The point is that DDG doesn't log the information—even in the face of a court order, they have nothing to hand over.
hoov 13y ago
I know this is paranoid, but I keep coming back to this post that hit HN a few days ago: http://www.cypherspace.org/adam/hacks/lotus-nsa-key.html http://www.cypherspace.org/adam/hacks/lotus-nsa-key.html When you combine that with the beam splitter logo, things get a bit scary.
leoc 13y ago
More concretely, they don't have to rely on decrypting https. An approved NSA or FISA order to DDG will give the government an en clair "wiretap" on your DDG searches for up to a year. They may not be able to get the searches you did before the wiretap began, but that's all.
humanspecies 13y ago
Google wasn't passively spied on via a beam splitter or whatever you call it. They were doing the spying and actively sending the data out.
martinlee 13y ago
What about Yacy? (http://yacy.net http://yacy.net). I am not sure if the queries inside a peer network can be decrypted as easily as http requests (I am not a networking specialist though, it is just an opinion).

nwh 13y ago

If you're using HTTPS, they can't even see your URLs or headers. That's sort of the point.

lurkinggrue 13y ago
Email is unencrypted in transit.
- eridius 13y ago
  What does that have to do with using a search engine? I'm pretty sure you aren't emailing them your queries.
  - skeletonjelly 13y ago
    Maybe that's all Stallman's queries
- diminoten 13y ago
  ...unless you encrypt it.
- bigiain 13y ago
  That's not universally true - there's a remarkable amount of TLS/SSL encrypted email-in-transit, either via STARTTLS ESMTP commands or SSL over port 465 (and 993/995 for IPAM and POP3). I don't think there's a way to guarantee your mail always travels over TLS/SSL secured connections, but I suspect more of it does than you think.
  - dllthomas 13y ago
    There's a straightforward way to make sure your email is always encrypted in transit: encrypt it before you send. No promises about making sure your email can always be read by the recipient, though...
    - bigiain 13y ago
      And here's the problem. Email needs to be able to be read by the recipient, so until a significant portion of email recipients can handle encrypted mail - the NSA doesn't need to attack my encrypted email storage, because enough of my correspondence ends up in cleartext in gmail/hotmail/yahoo et al. This is a hard one to solve. GPGmail seems to get broken with every Mac Mail.app release. Vast numbers of people rely on webmail - which'd need server-side or in-browser GPG decryption. My Mom's not going to use command like gpg tools. How the hell do we bootstrap our way up to ubiquitous encrypted email?
      - SilasX 13y ago
        Hm, should be easy enough to have some browser plugin that lets you select a text/data field and recipient list field and encrypt it with the appropriate key; and to do something similar for recognition and decryption of fields. If I implement this, will I become famous?
        bigiain 13y ago
        If you get it right you will. I think there are complications though - you need to be very sure that rogue javascript can't dig around in your plugin and extract my private key. I'm not sure how securely sandboxed plugins can be.
        SilasX 13y ago
        What's the normal procedure for making a call whose output depends on a file that must be kept secret? Is there a typical OS API pattern that's seen in the various programs like ssh, scp, and so on?
- deno 13y ago
  In transit it’s actually pretty good bet it is encrypted. Now at rest it’s entirely different.

gtaylor 13y ago

> I dont understand all the hubbub about direct server access It's upsetting. It's a breach of trust for the provider and the government. It's more principle than technical. Both the "upstream" and "direct" methods are upsetting, just in different ways and for different reasons.

diminoten 13y ago

Spoiler alert: They can't decrypt it. That's why they have to ask these companies for the info, rather than just take it from the ISPs.

smaili 13y ago
Doesn't necessarily mean they don't have the ability to decrypt, it just means that they have a process in place so in case shit ever hit the fan (like it just did) they can come back and say "what's the big deal? we have a process in place"
- diminoten 13y ago
  Okay, tinfoil.
iguana 13y ago
If they can decrypt some SSL (maybe low bit) it is likely a very intense process that requires vast hardware resources, so even if they can do it, it is not likely it is being done for all traffic, but could be applied to some traffic.
dredmorbius 13y ago
It could just as easily come down to simple costs. If it's less expensive to ask someone to hand over the data (in bulk) rather than burn CPU cycles cracking SSL (again: in bulk), then go for it. Even if it's feasible to crack SSL for a few crucial messages, it's likely not so for the volumes of data the NSA are capturing.

jerf 13y ago

"How much are you willing to bet they can't decrypt https?" I'd bet quite a bit, though not "my life", that they do not have a generalized "read everything" ability for all forms of SSL. They may have what cryptographers would call "a crack", but that's a low bar, and doesn't prove they have a practical attack. However, DDG is currently using 128-bit RC4, which is very weak. [1] I wouldn't care to bet anything that the NSA doesn't have an RC4 cipher crack that is practical to run on wide swathes of traffic. RC4 is very popular, which I believe is because some people claimed it was a defense against the BEAST attack. I researched this for work, and I couldn't find anyone whom I trusted saying that was a good mitigation. The people I trusted merely observed that RC4 was not vulnerable, but never said you should switch to it. Only secondary sources ever suggested that. My conclusion was that there was a reason for the primary sources never suggesting that; in response to a theoretical break of the rest of SSL, the correct move was not to move to a solution that had much more practical attacks already known than what BEAST demonstrated. But now it's even sillier; BEAST has been either entirely or almost entirely mitigated in browsers (there's no server-side defense against BEAST, but there's a client-side one you can use, and browsers now have it). As far as I can tell, RC4 should be abandoned and we should resume using stronger ciphers for SSL. Anyone still concerned about BEAST should update their browser. [1]: http://nakedsecurity.sophos.com/2013/03/16/has-https-finally-been-cracked/ http://nakedsecurity.sophos.com/2013/03/16/has-https-finally...

dllthomas 13y ago
I might bet my life on HTTPS depending on what my alternate choices are. I'm loathe to bet my life on anything, though.
icebraining 13y ago
OTOH, if they can get a CA - any CA - to cooperate, they can MITM anyone without having to break SSL.
- nwh 13y ago
  Only for targeted traffic though. They can't record, go back, and break it.

leoc 13y ago

There's no question that they're monitoring upstream traffic. In fact they may still be doing the old ECHELON trick in which the US eavesdrops on non-Americans, the rest of the world spies on Americans (among others) - and then everyone swaps the data received. But in the light of the PRISM documents it's even more likely than it was before that the NSA doesn't have the ability to decrypt HTTPS, or at the minimum that the US considers it too important to risk giving it away by using it on routine Top Secret signals intelligence. (And/or maybe too resource-intensive to use for that.) The strongest evidence for this is that we haven't heard anything about such a capacity yet from Snowden, Greenwald et al., who all have the full PRISM deck (along with other documents) in their possession and would surely tell us about it if they knew of it. So either 1) the PRISM slides do mention the ability to decrypt SSL or SSH streams but Snowden and the journalists haven't picked up on it (not impossible given the apparent incompetence they displayed over "direct access"), 2) it's too sensitive to mention in a self-aggrandising Top Secret overview of upstream and "direct collection" Internet signals intelligence, which probably means it's not in use (or at least not in regular use) for upstream collection or 3) they really don't have it. A supporting reason to think that they don't have it, or hardly ever use it, is the apparent emphasis on "direct collection" in the PowerPoint. Why go to the hassle of dancing the frenemy minuet with Google and other fairly-anti-surveillance Silicon Valley firms when you can just get what you want from upstream collection at the apparently more-accommodating telcos? This isn't conclusive because even if you could understand all the traffic into and out of someone's Facebook account you'd still like to be able to see the internal state of the account, in particular so that you'd know what they'd been doing before the upstream surveillance began. But I think it's at least as likely that the whole new focus on direct collection is a workaround for the fact that, thanks to SSL and SSH, upstream collection just isn't what it used to be back in the days of ECHELON. As the slide said, You Should Use Both: direct collection to give you access to US-company servers, probably bypassing the HTTPS problem, and upstream access to give you data, probably only unencrypted data (email!), that passes through the US without going to a US-company server. (If you want an exotic alternative theory, you could speculate that the PRISM document is a fake, a limited hangout http://en.wikipedia.org/wiki/Limited_hangout http://en.wikipedia.org/wiki/Limited_hangout by the US spooks, maybe precisely to direct attention away from their ability to decrypt HTTPS streams. But this now seems unlikely, for example because DNI Clapper would surely have to have approved a managed release of a set of documents that both gave away the Verizon metadata surveillance and so also implicated him in perjury.)

headstorm 13y ago

While I haven't heard explicitly about Amazon being part of PRISM, the duckduckgo ips all point to amazon's EC2 platform.

leoc 13y ago
PRISM doesn't matter that much, anyway - the NSA doesn't need a workflow automation system in place to send DDG or Amazon a NSL or a FISA order.
- mhartl 13y ago
  The point is that DDG doesn't log the information—even in the face of a court order, they have nothing to hand over.

hoov 13y ago

I know this is paranoid, but I keep coming back to this post that hit HN a few days ago: http://www.cypherspace.org/adam/hacks/lotus-nsa-key.html http://www.cypherspace.org/adam/hacks/lotus-nsa-key.html When you combine that with the beam splitter logo, things get a bit scary.

leoc 13y ago

More concretely, they don't have to rely on decrypting https. An approved NSA or FISA order to DDG will give the government an en clair "wiretap" on your DDG searches for up to a year. They may not be able to get the searches you did before the wiretap began, but that's all.

humanspecies 13y ago

Google wasn't passively spied on via a beam splitter or whatever you call it. They were doing the spying and actively sending the data out.

martinlee 13y ago

What about Yacy? (http://yacy.net http://yacy.net). I am not sure if the queries inside a peer network can be decrypted as easily as http requests (I am not a networking specialist though, it is just an opinion).