Thank you Crystal for not only your time, effort, and assistance but
also for this amazing comprehensive summary. I very much appreciate
your help.
I agree that at this point the effort to resolve the issue would seem to
surpass the any benefit that we could expect especially since I seem to
be the only one facing this problem.
Perhaps if someone else incurs a similar issue at some point their
experience, along with mine, will assist in diagnosing the root cause.
For now let's mark this issue as unresolved but on hiatus.
Once again, thanks to all who have provided meaningful assistance, your
time and effort is greatly appreciated.
I hope everyone has a great day.
On 2022-09-20 05:53, Crystal Kolipe wrote:
On Tue, Sep 20, 2022 at 01:04:01PM +0100, Stuart Henderson wrote:
On 2022/09/20 05:00, Alton Shaw wrote:
Thanks for the suggestion Mikhail.
Early on I had tried Chromium with the same result which I find very curious
as I don't believe they share any code. So I was thinking it was something
in how OpenBSD passed browser traffic to the web. But at Crystal's
suggestion I also gave Surf a go and it was the only browser that
consistently worked with the bank's website so I at least have a work around
should Firefox start acting up again.
Also be aware that the bank or their service provider/s may be changing
things while you are testing, also that they may direct different connections
to different backend servers which might be configured differently.
So things might change even if you do nothing different other than
get different sessions with the bank's website.
He does seem to have had fairly consistent results with each configuration,
though.
So if there are indeed two or more clusters of servers at the bank which are
configured differently, I don't think that he is just connecting to them
randomly in a round-robin fashion. Rather, a particular client,
(surf, firefox, etc), is for some reason connecting to a pool with a
particular config. This may be due to subtle differences in the connections
at the IP level, E.G. re-using an existing connection, using different
source ports, number of concurrent connections, etc, etc.
The error message that is displayed about the bank having technical issues
and to try again later, is NOT coming from the server as a response to the
login request. It's pre-stored somewhere within the Javascript login code.
You can test this without an account at the bank and with any browser that
is known to work - load the login page, and attempt to log in as user 'foobar'
with password 'foobar'. You should see a error message saying that they
were expecting something different, (I.E. username or password invalid, but
we're not saying which).
If you disconnect from the network before hitting the login button, (remove
the LAN cable, or adjust the firewall settings on your local firewall to
block traffic to your workstation), then you will see the, "sorry we're
having technical difficulties" message.
So, this message appears as a generic error when there is a failure of
communication between the javascript-based login code, and the remote server.
This explains why the bank rep that he spoke to said that they couldn't see
any sign of an attempted login.
It also strongly suggests that the problem does not lie with a mis-configured
user-agent, nor with cookies, because the problem is at a lower level than
that.
The fact that Surf works pretty much confirms that the bank doesn't care much
about the user-agent, because Surf's default user agent is something like:
Mozilla/5.0 (X11; Linux x86_64; OpenBSD amd64) AppleWebKit/605.1.15 (KHTML, like
Gecko) Version/15.0 Safari/605.1.15 Surf/2.1"
So it clearly announces itself as being Surf on OpenBSD, but otherwise looks
like a regular modern UA string to any sensible huristics on the server.
Since Surf works and Firefox and Chromium don't, I suggested off-list that he
tried disabling http/2, as Surf does not support http/2, and this was one
obvious difference between it and the browsers which do not work. However, it
turns out not to be the issue.
The bank seems to be IPv4 only, with no AAAA records for secure.royalbank.com,
although some other domain that the javascript login code connects to might
plausibly have IPv6 connectivity. If one browser is connecting over IPv4 only
and another via IPv6, that might cause the issue he is seeing, but I don't
think that that is the issue here.
He says that Firefox running on OpenBSD within a VM in virtualbox running on
an Ubuntu host works 50% of the time, whereas it works 0% of the time running
the same configuration of Firefox on OpenBSD on the bare hardware. This
suggests to me that some low-level manipulation of the packets at the IP layer
is happening as they traverse the VM hypervisor and head out via the Linux
networking stack, mitigating a packet-loss issue that is present in the
native OpenBSD installation.
Although the problem has now disappeared, it could easily return since we
don't know what caused it in the first place.
Unfortunately, further investigation would probably require analysing the
network traffic to and from the client, as well as understanding the large
lump of javascript that runs the whole affair.
At this point, without any co-operation from the bank, the effort of debugging
it rather exceeds the satisfaction gained from doing so.
There is an issue somewhere, though, and whether it's in OpenBSD or somewhere
else, it would be nice to fix it.