Introduction

In today's networked world, many companies demand security, and cryptography is one of the methods for providing that security. In response to Cyara customers’ security concerns, Cyara development team have been incorporating various security measures to address those security concerns.

With introduction of HTTPS, LDAPS and Web Identity on the Cyara web portal, I like many of you had to implement these security measures for Cyara on-premise deployments. I had to learn about SSL, TLS, Certificates, etc. to test the Cyara on-premise deployment and assist the customer to troubleshoot issue when the deployment stops working.

This document covers SSL, TLS, and certificates as well as showing how to implement HTTPS using self-signed certificates. Self-signed certificates are also useful to test on-premise deployment for a lab setup or as a temporary solution while waiting for permanent server certificates.

If you are only interested in how to deploy self-signed certificates, then skip the following sections and go straight to the section on “Setting up Web portal for HTTPS”.

SSL and TLS

TLS was based on SSL 3.0 and they share many details. The differences between the SSL and TLS are very minor and technical, but they are different standards. TLS uses stronger encryption algorithms and has the ability to work on different ports. TLS version 1.0 does not interoperate with SSL version 3.0. TLS was created as a replacement for SSL by the Internet Engineering Task Force (IETF). In addition to HTTPS, SSL/TLS can be used to secure other application-specific protocols such as FTP, SMTP, SIPS and LDAPS to name a few. SSL and TLS makes securing network connections much simpler. Using SSL and TLS does not require any understanding of how cryptographic algorithms work.

SSL and TLS refers to the handshake that takes place between a client and a server. The handshake does not actually do any encryption itself, it just agrees on a shared secret and type of encryption that is going to be used. Due to SSL protocol security vulnerabilities and outdated cipher suites, TLS protocol should be used instead of SSL protocol.

Key exchange or key agreement

Before a client and server can begin to exchange information protected by SSL or TLS, it must securely exchange or agree upon an encryption key and a cipher to use when encrypting data. The methods used for key exchange/agreement are public and private keys generated with for example, RSA, Diffie–Hellman or ephemeral Diffie–Hellman. Public key certificates used during exchange/agreement also vary in the size of the public/private encryption keys used during the exchange and hence the robustness of the security provided.

Symmetric key encryption

Symmetric key algorithms encrypt and decrypt data using a single key. The result can be sent across an insecure medium, allowing only a recipient who has the original key to decrypt the message, which is done by passing the cipher text and the key to a decryption algorithm. Obviously, the key must remain secret for this scheme to be effective.

Asymmetric key encryption

Asymmetric key cryptography suggests a solution to the key distribution problem that plagues symmetric cryptography. In the most popular form of Asymmetric key cryptography, each party has two keys, one that must remain secret (the private key) and one that can be freely distributed (the public key). The two keys have a special mathematical relationship. A message encrypted using public key encryption can be only decrypted using the private key. However, the algorithm works if keys are reversed. If something is encrypted with the private key, it can be decrypted only with the public key.

Digital Certificates

A digital certificate is a type of digital signature. In SSL and TLS there is the possibility of a man in the middle attack with just a normal public key encryption system. To implement a wide scale public key system, an independent source known as a Certificate Authority (CA) acts as the middleman between the client and the server. It confirms each side is who they say they are. The certificate authority’s public key is provided in either a browser or operating system.

A certificate authority is a trusted third party that provides a digital certificate so that a client knows a server isn’t a fake. Some companies that do this are VeriSign, Entrust, GeoTrust, and GoDaddy. The certificate they publish contains a public key used for public key encryption. The trust comes from the fact that the certificate authority has their certificate and public key on almost all OS’s and applications available. However, there exists the potential for someone to trick one of these companies into giving them a certificate that says they are someone else.

Hashing Algorithm

Hash algorithm are used by certification authorities to sign certificates and CRL (certificates revocation list). Two common hashing algorithms are MD5 (Message Digest 5) and the Standard Hash Algorithm 1 (SHA-1). MD5 produces a 128 bit value and SHA-1 creates a 160 bit value. SHA2 is the successor of SHA1, which includes 4 kinds of hash functions: SHA224, SHA256, SHA384 and SHA512. SHA2 works the same way than SHA1 but is stronger and generates a longer hash.

SSL/TLS Protocol Layers

SSL/TLS is comprised of two protocol layers. In the hierarchy, it exists between the application layer and the transport layer. The image below shows a representation of the layers.

The Handshake layer manages what cipher will be used, authentication, and key exchange. The second layer is the Record Layer.

The handshake layer is the layer responsible for the initial handshake done in SSL/TLS. The handshake layer is made up of three sub protocols, Handshake protocol, Change Cipher Spec and Alert.

The Handshake protocol manages the authentication and key exchange required to establish a secure session.

• Cipher Suite Negotiation: Negotiates which cipher suite (TLS 1.0, SSL 3.0, etc.) will be used for the session.
• Authentication: in TLS/SSL the burden of proof of identity is on the server. Public and private keys are used to do this.
• Key exchange: the client and server exchange random numbers and a special number called a Pre-Master Secret. These numbers are combined with data to create the shared or Master Secret. The master Secret is then used to generate the HMAC or MAC, which is the key used for hashing, and the write key, which is used for encryption.

The Change Cipher Spec (CCS) protocol is used to change the encryption being used by the client and server.

• It is normally used as part of the handshake process to switch to symmetric key encryption. The CCS protocol is a single message that tells the peer that the sender wants to change to a new set of keys, which are then created from information exchanged by the handshake protocol. The Handshake Protocol manages the authentication and key exchange required to establish a secure session.

