Incenser, or how NSA and GCHQ are tapping internet cables (2014)
electrospaces.net
electrospaces.net
With the proliferation of VPNs in recent years, many people are going to be targeted then, which perhaps is a good thing (the more people that leverage encryption for Internet privacy the better).
NSA & GCHQ must be getting very tired of all this cryptography, which has me thinking they have compromised several VPN companies or setup several VPN honeypot companies for their own purposes.
Another thing: being targeted with exploits because you use Tor must be an interesting thing to happen to you. I use secure endpoints and monitor all my traffic, and I've been using Tor since its inception.
Maybe they just don't want to target me because my systems are so hardened? I remain humble however, as everything can be hacked. Whatever exploits they have targeted me with, must be very good because I haven't spotted anything malicious (yet!).
My thought was to sell a VPN-business-in-a-box where you plug in your domain name, AWS creds, and payment details and in exchange you get a fully built VPN business including a web site, VPN nodes, iOS app ready to submit to Apple, and so on. Just add customers...
They most likely don't want to target you in the first place.
Yes, they're doing mass surveillance, but for the targeted stuff, they still have targets, and most of us won't make the list.
The bar seems quite low
"These variables define terms and websites relating to the TAILs (The Amnesic Incognito Live System) software program, a comsec mechanism advocated by extremists on extremist forums."
There is a huge difference between matching some of those criteria (which may cause your surveillance data to be retained longer) and actually being targeted for active attacks.
Regarding the longer retention, the Linuxjournal article says that "the Tagesschau story provides new details about how the NSA's XKEYSCORE program decides which traffic to keep indefinitely" but I found no such information in the Tagesschau story (http://web.archive.org/web/20141005083429/http://www.tagessc...)
The consequences of having traffic to one of the tagged sites were never really publicly explained, always just "THE NSA IS WATCHING SPECIFICALLY FOR (random thing the NSA had a selector for)". Given how many people match each of these selectors, just matching one of them can't mean that much.
How NSA and GCHQ are tapping internet cables - https://news.ycombinator.com/item?id=8680983 - Dec 2014 (60 comments)
This URL goes against our Community Standards on spam: electrospaces.net To protect people on Facebook from spam, we don't allow content that contains such URLs.
(I work on network security/integrity, including terrestrial and subsea optical, at aforementioned company).
The right (but useless) answer here is “Have a million dollar per month advertising spend, and talk to your account manager.”
You know the story Jack and the Wolf?
I looked at electrospaces website and I just can't figure out what cause it to be classified as "spam". Please, don't tell me it is AI because it has become so easy and convenient to avoid any responsibility by just saying "AI did it, not us".
Speaking generally, spam detection (even in email) often has as much to do with the behavior of whoever is trying to send a message as it does the content. I _suspect_ that a group of people were spamming it as evidence for their conspiracy theories and enough people reported the messages that it got added to a filter. Same thing happens with domains used for phishing (Google Safe Browsing), email spam filters, or other things.
Anyway, I'm not offended. I'm surprised that people here, upon hearing hoofbeats (spam), thought zebras (conspiracy to suppress information) instead of horses (spam filter false positive).
I'm sure someone will look into why electrospaces was marked as spam on Monday...
Usually, TLS is terminated on a load balancer and then the data in the data-centre flows in clear text. I is good practice to encrypt internal traffic but few companies do it because of the overhead. So "they" could sniff unencrypted traffic there, if they pay the data-centre providers.
Also, NSA is known to have modified network gear [1], so if they do that on a load balancer (or hack a software one) they can just sniff the encrypted traffic downstream and extract the session keys from the equipment. Then they can just decrypt the traffic without having to actually break RSA/ECC.
Other governments have had less subtle approaches by doing MITM attacks with compromised certificate roots, which is now somewhat mitigated with certificate pinning in modern browsers.
And of course there is the topic of secure protocols but compromised by design apps, such as WhatsApp. Even admitting that the Signal protocol is implemented correctly in WhatsApp, because the app is closed-source, they can read the unencrypted traffic from the app itself, and if they get caught doing it, they can say it's for moderation purposes [2].
If all of the above fails, you can always rely on Pegasus or similar. Once you have a rootkit on the device, you have access to everything in clear-text.
[1] https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa... [2] https://gizmodo.com/whatsapp-moderators-can-read-your-messag...
Exactly, this fact seems to have been lost on many. There's nothing wrong with using encryption on a day-to-day basis such as when we use https web pages, or buy something online, or when we don't want Google to read our email but it's another matter altogether when the stakes are much higher such as, say, leaking human rights abuses from within the confines of a totalitarian state.
When the stakes are high there are many other considerations to address. Not only do you have to consider what happens inside a server but also think about its physical security along with the possibility that data recovery tools may be used by the State to recover a copy of a critical email you sent after which you deleted. And that's just for staters.
An important rule to always assume and to adhere to before going online is that it's a safe bet that the State will be able to access anything you say or do on your PC, smartphone and or when you are online - and that it will be able to do so long after the event.
I think you misunderstand the purpose of dragnet, it is to identify targets of interest. Decrypting content is not needed, i mean it is desirable but even with sni encryption and DoH it is possible to identify targets of interest. Once identified,from what I have heard, they target your device or a common server targets of interest use, compromising those allows them to see much more than decrypted TLS.
Since we are speculating, what makes you so sure submarine cable tapping spies that can compromise cloudflare (or coerce) cannot do the same with say... Let'sEncrypt's root signing keys? They don't even have to mess with CT logs that way. Unless you are sayinf the handful of private keys used to encrypt most TLS traffic are impossible to compromise, even with nation state resources.
Doesn't it, at least, protect against snooping by (most) non-state actors? I'm pretty sure MI6 can break into my house, that doesn't mean I'm going to give up on locking my door.
Other than that and backdoored software (e.g. stuff using RSA Bsafe with Dual-EC-DRBG, which has an NSA backdoor, or those Juniper VPNs which used the same), I don't think they can do much about modern TLS besides exploit obvious flaws in the implementations.
Which unfortunately means they can do quite a bit as we've seen, implementation is often much trickier than theory.
It may seem natural to build such infrastructure for a life span of 20-30 years but do you remember what state of the art was back in 2001? Most of that is now basically considered broken. Software is living and should never be « set-and-forget »
Why shouldn't software be set and forget? Don't Ada and VHDL have massive amounts of re-use of things written in the 80's and 90's?
You only know it's correct after you verify the fact so formally that should read ...correct copy and verify routine.
Incidentally, we used to have switches to verify after copy such as /v but programming sloppiness and impatience - in having to wait extra time for the verify - has meant that the entropy for data processing integrity has increase as a consequence.
Right, no one seems to give a damn about such matters these days.
Even if you had bug-free hardware and formally verified software, your cryptography is broken and your kit has side channel issues that were never dreamed of 20 years ago.
I guess we can't really know unless there are more leaks.
So, where's the evidence? Without CT you could imagine that the spooks are snooping on everybody else and that's why you don't have any evidence -- they knew you were too smart, but with CT you can go look for evidence they snooped your grandmother's online bingo or your second cousin's Trump fandom forum, and well, seems like there just isn't any.
The Russians don't care if they're known to be doing crimes, that's why they sent assassins to England to murder an ex-spy and then offered the most stupid transparent lie about the men being "tourists". But the NSA is kinda sensitive about this stuff, they like plausible deniability. So, why would they choose a method that provides a signed paper trail proving they did it?
The security is found to be sometimes lax with these CAs. There have also been problems with audits, CTs and paper trail. I recommend this episode of the following podcast on security of CAs:
https://securitycryptographywhatever.buzzsprout.com/1822302/...
CTs help, but you really have to see who is behind them and how they are operated.
It’s known that hacking companies run CAs, accepted by Firefox and Chrome (at least for a period of time).
Either the certificate is included in the CT log, then the web site operator can notice that an illegitimate certificate was issued. This makes this approach risky, and infeasible against big services (since they presumably monitor CT logs for misissuances for their domains).
Or it isn't included in the CT log, then the certificate itself is a digitally signed admission of incompetence by the CA, and IIRC at least some browsers will reject the certificate if it doesn't have a CT receipt (SCT) from at least one accepted log.
The remaining options would be to compromise (or compel) an accepted CT log to issue SCTs without recording the certificate. This would require attacking two entities, and if caught (i.e. the victim noticed the cert wasn't in CT), would mean the end of the log.
These do not guarantee that such an attack will be discovered or stopped, but let's not pretend that these didn't massively raise the stakes for attacks against CAs. Previously, if an intelligence service could get a CA to misissue a certificate, they could only be caught if the victim identified the certificate as misissued, stored a copy, and even then it'd become a he-said-she-said.
You'd have to compromise at least the CA, and Google, and one other log operator. All the clients that care about SCTs have effectively the same requirement today, certificates must be logged by Google and by a trusted party which isn't Google. For example, you might get a certificate from Let's Encrypt, logged by Google and Cloudflare before it was delivered to you by Let's Encrypt.
This + some of the other news about how they handle privacy make me doubt how prudent it is to use Firefox, from a security/privacy perspective :(
However, although Firefox doesn't check SCTs, I believe you can add an extension to do this with the same policy everybody else has. Also, in practice all CAs in Mozilla's trust programme more or less have to use CT because Mozilla's incident process assumes you have working CT logs.
But yes, it would definitely be better if Firefox just checked SCTs even if they have to suck it up on the policy neutrality for compatibility reasons.
It would also be be nice if all clients that check SCTs implemented a Gossip protocol, and some other steps to complete CT as originally conceived. As shipped, today's clients would not reveal e.g. a split horizon CT log visible only to some particular group. It's just that we have every reason to think that this tree is bare of fruit, and so meticulously searching the highest branches is a much higher cost for likely no extra reward.
I'm going to give the same example I always do. In 1977 they standardised DES. DES was already publicly known to be weak in two specific ways, the keys are too short (56-bits), and the block size is too small (64-bits). This was done intentionally. Today you can break DES... by exploiting these two weaknesses with today's cheaper hardware. No other meaningful attacks on DES worked, it has performed exactly as designed for well over forty years.
At the turn of the century DES was replaced by AES. AES has 128-bit or 256-bit keys, and 128 bit blocks. So, brute force attacks known to be viable for DES are never going to be possible for AES because physics. You would need one of those mathematical breakthroughs that never happened for DES in, as I wrote, almost fifty years. Don't hold your breath.
Because of this, encrypted material probably gets less valuable over time, as keys which did exist and might become available to you in future are instead lost or destroyed. And the pace accelerates. With TLS 1.2 it was plausible that you (assuming "you" are a powerful adversary able to do stuff like seize people's property) could seize a running HTTPS server and use its "ephemeral" secrets to decrypt traffic from yesterday, or maybe even last week, but in TLS 1.3 the mechanism is more fleeting, perhaps you can decrypt messages from ten minutes ago, but without the client's help perhaps not at all.
I have to wonder what kind of information is useful enough to wait forever for? What kind of personal information of mine, for example, will be useful after I'm dead? There may be something.
Even if we look at state actors it doesn't change - if China's government manages to decrypt something the UK has that is useful now, like some advanced technology, will it still be advanced when its encryption is cracked? Slow them down for even 20 years and it'll be too long to wait.
If not, then you’re wrong about it being a platitude because you’ve given absolutely no reason how that data will be useful, other than ”who knows, a way might suddenly appear to decrypt all of it”. Maybe they’ll also invent a time machine but I’d prefer to stick to the realms of reality rather than sci-fi when assessing risk.
Forever is a long time. The point made above is valid, which is that data devalues greatly over time.
Take in point the famous case of the Zodiac Killer: https://en.m.wikipedia.org/wiki/Zodiac_Killer. Recent work seems to suggest that his encrypted messages are close to being solved (decrypted). If in fact we do have a solution and we've learned his identity then this information is of much less value now than if it would have been available 50+ years ago. For starters, it seems the killer is now dead. Thus, being able to decrypt his messages after this lengh of time is of little practical use other than of academic interest and or offering some resolution to his victims' families.
The value of encrypted data held by the NSA and GCHQ in anticipation of finding a decryption key will rot in exactly the same way. In short, it's only worth keeping the data whilst it's potentially useful.
But, 3DES is still DES, the blocks are still 64 bits which is too small. Sweet32 is an example of a more-or-less practical attack (practical enough to demo, but probably never used in anger) that breaks 3DES for HTTPS by "just" moving a couple of hundred gigabytes of data over the wire.
Lucifer (the cipher that the NSA cut down to make DES) used 128-bit keys and 128-bit blocks. It is vulnerable to differential cryptanalysis (which the NSA knew about before academics discovered it, and so the NSA fixed it in DES). If you imagine Lucifer was instead fixed by a similar technique to the one used in DES but not shortened to provide a NOBUS there's no obvious reason Lucifer would be insecure today. There are most sophisticated analysis techniques than differential cryptanalysis today, but the defences in DES warded those off, and so you might expect similar for Lucifer.
The smaller fry may or may not be compromised, but it wouldn’t take more than trivial effort for them to become compromised if the NSA wants in.
Any commercial VPN you can install, is likewise already compromised. You could install your own endpoints at a service provider, but all those service providers are already compromised (see above).
I’m sure that TOR was hard for them, and may still offer some challenges, but I’d be really surprised if they can’t compromise it when they want to.
And I’m also certain that I personally remain a person of interest for them, based on some things I said back during Crypto Wars I. I’m sure there’s a lot of people above me in the list, but I’m also certain it’s a fairly long list and that I’m on it.
So, I think the only thing a reasonable person can do is to continue to operate their lives, make sure they address the non-nation-state attackers that they can, and try not to attract the attention of the NSA.
Documentary about the cable landing stations: The Secrets of Cornwall
I'm not sure if I've got the picture right. Someone more informed than I please help.
First, let us set the scene with a precedent - the famous WWI Zimmermann Telegram of 1917 where Germany and Mexico were concocting a secret deal that wasn't in the interests of the US or UK which was tapped and successfully intercepted: https://en.m.wikipedia.org/wiki/Zimmermann_Telegram.
I only mention this 100-year-plus case as it'd be at the forefront of any planning for any undersea cable, transatlantic otherwise to see such incidents are not repeated. OK, so where are my assumptions wrong here?
1. Cable operator of say US-UK link doesn't want a tap put on cable in mid Atlantic by a third country so takes the necessary steps by encrypting all its data.
2. Cable operator knows both US/NSA and UK/GCHQ will want to tap cable at their respective ends (i. e.: on land). No problem, as the cable operator has no say in the matter anyway.
3. To stop undersea tapping by third party, cable is encrypted at cable stations at either end. Multiple levels of encryption are employed: fibers are encrypted either individually or collectively so only a raw encrypted datastream appears on the undersea section of circuit; that is, the only discernible IP address information on the cables is that necessary for the cable stations at either end to TX/RX data across the Atlantic. Thus an attack in the middle won't reveal who is using the cables nor their IP addresses (as they too will be encrypted as part of the overall encrypted datasteam).
4. Third-party counties, for argument sake, say Mexico and Germany that are also using the cable will similarly encrypt and obfuscate the source and destination IP addresses of all their users in a similar manner using an all-encompassing encrypted datastream. So effectively the NSA and GCHQ can only inspect their own local traffic, which they do on land at their respective cable stations after the undersea section of the link has been decrypted.
5. As, we've made Mexico and Germany the adversaries, we can expect them to not only encrypt data and obfuscate source and destination IP addresses of their users by multiplexing all data into a common encrypted datastream but also obfuscate the amount of traffic they're sending. They will likely achieve this obfuscation by using say an encrypted token ring/FDDI-like system, then the datastream would appear to be a constant quantity irrespective of the actual circuit load.
6. In essence, why do countries still try to tap undersea cables with submarine taps when they'd only pick up encrypted 'garbage'? Alternatively, why do cable users leave themselves vulnerable to tapping when they could employ methods to obfuscate not only their data but also how they are loading (using) said cables?
Right, I've greatly oversimplified the issue but the gist of my point is there.
You can always encrypt traffic that needs it at higher layers; most of these sorts of links were not themselves bulk encrypted.
MUSCULAR, for example, allowed the spies to tap WAN links between Google sites, which were at the time unencrypted as it was only Google-internal, even though it went hundreds of miles out of the buildings.
Those links are encrypted now. Google SREs were not happy about being hacked by the NSA.
I was told by SREs that they weren't encrypted before due to the CPU overhead that it would entail, as Google moves a lot of data. Once the threat wasn't theoretical, they were encrypted quickly.
I'm surprised that encryption wasn't (still isn't) the default for all submarine cables given the very high stakes involed - international espionage, their vulnerability and the long history of undersea cable tapping (which I didn't mention above).
You say "Encryption at these data rates was only recently within the realm of feasibility". Right, but 'recently' has been quite a while now - I'd estimate 10-20 years or so as we've had erbium optical switches, etc., in common use for that length of time.
It's now over 25 years since I was first involved in some high-stakes intergovernmental stuff where authentication and encryption were the normal default thinking (it was inconceivable that we'd transmit data across any link or network that was potentially vulnerable to attack unless the data was encrypted and full authentication was deployed). We used common carrier networks and submarine cables would have to have been involved but we did not administer them - hence our assumption that they were vulnerable to attack.
Whilst I wasn't involved directly with those security services, it was clear to me that at the time they didn't want encrypted circuits. Thus, it seems likely that at least part of the reason for the lack encryption even now would have been pressure from them not to deploy it in common-carrier networks.
Only private industry was pretending long haul cables were reasonably private, and even they aren't making that mistake anymore.
Maybe that's why they chose to be known by an acronym for "Garbage Collection Headquarters"