Reputation: 73
I'm trying to understand how internals of HTTPS works. I understand that the server uses symmetric encryption using the pre-master key generated by the client and encrypted with the server's public key. My understanding is also that the server encrypts the hashes of resources rather than the actual resources, which the client will then decrypt and verify the hash. But I have two questions -
Thank you very much in advance for the help!
Upvotes: 0
Views: 136
Reputation: 310903
I understand that the server uses symmetric encryption using the pre-master key generated by the client and encrypted with the server's public key.
Only in some cipher suites. In general you should just regard the session key as securely negotiated by a key-agreement protocol and leave it at that.
My understanding is also that the server encrypts the hashes of resources rather than the actual resources, which the client will then decrypt and verify the hash.
I don't know what this means. The server has to return actual data, not just hashes. There are hashes used over the handshake and the SSL data messages, but that's no concern of yours: it is just part of the privacy SSL provides.
But I have two questions - Is it correct to assume that the actual file is still sent by the server in plain text
No, of course not, it is encrypted with the session key. That's what the session key is for.
and that the browser trusts the contents only because it was able to hash the file and verify it with symmetric encryption?
No. Forget about hashing. Data is encrypted.
How exactly is the information from the client, such as POST payload or URL parameters encrypted when sent to the server?
With the session key.
Would the browser still hash the payload or the URL parameters
No. Forget about hashing.
or will it simply encrypt the data?
Yes.
Upvotes: 3