Fortify Allows Users to Generate X.509 Certificates in Their Browser
June 19, 2018 by
Tim Hollebeek
Chrome
Code Signing
Encryption
Firefox
Google
HSM
Microsoft
Mozilla
S/MIME
W3C
Fortify, an open source application sponsored by Certificate Authorities through the CA Security Council, is now available for Windows and Mac. The Fortify app, which is free for all users, connects a user’s web browsers to smart cards, security tokens, and certificates on a user’s local machine. This can allow users to generate X.509 certificates in their browser, replacing the need for the deprecated <keygen> functionality.
Certificate Generation In The Browser The Web Cryptography API, also known as Web Crypto, provides a set of cryptographic capabilities for web browsers through a set of JavaScript APIs.
Fortify Provides a More Secure Web Experience for Certificates and Smart Cards
June 19, 2018 by
CA Security Council
CASC
Code Signing
S/MIME
SSL/TLS
San Francisco – June 19, 2018 – The Certificate Authority Security Council (CASC), an advocacy group committed to the advancement of web security, today announced that Fortify, an open source application sponsored by the Council, is now available for Windows and Mac. Fortify, a free app, connects a user’s web browsers to smart cards, security tokens, and certificates on a user’s local machine. This allows users to generate X.509 certificates in their browser, replacing the loss of key generation functionality.
CA/Browser Forum Governance Reform
May 18, 2018 by
Dean Coclin
Apple
CA/Browser Forum
Code Signing
Policy
S/MIME
SSL/TLS
In March 2016, the CA/Browser Forum formed a working group to review potential ways to restructure the forum. The primary goal was to examine ideas so the Forum could work on other types of standards besides TLS. Ben Wilson and I chaired this group with excellent participation from a cross functional team of browser and certificate authority representatives as well as interested parties. After 2 years of efforts, the working group produced Ballot 206 which passed in April 2017.
TLS 1.3 Includes Improvements to Security and Performance
April 10, 2018 by
Tim Shirley
Forward Secrecy
IETF
SSL/TLS
TLS 1.2
TLS 1.3
Vulnerability
Last month saw the final adoption, after 4 years of work, of TLS version 1.3 by the Internet Engineering Task Force (IETF). This latest iteration of the protocol for secure communications on the internet boasts several noteworthy improvements to both security and performance:
Security All cipher suites that do not provide forward secrecy have been eliminated from TLS 1.3. This is a very important security property, because without forward secrecy, if a server’s private key is compromised today, any previously-recorded conversations with that server dating back as long as the key was in use could be decrypted.
Chrome Will Show Not Secure for all HTTP Sites Starting July 2018
February 15, 2018 by
Bruce Morton
(Entrust)
Android
Chrome
Google
HSTS
Phishing
SSL/TLS
Vulnerability
Through 2017 and into 2018, we have seen the use of HTTPS grow substantially. Last Fall Google announced the following status:
Over 68% of Chrome traffic on both Android and Windows is now protected Over 78% of Chrome traffic on both Chrome OS and Mac is now protected 81 of the top 100 sites on the web use HTTPS by default Google helped to drive this growth by implementing the “Secure” and “Not secure” status in Chrome’s status bar.
2018 – Looking Back, Moving Forward
January 6, 2018 by
Bruce Morton
(Entrust)
Attack
CA/Browser Forum
CAA
Certificate Expiry
Chrome
ECC
Encryption
Google
Microsoft
Mis-issued
OV
PDF
PKI
ROCA
RSA
SSL/TLS
TLS 1.3
Vulnerability
Looking Back at 2017 2017 saw the end of SHA-1 in public trust SSL/TLS certificates and the start of Certification Authority Authorization (CAA) allowing domain owners to authorize their CA. A “Not secure” browser indication was propagated to push more websites to support HTTPS. There was also a change in the certification authority (CA) ownership with DigiCert acquiring Symantec’s SSL and related PKI business and Francisco Partners buying Comodo’s CA.
How Does the ROCA Attack Work?
November 9, 2017 by
Tim Hollebeek
Attack
PKI
ROCA
RSA
Web PKI
On October 17th, a group of Czech researchers announced they had found a way to factor the moduli of many RSA public keys generated by hardware produced by Infineon Technologies AG. The technical details were presented in a paper at the 2017 Computer and Communications Security conference, hosted by the Association for Computing Machinery on November 2nd.
The technique only works against the key pairs produced by Infineon’s library, because it exploits the unique method they use to generate RSA primes.
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.
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.
Certificate Transparency Deadline Moved to April 2018
May 3, 2017 by
Bruce Morton
(Entrust)
Chrome
Google
IETF
Policy
SSL/TLS
Google just announced they will not be enforcing certificate transparency (CT) logging for all new TLS certificates until April 2018. In a previous blog post, we advised that Google provided a new policy, which required new TLS certificates to be published to the CT logs in order for the domain to be trusted by Chrome.
The reason for the delay was not clear, but Google needs to consider the following:
