PKI Consortium blog
Posts by tag Identity
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).
The London Protocol
June 27, 2018 by CA Security Council DV EV Identity OV PhishingThe objective of The London Protocol is to improve identity assurance and minimize the possibility of phishing activity on websites encrypted by OV (organization validated) and EV (extended validation) certificates (together referred to as “Identity Websites”). The London Protocol reinforces the distinction between Identity Websites making them even more secure for users than websites encrypted by DV (domain validated) certificates. That security feature can then be utilized by others for their own security purposes, including informing users as to the type of website they are visiting and use by antiphishing engines and browser filters in their security algorithms.
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/TLSThe 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 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.
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 TSASan 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.
Why Is Certificate Expiration Necessary?
October 19, 2016 by Bruce Morton (Entrust) Attack CA/Browser Forum EV Hash Function Identity OCSP Policy RSA SSL/TLS VulnerabilityThe Long Life Certificate – Why It Doesn’t Exist
Why is certificate expiration even necessary? Wouldn’t it be better if I could just buy a certificate with a long life before expiration? It would really simplify certificate management if it could be installed and forgotten. Simple, no management required, just file-and-forget.
Always-On SSL
September 30, 2016 by Rick Andrews, Ben Wilson Encryption Firefox Google Identity Microsoft Mixed Content OpenSSL Policy Qualified SSL/TLSThere 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.
Stay Safe This Tax Season by Looking for SSL/TLS Certificates
March 30, 2016 by Ben Wilson Encryption EV Identity SSL/TLSIt’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/
