2

Cloudflare enables several options regarding the communication between its servers and our own.

"SSL Full" means Cloudflare encrypts the traffic but doesn't check the validity of our servers' certificate.

"SSL Full (Strict)" means Cloudflare encrypts the traffic and checks the validity of our servers' certificate.

I am wondering what the security risks are of using "SSL Full".

I understand that theoretically the risk is that someone could pose as us to Cloudflare. I guess this would require that when Cloudflare's servers try to resolve the IP address of our server, they would be misled towards this malicious server. Or that someone on the way between Cloudflare and our server would pose as us, in a Man in the Middle pattern.

How likely is that? Is it even possible?

Cloudflare isn't explicit at all as to whether this option is acceptable in a production setting.

William Martens
  • 177
  • 9
Vic Seedoubleyew
  • 31
  • 9
  • 3
    The overhead of using "SSL Full (Strict)" is almost not existant. Cloudflare even generates a certificate for you to use at the origin. You probably spent more time typing this post than it would take to install that on your server. I'd never use "SSL Full" because even doing a little bit of analysis of the impact of the setting is magnitudes more expensive than just using "SSL Full (Strict)" – Josef Sep 28 '20 at 10:43
  • @JosefsaysReinstateMonica thanks for the comment. Unfortunately this is off topic, because there is a very good reason not to use "SSL Full (Strict)": it is currently bugged at Cloudflare. It randomly sends 526 errors, 5% of the time. In other words, it is a deal breaker. – Vic Seedoubleyew Oct 01 '20 at 09:06
  • 1
    @VicSeedoubleyew Just make sure that the reason lays on CloudFlare side, and not on the side of your servers, e.g. 5% of your nodes may contain invalid certificates, and that could be a sign of a security issue (generally, certificate management issue). – Alexander Fadeev Oct 02 '20 at 14:07
  • @AlexanderFadeev thanks a lot for the comment. I really appreciate you trying to help. The problem is I only have one node, so this rules the hypothesis out. If you have any other idea, I'd be happy to hear it! – Vic Seedoubleyew Oct 06 '20 at 09:09

3 Answers3

4

Issues with SSL Full (not strict)

  1. MITM: you can easily put the whole Internet into the scope, and at least your infrastructure provider. With SSL Full you have the following scheme in place:

    [user] --- TLS ---> [CloudFlare] --- TLS (self-signed) --> [origin]

    On the right side, a self-signed certificate can be used (even not a valid one, compromised, any). And let's zoom in to the right part between [CloudFlare] and your [origin]:

     [CloudFlare] -> Routers -> ISP -> Server provider -> Routers -> [origin]

    Because CloudFlare trusts to ANY certificate at the right side in this case, then a malicious actor at any intermediate node between CloudFlare and the origin can put the certificate and intercept the traffic, and neither CloudFlare nor your origin can identify the leak. You don't know whether it happens until you find yourself in the news.

    See more additional notes below.

  2. Internal threat and Access control: your engineers can mess up with certificates, replace them, use compromised ones, and redirect traffic through their own MITM server. The strict option narrows down the threat to the people with access to a domain controller who can issue a proper TLS certificate on your origins.

What option to choose?

The thing is that it's up to your risk acceptance whether you're ready to keep the connection of this kind of security level in place. Most likely we trust to CloudFlare's part of the network, and to server provider's part of the network (infra), and it basically means that you can keep SSL Full for a while. And I would personally recommend to start from SSL Full, but to plan to implement SSL Full (Strict) as soon as possible.

And forget about MITM for a moment: access control issue (internal threat) is a rather severe risk to not get considered.

Likelihood of MITM

I don't know for sure, but the important thing is that you have to apply the likelihood on the sensitivity of the traffic flowing through the channel. E.g. if the origin receives the PII, payments, and so on, you will get the higher severity of any possible breach. If to imagine that you send some trash just for fun through the channel, then you can drop the security of the channel to HTTP and don't bother.

Your ideal security strategy

  1. Step 1: SSL Full
  2. Step 2: SSL Full (strict)
  3. Step 3: SSL Full (strict) with CloudFlare's CA.

