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.
What Kind of SSL/TLS Certificate do You Need?
May 12, 2016 by
Ben Wilson
DV
EV
SSL/TLS
In previous blog posts we have discussed the differences among the various types of SSL/TLS certificates available. In this blog post we introduce you to a new infographic that has a decision tree to help you select the right kind of certificate for your needs. In most cases you will need a publicly trusted certificate, but the decision tree notes that one type of certificate is the private trust certificate, which can be obtained and used in situations where a publicly trusted certificate cannot be used. These types of private SSL/TLS certificates chain to a root certificate that is not embedded in the key stores of browsers and other similar software, but apart from that branch, the decision tree is an aid to server administrators looking to buy one or more publicly trusted SSL/TLS certificates.
SSL 2.0 and DROWN
April 4, 2016 by
Bruce Morton
(Entrust)
Attack
IETF
OpenSSL
SSL 3.0
SSL/TLS
Vulnerability
A team of researchers has announced a vulnerability with SSL 2.0 called Decrypting RSA with Obsolete and Weakened eNcryption; otherwise known as DROWN.
SSL 2.0 is a version of the SSL/TLS security protocols. It was released in February 1995, but due to security flaws was superseded by SSL 3.0 in 1996.
DROWN is a cross-protocol attack where the bugs in SSL 2.0 can be used to attack the security of connections that use TLS. The vulnerability applies to servers:
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/
Moving to Always on HTTPS, Part 2 of 2; Upgrading to HTTP Strict Transport Security
February 18, 2016 by
Ben Wilson
HSTS
Mixed Content
Policy
SSL/TLS
Vulnerability
W3C
Part 1 of this blog post discussed browser security indicators and how to avoid getting warnings about mixed content on your website. (Mixed content leaves a door open that allows an attacker to snoop or inject malicious content during the browsing session.) This Part 2 discusses other technical measures to implement Always on HTTPS. As I noted previously, one of the difficulties with implementing Always on HTTPS is that content is often provided by third parties. I suggested that you require HTTPS from them as well. However, until you are able to get them to do this you will need to find another way to serve up content via HTTPS. One approach is to collect the material locally and serve it up from the same origin – your HTTPS server.
Moving to Always on HTTPS, Part 1 of 2; Marking HTTP as Unsecure
February 3, 2016 by
Ben Wilson
Chrome
Firefox
Google
HSTS
Malware
Mixed Content
Mozilla
SSL/TLS
Vulnerability
Over the past several years there has been increased discussion about deprecating HTTP and making HTTPS the default protocol for the World Wide Web. (HTTP stands for “HyperText Transfer Protocol” and the “S” in HTTPS is enabled with an SSL/TLS digital certificate properly installed and configured on a web server.) These discussions have taken place in the context of browser security indications and technical improvements simplifying the global movement to “Always on HTTPS.” Part 1 of this two-part blog post will address browser security indicators, while Part 2 discusses technical developments to make HTTPS the default protocol when browsing the web.
What Will Happen With SHA-1 and Browser Users on January 1st, 2016?
January 5, 2016 by
Bruce Morton
(Entrust)
Android
Apple
Chrome
Firefox
Google
Mozilla
SSL/TLS
Vulnerability
On January 1, 2016, the public trust certification authorities (CAs) will stop issuing SHA-1 signed SSL/TLS certificates. What will happen?
Will all websites using SHA-1 fail? No. SHA-1 will be supported by browsers and operating systems through 2016. Microsoft and Mozilla have announced that Windows and Firefox will not support SHA-1 in 2017, but no change for 2016. We expect Apple to follow the same protocol.
What about Chrome? Chrome will still provide warning indications in the browser status bar for SHA-1 signed certificates which expire in 2016 and in 2017 or later. No change.
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.
Code Signing Baseline Requirements
November 30, 2015 by
CA Security Council
CA/Browser Forum
CASC
Code Signing
Identity
Malware
You may have heard that the CA/Browser Forum is getting ready to approve Baseline Requirements for Code Signing certificates. But why is this important?
Let’s back up and get some background on code signing. Software code that is digitally signed indicates to the user that the code has not been tampered with since it was signed. It also provides authenticity as to who signed it and when. With the advent of malware, it’s important to insure that the code which was written by the developer is the same code which you downloaded and installed into your computer or mobile phone. A digital signature is like a shrink wrap, protecting the code from modification without detection. Second, the code is signed with a digital certificate issued by a public certificate authority which has performed a verification check on the identity of the author. Malware authors don’t like to be identified, hence the likelihood of a legitimate code signing certificate being issued to a malware author is decreased.
CA/B Forum Istanbul 2015
November 10, 2015 by
Dean Coclin
Chrome
eIDAS
Qualified
Root Program
WebTrust
While some face to face meetings can be rather mundane and boring, that can’t be said about October’s CA/B Forum meeting in Istanbul, Turkey. Guest speaker Andrea Servida from the European Commission gave an overview of the new eIDAS regulation on electronic identification and trust services. While not everyone in the room agreed with his points, all were made aware that this has now become the law in the EU and certificate authorities which plan to issue the new EU Qualified website certificates must comply with it. Unfortunately, the law appears to make it a requirement that the Certificate Authority (or Trust Service Provider-TSP as spelled out in the regulation) must be based in the EU or in a country that has an agreement with the EU. This could limit CA choices for EU website owners to only smaller CAs located in the EU, and potentially drive up certificate prices. A link to Mr. Servida’s presentation is here: https://cabforum.org/wp-content/uploads/eIDAS-Istanbul-Servida.pdf
