Console Login
Home / Blog / Security / SSL in 2010: Why Your Unencrypted Login Form is a Liability
Security 2 views

SSL in 2010: Why Your Unencrypted Login Form is a Liability

@

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.csr

This 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.

/// TAGS

/// RELATED POSTS

Hardening the Stack: Defending Norwegian Web Apps Against the OWASP Top 10 (2012 Edition)

It is 2012, and SQL Injection is still king. A battle-hardened guide to securing LAMP stacks, comply...

Read More →

Surviving the Flood: Practical DDoS Mitigation for Small Norwegian Sites

Script kiddies and LOIC attacks don't care about your uptime. Learn to harden your Linux stack with ...

Read More →

Locking Down the Pipe: Building a Hardened OpenVPN Gateway on CentOS 5

Public Wi-Fi is a minefield for packet sniffers. Learn how to deploy a secure OpenVPN server in Norw...

Read More →

Secure Tunneling: Deploying OpenVPN on CentOS 5 for the Paranoiode Sysadmin

Public Wi-Fi is a minefield. Secure your traffic by building a robust OpenVPN gateway. We cover the ...

Read More →

Network Security Protocols for High-Availability VPS in Norway

A technical deep-dive into hardening cloud environments. We analyze firewall strategies, local NIX l...

Read More →
← Back to All Posts