Not to mention that if you use CloudFlare just to get a free SSL certificate out of them, you're also getting a CDN, so the performance overhead is negative.
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.
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?
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. :(
> 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?
Hmm 9 hours ago and some script kid has already performed this on my local vagrant-box? Pretty funny. I was running it behind vpn and I guess that's why it got exposed.
correct me if I'm wrong, but as good as haraka looks (and it looks great), it isn't really a "complete package" like the GP was looking for...
From the Manual page[0]:
> Haraka makes no attempt to be a mail store (like Exchange or Postix/Exim/Qmail), a LDA, nor an IMAP server (like Dovecot or Courier). Haraka is typically used with such systems.
The streaming part of Spotify is what makes the service great. But when it comes to improving their desktop-app they really are doing some weird stuff with their hipster developers. I think they are suffering from something that I'd like to call "the winamp effect".
I'm still looking for something that can do both.