In the past https/ssl was mainly used for shopping and Internet banking.
Since mid-2017, Google has flagged all http only websites as unsecured in a further push to drive adoption of https/ssl and to enhance privacy and safety.
Network engineers have to deal with ssl connections for device management access, remote user (ssl) vpns, ssl termination on load balancers and web reverse proxy / authentication services.
SSL certificates and Certificate Authorities
To understand ssl (the current version is also known as TLS), one has to read up on topics including ssl certificates and certification authorities, pki, key exchange. It is not easy figure out how these different elements relate to each other.
I will describe each of these elements and their place in establishing the communications between a web browser to a website.
— proving the website identity
Users who access a website must have some confidence that the website they are browsing is “who it claims to be” and not some other party masquerading as the legitimate owner.
SSL provides this proof of identity by presenting an ssl certificate to users. The ssl certificate can be thought of as a “digital passport” with information about the website. Just like any proof of identity document in the real world, the document must be issued by a recognized authority. For example our passports are issued by the government (immigration authority); and in the digital world ssl certificates are issued by recognized organisations called certification authorities (CAs). Examples of CAs are VeriSign, Entrust, GoDaddy etc.
The CA’s responsibility is to register/verify and record the identity (company name), domain name (of website) etc.
Here is the Amazon website certificate:
In order for a web browser to accept a certificate transmitted to it by the website, it must be able to recognise the CA.
CAs issue their own signed certificates which are called Root certificates.
A Root certificate is self signed by the CA and does not refer to any other authority.
Browsers by default come with a number of Root CAs pre-installed which saves you from having to install them.
You can review these Trusted root CAs under Settings in your preferred browser.
For example in Chrome,
chrome://settings/privacy > Click “manage certificates”
Here is a screenshot of the trusted CA store for my browser.
TLS handshake and key exchange
Let us first take a look at the TLS handshake.
The purpose of the TLS handshake is to set up a secure (encrypted) channel between the web browser and the server. This is achieved by using a pair of RSA crypto keys which the server generates for TLS communications.
At the start, the web browser (referred to a the client) sends a hello to the web server. Once the web server receives the client hello, it returns a response along with the server certificate and information about the encryption protocols/ciphers it supports.
If the server requires the client to authenticate itself, it will optionally request the client’s ssl certificate as well. Usually client authentication is not normally required for most public websites.
The server certificate is sent in the clear without encryption during this phase of the ssl handshake.
The client then examines the presented server certificate and checks
– the domain name matches the website it is accessing
– certificate start and expiry dates are valid
– the issuer is a trusted publisher in it’s CA trust store
There is no requirement to store the server certificate on the client machine as long as the CA is trusted.
Establishing a secure/encrypted channel with the premaster_secret
Once the web browser/client is satisfied with the identity of the server; the next step is to establish a secure / encrypted tunnel between the client and server.
TLS rely on cryptographic “keys” which are long sequences of random numbers (encoded in hex) that is the basis for encryption.
A pair of cryptographic keys (involving 2 large prime numbers) is generated during the creation the tls certificate (by the webserver).
The key pair consists of a public and a private key. The public key is part of the server certificate and made available to the web browser (client). The private key is stored securely on the server and should never be divulged to other parties.
The mathematical relationship between the key pair is such that any message block encrypted by one of the keys can only be decrypted with the corresponding key. Hence the client encrypts the data using the public key. The server then decodes the received encrypted data using it’s private key.
Generating the session key
At the end of the key exchange phase, a Master_secret is created for the actual session to encrypt the data.
The ssl/tls protocol mandates the use of a fixed length Master_secret to generate the session key regardless of the cipher suite agreed on. This stipulation requires a client to transmit a Premaster_secret (and applying a pseudo random function) to derive the fixed length Master_secret.
When the server receives the Premaster_secret , both client and server can then generate the Master_secret and use it to compute the session key.
Premaster_secret >> Master_secret (result = fixed length 48 bytes) >> Session key
Completing the handshake
The final part of the handshake is for the client to signal the change of cipher. During the exchange of the Premaster_secret, the cipher used was an asymmetric cipher. To use the Master_secret the client will now signal the change to use symmetric cipher and the server likewise signal the change to the same symmetric cipher and session key.
Notes on certificates
— Certificates for clients
You can also install certificates on the client side in order to authenticate a client (to the server).
This is most commonly within an organisation for client machines that run programs that access ssl secured services or for vpn connections.
It is up to the server to request client authentication via ssl certificates.
For general Internet browser communications, client certificates are not normally required.
If client ssl authentication is required, the server will be configured with a client certificate required to complete the ssl handshake. The server will normally send to the client a list of CAs it accepts with the server hello. The client should then review the CA list (called Distinguished CA list) received and send a certificate issued by one of these CAs.
If the client does not present a valid certifcate, then the communication will result in an error.
— Intermediate certificates and certificate chains
A browser contains a CA trust store that refers to authorised Root CAs.
However for security reasons most CAs will issue a certificate does not directly refer to their Root (anchor) certificate. Instead the certificate will most likely be signed by another certificate that can be traced back to the root. Such certificates are called intermediate certificates.
For intermediate certificates to be linked back to the root certificate; a “chain of trust” to an authorised Root CA is included with your certificate.
Along with the certificate you purchased, typically the certificate provider will have a bundle of intermediate certificates for you to download from their website; which must be installed to your server.
It is safest to set up your web server to send the intermediate certificates to the client to avoid any gaps in the trust chain. Some badly configured web servers might get away with not sending the intermediate certificates because the browser / client application may fetch their CA certificates using url information from the Authority Information Access (AIA) extension or if the browser has cache the intermediate certificate previously from another site.