Header indicating encryption status of the origin connection


Not only, but also because of Website not opening with cloudflare server, could Cloudflare introduce a new response header which indicates whether the connection between origin and Cloudflare was encrypted or not?

That would not only serve debugging but also transparency purposes.

Feedback and thoughts welcome :slight_smile:

Redirection loop : wrong SSL config?
Did I do it set SSL correctly?
Detecting non-strict SSL setups
Detecting non-strict SSL setups

Great idea @sandro, really like it and it would help a lot with debugging :slightly_smiling_face:… And yes, transparency also!


+1, but I imagine some people will be fully against the idea since it would expose their inability to secure the origin :stuck_out_tongue_winking_eye:


That’s precisely where the transparency argument kicks in :smile: :wink:


A slight nudge and tagging the usual suspects @cloonan, @cscharff, @ryan

Is there any chance of having this being made available and what could a possible timeframe for it be? Asking because I think it could be really useful and “should” :man_shrugging: be easy to implement :bowing_man:

1 Like

I don’t see it on the internal list, but will dig a bit…


In my opinion, this probably wouldn’t work in terms of customer reception.

Sure, we here in the Community know what we’re doing and advocate for HTTPS from browser to origin, but the main pull of Cloudflare (at least for Free websites on shared wordpress setups) is the green padlock without having to pay for their hosting provider to install a certificate.

If this header was implemented, it would only be a matter of time before Troy Hunt exposes a website on twitter for having cf-security: flexible in their headers on a page which processes logins or payment information. Odds are the company either goes under (lost a large portion of their ecommerce sales) or decides to switch to another CDN or SSL proxy provider which doesn’t expose their bad security practices.

I’m not saying that this is a bad feature, I voted since I always advocate for e2e security, but I don’t see this working out from a financial standpoint. I obviously don’t know the statistics or have any charts on me,but maybe it would just be togglable for debugging and not something that is immediately enforced on everyone.


I understand what you are saying but Flexible undermines security and is deceptive to visitors. One is made to believe a site is secure and data is transmitted in a safe manner, when in fact that is not the case and that data turns into plaintext the moment it leaves for the actual destination.

From this perspective a Troy Hunt who exposes sites handling payment data in such a manner should be more than welcome and would not only do the security but the whole Internet community quite a favour.

Again, I understand your point from a commercial point of view but Cloudflare is not solely a commercial entity but also assumed a lead in advancing and improving Internet security.
Please also keep in mind that profitable Cloudflare customers mostly likely wont be on “Flexible” anyhow.


I agree with @sandro on this, I was on a site that uses Cloudflare and processes payment details, and I was wondering (and hoping!) that they didn’t use flexible.

Both for this and for debugging, it would be a great help :slightly_smiling_face:

I completely see where you are coming from @Judge and why some wouldn’t want it though… They really should use full though!!


Of course, but then people also complained when browsers warned of password fields on HTTP pages. One site even came up with quite an ingenious solution to work around such a warning.

For debugging that feature could certainly be optional, for the sake of transparency it most certainly should not be optional.


It would even be added as a dot in Claire.


@cloonan @cscharff, possibly any update on this?

1 Like

Anything on this, @cloonan?

Last thing I know was @cscharff mentioned he had opened a feature request. :+1:t2:

1 Like

I see and am watching the issue @cscharff opened, still needs triage


Maybe it could just be on the debug page (/cdn-cgi/trace) and not in the headers since it seems those can be added more quickly (since warp= was just added).


That could certainly be an option too, even though it would not take into account page rules.


That’s great for debugging but for transparency, I believe it would be important that it’s visible on each request.


If not a header maybe in the request.cf object so loggers can get at it?


@cloonan, any news about this?