All about Secure Socket Layer (SSL)

The Secure Socket Layer (SSL) is a commonly used protocol for managing the security of a message transmission on the internet. SSL has recently been succeeded by Transport layer Security (TLS), which is based on SSL. SSL uses the program layer located between HTTP and TCP layers. SSL uses the public –and –private key encryption system from RSA Algorithm which also includes the use of digital certificates.

Why we need SSL

To encrypt Sensitive information

Just imagine, you are browsing a website which sends the data in un-encrypted format over the network. You entered your credit card details in the site. One hacker hacked into the network and gets the unencrypted information from the network and gets your credit card details. Result, you will lose money and you won’t even get to know what hit you.

The primary reason why SSL is used is to keep sensitive information sent across the network encrypted so that only the intended recipient can understand it. Since data will be in encrypted format so even if the hacker is able to get the data, he can’t decrypt the information so you are still safe.

Authentication

In addition to encryption, SSL also provides authentication. Imagine you created a website and your customer are trying to login to your website. In internet, the data is sent through series of computers so any of these computers can pretend to be your website. The malicious servers can trick your users to send the personal information to them.

Using SSL certificate, the Client and the Server can authenticate each other to make sure that they are sending data to the correct client or the server.

Digital Certificate

Digital certificates are the vehicle that SSL uses for public-key cryptography. Public-key cryptography uses two different cryptographic keys: a private key and a public key. Public-key cryptography is also known as asymmetric cryptography, because you can encrypt information with one key and decrypt it with the private key from a given public-private key pair.

Public-private key pairs are simply long strings of data that act as keys to a user's encryption scheme. The user keeps the private key in a secure place (in IIS it would be machine keys folder) and provides the public key to anyone with whom the user wants to communicate. The private key is used to digitally sign all secure communications sent from the user; the public key is used by the recipient to verify the sender's signature.

The private key is used to decrypt text that has been encrypted with the public key. Client sends a message to the server by encrypting it using the public key. Once the Server receives this message it can decrypt it using the private key. In addition to encrypting messages (which ensures privacy), Server can authenticate itself to the Client (so Client know that it is really the Server who sent the message) by using its private key to encrypt a digital certificate. When Client receives it, Client can use the public key to decrypt it.

A digital certificate serves two purposes: it establishes the owner's identity, and it makes the owner's public key available. A digital certificate is issued by a trusted authority--a certificate authority (CA)--and it is issued only for a limited time. When its expiration date passes, the digital certificate must be replaced.

Certificate authorities and trust hierarchies

Trust is a very important concept in digital certificates. Each organization or user must determine which CAs can be accepted as trustworthy.

A user of a security service requiring knowledge of a public key generally needs to obtain and validate a digital certificate containing the required public key. Receiving a digital certificate from a remote party does not give the receiver any assurance about the authenticity of the digital certificate. To verify that the digital certificate is authentic, the receiver needs the public key of the certificate authority that issued the digital certificate.

If the public key user does not already hold an assured copy of the public key of the certificate authority that signed the digital certificate, then the user might need an additional digital certificate to obtain that public key. In general, a chain of multiple digital certificates might be needed, comprising a digital certificate of the public key owner (the end entity) signed by one CA, and optionally one or more additional digital certificates of CAs signed by other CA.

SSL Handshake

1. The client sends a client "hello" message that lists the cryptographic capabilities of the client (sorted in client preference order), such as the version of SSL, the cipher suites supported by the client, and the data compression methods supported by the client. The message also contains a 28-byte random number.
2. The server responds with a server "hello" message that contains the cryptographic method (cipher suite) and the data compression method selected by the server, the session ID, and another random number.

Note:

The client and the server must support at least one common cipher suite, or else the handshake fails. The server generally chooses the strongest common cipher suite.

1. The server also sends its digital certificate.
2. If the server uses SSL V3, and if the application requires a digital certificate for client authentication, the server sends a "digital certificate request" message. In the "digital certificate request" message, the server sends a list of the types of digital certificates supported and the distinguished names of acceptable certificate authorities.
3. The server sends a server "hello done" message and waits for a client response.
4. Upon receipt of the server "hello done" message, the client (the Web browser) verifies the validity of the server's digital certificate and checks that the server's "hello" parameters are acceptable.
5. The client sends a "client key exchange" message. This message contains the pre-master secret, a 46-byte random number used in the generation of the symmetric encryption keys and the message authentication code (MAC) keys, encrypted with the public key of the server.

If the server requested a client digital certificate, the client sends a digital certificate, or if no suitable digital certificate is available, the client sends a "no digital certificate" alert. This alert is only a warning, but the server application can fail the session if client authentication is mandatory.

If the client sent a digital certificate to the server, the client sends a "digital certificate verify" message signed with the client's private key. By verifying the signature of this message, the server can explicitly verify the ownership of the client digital certificate.

Note:

