How To Avoid SSL Usage Mistakes

Freelance Technical Writer

Initially, many people who start out with SSL do not have a full understanding of how it actually works. They have this idea that the encrypted page is being protected throughout its lifespan – being the creation, then browser transmission, onto user usage and often a form with sensitive user information going back to the server. It is assumed that this process is safe, when in reality, it is not. So how do we make it safe?

Article Writing

Login Forms

The most common mistake made when trying to secure login forms is to serve the login form from a secure https address, and then post the sensitive data back to the server via a standard http address. Lifetime encryption protection is not provided when using SSL in this way. The page and its private information are only secure when being transmitted between the browser and the server. The page is not protected by SSL once the download is complete. In this case, the information that should be protected is sent unencrypted, and the form requiring no protection is downloaded via a secure connection.

It is your responsibility to protect the information of your site’s visitors.

New SSL developers and their form users believe they are secure because they see an https address. Some browsers enhance this protection illusion by not issuing any alerts regarding this misuse of SSL. Even though the data is meant to be protected, they will let users send information over unencrypted connections. Other browsers make it very clear that the connection should not be trusted as the form is not secure.

Although the login form page itself does not require encryption, it is nevertheless a bad idea to serve it over an unencrypted connection. You want your users to trust your site. Should they see that the form page address does not begin with https, they will obviously assume it is not secure and leave.

Protecting Session Information

Protecting session data is the area that most systems do not get right. SSL usage is a total waste when it fails to protect sessions. There are two ways to leave a massive security gap:

    • The login process is done safely via an encrypted connection which keeps the user’s information secure. After the safe logging in process is completed however, the user is then dumped onto an http connection and becomes immediately vulnerable to everything they were protected against when logging in.
    •  A user is given a session cookie once they have logged in. This is a small file with a long sequence of random text. After downloading a page from a site, the browser will send the session cookie back requesting a web page. The site then uses this information to identify the user and send them the appropriate content. So… if someone else can read the cookie information while it is being sent to the web site, then they can use it to pretend they are the original user. Unfortunately this means that they then have someone’s login information. If the actual login details were not obtained, then the fraudster can simply steal the cookie data and wait until the victim logs in. This means that a secure login, followed by a non-secure browsing session does not protect the user from having their account accessed.

The solution lies in securing the user’s session cookie. Even when an entire session is encrypted, the session cookie remains vulnerable. If the cookie is secure, then a browser will not send it over an unsecured connection. However, if the cookie is not secure, then a browser can be tricked into sending it through unprotected connections where it can be read by third parties.

By law, most countries require that sensitive information, such as financial or personally identifiable data, be kept secure.

Securing Storage

Often developers assume that SSL is all that is needed to provide security. SSL only protects data by encrypting it during movement between the server and browser. Once the information arrives at either end of the connection, it is decrypted and stays that way. If data is to be stored in some sort of database, then the data must be secured in an encrypted format. Likewise, should the data have a different host to the web server, or be spread over multiple hosts, it is then essential to secure all connections between the web server and the database. It is also important to secure the parts between your database structures.

Remember, SSL is a very powerful tool in protecting the information of your users, as well as inspiring their trust in your website. When a visitor arrives, it is the first thing they will look for when deciding whether the site is to be trusted or not. However, it certainly does not work for all the security threats out there. It is only a part of a greater effort. SSL will protect your data during a specific period of time, but it is wise to note that there are other opportunities for attackers to strike. When using SSL, do not render it useless by neglecting other key areas of weakness in your systems. Never assume that a system is safe. Rather take the time to make a system secure by actively finding weaknesses and strengthening them.