3

I saw in a post that terminating SSL at Cloudflare level and HTTP only traffic from Cloudflare to origin gives a performance boost since SSL is negotiated only at the edge.

I run a website (mostly static) where security is not a paranoid concern.

Is it worth shutting off my letsencrypt certificate to use Cloudflare provided “flexible certificate” to avoid expensive roundtrips between the edge and the origin?

Edit:

It’s not so much about the CPU (origin machine) that I am concerned. It's more about if I can speed up between the edge and the origin.

Quintin Par
  • 4,373
  • 11
  • 49
  • 72
  • 3
    Nah, probably not. SSL doesn't tax modern servers much at all. If it's mostly static, have CloudFlare cache as much as possible on their end and prevent it from reaching out to your server *at all*. – ceejayoz Aug 08 '18 at 22:09
  • CF caches the images and CSS but not the page itself. I don’t want to cache the page at CF level. So there is always an origin hit. – Quintin Par Aug 08 '18 at 22:25
  • The best way to determine this is by running some benchmarks. I suggest you run "apache bench" to simulate your median expected load with both configurations, that will answer your question. It should take an hour or so to get an answer customized to your setup. Once you do that please answer your own question so others can learn from it. – Tim Aug 11 '18 at 07:51
  • @ceejayoz The speed of light is still the same. Terminating the SSL on the origin server means that you have to pay the full cost of the roundtrips all the way to the origin server whenever a client establish an SSL connection. If SSL is terminated by Cloudflare you only have the roundtrips for SSL from client to Cloudflare. Of course Cloudflare still has to communicate with the origin server, but that's only two roundtrips for HTTP or one if Cloudflare pre-establish connections. – kasperd Aug 12 '18 at 18:35
  • 1
    @kasperd You can have SSL termination on *both*. CloudFlare can still cache, but communication between CloudFlare and the origin benefits from the security as well. Details at https://blog.cloudflare.com/universal-ssl-encryption-all-the-way-to-the-origin-for-free/ – ceejayoz Aug 12 '18 at 22:50
  • @ceejayoz True, but that's not the setup the question is asking about. The question is about end-to-end SSL vs SSL only from client to Cloudflare. And when comparing those two, the extra roundtrips to establish end-to-end SSL does matter. The third option of using two separate SSL connections is not even being considered by the question, but it certainly should be considered by a good answer. Such answer should also point out whether Cloudflare supports pre-establishing the backend connections and whether that differs between HTTP and HTTPS. – kasperd Aug 13 '18 at 07:53

4 Answers4

2

There certainly is an improvement in TLS negotiation by negotiating it closer to the user. TLS negotiation is still a bunch of packets that happens before the first byte of actual data is sent, so getting it closer to the user makes the session establishment faster. This is just basic speed of light stuff - the less physical distance the packets have to travel, all else being equal, the faster it will be.

The question is: Does this really matter? Should you care? In the case of Stack Overflow we establish thousands of user TLS connections a minute, so when you add up millions of TLS sessions over 24 hours, every millisecond counts.

However if you're just getting a few hits an hour, there's not a huge amount of cumulative gains for session estalishment by moving the SSL to your CDN.

In terms of connections from the CDN back to the origin, CloudFlare should use the same few sessions (from each PoP) so it won't be re-establishing on the clients behalf. CloudFlare used to (maybe they still do?) have an WAN accellerator called "Railgun", which makes terminating TLS on the CDN even more adventageous.

However I would think twice about cutting off your Lets Encrypt on your origin. You probably still want to encrypt between CloudFlare and your local web server. It won't make any performance difference, and this way you're still stopping snooping from Cloudflare to your origin.

Mark Henderson
  • 68,823
  • 31
  • 180
  • 259
2

Cloudflare not only offers SSL termination but also HTTP/2 running in conjunction with SSL. This is what provides the speed up, especially if you can cache most of the site content (static files, image files etc). I am somewhat surprised that the other commenters here have not even mentioned HTTP/2 as it brings various improvements to the HTTP protocol.

So I would argue that - if you can upgrade your webserver to support HTTPS+HTTP/2 (latest versions of Nginx do, I think Apache can do with an appropriate module add-on), that's actually going to be the main improvement that will aid any speed up. If you are unable to support HTTP/2, Cloudflare SSL termination with their HTTP/2 support is the next option. And if you are willing/able to run both, that's Cloudflare HTTPS+HTTP/2 termination, and HTTPS+HTTP/2 between them and your origin, the site will be extremely fast and responsive. I have noticed this myself after switching one of my own sites to an entire HTTPS+HTTP/2 pipeline and it is noticeably quicker in loading, primarily due to improvements HTTP/2 brings to the table.

parkamark
  • 1,128
  • 7
  • 11
1

Given you are talking about static content I do not think it makes any sense to decrease security for cold cache cases just to remove an SSL handshake. Clearly you will have proper cache-control headers and will be caching this content for a while.

I would also caution against any micro optimisation that attempts to kill off encryption between the edge and origin for dynamic content to remove an RTT or 2. Cloudflare can already optimise this quite a lot and keep a connection open to the origin for a period of time cutting out the SSL handshakes, raising the congestion window size and so on.

Sam Saffron
  • 1,979
  • 3
  • 18
  • 27
1

If you are speaking at the network level clearly not a worthy gain as already spotted by other comments.

But in the case where CPU is an issue on your origin server that can be an idea because SSLization of the content do cost a CPU overhead (around 20% let's say). But if you don't have CPU issues on the origin it won't save much and thus dosen't worth it at all.

webofmars
  • 190
  • 7