So you want to know all about securing your communications on
the World Wide Web, eh? Well, make yourself comfortable and let grandpa tell
you a story..
Back when the Internet was young and web access was only within the
reach of educational institutions, the military and well-off early adopters,
people didn't worry all that much about the information they sent over the
interconnecting networks that composed the World Wide Web. This attitude
was somewhat akin to how people didn't lock their doors or have car alarms and
such back in the nostalgic "good old days". As became the case with homes and
automobiles, keeping information safe from prying eyes and thieves on the
Internet is a huge concern today. As more and more people make the
transition to the "online" world, so to is there in increase in
unscrupulous individuals looking to be the digital equivalent of a
"Peeping Tom".
At a very basic level, information you send to a machine over the Internet
(a web site, for instance), or that is sent to you via the Internet goes
through a series of networks ("hops") en route to its final destination.
Picture it like a piece of postal mail - many people handle it, load it onto
trucks, airplanes, etc. At every "hop" your mail takes, there is a chance that
someone can steam open the envelope or hold it up to the light and take a look
inside. What makes matters worse is that unsecured Internet communications
are more like postcards than letters in envelopes; all your information is
presented clearly for any of the handlers to see. While this may not bother
most people in their daily web surfing (news sites, search engines, etc.),
this isn't an ideal way to send financial (via your bank or
broker's web site) or otherwise confidential information. Clearly, a more
secure way of concealing the messages on those billions of postcards
zipping across the network is needed.
The answer to the problem is encryption. The Secure Socket Layer (SSL) was
developed by Netscape to allow two machines encrypted, secured communications
despite the number of network "hops" between them. The Internet Engineering
Task Force (IETF) drafted a standard based on Netscape's SSL, the
lesser-known acronym TLS - Transport Layer Security, that is supported by
just about every major web browser, web server, and email client.
Simply put, this system allows data to be encrypted during the trip from your
web browser to the remote web server and vice-versa. What kinds of data, you
ask? Just about everything, from the name of the web page you're viewing
to your name, address, phone number, email address and other items you may
provide on a web form.
Now that we've established why we need SSL / TLS and a basic idea of what it
is, let's dig a bit deeper into how it works. It all begins with a request
from your web browser. Let's say you click on a link or type into the
address bar: "https://www.something.com/". Note the "s" in "https".
Normal, unsecured web communications have a protocol identifier of "http", an
acronym for HyperText Transfer Protocol. The trailing "s" tells your web
browser to try and initiate a secure communications channel when sending and
receiving data from the remote web site. Before we cover how your browser
and the remote server actually set up the secured communication ("handshake"),
we'll need to take a side-trip and look at public key encryption.
The most well-known form of encryption is symmetric-key encryption, commonly
used in substitution ciphers. The basic idea is that all parties involved
share a common key, used to both encrypt and decrypt messages.
Newspapers for years have carried a daily puzzle called the "CryptoQuip" which
presents you with a message encoded via a substitution cipher. Each letter in
the original message is represented by a (normally) different letter in the
encrypted version. Here's an example that I use in my random signature file
quotes, attributed to Kevin McCurley:
"When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl."
Looking at the second part of the message, "bayl bhgynjf jvyy unir cevinpl"
, we see the use of a substitution cipher. In this case, the letter "b"
has been substituted for the letter "o", "a" for "n" and so on. The message,
when decoded, reads:
"When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl."
"When cryptography is outlawed, only outlaws will have privacy."
When the two lines are laid out above in a mono-spaced font, it's quite easy to
see the "key" used for this message. The problem with symmetric-key encryption
is that once a key is compromised, the whole system falls apart. Since the
same key is used to encrypt and decrypt, false messages could be sent and any
further messages encrypted with this key are as good as read. Another issue
that arises from this is how to distribute a new key to the other parties
without it being compromised in transit.
Public-key encryption, or "PKE", uses a bit of mathematical theory to address
most of these shortcomings. In public-key encryption, you have a private key
that is kept secret and known only to you. If this key is leaked,
the whole encryption scheme becomes worthless. For others who want to send
encrypted messages to you, you have a public key. This key is not intended
to be a secret by design and can be distributed on websites, public key
servers, even published in the New York Times! Unlike symmetric-key encryption
discussed earlier, only your private key can be used to encrypt messages as
you or decrypt messages encrypted for you. Thanks to the underlying
mathematical theory, your private key cannot be derived from your public key,
making the whole system more secure. This system all boils down to the
difficulty involved in factoring large numbers into products of primes; more on
this at the end of this document for those who are interested.
Now that we know the basics of PKE, let's take a look at the initial handshake
that sets up the SSL session. Your browser will connect to the server
on the SSL port (tcp/443) and send some basic, non-confidential
information to the server, such as which cryptographic methods the client
supports, SSL version, etc. The server will then respond with its list
of supported ciphers, SSL version and other necessary information. Included
is a copy of the server's certificate and public key. The certificate is then
validated by the client (more on that later). If the client is satisfied, it
will generate a secret key to be used during the secured session,
encrypt it using the server's public key, then send it to the server.
The server will then send a final message back to the client, encrypted with
the client's generated secret key, to indicate the handshake has been
completed. From this point on, all communications for the session will be
encrypted using the new "shared" secret key. As a user, your indication that
the connection is encrypted usually comes in the form of a locked padlock icon
in your web browser's status bar. Note that this key is only
used for this session; new sessions will require re-negotiation and in all
likelihood, a new shared key.
By now, if your eyes haven't glazed over and you're still reading this,
you may be wondering if encryption is the only benefit of using SSL / TLS on
a web site. Well, hold on to your hat because it's not! All sensitive
communications on the Internet always boil down to a matter of trust.
If I can't trust your web server to use and guard my data properly, who cares
if the connection is encrypted? My information, while safe in transit, may
still be at risk if you're not the person(s) for whom it was intended. In
other words, just because your site looks and feels like Walmart.com, how can
I be sure it's not some clever trick by some miscreant bent on grabbing my
credit card number? Here's where that "server certificate", mentioned briefly
during the SSL handshake discussion earlier, comes in to play.
SSL certificates contain information about the individual or
organization that uses them. Certificates provide the individual or
organization's name, location, email address, server name and the dates during
which the certificate is valid. This is all well and good until you realize
that it would be trivial for someone to make up a certificate that says they
are "Walmart.com", regardless of their true identity. To overcome this,
Certificate Authorities (CA) were
created. A Certificate Authority is an organization that is trusted to
vouch for whether a person is who they say they are, somewhat like a Notary
Public in the offline world. In order to certify a certificate, the CA will
investigate the identity of the requester and, if satisfied, "sign" the SSL
certificate. When the server presents this signed certificate
to the client during the SSL handshake, the client will attempt to verify
the signature against a list of "known good" signers. Web browsers normally
ship with lists of CAs that they will implicitly trust to identify hosts.
If the authority is not on the list, like some sites that sign their own
certificates, the browser will alert the user that the certificate is not
signed by a recognized authority and ask the user if they wish to continue
communications with the unverified site. Users can add custom certificate
authorities to the browser's list of trusted signers, thus solving the problem
of being prompted
every time you visit the same self-signed site. If the today's date falls
within the certificate's valid time range, the host name matches and
the certificate was signed by a trusted authority, you can be reasonably
certain that you are communicating with the site you intended to. As a
final precaution, you can always verify the information for yourself by
clicking the little "lock" icon in your browser window and looking through the
certificate details.
No discussion on SSL / TLS would be complete without a paragraph
on encryption strength. If you recall our mini-discussion on public-key
encryption (you were paying attention, weren't you?), we talked about
public and private keys and that the whole system was based on the difficulty
of uncovering the private key used to encrypt and decrypt messages. What we
managed to gloss over is how the size of that key impacts the ideal amount of
time required to break the encryption. Yes, I said "break the encryption";
it is possible! Public-key encryption strength is expressed in terms of
"bits", as in the common standard of "128-bit encryption". What this means is
that the key used contains 128 bits, each "bit" being either a "1" or a "0".
Ignoring the possibility of a lucky guess, a brute-force method of uncovering
a 128-bit key would require testing a worst case of 2128
combinations of ones and zeroes. I say worst case because you would only need
to try every combination if the one used was the last possible combination.
To get an idea of the sheer size of this number, imagine the number three
followed by thirty-eight zeroes! Definitely not for the faint of heart!
Even if you had a modern 4GHz machine capable of trying one combination per
cycle dedicated to the task of cracking a key of this strength, it would take
you roughly 2.6x1021 years (2.6 sextillion!) to try every
combination. However, if you take the bare minimum encryption level supported
by most browsers (excepting no encryption), 40-bit or 240
combinations, the same machine could try every key within a matter of minutes.
Of course, these theoretical numbers do not take into account the normal
overhead of running an operating system and other user processes that would
reduce the amount of cycles dedicated to cracking the key. What they do show
is the tremendous difference in effort between the 128-bit and 40-bit
strengths. Therefore, to obtain the best
encryption supported by most browsers and servers, you'd definitely want the
sites you visit securely (and your browser) to support 128-bit encryption.
So there you have it. Never again will you feel the need to sulk
away in shame when those "techies" start talking about SSL and encryption at
wild parties (ha!). I've tried to keep this as simple and light on the
techno-babble as possible, even going so far as to gloss over the finer points
of encryption schemes and using RSA as the only model. Those of you still
yearning for more technical or in-depth information might want to consult the
resources
listed below. As a final note, I didn't bother to touch on the paranoia some
folks have over the fabled ability of the
CIA/FBI/NSA/Insert-Three-Letter-Acronym-Here to break any strength encryption
faster than Mr. Coffee™ can brew a a fresh pot. Believe what you will,
tinfoil hat or not, SSL / TLS helps to keep your stuff safe from prying eyes.
Well, at least in transit...
Resources:
|
|
