[PLUG] Connecting to Multnomah County Library's ezproxy portal

Tyrell Jentink tyrell at jentink.net
Mon Mar 15 01:40:16 UTC 2021


OK, I have tried a couple more things, and have more symptoms:

First, I tried using the upstream "curl for windows" (instead of the one in
cygwin), and got a more familiar output, but no new success:
>
> *   Trying 205.173.218.15:443...
> * 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: C:\Users\tyrell.WIN\Downloads\curl-7.75.0_4-win64-mingw
> (1)\curl-7.75.0-win64-mingw\bin\curl-ca-bundle.crt
> *  CApath: none
> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> * Operation timed out after 300250 milliseconds with 0 out of 0 bytes
> received
> * Closing connection 0
> curl: (28) Operation timed out after 300250 milliseconds with 0 out of 0
> bytes received
>

Then, just out of curiosity, I installed Firefox on Fedora for WSL (And
opened up Cygwin-X), opened  https://proxy.multcolib.org/login, and it
loaded just fine...  So now I suspect it's a Windows problem after all -
Maybe a specific Windows-with-Ubiquiti problem...  But I don't even know
what to call this error to search for it...

To review:

   - On Windows directly, I can ping proxy.multcolib.org, but I can't
   complete a TLS handshake in a browser (I tried Firefox, Chrome, and Edge)
   or in curl (I tried both the Cygwin version of curl as well as the upstream
   "Official curl for Windows" version)
   - However, on Windows Subsystem for Linux, I am able to ping
   proxy.multcolib.org and I can curl the page
   https://proxy.multcolib.org/login from either Ubuntu or Fedora;
   Additionally, on Firefox on Fedora on WSL, I can load the page in a
   browser.
   - This is the same laptop... So the same physical network card, the same
   physical network, the same VLAN... It SHOULD even be the Windows driver
   talking to the hardware...
   - My Ubiquiti firewall isn't logging any dropped packets when I tell it
   to log "Invalid State" packets... So it wouldn't SEEM to be Ubiquiti...
   - It COULD be Windows? It seems to be affecting ALL of our Windows
   laptops...  But Windows is ONLY having problems with this one site...
   - AND, Windows isn't having problems at all when it's direct connected
   to the internet, either directly to the Ziply WAN cable or through my
   Android phone's hotspot...
   - Android seemed to initially have some very similar problems as well,
   but as soon as the page loads over Mobile, it caches whatever is failing,
   so the failure becomes unproducable after just one success...

I remain at a total loss...  This just doesn't make sense to me...

On Sun, Mar 14, 2021 at 1:09 PM Tyrell Jentink <tyrell at jentink.net> wrote:

> 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
>
>

-- 
Tyrell Jentink
tyrell.jentink.net



More information about the PLUG mailing list