A web-log on Q3J5cHRvZ3JhcGh5, alert(document.cookie), and screensaver.exe

Menu

Tag Archives: ssl

SSL/TLS provides an extra layer of security to the HTTP, making it HTTP Secure (HTTPS). It works on the Application Layer (OSI Model) along with HTTP. HTTPS is not a different protocol, but the underlying HTTP with implementation of SSL/TLS for security.

Public Key Infrastructure and Certificate Authorities are used for making it possible.

How HTTPS works?

Short Version
Just like the TCP Handshake, a handshake happens in SSL between the server and the client. We can break this handshake into three steps: Hello, Certificate exchange and Key exchange.

Hello

The client sends a Hello message and the server responds with its Hello message. These messages contain information like the SSL version supported, cipher suite and some random data for key generation.

Certificate Exchange

To provide its authenticity, the server has to send its SSL certificate to the client. On receiving the certificate, the client checks whether its verified and trusted by some Certificate Authority, and takes the decision accordingly. For some sensitive applications, the server can ask for a certificate from the client too.

Key Exchange

A symmetric key is exchanged between the two parties. The client computes a key, encrypts it with the server’s public key, and sends it to the server. Only the server can decrypt it, by its own private key. All the communication then takes place encrypted with this symmetric key.

Long VersionClient Hello

After the TCP connection is established, the clients starts the SSL handshake. The important data in the Client’s Hello message includes:

Version Number (eg. SSL 2.0, SSL 3.0, TLS 3.1)

Random Data (which is later used with the Server’s Random Data to generate a secret key)

Cipher Suite (the list of cipher suite available with the client, which includes – the protocol version, the algorithm for key exchange, the algorithm for encryption, and a hash function)

Along with the above mentioned details, the following steps take place in the Server Hello message:

The server sends its digital certificate to the client, which has the server’s public key

Server creates a temporary key to the client

Server asks the client for its certificate, to validate the client’s authenticity

End of hello, meaning the server’s Hello message is done, and client can respond

Client Response

After getting the server’s Hello Done message, client starts talking. It sends the necessary messages in the below mentioned sequence:

Client certificate – contain’s the client’s public key, to provide its authentication at the server

Client Key exchange – the most important part of the communication. The client computes a premaster key from both the random values previously exchanged. This key is then encrypted by server’s public key before sending it, so that only the server can decrypt and get out the original key with its private key.

Change cipher spec – all the further messages will be encrypted using keys and algorithms negotiated

Client Finished – is the hash of the entire conversation. This is the first message which is encrypted and hashed for the session.

Server Final Response

This is the final message in the conversation between the server and the client to have a secured connection. The server’s final response will have:

Change cipher spec – will notify the client that the server will start encrypting the messages with the negotiated keys and algorithms

Server Finished – is the hash of the entire conversation to this point. If the client can decrypt this message and validate the hashes, it means that the SSL/TLS handshake was successful.

After the SSL/TLS handshake is done, further communication is secure between the server and the client.

Example

A representation of how your browser starts a HTTPS connection with website example.com-

Firefox (your browser, for example) connects with the server of example.com with HTTP and asks for the login page which uses HTTPS

For the communication, the server sends Firefox a certificate, which contains the server’s public key

Firefox verifies the public key of the server from the certificate

Firefox chooses a random symmetric key and encrypts it with the public key of the server

On receiving the encrypted message, the server decrypts it with its private key. Nobody else on the network who has received the encrypted message can decrypt it, because they don’t have the server’s private key. Now the server has the symmetric key with it

Every time Firefox wants to send something to example.com in a secured manner, it will encrypt it with the symmetric key. On the other end, the server will decrypt it with the same key

Every website/server which wants to implement HTTPS (i.e. SSL/TLS security) has to buy SSL certificates from authorities like VeriSign, Comodo, etc. Many websites implement HTTPS part only for some important pages (like login or payment) and other parts of the website work on simple HTTP. Implementing HTTPS for the whole website is not much costly, but the CPU overload increases in processing the requests. Hence many website owners keep away from HTTPS because of the cost factor or the overload factor. Recently Google announced that it will reward the HTTPS webpages with a higher ranking in its search results (source).

Why not use asymmetric key encryption for the handshake?

There’s an answer on StackExchange. (1) Asymmetric encryption is much slower compared to symmetric encryption, (2) For the same keylength, asymmetric is weaker compared to symmetric encryption.

What an attacker can see if you are using SSL/TLS during your connection?

If you are using SSL/TLS correctly, the attacker can interpret only some of your data. That includes – the domain you are connected to, the related IP address and port numbers.

For example, if you are doing a Google search using https, the URL in the browser will be: https://www.google.co.in/?gws_rd=ssl#q=what+is+https, and you can see the full URL. But on your cable, only the domain name google.co.in is sent to the DNS for domain name resolution, instead of the full query/URL. Hence, you can say that HTTPS hides your full URL, only the domain name is revealed.

HTTPS provides confidentiality of data, but not anonymity of who is sending / receiving the data.

This interactive image by EFF provides clear understanding of what can be seen by the eavesdroppers while you are using HTTPS and while you are using Tor.

Now you need to make changes for including the SSL connection. First go to the directory sites-available

# cd sites-available

Modify the file “default-ssl” by replacing the contents of SSLCertificateKey and SSLCertificateFile as shown below:

Modify the file “default” by copying the the Virtual host from above and making the changes as in it as shown:

In the folder /etc/apache2/ you need to make changes to the ‘httpd.conf’ file by adding these two lines to the blank file:

Now provide the command to start the ssl service

# a2enmod ssl

Restart the apache service and you will get the service started as shown below:

Congratulations! Your SSL Apache server has started.

Now try to browse your Apache from a remote machine, by typing “http://ip of your server” in its browser.

To check the SSL connection, try ‘https’ instead of ‘http’ before the ip address

At first time, you will get a message that it is an untrusted connection (because it is using a certificate which we have just created, and your will not be having that certificate) Add and exception for the certificate.

After you add an exception for the certificate, finally you will get the SSL connection to the Apache server. The SSL connection will work until you have the respective certificate added to your browser.