Trust Issues: Know the limits of SSL certificates
IT | Apr 20, 2017 | Master3395
Certificate authorities (CAs) have given themselves a black eye lately, making it hard for users to trust them. Google stopped trusting Symantec after discovering the CA had mis-issued thousands of certificates over several years, and researchers found that phishing sites were using PayPal-labeled certificates issued by Linux Foundation’s Let’s Encrypt CA. Even with these missteps, the CAs play a critical role in establishing trust on the internet.
CAs issue different types of certificates, and each type addresses a different internet security use case. Here’s what you need to understand about certificates and online trust, so you know what is happening behind HTTPS—especially now that free CAs have made it so easy to get certificates.
How certificate authorities lost your trust
Let’s Encrypt, a free CA operated by the Linux Foundation’s Internet Security Research Group, is taking a pounding for issuing 15,270 certificates containing the word “PayPal” in either the domain name or the certificate identity. The sites using those certificates weren’t PayPal properties, and nearly all (97 percent) of the domains hosted phishing pages, said researcher and encryption expert Vincent Lynch.
Our new gaming site is live! Gamestar covers games, gaming gadgets and gear. Subscribe to our newsletter and we’ll email our best stuff right to your inbox. Learn more here.
A researcher earlier this year found issues with several hundred Symantec-issued certificates, prompting Google to conduct its own investigation. After discovering that Symantec allowed other parties access to its certificate infrastructure and did not oversee the process sufficiently, Google Chrome developers said they “no longer have confidence in the certificate issuance policies and practices of Symantec over the past several years.” Symantec has promised to reissue all its Transport Layer Security (TLS) certificates to comply with Google’s new validity period requirements.
Those are only two examples. There have been missteps by other CAs over the past few years that have led to the current doubts about their trustworthiness.
What the different certificates actually mean
There are many reasons a domain owner may decide to obtain a TLS/SSL certificate, but the most common one is to give users a way to verify that the site is authentic and the owner is legitimate. Another reason is that—in this day of rampant surveillance, tracking, and eavesdropping—there is growing interest in encrypting all traffic moving from the user’s computer or mobile device and the web server hosting the application.
These are two distinct reasons for getting certificates, but both rely on HTTPS. That HTTPS reliance has made it easy for domain owners and internet users to conflate the two, causing further confusion beyond the trust issues, said Ilia Kolochenko, CEO of web security company High-Tech Bridge. “We should separate the HTTP traffic encryption and website identity verification questions.
There are three main types of certificates:
- Domain-validated (DV) certificates are checked against the domain registry but don’t require any identifying information to prove the owner is who it says it is. All DV certificates do is tell visitors the domain they think they are visiting matches the domain listed in the certificate. That lets domain owners be spoofed, though the sites have certificates.
- Extended-validation (EV) certificates tell visitors the owner of the domain they are visiting has been validated and is the real owner. To get an EV certificate, the requester provides information verifying identity, making it harder—although not impossible—to obtain a fraudulent one.
- Organization-validated (OV) certificates also verify identity, but they require less information than EV certificates, so they’re a bit easier to get fraudulently. However, they aren’t as common as EV certs.
Where the primary goal is to validate a website as authentic, the website should have an EV certificate. Thus, users know the CA has received proof that the entity applying for the certificate is the legitimate owner.
A user doesn’t need to view the actual certificate to tell that a website is using an EV certificate because the browser’s address bar displays the name of the domain owner next to a padlock. For example, for PayPal, in most browsers you’d see the closed padlock icon and the words “PayPal, Inc. [US],” then the actual PayPal URL with the HTTPS prefix. In Internet Explorer, hovering over the domain owner’s name also shows the name of the CA that issued the certificate.
By contrast, users can tell in most browsers if a site has only a DV or OV certificate because there is the padlock icon or the word “Secure” in the address bar next to the URL (again, with the HTTPS prefix). However, you won’t see the name of the domain owner also listed, as you do for EV certs. Though OV certificates require some proof of identity, it is not sufficient enough to get the green bar and domain name that EV certificates carry. The only way to tell the difference between DV and OV is to view the actual certificate.
Where the primary goal is to encrypt communications, it doesn’t matter what cert type a site uses—they all provide the same encryption of the communications in transit. A (cheaper) DV certificate can be sufficient if it’s not important for the domain owner to prove (via a pricier EV certificate) who owns the site (because there is no financial information or sensitive user information shared). OV certificates give you the worst of both worlds: pricier than DV without the security benefits of EV.
Regaining trust in certificates
TLS/SSL certificates have a usability problem because web browsers mark all HTTPS websites as secure—and users have been trained to look for the padlock or the word “Secure” to determine the site’s legitimacy. Yet all that padlock or the word “Secure” indicate is that the communications is encrypted. It doesn’t say the owner has been validated. A site can be encrypted and still be unsafe because the owner has been spoofed by a phisher or other malevolent force.
Web browsers have done a great job of making certificate information much more visible—but let’s break the overreliance on the little padlock.
Until browser makers fix how they indicate what is actually secured, all users can do is look for the domain owner’s name to be shown separately from the URL. That’s the only clue that the site owner’s identity has been confirmed. The padlock icon or the word “Secure” doesn’t tell you that.
But better showing which domains are validated, not simply encrypted, is not the only step the industry needs to take. It also needs to raise and enforce better standards for the CAs to follow. It is easy to rag on the free ones, but sloppy, cheap practices can happen to any CA, as Symantec’s case has shown. It’s just that free CAs make it easier for criminals to get a certificate, an inevitable result of making security more ubiquitous and easy to use.
I don’t agree with security experts who say free and low-cost CAs should filter our certain substrings to prevent phishing sites from spoofing popular brands. Such approaches put CAs in a very powerful position of deciding what kind of content can go online, which is a dangerous precedent to set. For example, PayPal shouldn’t have exclusive control of the substring; for example, a disgruntled user should be able to set up IHatePayPal.com.
But the industry can take action to raise the level of trust. Having better audit tools for certificate transparency and antiphishing filters would limit the amount of damage malicious websites can cause, for example.
Correction: This blog has been amended from its original version.
This story, "Trust issues: Know the limits of SSL certificates" was originally published by InfoWorld.
Keywords: ssl, trust, lost, issues, Internet, Security
Comments:comments powered by Disqus
General (120) IT (314) Microsoft (148) Apple (60) Europe (2) Google (82) Norge (12) Lokale nyheter [Vestfold] (19) Roblox (0) Roblox Game Review (8) Roblox Model Review (0) Roblox Plugin Review (0) Tutorials (29)