PKI Consortium blog

Posts by author Rick Andrews

Always-On SSL
September 30, 2016 by Rick Andrews, Ben Wilson Encryption Firefox Google Identity Microsoft Mixed Content OpenSSL Policy Qualified SSL/TLS

There is no doubt that content owners and publishers have a duty to encourage trust and the confidence during internet usage by adopting security best practices. If a customer believes that their data and identity are safe and protected, they are more inclined to continue their online transactions. Industry best practices for website protection should be vendor-neutral, easy to implement, and globally accessible. Websites should take all the reasonable steps possible to adopt best practices in secure design and implementation, and this includes using Always-On SSL across the entire website.

TLS Certificates on the Web – The Good, The Bad and The Ugly
May 17, 2016 by Rick Andrews CA/Browser Forum Code Signing ECC Encryption EV Hash Function PKI Policy RSA SSL/TLS

It might be hard to believe, but the SSL/TLS Ecosystem is nearly 20 years old. It’s time to take stock and see how we’re doing with regards to TLS certificates. In this article, we’ll primarily discuss certificates themselves and not web server configuration, although that is often a source of problems.

In the last few years, we’ve endured three major certificate-based migrations:

Away from the MD2 and MD5 hash algorithms to SHA-1
Away from small RSA keys to 2048-bit keys or larger
Away from the SHA-1 hash algorithm to SHA-256

What’s driving these migrations? Primarily, it’s the relentless march of attacks. As Bruce Schneier says, “Attacks always get better; they never get worse.” To stay ahead of these attacks, Certification Authorities and browser vendors joined together several years ago to form the CA/Browser Forum, and published several requirements documents: the Baseline Requirements, the EV SSL Guidelines and the EV Code Signing Requirements.

New Directions for Elliptic Curve Cryptography in Internet Protocols
June 24, 2015 by Rick Andrews ECC ECDSA IETF NIST RSA SSL/TLS

Last week I attended and presented at the National Institute of Standards and Technology (NIST) Workshop on Elliptic Curve Cryptography Standards. In NIST’s words, “The workshop is to provide a venue to engage the crypto community, including academia, industry, and government users to discuss possible approaches to promote the adoption of secure, interoperable and efficient elliptic curve mechanisms.”

We began by discussing the reasons for holding this workshop. Speakers acknowledged that although there are no known issues with the current set of NIST curves, in some circles they are widely distrusted. In addition, they are almost 15 years old, not particularly resistant to side-channel attacks, and don’t perform as well as newer curves. For these reasons, many people feel that NIST should standardize on one or more new curves.

The Insecurity of Mobile Applications
June 11, 2015 by Rick Andrews Android Attack MITM OpenSSL SSL/TLS Vulnerability

Recently, we read about lots of SSL/TLS-related vulnerabilities found in mobile apps, which should come as no surprise. We were warned about this back in 2012 (see these studies). More warnings came in 2014 from CERT and FireEye. The Open Web Application Security Project (OWASP) listed “insufficient transport layer protection” as number three (#3) in its top 10 list of mobile security problems of 2014. Apps that don’t use SSL/TLS are particularly vulnerable, given the ease of reading and modifying unsecured traffic at Wi-Fi hot spots, for example. But even apps that use SSL/TLS must be careful to implement proper checking to ensure that attackers can’t exploit weaknesses.

My Website’s SSL Certificate is Fine; Why Do Browsers Downgrade the Security Indicators For My Site?
April 1, 2015 by Rick Andrews Attack Chrome Encryption EV IETF RC4 SSL/TLS

All the major browsers provide “security user interface”, meaning visual elements to inform the user of the security of their connection to the web page they’re visiting. Up until now, those interface elements were tied to the use of SSL/TLS certificates served by the web site. For example, if you went to http://www.example.com, no special elements would be displayed, but if you visited https://www.example.com, you would see a lock icon indicating the presence of a trusted SSL/TLS certificate. You would also see in the address bar the name of the company responsible for the web site, if the web site used an EV certificate. Most browsers change user interface indicators for mixed content (when a secure page loaded scripts, images or other content from a non-secure site).

Gogo Found Spoofing Google SSL Certificates
January 8, 2015 by Rick Andrews Google Malware MITM SSL/TLS

It was recently disclosed that Gogo, a provider of Wi-Fi Internet services on commercial aircraft, has been issuing spoofed SSL certificates for Google sites that were viewed by customers of Gogo’s service. It appears that Gogo Inflight Internet was acting as an SSL Man-in-the-middle (MITM), a technique used within some enterprises to allow themselves to inspect and control all web traffic, even traffic to secure web sites. To understand what this means, let me explain MITM in a bit more detail.

The Cost of Creating Collisions Using SHA-1
November 18, 2014 by Rick Andrews Attack SSL/TLS

SHA-1 is a cryptographic hash algorithm that is most commonly used today in TLS/SSL certificates on the Internet. It has almost completely replaced older algorithms like MD2, MD4 and MD5, which were phased out when practical attacks against those algorithms became widely known.

If you do a simple web search, you’ll find a number of online services that claim to “crack” SHA-1 and other hash functions. These generally use a computer’s CPU to build and search through a rainbow table, which contains the hash value that results from a number of expected inputs, and allows you to “reverse” the hash algorithm. Give them a hash value and they will look in their table to see if they have the input that resulted in that hash value. If they haven’t pre-computed the hash value for the data you’re looking for, they won’t find anything. They’re intended as password recovery services, since many user authentication systems store the hash values of passwords rather than the passwords themselves. Many years ago, we thought this was safe since good hash functions were considered irreversible (if someone has the hash value without the corresponding input, they can’t reverse the algorithm to recover the input), and computers didn’t have enough memory or storage to save and process large rainbow tables. Today, rainbow tables are commonly used to associate hash values with passwords and vice versa.

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.

Always-On SSL, Part I
January 16, 2014 by Rick Andrews Encryption Google Identity Microsoft Mixed Content OpenSSL SSL/TLS