@UseTheFork I agree with Sri that SSL/TLS is the best you can do.
When using SSL/TLS you can force your application to use encryption (e.g. showing a login page if a request comes via http or automatically redirect). Therefore, Mallory can't just modify the protokoll from https to http. The client can validate the signed response with the certificate. Hence, he can detect if mallory modified the communication (wrong certificate or handshake). In this case the browser should present the user a site which tells him that someting is going wrong (e.g. tell him that the certificate is self signed or signed by an distrusted authority). If you use DH you must ensure that the received numbers are valid. When you use JS you hava no possibility to do that. You would need something like the trusted certificates (of trustworthy CAs) used in SSL. Basdl On Dec 14, 12:17 pm, UseTheFork <[email protected]> wrote: > Hi Sri, > > On Dec 13, 11:00 pm, Sripathi Krishnan <[email protected]> > wrote: > > > @UseTheFork > > We have had similar discussions on the web security mailing lists. Here is a > > relevant discussion > > thread<http://www.webappsec.org/lists/websecurity/archive/2010-09/msg00079.html>. > > Short summary is that SSL/TLS has its limitations, but thats the best you > > can do. > > I read this document carefully. The claims made by the author are > utter C.R.A.P. Here is why: > > i) Client wants to log in to server using form > ii) Server sends random r to client > iii) Mallory let's the communication pass > iv) Client computes h_user using r > v) Client sends h_user back to server > iv) Mallory intercepts h_user and sends a disconnect to client > v) Mallory forwards h_user to server > vi) Server accepts h_user, believing it is dealing with client > > That's why you should never login with this protocol. I guess we all > agree here. > > > The flaw in your protocol is that the Mallory can modify the javascript > > before it reaches the browser. He doesn't have to modify the algorithm, he > > just has to send the keys to a server of his choice. No algorithm can detect > > that the keys have been siphoned off, because mathematically the server will > > continue to get whatever it expected from the client. > > Because of MITM attack (described > athttp://en.wikipedia.org/wiki/Man-in-the-middle_attack), > Mallory can also siphon certificates under SSL/TLS. Mallory can > impersonate a Certificate Authority too. Hence, your argument is not > sufficient to justify using SSL/TLS to protect JS . > > > > > If you find a way to reliably transport the JS code to the browser, it * > > could* work. But there is no way to do that without SSL, so it is a bit of a > > catch-22. > > No, plain no. SSL does not guarantee reliable transport of JS to > client for the MITM reason mentioned above. Mallory can substitute its > own certificates at any time. The bottom line is that there is no way > to guarantee the identity of a client with 100% certainty when no pre- > established secret between the server and the client is available. > Most often, such pre-established secrets are not available over the > Internet. This is the real starting point, including for SSL/TLS. > > If Mallory breaks the SSL/TLS connection, he/she can break the JS as > well. But, you will agree, this is pointless to Mallory, since he/she > already has broken the SSL/TLS communication. This makes my > implementation and SSL/TLS equivalent in that respect, since in both > case, Mallory can fiddle with JS. > > Now, one could (try to) argue that it is easier to modify the JS when > no SSL/TLS is implemented. Therefore, SSL/TLS brings extra safety. > This is irrelevant, since any protocol to establish a secured > communication should never rely on the algorithm itself and should > detect abnormal communications when algorithm has been modified. I > plan to use Diffie-Hellman and Diffie-Hellman is (often) used in SSL/ > TLS. DH does not work when algorithms are modified, so what would be > the difference between both implementations when JS is tampered? None. > > If I create a pair of keys on my client before I log in, I can use > them like I would with SSL/TLS in my implementation of DH. I only have > to verify the server's certificate to match the security level of SSL/ > TLS. Of course, this pair should be regenerated for each session (use > of cookies = pandora's box), but does SSL/TLS operate differently? No. > > Overall, I still benefit of an integrated solution, with the same > level of security as SSL/TLS when only one side (the server) is > identified, only at the expense of slower JS code. But, according to > my tests, it is still acceptable for what I want to do. > > I remain open to counter arguments, because I know cryptography is > tricky. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