The Alert protocol is used to alert status changes to the peer.

• The primary use of this protocol is to report the cause of failure. Status changes include such things as error condition like invalid message received or message cannot be decrypted, as well as things like the connection has closed. One thing that TLS has over SSL is that TLS has more alert messages than SSL does.

The Record layer is the one that handles the actual data. It gets data from the application layer, encrypts it, fragments it to an appropriate size, as determined by the algorithm, and sends it on to the Transport Layer. Additionally, this layer can optionally compress or decompress data based on if the data is being sent or received.

Handshake Process

The handshake between the client and server in SSL/TLS operates as follows:

1. Client sends a clientHello message to the server and the client’s random value and supported cipher suites.
2. The server sends a serverhello message to the client with the following information

• SSL or TLS Version.
• Selected Cipher
• Random server value
• Session specific data
• Server certificate
• (Optional: Request for client certificate)

3. Client authenticates server
4. The client creates a random Pre-Master Secret and encrypts it with the public key from the server’s certificate and sends it to the server
5. The client sends the client certificate is requested by server. (The client certificate is optional)
6. Server authenticates client.
7. The server and the client each generate the Master Secret to generate symmetric session keys.
8. The client sends the ChangeCipherSpec notification to the server to begin using the session keys for hashing and encrypting data. The client then sends the clientFinished message.
9. The server gets the ChangeCipherSpec and switches to symmetric encryption using the session key. The server sends serverFinished message.
10. SSL or TLS Handshake completed.
11. The client and server can now exchange application data using the symmetric encryption and session key. Symmetric key encryption is faster that Asymmetric key encryption.

Setting up Web portal for HTTPS

The steps below assumes that there are server certificates available for IIS and a self-signed certificate is required for HTTPS setup. For this example a Windows 2008 Server is used, so the screenshots may be different for other versions of Windows Server.

Logon as administrator and select Internet Information Services (IIS) Manager.

Certificates are managed in IIS by clicking the root machine node in the left-hand tree-view explorer, and then selecting the "Server Certificates" icon in the feature pane on the right.

Click the "Create Self-Signed Certificate" link on the right-hand side of the admin tool.

Choose a friendly name for the certificate and click OK.

The self-signed certificate has now been created.

To setup HTTPS for Cyara Web Portal website, select the website node in the left-hand tree-view, and the click the "Bindings" link in its "actions" pane on the right-hand side of the screen.

This will then bring up a dialog that lists all of the binding rules that direct traffic to this site (meaning the host-header/IP address/port combinations for the site).

To enable HTTPS for the site, click the "Add" button. This will bring up an "ADD Site Binding" dialog that we can use to add HTTPS protocol support.  We can select the self-signed certificate we created earlier from the SSL certificate drop-down list in the dialog, and in doing so indicate that we want to use that certificate when encrypting content over SSL.

Click OK

We now have HTTPS enabled for our site.

Testing the Site

• Try connecting to portal by typing the URL of the web portal.

For example, https://192.168.91.44/ (note the usage of "https" instead of "http" to indicate that the connection over TLS is requested).

In case of usage of Internet Explorer an anti-phishing error message the most likely be displayed:

This IE message indicates that the web site is suspicious or has an issue with the certificate. Click the "Continue to this website" link to bypass this security warning and proceed to the site. From the image below, it can be observed that there is a certificate issue with this site.

Click on Certificate error and select View Certificates

The client could not verify and trust the server certificate.

To resolve this certificate issue, a valid certificate that is issued by a Certification Authority or a self-signed certificate is required. Since we are using a self-signed certificate, we will need to import the server certificate instead and store in the trusted store on each of the client host that needs to access the server via HTTPS. To do this, we must first export the server certificate.

Select Server certificates icon in the IIS Administration manager.

Select the self-signed certificate created previously and click on Export.

Enter the path with the certificate name, password and click OK.

Copy the exported certificate to the client host and double click the certificate to import. This will open the Certificate Import Wizard. Select Local Machine and click Next.

Click Next.

Enter the password used to export the certificate and click next.

Select “Place all certificates in the following store” and click Browse.

Select “Trusted Root Certification Authorities” and click OK.

Click Next.

Click Finish.

To check if the certificate was installed, run mmc.exe

From the File drop-down menu, select “Add/Remove Snap-in”.

Select “Certificates” snap-in and click Add.

Select Computer account and click Next.

Click Finish

Click OK.

To verify that the certificate had installed correctly, select Certificates in the left pane. You should see your self-signed certificate in the middle pane. Double click on the certificate to see the details of the certificate.

Select the “Details” tab. The Subject field shows the name of the server. This name should be the FQDN and resolvable by a DNS.

In the example below, the IP address was used and IE browser reported a certificate issue. This because the IP address is not in the certificate as an alternate name.

When the server name was used that matched as in the certificate (this should be the FQDN), IE browser verified the server and established a secure HTTPS connection.

Sources

Below are some of sources I used to compile my notes.

https://www.instantssl.com/ssl-certificate-products/https.html

https://en.wikipedia.org/wiki/HTTPS

https://en.wikipedia.org/wiki/Transport_Layer_Security

https://robertheaton.com/2014/03/27/how-does-https-actually-work/

https://blogs.msdn.microsoft.com/kaushal/2013/08/02/ssl-handshake-and-https-bindings-on-iis/

and many more I cannot remember.