306435 - Mozilla browsers should support the new IETF TLS-PSK protocol to help reduce phishing

Status: RESOLVED WORKSFORME

(NSS :: Libraries, enhancement, P4)

Description

[Young H. Etheridge]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

In the words of some IETF security forums: TLS-PSK provides mutual
authentication of client and server as part of the key exchange.  Both sides
demonstrate proof-of- possession of the password (without actually communicating
the password), if either side fails to do this then the TLS handshake fails. 
Its only downside is that it isn't widely supported yet, it's only just been
added to OpenSSL, and who knows when it'll appear in Windows/MSIE, Mozilla,
Konqueror, Safari, Opera.

And that's it's killer feature: Although you can still be duped into handing
out your password to a fake site, you simply cannot connect securely without
prior mutual authentication of client and server if TLS-PSK is used.

What'd be necessary in conjunction with this is two small changes to the
browser UI:

- Another type of secure-connect indicator (maybe light blue or light green in
  the URL bar instead of the current yellow) to show that it's a mutually
  authenticated connection, along with a "Why is this green?" tooltip for it.

- A non-spoofable means of password entry that only applies for TLS-PSK
  passwords.  In other words, something where a fake site can't trick the user
  into revealing a TLS-PSK key.

This would also be a very good security discriminator in browser one-upmanship!

Reproducible: Didn't try

Steps to Reproduce:
1.  This is a request for a new feature.
2.
3.

Comment 1

[Jo Hermans]

more info at <http://tools.ietf.org/wg/tls/draft-ietf-tls-psk/>

For the latest draft:
   The ciphersuites defined in this document are intended for a rather
   limited set of applications, usually involving only a very small
   number of clients and servers.  Even in such environments, other
   alternatives may be more appropriate.

You comment seem to indicate that it's another authentication procedure
("without passing the password"), but it's in reality nothing more than a normal
TLS connection with pre-shared keys. A password has nothing to do with this, it
just proves that you're in posession of the right key (similar to having a
site-specific cerificate, not a public one like most TLS connections).

The key shouldn't be read by any random program ofcourse, it needs to be
protected with its own password. That's where you prove that you're the right owner.

But I fail to see where it would protect against phishing itself. The point in
phisihin is that a rogue website if trying to impersonate f.i. ebay.com - and
the user fails to see that he/she is being duped (due to a good visual
resemblance, or failure to check that you're connected to the right server).
This wouldn't protect against it, it only make it more difficult to intercept a
TLS stream that uses a public certificate. That's protecting against
interception, hackers, not phishers. Luckily, those !@#$%&* aren't working
together for identity theft (but they will, one day !).

moving to the NSS area (note: Gecko doesn't use OpenSSL !)

Comment 2

[Young H. Etheridge]

Presently, the Mozilla site/password negotiating process over a TLS connection
is generally user driven w.r.t. to password selection and depends on trust in
the sites' public key.  Of course, phishers can use this one-sided session
negotiation to their advantage, particularly if the client-user does not pay
close attention to connections.  The TLS-PSK session negotiation actually is
more that just the Gutmann TLS SharedKey negotiation since there is also a
PSK-identity negotiation step.  Of course, identity theft is a problem at the
server side, as well as the client side, but the well-publicized breakages of
late seems to be encouraging many managed sites to upgrade their procedures.  My
impression of anti-phishing schemes is to increase the trust in a negotiated,
secure session, one of the apparent goals of TLS-PSK.  TLS-PSK has the added
benefit of helping Mozilla to operate in a computation-constrained device with a
synchronous key-only crypto-provider.

Typical users seem to have a blind faith that they are being cared for w.r.t.
security.  It'd be nice to continue to shore up the security solutions to
justify this blind faith and enhance trust conditions as well.

I realize the Mozilla does not use OpenSSH, but many servers do, especially
Apache-based servers.  The statement was merely an encouragment to stay abreast
of other important open software upgrades and stay ahead of proprietary
offerings.  Every encouragement to lure users to a well-maintained, secure,
standards-compliant, open-software product is my interest.

Comment 3

[Ralf Hauser]

see also RFE Bug 268835

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

I confirm that this is a request for enhancement.  :)  But ...

The NSS developers actively oppose network authentication based on 
secrets shared by remote parties, ESPECIALLY PASSWORDS.  
If the user types in the shared secret, the user can be fooled into 
giving it to the attacker.  That's the essence of phishing.  
Increasing the dependence on shared password secrets will not decrease
phishing.

There has been a proposal for a "token" based shared secret scheme,
to be used with TLS-PSK.  This has some merit.  Otherwise, this RFE
would be resolved WONTFIX.

Comment 5

[Young H. Etheridge]

I don't fully agree with the notions regarding passwords, but I understand the reticience to compound the continued use/misuse of them.

The token solution would be better than nothing.