Mozilla proposes an HTTP header to force HTTPS-only connections | Hacker News Reader

Mozilla proposes an HTTP header to force HTTPS-only connections

forcetls.sidstamm.com

10 pointsalexkon8 comments

Here’s the announcement from the Mozilla Security Blog: http://blog.mozilla.com/security/2009/07/27/locking-up-the-v...

I wonder how the initial request could be made secure. With the current proposal, if you happen to work over a compromised network connection the first time you open a site, the site cannot force your browser to connect over HTTPS and the attacker wins.

Daniel Veditz commented on this concern:

“...[W]elcome to the bootstrapping problem. We’re making the assumption that the sites people most want to protect from eavesdropping and tampering are those for which they’ve set up accounts. That means they connected correctly at least once, and this header could be set at that time. In addition, careful users could always add ‘https://’ themselves the first time and avoid that initial redirect.” (http://blog.mozilla.com/security/2009/07/27/locking-up-the-v...)

I'm not seeing how this is a big improvement over an HTTP redirect (via a Location header) to the HTTPS site -- beyond a single connection for each session, to redirect to the HTTPS site. Nor any improvement over RFC2817 HTTP Upgrade to TLS, which has the advantage of allowing virtual hosting of multiple secure sites on a single port on a single IP address.

There is an improvement over an HTTP redirect to the HTTPS site. Such redirects usually occur in the beginning of every session (or, at least, of some sessions). An active attacker could intercept the redirect at any time a-la Moxie Marlinspike’s sslstrip: http://www.thoughtcrime.org/software/sslstrip/ . But once the browser has received the X-Force-TLS header, it will avoid accessing the site over HTTP at all thus preventing that kind of attack. In other words, the browser will now automatically perform the redirect without issuing any insecure HTTP requests to the site.

The issue is that people don't always check to see if a site is secure before putting in their login credentials and so if someone does a main-in-the-middle on their bank website, they might not notice that it isn't HTTPS.

I'd suggest that there's another good defense (not that I think this proposal is bad). Right now, everyone turns off that "warn me before sending insecure data over the internet" warning because it would be annoying as all hell. Every form you tried to submit would give you a warning. First, I'd change it to only warn about sending a password field over an insecure connection. That's really what most people are worried about. Second, because we all have non SSL sites with passwords, allow for an exceptions list - continue warning me about sending insecure passwords, except for this site which I realize is insecure, but don't care.

That way the browser is warning people about insecurely sending the information they want being sent secure. It provides them with a convenient exceptions list for places that don't use SSL and the user deems is fine for that exception.

Contrary to popular belief, it doesn’t make much sense to protect the password without protecting the whole session (that is, without serving most of the site over HTTPS). If just the login page is encrypted, any attacker who is now prevented from stealing your password can still obtain your session cookie that travels over plain HTTP.

A compromise of a single session is bad enough for many services. Set up a filter to forward your email to the attacker’s address? Access private information? Post messages on your behalf? Change your user profile, including your email and shipping address? Usually such actions do not require password authentication when the client already has a valid session cookie. A man-in-the-middle attacker could also intercept your attempt to log out and keep using your session for as long as possible.

Mozilla's propensity for adding yet another database to your user profile with each new feature they add is really starting to grate on me.

Though now that they're planning to keep knownhosts-like data around for https, perhaps they could be persuaded to use a more SSH-style system for self-signed certificates instead of the intentionally user-hostile asshattery they implemented in FF3.

What is it about additional database files in the user profile that bothers you?

Regarding the untrusted TLS certificate warnings, it seems to benefit the users who need the most help: http://www.goodgearguide.com.au/article/312438/security_cert...

This could be a DNS SRV record, too?

I'm not sure I understand the motivation.

Reply on news.ycombinator.com