

Mozilla proposes an HTTP header to force HTTPS-only connections - alexkon
http://forcetls.sidstamm.com/

======
alexkon
Here’s the announcement from the Mozilla Security Blog:
[http://blog.mozilla.com/security/2009/07/27/locking-up-
the-v...](http://blog.mozilla.com/security/2009/07/27/locking-up-the-
valuables-opt-in-security-with-forcetls/)

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...](http://blog.mozilla.com/security/2009/07/27/locking-up-the-
valuables-opt-in-security-with-forcetls/#comment-106091))

------
CraigBuchek
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.

~~~
alexkon
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.

------
mdasen
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.

~~~
alexkon
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.

------
blasdel
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.

~~~
kinetik
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...](http://www.goodgearguide.com.au/article/312438/security_certificate_warnings_don_t_work_researchers_say)

------
joshu
This could be a DNS SRV record, too?

I'm not sure I understand the motivation.

