‘Secure’ in Chrome Browser Does Not Mean ‘Safe’
Google’s Chrome web browser is used by over 50% of users on the web. When you visit a website that is using SSL, otherwise known as HTTPS or TLS, you see a green message in your browser location bar that says “Secure”.
“Secure” in Chrome browser does not mean “Safe”. In this post I will explain why in terms that are easy to understand and tell you what to do about it. I’ve written this post to be easy to read. I’d like to encourage you to share it with friends and family to help them stay secure.
For our technical readers, here is a summary of what we discuss in this post:
- We show that SSL certificates are being issued by more than one certificate authority (CA) to phishing sites pretending to be Google, Microsoft, Apple and other well-known companies.
- A valid certificate causes Chrome to show a website as “Secure”.
- When a certificate is revoked once a CA realizes they should not have issued it, we show that Chrome still shows the site as “Secure”. The “revoked” status is only visible in Chrome developer tools.
- Malicious sites that have been issued valid SSL certificates take some time to appear on Chrome’s malicious site list. We show that the safe browsing list can not be relied on as a backup mechanism to protect users from malicious sites with valid SSL certificates.
What does “Secure” actually mean in Chrome browser?
In order for a website to be labeled as ‘Secure’ by Chrome, it needs to set up SSL on its web server. As part of that process, it needs to contact a certificate authority (CA) to get a ‘certificate’. The CA is supposed to verify that the website owner actually owns the website. This process is called ‘domain validation’. Other than verifying that the domain owner actually owns the website, the CA is not required to do anything else.
In Chrome, when you see “Secure” in your browser location bar, it means that the connection between your browser and the website you are connected to is encrypted. It also means that the person who installed the certificate on the website actually owns the site domain. It does not mean that the domain is “Trusted”, “Safe”, “Not malicious” or anything else.
LetsEncrypt is providing valid SSL certificates to phishing sites
Until relatively recently, CAs would generally not issue an SSL certificate to a site that is obviously trying to pretend it is apple.com or microsoft.com. However, there is a new CA called LetsEncrypt which issues free certificates to websites who want to use SSL.
LetsEncrypt has a noble goal. They are trying to make it free to use SSL to encrypt connections on the Web. However, they do not check to see if the website owner is pretending to be someone else. So the effect of this is that we are seeing many phishing sites that have a valid certificate issued by LetsEncrypt and which appear as ‘Secure’ in the Chrome browser.
Here’s an example of a website that is using a LetsEncrypt certificate and which appears as ‘Secure’ in Chrome. At the time of writing this (1am PDT on March 28th, 2017) this site was not listed as malicious by Chrome or the Google Safe Browsing list and is shown as ‘Secure’.
As you can see, Chrome says the site is ‘Secure’. The site owner is trying to pretend the site is the Google Play store. They are hoping that you will confuse the text after ‘.com’ with what usually appears after the forward slash on the actual Google Play store. This is an example of a phishing site that will try to trick you into entering your Google Play Store login credentials.
To view the information about this site’s certificate, you need to open up Chrome’s developer tools and view the security tab. You can do this by going to the View > Developer > Developer Tools menu.
Here’s what the developer tab looks like:
If you click “View certificate” here is what you see:
The certificate is listed as belonging to geoduo.fr but it is in fact used by many other websites. In the network tab you can see that list of sites: (Showing just the first few)
All of these sites share the same certificate. This can mean several things. It may mean that they are operated by the same individual. It can also mean that the hosting provider who hosts this site, OVH SAS France in this case, issued a free certificate to this site and lumped a lot of other sites into the same SSL certificate.
As you can see, “Secure” in this case simply means that you are talking to a malicious website using an encrypted connection. It does not mean the site is “Safe”.
The Problem is not just LetsEncrypt. It is other certificate authorities (CAs) too.
This problem is not just confined to LetsEncrypt, although they are by far the most common CA that phishing sites are using now. In the example below, the website is pretending to be Apple.com so that it can steal your Apple login credentials:
At the time of writing (March 28th at 1am Pacific Time) this site was not listed in the Google Safe Browsing list and Chrome was showing it as “Secure”. In this case the certificate was issued by Comodo.
Even if a CA revokes a certificate, Chrome still shows it as “Valid” and “Secure”.
Let’s take a look at the Comodo certificate in the above example. First we go to ‘Dev Tools’ in Chrome and open the ‘Security’ tab:
As you can see the Security Overview says the page is “secure”. Now let’s click on “View certificate”:
It turns out that this certificate has been “revoked”. What that means is that Comodo, the CA in this case, realized that the certificate belongs to a malicious website after they issued it and they decided to mark it as invalid.
Because Chrome does not check certificate revocation lists in real-time, it shows the certificate as valid in the location bar and the site as “Secure”. Chrome is unaware that Comodo has revoked the certificate after Comodo realized they should not have issued it in the first place.
You can’t rely on Chrome’s malicious site warnings from the Google Safe Browsing List
To do the research for this post, we used a service called Censys.io to look up certificates for websites that match specific patterns. Then we found other domains that are using the same certificates. Domains that share certificates are often related and may have the same owner.
The following is a graphic that shows a number of phishing domains we found in our research that are sharing certificates. In the graphic below, domains that are marked as malicious by Chrome are in red. The rest are green. The lines link domains that share SSL certificates.
As you can see the domains in this list are pretending to be either google.com or microsoft.com. Click the graphic for a larger view. Some of them are listed as malicious by Google’s Chrome browser. Most of them are not listed as malicious.
The good news is that these domains will eventually end up on Google’s “safe browsing list” which is what Chrome uses to identify bad sites. This list was generated on the morning of Monday March 27th and by the evening some of the green domains above were appearing on the Google Safe Browsing list and Chrome was warning about them. But it does take time.
While the Safe Browsing project that Google runs does great work, Chrome users can not rely on it to reliably identify malicious sites and throw up a warning.
What should you do to ensure you stay safe on the web?
The best way to protect yourself against malicious sites, in this case, is to check your web browser’s location bar and read the full website hostname that appears there.
Look at the location bar above. You should see ‘https://www.wordfence.com/….’. When visiting any website that you plan to exchange sensitive data with, check the full hostname after ‘https://’ and before the next forward slash. If you don’t recognize it or if it looks like it has some weird stuff on the end, close the window immediately and think carefully about how you ended up on that website.
Avoid clicking whatever link brought you to that website again.
What can Google Chrome do to improve security?
In my opinion Google actually does a pretty good job of staying on top of things. They responded quickly to our post earlier this year about a new Gmail phishing scam. They reached out to contact us and fixed the issue.
Chrome must start looking up certificate revocation lists in real-time to fix the Comodo certificate issue we showed above. Having Chrome show a revoked certificate as “Secure” is not acceptable. However, doing this has performance penalties for Chrome users and it may also have privacy implications as websites that are visited are sent to CAs during the lookup. So it’s not a simple fix.
I’d like to see the Google Safe Browsing (GSB) team using certificate relationships as we have used above to identify other malicious domains that should be on the GSB. They may be able to automate this. This will speed up the time it takes to get malicious sites listed on the GSB.
I don’t think the “Secure” designator in the Chrome location bar is good enough. The Chrome team should consider a sliding scale that takes into account who the CA is, how many domains share the same certificate and the age of a domain and its certificate. There are other signals they can probably incorporate to produce a security score, rather than just a binary “Secure” or “Not Secure” designator for websites.
What can LetsEncrypt do to improve security?
The LetsEncrypt team must start doing keyword searches on SSL certificate applications. This can be fully automated and LetsEncrypt needs to reject certificates that contain strings like “.apple.com.”, “.paypal.com.”, “.google.com.” and other common phishing patterns.
They could implement a review process where, if your certificate request is rejected, you can apply for a token which lets you bypass the check in future once you prove you need something with “.apple.com.” in it.
What about other CAs like Comodo?
In the example we provided above, Comodo actually realized the site was malicious and revoked the certificate. So they should be given credit for doing that. The problem was that Chrome does not correctly look up revoked certificates.
The way CAs issue certificates has been a source of debate for some time. Google has put a proposal on the table to revoke Symantec’s ability to issue certificates based on a history of bad CA behavior from them. The proposal suggests immediately revoking Symantec’s ability to issue EV (extended validation) certificates and to gradually mistrust regular SSL certificates issued by them.
There is a constant and lively debate between browser makers and CAs about how certificates should be issued and what constitutes a valid certificate.
Spread the word!
As browsers try to improve the way they represent the security of sites and CAs try to improve their processes, you can help secure the web by making sure you actually look at the hostname that appears in the location bar. Here is what a hostname looks like. It is the underlined part of the URL:
Make sure:
- You can see the entire hostname in the browser location bar.
- You recognize the entire hostname.
- Your browser says that your connection is encrypted. Chrome will show the word “Secure”.
Share this message with those you care about. Less technical users may see the word “Secure” and think it means the site is “Safe”. It does not. By explaining to your friends and family what a ‘hostname’ is in the location bar and getting them to double check it, you will probably save at least one person from being the victim of a phishing attack.
Credits: Thanks to Wordfence team member Sean Murphy who did the original research connecting malicious sites through their shared certificate use and developed the graph visualization. He also generated the data for this post. Thanks to Dan Moen for editing.
Comments
9:15 am
Do you foresee LetsEncrypt continuing to be a reliable and effective source of SSL certificates? I recently found out about LetsEncrypt and I have used them on a couple of my clients' websites, but I don't want to roll this out to the rest of my clients if it's not going to be a lasting solution.
Like you said, "LetsEncrypt has a noble goal", but are they going to last if they continue to be abused by malicious site owners?
9:17 am
I think they will last. And I think they will bow to pressure from the security community and start doing a few basic checks to see if a domain is a phishing domain before issuing certificates.
12:34 pm
If certificates are not issued automatically anymore by Let's Encrypt then it will break the many automated solutions that rely on it. Let's encrypt does not charge for certificates so manual labor would mean they need more money for which they rely on investors and donations. This would lead to their downfall.
If you consider the service they deliver and how it makes it possible for every website, even for hobbyist sites, to safely encrypt your PII and usernames & passwords, I think the pros outweigh the cons.
I find it strange that you would not consider this or even mention this in your post.
What I think that perhaps should be done about this, is a system with certain keywords that get flagged and which halt the automated process. But this should be done very carefully. For instance the appearance of both the word Google and the word com in the domain could be flagged. It's a difficult exercise to undertake.
What I do find very appalling is that Google Chrome does not alert of act on certificate revocation. This means that in the event of a stolen private key from a known internet site, this would mean security disaster.
Furthermore I think that educating the users to read the full URL in the address bar and be prudent is the best solutions. Users must learn to pay attention and not just click on everything.
12:58 pm
I did. See above: "LetsEncrypt has a noble goal. They are trying to make it free to use SSL to encrypt connections on the Web.".
Agreed again, as I said in the post: "The LetsEncrypt team must start doing keyword searches on SSL certificate applications. This can be fully automated and LetsEncrypt needs to reject certificates that contain strings like “.apple.com.”, “.paypal.com.”, “.google.com.” and other common phishing patterns."
1:03 pm
How about changing the address bar so that visually the protocol (https) ,subdomain, domain, and the path after it are shown separately. And that the protocol part is in a green color, and the domain as well for EV certification.
By separating the domain and the path behind it, would make it easier for users to see specially crafted domains that try to mislead them.
1:11 pm
That's a great idea.
5:52 pm
BEST idea I've seen. Get this off to the Chrome team ASAP.
4:56 am
The best idea I have seen in a long time. The original idea behind SSL's is to encrypt data from one point to another, so it is private. There needs to be a way for organisations to protect their identity, which does not rely on SSL's. This is where the security gap is and it is being exploited by the hustlers. Color coding works for me!
5:35 am
Excellent. This problem has a partial solution by using design.
9:41 am
That would be really useful.
9:20 am
Lets Encrypt should not issue certs with apple.com, and the top 50 other companies in them no exceptions. That means apple.com can't get free certs. I'm sure they are ok with that.
Also
Lets Encrypt should not issue certs for more than one sub domain deep. Ever.
If you want a cert on something that is outside of those parameters, pay $100 for it. Simple.
9:25 am
It really is the responsibility of the user to protect himself - nobody else should be expected to.
That being said, I think the most important thing that should happen is for a lot of good information to be disseminated about how a security certificate only really means that a site is encrypted, not that it is a legitimate business which will protect your information.
While some CAs provide certificates that purport to verify legitimate businesses, there will always be methods of circumvention. A diligent user should (MUST) always protect himself the best way possible, and that's by information and suspicion.
Yes, browsers would do well to report relevant info about a certificate, such as revokation status.
Yes, CAs should revoke certificates that are obviously illegitimate.
But I think the article implies (though maybe unintentionally) that Google and Let's Encrypt are doing something wrong, when in reality, at worst, it could be said that they should do something a little differently to help users.
9:41 am
They should be doing something differently and I laid out clearly what they should change.
1:51 pm
Mark, I wasn't attacking the article (except to say the implication might have been strong, and noted it was possibly unintended) or you. I agree with the article, apart from that.
My main point was that the best way to make sure a user is safe is to teach him the truth about what encryption means because phishers and hackers will always find ways to circumvent proactive attempts to block them such as CA initiated cert revokation or denial.
As I said, yes, LE and Google should do what you suggested, but they aren't doing anything "wrong", so to speak.
10:21 am
Blaming Let's Encrypt and Google for this "problem" is like blaming green traffic lights for causing traffic accidents.
A green light means that certain drivers and pedestrians are allowed to proceed, it does NOT relieve those drivers and pedestrians of the need to establish whether or not it is SAFE to proceed.
Let's Encrypt has ZERO responsibility to check for phishing — that is neither the function, purpose, nor promise of their service. They do not issue Extended Validation Certificates!
If USERS are misinterpreting the word "secure" in the address bar, then that is a UI design issue that Google should consider improving. Let's leave Let's Encrypt out of the picture here. They are providing an extremely valuable service at no cost.
8:11 am
Amen to that. Ultimately it's your own responsibility, and your own only, for your actions. I love it how people blame others for their ignorance, stupidity or otherwise.
7:46 pm
The thing I think everyone needs to remember is that not everyone using the internet are experts or even familiar with security and SSL. I don't think Mark is trying to blame Google or LetsEncrypt, I think he is just suggesting better ways to improve internet security. Yes it is people's responsibility to use the internet in a safe manner, but it is also the developers responsibility to make it as safe as possible. The people that designed the traffic light system made it as simple as possible so drivers could use the lights to be safe.
I commend Mark and his entire team for what they do. Wordfence is an amazing company that does top of the line work in internet security. If developers just sit by and allow those being scammed because they don't have the technical information to protect themselves then they are just as guilty as those that perpetrate the scam. I don't think Mark is attacking Google or LetsEncrypt, I think he is simply pointing out flaws in the system and suggesting better ways to protect everyone. I think that is great thing.
Great job Wordfence, keep up the excellent work you do!
8:02 pm
So many people can barely use a web browser - it is (unfortunately) unrealistic to expect users to be totally responsible for their online security.
Professionals and business need to do everything in their power to make the web safe, or ecommerce will suffer.
9:14 pm
Thanks for the comment Hank.
I think this needs to change. Using a browser and a mobile device need to become like walking and breathing and they will. Just like walking, users will eventually learn the difference between a bad neighborhood and a good neighborhood. Parents will teach children to not wander through dangerous areas at night. Cyberspace will become completely integrated into our daily lives from birth including how to be secure in cyberspace. We are in a transition stage right now.
Mark.
4:02 am
well, you tell me: even if you want to - can you see all needed domain details here ? http://imgur.com/a/0emir - it is the domain you gave as example. You see the exact "good" part of the bag url.
User has to click on the address bar... and investigate.... complicated.
A better solution is indeed - that all browser makers should agree to a color/format/convention of a domain in the address bar.
9:34 am
You should also point out that legitimate financial institutions almost always have EV certificates that include their names, precisely to help distinguish them from phishing sites. The real PayPal site doesn't say "Secure," it says "PayPal, Inc. [US]." And it's not possible to get THAT kind of certificate without actual human review.
Unfortunately, Google doesn't have an EV certificate...which is kind of silly, given that I'm sure they could afford one.
9:43 am
Thanks Sallie. The article was already pushing 2000 words and so I had to pick my battles. There's an interesting discussion in the industry around EV. It used to be that you would have to get a DUNS number as a company and get what amounted to a credit check to get an EV cert. I'm told that is no longer the case, although haven't confirmed it first hand. Also as I mentioned, Symantec's EV cert issuer status is under review/debate right now.
9:40 am
You think 14,000+ certs with the word paypal in them would raise a flag.
9:43 am
You would. :)
9:45 am
Interesting article with many key points. I do have a question, though:
It's still better to have a website running with a free SSL certificate (like one issued from a CA like Let's Encrypt) than to have one running with no certificate at all, correct?
10:30 am
Yes, that is correct.
9:45 am
Great article, well worth forwarding to users given the rise of LetsEncrypt, and the prevalence of Chrome. Small correction maybe? The sentence:
"The problem was that Chrome does correctly look up revoked certificates."
should probably read:
"The problem was that Chrome doesn't correctly look up revoked certificates."
10:29 am
Thanks Greg. Fixed.
9:45 am
Excellent analysis and very informative article, I had just started to look at Let's Encrypt for a project.
9:52 am
Thank you for your detailed analysis. What about Mozilla FireFox? Does it also have the non-realtime CA lookup?
10:03 am
A couple comments:
One thing Chrome and other browsers could do is make a distinction between "encrypted" and "verified". Replace the word "Secure" with "Private". For CAs that do domain authentication, show "Verified". Easy-peasy. I'm not saying every browser user will know what these terms mean, but tooltips could elaborate - and either way that would at least prompt the curious to Google the difference.
I think suggesting that LetsEncrypt try to do some sort of keyword search on domains used in certificates is unrealistic and unlikely to help, while introducing a lot of technical and logistical overhead for them that interferes with their mission. This is for a few reasons:
One, exactly which keywords get searched? No matter who is on this list, someone else will have the argument that their name should be on there too. 10 strings to match against may not be that burdensome but 20,000 is crippling, and anything near the scope of "all legitimate businesses on the internet whose customers are vulnerable to phishing scams" is literally impossible.
Two, I think you're underestimating the number of false positives you're going to get. For example about a decade ago I worked for a small web company named "thebestapple.com". We weren't trying to pass ourselves off as associated with Apple the computer company; I think it was more of a pun on the idea that there were a lot of "bad apples" in our business or something like that... but anyway, the scope of this problem grows as you add more brands to the cross-checking list.
Three, false positives may be perceived as more harmful than occasional negative consequences. A hundred people who get hit by phishing scams sucks, but LetsEncrypt doesn't necessarily get blamed. A hundred people trying to get certificates, getting rejected for vague reasons, and then having to go through some bureaucratic process (which will still sometimes fail) could create the perception among small websites that it's not worth the hassle. Remember they have to convince people to do this for _free_ and it's still a hard sale; introduce a bunch of additional burdens and bureaucracy and nobody will bother, since after all, non-HTTP is "not broken", why fix it?
So more clarity is necessary, but putting the burden on LetsEncrypt to solve the problem is asking them to tackle something outside their domain, capability, or competence. They're in the business of improving privacy, which although related to identity theft, is a different problem from malicious misrepresentation.
5:30 pm
@Justen I was going to say exactly the same thing. The word "Secure" is completely misleading.
The purpose of SSL is primarily to encrypt communications and that is all that LetsEncrypt does and all it promises. LetsEncrypt is a fantastic solution with the aim of encrypting the entire Internet and it should be promoted and applauded for doing so.
But to suggest that a site is "Secure" just because communication is encrypted is wrong.
I think it would be best to have use the word "Encrypted" for certs like LetsEncrypt (and many of the cheap SSL registrations) and only use the word "Secure" where there has been a separate verification of ownership.
9:12 pm
I'd agree with avoiding the word 'Secure' which implies safe.
10:05 am
Looks like an error in this sentence: "The problem was that Chrome does correctly look up revoked certificates." Perhaps that should be "… does NOT correctly…"
10:30 am
Thanks Paul. Fixed.
10:21 am
You have to admit though! This knowledge is way beyond your typical user! I consider myself quite tech savvy but did not know to dig deeper into certificates and actually see who/by whom and for whom this certificate is issued.
Other uses, (and they are A LOT), won't even bother check and see if it is even marked as 'secure'. This is scary stuff!!
10:24 am
I like the Firefox idea where they dim the url apart from the actual domain name.
10:51 am
I am concerned about your comment regarding Google action towards Symantec for issuing unreliable certificates. Does this issue affect Norton Safe Search toolbar? Are sites listed there as "safe" really safe?
11:27 am
I'm not sure if it affects their toolbar, without further research. If I had to guess I'd say no. That sounds like a site review service rather than anything related to SSL certificates.
The Symantec Google SSL story is all over the news:
https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=symantec+google+ssl&safe=off&tbm=nws&*
10:51 am
Perhaps your idea of underlining the active part of the URLin red, should be implemented as a standard feature on browsers!
Many thanks for a great article I had similar thoughts when signing up for LetsEncrypt.
11:26 am
I actually really like that idea. Thanks Geoff.
11:03 am
GRC has been warning about this very issue for a long time, and in particular that Chrome does not have any way to fail on a revoked certificate. https://www.grc.com/revocation.htm and https://www.grc.com/revocation/implementations.htm go into some detail on this.
12:15 pm
LetsEncrypt has been a huge lift in to my ability to serve customers well.
I agree with the commenters who have suggested this needs to be about the browsers doing a better job of:
1) indicating encryption vs. domain validation vs. extended validation
2) better domain name highlighting
3) issuing warnings for top domain names appearing within longer domain names; the registrars might also be able to help in this regard, by flagging such registrations for some type of review, prior to issuing the domain name.
#3 might also help curb brand and trademark abuse by third parties.
12:55 pm
In a similar fashion to Let's Encrypt suggesting that it's not their job to stop scrammers generating certificates for phishing etc. Google only seem to be interested in the security of the browser itself, not the content being browsed to. I guess that's fine on desktop where you can install extensions that can secure your browsing further. Unfortunately Chrome on other devices can't have these additional things added.
1:00 pm
Google Chrome does care about the content of sites you browse to. That is why the have a Google Safe Browsing list that Chrome uses to warn you about unsafe sites. They even split the list into phishing sites and malware sites, based on the site's content.
1:27 pm
Hi Mark,
I just had my hosting company WestNic install the Let's Encript SSL software on my site. In response to your first article about the need for end to end encription. When I read your second article Secure does not mean safe which talked about Let's Encript I became alarmed.
I went to Qualys Labs ssl analysis tool and ran an analysis on my site. I was futher alarmed by the fact that this report indicated that a second ssl certificate was installed to a site in Turkey marketing SEO services. That site in the report was listed as NOT Trusted.
Further that site had a field in the report called chained which says there are an additional 4 ssl certificates.
Of course I immediately asked the hosting company, who installed the Let'sEncript software on my site to remove it.
But I was wondering if there is the possibility of any damage to my site from this. What actions do I need to take?
I would assume that one of the problems of having your website ssl certificate lumped together with untrusted website is that people would come to not trust the ssl certificate and safety at your site. But can the ssl certificate, which is installed at the server, actually introduce malicious code to your site.
If you want me to provide you the link to that Qualys SSL report just let me know.
Thanks in advance for your help.
All the best,
Ted Sudol
9:11 pm
Hi Ted,
I think there's some confusion here.
Having an SSL certificate is a good thing.
Having other sites share your SSL certificate is not a bad thing.
Using a LetsEncrypt certificate is fine.
The blog post above is focused on protecting site visitors from visiting malicious sites. Your site is not a malicious site.
What we are worried about is malicious sites who are able to get free SSL certificates and which have domain names that pretend to be well known companies. We don't think the certificate authorities should be giving those sites SSL certificates.
We're also concerned about Chrome not showing when an SSL certificate has been revoked.
So by all means, use SSL, use LetsEncrypt SSL, share the SSL certificate with other sites if you have to.
An SSL certificate can not introduce malicious code to your site.
Mark.
2:16 pm
Thank you for this!!! Cert revocation in Chrome has always been so annoying, Firefox seems to immediately not trust revoked certs. I've also seen Chrome support an HTTPs connection to www.domain.com with a cert that was only valid for domain.com (neither CN or SAN supported the www.domain.com version). As much as they preach security and force the Internet to heed to their standards, their browser is really lacking some basic features and security checks.
4:57 pm
I'm curious as to why you focus solely on the Chrome browser. I'm a long-time Firefox user (surprised that Chrome now has 50% of the market!) and I'm left wondering if (a) Firefox does not have this problem, as you did not mention it, or (b) you simply choose to concentrate on the market leader, and so Firefox's state is indeterminate (in the context of your article).
Very interesting material anyway, thank you!
9:12 pm
Hi Brad. I simply focused on the market leader with over 50% share. Firefox has 16%.
1:42 am
First of all the browser will mark the website as secure because it is checking for a successful SSL connection to the requested URL which the server is returning. There is no difference if the site contains phishing or malicious content, because when a site has a valid SSL certificate installed that means all information between the client and the server would be encrypted which is the main idea of the SSL certificates.
Google will show you sites which are marked as malicious only in case they are reported, and there is no matter if the site has an SSL encryption behind or not.
If there is no word "Secure", what you will tell to your readers? That the green padlock does not means secure?
"LetsEncrypt is providing valid SSL certificates to phishing sites" - that will only confuse all non-technical readers. You want to know why?! Because most of the hosting companies are providing their certificates and that will not leave a good impression if a reader see а sentence like this one.
Let's encrypt are issuing certificates based on a server verification. That means when a hosting account owner is requesting a certificate the Let's Encrypt module installed on the server's management system is sending a request to the server of Let's Encrypt. Then Let's Encrypt is checking if the SSL certificate is already installed and if the domain is resolving from the same IP as the server from which the request was sent. if this account owner has a phishing website, does that mean all sites hosted on this server are too?
How Let's Encrypt would know if a domain is used for phishing purposes?
Also you can request SSL certificates for any domain containing words close to google, facebook, amazon and etc, which would be used for any bad purposes, because the SSL issuing process is requiring only a successful verification from the domain owner.
7:56 pm
I think that is why Mark is suggesting that the SSL issuing process should be more than just requiring only a successful verification from the domain owner. Many CAs do more work than just a simple owner verification. And I think it is obvious that CAs should not issue certificates for any domain containing words close to google, facebook, amazon and etc. This would easily reduce the amount of phishing sites getting SSL certificates.
2:48 am
Well researched an well written article. I have one beef, though. You made this out to be an issue for Chrome only. Send like all modern web browsers would be equally susceptible to this. As far as I know, none of the other browsers - Firefox, IE, Edge, Opera, etc. - perform real time CRL checks.
True, Chrome accounts for over 50% of browser traffic today, but that's no reason to exclude the rest.
7:36 am
Thanks for the good info, Mark, as usual.
We shouldn't let Chrome cert revocation, which has always been a problem as far as I know, obviate the fact that Let's Encrypt has led the way to more affordable certs from the rest of the CAs. I got offered a full-on green bar cert for 90 bucks this year!
1:57 pm
Chrome shows this site (wordfence.com) as not secure. There doesn't seem to be any reason other than perhaps the number of cookies. Strange?
10:57 am
Yes. I suspect it's an issue with your browser. This is the first and only report we've received and we have a team of over 30 on the site daily along with 10s of thousands of visitors. If you can click on the 'Not Secure' icon and send me a screenshot I'd appreciate it. My email is mark at wordfence dot com. Thanks.
4:51 pm
When I access an Apple site using chrome I get a padlock then "Apple Inc. [US]" rather than "Secure". This helps my confidence that I am on an Apple site. Why doesn't it work this way with Google and Microsoft?
You have a lot a good information in this post.
Thanks.
12:36 pm
David, the Apple site is using an Extended Validation (EV) SSL certificate, while the other two sites you had mentioned are using Organizational Validated (OV) SSL certs. EV certs are a higher class of OV certs (requiring much more validation) and browsers treat them specially by listing the company name in the address bar.
2:09 am
AFAIK, Letsencrypt runs the same basic verification for domain's owner as other CA which provide regular certs.
9:42 am
Except that they don't do the "high risk domain checking" that other CAs do. They check Google Safe Browsing API before they issue. Of course, Phishers know this so they don't put up their phishing site until after they get the cert. Hence Safe Browsing won't catch it. Other CAs have blacklists that catch many attempts at alterations of popular domains.