Slashdot Mirror
Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites (bleepingcomputer.com)
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.
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.
they are changing the name to "Let's Phish"
The fight against phishing and malware content is an important one, but it does not make sense for CAs to be on the front lines
but thats just it. prior to you, people had a barrier to entry. phishing sites needed to pay money to play in the https realm or hire someone smart enough to exploit an https protected site. your service removed both of those barriers and now 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.
.info and .biz of the internet.
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 if it turns into the
Good people go to bed earlier.
Right. The point of these certs is to verify that a secure connection to the site in question has been established and there is no man-in-the-middle or DNS hijack or proxy etc. It is not to verify the identity of the site in question.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
How on Earth would a non IT person "verify the legitimacy of emails and websites?"
Let's say, you entered paypal in Google and miraculously the second link leads to paypall.com (such a SEO "optimization" is entirely possible if your have enough resources) which is the exact same copy of paypal.com, which siphons your log in credentials. How would you know paypall.com is not PayPal? Extended validation is still better than nothing.
HTTPS was a badly realized afterthought and it bites people all the time. I wonder if this problem can be solved at all. There are way too many things you have to blindly trust when you're using the Internet: several layers of routing, DNS, SSL, etc. etc. etc. 99% of people in the world have no idea how this all works and how you can be sure you're safe. Then even your OS is not exactly without bugs and security vulnerabilities which allow the attacker to hijack your connection. Then you have various three/four letter agencies around the world who have ways of getting into your computer systems without you knowing.
"Verify", my arse.
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.
"there is no man-in-the-middle or DNS hijack or proxy etc. It is not to verify the identity "
If the identity of the endpoint can't be verified, exactly how is it that MITM is prevented? Are MITM sites required to set the Evil Bit?
"National Security is the chief cause of national insecurity." - Celine's First Law
Sorry, that wasn't very clear. It is to identify that the server is the server it claims to be, but does nothing to verify the identity of the person running the server.
For example, Let's Encrypt will check that the person getting the certificate really does control www.paypall-secure-login.com, but not that they are actually PayPal Inc. The point is to allow a visitor to establish a secure connection with the server, not to check that the web page served up is not misleading.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
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.
Or AutoFill. You enable AutoFill for PayPal.com, and then when your password doesn't automatically show up, you look at the URL more carefully and immediately see why.
The real threats to security are not the CAs that issue certs for sites containing PayPal in the name. The real threats are clueless sysadmins at (mostly banking) websites that insist on not allowing AutoFill and/or break their websites in ways that make AutoFill stop working when it worked before. Besides playing right into the hands of keyloggers, such actions force people to remain willing to type passwords when in reality, users should never, ever, ever type a password into a website. Ever. Seriously.
... that and browser makers, who haven't bothered to come up with a global standard for changing passwords so that users whose computers become compromised can easily reset all their passwords automatically with a single click, and also haven't bothered to come up with completely automatic plug-in update systems, thus making it easy to trick people into believing that their Flash Player or Silverlight plug-in is out of date, thus causing them to download and run a trojan horse installer that steals their password database, etc.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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.
Slashdot, fix the reply notifications... You won't get away with it...
(... 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... (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/ exists (note: it does) REALLY a better place than one where it doesn't? Or is it just more confusing?
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
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.
If the identity of the endpoint can't be verified, exactly how is it that MITM is prevented?
There's a difference between positively identifying a corporation and identifying the machine with which you are trying to communicate. An SSL certificate provides you only with the knowledge that you're communicating with the person who claims to own the address in question and that this communication is secure.
Phishing attacks are prevented by Extended Validation. It's an additional process which says the person who we granted the certificate to is the owner of the domain and the company and we have reasonable evidence to that effect, ... trust us.
Let's Encrypt doesn't offer the latter service, and if you go to www.payypal.com and see "Secure" in the title you know that you're talking securely to www.payypal.com. You don't know if you're actually talking to Paypal unless it says "Paypal, Ltd [US]." in the title, and even then you're doing it on nothing more than a promise.
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.
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.
A domain-validated cert guarantees *nothing* besides, "this cert was issued to a likely admin at $host.$domain.$tld."
The expectation is that clients (ie, web browsers) will compare the tail end of the hostname to the CN on the cert, and take appropriate action if they don't match.
They guarantee *nothing* about the identity of the site's owner, the legitimacy of their domain's ownership, or anything else.
DV certs exist because sometimes, all you care about is preventing MITM attacks to web users. Period. The onus is still on *you* to verify that login.chase.com.lucky7domainpark69.com is, in fact, the login page for your bank, and not a phisher's site. All a DV cert for that domain guarantees is that someone running a fake/compromised wifi access point can't intercept, read, or tamper with the request or response.
This is why banks pay thousands of dollars for "EV" certs. A CA issuing an EV cert IS expected to have "boots on the ground" physically verifying that the cert's applicant is who they say they are, has an office where they say they do, etc. They themselves STILL guarantee nothing about how data is secured or used after decryption.
TL/DR:
DV cert: the other party is whomever controls $(some-specific-domain).
EV cert: same as DV, but adds guarantee that they're ALSO whom they claim to be. They might STILL be evil & crooked, but at least you might conceivably hunt them down in the real world if they do something bad.
There is no fraudulent certificates being issued. A DV certificate which is all that Let's Encrypt issues only guarantees that you are actually talking to the domain (server) that is being claimed. Nothing more. Confidentiality, integrity and identification are completely correct and preserved. You are actually talking to www.ppaypal.com when it says you're talking to www.ppaypal.com.
If you want to know if you're talking to PayPal Ltd, [US]. That's a completely different certificate with a completely different issuing process, and your browser will handle DV and EV certificates differently.
A CA issuing an EV cert IS expected to have "boots on the ground" physically verifying that the cert's applicant is who they say they are, has an office where they say they do, etc.
EV pretty much just means they paid extra, and the buyer is a company. Depending on which CA, there won't be much extra verification.
Also, there's another type of cert you didn't mention which are Organization-Verified Non-EV Certificates. For example: Amazon.Com has one, The certificate lists the company name "Amazon" as the company name on the cert instead of just a blank or "Domain Owner Verified" in the company name.
Although, for some reason Chrome does not show the company name on Organization-Verified certificates.
In other words, the business model of Let's Encrypt is to sell digital certificates that aren't worth the electrons they are printed on.
Let's Encrypt certificates are free and issuance is fully automated.
Everything I write is lies, read between the lines.
Informational websites with no credentials do NOT need TLS, typically
Yes they do, if for no other reason than to protect visitors privacy against passive interception and tampering by their ISP.
Furthermore, websites such as Google search engine need TLS to avoid connections being hijacked by a malicious party and then used to phish attack against other Google.com/Same-origin properties
and very few people would check EV
Given how an EV produces a very clear and noticeable indication of the name of the organisation in the title bar, if someone doesn't "check" it then they should probably disconnect the internet as they are a danger to themselves.
If only. Most of the people who would be helped by such a thing are the sort of folks who would follow the instructions on how to disable their AV software to see the dancing cat video. EV is a nice mechanism, but PEBKAC still rules the day.
A thousand pounds of wood moving at 300 feet per minute. Don't get in the way.
OK but then you have to have cross-checks that let people register/get certs for paypal-sucks.com without also permitting paypall.com, unless paypall.com is a legitimate business (PayPall being some payment processor in, I dunno, South Uzbekhistan). You also have to prevent getting wildcard certificates for anyone, because then they could set up paypal.com.golbalisecure.com (just by getting a wildcard for com.golbalisecure.com) - which would also let them get close to microsoft.com(.golbalisecure.com), google.com(.golbalisecure.com) etc.
This is not a problem easily solved with simple rules. And even THEN you get to the point of having hundreds or thousands of people employed to push yes/no buttons, which would surely not lead to underpaid, bored staff with bad KPIs/goals just repeatedly clicking Yes with no thought.
How did that help, again?
Yes, you are technically correct. However, every phishing site that I've ever seen does exactly zero without javascript enabled. If you've already visited paypal and whitelisted it in NoScript, then you'll immediately notice when you go to a similar site that isn't whitelisted and know not to put in any credentials.
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
In other words, the business model of Let's Encrypt is to sell digital certificates that aren't worth the electrons they are printed on.
Let's encrypt is a free (price as-in-beer, code as-in-speech) service. They don't have a business model.
They have a purpose (the same as CACert, by the way), to issue simple certificates that can verify that "blah.com" is indeed "blah.com".
(As opposed to some man-in-the-middle attacker mascarading as "blah.com" using a different 3rd server).
They do not certify any thing else, and indeed the certificates' fields. This certificate doesn't certify any organisation name.
This is even reflected in some browser's URL bar.
e.g.: in Mozilla's Firefox.
- Go to a "let's encrypt" website (like here on /. ) or one certified by CACert :
you only get the green padlock (sign that the communication is encrypted) and no other indication.
let's encrypt only checked that slashdot.org is indeed slashdot.org, but didn't check anything regarding ownership.
(it might as well be someone trying to impersonate Slash, DJ Slash or Fat Boy Slim)
- Go to paypal :
in addition to the padlock, you get an indication that certificate is certifying that the server is owned by PayPal Inc.
(Symantec actually checked that PayPal Inc is indeed own
Issuing a certificate to BobsCarRepair.com is one thing. Obviously you have no way of knowing whether or not Bob is a reputable business.
Even further : it doesn't even certify that owner of the website is someone called bob. It only certifies you that it is indeed bobscarrepair.com
It might as well be owned by Alice, for what you know.
It only certifies that Eve isn't wiretapping you when you give your credit card number to buy parts.
However, Issuing 14,000+ certificates that contain the word PayPal, to domains not owned by the real PayPal, is incompetence on a massive scale and calls into question Let's Encrypt's honesty and trustworthiness.
Nope.
There's a difference between guaranteeing a secure channel (against 3rd party eaves dropping).
And guaranteeing identity.
is
These are 2 different concepts.
Let's encrypt only takes care of the first one and has never ever hoped to tackle the second problem. They DO NOT certify owners, this field is intently left blank on their certificates.
The point of Let's Encrypt (as its name says) is that encryption becomes the norm on the web. In order to avoid massively stupid blunders, like the dead easy identity theft demonstrated by FireSheep.
That's something that CAN BE achieved for free, on a massive scale, like Let's Encrypt and CACert are doing.
There's no realistic way that let's encrypt could in any way confirm owner identity for free on this massive scale.
That's something which is very easy to understand for people who have some basic knowledge of security.
Saddly, sheeple are stupid. So you need to educate them and try to find ways to make them understand.
(e.g.: the above mentionned "show certified owner in the URL bar if provided" that Firefox is doing).
But sapping efforts like "Let's Encrypt" which are providing very valuable service (bringing the availability of HTTPS, TLS/SSL, etc. on a massice scale), simply because some idiot can't make the difference between "protection against 3rd party eavesdrop" and "identity of the owner" is counter-productive
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
and very few people would check EV
That's why some browsers like Firefox checks it for you and display it right in the URL bar.
You can't miss it.
What you really need is the domain registrars to check that if sites are being registered that are similar to a company name or trademark that they have a legitimate right to use that name.
Hey, then you need to ban slashdot.org, because it's name is similar to Slash. Or to DJ Slash. Or to Fatboy Slim's song.
The problem with "check that if sites are being registered that are similar to a company name or trademark" is that it's a complex task require some thinking that it's not trivial to automate for absolutely free (and in a way that won't be trivially circumvented by attackers).
It goes beyond the point of Let's Encrypt (whose point is, as the name indicate, just to make encryption available).
Or build a chain-of-trust system where people can blacklist a bad domain by voting it down
Which isn't an easy task to do (how many - outside of /. - to use PGP on a regular basis ?) Chain-of-trust system aren't easy.
Blacklist aren't silver bullet neither : an attacker could still bank on a quick attack trying to scam as many users as possible before getting flagged.
(See all the "software to make a millionaire out of you on binary option sites !" scam that are popping every where. Site costs under a couple of hundred in stock-photos / fiverr actors / ads promotion to set up, and can manage to make a few thousands selling snake oil before getting reported and shut down).
Neither of them have anything to do with HTTPS.
Which brings us back to the point : Let's Encrypt's purpose, as it names implies, is to bring the S in HTTPS and nothing more.
It's not their job solving the certification of owner in an easy way.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Why are you encrypting traffic within your own private network?
To avoid loss of functionality once the Fullscreen API becomes limited to secure contexts. Browsers no longer support sensitive JavaScript APIs over cleartext HTTP. There are plans to make Fullscreen API unavailable over cleartext HTTP because of demonstrated phishing attacks. Without the Fullscreen API, streaming video from a home NAS will be limited to a window.