PKI Consortium blog
Posts by tag Attack
Digital Trust Is Elusive – Are Qualified Trust Services A Solution?
May 1, 2020 by
Sebastian Schulz
Attack
eIDAS
ENISA
ETSI
Phishing
Policy
QTSP
Qualified
SSL/TLS
Trust List
TSP
A popular saying goes: “Trust takes years to build, seconds to break, and forever to repair.”
While I wouldn’t completely agree, the idea isn’t wrong. In real life trust between two parties is established over some period of time, depending on a variety of factors. Have you ever wondered why you initially trust some people more and others less, even if you’ve never met them before? There are a complicated multitude of factors that influence our thoughts: the person’s appearance, tone of voice, title or rank, etc. Trust is established over time but can be lost within a few moments.
Chrome Kills Mixed Content for HTTPS
December 6, 2019 by
Bruce Morton
(Entrust)
Attack
Chrome
Firefox
Mixed Content
Policy
SSL/TLS
In a phased approach, Chrome plans to block mixed content on secure websites to improve user security. Most browsers already block some mixed content such as scripts and iframes by default. Chrome is amping it up by gradually taking steps to also block images, audio recordings and videos, according to a recent Google Security blog. Preventing mixed content to load will eventually result in HTTPS websites losing their security indicator downgrading the site to HTTP, which alerts visitors that the site is not secure.
The Insecure Elephant in the Room
October 10, 2019 by
Paul Walsh
2FA
Android
Attack
Chrome
DV
Encryption
EV
Firefox
Google
Identity
Malware
Microsoft
Mozilla
Phishing
Policy
Revocation
SSL/TLS
Vulnerability
W3C
The purpose of this article
The purpose of this article is to demonstrate why I believe browser-based UI for website identity can make the web safer for everyone. I explain in great detail, the reasons why the UI and UX didn’t work in the past. And what’s left is only making the problem worse instead of better.
2019 – Looking Back, Moving Forward
January 3, 2019 by
Bruce Morton
(Entrust)
Attack
CA/Browser Forum
Certificate Expiry
Chrome
Code Signing
DV
ECC
EV
Forward Secrecy
Identity
Mis-issued
Phishing
PKI
Policy
Qualified
Revocation
RSA
SSL/TLS
TLS 1.0
TLS 1.3
Vulnerability
Looking Back at 2018
2018 was an active year for SSL/TLS. We saw the SSL/TLS certificate validity period drop to 825-days and the mass deployment of Certificate Transparency (CT). TLS 1.3 protocol was finally completed and published; and Chrome status bar security indicators changing to remove “secure” and to concentrate on “not secure.” The CA/Browser Forum has been reformed, the London Protocol was announced and the nearly full distrust of Symantec SSL completed. Here are some details on some of the 2018 happenings in the SSL/TLS ecosystem.
CA Security Council (CASC) 2019 Predictions: The Good, the Bad, and the Ugly
December 6, 2018 by
Bruce Morton
(Entrust),
Chris Bailey
(Entrust),
Jay Schiavo
(Entrust)
Apple
Attack
CASC
Chrome
DV
Encryption
EV
Firefox
Google
Identity
IETF
Malware
Microsoft
Phishing
SSL/TLS
TLS 1.0
TLS 1.2
TLS 1.3
As the legendary coach of the NY Yankees Yogi Berra allegedly said, “It’s difficult to make predictions, especially about the future.” But we’re going to try.
Here are the CA Security Council (CASC) 2019 Predictions: The Good, the Bad, and the Ugly.
The Good
Prediction: By the end of 2019, over 90% of the world’s http traffic will be secured over SSL/TLS
CASC Announces Launch of London Protocol to Improve Identity Assurance and Minimize Phishing on Identity Websites
June 27, 2018 by CA Security Council Attack CA/Browser Forum CASC DV EV Identity OV Phishing SSL/TLSLONDON – (June 27, 2018) – The Certificate Authority Security Council (CASC), an advocacy group committed to the advancement of the security of websites and online transactions, announced at the CA/Browser Forum event in London the launch of the London Protocol – an initiative to improve identity assurance and minimize the possibility of phishing activity on websites encrypted with organization validated (OV) and extended validation (EV) certificates, which contain organization identity information (Identity Certificates).
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 VulnerabilityLooking 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 PKIOn 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.
The Latest on Certification Authority Authorization
March 21, 2017 by Jeremy Rowley Attack CA/Browser Forum CAA Encryption Identity OV PKI Policy QualifiedThings 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 VulnerabilityLooking 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.
