Many web hosts provide the ability for clients to provide their customers with SSL (Secure Socket Layer) connections when signed into their websites or email. It’s important to understand how SSL works, and why so many websites use the protocol to protect user data.

Websites use SSL to encrypt and secure each user’s session while they’re logged in. Without it, it’s very possible for someone to monitor or hijack that session.

Websites such as Facebook or Twitter currently do not use SSL, and thus should not be used on a public network because a user’s session can be monitored.

You can immediately tell when a website session is secure by a lock icon in the bottom right hand corner of the browser, and the website address should have https://, the “s” meaning secure. If the address only starts with http://, the website is not secure.

When you login to a website that uses SSL, you can rest assured that no one can monitor your session while you are logged in.

When a user accesses an SSL-enabled website, it automatically asks the server for a digital Certificate of Authority (CA). The browser will verify the information on the certification with server’s identity and to ensure data will remain secure. If all goes as it should, this process should happen behind-the-scenes.

When the browser verifies the certificate, it uses the public key to encrypt a “key” that includes the user’s login information and sends it to the server.

The SSL server decrypts the “key” and uses a private key to decrypt the data, and sends back the requested information in an encrypted “key” to the web browser, which decrypts the data and displays the requested web page and data.

Make sure that you are using a modern web browser that takes advantage of SSL, and that your hosting provider offers SSL capability so you can rest assured that traffic between your computer and their web server will be secure. Also make sure that the information you are entrusting to your hosting provider for those SSL sessions will not be sold to third parties.

My apologies for the lapse in Security Corner Posts. The next one will continue the series on building an Information Management Plan for clients.

There has been a lot of talk the past couple of weeks about the recently-discovered session renegotiation vulnerability in SSL. If you are interested in the details, here is a link to a .pdf of the original research. Here is a link to another article discussing the vulnerability. Mr. Google can find many more for you. This week’s episode of Security Now! will be devoted to this subject as well.

What does this mean to us and to clients? What are the real risks? These questions are difficult to answer at this point, because not all of the details have been made public. Initial reports focused on SSL connections that employ client-side certificates, which would not include most connections. Ironically, client-side certificates are generally considered more secure. However, since the protocol allows for more session renegotiation when using client-side certs, the risk is increased. There are more recent reports of attacks that do not involve client-side certs.

All versions of this attack require a successful MITM (man-in-the-middle) attack to be established first. This means that WIFI connections, especially on a public network, do present a real risk. A wired connection to a home or office network presents little risk, as does a well-secured wireless connection.

There have been reports of attacks “in the wild”, and at least one successful attack against twitter.

All browsers and all web servers are affected, but there is already a patch available for OpenVPN that addresses the issue. it will be a while before there are patches for all browsers and web servers. I will keep tabs on this and post news as it develops. In the meantime, even SSL connections are not necessarily secure when in on a public network.

Here are some interesting stats from a webinar on cloud security that I attended today:

The average “hard cost” (not including the cost of lost business or damaged reputation) of a data breach is $202 PER RECORD. The “less tangible” costs, such as loss of business, are often much higher. Remember this when advising clients about data protection, which has a cost. The cost of not protecting data can be much higher.

65% of data losses are caused by someone with privileged access (employees, contractors, etc). This includes malicious acts and errors.

40% of losses are caused by a third-party service supplier or contractor.

We focus a lot of thought and energy on hackers and outside attacks, but these are certainly not the only threats.

Dennis H in West Virginia, US

November 20, 2009