3 ms·

Question: in all discussion about API design, the hairiest to me is always authentication. The article recommends SSL, but the internet says that "SSL is slow.

• buro9 13y ago
  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.
  • T-hawk 13y ago
    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.
    • buro9 13y ago
      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.
      • diminoten 13y ago
        Huh, TIL. What was the reasoning behind this?
        • veesahni 13y ago
          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 https://www.stunnel.org/index.html ) which can be used to arbitrarily encrypt communications for any TCP based protocol
          • mcguire 13y ago
            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.
        • buro9 13y ago
          Who knows. I prefer to focus on what needs to be done to make things work.
      • jerdfelt 13y ago
        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.
  • jd007 13y ago
    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.