Comcast + Cloudflare = ERR_SSL_PROTOCOL_ERROR?


Since Monday morning, some of our customers got issues connecting to ERR_SSL_PROTOCOL_ERROR
It appears all these customers are using Comcast ISP.

Since all was fine for them the week before, it seems there is an issue between Comcast and Cloudflare.

For information, some of our settings:
Full encryption (not strict)
Min TLS : 1.2
TLS 1.3 : yes

It’s very hard to troubleshot as we do not have a computer using Comcast as an ISP.

Any idea how to solve the issue ?


1 Like

We have the same issue here: Some users can't establish connection to Cloudflare - #3 by djaho
We are currently trying to resolve this with Cloudflare Support, but the same as you, we can’t reproduce the issue on our side, so we have to ask users to run commands for us and provide us with the output.
When we finally found a user willing to execute a few commands for us in their Terminal we made some progress and wanted them to run a curl command to see the output of the SSL handshake. But after asking the user to run the command, they said that the issue went away on their end. A similar thing happened with some other users. The issue happened and then after some time (a day, two it went away). But then other users started reporting the same issue.

I believe that this issue is still happening for some users (they probably didn’t notice it yet), so it is just a matter of time when someone reports it again to us.

To help us both resolve this issue, I ask you if you can be so kind and ask one or more of your users which are experiencing this issue to run the following curl command in their Terminal (if they are on the Apple Mac devices, which come with curl pre-installed):

curl -svo /dev/null “

This will output a lot more info about the connection and if you can get that output from your users and either paste it here (anonymized of course) or send it to Cloudflare Support, this will most likely help them figure out what went wrong there.

If there is anyone on this forum on Comcast and experiences this issue (or knows someone who does) with the original poster’s domain, then I would like to politely ask you to run the before mentioned curl command and provide us with the output. This will help greatly.
If not, I guess I will just have to buy a plane ticket, go to the States and try this out by myself :slight_smile:

Thank you

Hello @djaho,

Thanks for sharing your inputs.
I will try gather those data, and put them in this thread.

Also, after some google search, I found another project got similar issue: Comcast / Xfinity Access Issues
They workaround it by asking to disable “Advanced Security”
I suspect the Comact Xfinity protection service doing some false positive.
Now you tell me that:

But after asking the user to run the command, they said that the issue went away on their end.

So, maybe, Xfinity is stateful and have some whitelist/cache. ie: If you succeed to TLS handshake once, they put the IP/domain/whatever in this table.

I think the actual command is

curl -svo /dev/null

without " double quotes

Hi @alban1,
Thank you for your input here.
I have also stumbled upon this Xfinity Advanced Security yesterday when I was Googling this issue. It does seem as something that could happen, but it seems strange that it would happen only on our subdomains that are proxied over Cloudflare and not on any other subdomains.
For example, we have subdomain A, which is proxied via Cloudflare and is experiencing this issue. But we also have subdomain B, which is not proxied via Cloudflare and isn’t experiencing this issue.
Both subdomains are part of the same domain.

If the issue is really in Xfinity’s Advances Security, then the solution for this definitely can’t be to ask customers to disable this feature. The solution here would be to make a worldwide exception in this Advanced Security for Cloudflare servers (or to just fix this so called “Advanced Security”).

It would be great if any of us could reproduce this issue so we can actually figure out what is wrong and stop scratching our heads.

I have tried the command with double quotes on Linux machine and it worked, but it could be that it has to be without double quotes on Apple Mac devices.

Hi @alban1 ,

Did you get any more info about this? It seems that some of our customers are still having issues.

Hello @djaho,

seems the issue disappeared itself for now.
Good for us but a bit frustrating not being able to troubleshot :frowning:

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