When we operate on the internet, there are 2 basic questions about security. First is ‘are we dealing with the correct person?’. The Second one ‘is the communication channel being safe and free from eavesdropping?’. The question of dealing with the correct person is, therefore, part of endpoint security. Similarly, The security of the communication channel is the job of channel security. Endpoint and channel security are 2 types of security. Likewise, In the case of site users, authentication identifies the correct person. Similarly, the channel’s security is about encryption.

(See Also: Authentication and Encryption)

The technique of asymmetric key encryption rules the web security landscape. The Public and Private Keys authenticates as well as helps in encrypting. Likewise, The server authenticates itself to the user via a thing called certificates. Similarly, The public key helps to establish a secure channel. the public key distributed in the same certificate. TLS (transport layer security) protocol handles the secure communication channel. The SSL (secure socket layer) certificate identifies the server*. The server is identified by a chain of trust.
PS: These certificates are famously called as SSL certificates. These certificates don’t specify protocol to use nor any server policy. The certificate’s main aim is to identify the server. Currently SSL protocol is depreciated.

1. The Chain of Trust: One of the types of security

In this model of trust, There is one God whom we all trust. He then appoints authorities who do the disbursement of certificates to server owners. The Root Certifying Authority (in short Root CA) is trusted by default. Every operating system has a mechanism to trust these Root CA’s. The program called root program builds this. The OS ships Root CA’s Certificate. This establishes trust. Most Importantly, Root CA certificates are self-signed. The non-internet based distribution and self-signing are the 2 hallmarks of root CA. Misuse is impossible with this Certificate. Since the Private Key is not available, its impossible to generate fake certificates*. The public key only verifies the signature.

PS: If CA is hacked, then this private key can be exploited. Also weak crypto algorithms for generating public and private keys can compromise too.

1.1 The flow of Trust

The Root CA appoints Intermediate CA’s to issue certificates to server owners. The Root CA signs the Intermediate CA’s certificates with his Private Key. The signing establishes trust. Hence we can say Intermediate CA’s enjoys the trust of Root CA’s. Since the Root CA is signing the certificate, there is no need to preload the certificate into OS to establish trust. The public key verifies the signature.

The Intermediate CA will then sign the certificate of the site owner. The site owner will get a certificate once he proves his ownership of the site. The Certificate Signing Request proves ownership to Intermediate CA. Most Importantly, CSR can be generated only if there is root access to the server. The site owner also hosts the certificate of his Intermediate CA. Consequently, hosting of owner’s and Intermediate CA’s certificate establishes this chain of trust. The public key only verifies and doesn’t sign, it establishes chain up to root.

1.2 An alternative model

This chain of trust model is one of the types of security for endpoints. The other model is of Web of Trust model. This model puts the people at the center. PGP is the biggest user of this model. In the WoT model, the user will decide on whom to trust. SSL doesn’t use this WoT model, instead uses the CoT model.

PGP is my default download checking habit. My computer has certificates of all the trusted developers. Whenever I download software, the download’s signature and dev’s certificate is matched. If this fails, I will be looking suspiciously at the ruling elite. Luckily, that hasn’t happened until now.

2. Channel Security:

This is the second one of the 2 types of security. Design aim of this is to prevent eavesdropping. The TLS protocol uses the certificates during the handshake to establish a secure communication channel. The public key encrypts the initial message. The server then uses its private key to decrypt the message. The connection parameters are all mentioned in that message. The connection is established based on that. The handshake process also negotiates the symmetric key (Its used for message encryption/decryption).

The TLS protocol works in the transport layer. The main job is to provide an encrypted communication channel between both the endpoints. This works on the top of TCP. It takes the message from application layer protocols. It then encrypts messages for transmission by TCP. TCP then gives this encrypted message to the client. Client’s TLS implementation decrypts the message. The application layer protocol will then receive the message.

As mentioned in previous sections, the security of crypto matters most. The SSL came in 1995. Then TLS 1.0 which was an improvement over SSL 3.0 came in 1999. The latest TLS version is 1.3. But most sites support 1.2. Due to weak cryptos in TLS 1.0 and 1.1, they have been depreciated.

Conclusion

If you are a site owner, the security of site endpoint and connection is important. Without the ends and connection secured, a hacker can easily unleash a MitM attack. The TLS ensures secrecy of communications. Hence enable at least 1.2 version of it. Older TLS versions are not safe anymore.

To prevent protocol downgrade attacks, enforce HSTS and min TLS version policy. Also, don’t have HTTP version of the site, nor listen on port 80 in your server. Remember HTTP sites and TLS 1.1 support are the clear way to get a penalty in Google Rankings. Only HTTPS connections have fast loading protocols like SPDY(now discontinued by Google) and HTTP 2 support. Lets Encrypt and Cloudflare provide free certificates. At least, use it to secure the site. It’s easy to inject malicious code on insecure connections in MitM scenarios.

If your site is not heavily trafficked, then enable DNSSEC too. The DNSSEC signs the domain records. This signing aids the recursive resolver. The signing will prevent cache poisoning attacks. This veil of secrecy is what gives the best experience to users as there is trust established in every step of the process.