Describe the bug
When the Tracker encounters a READ_TIMEOUT error when scanning a domain it marks the domain as failing HTTPS, HSTS, Certificates, Protocols, Ciphers and Curves. This lowers the compliance summaries for an organization. READ_TIMEOUTs occur naturally on the internet. They reflect a general communications error between the Tracker server, its hosting network and the target network/domain. They do not indicate that the domain is not properly configured. In most cases, it is normal to retry a connection after a READ_TIMEOUT, up to a maximum number of times. It should not fail after the first READ_TIMEOUT. If after retrying a few times it still gets a READ_TIMEOUT it makes more sense to me to mark the untestable properties as unknown/information instead of failed.
Doing a manual rescan will generally correct the domain issues, but it does not increase the compliance summaries. Given the regular number of timeouts I am seeing in the tracker, I think this more likely points to a server/network issue with the tracker itself, but it appears on the site that our compliance is dropping.
To Reproduce
Steps to reproduce the behavior:
- Login to the Tracker
- Go to the Domains section
- Add a filter for HTTPS + EQUALS + FAIL
- Notice the domains that are failing
- Find a domain that was previously passing
- Click on the View Results button for that domain
- Notice the errors all stem from a READ_TIMEOUT error in the Tracker.
- Notice the Protocols, Cipher Suites, Curves, Certificate Chain sections are all blank and marked as Failed.
Expected behavior
A READ_TIMEOUT error on the Tracker side should not mark the domain as failing.
Screenshots
After a manual rescan
Desktop (please complete the following information):
- OS: Windows 11
- Browser Mozilla Firefox
- Version 134.0.2
Additional context
The Summaries tab of the Organization page does not update after a domain rescan. So it regularly shows a lower compliance score caused by READ_TIMEOUTs on the Tracker side.
Describe the bug
When the Tracker encounters a READ_TIMEOUT error when scanning a domain it marks the domain as failing HTTPS, HSTS, Certificates, Protocols, Ciphers and Curves. This lowers the compliance summaries for an organization. READ_TIMEOUTs occur naturally on the internet. They reflect a general communications error between the Tracker server, its hosting network and the target network/domain. They do not indicate that the domain is not properly configured. In most cases, it is normal to retry a connection after a READ_TIMEOUT, up to a maximum number of times. It should not fail after the first READ_TIMEOUT. If after retrying a few times it still gets a READ_TIMEOUT it makes more sense to me to mark the untestable properties as unknown/information instead of failed.
Doing a manual rescan will generally correct the domain issues, but it does not increase the compliance summaries. Given the regular number of timeouts I am seeing in the tracker, I think this more likely points to a server/network issue with the tracker itself, but it appears on the site that our compliance is dropping.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
A READ_TIMEOUT error on the Tracker side should not mark the domain as failing.
Screenshots
After a manual rescan
Desktop (please complete the following information):
Additional context
The Summaries tab of the Organization page does not update after a domain rescan. So it regularly shows a lower compliance score caused by READ_TIMEOUTs on the Tracker side.