SSL, OCSP vs CRL

When preparing for the CompTIA Security+ (SY0-201) exam, you should have a basic understanding of how SSL is used and how certificates can be checked.

Web sites use certificates to create SSL sessions. When a user clicks a HTTPS link, it initiates the SSL handshake process.

The web site will then send the client a certificate with a public key that can be used in the asymmdtric portion of the SSL session to create a session key. (The session key will then be used in the symmetric portion of the SSL session.) The client needs to verify the certificate is trusted and valid:

Trusted. First, the certificate must have been issued from a trusted certificate authority (CA). A list of trusted CAs can be viewed in Internet Explorer by clicking Tools -> Internet Options, selecting the Content tab, click the Certificates button, and selecting Trusted Root Certification Authorities. If the certificate was issued to the web site from a company with a certificate in the Trusted Root Certification Authority store, it will be trusted. If the certificate is not trusted, the user will be notified that it's not trusted and encouraged not to continue.

Valid. Next, the client attempts to validate the certificate. CAs can revoke certificates if they become compromised in some way. A revoked certificate is considered invalid and shouldn't be used. Revoked certificates are published on a certificate revocation list (CRL). Clients can check if a certificate is valid using one of two methods:

• Requesting the CRL. The client requests a copy of the CRL from the CA. The CA sends the CRL and the client then checks the CRL to see if the certificate is on the list. If it's on the list, it's considered invalid and wouldn't be used.
• Online Certificate Status Protocol (OCSP). OCSP is an improved streamlined process. Instead of the client requesting a copy of the CRL, the client queries the CA about the certificate. Certificates are uniquely identified with a serial number. The CA then replies indicating the certificate is healthy (not revoked), not healthy (revoked), or unknown (the serial number is not known by the CA.

Once the certificate is verified to be trusted and valid, the public key embedded in the certificate is used to encrypt the session key. Imagine the client wants to use a key of 1234. The client then encrypts this key with the public key to result in something like "AF4D2D0F3EB304". (Both the session key and the encrypted session would be much larger but are shortened for illustration purposes. )

At this point, only the client knows the session key. The encrypted session key is sent back to the web server. Since this key was encrypted with the public key (which is matched to the private key held by the server and unknown to anyone else) it can't be decrypted if anyone intercepts it. When the web server receives the encrypted key, it decrypts it with the private key. Use of the public and private key is known as asymmetric encryption.

For the remainder of the session, the client and server use the session key (symmetric encryption).

Darril Gibson