PKI Consortium blog

Posts by tag Encryption

    Quantum Computing: Real or Exaggerated Threat to the Web PKI?
    August 30, 2017 by Dean Coclin, Tim Hollebeek Encryption PKI Quantum RSA SSL/TLS Web PKI

    Twenty years ago, paying your phone or electric bill involved receiving it in the mail, writing a check and mailing it back to the company. Today, that has largely been replaced by email and web-based payment submittals. All of this is secured by digital certificates and encryption, which provide privacy and authentication of information transiting the open Internet (aka Web PKI).

    The web PKI is predominantly secured by RSA encryption algorithms; mathematical theorems which have been improved over time. These algorithms depend on the difficulty of computers in factoring large prime numbers in a reasonable time. The current state of binary computers would require 6.4 quadrillion (See: https://www.digicert.com/TimeTravel/math.htm) years to solve this mathematical problem and subsequently decrypt a message.

    How Browser Security Indicators Can Protect You from Phishing
    June 6, 2017 by Chris Bailey (Entrust), Kirk Hall (Entrust) Chrome DV Encryption EV Google Identity Phishing SSL/TLS


    The media is full of stories about how phishing sites are moving rapidly to encryption using anonymous, free DV certificates they use to imitate login pages for popular sites, such as paypal.com.

    As noted in the article PayPal Phishing Certificates Far More Prevalent than Previously Thought, more than 14,000 DV SSL certificates have been issued to PayPal phishing sites since the start of 2016.  Based on a random sample, 96.7% of these certificates were intended for use on phishing sites.

    The Latest on Certification Authority Authorization
    March 21, 2017 by Jeremy Rowley Attack CA/Browser Forum CAA Encryption Identity OV PKI Policy Qualified

    Things are certainly heating up at the CA/Browser with exciting proposals surrounding inclusion of the Wi-Fi Alliance (WFA) as a subjectAltName otherName, new validation methods, and debates over how the CAB Forum will continue operating. One of these newly passed ballots requires all CAs to check and process a domain name’s DNS Certification Authority Authorization (CAA) resource record prior to issuing a digital certificate.

    Background

    RFC 6844 created CAA records as a method for domain owners to specify a policy on which certificate authorities are authorized to issue certificates for the associated domain. The basic concept is that immediately prior to issuance, the certificate authority (CA) will check the CAA record and determine whether policy permits creation of the certificate. Issuance is permitted if either a CAA record does not exist for the domain or the CAA record lists a string specified by the CA as authorizing the CA to issue the certificate. Using CAA records, the domain owner is able to control policy at a more granular level, including specifying which CA can issue wildcard certificates and how to report issues. Note, that CAA record checking is an additional requirement that occurs after the CA completes the normal domain verification process required by the CA/Browser Forum’s baseline requirements under Section 3.2.2.

    2017 – Looking Back, Moving Forward
    January 13, 2017 by Bruce Morton (Entrust) 3DES Apple Attack CA/Browser Forum CAA Chrome Code Signing Encryption Firefox Google Identity Malware MITM Policy Revocation RSA SSL 3.0 SSL/TLS TLS 1.3 TSA Vulnerability

    Looking Back at 2016

    Fortunately, 2016 was not a year full of SSL/TLS vulnerabilities. Although some researchers did prove old cryptography algorithms should be put out to pasture. The year showed the end of public-trusted SHA-1 SSL/TLS certificates. It also showed more transparency should be considered due to issues discovered with a few certification authorities (CAs). The great news is HTTPS is no longer the minority — after 20 years, connections using HTTPS has surpassed HTTP.

    The Web Is Moving From HTTP to HTTPS
    November 21, 2016 by Dean Coclin Chrome Encryption Google SSL/TLS

    The four letters, “http”, are known to technical and non-technical users alike as the beginning of any web address. These have been ubiquitous for many years. But things are about to change. Pretty soon, you won’t be able to go to many popular websites just by using those 4 letters. You will need to add an “s” at the end (https). Why is this happening? What are the reasons for this change?

    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.

    How a SWEET32 Birthday Attack is Deployed and How to Prevent It
    September 7, 2016 by Bruce Morton (Entrust) 3DES Attack Encryption RC4 SSH SSL/TLS TLS 1.0

    Details surrounding the SWEET32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN can be found in the paper released by Karthikeyan Bhargavan and Gaëtan Leurent from INRIA in France. The paper shows that cipher suites using 64-bit block length ciphers are vulnerable to plaintext recovery attacks. As such, Triple-DES (3DES) and Blowfish are vulnerable. Here’s an overview.

    Vulnerabilities to a SWEET32 Birthday Attack

    Certain scenarios are pre-disposed to a SWEET32 Birthday attack. For HTTPS, most susceptible are websites that support the 3DES algorithm and sustain long lived connections.

    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.

    Stay Safe This Tax Season by Looking for SSL/TLS Certificates
    March 30, 2016 by Ben Wilson Encryption EV Identity SSL/TLS

    It’s tax filing season again, and you need to be aware of scams that tried to steal your sensitive information or even your tax refund.  During 2015 the IRS blocked over 4.3 million suspicious returns and more than 1.4 million confirmed identity theft returns. https://www.irs.gov/uac/Newsroom/IRS,-States-and-Tax-Industry-Combat-Identity-Theft-and-Refund-Fraud-on-Many-Fronts.

    Phishing emails, account compromise, identity theft, and fake websites are a few approaches used by cyber criminals this time of year.  Good computer security hygiene will usually protect you from someone else filing a tax return in your name.  Do not open attachments from people you do not know, do not click on links that take you to websites with malicious content, use good passwords, remember that the IRS does not communicate by email, and only use a recognized e-filing website when entering your sensitive personal information.  The IRS website is a good place to start.  The SSL/TLS URL for the IRS e-filing webpage is https://www.irs.gov/Filing/E-File-Options. Don’t go anywhere else–unless you have used a particular trusted e-filing provider in the past.  SSL/TLS Certificates help establish the identity of web sites you visit.  https://casecurity.org/2013/11/22/how-organizations-are-authenticated-for-ssl-certificates/

    2016 – Looking Back, Moving Forward
    December 14, 2015 by Bruce Morton (Entrust) Attack CA/Browser Forum CAA Chrome Code Signing DH Encryption Firefox Google Hash Function IETF Microsoft MITM OpenSSL Policy RC4 Revocation RSA SSL/TLS TLS 1.2 TLS 1.3 Vulnerability

    Looking Back at 2015

    A number of new tactics proved 2015 was no exception to an active year defending against ever increasing security issues. Vendors found new and creative ways to provide vulnerabilities including the now popular man-in-the-middle (MitM) attacks.  MitM as well as a host of other new vulnerabilities caused browsers to rethink their security requirements.  This article gives a flashback of the exploits and industry changes from 2015 and looks ahead at the latest security requirements and how it impacts IT security teams.

    Participate in our community discussions and/or join the consortium