What Is The Escalation Process For A Technical Case?

What Is The Escalation Process For A Technical Case?

We’re trying to find a way to talk to a second customer support engineer.
We’ve asked a few times to escalate the case to a manager or to another customer support engineer, but, each time we do, the customer support agent closes the case and doesn’t address the request.
We’ve tried making a second request, but, each time we do, the original CSR merges our new request with the old one then closes it without escalating it.

We’re presently trying to solve a case where we pass a cipher suite via a curl command to Cloudflare.
The customer support rep, gave us the wrong syntax. Once we showed a previous case where the syntax was correct, she gave us the link we provided to the support engineer in the previous case. It appears that our current CSR doesn’t understand what is being discussed in the request. We’ve tried to get a second csr via another ticket and we’ve repeatedly asked the csr for an escalation either to another rep or a manager, but, each request is denied and the tickets are closed.

Is there a place to submit a ticket asking for an intervention by a manager or a more senior CSR? What is the process to do this?

Is this in relation to the ticket in one of your two other posts where you was told there is no escalation path since you wanted a cipher suite that isn’t supported?

The csr says the cipher suite isn’t supported, however, she also gave us bad syntax and from her responses it was clear she didn’t even read the question from some of her responses or the previous cases given.

The strangest thing in the entire process, was her response to us asking if there was a way to talk to a manager or something, I mean just look at the screenshots below. The behavior exhibited is clearly pretty strange.

Then all attempts to make a second ticket were merged to the original then closed.

The idea that Cloudflare only offers insecure cipher suits maxing out at TLS 1.2 seems pretty strange. The idea that an article written a few years ago with a list of outdated ciphers are the only ones allowed seems strange. Getting a second opinion seems warranted.

Asking the same question, and receiving the same answer but asking it again hoping for the answer to change - is not a good strategy.

Not sure where you got the idea that TLS 1.2 is the maximum.

Feel free to check the publicly available configuration if you’re not happy with documentation and employees telling you what is and isn’t supported.

Getting a second opinion when someone make a series of mistakes is a wise plan. If your doctor measures your height wrong and your weight wrong, you don’t trust him with your health conditions. If someone can’t sweep the floor well, you don’t make them CEO.

This rep made a series of mistakes with the basic concepts surrounding the question. This makes me think that this rep would also make a mistake on the complex concepts.

TLS 1.2 isn’t the maximum nor did I think that. That was actually my point, Cloudflare can even restrict the minimum SSL version to TLS 1.3 via the config panel. Typically, API have more capabilities then the config panels do. In this case, the ssl cipher suites listed on that contain just 3 cipher suites that 1.3 with the vast majority being 1.2 and 1 being just 1.0.
It seems to me that if the config panel allows 1.3 only, it likely allows more than these 3 cipher suits in TLS 1.3. I suspect that this list is an example and not a definitive list due to the limited number of 1.3 cipher suits available. This is what I am trying to confirm or get a solid no to with some sort of documentation supporting the no.

As you have been told by documentation, employees and the literal NGINX configuration that is public, it is the definitive list of ciphers used by Cloudflare.

If those 3 points of confirmation aren’t enough, feel free to look at the ones defined in BoringSSL.

It’s clearly the wrong answer to the problem. When I try to submit curl -X PATCH “https://api.cloudflare.com/client/v4/zones/**Censored**/settings/ciphers” -H “X-Auth-Email: censored” -H “X-Auth-Key: Censored” -H “Content-Type: application/json” --data “{”“value”“:[”“ECDHE-ECDSA-AES128-GCM-SHA256"”,““ECDHE-ECDSA-CHACHA20-POLY1305"”,”“ECDHE-RSA-AES128-GCM-SHA256"”,““ECDHE-RSA-CHACHA20-POLY1305"”,”“ECDHE-ECDSA-AES256-GCM-SHA384"”,““ECDHE-RSA-AES256-GCM-SHA384"”]}”

These cipher suites are all in here: Cipher suites — Edge certificates · Cloudflare SSL/TLS docs

It gives the following code:
{“success”:false,“errors”:[{“code”:1007,“message”:“Invalid value for zone setting ciphers”}],“messages”:,“result”:null}

That is the same error code as I received when trying to submit the other list of ciphers.
If the extended list of ciphers were what was causing this error, then submitting the TLS 1.3 ciphers on the list wouldn’t cause the error too. At the very least there is a second error. This conversation is too high of a level to be understood by the currently assigned, ‘engineer’, thus why I need a new one.

To specify certain cipher suites, include an array of applicable cipher suites used for TLS 1.2 or lower, in the value field.

It’s documented that you can’t set the TLS 1.3 ciphers - 1.3 will always use the 3 that are supported.

This isn’t something that needs an escalation when it’s in publicly available documentation.


The entire purpose of trying to do this is to limit the cipher to 1.3, you’re saying that Cloudflare is unable to limit ciphers to 1.3 in the api, when in the configurator area you can easily limit the ciphers to 1.3?

No, it isn’t.

You’re trying to limit the specific ciphers - this is to disable weak ones that are supported for backwards compatibility.

No, because you’re not limiting to TLS 1.3.

You’re trying to change the ciphers that TLS 1.3 would use.

Yep - so do that, or use the underlying API for that.

Changing ciphers individually has nothing to do with the TLS 1.0 to TLS 1.3 drop-down.

1 Like

Well, crud. That might mean my corporate it will force us off Cloudflare because we can’t run ciphers deemed to be secure. :frowning: This is going to be a nightmare.

So you’re saying that one of the 3 TLS 1.3 ciphers is insecure?

If not, absolutely nothing I’ve said would imply that you have to run insecure ciphers.

Well, so we’re running a minimum of TLS 1.2, however according to the scanner tool IT security is running, our Ciphers are insecure. We tried going into the Cloudflare settings and raising the security, but there is a specific list that they require.

Here are a few of them.

While the Cloudflare ones pass an nmap and a sslscan scan, they don’t pass our specific cyber security software. They want specific cipher suites. They gave me a specific number of days to implement it. However, it appears that the suites they require are incompatible with Cloudflare from what you and that csr were saying.

You will need to use the OpenSSL names for ciphers, ones provided by whatever scanning software you are using will not be accepted.

If you have an API call, that sets supported ciphers from Cipher suites — Edge certificates · Cloudflare SSL/TLS docs, which is rejected then that would be an issue.

If you’re trying to enable ciphers that aren’t supported, it would never work. Just disabling ones they don’t want seems like it’d be good enough for most organisations?

1 Like

I think the issue boils down to the fact that the parent company is using a scanner that is looking for those specific ciphers. I assume the Cloudflare ciphers are just as secure if not more secure, but, the scan is looking for specific ciphers that are incompatible with Cloudflare. It appears like whoever developed the cyber security scan made a list of ciphers that perhaps hasn’t been updated or is extremely narrow in scope that doesn’t account for CDN usage. I’m asking them for an exception to the rule, but, it could go either way.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.