Securing Software Distribution with Digital Code Signing
October 16, 2013 by
Bruce Morton
(Entrust),
Jeremy Rowley
CASC
Code Signing
Malware
SSL/TLS
Code signing certificates from publicly trusted Certification Authorities (CAs) fulfill a vital need for authentication of software distributed over the Internet in our interconnected world. As the commonly referred to “Internet of things” continues to grow, consumers have access to millions of applications for their desktops, laptops, and mobile devices. Creative software engineers provide us with applications to cover any of our potential needs or interests. Cybercriminals and others with malicious intent recognize this as an opportunity and seek to trick us into installing malicious software (malware) — programs that hijack our computers, steal our money, or try to inflict harm.
Certificate Authority Audits and Browser Root Program Requirements
October 15, 2013 by
Kirk Hall
(Entrust)
AICPA
CA/Browser Forum
CASC
ETSI
EV
ISO
ITU
Microsoft
Policy
Qualified
Root Program
SSL/TLS
WebTrust
Recent news stories have highlighted the need for strong security in online communications, and use of SSL certificates issued by a publicly trusted Certification Authority (CA) is perhaps the best way to achieve that. But why should the public trust SSL certificates issued from commercial CA roots, which are embedded as trust anchors in web browsers?
One answer is because of the multiple layers of standards and tough requirements that all commercial CAs must meet – and for which they are audited every year. These standards and requirements have increased from year to year over the past decade.
The (Soon to Be) Not-So Common Name
October 8, 2013 by
Ryan Hurst
CA/Browser Forum
CRL
Encryption
Identity
IETF
Revocation
SSL/TLS
Vulnerability
If you are reading this post you are probably already familiar with the use of digital certificates and SSL even if you may not be familiar with the history. Before exploring the history of SSL, let’s review at its core what a digital certificate actually is. Fundamentally, a digital certificate is the binding of entitlements and constraints to a key, in other words a digital certificate would dictate the following, “The holder of the private key associated with this certificate can rightfully use the name John Smith when signing emails.”
What is Certification Authority Authorization?
September 25, 2013 by
Rick Andrews
CAA
IETF
Policy
SSL/TLS
DNS Certification Authority Authorization (CAA), defined in IETF draft RFC 6844, is designed to allow a DNS domain name holder (a website owner) to specify the certificate signing certificate(s) authorized to issue certificates for that domain or website. Usually, the certificate signing certificate will belong to the Certification Authority (CA) that issues SSL certificates to you. It’s a way for you to indicate which CA or CAs you want to issue certificates for your domains. Using CAA could reduce the risk of unintended certificate mis-issuance, either by malicious actors or by honest mistake.
It’s Time for TLS 1.2
September 19, 2013 by
Wayne Thayer
Attack
BEAST
Chrome
Firefox
OCSP
RC4
SHA2
SSL 3.0
SSL/TLS
TLS 1.0
TLS 1.1
TLS 1.2
Vulnerability
In a previous post titled Getting the Most Out of SSL Part 2, we touched on the recommendation that Web servers be configured to prefer Transport Layer Security (TLS) version 1.2. With the planned release of Firefox 24 and recent release of Chrome 29 adding support for TLS 1.2, now is a great time for website administrators to make the switch.
Transport Layer Security was formerly called Secure Sockets Layer (SSL) and is the protocol that enables secure “https://” connections to websites. TLS 1.2 was defined 5 years ago in RFC 5246, and TLS 1.1 dates all the way back to RFC 4346 in 2006. Both of these versions are updates to the original standard that fix bugs and problems including vulnerability to cipher block chaining (CBC) such as the BEAST attack that made news in 2011. The authors also added newer cipher suites including a replacement for RC4, a popular cipher that has been shown to be susceptible to attack. In short, enabling TLS 1.2 is like a Windows software update – it fixes potential problems and makes your website more secure.
Encryption Still Works – It’s About How You Implement It
September 13, 2013 by
Ben Wilson
ECC
Encryption
Malware
RSA
SHA1
SHA2
SSL/TLS
TLS 1.1
Vulnerability
The September 5th joint article by the New York Times and Guardian newspapers on NSA’s and GCHQ’s efforts to circumvent encryption implementation have left many people speculating on the security of the data they are transmitting over the Internet. Hopefully, this blog post will provide some guidance and help understand SSL in light of these recent articles. Importantly, the articles point out that the primary means of attacking SSL/TLS do not exploit a vulnerability in the protocol itself but instead aim to exploit poor implementations of the protocol, insecure servers, and weak cryptography.
What Is Certificate Transparency and How Does It Propose to Address Certificate Mis-Issuance?
September 9, 2013 by
CA Security Council
Attack
Mis-issued
OCSP
Revocation
SSL/TLS
TSA
As originally architected by Netscape and others in the mid-1990s, the certificate issuance process envisioned that the CA would present the certificate and its contents to the named subject who would review and accept the certificate first. Then the CA would publish the certificate to a repository. That process would establish that the certificate’s subject was aware of certificate issuance. (Otherwise, an unscrupulous CA could sign a subscriber’s public key and create a certificate for the subscriber without its knowledge.) The repository was also an independent means of obtaining and verifying the public key prior to initiating secure, authenticated communication without having to obtain it solely from the server during session negotiation.
Public Key Pinning
August 28, 2013 by
Bruce Morton
(Entrust)
Android
Chrome
Google
IETF
Mis-issued
SHA1
SSL/TLS
The current browser-certification authority (CA) trust model allows a website owner to obtain its SSL certificate from any one of a number of CAs. That flexibility also means that a certificate mis-issued by a CA other than the authorized CA chosen by the website owner, would also be accepted as trustworthy by browsers.
This problem was displayed most dramatically by the DigiNotar attack in 2011 and in a mistaken CA certificate issued by TURKTRUST in 2012. In these cases, certificates were issued to domains that were not approved by the domain owner. Fortunately, the problem was detected in both cases by public key pinning, which Google implemented in Chrome.
Firefox 23 Blocks Mixed Content
August 13, 2013 by
Wayne Thayer
Chrome
Encryption
EV
Firefox
Google
Malware
Mixed Content
Mozilla
SSL/TLS
The latest version of the Firefox Web browser from Mozilla was released on August 6th with a great new security feature called a “mixed content blocker”. In a nutshell, this feature ensures that all of the parts of a secure Website are indeed encrypted via SSL certificates. All of the data on the website is prevented from being intercepted, and it becomes more difficult to add malware into the site’s content.
What Are the Different Types of SSL Certificates?
August 7, 2013 by
Dean Coclin
DV
Encryption
EV
Identity
Phishing
SSL/TLS
Domain Validation (DV)
A Domain Validated SSL certificate is issued after proof that the owner has the right to use their domain is established. This is typically done by the CA sending an email to the domain owner (as listed in a WHOIS database). Once the owner responds, the certificate is issued. Many CAs perform additional fraud checks to minimize issuance of a certificate to a domain which may be similar to a high value domain (i.e. Micros0ft.com, g00gle.com, b0fay.com). The certificate only contains the domain name. Because of the minimal checks performed, this certificate is typically issued quicker than other types of certificates. While the browser displays a padlock, examination of the certificate will not show the company name as this was not validated.
