🔒 Human? Slide comment captcha below and wait for the unlock button. (Cookies required)
6 thoughts on “GoDaddy Helps Break the Internet by Hard Adopting CloudFlare CDN”
Hello, sorry not leaving your comment section empty as I don’t hang out on social media…
CDN making site slower: Generally this is not the case, a CDN will make your site faster by caching assets and hopefully full pages close to you. But your site does not cache well as its giving off a PHPSESSID on the page so you can’t cache the page. If you fix this you should see a speedup in general and would also take better advantage of CDN performance. I don’t know how you did your speed testing if you could not turn off your CDN, I would really question the results though without more evidence. However that said a CDN does have the potential to make a site slower, that’s just very rare.
Safer: Yeah I mean cloudflare “could” block bad requests. They likely help with DDOS but “safer” is really not a great term as its not defined what is meant by that in this context. Safer for the user? Safer for the webserver?
More private: Well… you could potentially hide your hosting provider from website visitors. Your man in the middle is very much true though, that’s exactly what cloudflare is doing. If they decided to be evil they have access to all your traffic. Now hopefully its re-encrypted to the backend webserver. I think this is generally done so not sure why you are complaining about unencrypted traffic from Cloudflare to the webserver. Is this something that was actually done in your webhosting setup? That sounds like a misconfigured CDN if that is the case.
Good point on NSA surveillance. Yeah that’s scary they could easily have a tap at the cloudflare side. As its doing man in the middle stuff all your traffic is decrypted and (hopefully) reencrypted when its sent onward to the backend webserver if it does not hit cache. Cloudflare could easily send all that un-encrypted data to the NSA.
However the argument also falls flat in this case as Godaddy is ALSO a US based company. So any FISA order could be applied directly to them instead of Cloudflare even if you are not using a CDN. Same applies to DreamHost who appear to be your current cost (least they own the IP this site points to).
Now I agree I hate CAPTCHA’s, I know why they do them, and they do help a ton for preventing bot attacks. But they are awful for users and yes can also create fingerprinting issues. And the single point of failure I also agree, way too many sites are behind cloudflare. Some of the same issues are present in other big providers like Googles recaptcha, AWS hosting, etc. I don’t like the trend of big centralized internet. I wish people all went and bought their own servers, no more gmail, yahoo, facebook, x, etc. Everyone gets their own website, their own email, and puts it all on their own server so no one else can mess with it!
Anyway thanks for the post, the more people talk about and think about this stuff the better.
Hi Asdc,
Welcome first human comment in a century. Thanks, great points. The testing to see if a CDN was faster was during the time when I could turn it off at GoDaddy. I tried several via WordPress plugins as I recall. Great tip to look at PHPSESSID. Using PHP sessions is not standard for WordPress, so I assume it is from some plug-in, hopefully not one I wrote, or baked into my theme, which is pretty old. Will check into that. True on FISA orders on all those companies. Giving my encrypted SSL communications to CloudFlare (which annoys me with CAPCHAS) feels different because I signed up with GoDaddy and with NameCheap and DreamHost, but not with CloudFlare. Well I did once, and they are super easy to use. Great set up. Cloudflare offers a few different encyrption modes, but it decrypts the data at its edge servers for various functionalities, such as DDoS protection and Web Application Firewall (WAF) services. This means that while traffic is encrypted when it enters and potentially when it exits Cloudflare (though I think not usually), your private data is still always decrypted in transit within Cloudflare’s infrastructure. Therefore, it does not provide true end-to-end encryption as understood in traditional terms. (Ref: https://community.cloudflare.com/t/dedicated-ssl-does-it-provide-full-end-to-end-encryption/124441 unreachable). Encryption modes they offer include:
– I. Off: No encryption is used. All traffic is transmitted in cleartext HTTP.
– II. Flexible: Encrypts traffic from the browser to Cloudflare using HTTPS, but the connection from Cloudflare to the origin server is unencrypted (HTTP). This mode is suitable for origins that do not support TLS.
– III. Full: Cloudflare encrypts traffic both to and from the origin server but does not validate the origin server’s SSL certificate. If a visitor uses HTTP, Cloudflare will connect to the origin using HTTP as well.
There is a fourth option too, but I don’t like this whole situation where about 20% of the Internet now has a mandatory non-encrypted leg of the journey through part of CloudFlare. This is a big target for big surveillance. It should all be zero trust end to end. The concept of Zero Trust emphasizes the need for end-to-end encryption to protect data throughout its journey. This model assumes that breaches can occur at any point and thus requires rigorous verification of all connections. While Cloudflare promotes its Zero Trust solutions, it is basically saying “trust us”, or perhaps “pay us to un-break all that SSL security we just broke”?
Right so Cloudflare does support unencrypted transit to the backend webserver. But I would expect any big company integrating it as a CDN would set it up to properly encrypt traffic to the backend server (hopefully with full validation of the backend webservers cert too). (But ask your hosting company!)
Of course Cloudflare pretty much always decrypts and re-encrypts. Cloudflare is kinda useless if it’s not doing man in the middle style work as it can’t see much about the traffic. Does “zero-trust” actually do complete end to end encryption? Its rather hard to do end to end encryption, you would basically have to rely on SNI then pipe it to the correct backend server. At which point what’s the point of your CDN? Other then perhaps acting as a basic firewall it seems like your fancy anycast IP with geo-located servers are pointless.
I would expect most shared hosting products would have other decrypt/reencryps hops or even unencrypted traffic running around the hosting providers network too. After all you generally have some kinda shared webserver/proxy that then routes to the backend hosts. The exception being old things like Cpanel/Plesk where its often run on a single box. Or some very new things that are very clever and look at the SNI then route to the correct internal webserver for decryption never having to touch unencrypted traffic. Only way to be sure is to ask the hosting company (and trust them) or run your own server and keep control of your SSL certs.
Yeah, I relate to your point, you signed up to trust GoDaddy with your traffic not Cloudflare. Using an external vender and giving them your SSL cert is not what you expected when you signed up. Would be nice if they made this clear (no clue when/if this was ever mentioned when you signed up for hosting but sounds like they just added it on you without telling you).
Giving Cloudflare such a large chunk of the internet is worrysome. It gives Cloudflare a ton of power. If they decide they don’t like you they can block you from a large number of sites all at once. I pretty much always use a VPN and as of today they just bug me with captcha’s. But if one day they decide they don’t like the VPN at all it would be a huge headache to get around as I can’t simply avoid all the sites they control.
Same thing bothers me in other arena’s like Plaid in financial companies. Many of the “fintech” providers just use Plaid under the hood which is very much not who you expect to handle your sensitive data when you sign up with a different company.
As a final note, doing a speedtest within WordPress is likely not gonna show you the benefit of Cloudflare. To really see the benefit it can provide you need to load all the assets, hopefully a long ways from the webserver, with the Cloudflare node already caching at the very least the asset content. So for best case take a speedtest from some server at least a ways from your server, perhaps in another continent. Run it once to prime everything then run the test. Should be a huge decrease in total load time even without the page caching. With the page caching it would be even better. But if you start from cold you should see little to no benefit. It all works best when you have a steady stream of visitors to your site as its all about getting content from cache that the guy before pulled from the webserver. For the first cold page load you should see little to no difference and it might even be slightly slower. Unless Cloudflare has a better route to get you to the backend server quicker, which is possible as they have a huge network of fiber as well with their backbone. They really are eating the internet, imagine a world where you have to pay Cloudflare to get to some parts of the internet at a reasonable speed if they take over enough fiber? Cloudflare is really too big, it would be better if less people used them and picked some other CDN provider or none at all (though DDOS protection/etc is hard on a small website, Cloudflare provides a huge benefit for free/cheap)
Good points once again, but I strongly disagree that decryption should be happening anywhere between your web browser and the server you are communicating with. It’s not necessary and I think it is a looming silent disaster for human rights. CDNs cache content, which means they store static resources (like images, style-sheets, and scripts) for quick access. However, a CDN does not interpret or alter the content itself. CloudFlare is doing free “security” on top of CDN. How do they make money doing all of this at no cost? Could it be that our bulk decrypted (once secure) data is being sold? Seems crazy and unlikely, but it is not technically impossible. Here’s one “out in the open” way CloudFlare makes money: the Cybersecurity and Infrastructure Security Agency (CISA) awarded Cloudflare a $7.2 million contract to provide DNS services for .gov domains.
It seems from what I’ve read (I haven’t asked GoDaddy because I stopped using them), securing your traffic end-to-end is impossible with CloudFlare, and GoDaddy knows it. When using Cloudflare with GoDaddy Managed WordPress Hosting, the default SSL/TLS mode is typically set to Flexible. This mode encrypts traffic between the user and Cloudflare but does not encrypt the connection between Cloudflare and the origin server (GoDaddy). This is a huge security vulnerability. Reports indicate users can not achieve Full (Strict) mode due to limitations in GoDaddy’s Managed WordPress hosting, which may not allow third-party SSL certificates or specific configurations necessary for this mode1.
Cloudflare acts as a man-in-the-middle using SSL offloading. This practice raises concerns about privacy. Other CDNs offer SSL offloading as well. To me this is like saying some banks offer having outside businesses hold your safe deposit box keys. That’s not something I’d choose to use, and not something that should be allowed to be offered. I see SSL offloading as a form of wiretapping or at the very least severe network security negligence. I think there is a misconception (“Cloudflare pretty much always decrypts and re-encrypts,”) as traffic monitoring does not solely depend on packet content but also on packet routing. Cloudflare can effectively stop DDoS attacks and bots without needing to read sensitive information like bank account passwords. Implementing mutual TLS (mTLS) for secure connections can allow a network security provider to inspect traffic without exposing sensitive data.
Correct zero trust implementations ensure end-to-end encryption, where only the client and server can decrypt data. This means that even if a CDN caches content, it cannot read or manipulate it. A White House Executive Order (EO 14028) issued in January 2022 mandates a zero trust approach as a best practice for modern cybersecurity programs across sectors, emphasizing that HTTP traffic must be encrypted to safeguard data in transit. Cloudflare’s SSL offloading services enable decryption at their edge servers, allowing them to perform “security checks and optimizations” (aka spying) before re-encrypting traffic to users. However, this decryption process can expose user data to potential internal threats within Cloudflare, raising concerns about data privacy and regulatory compliance with laws such as HIPAA, GDPR, and CCPA. Instead of decrypting data, CDNs can filter requests based on patterns or behaviors indicative of malicious activity. Rate limiting and throttling policies can be applied based on request rates or patterns without inspecting payloads, helping to mitigate DDoS attacks or abusive behavior. Web Application Firewalls (WAFs) can also analyze traffic patterns and enforce security policies without decrypting traffic, working in tandem with CDN services.
I don’t think people realize the overreach happening and the future implications. To use a medical analogy, Dr. Cloudflare is requiring we give blood for genetic analyses for them to do the simple job of monitoring our blood pressure.
Perhaps someone with more real world current network security job experience will explain any errors in my views here, but this is what I currently believe to be correct.
I don’t see how you can do any caching without decryption. If you don’t decrypt you don’t know anything about the request beyond SNI* (hostname being asked for). You don’t know what page they are asking for, and even if you did you likely can’t send the encrypted blob to anyone else without re-encrypting as modern cyphers like diffie hellman negotiate a new encryption key on every connection. So no having your cake and eating it too. You gotta pick secure transport all the way to the backend server or caching on a CDN but not both.
As far as rate limiting/DDOS/DOS/etc prevention its much improved with decryption as well. Sure you can do some simple things without it, but without even knowing what pages/etc are being requested its much harder to be effective in blocking bots without blocking any humans.
All to say, there are very good reasons to do the decrypt/re-encrypt cycle. But not to take away from your point you are then completely trusting Cloudflare with the keys to the kingdom. They have your SSL cert and can do anything they want with incoming requests. I don’t know of any CDN’s that try and pass through requests without decrypting and think they would be very limited in their application if they did.
I only briefly glanced at EO 14028, not sure what it says about the matter. But from a purely technical point of view I just don’t see how end to end encryption could play nicely with caching for web requests. I mean you could do something very non-standard like give all the headers then an encrypted blob then give all the clients the same key to decrypt said blob. Do a bunch of stuff in javascript… Sure you could hide parts of the website or important data or what not, but you still have to let the CDN know the file you want or it can’t cache it for you.
* Actually as far as SNI goes Cloudflare is pioneering the way to encrypted SNI so no one else along the chain can see what website you are asking for.
Thank you, Some current realities are very different than I have assumed. I was wrong on a critical detail: SSL/TLS encrypts data transmitted over the network, including HTTP headers and body content. This encryption means a caching proxy or server cannot return needed content in response to requests without decrypting SSL first. Useful caching mechanisms must rely on reading this data and therefore require decryption capabilities. It makes sense. If non-encrypted traffic included the resource(s) (URIs) you wanted on a server, that would not be good privacy.
For encryption end-to-end, historically, many CDN providers offered shared SSL certificates, which required website owners to upload their private keys to the CDN. This practice poses significant security risks since sharing private keys undermines the fundamental principles of public key cryptography. One study examined 10,721 websites using HTTPS with CDNs and found that 68.8% of these sites displayed invalid certificate warnings [https://www.ieee-security.org/TC/SP2014/papers/WhenHTTPSMeetsCDN_c_ACaseofAuthenticationinDelegatedService.pdf]. Thus, a significant portion of CDN implementations may not adhere to proper SSL configurations, leading to trust issues with HTTPS.
Back-End Communication: Some CDNs, like Cloudflare, will use HTTP instead of HTTPS for back-end communication, which can expose vulnerabilities to man-in-the-middle (MITM) attacks. Even when using HTTPS, they may not always perform proper authentication, further compromising security. Thus, some trust issues with HTTPS are justified. If you see the green lock icon and words telling you your communication is secure, but your server uses Cloudflare or another CDN, that assurance of security may be untrue. The way SSL is supposed to work is thus significantly broken. 27% of all websites utilized a CDN as of 2021. Among the top 1,000 websites, CDN usage was notably higher, with 80.5% of those sites employing CDN services. Wow. [https://almanac.httparchive.org/en/2021/cdn]
So SNI is not typically encrypted and I wrongly assumed that is all you need to cache content. While the SNI (Server Name Indication) provides information about which hostname a client is trying to connect to, it is limited. SNI sent during the TLS handshake does not include details such as HTTP methods or paths. Thus, without decrypting the traffic, a caching mechanism can only make decisions based on SNI, which is insufficient for effective caching. The introduction of encrypted SNI (ESNI) further complicates matters by encrypting the SNI field itself, making it impossible for intermediaries to see even the hostname being accessed. This means that if ESNI is used, not only is the content encrypted, but also the information needed to make caching decisions based on hostnames is hidden from any proxies or firewalls that do not have decryption capabilities. Seems like a mess.
The solution is clear: move an encoded copy of the paths into ESNI and keep the rest of the content encrypted so the CDN can never see it. In other words, have two separate containers of encryption and give the least amount of information necessary, on a need-to-know basis.
In RFQ development for CDNs I assumed others would have thought of this. Still feeling some shock about it. How could HTTPS not have been designed with CDNs in mind for Zero Trust for all these years? What I found is that the original design of HTTPS did not fully account for the multi-tenant nature of CDNs. Large CDNs have multiple servers (at times in different locations) and (shockingly) your traffic hops around between them unencrypted. (Gee, where would a hacker sneak in a tap?). This is all because “managing SSL/TLS certificates across numerous CDN nodes can be cumbersome” which is true. Each node (eg server) must have valid certificates to ensure secure connections, which can lead to configuration errors or lapses in security if not maintained properly. Well, we could make CDNs pay for and manage all of those certs, make it mandatory for each node, by regulation, with severe fines. You are still trusting the CDN in this scenario, but at least they are acting in a trustworthy manner by honoring the spirit of SSL.
In other words, I suggest we BAN the SSL lock icon on all web browsers unless web users are getting true end-to-end SSL! Make the lock icon true again!
Hello, sorry not leaving your comment section empty as I don’t hang out on social media…
CDN making site slower: Generally this is not the case, a CDN will make your site faster by caching assets and hopefully full pages close to you. But your site does not cache well as its giving off a PHPSESSID on the page so you can’t cache the page. If you fix this you should see a speedup in general and would also take better advantage of CDN performance. I don’t know how you did your speed testing if you could not turn off your CDN, I would really question the results though without more evidence. However that said a CDN does have the potential to make a site slower, that’s just very rare.
Safer: Yeah I mean cloudflare “could” block bad requests. They likely help with DDOS but “safer” is really not a great term as its not defined what is meant by that in this context. Safer for the user? Safer for the webserver?
More private: Well… you could potentially hide your hosting provider from website visitors. Your man in the middle is very much true though, that’s exactly what cloudflare is doing. If they decided to be evil they have access to all your traffic. Now hopefully its re-encrypted to the backend webserver. I think this is generally done so not sure why you are complaining about unencrypted traffic from Cloudflare to the webserver. Is this something that was actually done in your webhosting setup? That sounds like a misconfigured CDN if that is the case.
Good point on NSA surveillance. Yeah that’s scary they could easily have a tap at the cloudflare side. As its doing man in the middle stuff all your traffic is decrypted and (hopefully) reencrypted when its sent onward to the backend webserver if it does not hit cache. Cloudflare could easily send all that un-encrypted data to the NSA.
However the argument also falls flat in this case as Godaddy is ALSO a US based company. So any FISA order could be applied directly to them instead of Cloudflare even if you are not using a CDN. Same applies to DreamHost who appear to be your current cost (least they own the IP this site points to).
Now I agree I hate CAPTCHA’s, I know why they do them, and they do help a ton for preventing bot attacks. But they are awful for users and yes can also create fingerprinting issues. And the single point of failure I also agree, way too many sites are behind cloudflare. Some of the same issues are present in other big providers like Googles recaptcha, AWS hosting, etc. I don’t like the trend of big centralized internet. I wish people all went and bought their own servers, no more gmail, yahoo, facebook, x, etc. Everyone gets their own website, their own email, and puts it all on their own server so no one else can mess with it!
Anyway thanks for the post, the more people talk about and think about this stuff the better.
Hi Asdc,
Welcome first human comment in a century. Thanks, great points. The testing to see if a CDN was faster was during the time when I could turn it off at GoDaddy. I tried several via WordPress plugins as I recall. Great tip to look at PHPSESSID. Using PHP sessions is not standard for WordPress, so I assume it is from some plug-in, hopefully not one I wrote, or baked into my theme, which is pretty old. Will check into that. True on FISA orders on all those companies. Giving my encrypted SSL communications to CloudFlare (which annoys me with CAPCHAS) feels different because I signed up with GoDaddy and with NameCheap and DreamHost, but not with CloudFlare. Well I did once, and they are super easy to use. Great set up. Cloudflare offers a few different encyrption modes, but it decrypts the data at its edge servers for various functionalities, such as DDoS protection and Web Application Firewall (WAF) services. This means that while traffic is encrypted when it enters and potentially when it exits Cloudflare (though I think not usually), your private data is still always decrypted in transit within Cloudflare’s infrastructure. Therefore, it does not provide true end-to-end encryption as understood in traditional terms. (Ref: https://community.cloudflare.com/t/dedicated-ssl-does-it-provide-full-end-to-end-encryption/124441 unreachable). Encryption modes they offer include:
– I. Off: No encryption is used. All traffic is transmitted in cleartext HTTP.
– II. Flexible: Encrypts traffic from the browser to Cloudflare using HTTPS, but the connection from Cloudflare to the origin server is unencrypted (HTTP). This mode is suitable for origins that do not support TLS.
– III. Full: Cloudflare encrypts traffic both to and from the origin server but does not validate the origin server’s SSL certificate. If a visitor uses HTTP, Cloudflare will connect to the origin using HTTP as well.
There is a fourth option too, but I don’t like this whole situation where about 20% of the Internet now has a mandatory non-encrypted leg of the journey through part of CloudFlare. This is a big target for big surveillance. It should all be zero trust end to end. The concept of Zero Trust emphasizes the need for end-to-end encryption to protect data throughout its journey. This model assumes that breaches can occur at any point and thus requires rigorous verification of all connections. While Cloudflare promotes its Zero Trust solutions, it is basically saying “trust us”, or perhaps “pay us to un-break all that SSL security we just broke”?
Thanks again.
Right so Cloudflare does support unencrypted transit to the backend webserver. But I would expect any big company integrating it as a CDN would set it up to properly encrypt traffic to the backend server (hopefully with full validation of the backend webservers cert too). (But ask your hosting company!)
Of course Cloudflare pretty much always decrypts and re-encrypts. Cloudflare is kinda useless if it’s not doing man in the middle style work as it can’t see much about the traffic. Does “zero-trust” actually do complete end to end encryption? Its rather hard to do end to end encryption, you would basically have to rely on SNI then pipe it to the correct backend server. At which point what’s the point of your CDN? Other then perhaps acting as a basic firewall it seems like your fancy anycast IP with geo-located servers are pointless.
I would expect most shared hosting products would have other decrypt/reencryps hops or even unencrypted traffic running around the hosting providers network too. After all you generally have some kinda shared webserver/proxy that then routes to the backend hosts. The exception being old things like Cpanel/Plesk where its often run on a single box. Or some very new things that are very clever and look at the SNI then route to the correct internal webserver for decryption never having to touch unencrypted traffic. Only way to be sure is to ask the hosting company (and trust them) or run your own server and keep control of your SSL certs.
Yeah, I relate to your point, you signed up to trust GoDaddy with your traffic not Cloudflare. Using an external vender and giving them your SSL cert is not what you expected when you signed up. Would be nice if they made this clear (no clue when/if this was ever mentioned when you signed up for hosting but sounds like they just added it on you without telling you).
Giving Cloudflare such a large chunk of the internet is worrysome. It gives Cloudflare a ton of power. If they decide they don’t like you they can block you from a large number of sites all at once. I pretty much always use a VPN and as of today they just bug me with captcha’s. But if one day they decide they don’t like the VPN at all it would be a huge headache to get around as I can’t simply avoid all the sites they control.
Same thing bothers me in other arena’s like Plaid in financial companies. Many of the “fintech” providers just use Plaid under the hood which is very much not who you expect to handle your sensitive data when you sign up with a different company.
As a final note, doing a speedtest within WordPress is likely not gonna show you the benefit of Cloudflare. To really see the benefit it can provide you need to load all the assets, hopefully a long ways from the webserver, with the Cloudflare node already caching at the very least the asset content. So for best case take a speedtest from some server at least a ways from your server, perhaps in another continent. Run it once to prime everything then run the test. Should be a huge decrease in total load time even without the page caching. With the page caching it would be even better. But if you start from cold you should see little to no benefit. It all works best when you have a steady stream of visitors to your site as its all about getting content from cache that the guy before pulled from the webserver. For the first cold page load you should see little to no difference and it might even be slightly slower. Unless Cloudflare has a better route to get you to the backend server quicker, which is possible as they have a huge network of fiber as well with their backbone. They really are eating the internet, imagine a world where you have to pay Cloudflare to get to some parts of the internet at a reasonable speed if they take over enough fiber? Cloudflare is really too big, it would be better if less people used them and picked some other CDN provider or none at all (though DDOS protection/etc is hard on a small website, Cloudflare provides a huge benefit for free/cheap)
Good points once again, but I strongly disagree that decryption should be happening anywhere between your web browser and the server you are communicating with. It’s not necessary and I think it is a looming silent disaster for human rights. CDNs cache content, which means they store static resources (like images, style-sheets, and scripts) for quick access. However, a CDN does not interpret or alter the content itself. CloudFlare is doing free “security” on top of CDN. How do they make money doing all of this at no cost? Could it be that our bulk decrypted (once secure) data is being sold? Seems crazy and unlikely, but it is not technically impossible. Here’s one “out in the open” way CloudFlare makes money: the Cybersecurity and Infrastructure Security Agency (CISA) awarded Cloudflare a $7.2 million contract to provide DNS services for .gov domains.
It seems from what I’ve read (I haven’t asked GoDaddy because I stopped using them), securing your traffic end-to-end is impossible with CloudFlare, and GoDaddy knows it. When using Cloudflare with GoDaddy Managed WordPress Hosting, the default SSL/TLS mode is typically set to Flexible. This mode encrypts traffic between the user and Cloudflare but does not encrypt the connection between Cloudflare and the origin server (GoDaddy). This is a huge security vulnerability. Reports indicate users can not achieve Full (Strict) mode due to limitations in GoDaddy’s Managed WordPress hosting, which may not allow third-party SSL certificates or specific configurations necessary for this mode1.
Cloudflare acts as a man-in-the-middle using SSL offloading. This practice raises concerns about privacy. Other CDNs offer SSL offloading as well. To me this is like saying some banks offer having outside businesses hold your safe deposit box keys. That’s not something I’d choose to use, and not something that should be allowed to be offered. I see SSL offloading as a form of wiretapping or at the very least severe network security negligence. I think there is a misconception (“Cloudflare pretty much always decrypts and re-encrypts,”) as traffic monitoring does not solely depend on packet content but also on packet routing. Cloudflare can effectively stop DDoS attacks and bots without needing to read sensitive information like bank account passwords. Implementing mutual TLS (mTLS) for secure connections can allow a network security provider to inspect traffic without exposing sensitive data.
Correct zero trust implementations ensure end-to-end encryption, where only the client and server can decrypt data. This means that even if a CDN caches content, it cannot read or manipulate it. A White House Executive Order (EO 14028) issued in January 2022 mandates a zero trust approach as a best practice for modern cybersecurity programs across sectors, emphasizing that HTTP traffic must be encrypted to safeguard data in transit. Cloudflare’s SSL offloading services enable decryption at their edge servers, allowing them to perform “security checks and optimizations” (aka spying) before re-encrypting traffic to users. However, this decryption process can expose user data to potential internal threats within Cloudflare, raising concerns about data privacy and regulatory compliance with laws such as HIPAA, GDPR, and CCPA. Instead of decrypting data, CDNs can filter requests based on patterns or behaviors indicative of malicious activity. Rate limiting and throttling policies can be applied based on request rates or patterns without inspecting payloads, helping to mitigate DDoS attacks or abusive behavior. Web Application Firewalls (WAFs) can also analyze traffic patterns and enforce security policies without decrypting traffic, working in tandem with CDN services.
I don’t think people realize the overreach happening and the future implications. To use a medical analogy, Dr. Cloudflare is requiring we give blood for genetic analyses for them to do the simple job of monitoring our blood pressure.
Perhaps someone with more real world current network security job experience will explain any errors in my views here, but this is what I currently believe to be correct.
I don’t see how you can do any caching without decryption. If you don’t decrypt you don’t know anything about the request beyond SNI* (hostname being asked for). You don’t know what page they are asking for, and even if you did you likely can’t send the encrypted blob to anyone else without re-encrypting as modern cyphers like diffie hellman negotiate a new encryption key on every connection. So no having your cake and eating it too. You gotta pick secure transport all the way to the backend server or caching on a CDN but not both.
As far as rate limiting/DDOS/DOS/etc prevention its much improved with decryption as well. Sure you can do some simple things without it, but without even knowing what pages/etc are being requested its much harder to be effective in blocking bots without blocking any humans.
All to say, there are very good reasons to do the decrypt/re-encrypt cycle. But not to take away from your point you are then completely trusting Cloudflare with the keys to the kingdom. They have your SSL cert and can do anything they want with incoming requests. I don’t know of any CDN’s that try and pass through requests without decrypting and think they would be very limited in their application if they did.
I only briefly glanced at EO 14028, not sure what it says about the matter. But from a purely technical point of view I just don’t see how end to end encryption could play nicely with caching for web requests. I mean you could do something very non-standard like give all the headers then an encrypted blob then give all the clients the same key to decrypt said blob. Do a bunch of stuff in javascript… Sure you could hide parts of the website or important data or what not, but you still have to let the CDN know the file you want or it can’t cache it for you.
* Actually as far as SNI goes Cloudflare is pioneering the way to encrypted SNI so no one else along the chain can see what website you are asking for.
Thank you, Some current realities are very different than I have assumed. I was wrong on a critical detail: SSL/TLS encrypts data transmitted over the network, including HTTP headers and body content. This encryption means a caching proxy or server cannot return needed content in response to requests without decrypting SSL first. Useful caching mechanisms must rely on reading this data and therefore require decryption capabilities. It makes sense. If non-encrypted traffic included the resource(s) (URIs) you wanted on a server, that would not be good privacy.
For encryption end-to-end, historically, many CDN providers offered shared SSL certificates, which required website owners to upload their private keys to the CDN. This practice poses significant security risks since sharing private keys undermines the fundamental principles of public key cryptography. One study examined 10,721 websites using HTTPS with CDNs and found that 68.8% of these sites displayed invalid certificate warnings [https://www.ieee-security.org/TC/SP2014/papers/WhenHTTPSMeetsCDN_c_ACaseofAuthenticationinDelegatedService.pdf]. Thus, a significant portion of CDN implementations may not adhere to proper SSL configurations, leading to trust issues with HTTPS.
Back-End Communication: Some CDNs, like Cloudflare, will use HTTP instead of HTTPS for back-end communication, which can expose vulnerabilities to man-in-the-middle (MITM) attacks. Even when using HTTPS, they may not always perform proper authentication, further compromising security. Thus, some trust issues with HTTPS are justified. If you see the green lock icon and words telling you your communication is secure, but your server uses Cloudflare or another CDN, that assurance of security may be untrue. The way SSL is supposed to work is thus significantly broken. 27% of all websites utilized a CDN as of 2021. Among the top 1,000 websites, CDN usage was notably higher, with 80.5% of those sites employing CDN services. Wow. [https://almanac.httparchive.org/en/2021/cdn]
So SNI is not typically encrypted and I wrongly assumed that is all you need to cache content. While the SNI (Server Name Indication) provides information about which hostname a client is trying to connect to, it is limited. SNI sent during the TLS handshake does not include details such as HTTP methods or paths. Thus, without decrypting the traffic, a caching mechanism can only make decisions based on SNI, which is insufficient for effective caching. The introduction of encrypted SNI (ESNI) further complicates matters by encrypting the SNI field itself, making it impossible for intermediaries to see even the hostname being accessed. This means that if ESNI is used, not only is the content encrypted, but also the information needed to make caching decisions based on hostnames is hidden from any proxies or firewalls that do not have decryption capabilities. Seems like a mess.
The solution is clear: move an encoded copy of the paths into ESNI and keep the rest of the content encrypted so the CDN can never see it. In other words, have two separate containers of encryption and give the least amount of information necessary, on a need-to-know basis.
In RFQ development for CDNs I assumed others would have thought of this. Still feeling some shock about it. How could HTTPS not have been designed with CDNs in mind for Zero Trust for all these years? What I found is that the original design of HTTPS did not fully account for the multi-tenant nature of CDNs. Large CDNs have multiple servers (at times in different locations) and (shockingly) your traffic hops around between them unencrypted. (Gee, where would a hacker sneak in a tap?). This is all because “managing SSL/TLS certificates across numerous CDN nodes can be cumbersome” which is true. Each node (eg server) must have valid certificates to ensure secure connections, which can lead to configuration errors or lapses in security if not maintained properly. Well, we could make CDNs pay for and manage all of those certs, make it mandatory for each node, by regulation, with severe fines. You are still trusting the CDN in this scenario, but at least they are acting in a trustworthy manner by honoring the spirit of SSL.
In other words, I suggest we BAN the SSL lock icon on all web browsers unless web users are getting true end-to-end SSL! Make the lock icon true again!