[PLUG] Connecting to Multnomah County Library's ezproxy portal
Tyrell Jentink
tyrell at jentink.net
Mon Mar 15 03:56:00 UTC 2021
I have performed two more tests...
1) I fired up my CentOS Stream workstation... It does NOT have a problem
loading the page.
2) I fired up Fedora in a VirtualBox VM back on my laptop... It DOES work
when I put it on a bridged network, it does NOT work when I put it on a NAT
network. I tried disabling the Windows Defender Firewall, but that had no
effect.
Suggesting that it's a Windows NAT bug of some sort, I suppose - A bug that
only triggers in some very specific combination of transparent proxy on the
library side, firewall and NAT at the gateway, and the Windows firewall
itself... Maybe one introduced in a relatively recent Windows Update, as
this DID work for us a few weeks ago. It's gotta be a VERY specific bug,
cuz no one is writing about it online... None of the combinations of words
I have tried have brought up anything directly describing my problems.
I suppose I'm stuck advising my housemates to use VMs, VPNs, or alternative
network connections, and then cross my fingers and hope it works itself out
in a future Windows update... I had really hoped there was something
obvious I hadn't tried...
On Sun, Mar 14, 2021 at 6:51 PM Russell Senior <russell at personaltelco.net>
wrote:
> Have you tried a REAL linux? You could live-boot Ubuntu or something,
> which could eliminate windows as the problem. If you still have the
> problem, then it sort of narrows it down to your gateway device.
>
> On Sun, Mar 14, 2021 at 6:40 PM Tyrell Jentink <tyrell at jentink.net> wrote:
> >
> > 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
> > _______________________________________________
> > PLUG: https://pdxlinux.org
> > PLUG mailing list
> > PLUG at pdxlinux.org
> > http://lists.pdxlinux.org/mailman/listinfo/plug
> _______________________________________________
> PLUG: https://pdxlinux.org
> PLUG mailing list
> PLUG at pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>
--
Tyrell Jentink
tyrell.jentink.net
More information about the PLUG
mailing list