SRT210 Lab 7

PART 1: ENCRYPTION FOR NETWORK SERVICES

We've seen in several labs how open to attack unencrypted traffic is. In this lab we'll look at what's involved in securing communications using encryption.

Crypto by Steven Levy is my favourite introductory book to cryptography. It's not required reading for this course, but I strongly recommend that all of you read it at some point (perhaps over the summer). The Toronto Public Library has some copies of it.

Symmetric vs Asymmetric (Public Key) encryption

Symmetric encryption is much faster than assymmetric encryption, but it has the key exchange problem which makes it unusable on its own. Therefore public key encryption is used to do the initial handshake and exchange of symmetric keys, which are then used to encrypt the communication efficiently. The internet could not function at its current scale without public key encryption.

For public key cryptography to work efficiently it requires a central storage of public keys, and strangers are expected to trust the certificates listed in that cetral storage location. That central storage is called a Certificate Authority, or CA.

Since we don't want to pay a yearly fee for every certificate we create in this course, we're going to set up our own certificate authority. The only catch is that noone will trust that CA except ourselves.

Setting up a Certificate Authority (CA)

We'll do it graphically, using an application called TinyCA. It's available in the EPEL repositories for CentOS 7.

The questions you need to answer to create a CA are a little strange, but don't worry - practically noone pays attention to them. All that matters is that the correct keys are in the correct places. Everything else is just a distraction.

Set up your own CA like this, using your own name where appropriate:

Note that the country name is CA which is short for Canada, not Certificate Authority.

Obtaining a Certificate

In the real world the process for obtaining a certificate looks like this:

1. You: Create a certificate request (often abbreviated as CSR). You don't need to do it on the server that requires the certificate. Typically this is done on a commandline with the openssl command.
2. You: Send the certificate request and your payment to a good CA. There are various factors that affect what makes it "good", most commonly people care about how well it's trusted, and how much it costs.
3. CA: Receives your request and payment, creates a set of keys, and signs your certificate with their own private key (the certificate is your public key). The CA then sends you the files it generated for you.
4. You: Configure your server to use the private and public keys you got from the CA. This looks different for every type of server.
5. Clients: When someone connects to your server using a secure mechanism, they first ask your server for a copy of your certificate (public key). Then they verify that a CA they trust signed that certificate and it's not expired. Following that they can encrypt messages they send to your server using the public key it gave them.

In our case each of you will be all three of the above: You, the CA, and the clients. That will allow us to do all this stuff in one lab.

Lab completion

• Make sure you understand what you've done in this lab, so that you're ready to answer questions about it.
• Have notes in your labbook from this lab.
• Show your work to the professor and have them sign your labbook.