On Thu, Sep 23, 2021 at 9:34 AM Peter van Dijk <peter.van.d...@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@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
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
