Secure HTTP (HTTPS) conection for the Half-Initiated : SSL/TLS

The goal

I am a client application and want to talk to you, the server application, privately, with nobody eavesdropping or tampering with my messages. I also want to know that you, server, are who you claim to be, because I want to do some serious business with you.

The situation

You and I are using a common language, HTTP (protocol, ie a standard how we talk to each other, what we need to do etc) that we need to follow. As our communication travels over the internet, it can be intercepted, listened to. To prevent this, we need a secure and authenticated channel of communication. Enter SSL/TLS cryptographic protocols: Secure Sockets Layer/Transport Layer Security. These two provide the same, TLS being a newer, safer version. As old habits die hard, many people use SSL to mean any of the two.

SSL/TLS cryptographic protocols

SSL/TLS protocols, being more general, are used as a wrapper around the HTTP (or other Application Layer protocols like FTP, SMTP, XMPP etc). The protocols are based on the X.509 standard. The corresponding PKI - Public Key Infrastructure, a framework for secure communication (based on the standard) - collection of hardware, software, policies and procedures - allows the following to happen:

1. We shall end up in a secure communication channel where everything, including URLs, HTTP headers and POST data is encrypted. Our communication will be safe from prying eyes and devious minds.
2. Your identity was verified by a trusted party, so I shall know that you really are you and, if required, you know know I am I. I can trust you.

Public key cryptography

The protocols are based on public key cryptography. Public key cryptography is called asymmetric, because one party (one application) has a pair of keys (essentially two long nonsensical strings), a private one and a public one, and the other party(ies) (application(s) eg browser(s)) is given the mentioned public key.

The public key is used to:

• encrypt data
• verify authenticity of the data

The private key is used to:

• decrypt the encrypted data
• offer proof of authenticity (of both the data and the data sender) by using this key and the data to be sent to create a digital signature

• it is important that the private key is kept truly private and never disclosed. 

(In symmetric cryptography both parties share a private key. This key is used for all of the functions mentioned above, hence the word 'symmetric'.)

The public and private keys are mathematically related and have the following properties:

1. There is 1-to-1 relationship between them, ie one private key is associated with just one public key and vice versa.
2. The private key cannot be reverse-engineered from the private key

Authenticity

The basis for establishing trust between applications are digital certificates, documents providing all the relevant information for confirming validity of the data and the sender. They contain:

1. public key
2. meta data (company info, expiry date, which DNS domains the certificate covers)
3. trusted CA (Certificate Authority) signature that 1) and 2) are correct

Certificate Authority (CA) is an entity issuing digital certificates, a third party, trusted by those wanting to establish a secure connection. A company can decide which root CAs (the very top ones have a self-signed certificate) they will use. (The browser development team will, for instance, include their chosen CAs in the binary.) Top CAs can create other, intermediate CAs in a chain of trust.

How it works

Obtaining private and public keys and the certificate

1. Owner of an application creates the key pair
2. Owner sends a Certificate Signing Request (CSR, a digital file) to a CA, containing:
1. Public key
2. Information to identify the owner (fully qualified domains that the owner wants secured, organization name, email, address etc)
3. Owner obtains the certificate from the CA (signed CSR)
4. He distributes the certificate to other parties
1. Root CA certificates are distributed by some type of bootstrapping: browsers come with root certificates, modern operating systems come with root certificates etc

Secure communication - SSL handshake

1. Browser connects to a website, ie web server, secured with SSL (the URL contains https). Browser requests that the server identify itself
2. Server sends over a copy of its SSL Certificate. The certificate includes its public key.
3. Browser checks the certificate root against a list of trusted CAs the validity of the certificate (expired?, revoked?) and also, that its common name is valid for the website that it is connecting to. If the browser is satisfied about the certificate authenticity, it creates and encrypts a symmetric session key using the server’s public key. It send it over to the web server.
4. Server decrypts the symmetric session key (using its private key). Sends back an acknowledgement encrypted with the session key to start the encrypted session.
5. From now on, the Server and the Browser encrypt all transmitted data with the session key

The impact of SSL/TLS

Opening a TCP connection for HTTP uses a three-way (3 packet) handshake. The prerequisite is that the server is listening on a port, so clients can bind to it and start a communication. This handshake involves:

1. client opening a socket
2. client sending SYN package
3. server sending back SYN/ACK package
4. client responding with ACK package

When both the client (phases 2 and 3 ) and server (phases 3 and 4) have received an acknowledgement, the interchange of data can start.

Establishing an SSL/TLS connection happens on top of the three-way TCP connection. After the TCP/HTTP connection is in place, the client requests are forwarded to the SSL/TLS port where the rules of the SSL/TLS protocol are followed. The SSL handshake involves verifying server authenticity etc, after which decrypting and encrypting of transmitted information happens.

https://realtimelogic.com/images/HTTPS-scalability-prob/client-server-handshake.jpg

To avoid performing a handshake for each request, an HTTP persistent connection (HTTP keep-alive) can be taken advantage. This is a way of reusing a single TCP connection for multiple requests/responses. This is particularly relevant for SSL/TLS connections (more CPU and network trips needed during the connection startup). All modern browsers implement
HTTP keep-alive.

SSL connection means, that everything sent, headers, urls, images etc, is encrypted. Encryption means number crunching, therefore higher consumption of resources (CPU). The need for resources depends on the cipher (the algorithm used for encryption and decryption), certificate key lengths, type and size of sent data, volume of requests. As a result, a web server serving SSL encrypted traffic, will experience higher load. This can be helped by delegating dealing with SSL to a reverse proxy, where the SSL traffic is terminated and the request is sent further unencrypted to one of the web application servers. The reverse is true for the HTTP response being returned. The load on the web application servers is reduced, however, the users are still affected by the increase of the page load time due to the encryption being performed.