You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: