Many (most?) of us, when accessing a "secure" web site, have at one time or another been presented with a browser dialog indicating something isn't quite right with the site's certificate, and offering the ability to ignore the issue and proceed. Sometimes proceeding is not a good idea because it may lead to a man-in-the-middle attack.
Collin Jackson and Adam Barth present the details of such situations, as well as a means to remediate them, in their paper ForceHTTPS: Protecting High-Security Web Sites from Network Attacks. Essentially, ForceHTTPS enables a server to signal to browsers that it wishes to be interacted with only over secure transport, e.g. TLS/SSL. Part of the idea here is if the user enters, say, "http://www.paypal.com", the browser will rewrite it as "httpS://www.paypal.com/", and initiate the HTTP connection over secure transport. Another aspect is that if there are any certificate errors upon secure transport establishment, the connection will simply fail and the user won't be presented the opportunity to "click through" warnings.
Now, working with Collin and Adam, we've produced a refinement in the form of a HTTP Header Field specification entitled Strict Transport Security (STS). We're talking with the W3C about standardizing it there. There are already two Firefox extensions implementing it, Giorgio Maone's NoScript, and Sid Stamm's ForceTLS. Both Giorgio and Sid have blog entry's concerning STS, too:
Additionally, Google Chrome has STS functionality implemented and it is working its way through the development channel process.
We (PayPal) are excited by the positive feedback we're receiving and the implementation work. We're looking forward to having our customer's security improved.
I read a rather worrying criticism of Firefox 3.0 on “Risks” the other
day, which made me realize that perhaps there isn’t a common agreement amongst
the infosec industry about the threatscape and how we should prioritize our
response to them. Specifically, the
complaint against Firefox 3.0 is that the user experience has been deliberately
crafted to make it hard to accept self-signed certificates. The argument is that there are times when
simply establishing an encrypted tunnel (i.e. an SSL session) is all that’s
needed.
I certainly wouldn’t argue that encryption is unnecessary, just that the
threat has changed. While our old
“friend” Mallory isn’t particularly busy these days, it’s pretty clear that
he’d be having a field day if he could easily penetrate communications across
the Internet. The attacker however is no
longer limited to passive eavesdropping. Modern attacks use active DNS spoofing, active MITM attacks and the
like, on public networks. The main
threats these days are against the weakest link in the chain – the end
user. That’s why phishing is such a
popular method of e-crime – it’s simple and it works. It relies completely on the gullibility of
users in clicking on links in e-mails apparently from organizations with whom
they have a relationship.
However, it’s equally clear that almost everyone who wants to
communicate securely using a browser can afford an SSL certificate from CAs
such as GoDaddy, Thawte, etc. The cost
of single certificates from these sources can only be described as nominal.
My company is a major target of phishing, and as such we’ve spent quite
a bit of time researching what anti-phishing approaches work We published a whitepaper on this topic (which
can be found on the company blog at www.thepaypalblog.com), which explains this
in detail. However, a couple of relevant
conclusions are that: 1) the vast majority of users simply want to be
protected, 2) there’s no single “silver bullet”, and 3) that what we describe
as “safer browsers” such as IE 7, and Firefox 3.0 are a significant part of the
solution based on their improvements in user visible security indicators and secure-by-default
behaviors.
I conflated two or three separate ideas in that last sentence, and I
should explain them. The general logic
is that most users should never be presented with a security dialog that gives
them a choice – if they are, there’s typically at least a 50:50 chance that the
wrong decision will be made. Instead,
the browser should make the decision for them. However, in the case of self-signed certificates it’s almost impossible
to see how any technology can disambiguate between legitimate uses and criminal
ones.
When viewed through this lens, the changes to the Firefox user
experience for self-signed certificates makes perfect sense. It’s not that self-signed certificates are
impossible to use – but for most users, the experience will be such that they
won’t accept them. In the unsafe world
in which we live, that will be the right choice. For organizations which wish to use
self-signed certs internally, it is still technically possible – but it will
require either explicit user training, or deployment of pre-installed
certificates on PCs.
I should also add that the major security features which have been added
into the most recent browser versions (and which we believe are necessary in
order to be considered ‘safer’) are exactly those which impact this area. That is: support for Extended Validation
certificates, which make it clear to end users whose web site they’re on; and
support for spoof-site black lists, so that users can’t easily reach
spoof-sites.
While I’m personally a great supporter of the “Risks” list, I think it’s
important that the infosec industry speaks with good consensus about
risks. In this case, I believe that the
criticism of Firefox 3.0 was simply misguided and ill-informed. This is not helpful.
