1504109 - SSL_ERROR_NO_CYPHER_OVERLAP on https://archive.is/ when using Cloudflare DoH

Status: RESOLVED WORKSFORME

(Core :: Security: PSM, defect, P2)

Description

[Chris Peterson [:cpeterson]]

STR:
1. Enable DoH prefs:
network.trr.mode = 2
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query

2. Load https://archive.is/

RESULT:
Secure Connection Failed

An error occurred during a connection to archive.is. Cannot communicate securely with peer: no common encryption algorithm(s). Error code: SSL_ERROR_NO_CYPHER_OVERLAP

If I revert network.trr.mode to the default value 0 and reload archive.is, then the page loads successfully.

If I change network.trr.uri to "https://dns.google.com/experimental" and reload archive.is, then the page loads successfully.

Comment 1

[Franziskus Kiefer [:franziskus]]

Resolving https://archive.is with trr through CF gives me

> NS_ERROR_UNKNOWN_HOST: Component returned failure code: 0x804b001e (NS_ERROR_UNKNOWN_HOST) 

Manually querying CF DoH looks fine though.

> curl -H 'accept: application/dnjson' 'https://cloudflare-dns.com/dns-query?name=archive.is&type=A'
> {"Status": 0,"TC": false,"RD": true, "RA": true, "AD": false,"CD": false,"Question":[{"name": "archive.is.", "type": 1}],"Answer":[{"name": "archive.is.", "type": 5, "TTL": 300, "data": "no-ecs.archive.is."},{"name": "no-ecs.archive.is.", "type": 1, "TTL": 300, "data": "104.27.170.40"},{"name": "no-ecs.archive.is.", "type": 1, "TTL": 300, "data": "104.27.171.40"}]}

So this looks like a DoH or CF issue to me. Daniel, can you have a look at this?

Comment 2

[Daniel Stenberg [:bagder]]

I'll dig in!

Comment 3

[Daniel Stenberg [:bagder]]

CF responds with addresses just fine I think it does even in :cpeterson's case. The problem is that CF responds with IP addresses that are different than what Google returns and the CF ones don't seem to work!

Using my 'doh' tool [1]:

archive.is from https://mozilla.cloudflare-dns.com/dns-query
TTL: 26 seconds
A: 104.27.171.40
A: 104.27.170.40
CNAME: no-ecs.archive.is

archive.is from https://dns.google.com/experimental
TTL: 297 seconds
A: 213.202.222.45

curl 7.62.0 was released two days ago and has support for DoH and it too gets problems with archive.is that seems to be the same reason.

Skipping DoH and hitting the CF servers directly with curl reproduces the failure:

$ curl --resolve archive.is:443:104.27.171.40 https://archive.is/
* error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

I suspect the "no-ecs" CNAME is a clue. CF doesn't pass on client subnet so we probably get a "special" one via them that we don't get from the other resolvers that pass that on.

104.27.171.40 is, ironically enough, an IP that seems to be owned by CF... I'll reach out to them.

[1] = https://github.com/curl/doh

Comment 4

[Ekanan Ketunuti]

Ditto for both Chrome and Edge (using dnscrypt). CF is at fault definitely. 

Chrome:
> This site can’t provide a secure connection archive.is uses an unsupported protocol.
> ERR_SSL_VERSION_OR_CIPHER_MISMATCH
> Unsupported protocol
> The client and server don't support a common SSL protocol version or cipher suite.

Edge:
> Can’t connect securely to this page
> This might be because the site uses outdated or unsafe TLS security settings. 
> If this keeps happening, try contacting the website’s owner.

Comment 5

[Daniel Stenberg [:bagder]]

archive.is seems to do this on purpose: https://twitter.com/archiveis/status/1018691421182791680. They knowingly deliver a broken response to Cloudflare's queries. I personally think Cloudflare does the right thing to refuse ECS for privacy reasons.