OK, I'm simply trying to log in to view historical Oregonian articles, at the resource listed here: https://multcolib.org/resource/historical-oregonian-1861-1987 Specifically, the link goes to https://proxy.multcolib.org, and there in lies my problems.
The below detailed tests were conducted on my laptop, which is running WSL on Windows 10, but the problems were first noticed on a different Windows computer... I SUPPOSE it's possible these problems are Windows-only? But I don't think the evidence is suggesting that... I'm using a Ubiquiti Dream Machine as my router and firewall; It's running Linux and IPTables "Under The Hood," but it abstracts everything into a web GUI. It *SEEMS* like my Ubiquiti firewall is detecting certain TLS handshakes as "invalid state," but that doesn't make sense, does it? First, I seem to have no problem loading https://proxy.multcolib.org on my phone using the mobile network, so I conclude there is no problem on THEIR side... But I can't load that page same page on my phone on WiFi, so I am fairly certain it's not an OS specific problem, either... (However, once the page is cached, it reloads just fine regardless of connection... Does the TLS handshake get cached somehow? As some critical bit *IS* getting cached, and flushing the cache on phones is less simple than on a PC, reproducing results on phones is hit-or-miss) Second, I seem to have no problem loading https://proxy.multcolib.org on my laptop when it's connected to my phone's hotspot, or even when plugged directly into my Ziply internet... My laptop is running Windows, further supporting the hypothesis that it's not OS dependent. However, it won't load over my WiFi, so I suppose we are narrowing it to my router and firewall... I don't have any drop rules in the firewall, aside from the default "Drop Invalid State" rule... But here's where it gets weird... I CAN ping the URL from any host I have tried it, so it's not blocking the path outright... I can also curl the page from curl on Fedora on WSL and curl on Ubuntu on WSL, but NOT curl on Cygwin... Running them verbosely, I get nearly identical successful logs from Fedora and Ubuntu, but Cygwin seems to use different cryptography libraries, or otherwise spits out different messages... I garner though, that it's successfully connecting to the server before failing the handshake... curl on cygwin's output looks like: * Connected to proxy.multcolib.org (205.173.218.15) port 443 (#0) > * schannel: SSL/TLS connection with proxy.multcolib.org port 443 (step > 1/3) > * schannel: checking server certificate revocation > * schannel: sending initial handshake data: sending 190 bytes... > * schannel: sent initial handshake data: sent 190 bytes > * schannel: SSL/TLS connection with proxy.multcolib.org port 443 (step > 2/3) > * schannel: failed to receive handshake, need more data > * schannel: SSL/TLS connection with proxy.multcolib.org port 443 (step > 2/3) > * schannel: encrypted data got 1460 > * schannel: encrypted data buffer: offset 1460 length 4096 > * schannel: encrypted data length: 1394 > * schannel: encrypted data buffer: offset 1394 length 4096 > * schannel: received incomplete message, need more data Meanwhile, curl on Fedora on WSL is reporting: * Connected to proxy.multcolib.org (205.173.218.15) port 443 (#0) > * ALPN, offering h2 > * ALPN, offering http/1.1 > * successfully set certificate verify locations: > * CAfile: /etc/ssl/certs/ca-certificates.crt > CApath: /etc/ssl/certs > * TLSv1.3 (OUT), TLS handshake, Client hello (1): > * TLSv1.3 (IN), TLS handshake, Server hello (2): > * TLSv1.2 (IN), TLS handshake, Certificate (11): > * TLSv1.2 (IN), TLS handshake, Server key exchange (12): > * TLSv1.2 (IN), TLS handshake, Server finished (14): > * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): > * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): > * TLSv1.2 (OUT), TLS handshake, Finished (20): > * TLSv1.2 (IN), TLS handshake, Finished (20): > * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 > * ALPN, server did not agree to a protocol > * Server certificate: > * subject: C=US; ST=Oregon; L=Portland; O=Multnomah County; CN=*. > proxy.multcolib.org > * start date: Sep 20 23:16:28 2019 GMT > * expire date: Sep 20 23:16:28 2021 GMT > * subjectAltName: host "proxy.multcolib.org" matched cert's " > proxy.multcolib.org" > * issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU= > http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate > Authority - G2 > * SSL certificate verify ok. I can't imagine a firewall configuration that would allow the connection under WSL but would refuse it in the parent Windows system... And yet I can't deny that the evidence does suggest that it works everywhere not protected by my firewall... SO, on to the firewall: I'm using a Ubiquiti Dream Machine (UDM). I have a bunch of VLANs, one of which is isolated from the LAN and provides a direct connection to the internet, without my local DNS messing with things... Lots of firewall rules exist to bridge the local VLANs together, and to prevent any of them from accessing the isolated VLAN... But the observed problems exist on both the "regular" LAN and that isolated LAN... So I suspect it's an inbound WAN rule? But I don't have any inbound WAN rules, just the defaults... I did get it to work for a bit last night by adding a higher priority "Allow All" rule, possibly set to match only "Invalid" states... But I was wholly uncomfortable with that approach, and removed the rule... This morning, I was unable to reproduce that success... Which is too bad, as I would have liked to try "Allowing All" from just the libary's IP... Anyway... Conclusion, when connected to my home LAN, I can access The Entire Internet, but not this Multnomah County Library resource... It fails TLS handshake... But it works just fine in curl on WSL. What gives? I'm more than willing to redo any tests anyone might suggest... This is striking me as magnificantly weird. -- Tyrell Jentink tyrell.jentink.net _______________________________________________ PLUG: https://pdxlinux.org PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
