Re: Another entry in the internet security hall of shame....
James A. Donald [EMAIL PROTECTED] writes: From: [EMAIL PROTECTED] (Peter Gutmann) TLS-PSK fixes this problem by providing 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, This will take out 90% of phishing spam, when widely adopted. 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. Anyone know how to communicate this to the Mozilla guys? The only mechanism I'm aware of is bugzilla, which doesn't seem very useful for this kind of request. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Peter Gutmann wrote: 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. If I have understood the draft correctly, using PSKs means that the server and the client have a shared secret that they must communicate securely beforehand, and that they use some form of ZKP to assure the other party that they know that secret without revealing it. If that's indeed so, wouldn't this have key management and storage issues that PK was designed to prevent in the first place? Also, the prior secure exchange of secrets would seem to preclude communication between entities that don't know each other. That, however, is how many businesses (including ebay, in whose name much phishing spam is generated) operate. Additionally, I don't think that this is just a UI issue; after all, both the client and the server must somehow manage the PSKs. There are probably expiration and revocation problems: what if my computer gets stolen and I can't get at my PSK? Does this mean that I can't do business with my bank anymore? What if I suspect that someone has stolen my PSK (for example with the same javascript attack that phished my password)? And so on and so on. I'm not saying that the idea is bad, far from it; I'm just saying that there are probably many practical problems to be solved before this can be widely deployed. Or perhaps I haven't understood the draft correctly. What'd be necessary in conjunction with this is two small changes to the browser UI: ...and the PSK management code in the server and in the client. Fun, Stephan begin:vcard fn:Stephan Neuhaus n:Neuhaus;Stephan org;quoted-printable:Universit=C3=A4t des Saarlandes;Department of Informatics adr;quoted-printable:;;Postfach 15 11 50;Saarbr=C3=BCcken;;66041;Germany email;internet:[EMAIL PROTECTED] title:Researcher tel;work:+49-681/302-64018 tel;fax:+49-681/302-64012 x-mozilla-html:FALSE url:http://www.st.cs.uni-sb.de/~neuhaus version:2.1 end:vcard
Re: Fwd: Tor security advisory: DH handshake flaw
Simon Josefsson wrote: No, the certificate is verifiable in deterministic polynomial time. The test is probabilistic, though, but as long as it works, I don't see why that matters. However, I suspect the ANSI X9.80 or ISO 18032 paths are more promising. I was just tossing out URLs. Surely Miller-Rabin is polynomial time anyway? -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
