A Call To Let’s Encrypt: Stop Issuing “PayPal” Certificates
1 Star2 Stars3 Stars4 Stars5 Stars (21 votes, average: 3.62 out of 5)
loadingLoading...

A Call To Let’s Encrypt: Stop Issuing “PayPal” Certificates

Data shows wide-spread use of certificates for phishing

This is an open letter to Let’s Encrypt regarding its issuance of certificates containing the word “PayPal.”

Within the SSL/Certificate Authority industry, there is an ongoing debate about SSL certificates for malicious websites – the big question is if CAs should be policing the content and nature of the sites they issue certificates to. Should CAs be filtering out and rejecting certificate requests if they believe websites will use them for phishing or malware distribution? Should CAs revoke certificates for websites that are reported and proven to be involved in these activities?

Prior to Let’s Encrypt, all major CAs supported the view that certificates for malicious sites should be rejected or revoked, and Let’s Encrypt has stirred the pot by taking such an aggressive stance on the subject.

Josh Aas, Executive Director of Let’s Encrypt, has previously written about his view on a Certificate Authorities’ responsibilities. They think it’s not a CA’s job to determine if the site requesting a certificate is safe or legitimate, and that even when one tries to, CAs aren’t very effective at blocking the “bad” sites.

As a result, Let’s Encrypt forgoes the pre-issuance checks that CAs have traditionally used to block “high-risk” requests likely to be used for malicious reasons, such as phishing. Instead, Let’s Encrypt defers to services like Google’s Safe Browsing and Microsoft’s SmartScreen which identify and block dangerous sites at a different layer.

Most of the commercial CAs disagree with Let’s Encrypts position and this is a topic that is frequently debated. For more background on this topic, I suggest reading this great post from Eric Lawrence, which inspired this post.

I am not asking Let’s Encrypt to change its larger position. I respect and understand its view, and think it’s a sensible position given its goals as a CA.

Given that the content filtering debate is such a heated topic, I would like to sidestep it all together and ask for something much simpler:

Stop issuing certificates containing “Paypal.”

Certificates containing the term “PayPal” are being pervasively abused, and the continued issuance of these certificates poses a danger to the web by bestowing legitimacy to phishing sites. Let’s Encrypt can address this without impacting its users or its mission.

That’s it. That’s all we’re asking. Now you may be thinking, wait, isn’t this content filtering?

As other CAs implement it, filtering involves complicated blacklists, submissions to multiple reputation and spam services, manual review processes, and a constant whack-a-mole game figuring out what misspelling or homonym the phishers are using this week.

There is no way for Let’s Encrypt to implement similar measures without it compromising its mission or incurring large costs in developing, maintaining, and reviewing such measures. I think it is unfair to ask for that.

Instead, simply blocking “PayPal” (and literally just “PayPal,” no variations or misspellings) is an easy, feasible, and effective measure against the most dangerous and malicious use of Let’s Encrypt certificates.

When Eric published his post, Let’s Encrypt had issued 709 certificates containing “PayPal.” Now that number is 988.

988 Let’s Encrypt PayPal certificates.

Here is an example of one of these phishing sites:

Let's Encrypt PayPal

Can you honestly say this could not trick an everyday user? What about an educated user? What about you?

Some internet users “look for the lock” as an indicator to tell if a site is legitimate – this was common advice when CAs were hard on phishing. Even Google was giving this advice as recently as last month (to its credit, the company fixed this once it was pointed out). While there is good reason not to teach users this anymore, it’s already a learned behavior for some. Now that Google Chrome displays “Secure” next to the padlock for all HTTPS connection, the risk of associating HTTPS with legitimacy is higher than ever.

Paypal is one of the most common targets for phishing due to its popularity across the world, especially in developed countries. The better that phishers can imitate the real PayPal.com site, the more effective their schemes can be. Having “PayPal” spelled correctly in the domain name combined with the browser indicators of HTTPS – made possible with a Let’s Encrypt PayPal certificate – helps create the best imitations.

Let’s Encrypt PayPal Phishing, A Unique Threat

Let’s Encrypt certificates containing “PayPal” are overwhelmingly being used for phishing, and they pose a substantial and unique threat to innocent users.

Using Censys.io, which has a corpus of more than 40 million publicly-trusted SSL certificates, we found that prior to Let’s Encrypt there was not widespread issuance of phishing certificates containing the term “PayPal.” According to the Censys database, between August of 2012 and August 2016, all other CAs combined have issued 258 certificates containing “PayPal” that were likely used for phishing.

