Secure-socket Layer Notes

SSL is a mechanism for securing a communication channel, a method of verifying the identity of the key owner. Why aren't passwords enough for that?

Passwords are a means to authenticate a user to see if he is who he claims to be. If the channel on which the password is communicated is not secure, however, it can be intercepted and the identity of the user compromised, permitting someone else to authenticate as that user.

For example...

1. A user logs in to a server on the network.
2. Elsewhere on the network, a hacker is connected and using a sniffer (like Wireshark) to capture HTTP traffic looking for user credentials of people authenticating over insecure channels (such as plain HTTP).
3. If I'm logging in to a server via HTTP, the hacker could see that in the sniffer trace. But, if I am using HTTPS, no useful data can be seen since my communication is encrypted.

But, how does this happen? (How does SSL work?)

While setting up an HTTPS connection to a server, the server's public key is given to my browser and they shake hands over the strongest common algorithm encryption algorithm is accomplished between them (my browser and the server) to create a symmetric key both of us can use for encryption and decryption.

My browser encrypts a message using the algorithm and the shared key with the server's asymmetric public key and sends it back to the server.

The server decrypts it with its private key and now both know the algorithm to use and the shared symmetric key for encryption and decryption.

A TCP socket connection is established and communication over this socket is henceforth encrypted using that shared key

How is the identity of the server verified? (Also important!)

There are four states to check in validating the server's key.

1. The hostname of the server must be verified.
2. The certificate or one of its signatories has to be signed by a third party that is known to be trusted.
3. None of the certificates in the chain can have expired.
4. None of the certificates in the chain can have been revoked.

Man-in-the-Middle attack

It's possible for a hacker to fake who he is.

1. Connect to a server over SSL (or so you think).
2. The server presents a certificate not for the server I was trying to connect to, but for a different one.
3. If I don't verify the hostname of that server against the one in the certificate name, it could be faking it and using its own certificate and you're now exchanging confidential data with it.

This still does not guarantee you have the right server if the other conditions are not met. This is where signatures come into play.

Certificate Signatures

If the second server (in the "man-in-the-middle" attack) had used a self-signed certificate, meaning one that someone had created unofficially, the verifying the certificate name against the hostname would succeed, but the certificate would still not really be the one for the first server, the one I want to connect to.

How to solve this?

There's something called certificate authorities that check out companies and individuals requesting formal certificates—before issuing them. (These cerficates cost big money.) Examples of these companies are Verisign, Thawte and Digicert. (There are more.)

When these companies issue certificates, they sign them using their own certificates thereby vouching for the authenticity/identity of the individual or company requesting the certificate. These certificates are "trusted" something that most operating systems and virtual machines are able to detect. Also, browsers will present a modal dialog to the user when they encounter a certificate that is not trusted. The user then accepts responsibility for continuing on against the browser's advice against using it.

Back to the example, if the server (I want to connect to) presents a certificate that's been signed by one of these authorities, my software knows that certain checks were carried out. If not (as the case with the second server), then my software (or I) must reject it.

More checks...

Beyond this, expired certificates are checked and also the expiration dates of other certificates in any chain must also be checked. A "chain" of certificates can arise when software encounters a certificate whose services lead to the use of another certificate, etc. An expired certificate may indicate that a software producer is out of business or some other reason and it's not a good idea to accept that certificate. There is also the positive case of a revoked certificate, one from an origin that's known to be bad and whose revocation is included in the certificate repository available to operating systems. There do exist "zero-day bugs" and other border cases, but usually the verification as it stands is reliable.

What's just been covered is server authentication. There also exists client or mutual authentication in more peer-to-peer situations.

Public-key encryption

There are two types:

1. symmetric —the same key is used for both encryption and decryption and requires that it be shared between sender and receiver (presumably over a secure channel).
2. asymmetric —there are two keys, a public one for encryption and a private one for decryption. Only the holder of the private key can decrypt, so it's unnecessary to exchange the public between sender and receiver in a secure manner.

How does symmetric encryption work?

Imagine a night safe at a bank. You can:

1. open the chute
2. deposit your money
3. but only the banker has the private key to be able to retrieve your deposit (and credit your account).

So, ...

1. you can open the chute and deposit cash
2. others can open the chute, but can't reach (decrypt) your cash
3. only the banker can retrieve (decrypt) your cash.

In practice, you can give out your public key so that anyone wanting to send you information (deposit cash/encrypt the information) can do so, but only you can decrypt it (retrieve the information).

You must keep your private key safe. Once it gets out, everyone can decrypt information.

In practice...

When you connect via your browser to a site using HTTPS, the server passes your browser its public key (and information about the cryptographic algorithms it supports). With this information, your browser creates a symmetric key which it encrypts using the public key the server offered, then sends it to the server specifying the algorithm it chose (from among those the server said it can handle) to be used with the new key. Once done, both the client browser and the server have a shared, symmetric key with which they can exchange information (by encrypting and decrypting each other's communication).