It’s still sitting in triage. @cscharff, any secret sauce we can use to get eyes or interest on this?
Thanks! I was not aware of that post - and if there wasnt a date linked to the article, I could claim that as a perfect backup to strengthen my case
Neither was I aware @troyhunt actually had an (inactive) account here on the forum.
I can’t say that I would be in favour of any of the options proposed above, or flagging to the user that “this SSL connection is better than those over there because we have a special header”.
There are some practical problems with the request.cf or cdn-cgi/trace methods in that these tools contain information about the client connection to the Cloudflare edge, and know nothing about the onward request to the origin.
My main issue is that a header or similar flag would give no assurances about anything further than Cloudflares next hop. You could easily have a TLS terminating device (Load balancer, Nginx, Hitch etc.) that terminates the TLS connection from Cloudflare, and then makes plain old HTTP requests to the ‘real’ origin. This would all be invisible to Cloudflare, but would be a simple solution to get the green tick of approval from SSLLabs/Hardenise etc., but with almost no improvement in the security of the client request.
The connection from CF to Origin might be over TLS, but the TLS key might have been compromised? Is that any better than HTTP?
Even if all communications to the origin is TLS and secure, what assurance is there that the origin implements any sort of security? They might be exposing a database with user names and credit card numbers through a world readable S3 bucket, but
cf-security: full (strict) says everything is good!
To give the user assurance that there is E2E security is something that is almost impossible for CF to do in a header, and might be only possible with a third party audit. I’m as eager as all commenters on this thread to get the default to be
SSL: Full, but
cf-security is not the solution.
You will never get the connection to be guaranteed 100% secure, no. However I think this is a step in the right direction from a transparency front, and I would still rather know whether a site is using Flexible Vs Full (strict) than not.
I don’t believe the header would be implying that ‘everything is good’ or about any security on the origin, just the status of the encryption from Cloudflare.
I would probably go with a
Why not? I am afraid I could not find a proper reason in your posting as to why such a header should not be introduced. It addressed what-if scenarios of what could potentially still happen after the TLS connection finished on the origin.
Full is not “just simply better” than “those over there” (Flexible). The former is a properly encrypted connection, whereas the latter is not and just encryption sugarcoating.
That is also something it never was intended for.
The header should indicate whether the connection between Cloudflare and origin is secure. Thats it! Whatever happens afterwards is (mostly) not part of the transport anymore and really is entirely up to the site maintainer and outside of Cloudflare’s responsibility.
No offence please, but the arguments you brought up rather seem like a distraction than a proper reason as why such a header is a bad idea.
Following your argument we could abandon HTTPS altogether as you can never know if any data is absolutely secure. Do we know Google really stores hashed passwords? Maybe Paypal keeps credit card numbers in plaintext.
I guess I should start predicting lottery numbers
Thanks for reminding me of that! Had that email yesterday and forgot
They only gave us one days notice of the change , but at least they are doing something about it…
And, for the record, invocation #5 of @cscharff - this time should do the trick, shouldnt it
Seriously, though, it is a bit frustrating at this point.
I wish… 6 didn’t work on the other thread, and I have kind of given up on tagging now
I cant deny that there was a certain sarcasm involved
There should be a way to determine if a Cloudflare site is using flexible or full SSL. It could be done by using a CA with a different name for each type of SSL.
Keep in mind, one can change their SSL status every five minutes if they want, that would require either reissuing a certificate every time they change the status or a issueing the certificate twice and then switch every time they change the status.
Update along the way, this request has been moved to the appropriate team for a security review.
Thanks for the update, @cloonan. An idea how quickly they typically take for such features?
Not offhand, but ill take a look at a few that have gone through the process to see if there is a norm, suspect once through review it would be some time to work it into the roadmap.
Any news on this?