CloudFlare’s last Warrant Canary was published over a year ago • Hacker News Board

Re: CloudFlare’s last Warrant Canary was published over a year ago

#141

Post by tick_tock_tick » Tue, Aug 01, 2023, 7:05 AM UTC

edandersen wrote: post #134

jlbooker wrote: post #118

Earlier quoted context omitted.

I guess you like those cookie warnings that pollute the Internet these days? Because this would be cookie warnings all over again. Any site that's reasonably popular uses a CDN to increase scalability, improve performance, and add reliability. Half the Internet would need a new pop-up warning that a CDN is in use. The last thing we need is yet another pop-up when a page loads....

It doesn't need to be a pop up. Just behave like a HTTP site ("not secure" warning) when you could be MITM'd between yourself and the entity you think you are communicating with. If it turned out "End to end" encrypted chat went through a third party that even transiently had access to the plaintext version of the chat (like how Cloudflare works) you'd be apoplectic.

It's impossible to know if a third party had access to the plain text. Hell even Cloudflare can be setup with actual end to end encryption where they can never see the contexts of the traffic. Most users don't want that as they want CDN features that require unencoding the data.

Re: CloudFlare’s last Warrant Canary was published over a year ago

#142

Post by richij » Tue, Aug 01, 2023, 10:09 AM UTC

tsujamin wrote: post #3

The glossary entry on warrant canaries is dated December 2020, but there is a more recent canary list in their 2022 transparency report ( https://www.cloudflare.com/en-au/transparency/ ) with the same 6 items in it. Bizarre they appear to have skipped the H2 2022 transparency report unless I’m missing something

also on that page: "Confirmed: July 31, 2023"

Re: CloudFlare’s last Warrant Canary was published over a year ago

#143

Post by byndlimitsfy » Tue, Aug 01, 2023, 12:59 PM UTC

hamandcheese wrote: post #88

charcircuit wrote: post #66

Earlier quoted context omitted.

Cloudflare is not a MitM attack. By that same logic AWS would be an even bigger MitM attack.

By that same logic, it would not be surprising to discover AWS working with the feds either.

This might be anticipated, it won't be a surprise.

Re: CloudFlare’s last Warrant Canary was published over a year ago

#144

Post by Manouchehri » Tue, Aug 01, 2023, 6:19 PM UTC

eastdakota wrote: post #75

JHorse wrote: post #5

Earlier quoted context omitted.

Their Canary has more to do with their infrastructure being compromised. It's likely one or more of these statements are no longer true: 1. Cloudflare has never turned over our encryption or authentication keys or our customers' encryption or authentication keys to anyone. 2. Cloudflare has never installed any law enforcement software or equipment anywhere on our network. 3. Cloudflare has never provided any law enfo…

I'll state right here: all these are still true. We'll get the canary updated. Checking with legal and trust & safety why it hasn't been for so long. Likely just slipped someone's mind. Will make sure that doesn't happen again.

How about make `https://www.cloudflare.com/.well-known/warrant-canary.txt`, and use a Cloudflare Worker with a Cron Trigger to trigger an email to legal if it's approaching expiry?

Re: CloudFlare’s last Warrant Canary was published over a year ago

#145

Post by thephyber » Thu, Aug 03, 2023, 7:50 AM UTC

edandersen wrote: post #135

thephyber wrote: post #128

Earlier quoted context omitted.

This seems like a useless warning. The owner of the domain has to choose to integrate a CDN. They implicitly trust the vendor who runs the CDN just like they implicitly trust the cloud provider that asserts their VPC between their server that terminates TLS and any API servers behind that which don’t use encryption for data in transit.

That's fine but the user has no way of knowing if a third party is party to the communications or not. Surely they should know?

Again - that seems like a useless warning.

3rd party could mean a DBA, IT consultant, AWS support tech, CDN support tech, MSSP employee, cloud platform, etc. those all come with different levels of risk, different contract terms, etc.

I’m trying to say that just saying the TLS connection is terminated by a vendor, who then creates another to the origin server doesn’t tell you anything valuable from a security / risk standpoint. The CDN-fronted connection that shows the warning may be highly secure while a self-managed reverse proxy that terminates the TLS connection to another serve owned+managed by the same person/org might be completely insecure. The warning is not a useful signal.