latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic
Google is speeding up its initiative to encrypt all DC to DC traffic, as this was suspected a short time ago. http://www.informationweek.com/security/government/nsa-fallout-google-speeds... On Wed, Oct 30, 2013 at 1:46 PM, Jacque O'Lantern < jacque.olantern@yandex.com> wrote:
http://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-...
As a top-posting IT generalist pleb, can someone explain why Google/Yahoo did not already encrypt their data between DCs? Why is my data encrypted over the internet from my computer to theirs, but they don't encrypt the data when it goes outside their building and all the fancy access controls they like to talk about? Thank you for your feedback, explanoit On 2013-10-30 13:46, Jacque O'Lantern wrote:
http://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-...
On Fri, Nov 1, 2013 at 1:48 PM, explanoit <explanoit.nanog@explanoit.com> wrote:
As a top-posting IT generalist pleb, can someone explain why Google/Yahoo did not already encrypt their data between DCs? Why is my data encrypted over the internet from my computer to theirs, but they don't encrypt the data when it goes outside their building and all the fancy access controls they like to talk about?
Its about the CPU cost of the crypto. I was once told the number of CPUs required to do SSL on web search (which I have now forgotten) and it was a bigger number than you'd expect -- certainly hundreds. So, crypto costs money at scale basically. Cheers, Michael
On Thu, Oct 31, 2013 at 11:26 PM, Michael Still <mikal@stillhq.com> wrote:
[snip]
Its about the CPU cost of the crypto. I was once told the number of CPUs required to do SSL on web search (which I have now forgotten) and it was a bigger number than you'd expect -- certainly hundreds.
So, crypto costs money at scale basically.
SSL Cryptography for web search is a different problem than, say Site-to-Site VPN encryption. Every time a new browser connects, you have a new SSL session setup. New SSL session setup requires public cryptography operations which impose a significant delay, and the public key operations have an enormous CPU cost. So much so, that the key generation and signing operations involved in CPU session setup are a big bottleneck, and therefore, a potential DoS risk. For encryption of traffic between datacenters; There should be very little session setup and teardown (very few public key operations); almost all the crypto load would be symmetric cryptography. No doubt, there still must be some cost in terms of crypto processors required to achieve encryption of all the traffic on 100-gigabit links between datacenters; it's always something, after all.
Cheers, Michael
-- -JH
I still have some one time pads if you are good writing fast ... -J On Fri, Nov 1, 2013 at 11:26 AM, Randy Bush <randy@psg.com> wrote:
For encryption of traffic between datacenters; There should be very little session setup and teardown (very few public key operations); almost all the crypto load would be symmetric cryptography.
trivial at 9600 baud between google datacenters
* mikal@stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
Its about the CPU cost of the crypto. I was once told the number of CPUs required to do SSL on web search (which I have now forgotten) and it was a bigger number than you'd expect -- certainly hundreds.
False: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html "On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that." -- Niels.
On Fri, Nov 1, 2013 at 3:26 PM, Niels Bakker <niels=nanog@bakker.net> wrote:
* mikal@stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
Its about the CPU cost of the crypto. I was once told the number of CPUs
required to do SSL on web search (which I have now forgotten) and it was a bigger number than you'd expect -- certainly hundreds.
"On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that."
That was *front end* SSL/TLS - not internal / back end SSL/TLS. One could assert that the per-activity SSL/TLS overhead might be the same for internal services accessed to answer a front-end request, but that's not necessarily true. The code/request ratios and external/internal SSL/TLS startup costs are going to vary wildly from service to service. -- -george william herbert george.herbert@gmail.com
Hey expanoit, There was a small part that jumped out at me when I read the article earlier: "In recent years, both of them are said to have bought or leased thousands of miles of fiber-optic cables for their own exclusive use. They had reason to think, insiders said, that their private, internal networks were safe from prying eyes." It seems as if both Yahoo and Google assumed that since they were private circuits that they didn't have to encrypt. This would've added cost in engineering, hardware, and in the end, overall throughput; I would assume they saw it as a low possibility that anyone would (a) have knowledge of the their traffic inter-site and (b) would have the ability to not only accomplish the task but not get caught as well. This is just my take on the situation and I'm sure there are others more experienced that could offer a more detailed perspective with much less speculation. Thanks. Sincerely, Anthony R Junk Network Engineer (410) 929-1838 anthonyrjunk@gmail.com On Thu, Oct 31, 2013 at 10:48 PM, explanoit <explanoit.nanog@explanoit.com>wrote:
As a top-posting IT generalist pleb, can someone explain why Google/Yahoo did not already encrypt their data between DCs? Why is my data encrypted over the internet from my computer to theirs, but they don't encrypt the data when it goes outside their building and all the fancy access controls they like to talk about?
Thank you for your feedback, explanoit
On 2013-10-30 13:46, Jacque O'Lantern wrote:
http://www.washingtonpost.com/**world/national-security/nsa-** infiltrates-links-to-yahoo-**google-data-centers-worldwide-** snowden-documents-say/2013/10/**30/e51d661e-4166-11e3-8b74-** d89d714ca4dd_story.html<http://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html>
On Fri, Nov 1, 2013 at 4:43 AM, Anthony Junk <anthonyrjunk@gmail.com> wrote: ...
It seems as if both Yahoo and Google assumed that since they were private circuits that they didn't have to encrypt.
I actually cannot see them assuming that. Google and Yahoo engineers are smart, and taping fibres has been well known for, well, "forever". I can see them making a business decision that the costs would be excessive to mitigate against taping(*) that would be allowed under the laws in any event. Gary (*) "A" mitigation was run the fibre through your own pressured pipe which you monitored for loss of pressure, so that even a "hot tap" on the pipe itself would possibly be detected (and there are countermeasures to countermeasures to countermeasures of the various methods). And even then, you had to have a someone walk the path from time to time to verify its integrity. And I am pretty sure there is even an NSA/DOD doc on the requirements/implementation to do those mitigations.
On 11/01/2013 01:08 PM, Gary Buhrmaster wrote:
On Fri, Nov 1, 2013 at 4:43 AM, Anthony Junk <anthonyrjunk@gmail.com> wrote: ...
It seems as if both Yahoo and Google assumed that since they were private circuits that they didn't have to encrypt.
I actually cannot see them assuming that. Google and Yahoo engineers are smart, and taping fibres has been well known for, well, "forever". I can see them making a business decision that the costs would be excessive to mitigate against taping(*) that would be allowed under the laws in any event.
Gary
(*) "A" mitigation was run the fibre through your own pressured pipe which you monitored for loss of pressure, so that even a "hot tap" on the pipe itself would possibly be detected (and there are countermeasures to countermeasures to countermeasures of the various methods). And even then, you had to have a someone walk the path from time to time to verify its integrity. And I am pretty sure there is even an NSA/DOD doc on the requirements/implementation to do those mitigations.
Given what we now know about the breadth of the NSA operations, and the likelihood that this is still only the tip of the iceberg - would anyone still point to NSA guidance on avoiding monitoring with any sort of confidence? There has always been cognitive dissonance in the dual roles of the NSA: 1. The NSA monitors. 2. The NSA provides guidance on how to avoid being monitored. Conflict? -DMM
On 11/01/2013 01:08 PM, Gary Buhrmaster wrote:
[...]
Given what we now know about the breadth of the NSA operations, and the likelihood that this is still only the tip of the iceberg - would anyone still point to NSA guidance on avoiding monitoring with any sort of confidence?
There has always been cognitive dissonance in the dual roles of the NSA: 1. The NSA monitors. 2. The NSA provides guidance on how to avoid being monitored.
Conflict?
-DMM
As a local 'barbecue baron' said about his brother's competing restaurants: "I taught him everything he knows about barbecue. I just didn't teach him everything _I_ know about barbecue."
On Sat, November 2, 2013 6:44 am, David Miller wrote:
On 11/01/2013 01:08 PM, Gary Buhrmaster wrote:
On Fri, Nov 1, 2013 at 4:43 AM, Anthony Junk <anthonyrjunk@gmail.com> wrote: ...
It seems as if both Yahoo and Google assumed that since they were private circuits that they didn't have to encrypt.
I actually cannot see them assuming that. Google and Yahoo engineers are smart, and taping fibres has been well known for, well, "forever". I can see them making a business decision that the costs would be excessive to mitigate against taping(*) that would be allowed under the laws in any event.
Gary
(*) "A" mitigation was run the fibre through your own pressured pipe which you monitored for loss of pressure, so that even a "hot tap" on the pipe itself would possibly be detected (and there are countermeasures to countermeasures to countermeasures of the various methods). And even then, you had to have a someone walk the path from time to time to verify its integrity. And I am pretty sure there is even an NSA/DOD doc on the requirements/implementation to do those mitigations.
Given what we now know about the breadth of the NSA operations, and the likelihood that this is still only the tip of the iceberg - would anyone still point to NSA guidance on avoiding monitoring with any sort of confidence?
There has always been cognitive dissonance in the dual roles of the NSA: 1. The NSA monitors. 2. The NSA provides guidance on how to avoid being monitored.
Conflict?
I don't think so. The folks who actually do it, are the ones who are going to best know how to avoid it. Plenty of TV shows bear this out. :-) I think that failure to encrypt inter-DC traffic that is on dark fibre is simply on the presumption that corporations are seeking to protect their links from the actions of 'unauthorised' people. The telco theyre contracting presumably have some sort of privacy agreement with them. No-one else is supposed to be able to get on the wire. A risk assessment pre-Snowdon probably didn't make the performance hits, costs, etc of high-speed rateable encryption, worthwhile - but the paradigm has shifted. The government is using 'authorisation' to get access to that dark fibre link (presumably) and that authority is at the heart of the problem. When reviewing your risk assessment around the presence (or not) of encryption on your inter-site links, also consider whether the methods of encryption available to the private sector havn't also been cracked by the NSA etc. They had the 'golden standard' for crypto, but one has to wonder whether that standard includes an undocumented backdoor... Mark.
On 11/1/13, 1:08 PM, "Gary Buhrmaster" <gary.buhrmaster@gmail.com> wrote:
On Fri, Nov 1, 2013 at 4:43 AM, Anthony Junk <anthonyrjunk@gmail.com> wrote: ...
It seems as if both Yahoo and Google assumed that since they were private circuits that they didn't have to encrypt.
I actually cannot see them assuming that. Google and Yahoo engineers are smart, and taping fibres has been well known for, well, "forever". I can see them making a business decision that the costs would be excessive to mitigate against taping(*) that would be allowed under the laws in any event.
Gary
While smart, most providers make an assumption at least with a piece of dark fiber the only people with access to it are themselves and any providers of the fiber. I don't think that's an unrealistic expectation... Providers who have trenched their own fiber certainly do not encrypt traffic across the network, but their fiber is probably no less susceptible to tapping at certain locations. There have been a number of articles in recent years about how vulnerable the fiber infrastructure is to attacks, tapping, etc. Vaults, manhole locations, etc. are pretty much wide open. Phil
Anthony Junk wrote:
It seems as if both Yahoo and Google assumed that since they were private circuits that they didn't have to encrypt.
According to Snowden, there are government agents at key positions for managing security. When they declare the private circuits are secure, no one else in the companies can argue against. Unless they are fired and all the backdoors installed by them are removed, neither Yahoo and Google are secure. Masataka Ohta
On Fri, Nov 1, 2013 at 4:01 PM, Masataka Ohta < mohta@necom830.hpcl.titech.ac.jp> wrote:
Anthony Junk wrote:
It seems as if both Yahoo and Google assumed that since they were private circuits that they didn't have to encrypt.
According to Snowden, there are government agents at key positions for managing security.
When they declare the private circuits are secure, no one else in the companies can argue against.
Unless they are fired and all the backdoors installed by them are removed, neither Yahoo and Google are secure.
This is probably not entirely true, however... There is certainly enough in the Snowden docs to render this a valid question, and there is enough to assume some truth to the statement. Anyone familiar with secure organizations will realize this as the internal witch hunt problem. You now have serious reason to believe that you have been compromised. If security needs to be absolute, then the degree of response needed to succeed at attaining that will require very serious vetting of all the staff, of the nature of what national security organizations do (background checks, polygraphs, detailed personal histories, intrusive random monitoring of employee actions in and outside the office, etc). Most of "us" will not put up with that. However, most of "us" also desire reasonably secure services (both those of us who work for those services, and those of us who use them). The prior default setting was to assume there was nobody trying hard enough to penetrate those services that the internal witch hunt degree of internal security was necessary. It was "reasonable" to hope that someone with nation-state / superpower level resources was not actively Trying To Get In. Now that's not a safe assumption. The NSA has just put the entire profession in a horrible bind. By going beyond the foggy-but-legally-documented FISA warrant activities into active hostile actions against US providers we have to wonder about what degree of paranoia is necessary. Do we now just stick our heads back in the sand? Identify key security groups with override authority within our organizations, vet them and monitor them like the CIA and NSA vet and monitor their employees? Try to establish that level of review of all our staffs? Bruce Schneier has tiptoed around this some, but the thread from his blog last week of "How do we know we can trust Bruce" is terrifying when we have to consider applying that question to everyone on this list (and who should be on this list). -- -george william herbert george.herbert@gmail.com
On Fri, Nov 1, 2013 at 4:37 PM, Randy Bush <randy@psg.com> wrote:
Anyone familiar with secure organizations
there are such things?
we should be more cautious with absolutes, usually :)
Nothing is absolute, but there are certainly "white" organizations which have no attempt to be secure, and much greyer ones where it's a big deal in organizational process and ethos. A Snowden once a decade or so is not a bad record. Unfortunately, we ... hoped ... they were the good guys, not the bad guys. -- -george william herbert george.herbert@gmail.com
-------------------------- According to Snowden, there are government agents at key positions for managing security. ------------------------- And zero documented proof. I'll just go ahead and put my tinfoil hat on for the remainder of this thread. On Fri, Nov 1, 2013 at 6:37 PM, Randy Bush <randy@psg.com> wrote:
Anyone familiar with secure organizations
there are such things?
we should be more cautious with absolutes, usually :)
-- Jason
And zero documented proof. I'll just go ahead and put my tinfoil hat on for the remainder of this thread.
http://www.antipope.org/charlie/blog-static/2013/10/spook-century.html
George Herbert wrote:
Anyone familiar with secure organizations will realize this as the internal witch hunt problem.
No hunting necessary to fire those agents who are hired at the request of NSA/CIA. It is also reasonable to fire those who are hired by the agents, recursively. Masataka Ohta
On Sat, 02 Nov 2013 11:30:57 +0900, Masataka Ohta said:
George Herbert wrote:
Anyone familiar with secure organizations will realize this as the internal witch hunt problem.
No hunting necessary to fire those agents who are hired at the request of NSA/CIA.
Do you *really* think that HR has an entry on the employee's file that says "NSA suggested hire"? How do you intend to *find* the agents who were hired at a government agency's under-the-table request that never had a written record that the company had access to?
On Mon, 04 Nov 2013 09:14:40 +0900, Masataka Ohta said:
Valdis.Kletnieks@vt.edu wrote:
How do you intend to *find* the agents who were hired at a government agency's under-the-table request that never had a written record that the company had access to?
By memories of those who are at the table.
So one of the two people at the table you don't have a name for because they're not an employee, and the other is either an NSA plant lying about never being at a table, or you just gave your top network troubleshooter a damned good reason to update their resume. Hint: This isn't a children's game of hide and seek, and if there *is* an NSA plant they're not going to just smile and say "Oh, you found me". Good job at flushing out those NSA guys. Now who are you going to hire to replace them, and your top troubleshooter?
Judging from this NSA ad, keep an eye out minority disabled females.. [image: Inline image 1] On Sun, Nov 3, 2013 at 8:04 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Mon, 04 Nov 2013 09:14:40 +0900, Masataka Ohta said:
Valdis.Kletnieks@vt.edu wrote:
How do you intend to *find* the agents who were hired at a government agency's under-the-table request that never had a written record that the company had access to?
By memories of those who are at the table.
So one of the two people at the table you don't have a name for because they're not an employee, and the other is either an NSA plant lying about never being at a table, or you just gave your top network troubleshooter a damned good reason to update their resume.
Hint: This isn't a children's game of hide and seek, and if there *is* an NSA plant they're not going to just smile and say "Oh, you found me".
Good job at flushing out those NSA guys. Now who are you going to hire to replace them, and your top troubleshooter?
-- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- -
Valdis.Kletnieks@vt.edu wrote:
How do you intend to *find* the agents who were hired at a government agency's under-the-table request that never had a written record that the company had access to?
By memories of those who are at the table.
So one of the two people at the table you don't have a name for because they're not an employee, and the other is either an NSA plant lying about never being at a table, or you just gave your top network troubleshooter a damned good reason to update their resume.
Hint: This isn't a children's game of hide and seek, and if there *is* an NSA plant they're not going to just smile and say "Oh, you found me".
Hint: I'm not talking about a way to have perfect security. I'm talking about possible/good/recommended approach to improve the security without witch hunting.
Good job at flushing out those NSA guys. Now who are you going to hire to replace them, and your top troubleshooter?
Feel free to hunt witches if you think it necessary. Masataka Ohta
On Wed, 06 Nov 2013 08:50:06 +0900, Masataka Ohta said:
Valdis.Kletnieks@vt.edu wrote:
How do you intend to *find* the agents who were hired at a government agency's under-the-table request that never had a written record that the company had access to?
By memories of those who are at the table.
Hint: I'm not talking about a way to have perfect security. I'm talking about possible/good/recommended approach to improve the security without witch hunting.
You still haven't explained how "the memories of those who are at the table" help, when the NSA plant has very good reasons to say they're not an NSA plant, and you haven't explained how you can show they *are* a plant.
Valdis.Kletnieks@vt.edu wrote:
You still haven't explained how "the memories of those who are at the table" help, when the NSA plant has very good reasons to say they're not an NSA plant, and you haven't explained how you can show they *are* a plant.
That is a problem between NSA, which recommended a person, and the person recommended by NSA. Masataka Ohta
participants (19)
-
Anthony Junk -
berry＠gadsdenst.org -
Brandon Galbraith -
David Miller -
explanoit -
Gary Buhrmaster -
George Herbert -
Jacque O'Lantern -
Jason Biel -
Jimmy Hess -
Joly MacFie -
Jorge Amodio -
Mark Foster -
Masataka Ohta -
Michael Still -
Niels Bakker -
Phil Bedard -
Randy Bush -
Valdis.Kletnieks＠vt.edu