HTTPS full handshake

1) Encryption suite interaction;

2) password Exchange;

3) identity authentication;

Full handshake

Initially, client and server "agree upon" null encryption with no MAC and null compression. This means the record they would first send would be sent as cleartext and unprotected.

First message of a handshake is a ClientHello . It is the message by which the client states its intention to do some SSL. Note that the "client" is a symbolic role; It means "the party which speaks first". It so happens this in the HTTPS context, which are http-within-ssl-within-tcp, all three layers has a notion of "client" a nd "Server", and they all agree (the TCP client was also the SSL client and the HTTP client), but that ' s kind of a coincide nCE.

The ClientHello message contains:

• The maximum protocol version, the client wishes to support;
• The "Client Random" (bytes, out of which, is suppose to being generated with a cryptographically strong number Generato R);
• The "Session ID" (in case the client wants to resume a session in an abbreviated handshake, see below);
• The list of "cipher suites" that the client knows of, ordered by client preference;
• The list of compression algorithms that the client knows of, ordered by client preference;
• Some optional extensions.

A cipher suite is a 16-bit symbolic identifier for a set of cryptographic algorithms. For instance, the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite had value 0x002f, and means "records use Hmac/sha-1 and AES encryption with a 128-bit Key, and the key exchange is do by encrypting a random key with the server's RSA public key.

The server responds to the with ClientHello a ServerHello which contains:

• The protocol version that the client and server would use;
• The "Server Random" (bytes, with the random bytes);
• The session ID for this connection;
• The cipher suite that'll be used;
• The compression algorithm that'll be used;
• Optionally, some extensions.

The full handshake looks like this:

  Client                                               Server  ClientHello                  -------->                                                  ServerHello                                                 Certificate*                                           ServerKeyExchange*                                          CertificateRequest*                               <--------      ServerHelloDone  Certificate*  ClientKeyExchange  CertificateVerify*  [ChangeCipherSpec]  Finished                     -------->                                           [ChangeCipherSpec]                               <--------             Finished  Application Data             <------->     Application Data

(This schema has been shamelessly copied from the RFC.)

We see The  clienthello  and  Serverhello . Then, the server sends a few other messages, which depend on the cipher suite and some other parameters:

• Certificate:  the server ' s Certificate, which contains its public key. More on that below. This message was almost always sent, except if the cipher suite mandates a handshake without a certificate.
• serverkeyexchange:  some extra values for the key exchange, if-what are in the certificate are not sufficient. In particular, the ' DHE ' cipher suites use an ephemeral Diffie-hellman key Exchange, which requires that message .
• certificaterequest:  a message requesting that the client also identifies itself With a certificate of its own. This message contains the list of names of trust anchors (aka "Root Certificates"), that the server would use to validate th E client certificate.
• serverhellodone:  a Marker message (of length zero) which says, the server is finished, and T He client should now talk.

The client must then respond with:

• Certificate: The client Certificate, if the server requested one. There is subtle variations between versions (with SSLV3, the client must omit this message if it does does have a certific Ate With TLS 1.0+, in the same situation, it must send a Certificate message with an empty list of certificates).
• Clientkeyexchange: The client part of the actual key exchange (e.g. some random value encrypted with the server R SA key).
• certificateverify: A digital signature computed by the client through all previous handshake messages. This message was sent when the server requested a client certificate, and the client complied. This is what the client proves to the server so it really "owns" the public key which are encoded in the certificate it SE Nt.

Then the client sends a  Changecipherspec  message, which are not a handshake message:it have I TS own record type, so it would be is sent in a record of its own. Its contents is purely symbolic (a single byte of value 1). This message marks the which the client switches to the newly negotiated cipher suite and keys. The subsequent records from the client would then be encrypted.

The finished message is a cryptographic checksum computed through all previous handshake messages (from both the CLI ENT and server). Since It is emitted after ChangeCipherSpec the, it's also covered by the integrity check and the encryption. When the server receives this message and verifies its contents, it obtains a proof that it had indeed talked to the same Client all along. This message protects the handshake from alterations (the attacker cannot modify the handshake messages and still get the Finishedmessage right).

The server finally responds with its own ChangeCipherSpec then Finished . At which point, the handshake are finished, and the client and server may Exchange application data (in Encrypted records TA Gged as such).

To remember: the client suggests but the server chooses. The cipher suite is in the hands of the server. Courteous servers is supposed to follow the preferences of the client (if possible), but they can do otherwise and some A Ctually do (e.g. as part of protection against BEAST).

Abbreviated handshake

In the full handshake, the server sends a "session ID" (i.e. a bunch of up to + bytes) to the client. Later on, the client can come back and send the same session ID as part of the ClientHello . This means, the client still remembers the cipher suite and keys from the previous handshake and would like to reuse T hese parameters. If The server also remembers the cipher suite and keys, then it copies this specific session ID in its ServerHello , and then fol Lows the abbreviated handshake:

  Client Server ClientHello-------->                                Serverhello [Changecipherspec] <--------finished [Changecipherspec] finished-------- > Application Data <-------> Application Data  

