How expensive is SSL for a RESTful API?

Question

I am creating a RESTful API and wondering how expensive it is for the server if every request is made using SSL? This is probably hard to measure, but comparing with non-SSL requests would be helpful (e.g. 1 SSL was as expensive as 30 requests without SSL).

I understand correctly that in order to establish an SSL connection, both parties need to generate public and private keys, share them with each other and then start communication. If using the RESTful API, is this process performed for each request? Or is there some kind of caching that reuses a key for a given host for a certain period of time (if so, how long do they end?).

And the last question, the reason I ask is that I am creating an application that uses facebook connection, and there are some access tokens that provide access to facebook user account, saying this why facebook allows you to transfer these access tokens over unencrypted connections? Of course, they should protect access tokens as much as the username / passwd commands, and thus use an SSL connection ... but they do not.

EDIT: facebook does provide an HTTPS connection whenever an access_token is passed.

Answer 1

http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

On our front-end production servers [Google, ed.], SSL / TLS is less than 1% of the processor load, less than 10 Kbytes of memory per connection, and less than 2% of network costs. Many people believe that SSL takes a lot of CPU time, and we hope that the above figures (public for the first time) will help eliminate this.

If you stop reading now, you only need to remember one thing: SSL / TLS is no longer expensive.

Answer 2

The SSL process looks something like this:

• The server (and optionally the client) presents its (existing, non-generated) public key using the certificate along with the signed call. The opposite side verifies the signature (its mathematical authenticity, certificate path to CA, revocation status, etc.) to make sure that the opposite side is who it approves.

• An authenticated session key is enclosed between authenticated parties (for example, using the Diffie Hellman algorithm).

• Parties switch to encrypted communication

This is an expensive protocol before this and happens every time a socket is installed. You cannot cache a check about who is on the other side. This is why you need persistent sockets (an event with REST).

Answer 3

mtraut described how SSL works, but he omitted the fact that TLS supports session resumption. However, even when session renewal is supported by the protocol itself and by many compatible servers, it is not always supported by client-side implementations. Therefore, you should not rely on renewal, and you better keep a consistent session where possible.

SSL handshaking, on the other hand, is pretty fast (about a dozen milliseconds) these days, so it's not the biggest bottleneck in most cases.