Field notes

What's the deal with HTTPS?

HTTPS is designed to secure communication between parties by establishing encrypted connection. It allows to encrypt the messages so even if they’re intercepted nobody would be able to read them or modify unless they have a pair of Public/Private keys.

This is achieved by utilizing asymmetric encryption keys.

  1. The process starts with a handshake. Client sends ClientHello message when it wants to initiate the communication. The message contains metadata with preferred SSL version, cipher suites etc. Server chooses preferred settings and sends ServerHello message in response. It contains similar set of data.
  2. Client and Server are exchanging with their digital certificates. Among other information certificate includes public key and the information about its issuer. For simplicity’s sake in this step we can focus on Server. It sends certificate to prove its identity to the Client. So the client knows that it communicates to the Server that is legit.
  3. Client verifies the certificate to be sure it’s issued by one of the trusted Certification Authorities. This is important part as client has to be sure that certificate was not tampered while it was in transit from server. Otherwise somebody could have intercepted request and exchanged the certificate. If we’re talking about secure applications server can also check client’s identity to be sure it can trust it.
  4. Client generates a random pre-master secret, encrypts it with Server’s public key and sends it to Server. The Server decrypts it by using its own Private Key. Now both parties can derive the same symmetric session key from it. This key will be used for encrypting and decrypting all the messages in further communication. Utilizing symmetric key requires less computational power and allows to save some resources.

One note here. This RSA key exchange is how older TLS versions worked. TLS 1.3 removed it and uses ephemeral Diffie-Hellman (ECDHE) instead, which gives forward secrecy. The certificate and CA trust story stays the same though.

The important part in the above algorithm is played by Certification Authority (CA). Without CA it wouldn’t be possible to negotiate symmetric key as parties wouldn’t know if they could trust to certificates they receive. Anybody could intercept the requests and edit the certificates. But having CA in place allows to verify if Certificate is legit. The browser itself is coming with predefined list of CAs that can be used to verify legitimacy of the certificates. On top of that the browser also has a list of trusted certificates controlled by secure centralized group. If needed you can extend this list on your own.

keys exchange flow in https flow

Digital Certificate

Certificate is a file that contains information about server owning it. It consists of the following blocks:

  • Subject - name of the entity it was issued to
  • Validity period
  • Public key - opposite to Private Key this one distributed publicly with the certificate. Private Key stored securely on the server
  • Digital signature - used to verify authenticity of the certificate. Certification Authority that issued this certificate needs to be trusted by Client. If that’s the case Client can use public key of CA to verify if Digital Signature is valid.

There are different formats you’ll see certificates stored in:

  • PEM (Privacy Enhanced Mail) - Files with extension .pem. Contains base64 encoded certificate between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----
  • PKCS (Public-key cryptography standards ) - Files with extensions .p12, .p8, .p7b etc. They contain public and private keys in the same file.
  • DER (Distinguished Encoding Rules) - Files with extensions .cer, .crt, .der. Contains binary encoded certificate.

SSL Certificate Pinning

This is the process of associating a host with its certificate or public key. It’s used to verify that communication with host stays secure. By using SSL pinning you make your application to trust predefined certificates and public keys.

So if you distribute the application you need to embed certificate into the application bundle. Then at the runtime application would rely on this certificate to compare it with what comes from server.

Public Key Pinning

In practical terms it means you’re retrieving public key from the certificate as a string. Then this string is passed into your application as configuration parameter. Then at runtime application would rely on this string to compare it with public key coming from server in Certificate.

The benefit of pinning public key over pinning certificate is that you don’t need to re-distribute application every time certificate changes. As certificate rotation happens public key doesn’t change so applications using it wouldn’t need to be re-distributed. The downside though is that you need to extract public key from certificate coming from server every time the connection is established.

References

  1. How does HTTPS actually work?