Step 3 means to use CloudFlare's CA to issue certificates for your origin servers: users can connect to the CloudFlare's front-end, but users won't be able to connect directly to the back-end without a TLS handshake error, as browsers don't trust to CloudFlare's Root CA. You would also need to whitelist CloudFlare via iptables.

Again, it's up to you whether to use or not any of the options, it boils down to security and risk assessment of your system.

Alexander Fadeev
  • 1,244
  • 4
  • 10
  • Thank you very much for your answer. I really appreciate your taking the time to help. I am interested only in the security consequences. Thus in order to make your answer more relevant, I would suggest you remove the part about the benefits of using the strict version. Also, could you expand on the security risks, especially the Man in the Middle one? What do you mean, "put the whole Internet into the scope"? How likely is such a threat? Thanks again very much! – Vic Seedoubleyew Oct 01 '20 at 12:27
  • @VicSeedoubleyew Done – Alexander Fadeev Oct 02 '20 at 08:53
  • Thank you very much. This answer really shows effort. It makes the situation very clear. Unfortunately it is still hard to assess the likelihood of this risk, so if you have any ballpark figure I would welcome them. Thanks again very much! – Vic Seedoubleyew Oct 06 '20 at 09:14
  • @VicSeedoubleyew Thank you – Alexander Fadeev Oct 06 '20 at 15:32
1

I think the reason for the option is more operational than security.

Let's say you have a setup where cloudflare is your reverse proxy and nameserver (a typical use-case for the service). So an attacker could either compromise your Cloudflare account or the server at the IP address that the DNS resolves to.

SSL Full or SSL Full (strict) have no difference from this perspective, either compromise would still work.

The only difference is that, under SSL Full (strict), the endpoints need to have real-world certs issued by a valid CA. In SSL Full they can have self-signed certs (or even expired certs IIRC).

Hence operationally SSL Full (strict) is slightly harder to maintain, as each endpoint must have these certs and corresponding private keys. It's much easier to generate self-signed certs on the fly, than it is to load and secure pre-minted certs.

But...the benefit of valid certs, is that should you decide to bypass Cloudflare or Cloudflare decides to offload you from their service, your server can still host the site directly on the internet as it already has the valid certs.

Finally, I don't know for sure, but I suspect the self-signed cert for SSL Full does not require you to set a valid hostname -- which means that your server might not show up on Shodan searches. On the other hand, SSL Full (strict) definitely requires this and hence will appear on Shodan. (you can whitelist only Cloudflare IPs on your server, but unless you have a paid account, Cloudflare do not recommend this).

keithRozario
  • 3,571
  • 2
  • 12
  • 24
  • If you ensure that your origin web server requires SNI and the host name then scanning by services such as Censys & Shodan becomes less of a concern. Cloudflare will know to send the right Host header, but other internet users should not. This of course depends on using Cloudflare properly as a proxy without exposing the origin server. – David Sep 30 '20 at 22:10
  • That’s a good suggestion, there has to be some webserver configuration that mandates SNI, will try to locate it :( – keithRozario Sep 30 '20 at 22:40
  • Thank you very much for your answer. I really appreciate you taking the time to help. Unfortunately my question is really just about security, not about the upsides and downsides of each option. I am specifically interested in knowing the risks of using the non-strict mode. To make your answer more relevant I would suggest you delete all parts that do not address strictly this matter, and develop on the security implications. Thanks again very much! – Vic Seedoubleyew Oct 01 '20 at 12:24
1

The Full (strict) SSL option checks for SSL certificate validity at the origin web server. A self-signed certificate cannot be used. A Cloudflare Origin CA certificate or valid certificate purchased from a Certificate Authority is required to avoid 526 errors.

See: https://support.cloudflare.com/hc/en-us/articles/200170416-End-to-end-HTTPS-with-Cloudflare-Part-3-SSL-options#h_8afd8a8d-382d-4694-a2b2-44cbc9f637ef

schroeder
  • 123,438
  • 55
  • 284
  • 319
D J
  • 11
  • 1
  • Thank you for your answer. I appreciate your taking the time to chip in. I am using a perfectly valid non-self-signed certificate. This is not my problem. This also wasn't my question. Thank you anyway for trying to help! – Vic Seedoubleyew Dec 07 '20 at 09:40