Asymmetrical cryptography in HTTPS
As mentioned earlier in this chapter, asymmetrical cryptography is utilized between a web client and web server to agree on a shared encryption key (also known as shared secret or session key) that is then used in symmetrical cryptography. In other words, the key is used by both the web client and web server to encrypt mutual HTTP communications. We have already covered the symmetrical cryptography part of this interaction, so now let's pe a bit deeper into how the asymmetrical cryptography part is carried out.
A handshake occurs between the web client and web server, where the client indicates its intention to start a secure communication session to the server. Typically, this entails agreeing on some mathematical details on how the encryption occurs.
The server then replies with a digital certificate. If you are not familiar with the concept of digital certificates, then now is the time to shed some light on what it is. A digital certificate (or a public-key certificate) is an electronic document that proves the ownership of a public key. To understand the importance of digital certificates, let's take a couple of steps back to remember what a public key is.
As covered earlier, a public key is an encryption key used in asymmetric cryptography (or public-key algorithms); the key can only encrypt data but can never decrypt it back, and it can be shared with anyone who we wish to communicate with. The issuer of the public key always holds a corresponding key called the private key, which can decrypt the data encrypted by the public key.
This sounds great, but what happens if a client requests a public key to communicate with a server, then a bad agent intercepts this request and replies with its own public key (this is known as a man-in-the-middle attack)? The client will then keep communicating with this bad agent thinking that it is the legitimate server; the client may then send sensitive information, such as credit card numbers or personal data, to the bad agent. Obviously, if we seek true protection and security, we want to avoid this scenario at all costs, hence comes the need for certificates.
A digital certificate is a digital document that gets issued by a trusted third-party entity. The document contains a public encryption key, the server name that the key belongs to, and the name of the trusted third-party entity who verifies that the information is correct and that the public key belongs to the expected key owner (also called the issuer of the certificate). The trusted third-party entity who issues the certificate is known as a CA (certificate authority). There are multiple known CA who issue a certificate and verify identities for businesses and organizations. They typically charge a fee for their service. For larger organizations or government bodies, they issue their own certificates; this process is known as self-signing, and hence, their certificates are known as self-signed certificates. Certificates can have expiry dates by which the certificates will need to be renewed; this is for extra protection to protect in case the entity that owned the certificate in the past had changed.
A web client typically contains a list of certificate authorities that it knows of. So, when the client attempts to connect to a web server, the web server responds with a digital certificate. The web client looks for the issuer of the certificate and compares the issuer with the list of certificate authorities that it knows. If the web client knows and trusts the certificate issuer, then it will continue with the connection to that server and make use of the public key in the certificate.
The public key obtained from the server will then be used to encrypt communications in order to securely negotiate a shared encryption key (or session key or shared secret) to then be used in symmetrical cryptography communications between the web client and web server. There is a number of algorithms that can be used to generate this session key, but they are beyond the scope of this chapter. What we need to know is that once a session key is agreed on, the initial handshake between the web client and web server will conclude, allowing the actual communication session to proceed securely under the protection of the shared session key.
With this, we now have sufficient practical understanding of how web communications are secured. This is used for secure Restful web APIs and secure web page loads. One more important remark to add is that the URL utilized for secure web communications starts with https:// instead of http://. This is obvious because secure web communications utilize HTTPS instead of just HTTP.