Open SSL: Still the best option for secure internet communication

Our goal is to transfer information securely between a known client (Alice) and a service (Bob) such that Bob and Alice can be certain that only they are privy to the information being exchanged. Once the information is in their hands, they trust each other not to pass it on to anyone else. A spy (Charles) cannot masquerade as either Alice or Bob and he cannot evesdrop on what Alice and Bob are saying to one another.

How SSL works

OpenSSL remains the best option for Alice and Bob. It is used throughout the Internet to access servers and all manner of critical information. The recent issues with the heartbleed only serve to underline why Open Source is the most effective route to secure transactions: The problem was identified and rapidly addressed across the world. If OpenSSL had been closed source, this vulnerability might have languished until it was extensively exploited. As it is, the only known exploits followed on the heels of the public discovery of, and solution to, the problem and thus have only affected those servers whose administrators did not quickly address the problem.

To understand how OpenSSL works, consider the following analogy:

  1. Alice sends a courier to Bob’s address.
  2. Bob has envelopes that, when closed, can only be opened by Bob. Bob and the courier go together to a trusted third party — a notary — which makes Bob provide documentation to prove its identity. The notary certifies Bob’s identity and his secure envelopes and the courier takes these envelopes back to Alice.
  3. Alice gets the envelopes and, if she trusts the notary’s reputation, she can be sure that they are actually Bob's envelopes.
  4. Alice also has secure envelopes that, once sealed, only Alice can open. She puts some of these in one of Bob’s secure envelopes, seals it and sends it back to Bob.
  5. Bob gets the sealed secure envelope. He opens the envelope (as only he can). He now has Alice’s secure envelopes.
  6. Bob has another kind of envelope that can be opened and sealed only by using a special combination. Bob puts this special combination-envelope, together with the appropriate combination, into one of Alice’s secure envelopes. Bob seals the envelope.
  7. Bob has another type of secure envelope that anyone can open, but which only Bob can seal. If you open one of these sealed envelopes, you know for sure that it was sent by Bob. Bob seals the whole package inside this and sends it to Alice.
  8. When Alice gets the secure envelope, she opens it and thus knows that it came from Bob. She then opens the next secure envelope inside that can only be opened by Alice. Inside, Alice finds the combination-envelope and the combination itself.
  9. Alice puts her data in the combination envelope, seals it and sends it to Bob.
  10. Bob receives it, opens it, and puts the response in the same secure envelope and sends it back.
  11. The procedure is repeated as often as necessary for required communications.

SSL relies on the concept of “public key cryptography” to accomplish these same tasks. In normal “symmetric” encryption, the two parties communicating share a “password” and that password is used to both encrypt and decrypt messages. While this is fast and efficient, how do you communicate the shared passwords to people you have not yet met in a way that is itself secure?

In “public key cryptography”, each person has two keys — a “public” key and a “private” key. Anything encrypted with the person’s public key can only be decrypted with the private key and vice versa. Each person then tells the world what his public key is and keeps his private key safe, secure, and, well, private.

If Alice sends Bob a message encrypted with Bob’s public key, then only Bob can open it, as only he has his private key. This is like an envelope that anyone can seal but which only Bob can open.

If Alice sends Bob a message encrypted with Alice’s private key, then anyone can open it, as everyone has access to Alice’s public key. However, successfully opening the message proves that it was sent by Alice and no one else, as only Alice has access to her private key. This is like an envelope that only Alice can seal, but which anyone can open and thus prove that Alice sealed it.

How to use SSL

To make use of OpenSSL to transfer files directly to services, you need to first generate a key pair. You will never need to divulge your private key - it is important that you keep this secure and do not reveal it to anyone. If using Linux (best) or a Mac (OK) then the following instructions will create (or locate) your key pair. For less secure client systems using Microsoft Windows, there are various utilities available which google will quickly find.

Step 1: Check for SSH keys

First, we need to check for existing SSH keys on your computer. Open up your Terminal and type:

cd ~/.ssh
ls -al
# Lists the files in your .ssh directory

Check the directory listing to see if you have files named either id_rsa.pub or id_dsa.pub. If you don't have either of those files go to step 2. Otherwise, you can skip to step 3.

Step 2: Generate a new SSH key

To generate a new SSH key, copy and paste the text below, making sure to substitute in your email. The default settings are preferred so, when you're asked to "enter a file in which to save the key", just press enter to continue.

ssh-keygen -t rsa -C "your_email@example.com"
# Creates a new ssh key, using the provided email as a label
# Generating public/private rsa key pair.
# Enter file in which to save the key (/home/you/.ssh/id_rsa):

Next, you'll be asked to enter a passphrase.

Tip: We strongly recommend a very good, secure passphrase. For more information, see Working with SSH key passphrases.

# Enter passphrase (empty for no passphrase): [Type a passphrase]
# Enter same passphrase again: [Type passphrase again]

Which should give you something like this:

# Your identification has been saved in /home/you/.ssh/id_rsa.
# Your public key has been saved in /home/you/.ssh/id_rsa.pub.
# The key fingerprint is:
# 01:0f:f4:3b:ca:85:d6:17:a1:7d:f0:68:9d:f0:a2:db your_email@example.com

Then add your new key to the ssh-agent:

ssh-add ~/.ssh/id_rsa

Step 3: Add it to the service

Supply your system administrator with the id_rsa.pub file and your username on your local system if they don't already know it (using the same username on the service will avoid you ever needing to type in your username explicitly).

id_rsa.pub is your public key so you can email it to them safely. Remember, you never need to supply your private key to anybody for any reason.

Step 4: Copy files and use ssh

Once your administrator has set up your account with your public key, you can use the rsync command to efficiently copy files to the service and ssh to login to the service in order to review the files and do other work (depending upon your privileges).

For example:

$ rsync my_datafile.csv example_server.com:
$ ssh example_server.com
...$ ls
my_datafile.csv
...$ logout
$

Use google or the man command to find more that you can do with ssh and rsync.

The above instructions are modifications of excellent existing instructions at luxsci.com and at GitHub.


Comments

There are currently no comments

New Comment

required

required (not published)

optional

Australia: 07 3103 2894

International: +61 410 545 357