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.

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. It wouldn’t check the padding bytes but that wouldn’t cause any problems in normal operation. However, if an SSLv3 decoding function was used with TLS, then the POODLE attack would work, even against TLS connections.”

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). The IETF released TLS 1.0, 1.1 and 1.2. They are currently working on TLS 1.3.

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. Supporting browsers will automatically change any HTTP query for your website into an HTTPS query. If there is no HTTPS version available, then the browser will provide a trust dialogue to the user.

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. | A single point of reference for the status of all certificates issued by the CA’s certificate. | Over time, CRLs might become very large, resulting in unacceptable latency. An attacker may be in a position to block the CRL delivery. | | Online Certificate Status Protocol (OCSP) | A signed response containing the status of one certificate. | An OCSP response is small and does not grow. As such, there is no latency due to size. | Browsers have to obtain an OCSP response for each certificate in the Web server’s certificate chain, requiring it to open additional connections, thereby impacting page load time. Privacy issues may be a concern as the CA can determine which websites a user is visiting. An attacker may be in a position to block the OCSP delivery. | | OCSP Stapling | A signed response, fetched by the Web server, with the status of its certificate. The OCSP response is then provided by the Web server to the browser. | No privacy issues, as the CA does not know which user has asked for the OCSP response. | Need Web servers and browsers that support OCSP Stapling. An attacker may be in a position to block the OCSP delivery. | | Blacklist (for example, CTLs or CRLSets) | A list of certificates that should not be trusted (whether or not they were revoked), distributed by the browser supplier. | The blacklist is distributed by the browser supplier as part of the browser executable. | Any certificate on the blacklist can be rejected without any additional checks. | For practical reasons, the list is incomplete. |

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. In nearly all cases, the web site owner generates their key pair and sends only the public key to their Certification Authority (CA). The CA (and any eavesdropper) sees only the public key, and the private key cannot be derived from that. So the CA cannot reveal a web site owner’s private key to the government or an attacker, even if coerced to do so.

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.

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). In the past, we used MD5 for hashing; we are now primarily using SHA-1 while beginning the transition to SHA-2, and have SHA-3 available for the future.

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.