More on https as a necessary mistake

December 7, 2010

Rather than write an extensive reply to a comment on the original entry as another comment, I'm doing it here. So, without further delay and in the traditional Usenet style:

Are you proposing every TLS secured service which does not provide strong ciphers shows up as if it were a cleartext service?

In my ideal world the short answer is yes; both bad ciphers and no ciphers would show up as plain boring insecure connections. That weak ciphers are somewhat harder to eavesdrop on than cleartext is not something that users care about or should be confused by. (If they really care they can check the detailed connection information dialog.)

I do not see a problem with asking end-users questions if you provide them with enough data to help them make a well informed decision.

I do, especially for security questions. People aren't interested in being well informed about security issues; they're interested in getting done whatever they want to get done with the computer. And besides, if you don't know enough to make a decision, how are they supposed to?

(Part of the problem is that making that mythical well informed decision requires a lot of information, not just about what is going on but what it means and what the risks are. Consider how much you would have to explain to someone before they can make a well informed decision about whether or not to go ahead with a 'weak cipher only' connection. For a start, how weak is weak?)

Regarding authentication, this is not a failure of TLS but a weakness in PKI. As you know, if you cannot trust your CAs, you cannot trust any of the data they sign. The entire house of cards comes tumbling down. The CA business is not well regulated and could use an overhaul. The businesses and governments which rely upon them could easily get the ball rolling.

As the famous saying goes, 'in theory there is no difference between theory and practice'. Security systems are practical systems, not theoretical ones. If the math works but nothing else does, they've failed. And I don't see how to make CAs actually work, because the economic motives of all parties involved are misaligned. Nor do I see how the economic interests can be aligned by force and fiat, for example through liability laws.

(Perhaps I should write a follow the money entry on SSL certificates.)

Also, as a practical matter I think it would be very hard to keep what I consider the most dangerous CA certificates out of major browsers, especially Windows and IE. To put it crudely, we've already seen that surprisingly small governments are quite successful at pressuring companies (and major governments are even better at it).

(As I alluded to, the most dangerous CAs are not the ones with bad business or security practices but the ones who are willing to do whatever a government demands of them.)

The trust system would benefit from multiple signatures (think PGP) or a community certificate rating system. Placing full trust in profit driven CAs just seems like a bad idea.

These are popular ideas but I don't think they work; I've written longer entries on both of these (MultiSignedProblem and SSLCANeed). The short version is that I don't think you can have certificates that are both free and authenticated in any meaningful way, and once you are charging for certificates, having more than one is either a pointless insurance policy or an attempt by CAs to extract more money from websites (depending on what happens when you do or don't have more than one).

Written on 07 December 2010.
« What performance anomalies mean
Exploring a limitation of the DTrace fbt provider (on x86) »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Dec 7 01:08:01 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.