[dns-operations] Oddness with Cloudfare authoritative servers

Thu Sep 23 18:35:45 UTC 2021

On Thu, Sep 23, 2021 at 9:34 AM Peter van Dijk <peter.van.dijk at powerdns.com>
wrote:

> On Wed, 2021-09-22 at 20:13 -0400, Warren Kumari wrote:
> > Oh, testing now gives a different / working result:
> >
> > $ curl -v https://www.deltamath.com --connect-to deltamath.com:443:172.64.80.1
> 2>&1 | grep "HTTP/2 200"
> >
>
> This one sends a Server Name Indication of www.deltamath.com (like with
> 'openssl s_client -connect 172.64.80.1:443 -servername deltapath.com').
>
> >
> > > Yes, 172.64.80.1 is a CF address, but it was being returned for
> deltamath.com.
> > > Doing a GET / over TLS with the host set to deltamath.com  was giving
> a 403 Forbidden:
> > > HTTP/1.1 403 Forbidden
>
> This one is reproducible by not sending an SNI (like with 'openssl
> s_client -connect 172.64.80.1:443').
>
> As far as I can tell -right now-, the IP is entirely valid for the
> site, as long as the client sends the correct SNI and Host header
> (which web browsers do!).
>

Hah! That explains at least some of my testing issues.
When I was testing this issue it was from a machine without curl -- and so
I used openssl and manually typed the HTTP, I didn't include -servername:
$ echo -e "GET / HTTP/1.1\r\nHost:deltamath.com\r\n\r\n" | openssl 2>&1
s_client -quiet -connect 172.64.80.1:443
depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust
Root
verify return:1
depth=1 C = US, O = "Cloudflare, Inc.", CN = Cloudflare Inc ECC CA-3
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.",
CN = sni.cloudflaressl.com
verify return:1
HTTP/1.1 403 Forbidden
Server: cloudflare
Date: Wed, 22 Sep 2021 18:36:57 GMT
Content-Type: text/html
Content-Length: 151
Connection: keep-alive
CF-RAY: 692da44bb84eeb39-LAX

<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
<hr><center>cloudflare</center>
</body>
</html>
^C

This gave a different result to testing against the other addresses, which
just error out:
$ echo -e "GET / HTTP/1.1\r\nHost:deltamath.com\r\n\r\n" | openssl 2>&1
s_client -quiet -connect 104.26.2.229:443
140607395013952:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert
handshake failure:../ssl/record/rec_layer_s3.c:1544:SSL alert number 40

I didn't really bother wondering *why* the "working" ones were giving me an
SSL failure though.

Adding '-servername deltamath.com' does at least fix that, but now I've
made CF sufficiently grumpy by sending odd requests that it's popping up a
CAPTCHA :-)

Whatever the case, the fact that William was experiencing issues when this
particular address was returned, and it seems to be the only one that
responds in this way when no SNI is provided is, um, interesting. Perhaps
whatever his customer was using isn't a web browser, or is really old, or
(being part of a school system) passes through some sort of interception
proxy which doesn't interact well, or...

W

>
> Kind regards,
> --
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20210923/a0da08f7/attachment.html>