HTTPS 是如何工作的，它是否使用 cookie？

Question

I have a basic understanding that HTTPS creates a secure connection between a user and a server using some sort of unique identifying code. However, if the server sends this code (or whatever it is) to the user, can't that code be intercepted and that renders the entire HTTPS just as vulnerable as HTTP?

I'm a total newbie to this area, and am interested in how it works. The current answers on Stack Overflow don't give me the full answer.

Answer 1

I'm not sure it's fair to say there isn't any answer on Stack Overflow to the question of how SSL works: https://stackoverflow.com/search?q=how+does+ssl+work

Cookies work the same way over HTTPS that they do over HTTP. HTTPS is just HTTP, but with the server and client using a "shared secret" symmetric encryption key to encrypt and decrypt the data they exchange so that a third party can't intercept and read the communication.

So having said that, and largely agreeing with the advice to start reading at Wikipedia , why don't I take a quick stab at doing this a modest disservice by explaining it as briefly as I know how.

First, "SSL" is now officially obsolete since the POODLE exploit in SSLv3 will never be fixed. SSL (Secure Sockets Layer) has been succeeded by TLS (Transport Layer Security) and has really become a generic although somewhat inaccurate term referring to secure HTTP (HTTPS).

Still, SSL and TLS both use the same underlying technologies and general ideas.

There are several technologies involved, all of them complicated, and the interplay between them is complicated.

But here are the high points, jammed into a little nutshell.

SSL/TLS fundamentally relies on public/private key asymmetric encryption , in order to securely exchange a shared secret--an ephemeral (disposable, short-lived) symmetric encryption key known only to the server and the client, which the client and server then use to encrypt the messages they exchange from that point forward.

Asymmetric encryption is a big, quite sciencey topic all by itself.

a·sym·me·try

āˈsimətrē/

noun : lack of equality or equivalence between parts or aspects of something; lack of symmetry.

Assymetric encryption utilizes paired private and public keys which are derived mathematically from very large, mathematically related prime numbers.

The encryption is asymmetric because if a message is encrypted with the "private" key, it can only be decrypted by the "public" key, and vice-versa.

It is therefore absolutely critical to keep the private key private. The public key can be (indeed is ) published to the world

TLS uses asymmetric encryption and a handshake protocol to create and exchange a symmetric session encryption key that is known only to the server and the client.

Asymmetric encryption is an order of magnitude slower than symmetric encryption, making it unsuitable for encrypting data for real-time communication. The other thing making it unsuitable for encrypting data for two-way communication is that anything encrypted with the server's private key can be decrypted by anybody who has possession of the public key. By definition, that's everybody .

So, committing an atrocious act of willful oversimplification; the handshake protocol basically allows the client to send an encrypted challenge that only the server can decrypt, the server can then sign that challenge with its private key and return it. The client knows both which challenge it sent, and how to verify the server's signature using the server's public key. Once the client and the server are satisfied that their communication has not been tampered with, they can securely exchange an ephemeral symmetric encryption key. Some steps may be combined to reduce the number of round trips, and different versions of the protocol, you know, differ somewhat in the details... (willfully oversimplified, remember).

There are a number of encryption protocols and key lengths that can be used, and these specifics are negotiated during the key exchange. Let's just say the client and server agree to AES encryption with a 256 bit key.

So, once the client and server have securely exchanged that 256 bit key (the size of which they negotiated), they can encrypt and exchange data securely at will using that key with the AES algorithm that they also negotiated. No other party has that ephemeral encryption key, thus no other party can decrypt the data they exchange.

Symmetric encryption is much, much faster than asymmetric encryption. As such, the performance impact of encrypting/decrypting large data transfers is virtually irrelevant.

The expensive part of HTTPS is in the initial protocol handshake and key exchange since it requires multiple round trips and a couple of rounds of super expensive asymmetric encryption. Because of this, HTTPS communication benefits enormously when the client and server reuse the same connection for multiple requests. For information on that, look into the SPDY protocol.

Finally, you should research forward secrecy and/or perfect forward secrecy . What forward secrecy does is to exchange an ephemeral public/private keypair during the handshake, then use that ephemeral public/private key pair to handshake and exchange a private symmetric key and quickly discard the ephemeral private/public keypair. What this accomplishes is protection against replay and decryption of a captured HTTPS session in the future if the web server's private key is compromised.

Answer 2

There are protocols that allow two parties to arrive at a shared encryption key, even though all communication between them is in the clear.

Check out the Wikipedia article on how this happens during the SSL handshake.

After they have this session key, this is used to encrypt the payload messages.