by Steven J. Owens (unless otherwise attributed)
Somebody once asked me:
>How do "secure" websites work? How is the encryption carried out?
>Does it differ from browser to browser? I am interested because I
>recently started on-line banking.
Well, since I spent most of the last year consulting at a major national bank's web department, guess I'll take a crack at this one. The short answer first:
1) They use SSL servers and browsers that support SSL.
2) Using a public key encryption system that encrypts packets at the sockets layer (hence the acronym SSL, Secure Sockets Layer).
3) Not appreciably; if the browser supports SSL it doesn't care what brand of SSL server it's talking to.
Now the long answer... long and disjointed, but I'm tired and this is just something quick I'm dashing off. Those much more familiar with the technology are invited to kibbitz like crazy.
What "secure" means depends on who's using it - and when. There're a couple different means of secure transactions on the web, but the one most people refer to is "SSL", which stands for "Secure Sockets Layer" encryption. "Online banking" is vague; you might be referring to First Virtual Bank or Cybercash or somebody else, for all I know, and they use entirely other systems than SSL (though cybercash now offers credit card processing that uses SSL to protect the transaction). So for now I'll assume you're talking about SSL.
Netscape came up with SSL (don't know, offhand, whether they invented it or bought it - the one time I talked to a Netscape engineer about it, he seemed pretty clueless, but then again...). They published the standard and other browsers and servers have licensed it, although the Netscape Commerce Server still pretty much dominates the market, last time I checked. (Since this writing Netscape's buyout and breakup took place and now the Netscape webserver is the Sun IPlanet server, and there are now a lot more players in the SSL arena).
What SSL is, is a "zero knowledge transfer" encryption system that works based on some highly advanced mathematics, also used in public key encryption strategies. I'm not even going to begin to describe what Public Key Encryption is. Hm. Well, okay, I'll describe it a little bit.
Traditional encryption has this major problem, in that it works by having a "secret" key that is used to both encode and decode the information being sent. This means that unless you have some prior, secure method of transmitting the key to the destination, you can't have a secure communication. On a massive, public, random network like the Internet, this just doesn't cut it.
Public key encryption is mostly greek to me (well, okay, and some latin), but the essentials are that by some really odd math, instead of having one key for encoding and for decoding, you have two keys, one for encoding, one for decoding. Having the encoding key doesn't help you decode at all. So you can publish your encoding key to the whole world, and then people anywhere can just encode and send to you, and only you can decode.
There's a related issue of identifying people. How do you know a message comes from the people it says it comes from? Well, you could encode a special password with their public key, send it to them, and ask them to decode it and then reencode it, with your public key, and send it back to you. A bit awkward, but it makes sense. There's a shortcut, however, that I'm not even gonna begin to explain, which lets them do the same thing only without trading a bunch of messages beforehand.
In the example above, you still don't know for sure that it came from the name it says it came from, but you know it came from the holder of the secret key corresponding with the public key it says it came from. This is why SSL servers have a "digital certificate". They purchase these from a bonded company (e.g. VeriSign, one of the earliest and so far the biggest player in this market), and that company maintains servers. When you connect to a web site and the site sends your browser a public key, preparatory to doing SSL, your browser checks with a VeriSign server to see if the digital certificate you were sent really belongs to the bank. More or less. I'm glossing over a lot of details.
For more info on all sorts of public/private key encryption issues, check out the Pretty Good Privacy page at:
http://www.arc.unm.edu/~drosoff/pgp/pgp.htmly
Now, SSL uses this kind of encryption (Public Key Encryption, not PGP) at the "sockets layer", meaning that it encrypts the packets of data being sent from your browser to the server and the server to the browser. As you might imagine, this is a bit more resource-intensive than your average web page (an SSL request burns about twice as much CPU as a regular web page request), so most web sites that offer SSL use a separate server program and process, and only put the ABSOLUTELY NECESSARY pages under SSL.
You'll notice this because the URL for those pages is httpS://blah.blah.blah, note the S on the end of http (I only capitalized it to make it easier to see). Also, the mainstream browsers that support SSL (Netscape, MSIE, anybody who's added support since I looked last) usually have something very visual that lets you know if encryption is on or not:
Netscape uses a little gold key in the lower-left corner, that's broken into two parts most of the time, solid when you're using SSL. It also adds a blue line across the top of the browser window when SSL is in force.
I remember MSIE used a lock that was unlocked most of the time and locked when you use SSL, but I don't remember if it has the blue line or not. Then again, I try to avoid MSIE as much as possible.
When I last talked to the folks down at the bank (note: this is a couple years out of date, many banks are now offering online transaction support to some degree or another), most of the banks online weren't supporting actual transactions online, although one or two had ventured into that area. Most of the banks were just using it for customer support, and most of them weren't even letting you do things like check your balance, see if checks cleared, etc. Banks tend to be funny about security :-).
All of the banks that are using SSL-protected web pages for transactions of any sort are requiring "strong" SSL, which means a 128-bit key. The default vanilla SSL is a 40-bit key. Key sizes work kind of funny - you might think that a 128-bit key is 88 bits better than a 40-bit key, but it's actually a lot more. A digital key is like a combination lock, except that the dial only has two numbers on it - 0 and 1. So if you have a one-digit combination, you'd only have two possible combinations - 0 or 1. If you had a two-digit combination, you'd have four possible combinations - 00, 10, 01, 11. If you had a three digit combination, you'd have eight possible combinations, and so forth. So for each of those 88 extra bits in the 128-bit key, you've doubled the number of possible combinations.
A few were starting to work with Quicken or Microsoft Managing Your Money, selling services bundled to work with the software and including a dialup in the package. A dialup is much easier for a bank to deal with, since its traditional network guys find it much easier to cope with securing a direct dialup than with securing an Internet transaction. If this is what you have, then they're almost certainly using whole different sorts of security than what I described above, though they may well be using SSL in addition to other measures.