Comments on: Certifiably Silly

By: Adam

Adam — Fri, 15 Aug 2008 11:01:14 +0000

Andy,
When I say training, I mean implicit training. People are pattern-sensing *machines*. we sense patterns everywhere, regardless of if they’re real or not. It’s part of how we make sense of a big world. Right now, users see conflicting messages from their financial institutions and across them, and so can’t construct good patterns, which is the goal of implicit training.

By: Jim Burrows

Jim Burrows — Thu, 14 Aug 2008 19:04:49 +0000

I think one of the problems in the space is that the no one has explained to either the everyday user’s of the net or the commercial customers on the net what all of this means. The SSL EV green bar means “You know who is at the other end”, but it is often described to users as “you’re talking to a trusted site” or “you’re safe here”.
The problem is that a EV site with a cross scripting bug isn’t a lot like any of those, certainly if someone exploits the bug and steals your ID then you certainly aren’t safe, you only know who one of the entities you are talking to, and your trust in them may feel more than a little misplaced.
So long as we oversimplify to the masses, they won’t understand, they will be surprised and things will break. And before we tell them what it all meaqns we do rather need to decide amongst ourselves, and I don’t think we’re in great accord.
JimB.

By: Andy Steingruebl

Andy Steingruebl — Thu, 14 Aug 2008 18:00:24 +0000

Adam,
From a completeness perspective plain old end-user training isn’t really an option right now. If I stopped sending HTML mail with links in it today, how exactly would I communicate that successfully to my customers so that they wouldn’t just click the links in HTML email from the phisher?
Additionally, any large company runs lots of websites. They are customized on a per-country basis, or they are other somewhat related sites but for security reasons (same origin policy for example) you don’t want them on your core domain. So, you end up with lots of URLs.
Frank’s point about checking out with PayPal is pretty important. Not everyone is trying to just periodically log in and check their balance or statement.
What this means is that your description of how to solve this problem neglects a lot of real world situations and uses of websites. Your guidance applies to a bank perhaps, but certainly not to many other large e-commerce sites.

By: Frank Hecker

Frank Hecker — Thu, 14 Aug 2008 16:12:54 +0000

“Also, I’d love to hear how my thoughts in ‘preserving’ are not complete–what parts of the problem survive in relevant ways?” First, I think your advice in “Preserving” is still perfectly valid, and I wish more financial institutions would follow it.
I think one major issue is that it’s not always convenient to reach a financial institution through a bookmark. For example, I recently bought Girl Talk’s new album “Feed the Animals” online, following a link from his site to a Paypal-hosted payment page at which I could login in and make the payment. This was certainly more convenient than going separately to a bookmarked Paypal page to authorize a payment.
Also, Firefox 3 put up the “PayPal Inc. (US)” indicator based on PayPal’s use of an EV cert, which was a nice verification that I was signing in to the right service. Though to be fair, this same type of indicator could also have been provided by the browser based on a prior decision by me to designate PayPal as a site I go to make payments. (In fact, this could have been an optional capability in the bookmarks system.)
So the advice I would add for financial institutions is: First, get an EV cert; I don’t see any real downside for doing this, and I think it adds useful information for users. And second, if/when browsers support EV-like indicators for arbitrary user-designated sites, recommend that users do this in addition to bookmarking the site in the normal way, to take care of cases where the user happens to end up on the site in the course of browsing other sites.

By: Dan Weber

Dan Weber — Thu, 14 Aug 2008 15:49:16 +0000

I’m currently doing work for a company selling perimeter security devices to small-and-medium businesses. It is operated through a web UI over HTTPS.
We need to do this via a self-signed cert; it’s impossible to do it any other way, unless we do some sickening level of DNS poisoning.
The Firefox 3 warning is much better than the Internet Explorer 7 warning. FF3 gives a warning and tells you “legitimate public sites will not ask you to do this,” whereas IE7 just panics and says “don’t continue, I’m warning you.”
Although the self-signed warnings work directly against us — we have to explain to a customer at least once a week why the browsers do it, and why it’s a good idea for them to do it, and why we cannot comply — it’s still a better security posture than what comes before.
Now, EV certs? Bah, what a distraction. Unless you’re a CA, in which case it’s a nice new revenue source.