An additional process to verify the server digital certificate is not necessary. If the server does not have the private key that belongs to the digital certificate, it cannot decrypt the pre-master secret and create the correct keys for the symmetric encryption algorithm, and the handshake fails.

1. The client uses a series of cryptographic operations to convert the pre-master secret into a master secret, from which all key material required for encryption and message authentication is derived. Then the client sends a "change cipher spec" message to make the server switch to the newly negotiated cipher suite. The next message sent by the client (the "finished" message) is the first message encrypted with this cipher method and keys.
2. The server responds with a "change cipher spec" and a "finished" message of its own.
3. The SSL handshake ends, and encrypted application data can be sent.

SSL in IIS6

1. After the TCP handshake and SSL handshake, The HTTP requests in the encrypted form reach to the HTTP.SYS layer.

2. The Kernel mode HTTP.SYS driver doesn’t know how to decrypt the request.

3. Kernel driver uses the service called HTTP SSL Service to do the operation. This service runs under Lsass.exe and this service runs under the user mode.

4. The HTTP Protocol stack receives the request from the client and then it will place it in the SSL Queue.

5. There is a filter called HTTPFilter in the HTTP SSL Service which keeps listening to the SSL Queue. As soon as the request comes, it will pick it up for processing.

6. HTTP Filter checks the IP-Address and port from the request. Get the Certificate from the SSL Binding info based on the IP-Address and port, decrypt the request and then send the decrypted request to the HTTP.SYS Layer.

7. After decryption of the request HTTP.SYS knows about the IP-Address, port and the host-header so it will put the request accordingly in the correct worker process request queue. From where w3wp.exe picks it up and work on it.

8. After processing w3wp.exe sends the response to the HTTP.SYS layer. HTTP.SYS layer again put the response into the SSL Queue.

9. HTTPFilter again picks up the request from the SSL Queue, get the certificate and then encrypt the request using the private key and then send the encrypted request to the HTTP.SYS.

10. HTTP.SYS then send this encrypted request to the Client.

SSL in IIS7

HTTPSSL Service is in UserMode and HTTP.Sys is in Kernel mode. As mentioned above, the IIS6 process of SSL encryption and decryption require lot of context switching between the User mode and the Kernel mode and thus reduce the performance. You can enable the Kernel mode SSL in IIS6 using the registry key as mentioned in the following article

https://technet.microsoft.com/en-in/library/dd441380%28v=office.13%29.aspx

In IIS7, The SSL is done by default at the Kernel level at HTTP.SYS layer. So it improves the performance.

In IIS7, instead of using HTTPFilter SSL uses Schannel driver in the Kernel mode itself for the encryption and decryption of the request.

IIS6 SSL request/response flow

IIS7 SSL request/response flow

This new design of how SSL processing is done inside kernel mode increases performance on IIS7.

Server Authentication

SSL by itself does not guarantee that the client is communicating with the correct server.

  To illustrate the risks involved with this protocol, consider the following scenario. There are two servers,Server1 (myserver1.com) and Server2 (myserver2.com), and one client, Client ( IE ) . Both servers have valid certificates from a CA that the client trusts. Client wants a secure session with Server1, but Server2 wants to eavesdrop on their communication, and is physically located in such a place that it can do so. The scenario goes as follows:

1. Client sends a request for an SSL session to Server1. The request (and all subsequent traffic) actually goes through Server2. Instead of forwarding Client's request to Server1, Server2 responds directly to the request by sending its own certificate to Client.

2. Client receives Server2's certificate and checks its list of trusted CAs. Since Server2's certificate is signed by the same CA as Server1's certificate, Client accepts the certificate and creates a secure session with Server2.

3. Having completed the secure session with Client, Server2 requests and creates its own SSL session with Server1. From this point, Client sends encrypted information to Server2. Server2 decrypts the information, re-encrypts it, and then sends it to Server1. It does the same for information flowing in the opposite direction. The result is that, although all data is encrypted when it flows over the Internet, Server2 is able to read it, and even change it.

4.

To avoid the above danger, there is something called Server authentication. Server Authentication is a mechanism by which a Client authenticate the server so that Client will get to know if it is talking to the correct server or not. To authenticate the server one condition has to match that the common name in the server's certificate must match its Internet name.

After Enabling Server Authentication the above scenario goes now like this

1. Client sends a request for an SSL session to Server1. The request (and all subsequent traffic) actually goes through Server2. Instead of forwarding Client's request to Server1, Server2 responds directly to Client's request by sending its own certificate to Client.

2. Client receives Server2's certificate and checks its list of trusted CAs. Since Server2's certificate is signed by the same CA as Server1's certificate, Client accepts the certificate and creates a secure session with Server2.

3. After the secure session has been completed, but before any real data has been sent or received, Client compares the Internet name in the certificate it received (myserver2.com) with the name of the server it wants to talk to (myserver1.com). Since they do not match, Client knows that the connection should not continue and disconnects it.

To know how client authenticate the server please follow the link

https://support.microsoft.com/kb/257587