PKI Consortium blog

How Safe Are Your Business’ Online Payments?: E-Commerce Sites and Protected Payment Gateways
October 21, 2015 by CA Security Council Encryption Google SSL/TLS

This blog was originally posted on staysafeonline.org on June 29, 2015.

Online payments can be made in a variety of ways, but majority of the online financial transactions are done through secured payment gateways. Secure payment gateways, as the name suggests, are application service providers for ecommerce websites that authorize various financial transactions taking place on online stores for ensuring safety for both the retailers and the online buyers. The key goal of payment gateways is to secure personal information like cconsumers’ credit card numbers by encrypting their personal and confidential information. Learn more about what these gateways are and how they help protect your online transactions.

Practical Steps to Counter the Logjam Attack
May 26, 2015 by Kirk Hall (Entrust) Apple Attack Encryption Google MITM SSL/TLS Vulnerability

Another flaw has been found in the basic encryption algorithms that secure the Internet. This flaw, named the Logjam attack by its discoverers (researchers from various universities and companies), allows an attacker that can carry out man-in-the-middle (MitM) attacks to weaken the encryption used in secure connections (such as HTTPS, SSH, and VPNs). In theory, this means that an attacker (with sufficient resources) can break the encryption and read the “secure” traffic.

Why You Should Get Familiar With TLS If You Accept Credit Cards
April 28, 2015 by Billy VanCannon Encryption PDF SSL/TLS Vulnerability

The group that manages the Payment Card Industry Data Security Standard quietly announced in February that an imminent update was coming to its payment card and application requirements related to the use of the SSL encryption protocol. Since then, there has been growing concern among merchants about what the changes mean to them.

The confusion among retailers generally can be boiled down to two questions:

1. What will the new updates require me to do?
2. What happens to my TSL/SSL certificates?

First let’s explain what’s going on: On Feb. 13, the PCI Security Standards Council informed its assessor community that SSL (Secure Sockets Layer) – a protocol designed to ensure that data provided between a web server and a web browser, such as credit card information, remains secure – is no longer an acceptable way to provide “strong cryptography.” This is due to a number of known fundamental vulnerabilities – some of which, such as Heartbleed, we have documented here, here and here – that essentially make SSL, as an encryption mechanism, obsolete.

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).

Is Your SSL Server Vulnerable to a FREAK Attack?
March 11, 2015 by Bruce Morton (Entrust) Android Attack Encryption Forward Secrecy Microsoft MITM RSA SSL/TLS Vulnerability

FREAK is a new man-in-the-middle (MITM) vulnerability discovered by a group of cryptographers at INRIA, Microsoft Research and IMDEA. FREAK stands for “Factoring RSA-EXPORT Keys.”

The vulnerability dates back to the 1990s, when the US government banned selling crypto software overseas, unless it used export cipher suites which involved encryption keys no longer than 512-bits.

The issue is there are still some clients who let crypto be degraded from “strong RSA” to “export grade RSA”. These clients use OpenSSL, Apple’s Secure Transport and Windows Secure Channel. As such, users of Android mobiles, Apple Macs, iPhones and iPads, and Windows platforms will be impacted.

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.

Who Sets the Rules Governing Certification Authorities?
August 19, 2014 by Kirk Hall (Entrust) CA/Browser Forum Code Signing DV Encryption ETSI EV Google Hash Function Identity IETF Microsoft Mozilla OCSP Policy Revocation Root Program SSL/TLS WebTrust

Every time something positive is published about SSL and encryption,such as Google’s recent decision making use of https encryption a favorable rating factor for a website, or negative, such as the Heartbleed issue – bloggers and others always post questions about public Certification Authorities (CAs), including general questions on who sets the rules that govern CAs. Some bloggers seem to assume there are no rules or standards, and that CAs can operate without any requirements or limitations at all — that’s incorrect.

Benefits of Elliptic Curve Cryptography
June 10, 2014 by Wayne Thayer CA/Browser Forum ECC ECDH ECDSA Encryption RSA SSL/TLS

Elliptic Curve Cryptography (ECC) has existed since the mid-1980s, but it is still looked on as the newcomer in the world of SSL, and has only begun to gain adoption in the past few years. ECC is a fundamentally different mathematical approach to encryption than the venerable RSA algorithm. An elliptic curve is an algebraic function (y2 = x3 + ax + b) which looks like a symmetrical curve parallel to the x axis when plotted. (See figures below.) As with other forms of public key cryptography, ECC is based on a one-way property in which it is easy to perform a calculation but infeasible to reverse or invert the results of the calculation to find the original numbers. ECC uses different mathematical operations than RSA to achieve this property. The easiest way to explain this math is — for an elliptic curve, a line will only pass through three points along the curve (P, Q, and R), and that by knowing two of the points (P and Q), the other (R) can be calculated easily, but with just R, the other two, P and Q, cannot be derived.

Heartbleed Bug Vulnerability: Discovery, Impact and Solution
April 9, 2014 by Jeremy Rowley Attack BEAST CASC CSR DTLS Encryption Google OpenSSL SSL/TLS TLS 1.0 TLS 1.1 Vulnerability

On April 7, 2014, a vulnerability in the OpenSSL cryptographic library was announced to the Internet community. Aptly labeled as the Heartbleed bug, this vulnerability affects OpenSSL versions 1.0.1 through 1.0.1f (inclusive). The Heartbleed bug is not a flaw in the SSL or TLS protocols; rather, it is a flaw in the OpenSSL implementation of the TLS/DTLS heartbeat functionality. The flaw is not related or introduced by publicly trusted certificates and is instead a problem with server software.