Hacker News new | past | comments | ask | show | jobs | submit login

I'm curious as to the technical specifications of the supposed Naris device. I don't doubt that the US government can obtain the email logs of most citizens, but would it truly occur in this manner? Binney seems to describe a single unit connected directly into the backbone networks of major ISPs, logging all data on certain ports I assume (ie, the common POP3, IMAP, SMTP ports)? Depending on the level of distribution, this device would be tapping into potentially enormous amounts of data. The processing and storage infrastructure would have to be incredibly robust.

I'm not very knowledgable as to the feasibility of such a device, and quite frankly don't know where to begin, but I would love to hear from someone who might know more.

As a back of the napkin, rougher-than-order-of-magnitude calculation, it seems more feasible for the government to tap into existing email providers' databases than to try and administer their own. Would it not simply be easier to file requests (perhaps in a quasi-legitimate manner) for data from Google/Yahoo/MS/Apple than to try and catalog the entire email history of the Internet?




I think the government is sniffing packets directly. It's much easier to feed through whatever content analysis engines they have today than try to access remote systems routinely. SSL? When the government has access to most of the internet's root keys, decrypting 128-bit SSL is 'annoying' and definitely solved. There was a controversy a few years ago about secret closets with direct access to raw fiber traffic:

* http://yro.slashdot.org/story/05/12/25/0029204/nsa-data-mini...

* http://slashdot.org/story/06/04/07/1246259/att-forwarding-al...

* http://yro.slashdot.org/story/07/11/09/2040206/ex-att-tech-s...

Mirroring traffic at the ISP would be much harder to detect, more thorough, and reduces the number of pesky admins who would come across surprises in their logs. My vote is on that approach -- it's similar to how spy satellites are operated now ("record everything and playback like it's a DVR when we need it").

As an aside, this is the third time in as many days that I've seen 'repeated' content from old Slashdot on HN. Not sure what I make of that trend.


Can you clarify the government's SSL decryption capabilities?

I'm aware the US government has CA certs installed in pretty much all browsers. Obviously being a CA allows you to MITM any SSL connection (though probably not without someone noticing, if done on the scale people are talking about, which is probably computationally prohibitive anyway).

But isn't it impossible to decrypt passively sniffed SSL traffic in all cases?


Neither SSL or cryptography are broken. However, it's widely known that the government has its hands on most root-level private keys. All of cryptography comes down to how well we manage keys, whose weakest link is humans :)

Having the internet's root keys does two things:

1) The government can impersonate as most sites to perform a MITM, which is rare and would only happen on specific, targeted people.

2) The private keys reduce the search space for brute force 128-bit decryption to the point that it can be completed in near real time. If the government were to have direct access to the fiber backbones, then they could monitor SSL traffic as easily as plain-text traffic. Hence, "solved problem." Part of the trick behind this is pre-computing a lot of commercial site's individual private keys ahead of time. If you do nothing but monitor headers you would know the top 90% of hosts to pre-compute first.

To be clear -- I don't know what the government does or does not do. But I know a little bit about crypto and the industry, and I'm inferring what the government does based on 'innocuous' requests it makes regularly to a popular crypto products such as the one I worked on.


By root level private keys you mean the third-parties like Verisign etc, not just the ones explicitly belonging to the US government?


Correct.

Furthermore, at least Chrome restricts most Google domains to a known CA. So MITM is not possible for Gmail either.


So if I have my own server, with my own self-signed certificate, the government can still decrypt my traffic easily?


That depends. SSL (https) as it is currently implemented in browsers has the vulnerability, that you trust all certificates signed with any root certificate which are installed in the browser. So if you have a dedicated browser, where you have deinstalled all default certificates and installed only your private self-signed certificate, then SSL is (to the best of my knowledge) secure. Unfortunately your server has no way to check, which certificate the client sees ( and vice versa). Therefore it can not enforce the use of this specific browser. ( And this obviously does not work for a public website.)

By contrast in the case of ssh the server and client each store a key for the specific connection. In this case your connection is essentially as secure as the key exchange. And if a mitm (Man in the middle) attack was already in place when you established a connection for the first time, then ssh will warn you if the mitm attack ends. ( Since in this case the server sends you a different public key than the stored one, which was corrupted by the mitm attack. )


Even if your browser has CA certs installed someone with a CA cert can only MITM your SSL connections, not passively sniff them, right?


This depends on the meaning of "sniff them." If you mean by this, that the attacker needs some way to get active equipment into your data stream, then yes. But a sufficiently advanced attacker can of course always get his equipment into your data stream. For example by using directional antennas to spoof a wifi hotspot, or digging a hole and splicing it directly into the optical fiber.


Yeah, I don't doubt the government could perform active attacks on more targeted individuals if they wanted to, but this mass collection of internet traffic that's supposedly happening is almost certainly passive.


No. But no one can verify your certificate.

The same principle that should make Verisign trustworthy (centrally recognized / audited trust authority) makes them vulnerable to nation-state tampering, or more specifically, eavesdropping.


Why?

Verisign merely signs your certificate. It does not even know your private key and hence also can't pass it to governments.


It is not necessary for the government to have your key; They can impersonate your site (using their own key) if they have the cooperation of the CA.


The trick is that if this were being done on a regular/wide basis, people would notice and have pretty incontrovertible evidence of it.

I have no doubt they can do it, but it seems to be consigned to their bag of tricks for special occasions.


Filing requests with endpoints leaves a trail, and an agency would have a hard time requesting everyone's total traffic without proper cause.

On the other hand, recording everything through a key bottleneck leaks no information about what is specifically of interest. It also allows retrospective looks at things that might not have seemed interesting enough to request up front. And 'certain ports'? Bah! Get it all. Maybe future breakthroughs (or current undisclosed innovations) can render it all transparent.

This may not be the 'easiest' approach, but it's definitely the 'best', for maximum knowledge, if you can afford/manage it.

The proper spelling is 'Narus', which is also the name of the supplier company, based in Sunnyvale and since 2010 a subsidiary of Boeing. You can read about them and their capabilities at:

http://en.wikipedia.org/wiki/Narus_%28company%29

http://www.narus.com/


Ah, thank you very much. A google for "Naris" (as it is spelled in the RT article) isn't very helpful.

Your logic is definitely sound. It's just mind boggling to me that anyone could possibly be logging everything thrown through every port. Every single day. Just, wow.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: