Visibility and control of digital certificates remains a challenge for even the largest enterprises, as evidenced by a high profile incident this week affecting Microsoft’s LinkedIn. Users accessing LinkedIn on Tuesday got a warning from their browsers alerting them about an insecure connection. The culprit: An expired TLS certificate.

In a statement to the press, LinkedIn said it experienced a “brief delay” in updating a digital certificate, and stated that member data wasn’t affected. Yet, the incident spotlights a nagging issue that frequently trips even the most technically savvy companies in the world: Digital certificate management.

Qualys SSL Labs’ SSL Pulse, which monitors the quality of SSL/TLS support across 150,000 of the most popular websites in the world, rated about 33% of the sites monitored as having inadequate security in its May report. A few thousand of these sites had expired certificates.

Continue reading …

Recently new vulnerabilities like Zombie POODLE, GOLDENDOODLE, 0-Length OpenSSL and Sleeping POODLE were published for websites that use CBC (Cipher Block Chaining) block cipher modes. These vulnerabilities are applicable only if the server uses TLS 1.2 or TLS 1.1 or TLS 1.0 with CBC cipher modes.

Update May 30, 2019: The grade change described below is now live on https://www.ssllabs.com/

Continue reading …

Two QIDs will be marked as PCI Fail on May 1, 2019 as required by ASV Program Guide:

• QID 38601 “SSL/TLS Use of Weak RC4 Cipher”
• QID 42366 “SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Server Side Vulnerability (BEAST)”

Continue reading …

Update March 13, 2019: SSL Labs Renegotiation Test is re-enabled on the production instance.

Update March 12, 2019: SSL Labs Renegotiation Test is re-enabled on the development instance, and will be live on the production instance this week.

Update February 20, 2019: To give more time to fix, we will re-enable the SSL Labs Renegotiation Test on March 11, 2019 (two additional weeks).

The Apache Security Team fixed a bug which triggers whenever a client attempts renegotiation with Apache HTTP Server 2.4.37 and OpenSSL 1.1.1. This bug causes the Apache httpd service to consume 100% CPU. Details of the bug can be found at: https://bz.apache.org/bugzilla/show_bug.cgi?id=63052

Local testing by Qualys confirms that the SSL Labs renegotiation test triggers this bug for the above-mentioned server configuration, and can be used to cause the Apache httpd service on a target system to consume 100% CPU.

To allow Apache users time to apply the fix, SSL Labs has disabled the Renegotiation Test for one month, and we will re-enable it on February 25, 2019. While the test is disabled, users will not see the following in SSL Labs reports:

Acknowledgements

We would like to thank the Apache Security Team for working with us on this issue.

How many digital certificates are in use in your organization? When do they expire? Do you have a way of discovering digital certificates from unapproved Certificate Authorities?

Most organizations can’t answer these questions with complete certainty, because they lack the necessary visibility and control over their certificates. This creates the potential for security lapses, since SSL/TLS certificates are critical for the integrity and protection of a host of e-business functions.

With proper certificate management, organizations can cut their risk of breaches and unplanned outages, and continuously and effectively protect their digital assets, Asif Karel, a Qualys Director of Product Management, said recently during a webcast.

Since their creation in the mid-1990s, digital certificates have provided security for Internet traffic. They’re meant to ensure the confidentiality, authenticity, integrity and non-repudiation of online communications in public-facing online services, internal services, machine-to-machine communications, public cloud services and API integrations.

During his webcast, Karel outlined the current challenges organizations face with certificate visibility, and explained how Qualys can help with CertView, a free app available now.

Continue reading …

Update March 1, 2018: The completion of these changes is documented under Version 1.31.0 in the SSL Labs Changelog.

We are giving advance notification for following grading criteria changes applying from March 1, 2018: Not using forward secrecy, not using AEAD suites, and vulnerability to ROBOT. Update: This release also includes a grading change for some Symantec certificates.

Continue reading …

Earlier this month, after roughly six months of deliberation and planning, Google finalised their plans for staged deprecation of Symantec certificates. The process began in March 2017 when Google had announced on the Blink mailing list that they had lost confidence about Symantec’s certificate issuance policies and practices of recent years. The initial deprecation proposal was very strict and looked like it would completely paralyse Symantec, ending with limiting their certificates to validity time of less than one year.

Over time, however, a different solution emerged and Symantec agreed to handle operations of their PKI to some other CA, selecting DigiCert for the role. In return, Google agreed to a deprecation plan that will still be difficult for Symantec, but allows them to resume issuance normally afterwards. Mozilla carried out their own investigation and decided to match Google’s actions and dates. In the final twist, Symantec decided to sell their certificate business to DigiCert.

Continue reading …

This is the third post in my series on HPKP. In my first post I declared HPKP dead, and in my second post I explored the possibility of fixing it by introducing pin revocation. Today I will consider an entirely different approach to make HPKP much safer, by changing how it’s activated.

Continue reading …

Last year, almost exactly to the day, I declared HPKP effectively dead. I believed then—and I still do—that HPKP is too complex and too dangerous to be worth the effort. The biggest problem lies in the fact that there is no sufficient margin of safety; pinning failures are always catastrophic. That’s always bothered me and I wondered if it was possible to somehow fix HPKP without starting from scratch. That’s what this blog post is about.

If you haven’t already read my last year’s blog post, I suggest that you do so now as it will make the discussion easier to follow. I’ll wait for you patiently until you come back.

Today I am exploring the possibility of fixing HPKP with an introduction of pin revocation, which would be used in case of emergency. Please note that, even though I’ll be trying to save HPKP from a technical perspective, I am not necessarily declaring that HPKP is worth saving. The landscape of PKI had changed and today we have Certificate Transparency (CT), which addresses one set of problems that HPKP was supposed to solve, and also Certification Authority Authorization (CAA), which addresses another set of problems. One could argue that, between CT and CAA, there is perhaps not enough left for HPKP to do, given its complexities. I’ll leave that discussion for some other time. For now, let’s attempt the challenge of making HPKP more palatable. Continue reading …

We’re excited to share with you the first preview of our next-generation grading. This is something that’s long overdue but, due to lack of available time, we managed to keep up patching the first-generation grading to keep up with the times. Now, finally, we’re taking the next necessary steps to modernise how we grade servers based on our assessments.

Continue reading …