[drdaeman]

I thought the same, but reality isn't that nice. Got this response: https://news.ycombinator.com/item?id=10602621

I was able to replicate this on my own server too, but haven't immediate solution (all the obvious things like OCSP stapling were already configured, following common sense and various "best practices" guides) and I hadn't enough spare time to properly investigate why TLS takes longer.

If someone had encountered this or knows the possible culprits, would be glad to hear suggestions.

[geofft]

I don't currently see a 500 ms difference, so maybe they figured something out. From my shell, I see about 35 ms to http://www.stavros.io/404 and about 85 ms to https://www.stavros.io/404 (the HTTPS site serves actual content and the HTTP a redirect, which confounds the numbers).

The HTTPS server is currently offering me a 4096-bit-RSA certificate, signed by the 2048-bit-RSA StartCom class 1 intermediate CA. There's no security benefit in a 4096-bit cert signed by a 2048-bit one, since any attacker capable of breaking 2048-bit RSA but not 4096-bit is just going to attack the CA cert and sign their own forged cert (and any attacker sorta capable of breaking 2048-bit RSA will dedicate their brute force effort to CA certs). And to my knowledge, all current CA intermediate certs are 2048-bit. Meanwhile, because of math, 4096-bit certs take a lot longer to handshake: see e.g. https://certsimple.com/blog/measuring-ssl-rsa-keys

CertSimple's data indicates a 25 ms difference between 2048-bit and 4096-bit keys on their server, so I'd expect that the 4096-bit key is responsible for at least most of the performance difference here. A few years ago I screwed this up on a production shared web host, and I believe we saw a greater than 50 ms difference. (While we're at it, that cert is SHA-1, so it's possible they can get a reissue for free.)

Were you able to replicate the 500 ms (!) performance difference on your own server? Are you using a 2048-bit cert and reasonable cipher suites?

[drdaeman]

Currently I see ~200ms difference (repeated those tests a good number of times, of course, those are results closest to average):

    $ time curl -4 -s -o /dev/null https://drdaeman.pp.ru
    curl -4 -s -o /dev/null https://drdaeman.pp.ru  0.00s user 0.00s system 2% cpu 0.300 total

     $ time curl -4 -s -o /dev/null http://drdaeman.pp.ru
    curl -4 -s -o /dev/null http://drdaeman.pp.ru  0.00s user 0.00s system 7% cpu 0.107 total

The host isn't doing anything, although the server is old weak Atom machine so it could take some time to do RSA. I followed some guides (say, used Mozilla-recommended cipher list) to get "A+" rating with SSLLabs. Currently it's just "A", I guess because of SHA1 deprecation on Startcom intermediate certs. https://www.ssllabs.com/ssltest/analyze.html?d=drdaeman.pp.r...

I'm also using 4Kbit RSA keys, maybe that's the cause, especially given that the server is a tiny Atom HTPC sitting in the kitchen (100ms is because I'm accessing it from the other country). Will try to find some time on weekend and test with 2Kbit ones to see if this is indeed the cause.

--------------

Added: seems that this worsens with latency, because I see extra 200ms. Maybe the cause is extra network round-trips, not crypto overhead. Or maybe there's something with my curl...

    $ time curl -4 -s -o /dev/null http://stavros.io/404
    curl -4 -s -o /dev/null http://stavros.io/404  0.00s user 0.00s system 4% cpu 0.180 total

    $ time curl -4 -s -o /dev/null https://stavros.io/404
    curl -4 -s -o /dev/null https://stavros.io/404  0.01s user 0.00s system 2% cpu 0.370 total

Unfortunately, don't have time to meditate on Wireshark output right now. :(

[geofft]

> I'm also using 4Kbit RSA keys, maybe that's the cause, especially given that the server is a tiny Atom HTPC sitting in the kitchen

Yeah, the combination of those two things is very likely to not do you any favors.

It is worth clarifying that Google et al.'s claim that SSL is essentially no overhead is conditioned on the assumption that you're using reasonably modern and full-featured processors, especially with AES-GCM in hardware. (Which is pretty common on laptop processors these days even without trying hard to find it, but probably won't be on an Atom HTPC.) I think that's reasonable, since if you're seriously worried about performance and latency, you're probably starting off with good hardware, and your worry is that investment will go to waste if you turn on SSL. At least for running a web server for fun on an old personal machine, the added latency is real and is unfortunate but I'd guess also not such a big deal. But maybe that's a bad assumption?