Curious if they can also tap encrypted content? Maybe for high interest targets a certain amount of cracking power can be directed to it?
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.
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.
Which unfortunately means they can do quite a bit as we've seen, implementation is often much trickier than theory.
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 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.
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.
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.
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.