PKI Consortium blog

2015 – Looking Back, Moving Forward
January 6, 2015 by Bruce Morton (Entrust) Apple Attack CA/Browser Forum CAA Chrome Code Signing EV Firefox Forward Secrecy Google IETF Malware Microsoft MITM Mozilla OpenSSL PKI Policy RSA SHA1 SSL 3.0 SSL/TLS TLS 1.0 TLS 1.2 TLS 1.3 Vulnerability

Looking Back at 2014

End of 1024-Bit Security

In 2014, the SSL industry moved to issuing a minimum security of 2048-bit RSA certificates. Keys smaller than 2048 are no longer allowed in server certificates. In addition, Microsoft and Mozilla started to remove 1024-bit roots from their certificate stores. Hopefully, the key size change will support users through to 2030.

What To Do When You Rely on Internal Names in TLS/SSL Certificates
July 18, 2014 by Wayne Thayer Attack CA/Browser Forum Firefox IANA ICANN Microsoft MITM Qualified SSL/TLS

A deadline set by the CA/Browser Forum for the use of Internal Names is quickly approaching, and many system administrators need to understand how best to adapt to this change. At the same time, hundreds of new top-level domains are being launched, which redefines what constitutes an Internal Name. In this post we’ll explain what the changes are, why they’re being made, and how you can update your systems in response to the problem.

Certificate Reputation
March 28, 2014 by Bruce Morton (Entrust) Microsoft MITM OCSP PKI SSL/TLS

One of the advantages of having multiple certification authorities (CAs) from which to choose an SSL certificate is that customers have flexibility to choose a CA that meets their specific needs, or even use a number of CAs for redundancy or to have access to a broader toolset. The disadvantage for end users, however, is that they often may not know if a particular CA was authorized to issue the certificate, and there could be a chance that the certificate was fraudulently obtained.

Bogus SSL Certificates
February 20, 2014 by Bruce Morton (Entrust) Attack Google MITM SSL/TLS

Netcraft has published an article stating they have found many bogus SSL certificates. In this case, a bogus certificate is self-signed (i.e., not issued from a legitimate certification authority) and replicates an SSL certificate of a large, popular website.

This type of bogus SSL certificate could be used for a man-in-the-middle (MITM) attack. In this scenario, the attacker needs to gain a position that will allow them to intercept traffic and make you to go to their site instead of the real site. This is more likely for public Wi-Fi networks that allow connectivity in airports, cafes and hotels.

Intermediate CA Certificates and Their Potential For Misuse For Man-In-The-Middle Attacks
January 9, 2014 by Robin Alden (Sectigo) Attack Firefox Google MITM Policy Root Program SSL/TLS Vulnerability

We have seen recently that Google detected that publicly trusted TLS/(SSL) certificates had been created for Google domains without having been requested by Google themselves.

The existence of such certificates might usually be taken as an indication of misissuance by the issuing CA (i.e. a failure or mistake by the CA which allowed the issuance of an end-entity certificate otherwise than in accordance with their policy) or as an indication of compromise of the issuing CA.

2014 – Looking Back, Moving Forward
January 6, 2014 by Bruce Morton (Entrust) Attack BEAST CA/Browser Forum CAA Code Signing ECC Encryption Forward Secrecy HSTS ICANN IETF Microsoft MITM Mozilla PKI Policy RC4 RSA SHA1 SSL/TLS TLS 1.2

Looking Back at 2013

Protocol Attacks

The year started with a couple of SSL/TLS protocol attacks: Lucky Thirteen and RC4 attack. Lucky Thirteen allows the decryption of sensitive information, such as passwords and cookies, when using the CBC-mode cipher suite. Lucky Thirteen can be mitigated by implementing software patches or preferring the cipher suite RC4.

ICANN’s Accelerated gTLD Delegation Process and How This Impacts Your Organization
December 18, 2013 by Jeremy Rowley Announcement CA/Browser Forum CASC ICANN MITM Mozilla PKI Policy Qualified Revocation SSL/TLS Vulnerability

After the CASC’s previous letter addressing ICANN’s proposal to delegate nearly 2000 new gTLDs for use on the public Internet, ICANN identified and initiated an extensive study on two significant security issues. Now, based on the conclusions of the studies, ICANN is moving forward quickly with the delegation process, delegating more than 30 in the last two months alone. With ICANN ramping up the delegation process, nearly all 2000 will be delegated under the new rules, with only .corp and .home reserved as high risk gTLDs. This post serves as an advisory for interested network administrator on how the newest ICANN decisions may affect their networks and certificates.

Getting the Most Out of SSL Part 3: Optimization
July 29, 2013 by Rick Andrews, Ryan Hurst MITM Mixed Content SSL/TLS

To get the most out of SSL/TLS, you need to do a bit more than just configure your web server with an SSL certificate. The information below will help you optimize your website’s use of SSL. Making the changes suggested below will also help move your site towards “Always On SSL” (https://otalliance.org/resources/AOSSL/index.html), a best practice in which you serve the entire contents of your website over SSL/TLS.

Changes to the content of your website

Some HTML tags can include attributes that are links or paths to other pages on your site. These paths can be absolute (explicitly referencing a protocol and domain name, like href=”http://foo.example.com/index.htm” or src=”https://foo.example.com/script.js”) or relative (like href=”/index.htm” or src=”/script.js”).

The Importance of Checking for Certificate Revocation
March 9, 2013 by Rick Andrews Attack CRL Identity Malware MITM OCSP Revocation SSL/TLS

Certificates are typically valid for one to three years, and during that time it’s possible that the web site owner or the CA realizes that end users should not trust the certificate. There are several cases in which this might happen, including these:

• The web site owner ceases doing business, no longer owns the domain name used in the certificate, has changed their organization name, or wishes to shut down the web server.
• The subscriber learns that an unauthorized party has gained access to the private key associated with the public key in the certificate.
• The CA learns that errors were made in authentication, the subscriber misrepresented some material info used in the authentication process, or the subscriber has violated the terms of its agreement with the CA.

When the subscriber or CA makes the decision to revoke a certificate, that decision must be conveyed to end users who encounter the certificate in use. There are two different methods for this: