On Dec 13, 11:00 pm, Sripathi Krishnan <sripathi.krish...@gmail.com
> We have had similar discussions on the web security mailing lists. Here is a
> relevant discussion
> 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
> 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 at http://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
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