322661 - add simple protection against phishing/MITM

Status: RESOLVED INCOMPLETE

(Firefox :: Security, enhancement)

Description

[Ralf Hauser]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

To protect not just against normal phishing, but even against a real-time man-in-the-middle attacks, the following approach seems to provide decent protection where firefox can play an essential role in:

1) the user intends to visit https://myTrusted.site.org and clicks on *a*
   https - link
2) to log in, she clicks on the bottom right lock of her Firefox.
   Firefox copies a 6-(or longer?) character (ASCII) SSL/TLS session identifier 
   into the clipboard. This identifier is calculated by Firefox as follows:
   Take the handshake_messages of http://www.rfc.net/rfc2246.html#s7.4.8. (since 
   MITM are typically prevented when client certificate authentication is done,
   it only entails (and applies to) the messages of a handshake without client
   cert auth) and digest them until the result fits into the "identifier".
3) The user opens passwordsafe or an equivalently trustworthy open source
   utility
4) upon right-clicking on the previously stored password entry of
   myTrusted.site.org in the passwordsafe list, it does a
   HMAC(password,identifier), where HMAC is a keyed-hash function described 
   in RFC2104. The result(/"response") is then stored in the clipboard again.
5) in a login form, myTrusted.site.org asks for user-id and response (not
   password!) and the user pastes the clipboard value into the response field
   and fills in the user-id.
6) The myTrusted.site.org server receives the two values and
   i)  calculates the "identifier" independently by its own view on the 
       handshake it was involved in
   ii) retrieves the password from the secure user credential store and 
       calculates the HMAC response
   if it matches, there was no MITM, if it doesn't match the user most likely
   entered the response into a MITM (SSL proxy) and the server better aborts
   the session.

passwordsafe development (as per the above URL) has indicated to be interested in providing a prototype for this. We would take care of providing the server-side part for it. 

Would Firefox participate as well?

-------
P.S.: As soon as the refereeing process is over, we'll be able to provide two detailed papers on this approach including a way to authenticate the server back to the user and many more variants of the overall MITM protection issue, some of which might not be contributed to the open source.

Reproducible: Always




see also Bug 285361 - also, I guess this is a lot simpler than what is discussed in Bug 268835

Comment 1

[Petr Johansson]

I very much welcome this idea of integrating protection against MITM attackes into the browser. In many cases phishing attacks currently are a pretty simple way for the bad guys to be able to get into 'protected' accounts.
Once companies have reacted to the threats of phishing it seems pretty logical that 'online phishing' attacks (i.e. MITM) will become even more popular than they already are today.
As far as I can judge the proposed approach would be an effective countermeasure against MITM attacks. IMHO it also would be a great differentiator in Firefox' fight for market share.

Comment 2

[Martin v. Löwis]

I fail to see the value of this approach.

1. SSL is already safe against MITM attacks, if the client is able to validate the server certificate against a trusted root CA. So if Mozilla says the certificate has been verified, the user has the guarantee that the partne site has the private key corresponding to the server certificate.

2. If myTrusted.site.org wishes to do password-less authentication, there are already various alternatives available, most prominently client certificates.

3. If myTrusted.site.org wanted to support some out-of-browser entering of a password, they could just put some challenge on the web page itself, asking the user to respond to the challenge by copying it into the passwordsafe. The MITM would see the response, but be unable to infer the original password from that.
That would work independent of the web browser.

It appears that this approach would just be another way for password-less authentication, and one that is tedious to use for the user.

Comment 3

[Ralf Hauser]

> 1. SSL is already safe against MITM attacks, if the client is able to
> validate
> the server certificate against a trusted root CA. So if Mozilla says the
> certificate has been verified, the user has the guarantee that the partne
> site has the private key corresponding to the server certificate.
In an ideal world, this is true.
But typically a double-digit percentage of the users would not even know what the correct secure-site domain name of the site they intend to access really is - e.g. is it raiffeisen-online.de or raiffeisen-direct.de (=hypothetical domain name) and phishing unfortunately is on the rise (https://www.financialcryptography.com/mt/archives/000577.html, http://www.heise.de/newsticker/meldung/68335)
> 
> 2. If myTrusted.site.org wishes to do password-less authentication, there
> are already various alternatives available, most prominently client
> certificates.
In theory, again, this is true. 
But to do it right, it is so expensive, that even one the world's largest banks last year canceled a project to do so and still sticks to their off-line C/R device for now. I don't know the exact reasons, but AFAIK the user tests with their class-4 readers had signficant acceptance and support issues.
> 
> 3. If myTrusted.site.org wanted to support some out-of-browser entering of
> a password, they could just put some challenge on the web page itself,
> asking the user to respond to the challenge by copying it into the
> passwordsafe. The MITM would see the response, but be unable to infer the
> original password from that.
Perhaps we do not have the same definition of what a real-time MITM attack is. But IMHO what you propose here is not secure: If the challenge is independent of the SSL session and in the web-page itself, a MITM could hijack the session as soon as the valid response was provided by the victim (and empty the victim's bank account for example. The attacker would not get the password for a later attack, but once the money is with the attacker, this is not a priority.).
> That would work independent of the web browser.
Browser independence can also achieved by placing the logic needed to make the protocol session aware in a PKCS11/CAPI soft-token, but the disadvantage obviously is that this requires some installation (more on this in the mentioned paper). 

Comment 4

[Ralf Hauser]

see also the background papers in http://www.w3.org/2005/Security/usability-ws/papers/08-esecurity-browser-enhancements/ and RFE Bug 331568 to allow this to be realized in a plugin

Comment 5

[u279076]

Resolving unconfirmed bugs older than a year with no activity as INCOMPLETE.  Please reopen or file a new bug if you can still reproduce the bug.