The CA's Role in Fighting Phishing and Malware

It is really stupid to add an CA to the certstore, include the private key for the CA in the computer of each customer.
And then also tell that this is used to protect data collected from the customer PC for transmission. I think even an student
i the first semester would fail with such an software approach.

1 Like

The Safe Browsing API check is a good point in time check, at the time of issuance. However, the API should really be frequently monitored post certificate issuance as well. Negative changes in domain status should generate a revocation event.

Without doing this, we are only incentivizing the bad guys to stand up a ‘safe site’ until after the cert has been issued. That just doesn’t make sense, and doesn’t convey ‘trust’ from a CA, or protect end users.

1 Like

You cannot revocate a cert automatically based on an API, it can have false positives or maybe someone can do something to flag your site and revoke your cert.

Yes, you are correct. Ideally you should have a person in between to logically inspect before revocation.

However, this system is unique in that there is no monetary penalty for requesting a new cert. So while I would agree with you in a standard CA system (where folks are touching the validation and issuance by hand), in this system it may actually be more appropriate to tie revocation to the safe browsing API.

It is not like the CA is inflicting any greater harm on the web site operator than the web browser already is (where the browser is checking safe browsing and controlling user presentation and access based on safe browsing).

Wearing the site operators hat, I’d expect to get notified of this revocation - which I would actually consider a valuable service, because it is not like Safe Browsing is notifying site operators when their site is added to the list. At least this way the CA adds value and I as the site operator can inspect my site and see what is happening.

2 Likes

No, the problem is with people who don’t understand what a (DV) cert certifies. It’s not a magic seal that certifies a lack of malware or something like that. A CA’s job is not to vouch for “safe sites” or “protect end users”.

If you ever told people who know even less than you do, that a website is “safe” if it has valid HTTPS, then you were doing it wrong. Plain and simple.

7 Likes

6 posts were split to a new topic: DNS spoofing questions

Not sure if this danger has been mentioned before, but if this also applies to renewal, this means that previously secured sites can suddenly lose their TLS, because they are listed in Safe Browsing - including when that happens erroneously, and it’s not exactly a secret that this occurs with a non-negligible frequency.

Additionally, if an adversary can trick Safe Browsing into falsely believing that a site carries malware, they can intentionally deprive a site of access to a TLS certificate.

I’d argue for removing this ‘verification’ as soon as possible, given its actively harmful potential consequences.

1 Like

If an adversary can do that, they've also just ensured that a large majority of users won't be able to access the site at all.

Additionally, the default renewal schedule means you'll have at least 30 days to get your site off the list or find some other solution. If you're concerned about availability, you'll need to be monitoring your certificate lifetimes anyway, so this isn't really a new requirement.

While correct (and there have been a few cases of this happening), it still removes the choice of the user to ignore this warning (eg. if they know that this is the case) and still be assured of a secure connection, as the server can't have a valid TLS certificate. It'd still make the problem worse.

Sites have historically been on Safe Browsing incorrectly for longer than that.

I think getting off the list probably is manual while getting on the list may be automatic but even if not, getting off will probably take some time.

Any update on this area? Statistics of numbers of cert requests rejected due to Google Safe Browsing API hits?

Are issued certificates revoked if Google Safe Browsing API reports an issue after Let’s Encrypt cert is issued?

Thanks, John P.

The API is only checked during issuance.

1 Like

I want to put in my opinion here. I readed the whole blog post, and I really don’t agree. Sometimes you need to be able to scan after malware or phishing at the perimeter.

I think this will be going for a never-ending fight against phishing and malware. And this with TLS/SSL actually made it harder to block phishing/malware, as the path of the request is hidden using the encryption, which makes it harder to use blocklists like squidGuard to block phishing/malware. Yes, you can block via IP or domain, but thats not a entirely failsafe method. To not to say all malware and drive-by-downloads that slip through. Got one from some SSL site that infected my system with casino adware with ads@boot. Without clicking at anything, Microsoft Edge just auto-downloaded the rubbish and then created lots of icons on the desktop, and bizarre files in /temp and /system32 like uac_skip.exe and other garbage.

Due to that, my networks that I own now fully uses HTTPS Content inspection on my firewall, with a CA root imported in every computer.

IMHO, today, SSL have gone amok. Now SSL is more malicious than safe.

But theres one thing you can do to solve this:

Require a admission to start using Let’s encrypt.
A admission fee that is only one-time. Yes, only One-time for the life time. The admission fee could be like 15$ or something, too expensive to create accounts on a rolling band, but cheap enough to still keep up the SSL incentive for non-malicious sites.
This admission fee gives you a account that you can use along with Lets Encrypt software to create certificates for a limited number of domains, like 100 domains or something like that.
For payment, there could be required using a payment method that makes it possible to identify the end user, like a verified paypal account or something else.

