4 ms·

Something I have a hard time understanding, is how Cloudfare's cache generator page had access to sensitive information ? Were the 2 things running on the same

by vmarsy 10y ago

Something I have a hard time understanding, is how Cloudfare's cache generator page had access to sensitive information ? Were the 2 things running on the same process? If they were not, there's no way that the buffer overrun could read an other process memory, right? it would have failed with a segfault type of error. If so, shouldn't Cloudfare consider running the sensitive stuff on a different process, so that no matter how buggy their caching engine is, it would never inadvertently read sensitive information?

cjslep 10y ago
SSL connections were terminating at the proxy, so the proxy used plain HTTP to the web service backends.
- cjslep 10y ago
  Unsure about the random downvotes. It's CloudFlare's "Flexible SSL" offering. Granted, sibling non-speculative comments elaborate more thoroughly for the "non-flexible" cases.
- jpetersonmn 10y ago
  Are you sure about this? Just because they terminate ssl on the proxy doesn't mean the traffic between the proxy and the web service backends was plain HTTP. That's certainly not how we do things.
dugmartin 10y ago
My guess given their widespread use of Go is that each parser was a goroutine which uses the same process heap as other goroutines parsing other page requests.
- ecnahc515 10y ago
  Have you read their incident response? If you had, you would know they weren't using Go for this and it was actually an issue an a parser generated by ragel (C++) which was then used as an nginx module.
  - turbohedgehog 10y ago
    To be clear, it was mis-use of Ragel, not the fault of the Ragel module
CrLf 10y ago
It seems the parser is implemented as an nginx module, thus having access to its memory. CloudFlare terminates SSL in nginx and establishes SSL connections to their upstreams, but inside nginx everything is cleartext. Private keys are not exposed because they are not stored locally (they use the Lua module to implement this). Of course, AFAIK.

by vmarsy 10y ago

cjslep 10y ago

SSL connections were terminating at the proxy, so the proxy used plain HTTP to the web service backends.

cjslep 10y ago
Unsure about the random downvotes. It's CloudFlare's "Flexible SSL" offering. Granted, sibling non-speculative comments elaborate more thoroughly for the "non-flexible" cases.
jpetersonmn 10y ago
Are you sure about this? Just because they terminate ssl on the proxy doesn't mean the traffic between the proxy and the web service backends was plain HTTP. That's certainly not how we do things.

dugmartin 10y ago

My guess given their widespread use of Go is that each parser was a goroutine which uses the same process heap as other goroutines parsing other page requests.

ecnahc515 10y ago
Have you read their incident response? If you had, you would know they weren't using Go for this and it was actually an issue an a parser generated by ragel (C++) which was then used as an nginx module.
- turbohedgehog 10y ago
  To be clear, it was mis-use of Ragel, not the fault of the Ragel module

CrLf 10y ago

It seems the parser is implemented as an nginx module, thus having access to its memory. CloudFlare terminates SSL in nginx and establishes SSL connections to their upstreams, but inside nginx everything is cleartext. Private keys are not exposed because they are not stored locally (they use the Lua module to implement this). Of course, AFAIK.