Introduction
Reading a previous blog’s introduction, my partner made a wry comment about how surprising it was that the engineering team had been working hard again. I stand by this introduction, it is a fact that the team consistently work hard. This being August, and holiday season in the UK, some of the team have been on leave and therefore not working as much, but that’s allowed, and deserved.
Regardless, the Hexiosec engineering team have had another month of significant features, in this blog we will cover:
- New TLS version and cipher checks
- Updates to Hexiosec ASM CSP (Content Security Policy) checks
- Updates to security header checks
- Improvements to URL redirects on the web presence page
I’d also like to highlight that Lauren, Hexiosec’s Engineering Team Lead, and ASM Technical Lead, will be speaking at BSides Bristol on the 6th September in a talk entitled, Attacker’s Perspective: What Attack Surface Management Reveals About Your Organisation .
Lauren’s talk will be insightful for anyone, and particularly if you are interested in learning more about ASM and how it can help you stay ahead of the latest threats. If you are attending BSides please make sure you come along, and visit our Hexiosec stand.
New TLS Checks
To help users verify that TLS server configurations are secure we’ve expanded existing TLS certificate and server checks. Hexiosec ASM’s discovery now includes checks of the TLS versions supported by TLS servers, and the cipher suites they chose. Also, to bolster our TLS certificate checks, Hexiosec ASM will raise a new risk if an in-use TLS certificate has been revoked.
These TLS checks are available to all tiers of Hexiosec ASM, and will be included in any new scans or scans which have run since the 12th August 2025.
Why is the version of TLS important?
The TLS version largely determines the security functionality available when establishing encrypted connections to online services, such as when you use a web browser (e.g. Chrome) to view a website, the latest TLS versions being more secure. Because not all web browsers or other web clients support all version of TLS, servers will typically support multiple versions of TLS. During the initial TLS connection (referred to as a handshake), negotiation will chose the latest TLS version that both the web client and web server support.
The handshake will also negotiate the best cipher suite, which determines the encryption algorithms used for the encryption key exchange and message encryption.
TLS versions 1.2 and 1.3 are currently recognised as secure, and anything earlier are not secure and should be upgraded. Modern web browsers will normally block access to websites running TLS 1.1 or older, and display a warning message. This means a website could be at risk of both security and reputational damage if users can’t access it.
Why would you ever support TLS 1.1 or older then? In short, you shouldn’t, certainly not for a website. But legacy system may still need to support older versions of TLS if they need to accept connections from old software. In this scenario you should prioritise upgrading your legacy systems, whilst making sure you can also negotiate the latest TLS versions.
If you’re hosting your own TLS servers, or using hosting services, e.g. Cloudflare, check which versions of TLS it supports, and disable the legacy versions if they are not needed. Often these settings may be referred to as “Modern TLS”, meaning TLS 1.2 and 1.3. We have observed that some hosting services, Cloudflare again, enable old versions of TLS by default, so you may need to disable this. To be clear we do like Cloudflare, we use it ourselves.
Still not sure? Don’t worry, just let Hexiosec ASM run and go from there!
Where can I see the TLS results?
When exploring scan findings, the new TLS results include details on the discovered TLS servers, and potentially new TLS risks, if any discovered TLS servers have issues, such as using legacy TLS versions (e.g. TLS 1.0). We have included an annotation on our risks charts, to help you easily determine if a change in the discovered risks is due to these new features.
The Asset Management -> Services page includes a new ‘TLS’ column, which lists all the versions of TLS a server will support. The TLS version in bold is the version chosen during the TLS handshake, which is usually the latest version. The Services page includes a new ‘TLS Version’ filter, meaning you can filter for all TLS servers using specific versions, and help you isolate the servers which may be at risk.
From the Services page, you can use the go-to arrow to navigate to the Explore page for a specific service. This enables you to see more detail of the TLS version and the chosen cipher suite. The Explore page also shows the provenance of a service, helping you understand how it fits into the wider scan results.
The new risks you may see include:
- TLS services supporting vulnerable TLS versions
- TLS services supporting vulnerable TLS cipher suites
- A revoked TLS certificate, which is still in use
For the actions relating to these risks, there is a new “Remove Vulnerable TLS Protocols and Cipher Suite” action, and the revoked certificate risk would be included in any existing “Fix TLS Certificate and Renew” actions, which relate to the same domain or IP.
In future updates we’re planning to check for all cipher suites a TLS server supports, so watch this space for that update.
New CSP check: report-to endpoint undefined
Hexiosec ASM now includes a new CSP check. The report-to directive is deprecated and is being replaced with the Reporting-Endpoints HTTP response header. But if report-to is found Hexiosec ASM will check that the endpoint specified is included in a corresponding Reporting-Endpoints header, if it is not, a new low severity risk is raised, “Content Security Policy: Report To Endpoint Undefined”
You can learn more about CSPs by reading Geoff’s practical Content Security Policy implementation guide.
Existing check modified: X-Frame-Options header missing
Hexiosec ASM now raises a risk when the X-Frame-Options header is absent or set to the deprecated ALLOW-FROM value. If the Content-Security-Policy header includes frame-ancestors, the missing X-Frame-Options is not reported, as frame-ancestors offers equal or stronger clickjacking protection. Without either control, the site may be vulnerable to clickjacking via iframe embedding.
Multiple redirect chains on Web Presence page
We’ve improved our display of redirects on the popular Web Presence page. The Web Presence page now shows where a page has multiple redirects coming into it, and each of these branches in a revised visualisation.
In the example image below you can see that there are 3 different 301 (server-side) redirects, which all take you to the website displayed on the Web Presence page.
We’ve updated the ‘Sources’ filter on this page, to include the services hosting redirects. Both these updates help you understand your webpage hosting, and provide an improved experience when following links to the Web Presence page.
Coming Soon
New features for you to look out for, include some changes to our public API and checks relating to subdomain takeovers:
- New Changes endpoint on the public API: To provide the type of data already available from the Changes page.
- New checks for domains at risk of takeover: To help with brand protection.
Related Posts
