Slow Initial Connection in Vivaldi v6 (for internal web sites only)
-
@czvacko said in Slow Initial Connection in Vivaldi v6 (for internal web sites only):
When I open any HTTPS intranet page, there is a 15s delay in loading such page.
A possible cause is that Vivaldi, as opposed to certain other browsers, checks online revocation data (CRLs and OCSP) if that is specified in the certificate. Normally that is a less than 1 second operation, but if the server is unreachable or there is a DNS failure, then it will take a while to detect those failures.
If that is what is happening, then the likely underlying cause is that this was not caused by any upgrade of Vivaldi (after all, we have been doing these checks since pre-1.0), but that the update coincided with your sysadmins changing the certificates somehow, e.g. adding CRL/OCSP information, but not configuring the servers needed for that information. Only inspecting the certificates for the sites will determine what happened.
-
checks online revocation data
Was this checked also in earlier versions before v6 ?
And from where does he check them?Me, as it head of our branch, have implemented some of the affected system. For example grafana, I put the appropriate pfx certificate inside there years ago and it hasn't changed since. The whole certificate chain should be valid, but the root certificate is issued by an internal CA (is properly inserted into the cetrification store), can this have an influence ?
Vivaldi is installed as a standalone, so in an identical OS I can easily switch between v5 and v6, only v6 has a problem. Therefore I suspect some changes in v6.
-
@czvacko As I said above, online OCSP/CRL validation, based on querying servers and URLs embedded in the certificates, has been performed since before 1.0, if fact since before the very first Technology Preview of Vivaldi. It is not remotely new.
Public CAs are required to have those URLs embedded in their certificates. Company internal CAs aren't but they may conceivably be using software that does so automatically.
There has also been a number of changes in Chromium the past couple of years regarding certificate processing (including that the main rootstore is now part of our configuration and source code, and the Chromium source is doing all certificate processing and verification inside Chromium/Vivaldi, not using OS APIs), and that may also have had an impact.
My suggestion would be to use a tool like Wireshark to see what exactly happens at the network level, unless inspecting the site certificate and its chain (Especially the AIA, OCSP, and CRL fields) turns up a likely source of the problem.
-
@czvacko The 15s sounds like a general connect timeout.
To troubleshoot network issues you can use:
- Devtools - Network. Should be able to at least see what the browser tries to connect to and times out.
chrome://net-export
- Logs a detailed network log that can be examined. Needs some (lots?) networking knowledge to read these logs and actually understand what goes on.- Wireshark would work too of course, but requires even more networking knowledge to understand.
-
@yngve The main issue here in my personal case Is that this happen on my work machine and my home machine (windows and MacOS), both are in different networks from different isp provider, other browsers chrome base seems to work well in both machines, and is the same behavior that other users are reporting (Vivaldi took as long 15 second to load some websites) so this is something that is happening by different user in Vivaldi.
-
@JoshKauff Your post on the top say it applies to accessing intranet pages, and if that happens both from office and home (via VPN) that suggests a general problem with the network.
I still suspect that the certificates for your internal servers have added revocation URLs in the past year, and that there are problems with that/those servers (ranging from a DNS problem to the server actually existing but not responding).
As this is an internal network we can't do any inspection ourselved.
-
@yngve No, no, that was the OP, in my case this issue is on normal web browsing, no intranet or VPN use.
-
@JoshKauff Apologies, didn't notice that difference.
As far as your report is concerned, it sounds like you have enabled DNS over HTTPS (DoH) to work around the issue; which again suggest a DNS problem with the ISP/network provider (could just be slow, or it could be responding with obsolete, expired data). (IOW; your problem does not seem to have been the "same" as the OP's)
Note that changing the DNS to an external server will not work for DNS resolving intranet hosts.
-
@yngve
As recommended, I tried to capture the packets using Microsoft Network Monitor.
It seems to confirm your statement about "online OCSP/CRL validation", there are packets where destination is the URL specified in the certificate for the HTTPS site (note: the URL is ***.com resolved by the internal DNS server to the internal IP).
The captured packets show several retransmits to the destination, as I understand, retransmits usually mean that the packets were lost/dropped somewhere (checking with HQ). It seems that 4 retransmits were made for the original packet(s) before the browser gave up after 15s (that match with my observation).
If you say that validation is done from the early version, maybe it is done by a different way in v6 ? How is it implemented now and how was it in the past ?
Do validation:
-only first time when open related URL ?
-after some fixed time ?
-after some inactivity time ?
-or ? -
@czvacko said in Slow Initial Connection in Vivaldi v6 (for internal web sites only):
If you say that validation is done from the early version, maybe it is done by a different way in v6 ? How is it implemented now and how was it in the past ?
All this functionality is handled by Chromium's SSL/TLS system, and I know that Chromium have been changing how certificate are handled for the past year, plus, including how the rootstore is handled. Those changes may have affected how the revocation system works.
Our change was essentially: "Enable this system" (It is not enabled by default in Chrome, we think it should be checked, since the system Chrome uses is both delayed, and does not cover all CAs or revoked certs).
Revocation validation will occur when there is a new handshake, and there is no currently valid record already cached. If there is no response, which is what it sounds like, then that is something your sysadmins have not configured. As such, they should then either reissue the certificates, without revocation information, or enable the revocation server(s).
New handshakes for the same server happens when the server expires the current TLS Session record, and it sounds like your servers have a relatively short Session lifespan.
-
@yngve said in Slow Initial Connection in Vivaldi v6 (for internal web sites only):
enable the revocation server(s)
Yes, our HQ sysadmins just did that (closed it by mistake), now the problem is gone. Thanks for pointing me in the right direction.
Enable this system [in Vivaldi]
For future debugging purposes, is there any way for the user to disable this?
-
@czvacko said in Slow Initial Connection in Vivaldi v6 (for internal web sites only):
For future debugging purposes, is there any way for the user to disable this?
It is deep in the policy section, not an ordinary prefs, but policies can IIRC be modified by adding relevant registry entries (on Windows, at least); fairly advanced stuff, intended for enterprise policies.