HTTPS (HTTP Secure) is an adaptation of the Hypertext Transfer Protocol (HTTP) for secure communication over a computer network, and is widely used on the Internet.
In HTTPS, the communication protocol is encrypted by Transport Layer Security (TLS), or formerly, its predecessor, Secure Sockets Layer (SSL). The protocol is therefore also often referred to as HTTP over TLS, or HTTP over SSL.
1. Latest Version
TLS1.2 : SSL 2.0 was prohibited in 2011 by RFC 6176, and SSL 3.0 was also later prohibited in June 2015 by RFC 7568.
2. Introduce Encryption Algorithm
2.1 Symmetric encryption algorithm
- DES(Data Encryption Standard)
- 3DES(Triple DES)
- AES(Advanced Encryption Standard)
2.2 Asymmetric encryption algorithm
- RSA(Rivest–Shamir–Adleman)
- DSA(Digital Signature Algorithm)
- ECC(Elliptic Curves Cryptography)
2.3 Hash algorithm
- MD5(Message Digest Algorithm 5)
- SHA(Secure Hash Algorithm)
3. Digital Certificate
The following diagram shows the process of obtaining a Digital Certificate from a CA.
1. Generate Key-pair: User-A generates a Public and Private key-pair or is assigned a key-pair by some authority in their organization.
2. Request CA Certificate: User-A first requests the certificate of the CA Server.
3. CA Certificate Issued: The CA responds with its Certificate. This includes its Public Key and its Digital Signature signed using its Private Key.
4. Gather Information: User-A gathers all information required by the CA Server to obtain its certificate. This information could include User-A email address, fingerprints, etc. that the CA needs to be certain that User-A claims to be who she is.
5. Send Certificate Request: User-A sends a certificate request to the CA consisting of her Public Key and additional information. The certificate request is signed by CA's Public Key.
6. CA verifies User-A: The CA gets the certificate request, verifies User-A's identity and generates a certificate for User-A, binding her identity and her Public Key. The signature of CA verifies the authenticity of the Certificate.
7. CA issues the Certificate: The CA issues the certificate to User-A.
4. TLS Handshake
As we know TLS/SSL is an application layer protocol. Below is a diagram depicting the TCP/IP model:
Below is a diagrammatic representation of the SSL Handshake:
0 ms
TLS runs over a reliable transport (TCP), which means that we must first complete the TCP three-way handshake, which takes one full roundtrip.
56 ms
With the TCP connection in place, the client sends a number of specifications in plain text, such as the version of the TLS protocol it is running, the list of supported ciphersuites, and other TLS options it may want to use.
84 ms
The server picks the TLS protocol version for further communication, decides on a ciphersuite from the list provided by the client, attaches its certificate, and sends the response back to the client. Optionally, the server can also send a request for the client’s certificate and parameters for other TLS extensions.
112 ms
Assuming both sides are able to negotiate a common version and cipher, and the client is happy with the certificate provided by the server, the client initiates either the RSA or the Diffie-Hellman key exchange, which is used to establish the symmetric key for the ensuing session.
140 ms
The server processes the key exchange parameters sent by the client, checks message integrity by verifying the MAC, and returns an encrypted Finished message back to the client.
168 ms
The client decrypts the message with the negotiated symmetric key, verifies the MAC, and if all is well, then the tunnel is established and application data can now be sent.
5. Certificate-Chain
When you receive the certificate for another entity, you might need to use a certificate chain to obtain the root CA certificate.
The certificate chain, also known as the certification path, is a list of certificates used to authenticate an entity. The chain, or path, begins with the certificate of that entity, and each certificate in the chain is signed by the entity identified by the next certificate in the chain. The chain terminates with a root CA certificate. The root CA certificate is always signed by the certificate authority (CA) itself. The signatures of all certificates in the chain must be verified until the root CA certificate is reached.
Each certificate can contain one or more extensions. A certificate belonging to a CA typically contains a BasicConstraints extension with the isCA flag set to indicate that it is allowed to sign other certificates.
6. When will TSL handshake happen
A connection starts with a handshake, and ends when either party states it by sending a close_notify alert message. Typical Web browsers and servers will maintain connections open for some time, closing them after one or two minutes of inactivity; one or several HTTP requests and responses are sent over that connection. In normal HTTPS contexts, there is a one-to-one mapping between the SSL connections and the underlying TCP connections: for each TCP connection (to port 443), there will be a single SSL connection, and when the SSL connection ends, the underlying TCP connection is closed.
A session relates to the asymmetric cryptography which occurs in a "full handshake". The handshake process, which occurs at the beginning of a connection, is about establishing the cryptographic algorithms and keys which will be used to protect the data for that connection. There are two sorts of handshakes:
-
The full handshake is what a client and server do when they don't know each other (they have not talked previously, or that was long ago). In the full handshake, certificates are sent, and asymmetric cryptography (RSA, Diffie-Hellman...) occurs.
-
The abbreviated handshake is what a client and server remember each other; more accurately, they remember the algorithms and keys that they established in a previous full handshake, and agree to reuse them (technically, they reuse the "master secret" and derive from it fresh encryption keys for this connection).
A connection with a full handshake, and the set of connections with abbreviated handshake who reuse that full handshake, constitute together the session.
7. TLS handshake Performance Optimise
7.1 Session Resumption
Resuming an encrypted session through a session ID means that the server keeps track of recent negotiated sessions using unique session IDs. This is done so that when a client reconnects to a server with a session ID, the server can quickly look up the session keys and resume the encrypted communication.
7.2 OCSP Stapling
OCSP stapling resolves both problems in a fashion reminiscent of the Kerberos ticket. In a stapling scenario, the certificate holder queries the OCSP server themselves at regular intervals, obtaining a signed time-stamped OCSP response. When the site's visitors attempt to connect to the site, this response is included ("stapled") with the TLS/SSL handshake via the Certificate Status Request extension response (note: the TLS client must explicitly include a Certificate Status Request extension in its ClientHello TLS/SSL handshake message). While it may appear that allowing the site operator to control verification responses would allow a fraudulent site to issue false verification for a revoked certificate, the stapled responses can't be forged as they need to be directly signed by the certificate authority, not the server. If the client does not receive a stapled response, it will just contact the OCSP server by itself. However, if the client receives an invalid stapled response, it will abort the connection. The only increased risk of OCSP stapling is that the notification of revocation for a certificate may be delayed until the last-signed OCSP response expires.
As a result, clients continue to have verifiable assurance from the certificate authority that the certificate is presently valid (or was quite recently), but no longer need to individually contact the OCSP server. This means that the brunt of the resource burden is now placed back on the certificate holder. It also means that the client software no longer needs to disclose users' browsing habits to any third party.
Overall performance is also improved: When the client fetches the OCSP response directly from the CA, it usually involves the lookup of the domain name of the CA's OCSP server in the DNS as well as establishing a connection to the OCSP server. When OCSP stapling is used, the certificate status information is delivered to the client through an already established channel, reducing overhead and improving performance.
Refers:
https://en.wikipedia.org/wiki/Certificate_signing_request
https://blogs.msdn.microsoft.com/kaushal/2013/08/02/ssl-handshake-and-https-bindings-on-iis/
https://sites.google.com/site/amitsciscozone/home/security/digital-certificates-explained
https://tools.ietf.org/html/rfc5246
https://hpbn.co/transport-layer-security-tls/
https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake
