Comments on Asgeir S. Nilsen tenker litt: TLS: A Broken Trust Model

The security of DNS is a separate issue, and TLS a...

2009-08-06T21:32:42.161+02:00

The security of DNS is a separate issue, and TLS actually solves this problem. This doesn't have much to do with DNSSEC. If the DNS is spoofed, even if the CN of the server certificate matches the spoofed hostname, it won't (or shouldn't be certified) by a CA you trust. This trust can be enhanced by EV certificates.

Regarding your second example "The last time I registered with a new bank the welcoming package was delivered to me via certified mail where I had to identify myself with my passport.", that's exactly the same problem of logic as in your first suggestion ("1. The browser issues a digital certificate"): the fact that you identify yourself with your passport does not mean that what you're receiving comes from a legitimate source. It's up the the sender to identify itself first.
The same problem exists with client certificates and hardware tokens: there's no point sending your client certificate to a server you haven't verified. That's where the man-in-the-middle attack may come from.

What you would want from your bank is to go to their branch (assuming that it's a place you can trust) and ask them for their certificate or fingerprint in person, so as to be able to verify it when you connect to their website later. It's relatively easy to do for shops that have physical branches you can trust (assuming they're all real shops), but it becomes much harder for companies you can't get hold of physically (e.g. Amazon, etc.). That's why you need trusted intermediates such as commercial CAs.

I totally agree with the fact that few users really understand warning messages (and act upon them correctly), but checking each certificate isn't necessarily easier.

Thanks for your comment. You are absolutely right...

2009-08-06T20:31:56.468+02:00

Thanks for your comment. You are absolutely right regarding my first suggestion and it being vulnerable to a man-in-the-middle attack. However, TLS is here trying to fix a problem with DNS; the fact that you cannot be sure that the DNS server you are talking to is serving the correct data for a host name.

This is something DNSSEC or OpenDNS attempt to fix.

My second suggestion is actually part of what TLS support already today, as Jeff Moser pointed out: TLS-PSK or TLS-SRP.

The exchange of this pre-shared key is of course an issue, but one issue web banks solve already today upon customer registration. The last time I registered with a new bank the welcoming package was delivered to me via certified mail where I had to identify myself with my passport.

This welcoming package can then serve as the out-of-band delivery method for the pre-shared key. Many banks also require hardware tokens for logging in.

One final point: Many users have very little understanding of what these server certificates are for, and act wrongly: Look at the article Security certificate warnings don't work, researchers say.

The TLS trust model isn't broken as such. Your con...

2009-08-06T20:04:04.411+02:00

The TLS trust model isn't broken as such. Your concerns are valid, but what you seem to be disagreeing with is the concept of Public Key Infrastructures (PKI). You seem to have missed the problem they aim to solve: key distribution. What you're suggesting is a manual Web-of-Trust approach (a la PGP). This is fair enough, but it leads to a lot of practical problems when you want to deal with someone with whom you haven't pre-established trust (or established it via intermediate parties).

You don't need to change anything in TLS or Firefox to fulfil your requirements; all you need to do is to delete the certification authorities from your Firefox installation and re-import the certificate of each website you trust one by one when you visit them. However you verify those is up to you, and will have to be done out of band (and will certainly be tedious).

Regarding your key exchange suggestions:
(1) could lead to a man-in-the-middle attach (checking the identity of the server first is fundamental for the security of TLS);
(2) presents the same problem: that's what TLS does ultimately during the handshake (exchanging shared keys securely), again you do need to pre-verify the identity of the remote party to do this, so you'd need to know how to verify its key/certificate in advance.

Thanks for your comment. Your references to TLS-P...

2009-08-03T10:56:17.167+02:00

Thanks for your comment. Your references to TLS-PSK and TLS-SRP were interesting reads indeed.

Seems I didn't think thoroughly enough into the man-in-the-middle issues.

Good thoughts, however I think your #1 recommendat...

2009-07-28T17:11:26.876+02:00

Good thoughts, however I think your #1 recommendation has a man-in-the-middle attack issue.

I posted a full reply to the this at http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html#c9103997414201993900