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.
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.
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 self-signed certificate was for. Let's encrypt ends up moving the goal posts from unencrypted, to self-signed, to lets-encrypt (but not verify identity), all the while improving nothing. An unencypted connection is fast, cacheable, and secure enough when you're just transfering photos and cat videos. 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.
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.
(... 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.
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.
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.
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.