Part 2 of 3: The Digital World Runs on Trust (See Part 1, Should SSL Certificates be Free?)
The most valuable asset to a harmonious digital world is trust in that world…
The principle of encryption is as ancient as the need to protect information. Modern day encryption is not very different than ancient methods, excepting the computing power we now wield to makes the codes more difficult to break.
At its core, encryption is about maintaining trust in a world full of mistrust and deception. An ideal world of absolute trust would have no need for encryption. Since we do not live in such a world, human beings need encryption in order to maintain a society of relative trust.
Relative trust is the concept behind SSL/TLS Certificates as these not only provide data-protection in the form of encryption, but also identity-assurance in the form of identity verification. Identity assurance – or the validation that you are on a site that is owned and operated by who claims to be running it – seems to be just as important to every day users as encryption itself.
Ivan Ristic stated quite concisely in his book “Bulletproof SSL and TLS” :
Think about this: millions of people visit Amazon’s web sites every day and make purchases, even though the homepage opens without encryption. Why do we do that? Ultimately, because they earned our (real) trust.
In other words, people knowing who they are doing business with online has sometimes been of greater importance than knowledge that the first step to doing business is taking place within an encrypted connection. While Amazon has since encrypted its homepage and even launched its own web service that includes SSL/Certificate offerings, it wasn’t seen as necessary until the market shift towards always on HTTPS (the secure channel for HTTP connections created by SSL/TLS certificates) was seen coming on the horizon.
There is an evident symbiosis between digital security and identity assurance in application and web browser security. Trust is a matter of great importance to users, and many might not even know it. Those who drive the direction of the Internet through policies and security decisions surrounding the use of their browsers and applications face many challenges.
And it seems as though trust is going to be a big part of overcoming those challenges. And maintaining trust in a digital world is a job that everyone needs to be doing their part in if that trust is going to be maintained.
When trust is broken…
One example of a data breach that was not profitable for the hackers involved in a monetary sense, but quite damaging in regards to trust is the story of DigiNotar, a former Dutch Certification Authority whose root certificate was compromised, allowing for a huge number of rogue certificates to be created representing companies from Microsoft to Google to AOL to Facebook. The rogue certificates were issued as the attacker broke into DigiNotar’s network and was not found out to be issuing rogue certificates before it was too late. The breach led to the demise of DigiNotar and could have potentially hurt the image of every single company that unknowingly had a false certificate issued in their name. Ultimately, DigiNotar had to declare bankruptcy as trust in them had been irreparably broken.
HTTPS = Trust
But, without the proper controls to prevent fraud, how much is that trust really worth?
When you purchase a digital certificate you are making a choice that not only represents your own trustworthiness, but your trust in the Certification Authority issuing that certificate to properly represent your identity by applying the proper standards around the issuance and revocation of fraudulent certificate requests.
Regardless of the price, there are important standards that must be met in order for that certificate to be worth anything. Inconsistency in applying and adhering to these standards is what separates one Certification Authority from another, and ultimately what separates the trustworthiness of that vendor and thus, the quality of your certificate.
Despite this need for trust being an inherent quality of digital security, the desire to encrypt everything has create a demand for quick and easy digital certificates. As a result, techniques have been developed that circumvent regular domain validation standards to allow the issuance of fraudulent SSL/TLS certificates to be used for phishing attacks.
It used to be that phishing attacks would only take place outside of HTTPS or very rarely within it, but now, due to the advent of unpaid SSL/TLS certificates, we have been seeing phishing sites set up within the HTTPS ecosystem.
And this isn’t good for anyone.
The Effect of Uncontrolled, Automated Domain Validated SSL/TLS Certificates…
Between January 31st and March, 2017, anti-phishing firm Netcraft identified 47,500 sites with valid SSL/TLS certificates that were actually phishing websites. 
All of the associated SSL/TLS certificates were domain-validated certificates, and most disconcerting of all, 14,500 of the certificates issued were for Paypal phishing sites.
Inadvertently, Paypal became the target of an attack on their brand reputation. With such a high number of phishing sites set up in their name, it is easy to see how their brand would be affected by the untrustworthy actions of fraudsters, enabled by automated domain-validated certificates that were not surrounded by the proper controls to prevent such fraudulent activity from taking place.
So what does this mean for DV certificates and unpaid certificate solutions? Does this mean they don’t work because they are offered for free – as in to say, is it just the simple fact that certificates people pay for cost money the sole reason those certificates are not nearly as susceptible to breach? Does paying more for a certificate, thus guarantee a higher level of such quality?
What exactly should you look for when deciding whether or not, or how much to pay for a certificate? Check out the conclusion of this blog series for the answer to that question.
Up Next: Do you need to invest in trust?
 Ivan Ristic. Bulletproof SSL. Feisty Duck Limited, 2014.
This is a Security Bloggers Network syndicated blog post authored by Entrust Datacard Blog. Read the original post at: Entrust Datacard Blog