Does Qualys SSL Server test will make this "extended Master secret" TLS extension mandatory to get A+ grade?
SSL Labs currently doesn't even check it. We need out-of-the-box support first. Last week I tried to patch LibreSSL, it obviously failed.
I see that Qualys has engineered a QID overnight 13607 for "Host is vulnerable to Extended Master Secret TLS Extension (TLS triple handshake) and marks it as a potential, with no clue as to how it discovered the bug other than to say "Host XYZ is vulnerable to TLS tripe handshake".
This is in reaction to a 10 year old CVE ??? CVE -CVE-2009-3555
I don't know what to make of this. the only other QIDs for sample assets don't show any indication that Qualys has analysed TLS other than to identify that port 443 is open.
i've raised a ticket on this one, it's being seen on numerous occasions with little to suggest a true-positive.
Did Qualys respond to your ticket?
Engineering is checking it Joe. Regards
Thanks Tony. If you can, please let us know what Qualys says once they respond. We're having trouble figuring out what do with this one also.
I also have a ticket open with Qualys on this. The doc on the QID has changed and now removed CVE-2009-3555 as the primary CVE and only lists it as "reminiscent of [...] CVE-2009-3555" in a description with no direct replacement CVE to identify it. The initial response I got from support said they released an update to the detection in the last few days, but I'm not able to scan again for a few days to see if it fixed the issue. I requested an ETA on when the QID detection and documentation are expected to be stable.
Hi Kyle, update from support;
"QID 13607 is designed for detection of servers without support for the RFC7627 and therefore potentially vulnerable to the TLS Triple Handshake Attack (CVE-2015-6112). It attempts to negotiate using each relevant protocol version (TLSv1, TLSv1.1, and TLSv1.2) advertising a comprehensive set of ciphers and the TLS Extended Master Secret Extension. Servers not responding with support for this extension are considered potentially vulnerable.
This QID was released 11/21/2019 per customer request which is why you are seeing this QID now. Given the vulnerability's possible attack vector it is not possible for us to fully detect whether or not a target is vulnerable which is why the QID is marked as "potential". Internal testing will be required to determine if a targeted host is truly vulnerable.
A query does exist to filter out certain assets that should not be vulnerable based on the results of QID 38706. If the Extended Master Secret is set to "Required" this would point to the target not being vulnerable for QID 13607.
Here is the query I am referencing: VULN[./QID/text()="38706" and contains(./RESULT,"Extended Master Secret required")"
My response back was that if Qualys can probe the situation with QID 38706, then why can't it make the case for 13607 being true or not, why should it be up to us to prove this out?
Tony, I absolutely agree. I'm not sure what language that query is written in, but I have had a massive amount of customers start seeing this potential vulnerability on their reports recently and they are currently seeking answers due to the unhelpful nature of the explanation and solution provided. Please keep us posted about Qualys's responses, as I am getting the feeling that their support is probably overrun right now with questions about this issue. And the longer Qualys makes us wait, the longer I am making my customers wait...
Our certificate security engineering team is investigating this as well.
Latest update from support -- they have downgraded the CVSS Base score, so it's no longer a PCI fail. The update to CVSS Base hasn't shown up in the PCI module yet, so still waiting. We also haven't rescanned yet to see if the updated detection logic makes it detect less false positives. I will update once we have rescanned to see if the updated detection logic has made a difference.
What score was it downgraded to? In the KB entry for 13607 it says:
Based on the security impact of this vulnerability. Downgrade this QID from Severity 4 to Severity 3.
And severity is 3 in the PCI scanning module, and it's also a fail in the module. So it was downgraded from 4 to 3 and its still a failure. Are you sure it's no longer a failure?
The response form support, specifically, was "The PCI flag has also been removed as multiple customers were being affected by the QID failing PCI scans."
I separately noticed that the CVSS Base score was modified from a 4.3 to a 2.7; it wasn't noted in the change log. When it was a 4.3, the QID doc said it was a PCI fail -- "The QID adheres to the PCI requirements based on the CVSS basescore[sic]". After the change to 2.7, it no longer says it is a PCI fail. Support did say when I asked that I would have to rescan for the PCI status of the vuln against my assets to change though.
i don't get the detection logic of this at all, and have asked Qualys support to close #736886 as i can't impress upon them how if QID 13607 can see "Extended Master Secret" Yes/no, why the issue can't be confirmed or not.
A rescan in PCI module updated the risk and removed the "fail" status of this vuln. However, it is still detected everywhere it was before, so their update to detection logic did not help. I've closed my support ticket, as the removal of the CVE and the lowered risk ranking relegates this to a "potential" low-risk vuln. However, I view the QID as faulty and the documentation is still low-quality and inconsistent. (It still references the fix as an OpenSSL doc page that talks about a parameter, that appears to be secure by default, and takes effort to do the thing the QID thinks is wrong.) It's falsely showing numerous OpenSSL and some Windows systems are vulnerable that are not.
Completely agree Kyle
Thanks for the research on this. Just my two cents on the question regarding why Qualys can't confirm QID 13607 with same test as QID 38706. It appears that QID 38706 checks for a number of different TLS settings, of which the Extended Master Secret is only one. Therefore, one way to determine whether a device/endpoint is vulnerable to QID 13607 would be to scan the device, view the Results information for QID 38706, and look for the Extended Master Secret setting (should be yes or no). If yes, then the device is not vulnerable to QID 13607, if not, then it is. I welcome comments if anyone thinks this is incorrect.
I also requested additional info based on QID 13607. I got this response:
>> QID 13607 Host is Vulnerable to Extended Master Secret TLS Extension (TLS triple handshake) This is a potential vulnerability. Potential Vulnerabilities include vulnerabilities that cannot be fully verified. In these cases, at least one necessary condition for the vulnerability is detected. It's recommended that you investigate these vulnerabilities further
>> QID 13607 has “remote check” identification mechanism which means that QID will be flagged on the bases of response received by host machine.
Threat The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same.
Note: this attacks are reminiscent of the renegotiation attacks of 2009 [Ray, Rex] (CVE-2009-3555).
QID Detection Logic(Un-Authenticated):
This QID checks for web response coming from vulnerable host.
>> To identify if the QID is a false positive, you can follow the below steps. https://github.com/Tripwire-VERT/TLS_Extended_Master_Checker Once you identify the QID as false positive, you can follow below and exclude them. >> https://qualys-secure.force.com/customers/articles/Knowledge/000001833
I requested them to add it to there tests if there is a way the confirm this. What's the use of automated tests if you push out a bunch of maybe's.
So how does one enable support for extended master secret? Is it a directive in the Apache/IIS config files for SSL? A built-in setting inside the OpenSSL binaries? I'm not sure what to tell clients when they ask me how to fix this, or even to confirm or deny they are actually vulnerable.
I did find a Python script that seems to help determine vulnerability status. GitHub - Tripwire-VERT/TLS_Extended_Master_Checker: Detection for RFC7627 Support (TLS Extended Master Secret Extension)
I found that general HTTPS sites are not affected by this vulnerability.
the described attacks affect sites and services using client certificates or channel binding for authentication. This means that typical HTTPS sites and most other TLS protected services are unaffected,
Retrieving data ...