601998 - Warn the user whenever a page containing password forms makes any non-SSL requests

Status: RESOLVED WONTFIX

(Core :: Security, defect)

Description

[Kai Engert (:KaiE:)]

I have to start with a foreword:

In the past, the idea of warning the user about potentially sending their password data over an insecure channel was based on the following web-1.0 concept:
- user enters a ssl-protected (https) page and gets the lock icon
- user enters password
- user hits submit
- resulting request is sent to another https page

In order to make sure this concept is being used, in the old days, the browsers used warnings like:
- entering secure page
- leaving a secure page
- submitting form data to an insecure page

Nowadays all the above warnings have been disabled, because they were pestering, because people were getting those warnings all the time, even where there was no sensitive data involved at all, as in submitting a search form.

This has resulted in a world where we have accepted that we don't know whether the form data will be submitted with http or https.

Several sites introduced a concept like "plain http start page that shows the login form" however "form will be submitted using SSL". This is good, but how can we know that a site really uses SSL? I'm aware of sites that don't do this, but rather do either http-http-http or https-https-https, but don't do http-https-http for the login process.


I believe we should find a mechanism that will inform the user about sites that will send a password in the clear, without SSL. Here is a proposal:


Whenever a page contains a form with a password entry field (the one showing bullets instead of characters), the browser should track what's happening.

Whenever a password page attempts to perform a non-https request (JS or form submit), then we should warn the user. Ideally such navigation attempts could be blocked, notified to the user, and requiring some confirmation from a user to proceed.

(If we're really smart, we could track whether an outgoing request actually uses the contents of the password field for a non-SSL connection, and only block/warn in that scenario.)


Contrary to the above, for pages not containing any password form fields it shouldn't be tracked in the above way, because this kind of form submission happens all the time when using the web (search engine, social networking status updates, etc.)


Is this a new idea?

Comment 1

[Justin Dolske [:Dolske]]

I'm pretty sure there are bugs on file for variations on this.

But I'm dubious of its value -- there's no good way to ask users about this when it happens, and I'd expect this would unfortunately break sites. I tend to think password authentication is a bit of a lost cause, and it would be better to focus our efforts on making alternative authentication schemes more widely adopted.

Comment 2

[Honza Bambas (:mayhemer)]

I like this idea of checking the form POST content.  I did this my self manually my self to see if my password travels unencrypted.  We probably need a good tracking for http(s) state, which I'm assigned to work on.

However, for instance my offline web app, I work on, dynamically creates field with password type and then uses XHR to send the password to the login server using an insecure channel (in my case, the password is a hash of challenge+password, but whatever site could send it blank). 

Could we reasonably detect a blank password in such scenario?

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

This seems like a dupe of bug 261294.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Not quite; that bug covers one of the items in comment 0, but not all of them.

Comment 5

[Matthew N. [:MattN]]

Now that mixed content blocking is enabled by default, HTTPS is more prevalent, and we're warning in-context on insecure login fields in 52+, I don't think there's more likely to get done here.