There is a pretty lively debate going on over at the Security Catalyst forums about SSL on login pages. This drove home the fact that people still don’t really understand what SSL does and doesn’t protect you against. Also there seems to be a big lack of knowledge about what you need to do in order to keep what limited protection SSL gives a website intact.
SSL is like using an armored truck to transport rolls of pennies between someone on a park bench and someone doing business from a cardboard box.
SSL is just transport security, if your endpoints are not secure SSL buys you nothing. That is zero, nada, zilch. What does transport security do for you? It protects your connection (and the data you send over it) from eavesdropping. This is a good thing, especially with more and more people using public wi-fi hotspots, but it is not the whole story.
Ways websites screw up SSL
Let’s step back a moment and take a look at how websites work. We will use an example site where people can browse around a store, place things in a cart and checkout. When they checkout they also create an account in the system so they can check order status etc. This is a pretty typical ecommerce setup.
We have to remember that HTTP is a stateless protocol. There is no way in the protocol to track a user has they go from one page to the next. There is no way to give access to a piece of information only to a certain user with HTTP only. This is not a problem if you are delivering static information but becomes a real issue if you are trying to build an application. Lou Montulli saw this flaw while working at Netscape in 1994 and created the cookie in 1994. There are alternatives to using cookies but they are used fairly rarely. Any one of these that is used still has the same issue I will describe below. All of these technologies, when used to track state in a website, are session tokens. For simplicity’s sake I will use cookies to cover any of these techniques for tracking state since it is the most common.
Where a lot of sites screw up is where they implement SSL. Many sites only dump you into SSL after you have done something that they deem worthy of protection. This might be logging in or starting a checkout process. However they assign you a cookie before they dump you into SSL. Why does this matter? Your cookie is you on the site. If someone gets your cookie they are you for as long as that cookie is active on the system. So if SSL is supposed to protect you as you surf the site it has to be used as soon as the cookie is given. If the site is not under SSL before or after the token is assigned, any protection from SSL is rendered worthless.
Notice I mentioned after the token is assigned as well. This is what happens if you only SSL protect the login but then dump a user into cleartext afterwards. The token is passed around in clear for everyone to see.
If you enjoyed this post, make sure you subscribe to my RSS feed!
