In the dark ages people would sometimes communicate using a thing called “pen and paper”. You sat down at your desk and wrote your message to a friend. You placed your message in an envelope with address, affixed postage then sent it via the post. Your friend could then open the envelope and read your message.
Dear Jill, the treasure is hidden under the seat of Bob’s car.
As long as nobody opened the envelope, your message was secret and only Jill could find the treasure.
But you could do something a little cheaper then sending a letter in an envelope, you could instead send your message on a postcard. This was a small card that often had a picture on one side and space on the back for a short message plus addresses and postage. (My marketing person told me that people don’t know what a postcard is or how it is used. I’m such an old fuddy duddy.)
Now, every person that handles the postcard can read your message. That can be your local postman, who you trust, your local Postmaster, who you trust. But what about all the people in between? What about Jill’s spouse who brings in the mail?
Everybody that can see the postcard can read your message. Thus it isn’t secret.
Every message on the internet is written on a postcard!
Every single message sent on the internet is written on a postcard. Anybody that can see the message (packet) can see what is inside of it.
A few years ago, at a security conference, the presenter was showing off their new sniffing software. All it did was look for images. It then made a collage of the images. The presenter started sniffing the conference network as they started the presentation. Within moments the collage was being shown on the big screen behind the presenter.
Some of the images captured where company proprietary, some images were NSFW, some where government use only. All of it was captured by just looking at the messages flowing over the network.
If you don’t want people reading your postcards, you need SSL
This issue has existed for a very long time. Since ancient times the sender of a message has been working to hide the message from those that would intercept the message.
The most common methods are the use of codes, ciphers and concealment.
If you take nothing else away from this article, remember everything that is sent on the internet is sent on the equivalent of a postcard! SSL makes the message unintelligible.
Codes, Ciphers and Concealment
In order to make a message unintelligible, the message ether needs to be concealed, encrypted (enciphered) or encoded. All of these work in general, but for the Internet traffic, ciphers are the best option. SSL provides a method of using ciphers for your communications.
What are Codes?
A code replaces one concept (word or phrase) with another word or phrase. If I tell you that “cattle futures” means go pick up your son at the school and “weather front” means go pick up your daughter at dance class.
We have created a code. It is nearly impossible to figure out a code without access to the code book or intense observation.
And even if the bad guy figures out that “weather front” means “pick up your daughter at dance class”, they still don’t know what “cattle futures” means.
In order for a code to work, the sender and the receiver need a “code book” which allows the translation too and from english:
From the Western Union Telegraphic Code of 1901:
Please reserve at hotel three bedrooms, parlor, and bath; party consists of Mr. —–, wife, three children and servant; will arrive on the 23d. Want good accommodations at a reasonable figure.
Is encoded as:
Bodenloch, Jones, Estorsao, Elcoma.
Western Union Telegraphic Code
Unfortunately, codes just don’t work well for internet communications.
What are Ciphers?
A cipher is a method of “scrambling” letters. In the dark ages they had things called “news papers”. Often the news papers would have “comics” in them. Every once in a while the characters in a comic would discover a “secret” message of scrambled letters.
Wvyy, gur gernfher vf uvqqra va haqre gur bnx gerr.
With just a few minutes of time, this could be deciphered and the hidden message revealed.
In order to communicate via a cipher the sender and the receiver have to agree on an algorithm (cipher) and a “key” for that cipher. A key is a number or phrase similar to a password that configures the cipher to modify the input (plain) text into the output (cipher) text. Without the key it should be impossible to decipher the message.
The process of sharing keys, protecting keys, and destroying keys when they are no longer needed is all part of “key management.” Key management is the hardest part of private shared key (PSK) encryption.
Ciphers lend themselves to internet communications because everything can be considered a “character” or letter or number between 0 and 255.
The US originally released a civilian cipher called Data Encryption Standard (DES) in the 1970’s. It was later superseded by the Advanced Encryption Standard (AES) in 2001.
DES is hard to decipher without knowing the key. AES is very difficult to decipher without knowing the key. Very difficult is currently measured in thousands of years with unlimited resources. Hard is currently measured in days with limited resources. In other words, DES is no longer considered any more secure than rot-13 or Enigma.
What is Concealment?
If you can hide your message then the receiver just takes your hidden message and reads it. “Invisible ink” was a method of hiding messages. Lemon juice can be used as an invisible ink and you can cause it to be seen by applying gentle heat.
On the internet, messages can be hidden in longer documents or images.
For the internet, it doesn’t provide anything useful in the general case.
Key Management
Key management is the process of exchanging keys yet keeping them safe. In the military keys were distributed via secure means. I.e. some person carried them from one point to another. When a key was used, it was then destroyed so that the enemy could not “replay” the messages captured in real time with a key that was captured later.
The entire security of the communications depended on key security. Lose the key and your communications was on postcards once again.
In the civilian market, DES and AES still depend on key exchange. This means that if the key is known, the communications can be read.
Any cipher that requires that both parties know the keys in order to decipher the message are called “Private Shared Keys” or PSK.
Primary Cipher Types
There are two primary types of cipher which are named for the type of key management used. The first is Private Shared Key. The second is Public Key Encryption.
With PSK, two people exchange keys via some method. This could be a whispered conversation in an alley, it could be a telephone conversation, it could be by exchanging a piece of paper. In all cases that key could be intercepted, forgotten, mis-heard or mis-remembered. If that key falls into the hands of the bad guys, they will be able to decrypt any message encrypted with that key.
With PKI, each entity has two keys. A public key and a private key. Information that is encrypted with the public key can only be decrypted with the private key. It should be impossible to decrypt a message encrypted with the public key with just the public key.
Using PKI two people can exchange their public keys by publishing them in a newspaper or anywhere else without compromising security. The weakness of PKI is called “Man in the Middle”.
Public Key Encryption (PKI) (For the Geek)
In 1978 three researchers, Rivest, Shamir, Adleman (RSA), discovered that they could use a “hard” math problem to create a cipher where the key to encipher a message was different from the key to decipher a message and knowing one did not reveal the other.
The way it worked was that you could generate a pair of keys. One to encipher and one to decipher messages. You could then give the encryption key to the world, anybody could know it, and anybody could encipher a message with the encipher key but only the decipher key could be used to read the message.
This “solved” the key management issue. If two people wished to communicate they generated their keys, known as a “public key” and a “private key”. They share the public key with everybody in anyway they wish.
Then to send messages, they encrypt with the receivers public key and the decrypt with the receivers private key. Anybody that intercepts the message can not read the message.
There are two problems with PKI, the first is that it is resource expensive to encrypt messages with PKI (it is slow), and the second is that there is no simple way of knowing that the public key actually belongs to the intended recipient.
Man In the Middle
The primary weakness of PKI is an attack known as “Man in the Middle”. This is when the sender thinks they are sending a message to one person and instead it is sent to somebody else, the man in the middle. If the MIM can decrypt the message, they can then re-encrypt it using the actual receiver’s public key and nether the sender or receiver would know.
All it takes to do a MIM is to have the sender have the wrong public key for the receiver.
Consider the following situation: Bob wants to send a secret message to Jill. Charlie wants to intercept and read the message to Jill.
- Bob publishes his public key as: bob.pub
- Jill publishes her public key as: jill.pub
- Charlie publishes his public key as: Jill.pub
Bob goes to send his message to Jill and finds “Jill.pub”. He encrypts the message and sends it out. Charlie captures the message and decrypts it. Charlie then encrypts the message with “jill.pub” and sends it on. Jill receives the message, decrypts it with her private key and reads her secret message, never knowing that Charlie also read it.
Secure Socket Layer (SSL)
Everything we do with SSL is to solve the key management problem while stopping man in the middle attacks.
SSL solves the key management problem by using PKI to exchange a short message which contains nothing but the key to a PSK cipher such as the American Encryption Standard(AES).
When a browser connects to a server, the server tells the client “my public key is server.pub” The browser then generates a secret key for use with a PSK cipher and sends that key to the server encrypted with server.pub. The server decrypts the message with server.private, extracts the key and then both browser and server switch to using a faster PSK cipher.
This “solves” the key management problem but does nothing to solve the man in the middle attack.
The answer to man in the middle attacks goes back to PKI. As an interesting side effect, if you use the private key to encrypt a message the public key can be used to decrypt the message. Since only the owner of a private key has a copy of it, if you can decrypt a message with a public key, you can be pretty certain that the message was encrypted with the matching private key.
This allows a message to be “signed”. The message has a cryptographically secure hash computed. This “hash” is designed such that if any bit of the message is modified, the hash will be different. The hash is then encrypted with a private key. The encrypted version of the hash is then sent along with the original message. The receiver can then decrypt the hash using the senders public key, compute the same hash for the original message. If the computed hash matches the hash that was encrypted, the receiver knows that the sender has “signed” the message.
Once we have the ability to cryptographically sign a digital message we end up back where we started, how do we know the public key that signed can be trusted?
The answer in SSL is the “Certificate Authority” or CA. The CA generates their public and private keys just like anybody else, but then they publish their public key in a specific way, they communicate it in person to the creators of client software such as browsers.
Because the browser “trusts” the CA to verify the identy of any SSL certificate that is signed, the browser trusts servers that present public keys signed by a trusted CA.
Every browser has a list of known and trusted CA’s. You can see that list in Firefox by going to preferences->Privacy & Security->Certificate Manager where you can look at the list of “Authorities”. In Chrome it is Settings->Advanced->Privacy and security->Manage certificates->Authorities.
There are equivalents for IE, Safari and Opera web browsers. In addition any other software that uses SSL will have a list of trusted CAs.
Using SSL
When a server is going to uses SSL the owner starts by generating a Certificate Signing Request (CSR). The CSR contains identifying information about the server and owner of the server. The CSR is sent to a CA. The CA authenticates the request and then signs the CSR generating a SSL Certificate (CERT or CRT). The CA sends the s CRT back to the owner that installs it on their server.
When a client (browser) connects the servers sends their certificate to the client. The certificate contains the public key of the server as well as the signing information from the CA. The client looks up the CA in the list of known CAs. The client then decrypts the signature using the known public key of the CA which the client already had. It verifies the signature in the certificate. If everything verifies then the browser uses the server public key to start the key exchange.
For the geeks…
There is much more to this and the author knows this. We do not discuss certificate chains or a dozen other issues. The document is intended more as a non-technical introduction.
If you want to talk to an SSL pro and discuss security options for your website, get in touch with us and we will offer a FREE consultation.