The abbreviated handshake is shorter:less messages, No. Asymmetric cryptography business, and, most importantly, reduced l Atency. Web browsers and servers do, a lot. A typical Web browser would open a SSL connection with a full handshake and then does abbreviated handshakes for all other Conne Ctions to the same server:the other connections it opens in parallel, and also the subsequent connections to the same SER Ver. Indeed, typical WEB servers would close connections after all seconds of inactivity, but they would remember sessions (the CI Pher suite and keys) for a lot longer (possibly for hours or even days).

Key Exchange

There is several key exchange algorithms which SSL can use. This was specified by the cipher suite; Each key exchange algorithm works with some kinds of the server public key. The most common key exchange algorithms is:

• RSA : The server ' s key is of type RSA. The client generates a random value (the "Pre-master secret" of the bytes, out of which, is random) and encrypts it with The server ' s public key. There is no  serverkeyexchange .
• dhe_rsa : The server ' s key is of type RSA, but used only for signature. The actual key exchange uses Diffie-hellman. The server sends a  serverkeyexchange  message containing the DH parameters (modulus, generator) and a newly-generated DH public key; Moreover, the server signs this message. The client would respond with a  Clientkeyexchange  message which also contains a newly-generated DH p Ublic key. The DH yields the "Pre-master secret".
• Dhe_dss : like  Dhe_rsa , but the server have a DSS key ("DSS" is also known as  "DSA") . DSS is a signature-only algorithm.

Less commonly used key exchange algorithms include:

• DH: The server ' s key is of type Diffie-hellman (we are talking of a certificate which contains a DH key). This used to is "popular" in an administrative (US federal government mandated it use) while the RSA patent was still Active (This is during the previous century). Despite the bureaucratic push, it was never as widely deployed as RSA.
• DH_anon: Like DHE the suites, but without the signature from the server. This is a certificate-less cipher suite. By construction, it's vulnerable to man-in-the-middle attacks, thus very rarely enabled at all.
• PSK: Pre-shared key cipher suites. The Symmetric-only key exchange, building on a pre-established shared secret.
• SRP: Application of the SRP protocol which is a Password authenticated Key Exchangeprotocol. Client and server authenticate each of the regards to a shared secret, which can be a low-entropy password (whereas PS K requires a high-entropy shared secret). Very Nifty. Not widely supported yet.
• An ephemeral RSA key:like but with DHE a newly-generated RSA key pair. Since generating RSA keys is expensive, which is not a popular option, and was specified only as part of "Export" cipher su Ites which complied to the pre-2000 US export regulations on cryptography (i.e. RSA keys of the for most bits). Nobody does that nowadays.
• Variants of the DH* algorithms with elliptic curves. Very fashionable. Should become common in the future.

Certificates and authentication

Digital Certificates are vessels for asymmetric keys. They is intended to solve key distribution. Namely, the client wants to use the server ' S public key. The attacker would try to make the client use The attacker ' S public key. So the client must has a-to-make sure-it is using the right key.

SSL is supposed. This was a standard for certificates. Each certificate are signed by a certification authority. The idea is, the client inherently knows the public keys of a handful of CAS (these is the "trust anchors" or "root CE Rtificates "). With these keys, the client can verify the signature computed by a CA over a certificate which have been issued to the Serv Er. This process can be extended RECURSIVELY:A CA can issue a certificate for another CA (i.e. sign the certificate structure which contains the other CA name and key). A chain of certificates beginning with a root CA and ending with the server ' s certificate, with intermediate CA certificat Es in between, each certificate being signed relatively to the public key which are encoded in the previous certificate, is Called, unimaginatively, a certificate chain.

So the client was supposed to do the following:

• Get A certificate chain ending with the server ' s certificate. the  Certificate  message from the server was supposed to contain, precisely, such a chain.
• validate the chain, i.e. verifying all the signatures and names and the various. Also, the client should check revocation status of all the certificates in the chain, which is complex and heavy (Web browsers now does it, more or less, but it's a recent development).
• Verify This the intended server Name is indeed written in the server ' s certificate. Because the client does not only want to use a validated public key, it also wants to use the public key of a specifi C server. SEE RFC 2818 for details on how the is do in a HTTPS context.

The certification model with certificates have often been criticized, not really on technical grounds, but rather for Politico-economic reasons. It concentrates validation power into the hands of a few players, who is not necessarily well-intentioned, or at least no T always competent. Now and again, proposals for other systems is published (e.g. Convergence or DNSSEC) but none have gained wide acceptance (yet).

For certificate-based client authentication, it's entirely up to the server to decide what does with a client certificat E (and also-what-if with a client, declined to send a certificate). In the Windows/iis/active Directory World, a client certificate should contain an account name as a "User Principal name" (encoded in a Subject Alt Name extension of the certificate); The server looks it Active Directory server.

Https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work

HTTPS full handshake