And then, Let’s encrypt checks regularly if your domains happens to host malware or phishing. you get a one-time warning (one warning per domain) and 30 days to fix the issue. If you don’t fix the issue, then your access to Let’s encrypt is permanently revoked for all your domains. And fix does not only mean that the malware/phish should be removed, it should mean that you should remove the underlying issue why the malware/phish happened to appear there at all. (But this part isn’t verified, but if malware or phish get on the same domain for a second time, then its bye-bye without any warning)

Each account could also be limited to like 10 warnings to prevent phishers and malware actors from constantly changing domains to evade the warning system.

Of course, the “fixing” action should not require you to be removed from Google’s malware/phishing list, because sites could end up there for long after the issue is fixed. Instead, the issue fix could be verified in a another way, maybe that there some community system where people can vote “Does this site phish” and then a link to the page, and then users can vote. If the administrator did take down phish, then vote will clear and then a “whitelist” could be used to tell the system that certificates should still be issued. (but not if a new entry appears in Safebrowsing API). Of course, the phish voting system must be made in a secure way, incase the site is malware-infected aswell, check Phishtank how they have done that.

For malware, its unsuitable to let users vote, in that case a automated scanner with antivirus program could be used to verify if the issue is fixed. Possibly the same as google safebrowsing uses, and then the “listed url” is rescanned for malware, and also some “common urls” that are known for that website.

This prevent phishing actors and malware actors from creating new domains, as their payment account cannot be linked to a new Let’s Encrypt account, thus they need to get a new payment account, which means getting a new card from their bank, and verifying their details, which may cause paypal to request ID and then its linked back to the old account = malware actor’s is stopped in its tracks.

I think you should start checking safebrowsing for renew too, not only for initial issue. And also I think it would be a good idea to regularly check and revoke any certificates that happen to end up on malware/phishing lists.

Also one good blocklist to use would be malware.com.br , those have a blocklist that is a bit more “aggressive”, but requires a commercial license to deploy for Let’s encrypt.

It seems to me like you've provided the solution yourself: Scan HTTPS content using a MitM proxy! Nearly every enterprise network does that, and most endpoint protection software has that capability too (although I don't think endpoint protection/AV software adds a whole lot of security to a system, as demonstrated by a huge number of vulnerabilities found by Google Project Zero, but that's a different discussion.)

Given that the goal of Let's Encrypt is to get the internet to a point where TLS is used for every connection, adding a monetary requirement would pretty much guarantee that this never happens. Additionally, Let's Encrypt was not the first CA offering free certificates (StartSSL and WoSign did as well), so I fail to see why this suddenly became a problem when no one complained about it for years.

I'm sure every eCommerce site will be happy to know that using something like PayPal will guarantee that the account information is accurate and that they don't need to deal with fraud anymore. (No, that's not the case. You can buy legitimate-looking PayPal accounts, CC numbers, etc. on the internet. 15$ + the price of a stolen PayPal account in exchange for 100 domains that can be used to spread malware doesn't sound like a bad deal to me.)

Why is this something the CA should do? Why are you not asking your OS vendor, your browser vendor or your AV vendor to scan every single site on the internet and essentially whitelist/blacklist them as needed? Also: What makes you think that a CA would do a good job doing this particular scan? Operating a CA and detecting malware are completely different things.

Additionally, your counter-measures are not very useful. 30 days to remove malware is a very long time. Most malware sites aren't online anywhere near that long, they tend to rotate domains in a matter of days. All browsers have mechanisms to block known malware pages, and those will be significantly faster at blocking those domains.

1 Like

Scan HTTPS content using a MitM proxy!

Yeah. One problem is BYOD/Hotspot, which I now have to provide a captive portal which forces them to install the CA root to access the internet (by using HSTS to check if the certificate is correctly installed before giving them internet access, as condition to authenticate to the captive portal)

Given that the goal of Let's Encrypt is to get the internet to a point where TLS is used for every connection.

But is that really good? Im thinking more that it can hurt more than it solves?
About StartSSL and Wosign, its not really that bad, their limitations are pretty strict and they often require manual verification already after the second certificate. And actually, they also have a good system for detecting fake accounts, if you try to create a fake account, the system detects this and requires you to go through manual verification. They have a lot of logic behind, for example with IP-adresses, mail adresses, phone numbers and such.

