Key size of 1024 vs. 2048 bits should not account for 225 ms of latency. Here's the result of "openssl speed rsa" on a mid-grade desktop computer.

                    sign    verify    sign/s verify/s
  rsa  512 bits 0.000217s 0.000014s   4608.1  72363.4
  rsa 1024 bits 0.000711s 0.000032s   1406.0  30788.2
  rsa 2048 bits 0.003630s 0.000092s    275.5  10825.0
  rsa 4096 bits 0.021180s 0.000299s     47.2   3349.2

In other words, the difference between 1024 and 2048 bits for the server is 2.9 milliseconds, two orders of magnitude less than the latency the parent comment posted.

Second, it has nothing to do with the "performance on your end" (the client).

The client side of SSL is limited to public key operations only (cert verification, encrypted the pre-master secret). These are 40x faster than private key ops, key length being constant. You're talking a difference of 60 microseconds on the client.

They use HAProxy for load balancing which doesn't natively support SSL termination (yet...). There's probably an extra layer in there to handle that (pound/nginx maybe?) which would bump up the latency.

Exactly what does that have to do with the relation between RSA key sizes and hundreds of milliseconds of latency?

It does for three days. :)

http://blog.exceliance.fr/2012/09/04/howto-ssl-native-in-hap...

Good find!

Didn't realize Github were using 2048 bit keys. I would be interested in knowing what the actual performance differences are between key sizes, given RSA is used in the initial negotiation before symmetric SSL takes over.

>so one could say that googleapis and fb use snake oil rather than ssl ...)

Given that Paypal, my bank, Google and Facebook use 1024 keys, I think labelling 1024 bit as "snake oil", might be a stretch. ;)

>Given that Paypal, my bank, Google and Facebook use 1024 keys, I think labelling 1024 bit as "snake oil", might be a stretch. ;) It's no less snake oil just because every con man sells it...

PayPal uses 2048 bit SSL keys