5 ms·

Ive worked at several huge corporations in IT security, where we care about headers a lot, and they all use headers in a manner similar to CloudFlare. Includin

by efitz 2y ago

Ive worked at several huge corporations in IT security, where we care about headers a lot, and they all use headers in a manner similar to CloudFlare. Including using proxies at the edge to strip out internal headers bidirectionally- yes, inbound too.

sitkack 2y ago
That doesn't make it better, it makes it worse.
- hinkley 2y ago
  Are you on a corporate network? Do you use a firewall at home? You’re on enclaves all the time. This is just a different one. Separate networks per class of traffic used to be de rigeur before Cloud. Now it’s all munged together.
  - sitkack 2y ago
    I understand that security needs to be pragmatic, but because security does it, doesn't make it right. It isn't about being in the enclave, it is having to keep track of what headers you set vs external. It is fragile and error prone and it will absolutely break someone else when there is a name collision. All security exploits are a subset of bugs.
    - hinkley 2y ago
      And what would you have them do instead? SSL to every service? Reauthenticate on every single call? What’s your clever solution? There’s probably a dozen things you can terminate at a boundary that would cost so much to run through the entire system that it would bankrupt a company. And then there’s tracing, which also uses headers.
      - immibis 2y ago
        one of the listed options was to begin all the Cloudflare internal header names with "CFInt"
        hinkley 2y ago
        That’s still header filtering. And it should be X-CF- by the way.
        amluto 2y ago
        X-CF- seems to be used by some other software. And Cloudflare has plenty of documented headers that don’t start with X. The whole point is that a genuine user header should never conflict with a Cloudflare internal header, and a browser should never see an internal header.
        hinkley 2y ago
        Please reread the entire thread. We are talking about someone who thinks the header solution is stupid. You are both splitting hairs. Stay on target.
        sitkack 2y ago
        Having re-read the thread, I totally agree. What you have listed is table stakes. I'd also say that internal headers would also be encrypted to a narrow protection domain. If all internal headers were prefixed with X-CF-, you could strip them all via SIMD that had no knowledge of any specific header. Hell, you could probably do it on the NIC.
        faitswulff 2y ago
        It took me about 10 years to hear about it, but the IETF tried to deprecate the X- prefix back in 2012: https://datatracker.ietf.org/doc/html/rfc6648 https://datatracker.ietf.org/doc/html/rfc6648
        2y ago
  - the8472 2y ago
    Configure all machines in a way that they can survive on some random untrusted public wifi. This should be the obvious default stance for laptops and phones. But even for workstations wired to a trusted LAN it still makes sense because you never know which of the various tunnels might assign and expose some IPv6 address to the internet. For servers you might be able to make an exception if you have a vigilant IT and the people with admin access aren't actively trying to circumvent security, but even then that better not be your only layer of security.
hinkley 2y ago
The first large scale piece of software I worked on was for telcos pre smart phone. We used internal headers to offload authentication and terminate SSL. We also had to pressure F5 to fix about half a dozen bugs in BIG-IP to do so. Bugs that should in no universe have existed in version 9 of a product. I used to joke that F5 owed me and my coworker 3 months of salary for all the free QA we did for them.
- tmsite 2y ago
  It helps if you realize that BIG-IP 9.0 was essentially a from-scratch rewrite of BIG-IP 4.5. Among other major redesigns, the data plane was moved from BSD kernel space to Linux user space. Internally, the joke was that it would be two times better when we were done (4.5 * 2 = 9.0). It probably was, but not on day zero.
  - hinkley 2y ago
    On day sixty it couldn’t do SSL termination and cookie based traffic shaping didn’t work. I was a little bummed it was “just” a Linux box but that’s pretty common today. I hadn’t discovered dd-wrt yet and wouldn’t for a few years.

by efitz 2y ago

sitkack 2y ago

That doesn't make it better, it makes it worse.

hinkley 2y ago
Are you on a corporate network? Do you use a firewall at home? You’re on enclaves all the time. This is just a different one. Separate networks per class of traffic used to be de rigeur before Cloud. Now it’s all munged together.
- sitkack 2y ago
  I understand that security needs to be pragmatic, but because security does it, doesn't make it right. It isn't about being in the enclave, it is having to keep track of what headers you set vs external. It is fragile and error prone and it will absolutely break someone else when there is a name collision. All security exploits are a subset of bugs.
  - hinkley 2y ago
    And what would you have them do instead? SSL to every service? Reauthenticate on every single call? What’s your clever solution? There’s probably a dozen things you can terminate at a boundary that would cost so much to run through the entire system that it would bankrupt a company. And then there’s tracing, which also uses headers.
    - immibis 2y ago
      one of the listed options was to begin all the Cloudflare internal header names with "CFInt"
      - hinkley 2y ago
        That’s still header filtering. And it should be X-CF- by the way.
        amluto 2y ago
        X-CF- seems to be used by some other software. And Cloudflare has plenty of documented headers that don’t start with X. The whole point is that a genuine user header should never conflict with a Cloudflare internal header, and a browser should never see an internal header.
        hinkley 2y ago
        Please reread the entire thread. We are talking about someone who thinks the header solution is stupid. You are both splitting hairs. Stay on target.
        sitkack 2y ago
        Having re-read the thread, I totally agree. What you have listed is table stakes. I'd also say that internal headers would also be encrypted to a narrow protection domain. If all internal headers were prefixed with X-CF-, you could strip them all via SIMD that had no knowledge of any specific header. Hell, you could probably do it on the NIC.
        faitswulff 2y ago
        It took me about 10 years to hear about it, but the IETF tried to deprecate the X- prefix back in 2012: https://datatracker.ietf.org/doc/html/rfc6648 https://datatracker.ietf.org/doc/html/rfc6648
        2y ago
- the8472 2y ago
  Configure all machines in a way that they can survive on some random untrusted public wifi. This should be the obvious default stance for laptops and phones. But even for workstations wired to a trusted LAN it still makes sense because you never know which of the various tunnels might assign and expose some IPv6 address to the internet. For servers you might be able to make an exception if you have a vigilant IT and the people with admin access aren't actively trying to circumvent security, but even then that better not be your only layer of security.

hinkley 2y ago

The first large scale piece of software I worked on was for telcos pre smart phone. We used internal headers to offload authentication and terminate SSL. We also had to pressure F5 to fix about half a dozen bugs in BIG-IP to do so. Bugs that should in no universe have existed in version 9 of a product. I used to joke that F5 owed me and my coworker 3 months of salary for all the free QA we did for them.

tmsite 2y ago
It helps if you realize that BIG-IP 9.0 was essentially a from-scratch rewrite of BIG-IP 4.5. Among other major redesigns, the data plane was moved from BSD kernel space to Linux user space. Internally, the joke was that it would be two times better when we were done (4.5 * 2 = 9.0). It probably was, but not on day zero.
- hinkley 2y ago
  On day sixty it couldn’t do SSL termination and cookie based traffic shaping didn’t work. I was a little bummed it was “just” a Linux box but that’s pretty common today. I hadn’t discovered dd-wrt yet and wouldn’t for a few years.