61–70 of 112 posts
Earlier quoted context omitted.
The expectation is that the encrypted link is not decryptable by a third party. If that isn't always true in the face of an adversary then claims of forward secrecy for TLS 1.3 are false.
The expectation is that the encrypted link is not decryptable by a third party if both parties are implementing the protocol in good faith.
Earlier quoted context omitted.
Do you have any example of such applications that would be used by a bank?
I don't work for a bank so I can't speak definitively to their applications. A few sample applications I see listed as certificate pinned in Netskope (a CASB) though include: Adobe Creative Cloud Amazon Work Spaces Docusign GitHub Google Drive GoToMeeting iCloud Microsoft Office 365 Outlook.com Microsoft Skype for Business Salesforce.com Note this typically refers to native applications and plugins which also connect…
I'm a bit surprised by Skype for Business (horrible product BTW, it's a gamble to even be able to sign in on a fresh install) though, the rest I would expect people to use web versions of.
I would think that (perhaps coincidentally), the organizations that require these kinds of insights are not the ones that are relying on services that do cert pinning. And if they do, they can but the marketing department/the server running THAT wonky old software from the 90s in a separate subnet.
Yeah, let's just make it harder for banks to protect your money so that nobody can figure out your Facebook password in 10 years. EFF: "Everything sent over the network should be a secret! Nobody has a good reason to inspect traffic, it puts users' privacy at risk!" Bank: "We keep trillions of your dollars. Inspecting our own traffic is how we make sure nobody is stealing it. We're a pretty big organization, so this…
Not necessarily trivial but not exactly impossible for someone who controls one of the endpoints.
Active interception with a middlebox still works exactly the same as it always has.
Earlier quoted context omitted.
The other side of the argument is frequently discounted and as an IT security person myself I understand that. However, there is a real challenge for companies who deal with large amounts of very sensitive data. To be able to effectively monitor for data loss it makes a lot of sense to be able to monitor the connection points between your protected network and outside networks. The move to all traffic being encrypted…
> Or do you employ an official to help pack the belongings of each individual who you think may eventually cross the border? Without telling the person who's things were packed that they were packed by the official.
It’s worth reading the mailing list posts by BITS (the main proponent of ETS) here: https://mailarchive.ietf.org/arch/msg/tls/KQIyNhPk8K6jOoe2Sc... . The replies are pretty informative. You can see here the message in which BITS starts to consider fixed DH keys, which were implemented in ETS: https://mailarchive.ietf.org/arch/msg/tls/3d7TM0g_EdtMzhgmcP... > Tue, 27 September 2016 18:21 UTC > The various suggestions f…
If you think about it, given the retention requirements they have, it's not clear that forward secrecy is useful in that context.
It's not "useful" if your goal is to intercept and decrypt messages that are supposed to be secure, which is what both regulated entities and baddies want to do.
If you don't require forward secrecy you introduce a weakness. The protocol won't distinguish between whether that weakness is being exploited by regulated entities or baddies.
You don't need to weaken TLS in order to do what the regulated entities want to do - you just need to do the retention on the endpoints. The issue isn't that they can't do that, it's that they don't want to do that, probably for cost or convenience reasons. Those aren't reasons to weaken TLS for everyone who actually wants secure comms.
We need a big budget cut in the "homeland security" area. All this interception is not paying off. The biggest "terrorist event" in the US since 2001 was the guy who shot up a gay nightclub in Orlando FL in 2017. That was a solo nutcase; there was no planning chatter to intercept. The Boston Marathon bombing was two brothers. The San Bernardino shooting was a husband and wife. What's discouraging terrorism is the US'…
Also, cutting the government's budget would not impact the cost of compliance to corporations.
This is a remarkable story. Fortunately, this ETSI-backed "ETS" standard appears to have just about zero uptake or internet presence, let alone vendor acceptance. So although this is fairly outrageous based on the EFF article, it doesn't look like something that's a big threat to TLS at this point. PS. I can't even get ETSI's website to load! https://www.etsi.org/
If you're having trouble getting etsi.org to load, try using their static key for diffie-hellman: 0x00000000.
Earlier quoted context omitted.
If you think about it, given the retention requirements they have, it's not clear that forward secrecy is useful in that context.
Forward secrecy is always useful for two endpoints that want to have a secure exchange of messages. It's a core component of secure transport these days. It's not "useful" if your goal is to intercept and decrypt messages that are supposed to be secure, which is what both regulated entities and baddies want to do. If you don't require forward secrecy you introduce a weakness. The protocol won't distinguish between wh…
So what's the argument from the other side? Going through all this effort to allow PFS to be disabled seems like a ton of work? What's their use-case?
If your stance is: No opaque data leaves my network Then this is the only way you can have outbound HTTPS connections. And for e.g. a bank, certain legal firms, or any company that has a lot of sensitive data they either don't want to be leaked, or at least want the option of detecting when it is leaked, that is a somewhat reasonable stance. In the case of banks, this is needed for regulatory compliance regarding ins…
This expands to any IoT device with proprietary software on it, which by 2023 will be quite a lot of things.
Earlier quoted context omitted.
If you think about it, given the retention requirements they have, it's not clear that forward secrecy is useful in that context.
Forward secrecy is always useful for two endpoints that want to have a secure exchange of messages. It's a core component of secure transport these days. It's not "useful" if your goal is to intercept and decrypt messages that are supposed to be secure, which is what both regulated entities and baddies want to do. If you don't require forward secrecy you introduce a weakness. The protocol won't distinguish between wh…