IETF To Change TLS Implementation In Applications 80
Trailrunner7 writes "The NSA surveillance scandal has created ripples all across the Internet, and the latest one is a new effort from the IETF to change the way that encryption is used in a variety of critical application protocols, including HTTP and SMTP. The new TLS application working group was formed to help developers and the people who deploy their applications incorporate the encryption protocol correctly. TLS is the successor to SSL and is used to encrypt information in a variety of applications, but is most often encountered by users in their Web browsers. Sites use it to secure their communications with users, and in the wake of the revelations about the ways that the NSA is eavesdropping on email and Web traffic its use has become much more important. The IETF is trying to help ensure that it's deployed properly, reducing the errors that could make surveillance and other attacks easier."
End of certificates, please? (Score:5, Interesting)
Re:End of certificates, please? (Score:3, Interesting)
We did it wrong, let's do it wronger still. (Score:2, Interesting)
Consider this scenario: You're about to connect to a resource, but the service says you need to authenticate. So, a browser native login box pops up. You enter your credentials and those are hashed with the session nonce to key the symmetric ciphers, the connection then commences since the server already has a shared secret with you. It's not like HTTP Auth doesn't exist, it's just that TLS is ignorant of HTTP. If you have a secret GUID on the system, you can hash the domain name of the server with it to produce a unique user ID for each server. Same goes for a master password: HMAC( MPW, Domain + Salt ) = Session generator. HMAC( gen, nonce ) = session key. There, now you don't have to create a new account everywhere you go. One login for everywhere, and the sites can associate a nickname with the UID code if they want. Change your salt and you change all logins everywhere without having to change your password. Only time public key crypto is needed is when you exchange the UID and generator, for everything else use symmetric encryption with the pre shared secret. The window is small enough that PKI is moot.
Besides all the browsers explicitly trust cert roots in known enemy states, so PKI is moot anyway. FF > Preferences > Advanced > Certificates > View Certificates > Hong Kong Post... They can create a cert for Google.com without Google's permission and if they're a MITM, you get a big green secure bar and everything. No one checks the cert chain every time (shouldn't have to), and even if they did the govs can compel the CAs to generate certs under secret orders, or just infect them with a zero-day and do it themselves. All your retard is belong to IETF.
Oh, hey, while you brilliant bastards are at it, why don't you give us salted hashes in the HTML tags that pull in external resources? This way the encrypted page can specify validation codes for the external cache-able content and we can be sure it's not tampered with. Let's end that whole "mixed content" warning bullshit by making HTTP and TLS minimally aware of each other. <img src="..." hash="SHA2/base64: SUVURiBpcyBhbiBveHltb3Jvbi4K" salt="..."> Wow! How fucking difficult is that! Oh, snap! There must be some kind of alien super intelligence infecting my brain, hide your kids, hide your whitepapers!
Oh, That's Right. TRANSPORT Layer security. Ah, gotcha. Sorry, wouldn't want to make you all look like a bunch of morons by suggesting that the layers are just arbitrary lines you don't let interactions across for no damn reason except to further ensure nothing on the net is fucking secure. You know, not like it didn't take me all of one session thinking about this while taking a shit to figure out how you ruined everything, IETF. Internet Eradication Terrorist Fucks? That's what it means, doesn't it?
Earth: The longest running case study in how not to advance as a space faring race.
First things first, limiting CA's scope, please. (Score:5, Interesting)
One of the major problems is that currently no limits to what a CA can sign, and even though there is a urgent need to do major revamp to the protocol, I would like see first that TLS 1.next would at least fill that gap.
Can someone, please, if they can justify why for example Türktrust can sign a certificate for a *.gov and .*mil domain? Or why Spanish CA issued a wildcard *.google.com to someone, please?
Limiting that to happen, should be a minimum short distance goal, implementation shouldn't be delayed many years but possibly starting from beginning 2015.
There are many ways to implement these. Adding OID's to root certificate stating policy TLD's which CA is authorized and then also verified from TLD controlling party DNS query asking RR's for that CA whether policy is current and not revoked. The protocol could be lightweight DNSCurve for example. But like I said, there are many ways doing it. Hardest one to solve would be those where no connection exist to network before offered certificate, such as 802.1x/EAP, without chicken-and-egg problems.
IMHO, now founded new work group should concentrate longer period development, but first things first. The big gaping hole in current implementation should be fixed ASAP.
Two years ago a post (Honest Achmed's Used Cars and Certificates [mozilla.org]) to apply root CA from Mozilla was funny, but not any more. The there are so many incidents with falsely issued certificates, even root certificates, that they could have admitted root to Achmed and his brother who knows few things about computers and situation wouldn't have been much worse by now.
Re:We did it wrong, let's do it wronger still. (Score:5, Interesting)
Well, I can't really make out what you're proposing here.
As far as I can see, the client side has three secrets to maintain - the GUID, master password and salt. If the GUID is unique to a computer, your accounts only work from a single machine, and if you lose the GUID then you lose access to all your accounts. Correct?
The nonce is a "number used once" - i.e. randomly generated for each session in a cryptographically sound way.... so how do the server and client negotiate the nonce for each session? Does one pick it and encrypt it to send to the other? Do they both participate in picking it? Do they use something like Diffie-Hellman to arrive at the value?
I really don't understand your point about changing the salt equals changing your logins without affecting your password. Do you mean if I wanted to lose access to all my accounts everywhere and begin again, I wouldn't have to change my password?
And... how do you know you're talking to the right server in the first place? I don't see any server authentication at all in your proposal.
That's enough for now. The one thing I've learned from studying protocols is that it's really, really hard to get right. Not because the people creating them are dumb or have malicious intent. It may well be time to start creating a new protocol to replace TLS eventually, using what we now know about trust, authenticated encryption, protecting the handshake and side channel attacks. And possibly using some new techniques in there, like identity-based encryption...
Re:End of certificates, please? (Score:5, Interesting)
Making encryption stronger is just pointless if you can fake a ceritificate.
We should start, by allowing certificates to have multiple signers
Instead of everyone trusting a small number of CAs --- the certificate should bear a number of signatures, and you should be able to score a certificate based on how much you trust the signers.