HTTPS Security
HTTPS (Secure HTTP), as the name suggests is secure way of communicating over HTTP protocol. Under the hood, it uses a cryptographic protocol known as SSL (Secure Socket Layer) or TLS (Transport Layer Security), which provides encryption of data.
Note that SSL protocol is deprecated and is replaced by TLS protocol. There are various versions of TLS protocol which could be used for example, TLS 1.1, TLS 1.2 etc.
We will be using the terms SSL and TLS interchangeably in this section to provide general overview of how they work.
A SSL communication happens between two systems, referred to as a Client and a Server. There are two categories of system interaction:
- Client is a Browser, and the Server is an application running on a web server.
- Client and the Server are both applications running on a web server.
Further, there are two types of SSL Communication:
- One way SSL - Only the server has a valid certificate and this certificate is used in the communication.
- Two way SSL (or Mutually Authenticated SSL known as MASSL) – Both the server and the client have valid certificates and these certificates are used in the communication. In MASSL, the server would be configured to mandatorily expect a certificate from a client.
Certificates and Authority:
We would look what is a Certificate, who issues a Certificate etc. in the below sections.
Certificate:
A Certificate provides a proof of identity to a system (the system can act either as a client or a server in a SSL communication). To give an analogy, a certificate could be an Identity proof for an individual like a Passport for instance.
Certificate Authority:
Certificates are issued (actually signed) by well-known and trusted organizations like Digicert, Verisign etc., which are known as ‘Certificate Authority’ (CA). Continuing with the analogy, certificate authority are like governments who are authorized entities to issue a passport.
Certificate Trust Store:
A trust store is a logical repository of certificate Authorities, which a system (a browser or a server) would have. Browsers generally will have a list of trusted CA’s pre-installed in their trust store, and we can also add additional CA’s into the browser’s trusted CA store.
Similarly, we can initialize and configure trust stores in web servers (for example, Nginx, Apache etc.), load balancers or any system which takes part in a SSL communication.
Certificate Chains:
There are two types of CAs:
- Root CA
- Intermediate CA
The intermediate CA would have a certificate which is issued and signed by another intermediate CA or a Root CA. Thus we can have a chain of certificates. For example, example.com could have a certificate which is signed by intermediate.com and intermediate.com can have a certificate which is signed by Verisign (which is a Trusted Root CA).
A browser (or any system) would look through the chain of certificates until it finds a certificate which is signed by a trusted CA.
How do we generate a Certificate?
A certificate is associated with a public key and a private key, to facilitate asymmetric encryption. We need to generate a private key and a public key using various tools like (OpenSSL for example) and generate a CSR (also known as Certificate Signing Request) using tools like OpenSSL.
A CSR is a file which contains the public key and the various details like the Organization who is requesting this, the domain name in which the certificate would be installed etc.
This CSR needs to be sent to the CA (the private key should not be sent) and the CA would generate a certificate and digitally sign it.
The certificate thus obtained along with the private key, could then be installed on servers.
Self-Signed Certificates:
Self-signed certificates are certificates which are not issued by trusted CA’s but issued and signed by individuals or organizations on their own.
Why do we need Self signed Certificates?
Let us say an organization ‘XYZ Corporation’ has multiple applications which need to interact amongst themselves using SSL. Getting a certificate using trusted CAs would involve cost and in such cases, the organization can issue certificates which are signed by an Authority within the organization. These certificates could be used for any communication within the Organization, but cannot be used for communication with parties outside the organization, as they would not trust this Certificate Authority. Similarly, these certificates cannot be used for browser to server communication, as browser would not have this CA as a trusted CA. Generally, if you try to browse a website which has self-signed certificate, the browser would show a warning indicating that the website is not secure.
SSL Handshake:
Handshake is a mechanism by which the client and the server exchange information, check each other’s compatibility and agree upon certain things. Let us see the handshake mechanism in more detail.
1. Exchange Hello:
The client sends ‘client hello’ message, in which it sends details like, the TLS protocol it supports, the various cipher suites and a list of algorithms it supports. The server responds with a ‘server hello’, in which, it sends the minimum TLS protocol version required, cipher suites and the list of algorithm it prefers to use.
2. Exchange Certificate:
The server would send its certificate information, which would contain, the public key, certificate Issuing Authority (CA), its validity period. The client would check, if the server has a certificate which is issued by an authority which it trusts and is valid. Every client would have a list of trusted CA’s and if the server certificate’s CA is a CA which is trusted by the client, then handshake will proceed.
If the client also has a certificate (explained later in MASSL), then the client would present its certificate to the server for verification.
3. Exchange Key:
Once, the protocol and algorithms are agreed upon in step 1, and the client has trusted the server (in step 2), the client and server need to agree upon a secret key which would be used for encrypting the future messages. The client would generate a secret key (symmetric key), and it would encrypt the secret key with the server’s public key (obtained in step 2) and send it to the server. The server would decrypt the secret key using its private key and establish a master secret key to be used for all further communications. A SSL session would be established between the client and server and the master key would be valid only for the duration of the session.
Thus, both the server and the client exchange information by encrypting the data using the master key. Thus, a hacker who would try to eavesdrop into the channel and find out what information is being exchanged, would not be able to do so, since the data is encrypted. Also, the key used for encryption is specific to the session established, thus providing enhanced security.
MASSL:
In MASSL, the client is also expected to have a valid Certificate, just like the server does, and in step 2 above, the client is also expected to send its certificate to the server. The server would validate the certificate to establish the identity of the client.
MASSL is used in situations, wherein, we would want only known clients to communicate with the server. MASSL would provide additional protection, wherein untrusted clients cannot communicate with the server. MASSL is generally used to secure communication between two systems and is not generally used if the client is a browser or a browser based client.