What's SSL all about?
While I understand a little of the inner workings of public/private key encryption and something about the methods for implementing SSL I have to admit I don't fully appreciate why it's used.
Ok, I know it encrypts everything that's transmitted between browser and server, but what are the dangers of not doing this? If you send it all in plain text it's open to sniffing by hackers. How though? Can anybody, anywhere in the world listen in on any unencrypted communication on the web? Surely they would need inside knowledge of IP addresses and/or access to private networks.
Also, what part does the SSL certificate provider play in all of this? I know they have to be trusted to be able to prove the parties they issue to are legit, but do they have to be trusted to? Do they have access to snoop the communications? Is the use of SSL certs in things like online shopping more about feeling safe in the knowledge you know who you're dealing with or is it more about knowing your card details are safe from prying eyes?
Lastly, before I stop talking about SLL, how slow does encryption make a site compared to using normal http://? I've read that it can be 30% slower.
Skip to the 
You can subscribe to an individual
In short, yes. It's very easy to snoop an IP connection if it's not encrypted.
Obvisously some connections are harder than others (USB ADSL against WiFI for instance), but they are easily hackable, in fact that's what network analysers do.
<Techy bit>
Ethernet essentially broadcasts every packet onto the local subnet. To pick up packets for anyone else, you just need to tell your adapter to operate in 'promiscous mode' and it will suck everything it sees up.
</Techy>
So, you are right in thinking that you need some sort of physical access, but with so many compromised PC's around these days - that's not so hard either. Also, remember that public WiFi points are easily accessible and from my experience of most hosting companies- it's not that hard to plug into a backbone switch either (though switches cause their own problems). And internal networks are just a doddle.
So, yes -- SSL for encyption as well as to verify you are talking to paypal, not someone else!
As for the performance increase, yes it can be that much, but it depends what you SSL and how much you can cache/serve up non-encrypted. I always suggest enforcing SSL seperalty from the server anyway, normally at a load balancing level. That way you can load balanace & SSL in hardware, which is way faster than in software.
The trust that browsers place in certain certifiers is more convenience than requirement. I can create a certificate authority / SSL cert with a tool like IBM's Keyman:
{Link}
Most browsers allow you to configure which certificate authorities you trust. Many companies will create their own authority and SSL certs for an Intranet and use desktop management software to configure local browsers to trust this authority. In fact, if you hit an Internet site that has an SSL cert that you do not trust implicitly, browsers like IE will prompt you to see if you want to trust the authority going forward.
As for performance, it is a big consideration, which is why many sites will have you post your login credentials to an SSL page, but all others are unencrypted. Then when you need to enter your credit card number, that page will go back to SSL. This does allow a sniffer to see what you are ordering from the site, but nothing important like CC numbers, or home addresses.
I don't know of any cases where credit card numbers have been sniffed by hackers tapping in to public networks. I had to implement SSL on my site mainly because users (reasonably) did not like the idea transmitting credit card details over the net and didn't like the warning message from the browser. IMHO, the chances of being picked up by a random network sniffer are so small as to be infinitesmal. As for the trust issue, an instant certificate with a trusted root accepted by nearly all browsers (IE & Firefox) takes about 10 mins to organise on-line and is done with no real checking of credentials.
The funny thing is, I'm pretty sure that implementing the certificate hasn't *actually* made my web sites significantly more trustworthy or secure. But they *appear* to be both to the customer, and that's the important thing.
"the chances of being picked up by a random network sniffer are so small as to be infinitesmal"
Depends where you go. I travel a lot. Especially to Japan. And So I have to use Internet Cafes and such. In Japan there are open WiFi points all over the place. However a lot have been discovered to be run by Yakuza related persons. Anybody can set up an open WiFi point. And all it needs is a packet logger on the gateway and cyber crime has just lifted a few more percent.
For people suitting comfortably at home, I agree the chance is small. However when you're out and about, I never trust whatever network I'm connected to. In Notes, switch on that Encrypt Network Data option in the preferences. Firewalls, Anti-Virus, Anti-Spyware to the max. And never do online banking.
Making people "appear" to be safer appears to be all the rage. Ever heard of Chip & Pin? It's not safer at all. It's even worse. But the Banks try their hardest to convince you it's better, because they're pushing the blame onto you the consumers. Same thing with SSL. It's perfectly safe to buy most things over the Internet with trusted websites. Even without SSL. It just makes people think they're safer.
Who do you trust?
I'll not weigh in on the security debate but talk about performance.
There is a significant overhead in network IO to create a secure socket. Creating IP connections is generally an expensive process, further exacerbated by SSL, then magnified by HTTP (because it's connectionless).
Before any data is sent to the web server, an IP connection is created and the SSL handshake begins. The handshake is the exchange of RSA keys and verification that the keys are valid and trusted. Once the handshake succeeds, the http data is encrypted and sent over the IP connection. There is also some number-crunching (CPU) overhead occurring on the client and server side as the data is encrypted and decrypted with the public and private keys.
The HTTP protocol magnifies the poor performance because browsers are repeatedly creating and closing IP connections, so multiple handshakes and socket creations are usually required.
I'm sure someone will correct me if I'm wrong but I believe that only the initial SSL interaction between server and client is conducted using public and private keys. During this interaction a 'one-time' key is created and shared between the server and client and then all remaining transations are carried out with the one-time key. The reason for this is that one-time key encryption is quicker to encode and decode than public-private key encryption.
Sorry, it doesn't help on the performance issues of SSL but thought you might be interested.
There's a fantastic podcast called "Security Now." They've recently done a number of casts on WiFi security, SSL and VPN.
Sometimes a little techy but it explains the SSL stuff really really well.
Even if you don't use podcasts, you can download the audio files here: {Link} (Episode #15).
Cheers,
Carl