Let’s Encrypt has issued nearly four times that many, the majority of them since November 2016, which is a significantly faster rate than previously seen. If the current rate continues, the number of Let’s Encrypt PayPal certs will double to 2,000 by April.

We looked at the 988 Let’s Encrypt PayPal certificates to see how they were being used. The vast majority were phishing sites. Only 4 of the 988 appeared to be for non-malicious use (that’s less than half a percent). Three of those certificates appeared to be part of otherwise legitimate sites, but we could not determine their purpose and they were no longer being actively used. The last Let’s Encrypt PayPal certificate was being used on a staging site for testing PayPal integration.

“PayPal” certificates from Let’s Encrypt are unique in that they are a high-volume target for phishers, they are being used almost exclusively by phishers, and blocking the term is extremely unlikely to trigger false positives.

Other large brands do not satisfy these properties and could not be blocked without interfering with legitimate subscribers. For instance, “Apple” is a generic word and has lots of use unrelated to the computer company. “Google” would trigger false positives, for instance with companies offering SEO services. There seems to be no legitimate use of “BankOfAmerica” in Let’s Encrypt issued certificates, but it’s a very low-volume target with only 16 certs issued.

Most other terms fail to meet these properties as well – that’s why it is infeasible to implement a blacklist of any sort of “Alexa Top X” of domains or brands. Doing so would hurt Let’s Encrypt users.

But that is not the case for “PayPal.” Its use is almost entirely malicious, and it is worth blocking as it’s amongst the highest-volume targets for phishers. Given the term’s propensity for malicious use and the fact that PayPal gets its SSL from Symantec, there should be no more Let’s Encrypt PayPal certificates issued going forward.

Conclusion

The majority of these “PayPal” phishing sites are detected and blocked by services like Safe Browsing, which effectively protects users. However, they are reactive by nature and playing catch-up. No matter how quickly Google (and diligent reporters) may be able to catch them there is still a window between issuance and detection where a few people – potentially even a few dozen or hundred – can be harmed by the convincing use of SSL on a “PayPal” phishing site.

Even with “PayPal” certificates blocked, will it still be possible for SSL certificates to be used by phishing and malware sites every day? Yes, of course. We all recognize phishers will respond by using the second-best imitation for “PayPal.”

It has always been, and will continue to be possible to get variations like “PaayPal” and “PayPel” through the filters of most CAs. But these variations are less effective for phishing, and taking the best weapon out an attacker’s hands is a significant improvement in safety.

There is a future – where users have a more nuanced, or at least more accurate understanding of what the padlock icon represents. Where 2FA is widely used. Where HTTPS adoption is so widespread that browsers can flip the paradigm of security UI.

But that is the future.

Given the current state of user education, it is extremely difficult to justify the continued issuance of certificates quantifiably shown to be harmful to users. Certificates containing “PayPal” are a serious and unique threat – one which deserves attention and its own solution. That is why I hope to start a dialogue with Let’s Encrypt and discuss blocking issuance for certificates containing “PayPal.”

Blocking further issuance of these certificates will help protect users from convincing phishing scams without imposing a logistical or financial burden on Let’s Encrypt and without impacting its users.


I would like to thank Eric Lawrence, whose work inspired this article, and whose contributions improved it.

