The Plain Text Hangover
If you are still sending user credentials over port 80, you are not just negligent; you are begging for a data breach. In 2010, the tools required to sniff traffic on an open WiFi network are no longer limited to the dark corners of IRC. They are available to anyone who can run a script.
We recently audited a client in Oslo running a Magento setup on shared hosting. Their checkout page was unencrypted. They claimed SSL certificates were "too expensive" and "slowed down the site." Two weeks later, they lost customer data.
Security is not a luxury feature. With the Norwegian Personal Data Act (Personopplysningsloven) and the Datatilsynet watching closely, you need to lock down your transport layer. Here is how to do it correctly, using 2048-bit keys, without melting your CPU.
The 1024-bit Era is Ending
NIST has been warning us for years, but the writing is finally on the wall. 1024-bit RSA keys are insufficient. Computing power is too cheap. You need to move to 2048-bit keys immediately.
When generating your CSR (Certificate Signing Request) on your CoolVDS instance, do not stick to the defaults. Force the key length:
openssl genrsa -des3 -out coolvds_project.key 2048
openssl req -new -key coolvds_project.key -out coolvds_project.csrThis generates a key strong enough to withstand brute-force attempts for the foreseeable future. Submit that CSR to VeriSign, GeoTrust, or RapidSSL.
The Performance Penalty Myth
The main argument against SSL is the "handshake overhead." Yes, asymmetric encryption requires math. It eats CPU cycles. On a crowded shared host where you are fighting for processor time with 500 other WordPress blogs, enabling SSL can add 300-500ms of latency to the initial connection. That is unacceptable.
However, this is not an SSL problem. This is a resource isolation problem.
Pro Tip: Don't terminate SSL on your application server if you can avoid it. Use a lightweight Nginx reverse proxy in front of your heavy Apache/PHP stack. Nginx handles the handshake event-loop style, passing plain traffic to localhost.
Nginx Configuration (Version 0.7.x)
Unlike Apache's process-heavy model, Nginx can handle thousands of SSL handshakes with a fraction of the RAM. Here is a production-ready block for your nginx.conf:
server {
listen 443;
server_name secure.yourdomain.no;
ssl on;
ssl_certificate /etc/nginx/certs/yourdomain.crt;
ssl_certificate_key /etc/nginx/certs/yourdomain.key;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header X-Real-IP $remote_addr;
}
}Note the ssl_session_cache directive. This caches the SSL parameters, so repeat visitors do not force your CPU to re-calculate the handshake every single request. This is critical for performance.
Hardware Matters: The CoolVDS Advantage
You can optimize software all day, but you cannot code your way out of bad hardware. SSL offloading is CPU intensive. If your host is stealing CPU cycles (common in OpenVZ overselling), your users will see a white screen while the handshake hangs.
This is why we architect CoolVDS on Xen virtualization. We provide strict resource isolation. When you buy a slice with 1GB RAM and 2 Cores, those cycles are yours. They aren't shared with the neighbor running a runaway MySQL query.
Furthermore, latency matters. If your target market is Norway, hosting in the US adds 120ms of round-trip time (RTT) to every packet. The SSL handshake involves multiple round trips. 120ms x 3 = 360ms of dead air before a single byte of HTML loads. Hosting locally in Scandinavia drastically reduces this handshake overhead.
Conclusion
The "Green Bar" (EV Certificates) helps with trust, but standard SSL is mandatory for data integrity. Stop making excuses about performance. With the right configuration and a VPS that doesn't steal your CPU cycles, the overhead is negligible.
Don't wait for Datatilsynet to knock on your door. Secure your data.
Need a sandbox to test your SSL config? Deploy a dedicated Xen instance on CoolVDS today.