Defending against malicious SSL proxy
On the current web it is a matter of fact that a banking site should be developed under assumption that a substantial number of users use infected computers with some of them would attempt to perform a banking fraud. A real experience shows that a substantial number of those fraud attempts comes from computers where malware installs own root certificate and then install either real or transparent proxy. The access to the proxy is then sold to third parties that can do with it whatever they want with decrypted traffic. Sometimes the initial infection comes through a real exploit, but often it is social engineering that works best when a user installs some cool browser extension promising dancing pigs, faster Internet connection etc. Depending on the browser or OS a user could be tricked to install malicious root certificate themselves. As even rather restrictive OS like Chromebook or IPhone allows to install extra certificates, a banking site must be prepared to deal with this on most platforms. Currently the only feasible (and rather weak) protection against this threat is to implement RSA or similar public cryptography in JavaScript and then use that to encrypt important data such as banking password or payment details before they hit the network. The code must be heavily obfuscated to prevent automatic extraction of the public key and algorithm form the JS source in the proxy. This stops lazy thieves that capture the password or one-time-codes for later use while modifying original ones so a banking site would reply with a password error page. This way the thieves do not need to develop any fake pages etc. However, this is useless against more sophisticated attacks that either replace the original banking page entirely or patch its elements to minimize the work to emulate the page design and then capture the passwords. To fight with this issue a help from the browser is essential. One possibility is to replace HTTPS with SRP (srp.stanford.edu) or J-PAKE like protocol that allows for the user and the server *mutually* verify each other without leaking a password. However, this is very drastic as it require to switch the whole site to the new protocol. What is essential is to allow a gradual switch where a site can quickly protect few important pages without significant changes in the current setup. Here is what would be very desirable for a banking site: 1. Browser provides a secure GUI that cannot be spoofed from a web page code or even an extension. The GUI implements SRP/J-PAKE handshake. The GUI should support a form of 2 factor authentication where the user first enters one-time code that she gets from an SMS or a hardware token. Then, after the browser confirms that the server knows the code, a user is presented with a picture or a phrase that she can recognize (this is to make spoofing attempts ineffective) and then proceed to enter the password. 2. The same GUI should allow to sign important action like payment to a new account or password/phone change. In this case the GUI should show to the user a text about what is about to happen that it will receive from the server. 3. Both SRP and J-PAKE as their result, beside a mutual authentication, also provide an encryption key. This key is used to receive the fingerprint for the correct SSL certificate. If it does not match the current one, farther connection is stopped. With that in place the schema could be expanded later to perhaps to specify that for particular pages the browser should replace an ordinary SSL session key with one derived from the new SRP/J-PAKE key so more traffic could be protected. Now the question is if something is missed here? ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Defending against malicious SSL proxy
Unfortunately I cannot be more specific than to state that in Scandinavia most fraud attempts comes not directly from operators of botnets, but rather from third-parties buying their services. Those guys develop a so-called config file which the botnet typically applies to victim computer. The file allows to patch incoming/outgoing traffic based on some regular expressions or similar. Proxy-type botnets have been around for few years but previously they trained users to ignore warnings about invalid certificates. Now the warnings are gone. On 30 September 2013 19:46, ianG i...@iang.org wrote: On 30/09/13 20:35 PM, Igor Bukanov wrote: ... A real experience shows that a substantial number of those fraud attempts comes from computers where malware installs own root certificate and then install either real or transparent proxy. The access to the proxy is then sold to third parties that can do with it whatever they want with decrypted traffic. ... As a slight diversion, do you have any documentary evidence on that? I collect a history of attacks on PKI, so as to inform risk analysis, and I like to document any known *real* attacks other than omigosh attacks. iang ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Defending against malicious SSL proxy
I don't know the details of J-Pake etc., This is a type of protocols that allows *mutual* authentication using simple passwords or other shared secrets without leaking any information about the passwords (so dictionary attacks on the captured traffic etc does not work). As a result of the authentification both parties gets a strong shared cryptographic key that they can use for symmetric encryption. but if it could verify a fingerprint to a domain the user has chosen to communicate with (even better without a CA - self signed) SRP/ J-PAKE assumes that the user somehow already posses a shared secret. They cannot be used for password generation. This is not a problem for banks as they typically send the initial password and/or hardware token by post. For ordinary websites this is typically not an option. So even if those protocols are used for encryption as a SSL replacement, some initial establishment of trust must be done by other means. This where is where using SRP/J-PAKE for certificate verification would be very useful on the current web as this implies that the user is vulnerable only during the initial registration. After that she can always be assured that the site where she enters the password indeed knows it. On 1 October 2013 13:54, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: I agree that deploying token-based security mechanisms may take time in many countries; so interim security mechanisms are desirable. True but SSL should be secure too. Not just SSL from banks. I don't know the details of J-Pake etc., but if it could verify a fingerprint to a domain the user has chosen to communicate with (even better without a CA - self signed) then that may be a real step forward as DNSSEC isn't even close to being as secure or as reliable as it should or would need to be. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Fwd: Defending against malicious SSL proxy
-- Forwarded message -- From: Igor Bukanov i...@mir2.org Date: 11 October 2013 15:02 Subject: Re: Defending against malicious SSL proxy To: Brian Smith br...@briansmith.org From a practical point of view anything that requires changes in the existing SSL infrastructure cannot be deployed quickly. Moreover, until all clients support new protocols the server must keep supporting the old way bringing extra deployment headaches. Perhaps that is the reason why everybody still rely on certificate and trust chains. To move forward it would be nice to reuse the existing infrastructure. Hence the idea of using mutual password authentication just to verify SSL certificates. This can be implemented on the application level without updating HTTP servers and with minimal application-specific code. On 11 October 2013 10:33, Brian Smith br...@briansmith.org wrote: On Mon, Sep 30, 2013 at 10:35 AM, Igor Bukanov i...@mir2.org wrote: To fight with this issue a help from the browser is essential. One possibility is to replace HTTPS with SRP (srp.stanford.edu) or J-PAKE like protocol that allows for the user and the server *mutually* verify each other without leaking a password. However, this is very drastic as it require to switch the whole site to the new protocol. What is essential is to allow a gradual switch where a site can quickly protect few important pages without significant changes in the current setup. http://tools.ietf.org/html/draft-oiwa-http-mutualauth-12 See http://tools.ietf.org/html/draft-balfanz-tls-channelid-01 for a different approach. I also posted a message about ChannelID on this list recently. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
