Website encryption - a must (?)

Yes I think so, if you have a contact form, definitely if your website got services that requires login. Whatever these may be. In such a case some form of (basic) encryption is a must and a minimum! Why you may ask? Well for one thing, more than ever data traffic is being traced and tracked, that also includes anything sent via the internet on http:// or port 80. Which makes it relatively easy for anyone with average skills, a good utility at hand plus an additional appetite for prying and snooping around, to fetch and detect an open data transaction.

There are several means and ways to prevent transactions from being read, from the traditional and more expensive, to free methods.

Data sniffing got easy... too easy

In 2010 an extension for Firefox called Firesheep was made available (doesn't work on new versions of Firefox), a smart little devil of an add-on that used a packet sniffer to intercept unencrypted cookies from websites such as Facebook, Twitter and others. As cookies are transmitted over networks, packet sniffing is used to discover identities on a sidebar displayed in the browser, and allows the user to instantly take on the log-in credentials of the user by double-clicking on the victim's name. I believe quite a few were exposed to the use of this extension, deprived of access to web services or, as some erroneously called it, hacked.

This utility was designed to prove how easy it was (and is) to sniff unencrypted data/cookies. Today you can do the same thing with other tools, one such is Wireshark. Now, if all you do is to retrieve or read information, web documents and imagery, it doesn't matter so much, although some would claim that the optimal solution is to run with encryption for everything. Others would call it overkill. Classical encryption methods such as TLS/SSL Certificates does increase the load on a server, can slow down a website, how much will depend on what kind of traffic and data. But up to date servers with ditto up to date processors are quite capable of handling the load increase. And therefore, in most cases, with proper scalability such extra load can easily be mitigated.

When should you use Certified TLS/SSL

If you run a Web Enterprise, Social Business/Network or eCommerce solution that stores person or organization sensitive information such as banking or financial data, credit card or account information, or business critical data with access across the internet, you should not even consider whether or not to use proper certified TLS/SSL encryption. It should be a de facto standard. The price you pay for this level of safety is peanuts in comparison to the damage that can be done if you don't.

The certificate, being paired and tied to your domain name is installed on your server, and requires a dedicated public IP address. Another method to run encryption on a website but without the extra load impact, is to use a reversed proxy or a Load Balancer in front of the web server. Using this method the traffic is encrypted on the outside of the firewall, load balancer or reversed proxy, whereas on the inside or behind the firewall one runs normal http traffic. This method also permits unencrypted traffic inside an organization or network, and encrypted on the outside. Personally, in such cases I would apply the same level of security both in and outside.

A free solution for your web portal - JCryption (with Open SSL)

While on the outlook for an lower grade encryption solution for a couple of websites I one day came across JCryption. I dare say it works and works well! Several of the sites I've delivered where encryption or certification was not on the agenda, or something the customer would like to pay for, now runs encryption on several levels thanks to this solution.

Combined with a module for the CMS Framework, some fiddling with additional javascripts, a unique keyfile., RSA for the key exchange and AES for the encryption methods, no data are being sent open. An ideal, low budget solution. The approach also opens up for choosing where encryption should apply, and where not. From now on I'll include this methodology in every web project i do, or where Certified SSL encryption is not on the table.

A free solution for your server - OpenSSL

For those who don't run (very) heavy duty business critical operations, don't store person sensitive information as described above,  OpenSSL might be what is needed to secure basic authentication and submit. In fact some might claim, it will cover your every needs. The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library.

So, that was it... I hope it contributed to shedding some light on a topic I think cannot be emphasized enough. Thank you for reading!

Add new comment