SSL/TLS are protocols used for encrypting information between two points. It is usually between server and client, but there are times when server to server and client to client encryption are needed. For the purpose of this blog, I will focus only on the negotiation between server and client.
For SSL/TLS negotiation to take place, the system administrator must prepare the minimum of 2 files: Private Key and Certificate. When requesting from a Certificate Authority such as Symantec Trust Services, an additional file must be created. This file is called Certificate Signing Request, generated from the Private Key. The process for generating the files are dependent on the software that will be using the files for encryption.
Additional certificates called Intermediate Certificate Authority Certificates and Certificate Authority Root Certificates may need to be installed on the server. This is again server software dependent. There is usually no need to install the Intermediate and Root CA files on the client applications or browsers.
We shall help you in procuring and installing the best SSL Certificates from Global Vendors. We even shall help you in provisioning your servers with LetsEncrypt! Free DV-SSL Cert.
Lets take a deep dive into SSL/TLS technical details:
The following is a standard SSL handshake when RSA key exchange algorithm is used: (Please refer to the diagram above)
Client Hello
– Information that the server needs to communicate with the client using SSL.
– Including SSL version number, cipher settings, session-specific data.
Server Hello
– Information that the client needs to communicate with the server using SSL.
– Including SSL version number, cipher settings, session-specific data.
– Including Server’s Certificate (Public Key)
Authentication and Pre-Master Secret
– Client authenticates the server certificate. (e.g. Common Name / Date / Issuer)
– Client (depending on the cipher) creates the pre-master secret for the session,
– Encrypts with the server’s public key and sends the encrypted pre-master secret to the server.
Decryption and Master Secret
– Server uses its private key to decrypt the pre-master secret,
– Both Server and Client perform steps to generate the master secret with the agreed cipher.
Generate Session Keys
– Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session
Encryption with Session Key
– Both client and server exchange messages to inform that future messages will be encrypted.
(Source: Wikipedia – Transport Layer Security)
Tools such as OpenSSL can be used check the SSL/TLS negotiations. Try running the command below on a Linux/Mac/Windows Machine which has the latest OpenSSL Version installed on it and see the results:
“openssl s_client -connect www.secops.in:443 -state -tls1_2”
Digital certificates:
A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or on assertions made by the private key that corresponds to the certified public key.
Certificate authorities:
In this model of trust relationships, a certificate authority is a trusted third party – trusted both by the subject (owner) of the certificate and by the party relying upon the certificate.
As a consequence of choosing X.509 certificates, certificate authorities and a public key infrastructure are necessary to verify the relation between a certificate and its owner, as well as to generate, sign, and administer the validity of certificates. While this can be more beneficial than verifying the identities via a web of trust, the 2013 mass surveillance disclosures made it more widely known that certificate authorities are a weak point from a security standpoint, allowing man-in-the-middle attacks.
