UK Gov Says New Home Sec Will Have Powers To Ban End-to-end Encryption (theregister.co.uk)
An anonymous reader writes: During a committee stage debate in the UK's House of Lords yesterday, the government revealed that the Investigatory Powers Bill will provide any Secretary of State with the ability to force communication service providers (CSPs) to remove or disable end-to-end encryption. Earl Howe, a Minister of State for Defence and the British government's Deputy Leader in the House of Lords, gave the first explicit admission that the new legislation would provide the government with the ability to force CSPs to "develop and maintain a technical capability to remove encryption that has been applied to communications or data".
This power, if applied, would be imposed upon domestic CSPs by the new Home Secretary, Amber Rudd, who was formerly the secretary of state for Energy and Climate Change. Rudd is now only the fifth woman to hold one of the great offices of state in the UK. As she was only appointed on Wednesday evening, she has yet to offer her thoughts on the matter.
This power, if applied, would be imposed upon domestic CSPs by the new Home Secretary, Amber Rudd, who was formerly the secretary of state for Energy and Climate Change. Rudd is now only the fifth woman to hold one of the great offices of state in the UK. As she was only appointed on Wednesday evening, she has yet to offer her thoughts on the matter.
Again, idiots in government finds new ways to turn law abiding citizens into criminals, or even terrorists.
Eurasia and Oceania now have the same legislation like so
Any American who has actually been to the UK (or outside of the US) isn't surprised at all. Travel is good. It teaches you there are morons everywhere.
People have been on TV saying that they voted because of racism. Racist attacks have increased since the Referendum. Arsehole.
"We must never stop at all until we see the day when nuclear arms have been banished from the face of this earth." -- Ro
The government also says (on page 39) that the new law provides nothing more than what is already present in the Regulation of Investigatory Powers Act (2000). It specifically refers to "the ability to remove any encryption applied by the CSP to whom the notice relates" (my emphasis), and not to end-to-end encryption.
Internet security is not an illusion, but if the threat you care about is powerful enough, the CA system is just about the worst possible way to establish a basis of trust. Any CA can sign certs for any domain. If you have a powerful adversary that can co-opt a CA, you have a completely false sense of security. It's really easy to get users to trust rogue certs signed by real CAs, because it happens automatically with no user input!
Even worse, a less powerful adversary, like a browser maker or computer maker can undermine your system by installing trusted fraudulent root CA certs which should not be trusted to man-in-the-middle your TLS connections. Opera, Lenovo and Dell have all done this to name a few.
I work at a university, and to connect to the wireless, you need to "trust" a self-signed certificate. In some operating systems, you have to specifically follow some installation instructions for installing a cert manually, but on Windows and OS X, I think you just click "trust this certificate" and it pins the cert. I work in computer security (but in research, not IT). I have to explain this decision to many people who say it's insecure. Actually, it's more secure, because it forces even dumb users to pin a certificate that doesn't chain up to an public CA. Once you install the self-signed cert, it will warn you if it changes (I actually, don't know what the OS would say). This converts the certificate from the CA model to a trust-on-first-use (TOFU) model. Clearly the Uni's IT are no dummies.
TL;DR: I learned how terrible the CA system actually is in undergrad over 15 years ago. Only recently, however, has it become clear that powerful adversaries are seeming exploiting this weakness. I have no idea why there isn't more interest to actually change it, rather than just a lot of talk.
No. Read up on how the Great Firewall of China works. If the client requests a secure connection, and doesn't accept a certificate signed by the State MITM Attacker (claiming to be the connection target, if necessary generated on the fly) the connection goes no further. It's actually quite simple.
It can be worked around by letting the State MITM the connection with a proxy, then using real security for the connection through the proxy. Don't get discovered, though: doing this is terrorism. And proxies as they are discovered turn into honeypots leading to more terrorists. Your continued freedom depends on the operational security of everyone using the proxy, and on luck besides.
Let's say I am an ISP and I have a data stream coming through my system. How do I know if the data is encrypted or not? Data is data. Neither IP nor UDP packets have an 'encrypted data' indicator.
How would we differentiate between an encrypted data stream and a video stream in a new movie format? What's the difference between decrypting vs displaying a movie? Both processes are a conversion operation being performed on a data stream.
Simple. Packet capture and look for the key exchange. I do this daily.
If you have the private key, you can listen in on encryption. If you do some monkey business in the protocol, you can make a passive eaves drop impossible even in this situation; in which case, if you have the private key, you can insert yourself in the network path and mediate the conversation, thus accessing the plaintext while posing as the end server in a way the client is 100% incapable of identifying and unable to mitigate.
Having one end hand over the keys does, in fact, completely remove end-to-end encryption for that eavesdropper.
Support my political activism on Patreon.
The real "Libtards" are the Libertarians!
Next they will ban two people talking alone at the pub over a pint.
YMMV. It depends on the application and the implementation.
Modern Apple and Microsoft dot1x supplicants do pin on first use, but the only consequence of that is if someone spoofs a cert, the user gets a popup, and how they react to that depends on their training.
Android dot1x supplicants won't, and won't even allow you to pin a particular CA to limit exposure when using a public CA, nor even check the DN, so you are vulnerable to any old stolen key/certificate pair signed by a CA in the base OS trusted list.
If you set it up by hand, wpa-supplicant for Linux has the ability to pin either a particular cert or a CA/DN. Various GUI config tools may or may not support setting these options.
For IPSEC VPN, Windows supplicants cannot pin a CA/DN unless you use EAP-PEAP-MSCHAPv2 either for L2TP/IKEv1 or as the auth protocol in IKEv2, and it must be pinned manually or through a setup/install script. If you use EAP-MSCHAPv2/IKEv2 there is a check that DNS matches the DN, but that's not much extra security if your OS store includes a compromised CA, and Windows also cannot support DH groups higher than modp2048 in a RAS dialer, only in the decidedly user-unfriendly firewall policy feature set. Some 3rd-party VPN clients improve things slightly but often still play it loose with the store/validation. If installed through a mobileconfig, OSX and IOS do support locking things down, I think... that's next on my list of things to kick the tires on. Strongswan on linux pretty much kicks ass, once you've patched it up past the oopsie they had with the EAP state machine, but again, not an end-user-friendly animal so you are at the mercy of GUI tools to not be setting things up wrong.
The whole crypto landscape is a bit of a mess on the client side... the above doesn't really scratch the surface.
Someone had to do it.