27 comments
  • It doesn’t seem like a scalable solution to dealing with the issue. Also, why focus on the certificate authority and not also look at the DNS registrar? It seems like a logical next step but I think most people would think that’s not a good idea.

    • Hi Alex,

      My solution certainly does not scale to prevent ALL phishing. For example, as I mention in my conclusion, criminals can just use “paypaal”, “paaypal”, etc etc and come up with 100s of decent look-alikes for every brand.

      So I do think that other solutions (such as Safe Browsing, user education, etc) are essential. I explicitly do NOT think the solution is complicated CA-level moderation.

      But for the extremely narrow problem I outlined in my post, I do see the responsible CA as an effective actor in prevention.

      As to why focus on the CA and not the registrar? I work with SSL every day, so that is my wheelhouse. I agree that there are some compelling cases for dealing with this at a higher level, as well as some big concerns (for instance, the speech-restriction issues seem more pressing there). But I dont think one precludes the other.

      If you know of any good articles/writers/listservs about registrar-level filtering and trademark protection, I would love to read them as it is something I am simply not that knowledgeable about.

      But as we have it today, there is no easy or quick path to a registrar-based solution. But there is a VERY quick and easy solution to the problem I discussed in my article, and that is why I think it is worth pursuing.

      We should definitely continue to look for better protections and systems, but we also need to implement easy fixes when we can now, while we search for those more permanent options.

  • The suggestion in your article would ban legitimate websites like paypalsucks.com and paypalcomplaints.org from Let’s Encrypt. Also think of domains for legit services that hook into PayPal, like paypalforbitcoin.com. Just because you can’t think of good uses for domains with PayPal in the name doesn’t mean we should ban them all from Let’s Encrypt. Plus finding and banning the phishing sites from Let’s Encrypt just means they go to other CAs (which are cheap though they are not free). So in my eyes, your proposal doesn’t make the problem go away, it just moves it while creating a headache for both Let’s Encrypt and legit PayPal related domain owners.

    • Hi Maximillian,

      I am aware that some legitimate sites would not be able to get certs from Let’s Encrypt. However, I hope my analysis of real-world use shows that this is such a small percentage of users that its more of a principled argument than a practical one.

      It is simply unreasonable to argue that we should be setting policies on behalf of legitimate owners of paypal-related services. Are we really making decisions based on what .5% of users need? Because if so, I should go tell the CA/B Forum to bring back 10-year certificates and SHA-1.

      Since there are dozens of other CAs that provide trusted certificates, why can’t the tiny number of sites like paypalsucks.com go elsewhere? I’m sure we could even get those sites free certs from other CAs if that was the case.

      Pushing phishers to another CA is exactly what I want. Other CAs have more strict moderation and would not allow the certs to be issued. Furthermore, because you have to pay for certs from most CAs, you have another means to block/identify and limit attackers.

  • This is ridiculous. The example in the screenshot could easily be accomplished using a wildcard certificate from any CA.

    • Hi Selcuk,

      A lot of people have brought up the potential for Wildcards to do the same thing. I would like to address that:

      Yes, it is true that a Wildcard cert COULD be used to create an equivalent phishing site. But my article is not arguing that we should ban everything that COULD be used for phishing.

      I focused on something extremely narrow: One term from one CA. I did this deliberately. And I did this because of the evidence.

      994 out of 998 of the “Paypal” certs issued by Let’s Encrypt that I examined were used for phishing (in reality, its probably 997/998, but I could not sufficiently determine for 3 of the domains).

      If the ratio of phishing:legitimate was 50%, I would certainly not be suggesting a block or any similar moderation. Same if the ratio was 75%, or even 95%. But a 99.5% rate of abuse? That is an OVERWHELMING negative to the ecosystem.

      The problem is the *extent* of the abuse. The numbers clearly show that there is almost no one (less than 0.5%) tying to legitimately use “Paypal” in their certificate. That is not the case for “Google”, “Amazon”, “Bank”, or any other trademark/brand. That is also not the case for “Paypal” certs from other CAs.

      That is also not the case for Wildcard certificates. Not only is there not the same evidence of abuse, but bigger picture, there is a major functional benefit to a Wildcard that makes it much much easier to administer HTTPS for certain use cases.

      So while I do think Wildcards can create equally convincing phishing, I also think that the pro/cons “equation” is different. If you ban wildcards you DO make HTTPS deployment more difficult, and you DO create additional hurdles to HTTPS adoption. Because of that, I do not believe blocking Wildcards would be justified.

      I hope that makes sense and addresses the difference I see in the two situations. I think it is key to understand I am not just picking on a case of phishing, but have identified what I believe to be a oversight that is only being leveraged by criminals to the detriment of legitimate users.

  • I agree with Let’s Encrypt that this should not be handled on CA level. If you honestly think that blacklisting “paypal” for anything else but “paypal.com” is a good choice, how about asking browser vendors to implement that? That would take care of every possible CA now and future. And it would take care of wildcard subdomain certificates from all CAs.

    Blacklisting only a few selected words does not work because then you’re left with all kind of incorrectly spelled variants (e.g. paypa1.com probably looks pretty convincing for casual user).

    If paypal wants to protect its users, they need to educate those users.

  • Maybe this is the right time for enterprises to remove the trust of an entire CA by policy? While PayPal is the widest threat, the overall policy makes them a useful tool for developing a spearphishing attack. The overall risk to a company may be better served by distrusting all certs from this CA. A few big companies start doing this, and their customers will start fleeing.

  • Eric’s post is more nuanced. There are multiple parties involved, multiple layers where it could be blocked.

    Phishing is a browser-UI-specific problem (e.g. there’s no risk of such certs confusing REST API clients). So why not call Chrome to stop showing “Secure” label for phishing sites?

    Browsers already have mechanisms for detecting and blocking phishing, UI to show level of trust, and ability to inspect content of the page. CAs have none of that.

    It looks like you’re asking Let’s Encrypt to work around Chrome’s misleading UI.

    • Hi KL,

      I think Eric’s post is great, and I agree it does a better job at discussing the bigger picture and the dynamics of all the parties.

      I was not aiming for the same goal. Instead, I wanted to explore a low-impact solution to a particular case of the phishing problem.

      Instead of looking at a bigger picture way to fix *all* of the problems, I only want to address the pervasive phishing threat of “Paypal” certificates being issued by Let’s Encrypt.

      You make a good point that phishing is related to browser UI. I do think that there is a problem with Chrome’s new “Secure” UI label and that it does seem to confer a bit too much meaning to SSL.

      I also think that security UI/UX is still a developing field. I read most of the work from Google Chrome’s team, who do some great user research, and my impression is that even the cutting edge of the field is still figuring out what works best.

      So I think we all have to wait for a solution to come from that area. Which leaves some of the low-hanging fruit unaddressed now. I carefully considered all the options and feel that, for now, Let’s Encrypt can handle this problem on their own, without it financially or operationally stressing them, or causing undue hassle to their userbase.

  • How can you write an article about this and not once mention that “PayPal” is a registered trademark? Trademark protection alone should be grounds for denying issuance of certs containing protected names

    • Hi Andrew,

      I am not a lawyer or an expert on trademark law (though my parents wish I was), so I can’t really say if there is legal grounds to deny issuance/revoke a certificate because of a trademark.

      So I can only speak to what Certificate Authorities and the industry has done in the past.

      In general, trademark protection alone has not been suitable grounds to deny issuance. For instance, it is okay to issue a certificate for “PayPalSucks.tld” or “NewsAboutMicrosoft.tld.”

      There are definitely tens of thousands of certificates out there with trademarked terms in them that are not owned/operated by the legal trademark holders.

      Furthermore, within the SSL/CA industry, it is not a violation of industry rules to issue such certificates. In fact, I do want to explicitly say that by issuing phishing certificates, Let’s Encrypt is NOT breaking any rules that they must abide as a trusted CA.

      Hopefully that explains why I did not touch on trademarks in my article. But that may very well have been an oversight and possibly something I should write about in the future. Thanks for commenting 🙂

  • This is a freedom of speech issue. There is nothing wrong with registering a domain name with the letters “p a y p a l” in that order in the name. There is no ethical argument that could be made for denying such a domain to people. There are practically zero IP protections for domain names.

    The problem is PayPal’s, not LE’s. PayPal needs to continue working to educate their users of the dangers of phishing. As long as the real paypal site continues to show a Business Verified certificate, and fake sites do not, then even people of mediocre intellect should be able to browse safely.

    Education is what matters. It is important that the process of registering domains and acquiring certificates not be burdened by these challenges.

    • Freedom of speech issue? What does that even mean? Are you invoking the USA’s 1st amendment? You know that only applies to government action right? There is nothing preventing LetsEncrypt from saying they are no longer going to issue certificates that contain the word ‘paypal’.

      His solution does not stop all phishing, or even a majority. But it has essentially no drawback, it’s easy to implement, and it will stop some phishing. Isn’t that a good thing?

      • NO.

        See my post below, but trying to make certificates mean something they explicitly _do not mean_ actually makes secure certificates more effective for spammers. Plans like this broadly implemented without changing the baseline requirements issued by the CAB forum would tend to actually make phishing with certificates more effective.

        It will always be possible to get a wildcard for an innocuous sounding site and then create a paypal.com subdomain and the CA cannot effectively police this. Accordingly, the more we make it seem safe to trust a certificate as asserting the legitimacy of a site’s _content_ the more we empower spammers using certificates.

  • While I agree with most of the individual points, I think this approach glosses over some larger picture issues.

    I’ll start with some facts that are, hopefully, not contentious:
    1. The internet is moving towards an “https to play” model. (Google scoring https higher, spying concerns, etc)
    2. Paypal has been known to freeze accounts, withhold payments, etc, causing problems for small businesses.

    Considering #2 only, it’s perfectly legitimate for people to want to run domains like paypalsucks.com, or screw-paypal.com. Combined with #1 though, those sites need to have https to play on the internet. Asking Let’s Encrypt to block certificates for those domains means they would be helping to silence criticism of Paypal. I can understand why Let’s Encrypt wouldn’t want to go that route.

    I agree that the overall situation right now kind of sucks though. “Look for the lock” needs to stop being the guidance for how to tell you’re talking to the company you think you are. As https becomes more and more prevalent, that advice will become irrelevant.

    • Hi Derek,

      I agree with both your facts and also take censorship very seriously.

      But why is it so important for the very small number of sites using “paypal” in their domain for legitimate services to use Let’s Encrypt? What is wrong with all the other CAs out there?

      • Hi Vincent,

        I wrote a reply a couple days ago, but the blog ate it. I got a blank page when I submitted.

        I don’t know any other CAs that offer free certs. Comodo claims to, but it looks like it’s only a free 90 day trial, after which you have to pay.

        If LE is the only free CA, and LE disallows someone’s certs, then with my previous fact about “https to play”, this means it puts those people in a “pay to play” model. If you want to criticize Paypal on the internet, you’ll have to pay for it.

        That’s against a lot of the principals that made the internet what it is today, allowing the spread of ideas from people who couldn’t otherwise afford to spread their message. LE understands this, and I believe that’s why they’re taking the position they are.

        • Hi Derek,

          I appreciate you taking the time to re-write your comment.

          The “PaypalSucks.com” example is very popular counterarguemnt – but if we are being realistic here, there are probably 3 or 4 websites on the entire internet dedicated to hating on Paypal.

          I bet that there are many CAs who would be happy to offer free certificates for such sites if it meant there would be less “Paypal” phishing sites.

          Overall, I agree with your point that hampering speech is a problem. But I think my proposal considered that. If there had been thousands, or even hundreds of legitimate users who would be inconvenienced, I would have come to a different conclusion. But we are talking about a handful, and it would be quite easy to take care of them.

  • Hi Vincent, thank you for this great article, as well as mentionning Eric’s one. But I think this is the wrong debate. Yes Paypal is vastly targetted by phishing, but they are not the only one. How would react HSBC if they learnt LE would blacklist the term “Paypal”, they would for sure ask “HSBC” to be treated the same way. And I can’t imagine LE strating to propose to blacklist strings related to trademarks.
    For me, the debate is on browser level. Why do Google uses the same UI browser security indicators (as well as FF) for both DV and OV certificate? Why does Google possibly want to stop displaying EV ? We’re currently having a fight between CAs and Google/LE, with CAs wanting to have “secure” on strong authentication websites only, DV considered as regular (no indicator) and HTTP indicated as “non secure” ; and Google/LE fighting to get “secure” for all encrypted websites, whatever the authentication level is, which is to me totally crazy and not taking in consideration the end user who will never be able to get educated and will never make the difference between a real and a fake website as soon as “secure” is written in the adress bar.
    I’m really wondering what will be the outcome of this fight…

    • Hi Chris,

      There is a lot to talk about here.

      First, I don’t agree with the “slippery slope” example. I think its jumping to conclusions to say that Let’s Encrypt would HAVE to bow to pressure from others. They could just as easily ignore them.

      I also want to point out that a major point of my position is that Paypal is unique compared to other trademarks/brands. While I did not do an exhaustive search, I didnt find other examples that met the same conditions.

      For example, I only did a very quick search for “HSBC”, and from a glance it does look like there is a very high percentage of phishers. However, the volume looks to be about 1/5 of “Paypal.” So that right there is an objective reason not to bother with it.

      On your second topic:

      I am familiar with those UX changes proposed by Google. I have to say, for the most part I agree with them.

      The data I have seen on user education (and expectations/desires) leads me to believe that we need less UI states not more. I can’t go through all the reasons why, but OV will never get its own treatment (browsers will literally never do it). I think even if we did have an enforceable “third state” of identity, it would ultimately confuse more than it helps.

      There are also some technical considerations that make a good case for why HTTPS should be the “default” with no indicator, and HTTP should have a negative indicator.

      But, I DO see a big issue with a future web where we don’t have EV certificates (or a similar measure) that provide identity assurance to websites. Given the sophistication of phishing techniques, and all the bugs and other bad browser behavior (like the totally confusing way Chrome handled data: URLs until very recently), I think even advanced users need some help confirming legitimate sites. I think Google is wrong on this point.

  • This argument is ridiculous. You are trying to pin a browser problem onto a CA.
    I agree with some of these other commenters that this is not a CA problem. It’s not even entirely a browser problem.
    The purpose of a certificate is to verify that in a secure connection, that your browser is talking to the proper server. THAT’S IT. The green lock in the corner ONLY means that you are COMMUNICATING in an ENCRYPTED fashion with the CORRECT server for the domain that you are trying to reach. THAT’S IT. It has NO bearing on whether the site is malicious or not. That is a COMPLETELY different problem. Secure communication is NOT the same thing as SAFE communication. And you know what, I agree with you that not a lot of people realize this. And chrome/firefox etc could maybe do a better job at using their platform to educate people to this effect. Like, maybe they could do something like bold the root domain of the url so that it stands out more from the subdomain of paypal.com. But this is NOT a CA problem. That’s not what they are for. They are not private investigators that inspect websites for suspicious or malicious activity. They simply verify and vouch that the domain you are trying to reach is indeed the domain that you are reaching. THAT’S IT.

  • A key issue here is one created when we as security professionals oversimplify and tell people ‘Green is good!’ or ‘You’re safe if there’s an s after the http!’ Neither of these statements was ever true about the _content_ of a site. However, because of what the security community has taught people, spammers get a certificate and people trust those sites.

    Implementing some half-assed regexes at the CA does not solve the fundamental fact that neither DV, OV or EV certs actually assert _anything_ about the content of the website and we’ve told people they do. An approach like Vincent advocates here propagates and reinforces this unfounded trust. Encouraging the belief that a certificate asserts you can trust the _content_ of a site is dangerous and dishonest.

    The Let’s Encrypt approach can lead to a world where at least all of our communication over the web can travel encrypted. To combat phishing and other malicious web content we should be focusing on the tools that help to determine, at the point of consumption (i.e. the browser), whether content is malicious and training people to trust those tools. Microsoft Smart Screen and Google Safe Browsing are both excellent steps to achieving this.

    • Hi Tkan,

      I agree that the “green is good” advice is incredibly misleading and is not the right way to teach users about security.

      I am not disagreeing with Let’s Encrypt’s overall approach, or endorsing the “Green is good” mantra.

      Instead, I am considering the fact that we already have a huge number of users out there making the green = good assumption. We also have Chrome displaying “Secure” next to ALL HTTPS sites, and I think we can both agree that is a poor choice of words.

      This is not about what we should *teach* users, but what we have already *taught* them.

      The point of my proposal isnt to ensure “green is good” remains true. It is to protect people who are going to be led astray by bad advice and inaccurate browser UIs from a particularly pervasive threat.

  • People have fallen for phishing with and without TLS for she’s. The real problem here is that web browsers resolve domains containing paypal at all.

  • Let’s be clear here about which domain name the example phishing site you are displaying is – it’s not paypal.com or any derivative – it’s issues-add.com. The CA has issued a certificate to a sub-domain of issues-add.com (or issues-add.com is a Subject Alternative Name on the certificate). Now Let’s Encrypt doesn’t support wildcard certificates so let’s say that they now ban the issuance of certificates containing domains or subdomains or subject alternative names with “PayPal” in the name. So Let’s Encrypt won’t work. So the phishing attacker goes to another CA which does support wildcards (say Symantec) and ok, it’s not free, but they get a certificate for *.issue-add.com, which means that Chrome will show up https://paypal.com.blahblahblah.issue-add.com/ as “Secure” as the certificate will be valid. Problem solved, as far as the phisher is concerned.

    All you will do if you restrict Let’s Encrypt is push the issue onto another CA, and so on, ad-infinitum.

    • Right. One of Vincent’s arguments is exactly that the certificate cost serves as a deterrent to some phishers. For example, DigiCert shows a starting price of $495 per year for its wildcard certificate.If the phisher can justify this cost, then yes, problem solved.

Leave a Reply

Your email address will not be published. Required fields are marked *