By: Frank Hecker

Frank Hecker — Thu, 14 Aug 2008 15:07:16 +0000

“What’s the origin of my trust in StartCom, an organization I hadn’t heard of before today?” I think the most straightforward answer is that this is a case where (at least some) users are implicitly relying on the browser vendor to make decisions like this on their behalf. In this particular case I (acting as Mozilla’s designated person for this sort of thing) do happen to know who StartCom is, and made a conscious decision to approve including its root certificate in Mozilla.
Some users don’t like browser vendors deciding things for them, some do (or, at least, we don’t hear them objecting to it). Users who don’t like it typically do one of two things. Some use the built-in browser mechanisms to change how browsers work for them (e.g., adding or disabling particular root CAs), and some lobby the browser vendors to change the way the browsers work for everyone.
IMO those who do the latter in the case of SSL and self-signed certs need to make a compelling case for why and how this should be done, given that this would be a pretty major change to the traditional browser model.

By: Adam

Adam — Thu, 14 Aug 2008 14:43:20 +0000

Frank, very interesting questions, I’ll try to respond in depth tonight.
Andy, I don’t believe certification as done today adds trust. In the course of this conversation, I’m learning that there are CAs I’ve never heard of added to the FF root store.
How does having these StartCom people sign some bits influence when I should believe what’s in a certificate? What’s the origin of my trust in StartCom, an organization I hadn’t heard of before today?
Also, I’d love to hear how my thoughts in ‘preserving’ are not complete–what parts of the problem survive in relevant ways? (My goal in creating them was to break what I see as the crux–the links in email.)

By: Andy Steingruebl

Andy Steingruebl — Thu, 14 Aug 2008 14:15:46 +0000

What do you find non-compelling about Jonathan’s post here: http://blog.johnath.com/2008/08/05/ssl-question-corner/
Is your major complaint the general architecture of HTTP and HTTPS, the existing status quo, or Firefox’s slightly different new behavior?
There are a lot of browser behaviors we could modify related to these sorts of things. Things like the ForceHTTPS proposal from Collin Jackson and Adam Barth. Things like new UI in Firefox that tells you whether you’ve visited a given site a number of times before, etc.
Your solutions to phishing, while a part of the picture, aren’t a complete solution and don’t fully address the problem.

By: Frank Hecker

Frank Hecker — Thu, 14 Aug 2008 13:27:03 +0000

Could we take the cost issue out of this equation please (e.g., statements like “There are all sorts of use cases where $29 is not chump change”)? Because StartCom (http://www.startcom.org/) offers basic no-charge SSL certificates that are usable with Firefox today, and quite possibly with IE, Safari, and Opera in future. (As Matthias notes, CAcert also offers no-charge certs, though they’re not recognized by default in Firefox because CAcert doesn’t yet met Mozilla requirements for including a CA — requirements that were specifically designed not to exclude nonprofit CAs like CAcert.)
I think the cost issue is a red herring, or nearly so; IMO it can and will be addressed one way or the other, if not by StartCom or CAcert then by someone else. The real questions as I see it are
1) Leaving aside the issue of cost, what are the pros and cons of introducing self-signed certificates into the current browser model of SSL?
2) If the advantages of introducing self-signed certificates into this model outweigh the disadvantages, what is the best approach (from a technical and user experience perspective) to introduce self-signed certificates into the current SSL model?
3) If there is a good technical/UX approach to introduce self-signed certificates into the current SSL model, what is the likelihood of such an approach being adopted on a universal basis (i.e., by all browser vendors), and how might this be made more likely?

By: Matthias Urlichs

Matthias Urlichs — Thu, 14 Aug 2008 12:41:30 +0000

You can have both. See https://cacert.org