Hacker News Reader

Comment by buro9 | Hacker News Reader

SSL is not slow.

Grab the latest version of Nginx, turn on SPDY, enable SSL session cache.

You must always serve your API over SSL, as auth information is going to be in headers or the querystring and both would be readable by a MITM if you do not use SSL.

Nginx 1.4 statements to pay attention to (sample config):

    ssl                       on;
    ssl_certificate           /etc/ssl/domain.crt;
    ssl_certificate_key       /etc/ssl/domain.key;
    ssl_session_cache         shared:SSL:10m;
    ssl_session_timeout       10m;
    ssl_ciphers               RC4:HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
    ssl_stapling              on;
    spdy_headers_comp         1;

If you're not using Nginx, why not? Just use it as a reverse proxy and drop it in front of whatever you are using.

View on HN

While we're dispelling SSL myths, let me add the reminder that SSL does encrypt the URL and querystring and HTTP headers. It doesn't look like it in browsers because they still show the URL cleartext onscreen, but over the wire all of that is indeed inside the encryption envelope. Only the destination IP address isn't encrypted.

And whilst we're still here... SNI and SSL.

Thanks to Internet Explorer, and the early versions of the stock browser on Android, you will need a unique IPv4 address for your SSL endpoint.

You cannot safely serve multiple SSL sites on the same IP.✝

Basically: The hostname is also encrypted, so the SSL requests on some browsers require a unique IPv4 address. Your provider will give you one if you say the magic word "SSL" to them.

✝There are ways for most browsers, but not for IE and early Android browsers. Thankfully mobile device churn will cure us of the Android issue, but the affected IE versions will take longer to die.

Huh, TIL. What was the reasoning behind this?

Who knows. I prefer to focus on what needs to be done to make things work.

When client connects to server, first it does the SSL handshake. Then it sends HTTP headers.

As a result, SSL really has nothing to do with HTTP and could be used to wrap other protocols. Check out stunnel ( https://www.stunnel.org/index.html ) which can be used to arbitrarily encrypt communications for any TCP based protocol

And one of the first parts of the SSL handshake is for the server to send the certificate to the client, so the server has to know which certificate to send based only on the IP address that the client is connecting to. The client then verifies that the certificate matches the host name it's trying to connect to. Then it sends the Host: header with the request.

It's a strict layering: TCP - SSL ("Secure Socket Layer", right?) - HTTP

There are two (and a half) ways of using a SSL certificate for multiple hostnames on the same IP address / interface: SNI (Server Name Identification (?)) and Subject Alt Names or Wildcard certificates. SNI extends the SSL protocol to send the hostname during the client handshake. The Subject Alt Name extension, which has been more reliable and available for me, adds multiple hostnames to the certificate for the client to match against. Wildcards do the same thing, patternistically: *.example.com.

Internet Explorer does support SNI since IE7. However Windows XP doesn't even if running IE7 or newer.

That said, we're on our way to a bright SNI filled future, we just have to get over the hump of old versions of Windows and some old mobile devices before it's common enough to be used reliably.

Just to add: make sure your applications handle SSL certificates properly, and only trust either verified signed certificates or only the known certificate from the API server. Otherwise MITM could still expose everything.

Reply on news.ycombinator.com