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.
