tomclegg.net


Diary
Examples
Hire Tom
Mostly Mozart
Patches
School
    damnlies
    mendel
    notebookminus
  >secureserver<
    unixpackages
Scrapbook
Software
Telephones




colocation
comments
davidireland
edsgranola
faq
funsites
goodlooking
goodmovies
google-earth-saucy-amd64
houserules
liberating
resume
resume2
scratch
shopping
snacks
todo
university
warisbogus

What does "secure server" mean?

Is it safer to send your password and credit card number to a "secure server" than a regular web server?

What is different about secure servers?

A secure server responds to URLs starting with https, like https://example.com/.

When your web browser connects to the server, the first thing it does is verify that the server at the other end of the connection really is the example.com server. (The internet provides many opportunities for misdirecting connections, accidentally or otherwise.)

The server uses public key encryption in order to prove its identity. Every server has a matched pair of keys, one public and one private. A phrase, once encrypted with the public key, can only be decrypted by using the private key. Similarly, a phrase encrypted with the private key can be decrypted with the public key. Your browser uses the server's public key (which is available to everyone) to encrypt a message "M" and send it to the server. The server decrypts it and sends it back to your browser in order to prove that it knows the private key.

If "M" happens to be the public part of your browser's own pair of keys, then the browser and the server now know each other's public keys. From now on, they can encrypt everything they say, each knowing that there is only one computer in the world which will be able to decrypt it.

What if someone guesses the server's key? Anyone with spare time can get a server's public key, then try out all possible private keys until it finds the one which matches the public key. However, the time it takes to guess a key rises exponentially with the size of the key. If today's computers can guess 128-bit keys quickly, and computers get twice as fast with each passing year, it will be 900 years before computers can guess a 1024-bit key quickly. If you're worried about someone guessing your key, use a long one. Your computer can do 1024- and 2048-bit encryption. Most browsers and servers stick with 128-bit encryption. I guess the NSA can crack your keys. They probably already know your credit card number anyway.

How does the browser know the server's public key?

In the preceding explanation, the server's public key was "available to everyone." Exactly where does your browser find this critical piece of information?

Your browser has two ways of knowing what a server's key is supposed to be.

First, it asks the server what its key is. Along with the key, the server sends a version of its key which has been encrypted by BigCorp's private key. If your browser trusts BigCorp, and knows BigCorp's public key, then it can trust the server.

Popular browsers have built-in lists of companies (and their public keys) which should be trusted as "certificate authorities."

Your browser trusts that all certificate authorities are honest, and that they can always tell the difference between the real example.com and someone pretending to be example.com.

How does YourBrowserVendor decide whether an aspiring certificate authority should be added to the list?

If the server's key was not signed by any of the certificate authorities on your browser's list, then your browser asks you to verify the key yourself. "This key was not signed by anyone registered with YourBrowserVendor. Do you want me to go on, and assume that I am talking to the correct server?"

Internet Exploder (PC) tends to ask that question every time you visit the same web site, even though the server always uses the same key. This is mildly annoying. Internet Exploder (Mac) tends to ask that question every time you click a link. This is fatally annoying. Your browser should ask that question only once per server. When a server's key changes from one visit to the next, your browser should give you a different warning: "The server's key has changed. Either the server got a new key, or your connection has been intercepted by a different server. Do you want to continue?"

Security holes

Many servers sign their own keys. Browsers pop up unnecessary security warnings every time they visit these servers. Users become accustomed to clicking "yes" without reading the security warnings.

Certificate authorities' keys are extremely valuable. Anyone who manages to steal one is suddenly trusted to certify any web site.

Some recent versions of Internet Exploder had an interesting bug. Anyone whose key is signed by BigCorp was trusted too far -- not just to be who BigCorp says they are, but to sign keys for any other server! The example.com server was able to certify itself as ultrasecurebank.com, just because it had proved its real identity to BigCorp.

Certificate authorities can make money by signing keys. They can increase their profits by signing more certificates, and taking less trouble to verify the identity of each server before signing its key.

Browser vendors can make money by selling spots on the list of trusted certificate authorities. They can increase their profits by putting more keys on the list, and taking less trouble to verify that certificate authorities stay honest and keep their private keys safe.

The biggest security hole

You send your credit card number to a secure server. You verified the server's key yourself, so you are certain that nobody else saw your credit card number.

What happens next?

The secure server decodes your credit card number and stores it in a database. (This is common.) Somebody breaks into the server, avoiding the secure server software entirely, and downloads a database full of credit card numbers.

The secure server sends your credit card number to the site owner by email, then erases it so that nobody can break in and get it. (This is common.) The email message is intercepted or misdirected.

The secure server sends your credit card number to the site owner by email, after encrypting it with the site owner's public key. Only the site owner is able to decrypt it. (Most people don't take the trouble to do this.) Later, the site owner's computer gets a virus, which stumbles upon a file full of credit card numbers and broadcasts it to everyone in his Outhouse Express address book.

After all that, the yellow padlock in your browser window still assures you that the server is secure.

"Secure server" means "secure channel." The padlock assures you that nobody is eavesdropping. It implies nothing about whether your secrets will be difficult to steal after they arrive at the server.

Most secure web sites say nothing about how they protect your credit card number after it reaches the server. I wonder why?

Secure servers waste precious IP addresses.

There is a shortage of IP addresses. That's why most internet protocols allow multiple domain names to share a single IP address. Domain name (DNS), email (SMTP), and web (HTTP) protocols are all capable of sharing IP addresses. The original HTTP protocol did not have this feature; it was introduced in the 1990s. All modern browsers and servers support it.

A typical web server is responsible for several different web sites with different domain names. Normally, your browser connects to an HTTP server and asks for a web site by name. The server responds with a page from whichever web site was specified by the browser.

The HTTPS protocol requires the server to prove its identity before the browser tells it which web site you want to see. There is only one way for the server to figure out which public key to send: each web site has to have a distinct IP address. Result: one IP address is wasted for each "secure web site".

At first sight, this scheme appears to offer some benefits. Until the server can prove that it's really example.com, your browser doesn't even have to divulge which web site it expects to reach. For one thing, the very fact that you're trying to reach example.com might be a secret. Also, an impostor won't know which web site to impersonate.

These benefits do not actually exist, though. In order to connect to the server (or an impostor) in the first place, your browser has to send a packet to an IP address. That IP address can only be hosting one secure web site. Anyone can discover which web site that is, by connecting to it and asking for its public key. Therefore, just by initiating a connection, your browser has divulged (to all potential impostors and eavesdroppers) which secure server it is trying to contact. After that, why bother pretending it's a secret?

Nothing is gained. IP addresses are wasted.

A single computer can host a thousand web sites, using only two IP addresses.

A single computer can host a thousand secure web sites, but only by using up a thousand IP addresses.