21–30 of 117 posts
Earlier quoted context omitted.
It's a little hard for me to believe that there are IPv6-only users out there. Who are these people? edit: I realize there are plenty users behind NAT64 gateways etc, that's the point: how many users out there have no IPv4 connectivity at all?
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.
Glad to see this getting attention. Flexible SSL is an awful option that has no place in the modern encrypted web. Out of the four SSL options Cloudflare gives users, only one is actually secure. It's a huge foot-gun.
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 CloudFlare connect to it as `*.s3.aws.com` or whatever. As long as CloudFlare is actually requiring a trusted cert for *.s3.aws.com, are there security implications I'm missing for why this is a bad idea? (I guess AWS or someone with the keys to AWS certs could be spoofing you? Anything else?)
Or in general even without reference to this use case, explain vulnerability examples/threat models for `Full` without `Strict`?
Earlier quoted context omitted.
It's a little hard for me to believe that there are IPv6-only users out there. Who are these people? edit: I realize there are plenty users behind NAT64 gateways etc, that's the point: how many users out there have no IPv4 connectivity at all?
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.
Earlier quoted context omitted.
It's a little hard for me to believe that there are IPv6-only users out there. Who are these people? edit: I realize there are plenty users behind NAT64 gateways etc, that's the point: how many users out there have no IPv4 connectivity at all?
Most users from KPN (largest dutch telco) are stuck with just a IPV6 address. Phoning home is often quite a bit of a challenge.
Please Cloudflare, I'm a paying customer and have some IPv6 only users that are very frustrated every time they see a Cloudflare challenge page. Your provider, HCaptcha still do not support IPv6. I have to use workarounds like an alternative domain without CF and this is very frustrating.
It's a little hard for me to believe that there are IPv6-only users out there. Who are these people? edit: I realize there are plenty users behind NAT64 gateways etc, that's the point: how many users out there have no IPv4 connectivity at all?
Why is this hard to believe?
IPv4 ran out a while ago depending on which part of the world you are in. New networks do no longer get IPv4 by default. Some can get very small allocations that are barely enough to operate nat64 gateways for a few thousand users. Quite a few networks decided to not invest in legacy IP any more and better spend their (limited) resources on other activities.
> Who are these people?
me + non 1st-world countries.
Please Cloudflare, I'm a paying customer and have some IPv6 only users that are very frustrated every time they see a Cloudflare challenge page. Your provider, HCaptcha still do not support IPv6. I have to use workarounds like an alternative domain without CF and this is very frustrating.
It's a little hard for me to believe that there are IPv6-only users out there. Who are these people? edit: I realize there are plenty users behind NAT64 gateways etc, that's the point: how many users out there have no IPv4 connectivity at all?
Please Cloudflare, I'm a paying customer and have some IPv6 only users that are very frustrated every time they see a Cloudflare challenge page. Your provider, HCaptcha still do not support IPv6. I have to use workarounds like an alternative domain without CF and this is very frustrating.
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... )
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.
That’s not the whole story. Your service doesn’t need to be accessible through ipv6. Just over 464XLAT. That won’t be a problem if you use high level system apis to make connections. All of my servers are ipv4-only and I haven’t had any apps rejected by apple.
Glad to see this getting attention. Flexible SSL is an awful option that has no place in the modern encrypted web. Out of the four SSL options Cloudflare gives users, only one is actually secure. It's a huge foot-gun.
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…