October 28, 2017

SSL, Keys, Encryption: know just enough to make it work

Original post from July 2013

I've been using the web for a while, but I've never really understood how encryption works. And after all these years, I don't really care. I don't want to know how it works - I just want to know little enough to get things to work. This is really just a note to myself, that I can read whenever I need to deal with encryption. Because every few years I have to figure it out all over again just to get something to work.
NOTE: this is not meant to be 100% technically correct. I'm going to confuse some terms, and mix some stuff up. But its OK, because I don't care. I just want it to be sufficiently correct so that I can get the thing to work next time.

I have used (or only realised I was using) encryption in these three main cases:
1 HTTPS sites
2 SSH keys
3 SIP over TLS

The most important part of how SSL ensures that the traffic is safe is by authentication. By authenticating that the server is valid, it can use that fact to encrypt the traffic between the two.

Small excerpt:
Authentication and encryption are two intertwined technologies that help to insure that your data remains secure. Authentication is the process of insuring that both ends of the connection are in fact who they say they are. This applies not only to the entity trying to access a service (such as an end user) but to the entity providing the service, as well (such as a file server or Web site). Encryption helps to insure that the information within a session is not compromised. This includes not only reading the information within a data stream, but altering it, as well.
While authentication and encryption each has its own responsibilities in securing a communication session, maximum protection can only be achieved when the two are combined. For this reason, many security protocols contain both authentication and encryption specifications.

These are few terms that we need to introduce first (again, not 100% correct, its just my version)

  • SSL/TLS: I will be using these interchangeably. SSL is the predecessor of TLS. Both are used in browsers today. SSL and TLS run on top of TCP, and ensure the safety of the traffic.
  • Key: this is the signature of something. Used to verify its identity. For this discussion, we are talking about asymmetric keys, which consists of the public and private keys.
  • Public Key: Used for verifying signatures and encryption The public key of a site is distributed publicly. Clients use this to verify who the server is.
  • Private Key: Used for signing and decrypting Private keys are never distributed, and are guarded very seriously.
  • PKI: This involves CAs, and how clients can verify certificates
  • Public Key Cryptography: Messages encrypted with the public key can only be decrypted with the associated private key. Conversely, messages signed with the private key and be verified with the public key.
  • RSA, DSA: a Key Exchange Algorithm
  • X.509: the standard for certificates.
  • Certificates contain public keys, and are signed by a CA.

SSL runs on top of TCP. This is how the protocol messages look like:

Ok, now lets see how these things come together in the different use cases:

HTTPS - Browser

Basically, the browser (client) sends a request to a website (server). The website responds with its certificate, which contains its public key. The browser can now verify that the website is really the server, and not someone else: The client is certain that the identity of the server is authentic. They agree on a key to encrypt the data, which itself is encrypted with the servers public key.
There is an element of trust. The browser trusts the CAs. So if a site says its certificate was signed by a particular CA, then once the browser verifies that fact (by checking the sites certificate was signed by the CA), it now trusts that the website is who it says it is. And that really is how SSL ensures safety: that the bank website that you are visiting is in fact the bank, and not an imposter trying to steal your credentials.

To get a publicly/CA signed certificate for a new website you want to host, you can go to Thawte or Verisign, and paste your CSR on the order form. Your CSR is generated on the server you want the certificate for. It will also generate an associated private key.
Once the CA verifies that you own the domain, they will sign the CSR with their private key, and issue you the signed certificate. You can now import this into your web server.
You can also use self-signed certificates, but browsers won't be able to verify the servers authenticity.

Mutual authentication can be used as well: where the server asks for the browsers certificate. This can be used e.g. to verify the person for access to a private site.

SSH

I needed access to an SSH server at work. The admins don't allow the use of username/passwords - only SSH keys are allowed. I generated a key pair on my local box, and sent them the public key. The public was put in the allowed-keys on the SSH server. When I SSH into that box, my SSH agent presents the private key. Thus only I can gain access to that box, but only my private key can decrypt messages sent with the public key.

SIP TLS

TLS can be used to encrypt SIP messages. You can encounter SIP over TLS in two ways:

softphone to a SIP server: on your softphone, you can enable TLS, usually to a different port on the SIP server. The server will need a cert (self-signed will work) and private key. The softphone and server will then negotiate and encrypt the traffic.
SIP trunk: In this case, you are setting up a SIP over TLS trunk between two SIP servers (perhaps MS Lync and an SBC). In this case, mutual authentication is required. For this to work, Lync and SBC need a certificates. We did not use a public CA, so we used self-signed certs. Each device generates a CSR, which gets signed by a CA. Then each device loads the cert, and the root/domain cert. During TLS negotiation, they exchange certificates, and because they are both signed by the same root, they are now authenticated.

Here are some of the funnies I have come across:

There are different types of certificates. From Thawte, you can buy SS123, WebServer, or code signing certs.
Different formats of certificate files: .pem, .csr, p7b, pfx. Some are text based, and some are binary.
Certificates have different usages: Server, Client, signing, etc
you can use openssl to debug SSL issues. openSSL can act as a server or client, and can be used to negotiate and debug SSL
wireshark can be used to debug SSL issues. Capture some traffic, and use Decode As if it does not automatically see the SSL (if different ports are used)

One common misunderstanding I had was that to enable authentication between two parties, they both needed the same certificate. One needs a certificate, and the other needs the associated root/private certificate

I found these links very usefull: