|
To explain, let’s first quickly review what SSL technology gives an organization in terms of benefits. These benefits are trust and privacy.
Trust is provided through the use of a CA (Certificate Authority), such as VeriSign or Thawte. By having your SSL certificate signed by a CA, no one else can use your domain name with SSL without showing some sort of error.
Privacy is provided through encryption, which scrambles traffic so that it is incomprehensible to a potential eaves dropper. With regular HTTP, information such as usernames, passwords, credit card information are all sent over the Internet in plain-text. Someone could potentially “sniff” this traffic, which is the electronic equivalent of eaves dropping on a conversation. What’s more, this process can be automated so that it can be done unattended. A program automatically sniffs the network, and pulls out parts that are programmed to be interesting, such as passwords and credit card numbers. So encryption is one of the most powerful tools utilized in e-commerce.
SSL in practice
The ability to provide trust and privacy allows an organization to protect sensitive information. Currently, SSL is used primarily to protect just a few types of sensitive information. These include:
* Passwords (during login)
* Credit card transactions - which is a PCI (Payment Card Industry) compliance requirement
Most of what SSL is used for can be classified in one of those two ways. But is that the only type of sensitive data that could benefit from SSL? Consider the following:
* Memos on corporate strategy (web mail)
* Confidential sales information (CRM)
* Trade secrets (Web portal)
* Session identifiers (in the HTTP cookie)
With the exception of VPN technology that may or may not be in place, most of this information isn’t typically protected in most enterprises. It’s all done with regular non-SSL HTTP.
And then think for a moment, what isn’t data could you send over the Internet that isn’t sensitive? That is, what data would you not care about if it fell into the hands of competitors or the public.
It could even be that most of your data is non-sensitive, but some of it will invariably be, so how are you to know what is and what isn’t? So why not protect it all?
Session Protection
There’s another type of data that your users might want protected, although most don’t know about it. This type of data is called a “session cookie”. When the web protocol was developed, it was initially “stateless”, in that each request was independent of each other. As the web moved from static web pages to interactive web applications, there needed to be a way to create a relationship between the user and the server, where the web application would customize responses specifically to that user. This was done through assigning the user a session ID, typically in the form of an HTTP cookie.
When a user logs into a web application, they’re assigned a session ID, typically a long random string of letters and numbers. The user then sends this session ID to the server every time it makes a request. The server is then able to dynamically create content (such as a custom portal page, private email account, etc.) for that user.
A problem occurs if an attacker were to get hold of this session ID value. They could then hijack a user’s session, pretending to be that user without any login challenge from the server.
If only the initial login and perhaps credit card transactions are done with SSL, that means this session ID value is sent repeatedly over the network “in the clear” (without encryption). This makes it relatively easy to eavesdrop this particular data, because there’s no privacy.
So what’s the catch?
So, given the benefits of SSL and the nature of much of the data being transferred, why isn’t SSL used as the default? To answer this question, we need to look at the history of SSL and how usage developed.
When it was first created, the primary drawback to SSL was that it required more horsepower in terms of the server’s resources. Encrypting and decrypting is a CPU-intensive operation. What’s more, general purpose CPUs (such as x86 processors) are not optimized for this task. This is still true today, even for modern CPUs.
|
