Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Businesses Security The Almighty Buck

Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites (bleepingcomputer.com) 250

Posted by EditorDavid from the then-let's-also-phish-PayPal dept.
BleepingComputer reports: During the past year, Let's Encrypt has issued a total of 15,270 SSL certificates that contained the word 'PayPal' in the domain name or the certificate identity. Of these, approximately 14,766 (96.7%) were issued for domains that hosted phishing sites, according to an analysis carried out on a small sample of 1,000 domains, by Vincent Lynch, encryption expert for The SSL Store... Lynch, who points out the abuse of Let's Encrypt's infrastructure, doesn't blame the Certificate Authority (CA), but nevertheless, points out that other CAs have issued a combined number of 461 SSL certificates containing the term "PayPal" in the certificate information, which were later used for phishing attacks... Phishers don't target these CAs because they're commercial services, but also because they know these organizations will refuse to issue certificates for certain hot terms, like "PayPal," for example. Back in 2015, Let's Encrypt made it clear in a blog post it doesn't intend to become the Internet's HTTPS watchdog.
Of course, some web browsers don't even check whether a certificate has been revoked. An anonymous reader writes: Browser makers are also to blame, along with "security experts" who tell people HTTPS is "secure," when they should point out HTTPS means "encrypted communication channel," and not necessarily that the destination website is secure.
This discussion has been archived. No new comments can be posted.

Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites More

Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites

Comments Filter:

  • also.. (Score:4, Interesting)

    by Anonymous Coward on Sunday March 26, 2017 @10:37AM (#54112753)

    they are changing the name to "Let's Phish"

  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Sunday March 26, 2017 @10:46AM (#54112807)
    Comment removed based on user account deletion

    • Re: but you arent a traditional CA (Score:5, Insightful)

      by Zero__Kelvin ( 151819 ) on Sunday March 26, 2017 @10:52AM (#54112841) Homepage
      You have a basic lack of understanding of the purpose of certs. They guarantee that if you try to connect to phishme.com that you indeed are connecting to phishme.com and not being MITMed. It is NOT the purpose of a cert to say that phishme.com is or is not a safe place to go. The onus of that remains upon you regardless of if you use HTTP or HTTPS.
      • It is however the duty of the CA to verify identity and ownership of the domain before issuing the cert. That what makes them an authority.

        • And the person who owns www.phishme.com will actually own the domain www.phishme.com which is the domain that will show up on the certificate he is asking to be issued. The authority chain here is entirely preserved.

      • Re: (Score:2)

        by DarkOx ( 621550 )

        Correct certs are about AUTHENTICATION, Its to make sure that when you put your CC info in you really are sending it to paypal.com and not someone else. However, if letsencrypt lets me register päypal.com and you can't easily see something is different, that certificate isn't helping you to authenticate any more, its essentially a really good fake id! I am going to confuse that with the real paypal.

        Its not a question of determining if phishme.com is safe or not its a question of knowing who you are t

        • I am going to confuse that with the real paypal.

          Except that's not the difference you get in a browser. If you connect to a site with a domain validation certificate like the one Lets Encrypt issues then all the browser will say is "Secure"

          If you're wanting to guarantee that you're actually connecting to PayPal then that's a completely different certificate with a completely different process for a completely different purpose, and shock horror it is handled differently by the browser and displayed differently to the end user. Instead of "secure" the bro

        • Typosquatting has been a problem for twenty years and DV certs fo at least half that time. Why would this suddenly be Let's Encrypt's problem? $4.95 has never stopped phishing attacks before.

          Any typosquatting solution is going to be entirely locale dependent - the only place to handle that is at the browser. Give Google and MoFo hell about never caring about this. For all I know the Khazak word for "hot pizza" looks like "citibank" but it's definitely not a job for Let's Encrypt to deny that pizza plac

      • Re: (Score:2)

        by mhkohne ( 3854 )

        You have a basic lack of understanding of the purpose of certs. They guarantee that if you try to connect to phishme.com that you indeed are connecting to phishme.com and not being MITMed. It is NOT the purpose of a cert to say that phishme.com is or is not a safe place to go. The onus of that remains upon you regardless of if you use HTTP or HTTPS.

        Yea, but have you noticed that the general public has no idea how much of anything actually works, or frankly what most things are actually for? Most people have no real idea what that little lock icon means, so (assuming that someone managed to train them to look for such things at all), they think the lock icon means they are good to go. The slightly more subtle message of 'yea, this website IS who it says it is, but that doesn't mean it's not a criminal' is lost on these people.

        So yea, it's a problem, bu

    • Re: (Score:3, Informative)

      by Anonymous Coward

      Nope, not going to happen.

      The entire reason this is happening is because the browser vendors got a stick up their ass and required HTTP/2 connections to be run over TLS. So Let's Encrypt fills in the same space for HTTPS as Cloudflare does for CDN. They are not there to police their customers, and will ignore lots of shit until someone actually takes them to court.

      The solution has always been there. The self-signed certificate should never have been "this might be a dangerous site" warning. That is what the

      • Re: (Score:2)

        by DarkOx ( 621550 )

        Which is why I am advising all my corporate clients that do SSL intercept to either block site that have used and LE cert, or present the invalid/self signed warning to their users. These things are not better than self singed.

        • These things are not better than self singed

          And they are not trying to be. Why would you block a CA issuing only DV certificates when their process 100% confirms that the requestor of the DV certificate is the server owner?

          Do you not trust your communication to Slashdot to be secure?

          • The process might in fact be to block all domain-validated (DV) certificates and allow organization-validated (OV) and Extended Validation (EV) certificates. This would parallel the policy implemented by the Comodo Dragon browser, which displays a warning for DV certificates [netcraft.com]:

            The security (or SSL) certificate for this website indicates that the organization operating it may not have undergone trusted third-party validation that it is a legitimate business. Although the information passed between you and this

        • Which is why I am advising all my corporate clients that do SSL intercept to...

          ...stop that insecure crap immediately [us-cert.gov], because you take security seriously and don't want to weaken their defenses. Right?

      • The entire reason this is happening is because the browser vendors got a stick up their ass and required HTTP/2 connections to be run over TLS.

        And by that, you mean the browser vendors realized that "unsafe by default" is a shitty choice for a widely used Internet standard.

        For the "HTTPS-everywhere" has basically made website operators costs double if they want to jump on that bandwagon because the bandwidth costs explode when they can no longer be cached.

        Totally worth the tradeoff for making strong encryption the expected default.

    • That "lock" icon in the address bar is generally enough to convince people that what theyre doing with their Visa is sane. now, with letsencrypt, its not so certain.

      I do not disagree with anything you wrote but this conflates the idea of a secure connection to a website as being a legitimate website. This has never been true.

      if you're not going to at least police fraud or abuse, youre opening the service up to become a haven for quick and easy phishing sites. if you ignore this now, you might as well pack up and leave. Chrome and Firefox will not hesitate to lower their trust in your service

      Sadly, this is true and I think some basic safeguard requirements need to be put in place to prevent new registrants/hidden registrants from abusing the service.

      if it turns into the .info and .biz of the internet.

      Sir, how you denigrate my superbe site, InternetIsSrs.Biz!

    • allows dangerous sites to quickly and easily bypass an entire host of browser security checks designed to prevent people from entering bank card information and personal data into an unprotected site. That "lock" icon in the address bar is generally enough to convince people that what theyre doing with their Visa is sane. now, with letsencrypt, its not so certain.

      Except that's not what it does at all. A lock does not imply a chain of trust. The actual name in the actual site is what implies a chain of trust and you don't get that name from Let's Encrypt or any of the several free services which provided certificates in the past. If I go to my own personal website my browser says "Secure". If I go to PayPal my browser says "PayPal, Inc [US]." No checks have been bypassed.

      Also quite frankly, GOOD. I still greatly prefer only one phisher getting my credit card informat

    • Re: (Score:2)

      by dgatwood ( 11270 )

      ... phishing sites needed to pay money to play in the https realm or hire someone smart enough to exploit an https protected site.

      Nope. StartSSL had been issuing free low-validation certs since at least 2009, some six years before Let's Encrypt issued its first cert. The only substantive differences between Let's Encrypt and StartSSL, as far as I can tell, are:

      • Let's Encrypt didn't get bought out by a Chinese registrar who abused their signing certs in ways that caused them to become untrusted by most bro
      • The few times I've used Let's Encrypt was during testing phases, as a place-holder until I had the time to get a "real" cert. My company has an inane procedure to get purchase orders to pay for anything, so often it takes a couple of weeks to get to the point of being able to purchase anything via a "new vendor". If you can't afford $5 or so to get a year-long cert, then your either not serious about your site or doing something wrong.

        The most complicated process of getting a cert was for a "private doma

        • Re: (Score:2)

          by dgatwood ( 11270 )

          The few times I've used Let's Encrypt was during testing phases, as a place-holder until I had the time to get a "real" cert. My company has an inane procedure to get purchase orders to pay for anything, so often it takes a couple of weeks to get to the point of being able to purchase anything via a "new vendor". If you can't afford $5 or so to get a year-long cert, then your either not serious about your site or doing something wrong.

          Or you have more than the one subdomain that most CAs allow for $5 certs. Even with a limit of five for Let's Encrypt, it takes two certs for my main domain. Bare domain, www, images, git, homeserver, kinji, and I feek like I'm still forgetting one. A wildcard domain cert starts at two hundred bucks.

      • You can get the equivalent of key pinning using DNSSEC and TLSA.

        Now if browsers vendors supported TLSA it would improve security because rogue CA's can't issue a cert for the name that will be accepted.

    • Read: https://letsencrypt.org/2015/1... [letsencrypt.org]

      While they do conclude that they don't see CAs role for (DV certificates) to protect against phishing... They do already lookup domain names in Google Safe Browsing API before issuing certificates.

      From a puristic point of view the purpose of a certificate is to prove that you are talking to example.com, and not some other domain. Verifying that example.com is your bank and not registered by a scammer is a not the purpose of a certificate.

      That said, it seems they

  • Foundamental flaw of the CA infrastructure (Score:5, Interesting)

    by Cigaes ( 714444 ) on Sunday March 26, 2017 @10:58AM (#54112885) Homepage

    This story shows the fundamental flaw of the TLS CA infrastructure: it only certifies that the connection is established with the reported DNS domain name. That is not utterly useless, but not far from it.

    The protection against man-in-the-middle attack is relevant only in a handful of cases. With home Internet access, MitM can more or less only be performed by network operators, who have a lot to lose if they are caught playing these games. It is more of an issue with public access, but still rather minor.

    What would be really useful would be CA that certify the honesty of the sites. “If you see our green padlock, that means this site is reliable. If they scam you, we will refund you.”

    I will not hold my breath.

    • Re: (Score:2)

      by MobyDisk ( 75490 )

      With home Internet access, MitM can more or less only be performed by network operators,

      How so? This is exactly what HTTPS prevents.

    • Re: (Score:2)

      by Nkwe ( 604125 )

      The protection against man-in-the-middle attack is relevant only in a handful of cases. With home Internet access, MitM can more or less only be performed by network operators, who have a lot to lose if they are caught playing these games. It is more of an issue with public access, but still rather minor.

      There is no difference between protection from man in the middle attacks for home users and users using public access. The user (or software / browser on the user's computer) is either validating certificates or they are not. Validation includes checking cryptographic signatures, checking revocation lists, and checking that the subject matches the requested resource (web site). It is true that checking signatures requires keeping tabs on what certificate authorities are trusted, which is a difficult problem

    • With home Internet access, MitM can more or less only be performed by network operators

      Oh wow are you wrong about that. There are a myriad of ways you can MitM a connection other than passive listening. The most popular way is through malware that routes your connection via some third party. Having home internet doesn't make you secure against MitM attacks in the slightest.

      • Re: (Score:2)

        by Cigaes ( 714444 )

        Answering to this and the others:

        If you install malware on the target's computer, that is not a man-in-the-middle, and certificate will be of little protection anyway.

        • Re: (Score:2)

          by dgatwood ( 11270 )
          More generally stated, if you can't trust the endpoint, you can't trust the communication, period. No protection scheme can protect against a compromised endpoint.

    • The protection against man-in-the-middle attack is relevant only in a handful of cases. With home Internet access, MitM can more or less only be performed by network operators, who have a lot to lose if they are caught playing these games. It is more of an issue with public access, but still rather minor.

      You don't really know how SSL/TLS works do you?

    • Re: (Score:2)

      by taustin ( 171655 )

      You are entirely correct. It was the same when I was running a web store in the 90s. It took me all of 30 seconds to figure out that the only thing a Certificate Authority is certifying is that your credit card didn't bounce, and the only thing they're an authority on is processing credit cards.

    • What would be really useful would be CA that certify the honesty of the sites. “If you see our green padlock, that means this site is reliable. If they scam you, we will refund you.”

      They already work the way you think. You just don't understand the difference between the green padlock and the green text that comes up with an OV or EV certificate.

      The certificates issued to www.paypal.com will show a green padlock along with the very obvious text "PayPal Ltd [US]" next to it. The certificates issued to www.playpal.com will only show that little padlock indicating the channel is encrypted.

      • Re: (Score:2)

        by Cigaes ( 714444 )

        They cannot work the way I evoke when the CA is chosen by the server and not the client.

        • The CA IS chosen by the client. It is your prerogative who you trust to be a CA. The browsers only come with a list of defaults. Those list of defaults are based on what the browser vendors think is sane based on the performance of the authority. And quite frankly an authority that actually physically checks that a user is able to run a script that modifies a directory on a server within a domain in question is pretty damn authoritative on defining that a server belongs to a domain that it claims (the scope

          • Re: (Score:2)

            by Cigaes ( 714444 )

            The CA IS chosen by the client.

            No, the CA is chosen by the server. The only choice for the client is to either trust or not trust. They cannot decide to use another CA with more guarantees.

            defining that a server belongs to a domain that it claims

            Which is all but useless, and exactly the source of the present thread.

  • silent s (Score:2, Insightful)

    by bugs2squash ( 1132591 )

    I'm sure the "so called" security experts you deride would point out that the S in HTTPS is not simply encryption spelled in a funny way. Security != Encryption and the role of the certificate is Authentication not Encryption. If it doesn't authenticate anything then it is worthless, and the whole bloody point of a public CA IS to be the internet's watchdog or there is no point in trusting them.

    Or do they feel that the only role of an adult is to buy liquor for children ?

    • But the certificate does authenticate that the domain in your browser URL bar is owned/controlled by the owner of the certificate. The fact that you are going to a different domain than the one that you expected is nothing to do with HTTPS. The whole point of a CA is to provide a certificate to legitimate owners of the domains. The point of a CA is NOT to determine that such-and-such domain is mistaken with another domain because the user is stupid.
    • Secure means Encrypted. If you need authentication, use the much more expensive EV certicates, to get a nice browser green bar that includes the name of the company.

    • If it doesn't authenticate anything then it is worthless

      Oh but it does. A DV certificate authenticates that a computer responding on behalf of a domain is who it claims to be. Let's Encrypt is perfectly fine for that and does not issue any certificate with information that isn't completely authenticated. This is why they don't issue OV or EV certificates.

      The S doesn't indicate anything to do with security and encryption. It indicates a different protocol to standard HTTP is being used. The various results of different certificates are shown differently by browse

  • And? You may also get a wildcard certificate from whoever (even net sol) for *.mydom.com then create a host 'paypal.mydom.com' in DNS having paypal in the name, and covered by the certificate. If this article tries to discredit Let's Encrypt because they're free, paypal in the name is not the right argument.

  • Seems familiar (Score:4, Informative)

    by ugen ( 93902 ) on Sunday March 26, 2017 @11:28AM (#54113065)

    Something about road to hell being paved with good intentions.

    The issue is not SSL, certs or lack thereof. The issue is the fact that among human population there exist several fairly consistent groups. One of these groups is "low information people" (not to call them "stupid"). Another group is "dishonest people". Yet another is "well intentioned people" who want to protect the former from the latter. But, as the "wily" are, by definition, loath to play by the rules and, in general, fairly smart - they will surely find ways to exploit whatever well intentioned thing to take advantage of the "low informed".

    There isn't really any solution here.

    • Re: (Score:3)

      by fnj ( 64210 )

      "low information people" (not to call them "stupid")

      "Low-information" is a silly PC circumlocation. There are perfectly appropriate terms such as "ignorant" and "naive" to use to describe people who don't know stuff.

  • More tips for browser makers (Score:5, Informative)

    by sootman ( 158191 ) on Sunday March 26, 2017 @11:33AM (#54113101) Homepage Journal

    (... because I'm sure they read /. and value my opinion... )

    1. NEVER hide ANY part of the URL. If the URL extends beyond the size of the location box, give a nice big '...' for people to click on to see it.

    2. ALWAYS show a status bar that ALWAYS shows what URL I'll go to if I click a link. NEVER allow ANYTHING to change this behavior.

    3. NEVER hide the protocol.

    4. Don't allow 'data' URIs in the URL bar by default. https://www.wordfence.com/blog... [wordfence.com] (This also relates to #1)

    5. Don't make SUCH a big damn deal about 'https' -- big green text, giant padlock icons, etc. I've been telling people for YEARS that an HTTPS connection to bankofamurica.ru is worth NOTHING.

    This won't solve everything, but the least that browser makers can do is give people the tools they need to help them make good decisions. Long story short, QUIT HIDING SHIT!

    6. Bonus: enough with all these new shit TLDs. Is a world where http://blog.google/ [blog.google] exists (note: it does) REALLY a better place than one where it doesn't? Or is it just more confusing?

    • Re: (Score:2)

      by Sebby ( 238625 )

      2. ALWAYS show a status bar that ALWAYS shows what URL I'll go to if I click a link. NEVER allow ANYTHING to change this behavior.

      Also, don't allow changing what is shown in that status bar, like custom text instead of that link.

    • 1. Agree
      2. Irrelevant. Sources from phishing attacks do not originate from within the browser. Most often they do from some external source (email being the most popular).
      3. Irrelevant. No one cares about the protocol and the general public doesn't understand it so it does nothing to aid security. Even on browsers that hide the protocol people interested in it can identify it from the rest of the information in the URL bar (the colour / padlock icon).
      4. Agree
      5. They don't. There's a difference in the displa


    • 1. NEVER hide ANY part of the URL. If the URL extends beyond the size of the location box, give a nice big '...' for people to click on to see it.

      Given the example domains are of the form paypal.com.abc.xyz.tld (example: paypal.com.resolution-ticket.tk) maybe the tld should always be visible.

  • Something doesn't add-up:

    During the past year, Let's Encrypt has issued a total of 15,270 SSL certificates that contained the word "PayPal" in the domain name or the certificate identity.

    (Emphasis mine).
    But according to Let's Encrypt, their certificates don't say anything about identity:

    Let’s Encrypt is going to be issuing Domain Validation (DV) certificates. On a technical level, a DV certificate asserts that a public key belongs to a domain – it says nothing else about a site’s content or who runs it. DV certificates do not include any information about a website’s reputation, real-world identity, or safety.

    Can someone explain what the author meant by the term "certificate identity" in a Domain Validation certificate? It almost seems like the author of the article is conflating the concepts of DV certificates and EV certificates into one. Or am I wrong, and DV certs do indeed have an identity?

    In researching this a bit, the CA security council [casecurity.org] as well as some certificate authorities [digicert.com]

  • How is this an abuse of Let's Encrypt? Would you prefer that victims give their private information to phishing sites over plaintext? Seatbelts can be worn by bank robbery getaway drivers. Does that mean that seatbelts are a problem? The premise is absurd.

  • Letsencrypt versus a 'real' CA (Score:4, Interesting)

    by sjwest ( 948274 ) on Sunday March 26, 2017 @01:14PM (#54113667)

    I think most people here would spot a fake site without the ev,

    Even CA's have issued 'bad' certs to people - Symantec and others have also failed the test.

    • Re:Letsencrypt versus a 'real' CA (Score:5, Informative)

      by thegarbz ( 1787294 ) on Sunday March 26, 2017 @05:11PM (#54114833)

      That's just it. BleepingComputer doesn't understand the difference between a DV and an EV certificate and falsely assumes that Lets Encrypt is not doing exactly what a Certificate Authority issuing a DV certificate is supposed to do: Verify the requester is capable of administering the domain in question and nothing more.

  • Public key infrastructure is dependent upon a system of trust. Those who issue signed certificates can either strengthen or weaken trust in the overall system. Those issuing certificates bear responsibility to maintain trust in the overall system.

  • Years ago everyone who wanted an SSL cert had to provide actual corporate documentation reviewed by actual people. Everything was essentially "EV".

    Then all the CA vendors said fuck it, lets make more money on volume without doing any work and switched to automated systems.

    Finally Let's encrypt came along and said double fuck it not only will we use automated systems but we'll make it FREEEEEEEEE.

    The end result is a phenomena well known to the technology industry. A race to the bottom where everyone ends u

    • You seem to imply because something is free and automated that there is a lack of trust. There is not. DV certificates still identify the server as responsible for responding on behalf of the domain in question.

      What you're complaining about is trust beyond the machines and into the organisation and people behind the servers. This is something outside of the scope of DVs, outside of the scope of Lets Encrypt, and quite critically also handled and displayed differently to the user by the browsers.

      There's noth

  • Before they just used http without tls.
    The web is moving to be encrypted. So phishing sites are being encrypted as well. No surprise. And nothing worse than before. It's even better, because just the phisher gets your creditionals, but not the NSA, which sniffes your connection to the phishing site.

Slashdot Top Deals

We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. -- Larry Wall

Close