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.

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: What will the new updates require me to do?

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.

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

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.

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.

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.