Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yes I'd quite happily throw out 15+ years of intense study and research (inclusing SSL/TLS) as it occasionally breaks down and kicks you in the face (google for TLS MITM vulns).

There should be an explicit trust model where the service vendor ships your keys via an alternative side channel -or- a decentralised model which works on reputation or trust.

If it works, why do all the online banks use two-factor authentication these days?

Oh wait, there is the solution!



At the current rate of discovery, every vulnerability in TLS should make you more confident in the protocol. We're running an average of 3-5 years between protocol-level discoveries in TLS. Each one is the product of, literally, millions and millions of dollars of adversarial research.

Psst. I've got news for you. adb56780a76686326612a1eb3c2b32053bbcf3d8. Ask a friendly vulnerability researcher what I probably meant by saying that. Guess what? More confident as a result of knowing it.

The rest of your comment is just pique. "Why do online banks use two-factor auth?" Because the alternative is passwords. "There should be an explicit trust model!" Go ahead and build it. Because TLS is well-designed, your new scheme will work just fine with it.


> adb56780a76686326612a1eb3c2b32053bbcf3d8. Ask a friendly vulnerability researcher what I probably meant by saying that.

OK. Hey tptacek... :)

Mind elaborating a bit more, for those of us who don't happen to know any other vulnerability researcher who know what that hash means? The one vulnerability researcher I know had no idea what you were talking about.


Here's another request for elaboration...

(and a meta-comment; OMG, look how quick google is getting hackernews into it's index these days!)


I'll let someone else explain, and let me be clear: not my bug.


I assume you're referring to the practice of releasing hashes of one's advisory to prove that you discovering it while giving the vendor time to fix their software before disclosing it publicly.

Google doesn't turn up anything for that particular hash, though, nor did I see anything on the Matasano website, but I'm probably looking in the wrong places. I don't claim to be a security researcher, after all, even if I try to keep up to date.


Ouch, that was a bad typo. I meant "discovered" not "discovering" and it's too late to edit.


So why did you say it and direct people to ask researchers what it means, if pretty much no one does?


> We're running an average of 3-5 years between protocol-level discoveries in TLS.

Everyone knows the weakness with our current system isn't the protocol--it's the "trusted" roots. There are upwards of 100 organizations that have roots installed on my computer and each of them is an attack surface. And it's frustrating because if I'm Google, there's no way I can protect myself from these other firm's security flaws. That is the part of SSL/TLS that needs to change. Getting certs from DNSSEC would be a good start...


Getting certs from DNSSEC is morally equivalent to getting them from X509 PKIs.

Again: the problem we have is that the UX and policy for HTTPS/TLS is brittle, so that it's hard to recognize and even harder to react to misconfigurations like "we're trusting CAs who are not trustworthy".

Faced with a policy and UX problem, someone needs to explain to me how a reasonable next step is to bake a new PKI into the core of the Internet.

There is a reason the IETF-types are so gung-ho on DNSSEC. But it isn't that they know it's a sound replacement for the CA system. It's that it bothers them that DNS- the- protocol is insecure. And that's fine (I think their solution stands a good chance of making DNS even less secure, but whatever). But they shouldn't get to piggyback on other security issues to achieve their goal.


That we know about...


If it works, why do all the online banks use two-factor authentication these days?

I don't know about where you are, but even if I show up at my bank branch in person, they do two-factor authentication (card + PIN).


The card is not enough to authenticate you. It is enough to identify you. Slightly different concepts.

So card = identify. PIN = authenticate. That's not two factor.

The second factor would be an RSA key or a Digipass device.


You are using the words "authenticate" and "identify" in ways that professionals do not. In reality, a card and a pin are two factors in an authentication system; your fingerprint is a third (biometric) factor which does not need yet another synonym for "identify" to describe; the reputation of your origin IP is a fourth factor, your behavior a fifth.


If it works, why do all the online banks use two-factor authentication these days? Oh wait, there is the solution!

That's used to authenticate the client. SSL's job here is to authenticate the server. So no, that's not a solution.

Besides, it's completely preposterous to claim that HTTPS is useless just because it's not enough for banks. Should each website send an RSA Token to each user?


I've been quietly hoping that perhaps Google's Authenticator app might provide this for us... If there were a way for one of my websites to seed the Authenticator, I could provide an RSA-token-like 3rd factor to my logins effectively for free (at least to anyone with an iOS/Android device).

(I don't suppose anybody's more up-to-date than me on if/when that'll be possible?)


Two factor auth is more about stopping your login details being nicked and then used at a later time - not atall really a question of SSL, not to mention that as far as I can see this attack here would not be affected by it in the slighest except for future login attempts.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: