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. “Secure” was provided for HTTPS sites. “Not secure” was implemented progressively, first resulting for HTTP pages requiring a password or credit card number. Then resulting for HTTP pages where text input was required.
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. Key pairs produced by other methods and libraries are unaffected. However, Infineon’s library is very popular, and used in many scenarios, especially for smart cards. RSA keys for public websites are generally much less likely to have been generated by such hardware, although some cases are known to exist, and certificate authorities are working to inform customers and get the vulnerable keys replaced.
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.
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:
- Overall CT policy discussions with the major stakeholders are underway, but we are still far away from a conclusion.
- Other browsers appear to be supporting CT, but have yet to determine their policies or advance their browser code.
- The CT deployment document, RFC 6962-bis, tracked by IETF standards has not been released.
- The proposed document for CT Domain Label Redaction that addresses privacy has started, but has not been adopted or completed by the IETF.
- Sufficient, scalable, and reliable CT logs have not been deployed by the ecosystem to address the increase in requirements.
Certification authorities (CAs) as well as TLS certificate subscribers will welcome the extra time to help ensure that deployment of CT logging is efficient and seamless.
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.
Stricter Standards for SSL Server Test Coming in 2017
December 13, 2016 by
Bruce Morton
(Entrust)
3DES
CASC
Forward Secrecy
RC4
SSL/TLS
TLS 1.3
Vulnerability
This is a good time to offer a reminder that the CASC has a great tool for secure server testing, the SSL Server Test. The tool grades your server installation and reviews the: certificate, protocol support, key exchange and cipher strength for security against standards and known vulnerabilities.
The grading tool also provides feedback on handshake simulations with various versions of browsers and operating systems. This lets the server administrator know which implementations are supported. The test also checks the server mitigation for known vulnerabilities such as: DROWN, BEAST, POODLE and Heartbleed.
Leading Certificate Authorities and Microsoft Introduce New Standards to Protect Consumers Online
December 8, 2016 by
CA Security Council
CASC
Code Signing
FIPS
HSM
Identity
Malware
Microsoft
Revocation
SSL/TLS
TSA
San Francisco –December 8, 2016 – the Certificate Authority Security Council (CASC), an advocacy group committed to the advancement web security, today announced the Code Signing Working Group has released new Minimum Requirements for Code Signing for use by all Certificate Authorities (CA). These requirements represent the first-ever standardized code signing guidelines. Code signing is the method of using a certificate-based digital signature to sign executables and scripts in order to verify the author’s identity and ensure that the code has not been changed or corrupted. Helping to verify software authenticity and avoid downloading malware and other malicious software is critical to protecting consumers’ online interactions. Microsoft is the first applications software vendor to adopt these guidelines, with others expected to follow.
