Using
Secure Sockets Layer (SSL) With E-mail
By: Frank
Betsa, YSU Help Desk
The Secure Sockets Layer (SSL) is a commonly used
protocol for managing the security of a message transmission on the Internet.
SSL has recently been succeeded by Transport Layer Security (TLS), which is
based on SSL. SSL uses a program layer located between the Internet's Hypertext
Transfer Protocol (HTTP) and Transport Control Protocol (TCP) layers. SSL is
included as part of both the Microsoft and Netscape browsers and most Web server
products. Developed by Netscape, SSL also gained the support of Microsoft and
other Internet client/server developers as well and became the standard until
evolving into Transport Layer Security. The "sockets" part of the
term refers to the sockets method of passing data back and forth between a
client and a server program in a network or between program layers in the same
computer. SSL uses the public-and-private key encryption system from RSA, which
also includes the use of a digital certificate.
WHAT IS KEY CRYPTOGRAPHY?
RSA
public key cryptography is widely used for authentication and encryption in the
computer industry. Netscape has licensed RSA public key cryptography from RSA Data Security Inc. for use in its
products, specifically for authentication.
The easiest way to think of Key Encryption is to compare it to renting a
safety deposit box at your local bank. The renter of the box has a key and the
owner also has a key. Both keys are required to gain access into the box. The
same holds true for e-mail that is encrypted. Both parties must have matching
“keys” to read the message. However, the owner must issue the key to the
recipient. Keeping in mind that each pair of keys consists of a public key and
a private key. The public key is made public by distributing it widely. The
private key is never distributed; it is always kept secret. Data that is encrypted with the public key
can be decrypted only with the private key. Conversely, data encrypted with the
private key can be decrypted only with the public key. This asymmetry is the
property that makes public key cryptography so useful.
BUT WAIT, THERE'S MORE!
Unless you know exactly what you are encrypting, it is never a good idea to
encrypt something with your private key and then send it to somebody else.
This is because the encrypted value can be used against you (remember, only you
could have done the encryption because only you have the private key). So,
instead of encrypting the original message sent by Alice, Bob constructs a
message digest and encrypts that. A message digest is derived from the random
message in a way that has the following useful properties:
·
The
digest is difficult to reverse. Someone trying to impersonate Bob couldn't get
the original message back from the digest.
·
An
impersonator would have a hard time finding a different message that computed
to the same digest value.
By using a digest, Bob can protect himself. He computes the
digest of the random message sent by Alice and then encrypts the result. He
sends the encrypted digest back to Alice. Alice can compute the same digest and
authenticate Bob by decrypting Bob's message and comparing values.
GETTING CLOSER
The technique just described is
known as a digital signature. Bob has signed a message generated by Alice, and
in doing so he has taken a step that is just about as dangerous as encrypting a
random value. Consequently, our authentication protocol needs one more twist:
some (or all) of the data needs to be originated by Bob. When he uses this protocol, Bob knows what
message he is sending to Alice, and he doesn't mind signing it.
HANDING OUT PUBLIC KEYS
How does Bob hand out his public key
in a trustworthy way? With this protocol, anybody can be Bob. All you need is a
public and private key. You lie to Alice and say you are Bob, and then you
provide your public key instead of Bob's. Then you prove it by encrypting
something with the private key you have, and Alice can't tell you're not Bob.
To solve this problem, the standards community has invented an object called a
certificate. A certificate has the following content:
·
The
certificate issuer's name
·
The
entity for whom the certificate is being issued (aka the subject)
·
The
public key of the subject
·
Some
time stamps
The certificate is signed using the certificate issuer's private key. Everybody knows the certificate issuer's public key (that is, the certificate issuer has a certificate, and so on...). Certificates are a standard way of binding a public key to a name. By using this certificate technology, everybody can examine Bob's certificate to see whether it's been forged. Assuming that Bob keeps tight control of his private key and that it really is Bob who gets the certificate, then all is well.
Now when Alice receives Bob's first
message, she can examine the certificate, check the signature (as above, using
a digest and public key decryption), and then check the subject (that is, Bob's
name) and see that it is indeed Bob. She can then trust that the public key is
Bob's public key and request Bob to prove his identity. Bob goes through the
same process as before, making a message digest of his design and then
responding to Alice with a signed version of it. Alice can verify Bob's message
digest by using the public key taken from the certificate and checking the
result.
A bad guy - let's call him Dave -
can send e-mail to Alice using Bob’s certificate. But he can't satisfy Alice in
the final message. Because he doesn't have Bob's private key, so he can't construct
a message that Alice will believe came from Bob.
EXCHANGING A SECRET
Once Alice has authenticated Bob,
she can do another thing - she can send Bob a message that only Bob can decode.
The only way to find the secret is by decrypting the above message with Bob's
private key. Exchanging a secret is another powerful way of using public key
cryptography. Even if the communication between Alice and Bob is being
observed, nobody but Bob can get the secret.
THE BOTTOM LINE
There is a lot to e-mail security
and encryption. Users can get themselves into a lot of trouble “playing” with
these types of settings in their e-mail client (Outlook, Netscape, Eudora…). If
you are concerned that your e-mail is being tampered with or intercepted by an
unknown entity, your first response should be to contact your e-mail
administrator for further investigation. If needed, they can assist you in
setting your security properties. Always remember, the simplest forms of
security are good passwords, keeping your password a secret, and knowledge of
your e-mail recipients.
References:
http://home.netscape.com/computing/techsearch