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"
Jesus does not approve of homosexuality. All homosexuals are abominations in the eyes of our Lord. You must repent and turn away from your homosexuality or else you will surely face eternal damnation. Our Lord wants all of you to be saved, but you must believe in Jesus Christ and repent of your homosexuality in order to avoid the fires of hell. Our Lord is merciful and forgiving. It's not too late to repent!
Does anyone remember what the point of SSL was? It's just so our users don't see the non SSL warning right?
Phishing is a good thing. It weeds out the idiots who are too stupid and lazy to verify the legitimacy of emails and websites. I fail to see the problem here. It's not like anyone reading this site would be dumb enough to fall for a phishing attack.
Just as so-called service dogs are an emotional help, so are guns. Except guns have no negative impact on others unlike dogs, which are dirty and can trigger allergies.
It's time to end the discrimination against law abiding citizens and let people register their guns as service guns with all the same privileges as service dogs. Registered guns should be open carried everywhere: home, school, workplace, airplanes.
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.
It's to make development a pain in the balls because you're working on shit that's configured by domain name, and thus have to go hunt down every reference to foo.com and replace it with suckonmygiantfuckingcockyougooglefaggots.biz so Chrome will open your local fucking dev instance.
Once again people are confusing securing a communication with identity verification. Phishing sites can and already do buy HTTPS certs.
You know how browsers harassed self-signed certificates in the worst possible manner for ages until finally Let's Encrypt surfaced and made it possible for people who didn't want to pay the extortion fee to a commercial entity and fiddle around manually to actually get to run a HTTPS site without having instructions for each visitor on how to make an exception in their browser (which no user ever did in the history of mankind)?
Well, Let's Encrypt certificates are now going to be treated like self-signed certificates. Don't believe me? Just wait and see. All major browsers are being run by insane and/or evil people. It's going to happen.
It's time the browsers to blacklist certificates issued from Let's Encrypt. If ISPs or email service providers have a responsibility to make sure that bad guys don't use their domains for spam, phishing, downloading malware, and other nasty stuff, then so does LE. If you don't police your service, then the rest of the internet will do it for you by blocking you.
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.
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 ?
Nullius in verba
This message brought to you by the people that want to make you pay them for a cert.
some web browsers don't even check whether a certificate has been revoked.
This is a sloppy and invalid slur, hiding behind vagueness (it's a bogus criticism of Chrome). Revocation is useless when you fully work the threat model, and similar designs to address the uselessness are probably not workable. Remember, unless a scheme can handle revoking ~every certificate at once, it's inadequate recovery for Heartbleed. It's also a privacy problem because it lets CAs build a log of all web traffic.
The best incremental refinement is short-lived certificates auto-issued by intermediate CAs. CRLSet can revoke intermediate CAs. For normal certs, don't reissue and let them expire. That's basically what lets encrypt is, except "short-lived" is not short enough, like a day or two, yet. Also, as they point out, "weakest link": it's not a real answer unless every CA does it because an undeserving attacker could get someone to sign a long-lived cert for your domain even if you use short-lived ones. But this is the bog-obvious PKI refinement that's currently fashionable. The two-tier system keeps the CRL small, and the certs subject to "confirmation" (by not appearing in the latest short-lived CRL) can be backed by HSM that can't sign things quickly but is very unlikely to sign things wrongly.
The refinement being pushed instead of the obvious one is "OSCP stapling" and perhaps "must-staple", because this preserves the CA cartel. Without some long-lived rare magical token to give you, it's difficult to convince you that you owe them lots of money, so we still give you the token as a pacifier but then implement the above sane scheme in rube goldberg fashion, moving what should be the cert into the stapled confirmation.
However I think the correct response is not the obvious refinement. It's a major rethinking of the architecture, like Sovereign Keys. In this scheme, you must give up privacy to some central server because you must do lookups on a structure too big to store locally, but you can choose to whom you give it up because the structure is a blockchain that anyone can sync. Actually it might be small enough to store on a single computer so no big deal, but even if it weren't it's still less bad than OSCP privacy because of the option of picking a mirror you "trust".
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.
Slashdot, fix the reply notifications... You won't get away with it...
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.
HTTPS depends on trusting 3 things.
a) The site
b) The CA
c) The DNS
If any 1 of these things isn't trustworthy, none of them are.
Phishing site - never trustworthy.
CA - Symantec is an example, but there are lots of untrustworthy CAs https://arstechnica.com/securi...
DNS - hijacking DNS is a real thing. How much do you trust your network provider NOT to intercept all DNS and redirect them elsewhere?
(... 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.
And this is what happens when people actually sit down and talk to Jesus! (Better make the a double espresso with a shot of lithium...)
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 as well as some certificate authorities are pushing browser manufacturers to treat DV certificates differently from EV certificates, where the site owner's identity is verified. This would make sense. There's some politics going on here at Mozilla: according to Wikipedia, Firefox used to treat DV certificates subtly differently from EV certificates, but they changed that once they launched Let's Encrypt.
Real problems that Of the founders of about 770 users and has instead hand...don't share. *BSD is Join GNAA (GAY BSD machines,
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.
Now these connections can't be man in the middle attacked. This is a (slight) improvement.
Even invalid or self signed certificates leading to encrypted but not authenticated connections are better than unencrypted and unauthenticated, though browser vendors seems to disagree.
Also, if a website is committing a crime, its far easier to attribute the attack if you have strong evidence it was conducted by the actual domain owners (or said owners were criminally negligent and let their cert get used for crime): the TLD provider should be able to identify the owner of the domain, and the cert proves it was them that did the attack.
I think end users and browser vendors need to understand the difference between trusting a connection to someone, and trusting that end point to implement what the user actually wants.
If you blame the CA, for creating valid certificate for "misleading" domain name, why do you not blame also the registar?
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.
well it is called "lets encrypt" which has nothing to do with "lets know who were talking to"
If you have auto fill turned on, your browser may remember your PayPal information. A phishing site could setup in a way to steal the auto fill information without actually showing you a form. Another problem I've realized (maybe a tad off-topic) is that PayPal has allowed users to sign in with TouchID. There are parts of the world in which law enforcement can make you use your finger to unlock your phone; this also includes applications. In other words, PayPal gave law enforcement the keys to many peoples financial information but told everyone it was for convenience.
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 up screwed because there is no discipline and no market incentive to chose any path other than the one of least resistance.
We now live in a world where insecure jems like RFC6844 (DNS CAA) are necessary because CA's are too lazy even to be expected to coordinate amongst themselves.
I don't believe a world of countless dozens of overlapping planet scale trust anchors is rational to begin with. I have always advocated for any signing to leverage domain holders relationship with their registrar as a standard feature of domain ownership and get lazy third party CAs out of the equation altogether. The whole system has basically devolved into this only with much worse security/financial/effort outcomes for all concerned anyway. Way past time to force the worlds CAs out of business.
Yes originally it at least made sense if you were a bank or ecommerce site or something important you paid dearly each year for a cert and got something out of it in return. The second CA's abdicated their only value over domain registrars ... meaningfully vetting those seeking their blessings it should have been the second they ceased to exist altogether. They essentially became parasitic leaches from that point forward and the world has suffered for it as a result.
Read: https://letsencrypt.org/2015/1...
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 already are looking up in Google Safe Browsing API, so at-least there is some barrier to entry. And while I agree that it's not a CAs purpose to be internet police, I do hope that we'll see more best-effort protections to stem abuse. Granted this sort of a abuse is probably better fixed at registrar level.
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.
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:
[First-visit validation of a self-signed certificate is] where key fingerprints in DNS can help
Not until the root domain and major TLDs are signed with a key stronger than 1024-bit RSA. Short keys are why browsers haven't added support for DANE.
Even unauthenticated encryption is better than no encryption, because it prevents passive attacks.
It also gives the user a false sense of security that an active attack is not in progress. A self-signed certificate places the bar between "passive attack" and "active attack", but browser publishers have defined the https scheme to prefer a bar between "active attack" and "typosquatting".
An unencypted connection is fast, cacheable, and secure enough when you're just transfering photos and cat videos.
As far as I know, my browser does cache content served over https exactly the same as served over http.
But your ISP cannot cache said content. Say you have a classroom full of children all reading the same article on Wikipedia, and it's in a remote area with the only available Internet connection being a 0.13 Mbps ISDN or satellite link. With cleartext HTTP, a Squid or Polipo proxy can pull every . But with HTTPS, the proxy has to fall back to a separate CONNECT tunnel and transfer the same article 20 times unless the proxy is configured to intercept TLS, with its own root certificate in all browsers configured to use the proxy. Failure to cache in such a situation is inefficient, slow, and possibly costly if it causes the school to exceed a monthly Internet data transfer quota. (Source)
The best incremental refinement is short-lived certificates auto-issued by intermediate CAs. [...] The refinement being pushed instead of the obvious one is "OSCP stapling"
An OCSP response is a short-term statement issued by the CA that a TLS server's certificate is still valid. It can be thought of as exactly the sort of "short-lived certificate" that you describe. Stapling allows a TLS server to cache this response and present it alongside the main certificate. If only the TLS server contacts the CA to get OCSP responses, the CA can't see clients.
Sovereign Keys
From a footnote in the proposal: "In the current draft, there are additional requirements, including that an OCSP check for the CA certificate is successful".
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.
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.
Bullshit. The main purpose - or at least one of the main purposes - of PKI is that you're supposed to trust the certificate issuing authority to be validating the identity of the server. In practice, this becomes broken when CAs like LetsEncrypt decide that 'they don't want to be an internet watchdog' while issuing certificates that are vouching for the identity of phishing sites.