And you can only get certificate for one subdomain for free. Let's encrypt took that a step, IMHO a bit too long forward.

I'm sure every eCommerce..

I was just brainstorming a solution. The idea is that once malware is detected, the user is blocked off. Do you have some other ideas on how users can be banned in a way that getting a new domain won't get them on tracks again? Maybe verify via mobile phone number, but here burner numbers could be easily got. Maybe a computational puzzle that they must put their computer/server to solve, and that puzzle will take like 1 month to solve (and of course state is saved between poweroffs). This puzzle is then only needed during register of account.
The problem can however be botnets that solve puzzles for them. But you might understand how im thinking? Once a user is blocked off, it should be difficult for that user to regain access, regardless of how many new domain that user buys.

Why is this something the CA should do?

Why not? I think that since SSL allows somebody to hide information, especially from trusted persons like ISPs, Network administrators, government, and similiar fully trusted persons, I think there should be a vetting process to ensure that this power, of being able to hide data, should not be used for malicious purposes. With great power comes great responsibility.

The 30 days for the first 10 domains, one for each domain, is to ensure that people that run forums and file hosting sites and such, are not immediately shutted down for accidentially having a malware uploaded on their forum. To prevent this from misused, this was exactly why I suggested 10 warnings per account max, or even lowered to 5 warnings. The time could be shorted but people get on holidays and such. Maybe 14 days would be enough? But those people then still need to disable certain file uploading functions (like .exe, .html, etc) because the second time malware comes on the same domain, user is shut off without warning.

Doesn't you think, the power of hiding information, is something only trusted persons should get?

Who says that ISPs or the government are "fully trusted persons"? Mine aren't. Neither my ISP nor my government has any business knowing what traffic I send across the wire, and neither of them should have the capability to find out if I choose to conceal it. Network admins already have tools to allow them to bypass TLS on their own networks if desired--their network, their rules.

Secure communications are not a privilege, to be granted sparingly only to those who have shown themselves worthy. Just as freedom of expression is a fundamental human right, so is freedom of private communication.

3 Likes

@danb35

So if your ISP installed some content inspection proxy to block all virus infected files, you would scream at them “You have no business in my traffic” instead of thanking them for removing malicious content?

I disagree. This is about a perceived feeling of security, not actually something that can be measured. As an example: Many CAs were criticized a while back for issuing certificates to phishing sites - Comodo being the biggest used by 40% of phishing sites that used TLS.

You can get one subdomain per certificate, but you can get any number of certificates. I fail to see how that would make a difference?

I understand what you're saying, but I don't want CAs in the business of malware protection at all. That's a job for OS vendors, browser software and security products. CAs connect domain names to public keys, that's all.

Which government? The CA operates by a set of law that's different from the one in my country. I certainly don't want to be governed by the laws of another country, and I certainly don't want any government in a position where they could deny anyone the use of TLS. And as you yourself said, it is very much possible to scan TLS traffic if you're a network administrator. Let me put it this way: You're suggesting that you shouldn't need to scan TLS traffic, and that the CA should be responsible for ensuring a site is fine. You suggested that CAs should revoke certificates after 30 days (by the way, while we're talking about revocation, that doesn't really work anyway) if malicious content is detected. Are you really comfortable with a solution where you're vulnerable for 30 days, or don't you think it would be a better idea to make sure your security mechanisms protect you even if a site is using TLS?

If my ISP wants to offer that, and I decide I want to trust them with all my plaintext traffic, then they can ask me to install a CA certificate.

4 Likes

I don’t think I’d scream at anybody, but if they did that surreptitiously, without making it an option, I wouldn’t be pleased. There are a few problems with your suggestion:

  • Virus scanning is far from an exact science, and false positives happen. I don’t want my ISP blocking non-malicious content.
  • It’s not my ISP’s job to protect my network, it’s mine. Their job is to give me an IP address and bandwidth.
  • It opens the door to the ISP deciding that other content is undesirable, and blocking it. Perhaps they offer an overpriced phone service, so they block or degrade other SIP traffic out of your network. Or perhaps they’re owned by an entertainment company, so they block or degrade Netflix traffic. This is not a slippery-slope hypothetical; ISPs have done these things.
  • It opens the door to the ISP interfering with traffic, such as altering web pages to insert their own advertising. Again, this has happened.

Now, if the ISP wants to scan cleartext traffic for content they consider malicious, there’s nothing I can do to stop them. But I maintain they have no business doing so without the request, or at least permission, of the subscriber.

5 Likes

That's the best conclusion I've read in this matter.

So, do one thing and do it well. It's an approach that's proven it's advantages since the early 1970's.

1 Like