D-kriptik Blog

I enjoyed this post on Emergent Chaos.

So, I’d love to hear why, in an era when criminal enterprises are able to forge an entire enterprise, to the extent of developing new products, they won’t do enough to get a high assurance certificate?

True.

Shostak proposed the following solution.

I expect that persistence memory about the certificate, so that your browser alerts you on change, with a design that has been created with the user in mind, and tested on a variety of real users, is the right model.

This brought to mind a few notes from this post on D-kriptik, as excerpted below.

[...]For example, you could establish an SSL/TLS session with a malicious web site that has a domain name that is a variation of, or related to, the name of the site you intended to visit. That site could easily have a proper certificate signed by a browser trusted authority for that domain name, which means the browser does not even pop up a warning dialog box.

(We already see lots of business web sites that use separate payment providers, so when a user goes to checkout, they get redirected to some random payment web site. And, I was recently complaining to someone about bank web sites that have bizarre domains, a couple of which use variations of their normal domain for their online banking. So, people have become accustomed to entering sensitive information under “weird” domains.)

I think this attack will apply regardless of “high assurance” certificates. As Shostak pointed out, getting “high assurance” certificates can make sense for attackers.

In fact, most people have no idea what warning dialogs with relation to SSL/TLS negotiations or digital certificates mean, and, in many cases, they are false alarms anyway. So, virtually everyone has grown accustomed to just clicking through such warning dialogs.[...]

Attacks based on user ignorance of anything to do with PKI or TLS will apply regardless of “high assurance” certificates or not. What really matters here is whether or not browser security indicators matter to users (e.g., do users know about the security indicators provided by a browser, what the indicators mean, and what should be done in response to the indicators?).

[...]verifying that you are in fact establishing an SSL/TLS session with the proper entity.[...]

[...]countering an SSL/TLS MITM attack.[...]

This is an active research area. Petnames have been proposed, which I like (think PGP web of trust in some form). This has similarities to the SSH-type trust model, which has also been proposed and which I also like. In recent minutes to an IETF-PKIX meeting, the Opera people were looking at “extended validation” certificates. There has been all sorts of talk, pros and cons, about “high-assurance” certificates.

In this regard, while I like the idea of bookmarking a web site and its certificate(s), how exactly to inform a user that a certificate is changed, and establishing what actions a user should take in such a case, is the hard part. Every model I envision reduces to checking the digital certificates when the certificate presented is different from the one that is bookmarked, and then all the same problems come back into play – you might as well have just bookmarked the web site and left out the certificate.

Which leads me to what I have quoted a few times from this post.

Bookmark web sites that you visit, especially where you conduct transactions like buying stuff, and then return to those sites only through your bookmarks (this is like what we do with server public keys in SSH). Now, when you receive that email, instant message, or embedded link in some rogue web site purporting to be from, or purporting to point you to, Paypal and you really do feel it necessary to log into Paypal in response, don’t follow any of the links provided – instead, use your bookmark for the Paypal web site. It doesn’t solve all these problems, but it helps quite a bit.

Combine that with a broader version of something like PwdHash or, better yet, throw in widespread deployment of TLS with pre-shared keys (PSKs) (RFC 4279), and there you go.

-

I noticed this paper.

We develop and evaluate a system we call Loud-and-Clear (L&C) which places very little demand on the human user. L&C involves the use of a text-to-speech (TTS) engine for vocalizing a robust-sounding and syntactically-correct (English-like) sentence derived from the hash of a device’s public key. By coupling vocalization on one device with the display of the same information on another device, we demonstrate that L&C is suitable for secure device pairing (e.g., key exchange) and similar tasks.

This reminds me of one of the ways people (including myself) perform remote, (somewhat) out of band verification of each other’s OpenPGP public keys during an initial exchange of those keys over, say, the Internet.

The general idea is that I send my OpenPGP public key to my buddy via, say, email. Now, my buddy has no way of knowing whether the key received via email is actually from me – for example, someone else could have sent them a OpenPGP public key and claimed it was from me, or someone could be sitting in between us and replaced my key with their own. So, I call my buddy (or vice versa) and read off the key’s fingerprint while my buddy verifies that the key received has that fingerprint, usually by visually matching what I am reading off.

Of course, we don’t use Mad Libs, but some OpenPGP applications do translate the fingerprint into a string of words, instead of just displaying it in raw hex. Whatever floats your boat.

This entry was posted on Wednesday, May 3rd, 2006 at 2:52 am and is filed under Authentication & Identity, Security. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.