The only other thing I can think of is that you're worried about cache files on the client's computer revealing the request data. But presumably (correct me if I'm wrong), the responses from the server already include ample information related to the request (i.e, if I request "/home/user/books", the response will be a nice page with a big header that says "/home/user/books").
Having two seemingly identical layers of encryption sounds pretty redundant to me. Especially when one is at a lower level in the protocol stack, standardized, and well-studied by cryptographers (I have no idea what encryption you are proposing to use on top of the SSL). I don't think this is a case of having two different security mechanisms (suspenders and a belt, using Old_Gray_Bear's terminology) -- it's like using another little tiny belt to hold the buckle onto your first belt! ;)
I'm sorry for the long story- I can't figure out how to shorten it.Shorten it by using fewer words, not by using <small> tags, though I didn't think it was very long to begin with. ;) I could barely read the stuff in the smaller font on my browser.
blokhead
In reply to Re: In a web app, is using ssl, encrypting request data, and validating request data after decryption overkill?
by blokhead
in thread In a web app, is using ssl, encrypting request data, and validating request data after decryption overkill?
by leocharre
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |