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. Push to Perfect Forward Secrecy Following the Edward Snowden revelations of pervasive surveillance, there was a big push to configure web servers to support Perfect Forward Secrecy.

POODLE for TLS
December 16, 2014 by Bruce Morton (Entrust) Attack SSL 3.0 SSL/TLS Vulnerability
The POODLE attack on SSL 3.0 has now been extended to some implementations of TLS. POODLE for TLS can be tracked through CVE-2014-8730. POODLE is not a flaw with the certificate authority (CA), SSL certificates or certificate management system. POODLE is a TLS implementation bug. Adam Langley states that “TLS’s padding is a subset of SSLv3’s padding so, technically, you could use an SSLv3 decoding function with TLS and it would still work fine.

A Follow-up on POODLE and SSL 3.0
November 21, 2014 by Bruce Morton (Entrust) Attack Encryption Google IETF Mozilla OpenSSL SSL 3.0 SSL/TLS TLS 1.0 TLS 1.1 TLS 1.3 Vulnerability
In October 2014, Google announced POODLE, an SSL 3.0 protocol attack. To bring you up to speed, the SSL/TLS protocol is the most important and popular security protocol on the Internet. The Secure Sockets Layer (SSL) protocol was developed by Netscape. They quickly moved from SSL 1.0 to 2.0 and finalized with SSL 3.0 in 1996. This protocol was then picked up by the IETF, who released it under the name of Transport Layer Security (TLS).

Secure Your Website with HSTS
October 8, 2014 by Bruce Morton (Entrust) Attack Chrome Encryption Firefox Google HSTS Policy SSL/TLS
Is your website secure? One thing to consider is securing your website with HTTP Strict Transport Security (HSTS). Implementation of HSTS is an extension of the Always-On SSL policy. For each website you want to protect with HSTS, you must first deploy an SSL/TLS certificate (if you haven’t already), and configure that website to be accessible only via HTTPS, not via HTTP. Then you convey to HSTS-enabled browsers that your site is only available with HTTPS, by sending the HSTS header value.

OCSP Must-Staple
June 18, 2014 by Bruce Morton (Entrust), Rick Andrews Announcement Revocation SSL/TLS
With the announcement of the Heartbleed bug and the resulting need to revoke large numbers of SSL certificates, the topic of certificate revocation has, once again, come to the fore. There have been many issues with how revocation information is provided to the browsers. First let’s review how SSL certificate status may currently be obtained: How | How | Definition | Pros | Cons | | signed list of the serial numbers of all revoked certificates that were signed by the CA’s certificate.

Perfect Forward Secrecy
April 11, 2014 by Bruce Morton (Entrust), Rick Andrews 3DES DH ECC ECDH Forward Secrecy OpenSSL RC4 RSA SSL/TLS TLS 1.2
Recent revelations from Edward Snowden about pervasive government surveillance have led to many questions about the safety of communications using the SSL/TLS protocol. Such communications are generally safe from eavesdroppers, as long as certain precautions are observed. For example, configuring your web server to avoid using SSL2 and SSL3, favoring newer versions of TLS like TLS 1.2, selecting strong ciphersuites, etc. But even if your server is configured properly, you still must secure the private key associated with your SSL certificate.

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.

Why We Need to Move to SHA-2
January 30, 2014 by Bruce Morton (Entrust), Clayton Smith (Entrust) Attack SHA2 SSL/TLS
Previously, we advised that the SSL industry must move to the SHA-2 hashing algorithm for certificate signatures. We thought it would be helpful to provide the reasoning behind the position. In the context of SSL, the purpose of a hashing algorithm is to reduce a message (e.g., a certificate) to a reasonable size for use with a digital signature algorithm. The hash value, or message digest, is then signed to allow an end-user to validate the certificate and ensure it was issued by a trusted certification authority (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. That being said, RC4 was also attacked, where through 16 million sessions a small amount of plaintext can be recovered.