August 21, 2010

memes in infosec IV - turn off HTTP, a small step towards "only one mode"

There appears to be a wave of something going through the infosec industry. There are reports like this:

In the past month, we've had several customers at work suddenly insist that we make modifications to their firewalls and/or load balancers to redirect *all* incoming HTTP traffic to HTTPS (which of course isn't always entirely sane to do on proxying devices, but they apparently don't trust their server admins to maintain an HTTP redirect). Most of them cited requirements from their PCI-DSS auditors. One apparently was outright told that their redirects were "a security problem" because they presented an open socket on port 80, and they needed to be refusing all HTTP to their servers at the firewall. I think we gave them sufficient wording to convince their auditor that blocking access to the redirect itself wasn't going to do anyone any good.

Then, there have been long discussions circulating around the meaning of this hypothesis in security design:

there is only one Mode, and it is Secure

Which, if I can say in small defence, is an end-point, a result, an arrival that does not in the slightest hint at how or why we got there. Or by what path, which by way of example is the topic of this very blog post.

The Electronic Frontier Foundation has announced and pushed a new experimental browser plugin to take browsing on that very path towards more and pervasive HTTPS:

HTTPS Everywhere is a Firefox extension produced as a collaboration between The Tor Project and the Electronic Frontier Foundation. It encrypts your communications with a number of major websites.

Many sites on the web offer some limited support for encryption over HTTPS, but make it difficult to use. For instance, they may default to unencrypted HTTP, or fill encrypted pages with links that go back to the unencrypted site.

The HTTPS Everywhere extension fixes these problems by rewriting all requests to these sites to HTTPS.

And Jeff Hodges, Collin Jackson and Adam Barth have published an Internet Draft called Strict Transport Security based on this paper, which in essence tells anyone who connects to the insecure HTTP service to instead switch across to the secure HTTPS service.

Now, leaving aside whether these innovations will cause a few confusions in compatibility, site-redesign and access, all common ills that we would normally bow and scrape before, ... it would seem that this time there is some emphasis behind it: As well as the EFF plugin above, Paypal and NoScript have adopted STS. As Paypal was at one time the number 1 target for phishing-style attacks, this carries some weight. And as NoScript is allegedly used by practically all the security people on the planet, this could be influential.

A few words on what appears to be happening here. In the Internet security field is that the 800lb gorilla -- breaches, viruses, botnets, phishing,... -- it seems that outsiders like EFF, Paypal and PCI-DSS auditors are starting cleaning up the field. And in this case, they're looking for easy targets.

One such target was long identified: turn off HTTP. Yup, throw another bundle of tinder on that fire that's burning around me ... but meanwhile, switch all HTTP traffic to HTTPS.

In an ideal world, every web request could be defaulted to HTTPS.

It's a simple thing, and an approximate first step towards the hypothesis of there is only one mode and it is secure. Switching to HTTPS for everything does a few things, obvious and subtle.

1. the obvious thing is that the user can now be seriously expected to participate in the "watch the padlock" protocol, because she's no longer being trained to ignore the padlock by the rest of the site. The entire site is HTTPS, that's easy enough for the users to understand.

2. The second thing that the notion of pervasive HTTPS does is to strip away some (not all) of the excuses for other parties. Right now, most decision makers almost totally ignore HTTPS. Browser manufacturers, server manufacturers, CAs, cartels, included. It is all compliance thinking, all eyes are turned elsewhere. If, for any circumstance, for any user, for any decision maker, there is a failure, then there is also an easy excuse as to "why not." Why it didn't work, why I'm not to blame, why someone else should fix their problems.

Probably, there are more excuses than we can count (I once counted 99...) (the latest excuse from NIST, Mozilla and Microsoft).

However, if the PCI-DSS auditors make HTTPS the normal and only mode of operation, that act will strip away a major class of excuses. It's on, always on, only on. Waddya mean, it went off? This means the security model can actually be pinned on the suppliers and operators, more of the time. At least, the outrage can be pinned on them, when it doesn't work, and it will have some merit.

3. The third thing it does is move a lot of attention into the HTTPS sphere. This is much more important, but more subtle.

More attention, a growing market, more expectations means more certs, more traffic, more reliance on the server cert, etc. But it also means more attention to client certs, more programmers, more admins, more more more ...

Which will elevate the use of HTTPS and its entire security model overall; which will hopefully get the people who can make a difference -- here I'm thinking of Mozilla and Microsoft and the other browser security UI production teams -- to put a bit more effort and thinking into this problem.

Some would say they are working hard, and I know they are. But let me put this in context. Last I heard, Jonathan had a team of 2-3 programmers working on Firefox security UI. (And, yes, that's a set-up for a correction, thanks!)

This team is so tiny that we can even know their names.... Let me know and I'll post their names :)

Yet, this security UI is protecting the online access of probably 100 million people across the planet. And the current viewpoint of the owning organisation is that this is a backwater that isn't really important, other areas are much more important.

(Just to point out that I'm not picking on Mozilla unfairly: Microsoft is no better, albeit more clear in their economic reasoning. Google probably has one person, Opera may have one too. Konqueror? Apple won't say a thing...)

(Prove me wrong, guys! Ya know ya want to! :)

Posted by iang at August 21, 2010 01:27 PM | TrackBack

an original HTTPS deployment requirement was that the end-user understand the relationship between the webserver they thot they were talking to and the corresponding (HTTPS) URL that they supplied. Another requirement was that *ALL* Certification Authorities selling SSL/HTTPS domain name digital certificates operate at the same (very high) level of integrity.

almost immediately, the original requirement was negated by merchant servers that dropped back to using HTTP for the most of the online experience (because HTTPS cut thruput by 90-95%) and restricting HTTPS use to pay/checkout portion, accessed by a "pay/checkout" button (supplied by the unvalidated website). Clicking on HTTPS URL buttons/fields from unvalidated sources invalidates the original requirement, since it creates a disconnect between the webserver the user thinks they are talking to and the corresponding URL (that is personally known to them). Since then, the use of "click-on" URLs have proliferated widely resulting in users having little awareness of the corresponding URL. The issue/short-coming is that browser HTTPS only validates the equivalence between the webserver being talking and the supplied URL (it does nothing to establish any equivalence between the supplied URL and what the end-user believes that may URL represent).

In this environment, nearly anybody can buy a SSL domain name digital certificate for a "front" website, induce the end-user to "click-on" a field that claims to be some other website (which supplies their HTTPS URL to the end-user browser), and perform a MITM-attack with a modified PROXY server that establises a (separate) HTTPS connection to claimed website. Their are a pair of HTTPS sessions with the fraudulent website in the middle (MITM-attack) with the modified PROXY providing the interchange between the two sessions (transparent to most end-users).

With the proliferation of zombie machines and botnets, their could be a sequence of paired sessions, so the valid website isn't seeing a large number of different sessions originating from the same IP address.

Of course, with the progress of zombie machine compromises, the attack can also be performed with a compromise of the end-user's browser (eliminating any requirement for intermediate PROXY server). The latest sophistication of such compromises target very specific online banking services ... performing fraudulent transactions and modifying the results presented to the user (so that the fraudulent transactions aren't displayed).

The compromise of the end-user machine was well recognized and researched threat in the 90s and contributed to the EU FINREAD standard in the later 90s. The EU FINREAD standard basically added a separate hardened box as the end-point for financial operations, with its own display and input. Each financial operation was (accurately) displayed on the box and required explicit human interaction (eliminating transactions w/o the user's knowledge or transactions different than what the end-user believed).

The EU FINREAD standard ran afoul of some deployments of other add-on "secure" boxes which were done with serial-port interfaces. The difficult consumer problems with add-on serial-port attachments had been well known since the days of dial-up online banking (before the migration to internet). The enormous consumer problems with the serial-port attachments led to quickly spreading opinion in the industry that all add-on secure boxes were impractical for consumers (when it actually was that add-on serial-port boxes were impractical for general market ... which was also major motivation behind creation of USB).

There is little evidence that internet in-transit evesdropping has been any kind of significant threat (HTTPS encrypting information as countermeasure to evesdropping information being transmitted). The major exploits have been end-point attacks of one sort or another.

Posted by: Lynn Wheeler at August 21, 2010 11:55 AM

# If we need any special Directory permissions
<Directory "/var/www/sites/">
Options +ExecCGI
Order allow,deny
Allow from all
# If we need any special handlers for specific locations
<Location "/">
# The non-secure VirtualHost
<VirtualHost *:80>
Redirect /

# The secure VirtualHost
<VirtualHost *:443>
DocumentRoot "/var/www/sites/"
AddHandler cgi-script .cgi

Posted by: Kyle H at September 2, 2010 03:47 AM
Post a comment

Remember personal info?

Hit preview to see your comment as it would be displayed.