HTTPS: Securing java web services
As part of my internship project I had to learn about HTTPS, how it works and how to use HTTPS to secure SOAP based web services written in java.
Why do we need HTTPS?
The document transfer protocol of choice for the internet, HTTP uses a plain text format for transfering data. Hence anyone who is able to intercept the communication channel(MITM attack) can view everything that is being transmitted by the sender and receiver. This is specially a problem for wireless networks where any one with a pretty basic wireless network adapter can tap into and listen to the communications channel.
This can be demonstrated using free and opensource tools like Wireshark and mitmproxy
Demo:
Lets login to a website which does not use https to secure the connection using wireshark. If we inspect the packets using wireshark (as seen in the screenshot below) we can easily see the data sent to the server, which in this case are the email and password of the user. Hence anyone who can tap into the network can easily get hold of the login credentials and there by the users authenticity is compromised.
Now lets check login to the same website with https enabled and inspect the packets: As you can see from the image below, this time the data sent to the server is encrypted; i.e. the user’s credentials are safe.
So, HTTP by default is not suitable for sending private data. For this we need some protocol which provides data security using encryption like HTTPS
What is TLS/SSL?
The required data security/encryption can be provided by many mechanisms, but TLS/SSL has become the ubiquitous defacto standard for the Internet. SSL stands for Secure Socket Layer and TLS is Transport Layer Security. Both are more or less the same specifications with minor differences which we can generally ignore.
As we can see from the above figure, the ssl/tls acts as a layer on top of the transport layer in the IP stack. The connection between the communicating peers is provided by TCP. SSL/TLS acts as a layer in between the transport and application layers and encrypts the data passing through the connection.
Basics of encryption
Broadly speaking there are two kinds of cryptographic techniques used to encrypt data in SSL: symmetric key and asymmetric key cryptography.
Symmetric key or secret key cryprography:
As shown in the figure above, in case of symmetric key cryptography, both the sender and receiver have the same secret key which is used to both encode and decode the data. This technique is fine but we need a way to securely share the secret key.
Assymetric key or public key cryptography:
Now in case of asymmetric key or public key cryptography, there is a pair of keys. One is called the private key and the other is called its public counterpart or simply public key. Data encrypted with the private key can only be decrypted using the corresponding public key and that encrypted using a public key and only be decrypted using the corresponding private key. Hence, in this case the problem of sharing a secret is taken care off.
A basic overview of TLS/SSL:
Note: Public key encryption is more computationally intensive than Secret key encryption. Hence in case of SSL, public key encryption is used to share the secret. This secret is then used to encrypt the data.
The first set of messages is sent from the client to the server.
- It only comprises a
CLIENTHELLO
message.
The second set of messages comprises 2-5 messages that are sent from the server to the client:
- A
SERVERHELLO
message is sent in response to theCLIENTHELLO
message. - If the server is to authenticate itself (which is generally the case), it may
send a
CERTIFICATE
message to the client. - Under some circumstances, the server may send a
SERVERKEYEXCHANGE
message to the client. - If the server requires the client to authenticate itself with a certificate, it
may send a
CERTIFICATEREQUEST
message to the client. - Finally, the server sends a
SERVERHELLODONE
message to the client. - After having exchanged
CLIENTHELLO
andSERVERHELLO
messages, the client and server have negotiated a protocol version, a session identifier (ID), a cipher suite, and a compression method. Furthermore, two random values (i.e.,ClientHello.random
andServerHello.random
), have been generated and are now available for use.
The third set of messages comprises messages that are again sent from the client to the server:
- If the server has sent a
CERTIFICATEREQUEST
message, then the client sends aCERTIFICATE
message to the server. - In the main step of the protocol, the client sends a
CLIENTKEYEXCHANGE
message to the server. The content of this message depends on the key exchange algorithm in use. - If the client has sent a certificate to the server, then it must also send a
CERTIFICATEVERIFY
message to the server. This message is digitally signed with the private key that corresponds to the certificate’s public key. - The client sends a
CHANGECIPHERSPEC
message to the server (using the SSL Change Cipher Spec Protocol) and copies its pending write state into the current write state. - The missing type indicates that the
CHANGECIPHERSPEC
message is not an SSL Handshake Protocol message. Instead, it is an SSL Change Cipher Spec Protocol message (identified with a content type value of 20). - The client sends a
FINISHED
message to the server. As mentioned above, this is the first message that is cryptographically protected under the new cipher spec.
Finally, the fourth set of messages comprises two messages that are sent from the server to the client:
- The server sends another
CHANGECIPHERSPEC
message to the client and copies its pending write state into the current write state. - Finally, the server sends a
FINISHED
message to the client.
At this point in time, the SSL handshake is complete and the client and server may begin exchanging application layer protocol data units (using the SSL Application Data Protocol).
Now lets look into the handshake process using wireshark:
A few words about certificates:
As described earlier the ssl protocol requires that the communicating peers verify their identity using digitally signed certificates. These certificates are generally issued by some trusted certifying authority(CA) which guarantees the identity of the senders.
The most commonly used format for exchanging these certificates is the X.509 format.
There is another type of cerificate scheme which is gaining popularity called the PGP.