PKI Consortium blog

Always-On SSL
September 30, 2016 by Rick Andrews, Ben Wilson Encryption Firefox Google Identity Microsoft Mixed Content OpenSSL Policy Qualified SSL/TLS

There 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.

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.

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 Are “Application Reputation” and “Publisher Reputation”?
August 27, 2015 by Ben Wilson Code Signing Malware Microsoft

As one dog says to the other in Peter Steiner’s classic New Yorker cartoon– “On the Internet, nobody knows you’re a dog.”

Software downloaded from the Internet is similar to people on the Internet–it is hard to tell which ones are dogs–without help, which is what “application reputation” technology provides.    “Application reputation” and “publisher reputation” are methods employed by Microsoft’s SmartScreen and other systems to distinguish good software from bad software as it is downloaded from the Internet.  Reputation works similar to the way that we develop trust in other people– we study them over the course of multiple encounters or, if we don’t have prior experience with them, then we rely on others for information about reputation.

Facebook Will Stop Supporting SHA-1 in October
June 8, 2015 by Ben Wilson Announcement SSL/TLS

On June 2, 2015, Facebook announced that it would stop supporting Facebook-connected apps that were signed with SHA-1, as of October 1, 2015.

“These changes are part of a broader shift in how browsers and web sites encrypt traffic to protect the contents of online communications. Typically, web browsers use a hash function to create a unique fingerprint for a chunk of data or a message. This fingerprint is then digitally signed to prove that a message has not been altered or tampered with when passing through the various servers and systems between your computer and Facebook’s servers.” [https://developers.facebook.com/blog/post/2015/06/02/SHA-2-Updates-Needed/]

In the Wake of Unauthorized Certificate Issuance by the Indian CA NIC, can Government CAs Still be Considered “Trusted Third Parties”?
July 24, 2014 by Ben Wilson CA/Browser Forum CAA CASC Chrome ETSI Firefox Google Microsoft Mis-issued Mozilla OCSP PKI Policy Revocation SSL/TLS Trust List WebTrust

Short answer: Government CAs can still be considered “trusted third parties,” provided that they follow the rules applicable to commercial CAs.

Introduction

On July 8 Google announced that it had discovered several unauthorized Google certificates issued by the National Informatics Centre of India. It noted that the Indian government CA’s certificates were in the Microsoft Root Store and used by programs on the Windows platform. The Firefox browser on Windows uses its own root store and didn’t have these CA certificates. Other platforms, such as Chrome OS, Android, iOS, and OS X, were not affected. See http://googleonlinesecurity.blogspot.com/2014/07/maintaining-digital-certificate-security.html

Always-On SSL, Part II
February 5, 2014 by Ben Wilson Encryption Firefox Mixed Content Policy Qualified SSL/TLS

The SSL/TLS protocol has more to offer than just providing you with transmission encryption. Its main benefit is that it provides a way for third parties to authenticate connections to your website over the Internet. A user who can connect to your site and retrieve information via SSL/TLS will have greater assurance and trust that information came from you. The point of Always-On SSL is that once a user is able to create an authenticated connection to your point of presence via https, then he or she should not be bounced back outside of that zone of protection. When content is communicated via HTTPS, it is because you expect to provide a level of security — and your users come to expect them as well. Once you welcome a visitor, it makes no sense to have them go back outside in order to knock. This is just one of several illustrations I’d like to present where heightened protection of a visitor should be maintained, and hopefully these examples will illustrate why Always-On SSL is the preferred method for providing web visit security.

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.

• ««
• «
• 1
• 2
• »
• »»