Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A public letter to CloudFlare to fix their snoopy vendor

github.com

Post reply on HN
Print view View original

31–40 of 117 posts

Re: A public letter to CloudFlare to fix their snoopy vendor

#31

Post by ewuhic »

r1ch wrote: post #30
jrochkind1 wrote: post #22

Earlier quoted context omitted.

I assume you mean only ` Full (strict)` is secure, and not even `Full`? I happened to be recently looking at putting cloudflare in front of an S3 bucket, and it looked maybe easier/more feasible to do with `Full` instead of `Full (Strict)` -- because you can skip configuring the S3 bucket have an SSL cert for your actual front-facing domain (which can be cumbersome and/or more expensive to set up) and just let CloudF…

Full does not check certificates, so a MITM can supply any untrusted certificate and intercept your traffic. Only Full (Strict) does trusted cert checking.

"Can" theoretically, or there's a valid attack vector which one may pull off immediately in the wild?

Re: A public letter to CloudFlare to fix their snoopy vendor

#32

Post by captn3m0 »

ewuhic wrote: post #31
r1ch wrote: post #30

Earlier quoted context omitted.

Full does not check certificates, so a MITM can supply any untrusted certificate and intercept your traffic. Only Full (Strict) does trusted cert checking.

"Can" theoretically, or there's a valid attack vector which one may pull off immediately in the wild?

The current Airtel scenario is a good demonstration I’d say.

Re: A public letter to CloudFlare to fix their snoopy vendor

#33

Post by whymarrh »

ushakov wrote: post #2

what are the use-cases for cloudflare in front of GitHub pages?

GitHub Pages also doesn’t (yet) support custom headers and you can add them with Cf via Workers. So if you’re concerned about the results of securityheaders.io, for example, you can add those in.

Re: A public letter to CloudFlare to fix their snoopy vendor

#34

Post by ameliaquining »

MaulingMonkey wrote: post #15
BillinghamJ wrote: post #3

Earlier quoted context omitted.

This is answered quite clearly in the linked page. GitHub Pages originally didn't support SSL on custom domains, so people would often put Cloudflare in front of it. Now GHP does support SSL on custom domains, so Cloudflare is no longer needed, but obviously a lot of sites still exist with the original setup.

> GitHub Pages originally didn't support SSL on custom domains, so people would often put Cloudflare in front of it. I've done this myself and I'm fixing it now! (Some JavaScript APIs I've experimented with over the years require HTTPS - from WebAuthn, which hey, fair enough - to Web MIDI, which hey, what the heck? https://developer.mozilla.org/en-US/docs/Web/Security/Secure... )

Web MIDI isn't for playing .mid files in the browser. It's for letting in-browser JavaScript talk to arbitrary hardware devices that speak the MIDI protocol; this includes not only things like keyboards and synthesizers, but also stage lighting systems and other theatrical devices that use MIDI as a control protocol (so that you can have, e.g., lighting and sound cues happen in sync, because they're all centrally controlled by a single computer). In general, any API that controls hardware counts as security-sensitive; you don't want MITMs to be able to hijack your hardware devices and make them do something bad.

Re: A public letter to CloudFlare to fix their snoopy vendor

#35

Post by samwillis »

AtNightWeCode wrote: post #14

Ages ago Cloudflare started to advice against these kinds of setups. I did not even know it was still possible. TLS termination on the edge services is just stupid.

Disagree. TLS terminated at the edge, by a trusted partner, is perfectly valid and in many cases a great plus. You should, however, then always have a tls connection back to the main host, this is obviously not always the case and is wrong. Ideally CloudFlare would not make it possible.

By terminating at the edge it enables many useful features of services such as CloudFlare that would otherwise not be possible such as the “web application firewall”.

If you think of CloudFlare as a hosting provider in the same way as any other (which they are) it ridiculous not to trust them terminating TLS.

Re: A public letter to CloudFlare to fix their snoopy vendor

#36

Post by paco3346 »

captn3m0 wrote: post #9
tomklein wrote: post #6

What if the site owners change their SSL settings to Full SSL though?

It fixes the issue, and that has been the recommended fix I've been offering developers all this while.

So really website owners are just misusing Cloudflare? How is this Cloudflare's fault?

Re: A public letter to CloudFlare to fix their snoopy vendor

#37

Post by tedivm »

jaywalk wrote: post #18
JimDabell wrote: post #12

Earlier quoted context omitted.

It’s super common for cellular networks. Apple even has a rule for the App Store to reject any applications that don’t work in an IPv6-only environment because of this. They’ve had this rule for six years.

Must be smaller providers doing this? In the US, we've got CGNAT IPv4 and regular IPv6 for cellular.

It's driven mostly by adoption outside of the US, particularly in Asia. In 2019 over half of the connections in India were IPv6 (of 475 million devices, 52.49 percent are IPv6 devices, according to the APNIC report).

Re: A public letter to CloudFlare to fix their snoopy vendor

#38

Post by r1ch »

ewuhic wrote: post #31
r1ch wrote: post #30

Earlier quoted context omitted.

Full does not check certificates, so a MITM can supply any untrusted certificate and intercept your traffic. Only Full (Strict) does trusted cert checking.

"Can" theoretically, or there's a valid attack vector which one may pull off immediately in the wild?

Cloudflare terminates SSL at the point closest to the user, so any of the ISPs between Cloudflare's POP and the origin could MITM the traffic. Normally an untrusted MITM cert would throw up a TLS error, but since the Cloudflare End User part is trusted, a MITM attack with anything but Full (Strict) is undetectable to an end user.

There's plenty of examples of ISPs trying this in the wild: https://www.zdnet.com/article/kazakhstan-government-is-now-i... https://www.reddit.com/r/sysadmin/comments/4vy3op/my_isp_is_... https://superuser.com/questions/176651/isp-replaces-ssl-cert...

Re: A public letter to CloudFlare to fix their snoopy vendor

#39

Post by ameliaquining »

notRobot wrote: post #28
MaulingMonkey wrote: post #15

Earlier quoted context omitted.

> GitHub Pages originally didn't support SSL on custom domains, so people would often put Cloudflare in front of it. I've done this myself and I'm fixing it now! (Some JavaScript APIs I've experimented with over the years require HTTPS - from WebAuthn, which hey, fair enough - to Web MIDI, which hey, what the heck? https://developer.mozilla.org/en-US/docs/Web/Security/Secure... )

Even the webcam API requires HTTPS, I guess that makes sense?

If it didn't, then whenever you visited a non-HTTPS site, an MITM could inject code into the page that turns your webcam on and then spies on you. Permission prompts help somewhat with this, but not really enough, given that the address bar provides no clue that you're not talking to who you think you are (beyond the generic "Not secure" warning that users usually ignore since it's so common). Allowing this would be a total disaster for user privacy.

Re: A public letter to CloudFlare to fix their snoopy vendor

#40

Post by AtNightWeCode »

samwillis wrote: post #35
AtNightWeCode wrote: post #14

Ages ago Cloudflare started to advice against these kinds of setups. I did not even know it was still possible. TLS termination on the edge services is just stupid.

Disagree. TLS terminated at the edge, by a trusted partner, is perfectly valid and in many cases a great plus. You should, however, then always have a tls connection back to the main host, this is obviously not always the case and is wrong. Ideally CloudFlare would not make it possible. By terminating at the edge it enables many useful features of services such as CloudFlare that would otherwise not be possible such…

TLS termination in the sense that you terminate TLS and then send the traffic to the origins without encryption. Cloudflare services basically works at layer 7 so they must decrypt all the traffic.
Post reply on HN