Closed Bug 306435 Opened 15 years ago Closed 14 years ago
Mozilla browsers should support the new IETF TLS-PSK protocol to help reduce phishing
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.
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 !)
Component: Security → Libraries
Product: Firefox → NSS
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.
see also RFE Bug 268835
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P4
Version: unspecified → 3.11
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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.