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
We get it. You have no idea what certs are for. No need to keep making the point.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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
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
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
The identity of the endpoint is shown in the browser URL. To prevent a MITM attack, I recommend using NoScript, so you can enable javascript on paypal.com, and your browser will then not run javascript on phisingpaypal.com without the user enabling it.
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
NoScript. You enable javascript for paypal.com and then anytime you visit paypall.com, your browser sits there not running any javascript.
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
You have so much knowledge and such good people skills, I suggest you help senior citizens become more net savvy by volunteering some of your time in a nursing home or local senior citizen's center. Hopefully you can educate people like my mother, who just shook her head and said "I don't understand the instructions, it's all in geek".
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.
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.
(... 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.
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.
A person who knows to install a NoScript plugin, also knows not to blindly use google search as an address bar.
- Don't do what I do, it's probably not healthy nor safe. -
Normal people have no idea what https://paypal.com/ is. For them https://paypal.co/ looks perfectly fine (PayPal might have bought all second level domains but I highly doubt that). Normal people have no idea what "com" means, what domains levels are, what's the meaning of dot in the domain name. What's the meaning of HTTP or HTTPS whereas the former is now hidden by all major web browsers. I'm an IT pro and I've no idea why there are these three letters "://" after the protocol name. Why not "::" or "->" or any other arbitrary combination?
Normal people may want to visit paypal for the first time ever which means no AutoFill data or any indication they've arrived at the website they can really trust.
Idiots who say you should trust a website based on its name think too much of people. The Internet was designed for geeks and remains so, no matter what geeks say. And it wasn't designed with security/privacy/encryption/simplicity in mind - to the contrary, the first major protocols had nothing to do with encryption or remote party identification.
Here's an example from real life: my ISP transparently replaces IP records for DNS queries for forbidden websites (it's a usual practice even in the USA) - how on Earth you could trust a domain name, when your ISP can reroute your traffic at will? And no! I'm not using my ISP's DNS resolver - I have a recursive DNS server on my PC - which means they transparently replace my UDP traffic. The only way to be sure that my connection attempt is not spoofed is what? VPN? No, you cannot trust it either. DNSSEC hasn't really taken off and then you cannot really trust CAs nowadays.
Sorry, I've never seen so many idiots at /. simultaneously.
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.
I quite agree with that, however just like I said, the Internet and computer devices are inherently insecure. How would you teach them not to trust DNS or their Internet connection? How would you teach them not to trust their OS or their computing device (now that we know that BIOS/UEFI/your NIC/HDD firmware can all be p0wned)?
As of 2017 we're all fucked. Some people naÃvely believe we aren't. The ones who usually run Windows without any decent AV. At the same time 100% of modern CPUs (x86/ARM) are rigged for remote control without you knowing. >98% of people in the world run software/firmware/integrated circuits (read CPUs, DSPs, etc. etc. etc) which only select people in the world can access and verify.
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.
Normal people trust their search engine to return the real PayPal site when they search for it. The worst realistic scenario from a non-user getting otherwise redirected to a fake version of the site is having to contest false charges on a credit card and report the card stolen. No big deal. It becomes dangerous when you associate a bank account with it, which no mentally competent person should do when visiting a site referred from some random new website. But once you have done that, accidentally giving out your password to a phishing site becomes a really big deal, because you probably won't get that money back.
What the h*** else can you possibly use as a basis for trust? Do you expect us to create a little walled garden that prevents the free flow of information just in case some bad person decides to do something bad with that ability? We had that. It was called AOL, and it failed because it was too limited compared with the real web.
You should really be encouraging broader adoption of DNSSec so that we'll eventually be able to make DNSSec validation mandatory instead of whining on Slashdot that we aren't taking the problem seriously. Or propose a better solution. Either way.
With all due respect, has it ever occurred to you that if you think a large number of really smart people are idiots, it probably means that you don't understand the problem as much as you think you do? Just saying.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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.
HTTPS was a badly realized afterthought and it bites people all the time. I wonder if this problem can be solved at all.
The intention of HTTPS was only to provide secure communication between the client and server.
Saying it was horribly designed afterthought because it doesn't verify the owner of the server is simply false. That was never the point. That may have been something the CAs propped up, and then browsers started blocking use of self-signed certs. So now we're back at square one, as LetsEncrypt now offers a no cost solution to replace self-signed certs.
This is what LetsEncrypt believes, as well. The entire point of LetsEncrypt is to allow everyone to securely communicate with their own sites, free from spying of ${GOVERNMENT_ENTITY} or malicious hackers.
We simply need some other way to identify if a website is who it says it is. HTTPS was never meant for that, despite what the CAs have led you to believe.
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.
You know that there are cyrillic characters that look exactly like the roman ones we use except they have another unicode code point? So www.microsoft.com (to use a REAL example) could have a cyrillic o in there and you can't actually see the difference because the two characters are renderered identically?
Besides, I noticed that ld ' uo p uplo ,no
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
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.
Yes. I agree. Our local admin (who is a paranoiac) thinks autofill is the evilz. Autofill increases security for exactly that reason.
Bonus # 2: Autofill makes you much more immune to viruses that capture keystrokes, of which there are plenty.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
The point of the certificates is to provide a means to establish confidentiality, integrity, and identification of the server hosting information. Issuing fraudulent certificates undermines the security and leads to fraud.
The problem is very few people are aware of the correct URLs, and simply put "paypal" into google and follow the first result that comes up, or click the paypal link on ebay or that arrives in an email for example... They never directly enter https://www.paypal.com/ into their browser address bar.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Whats to stop a virus from dumping the autofill cache instead of capturing keystrokes? You've traded one problem for another.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
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.
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.
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.
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.
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.
Issuing a certificate to BobsCarRepair.com is one thing. Obviously you have no way of knowing whether or not Bob is a reputable business.
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.
If the identity of the endpoint can't be verified, exactly how is it that MITM is prevented?
The purpose of these CAs is to Verify the Identity of the Domain Name for the purpose of establishing TLS connections. They verify DNS domain name Identity, Not Organizational Identity.
I.e. They verify the person who controls the Hostname authorizes the certificate, Not that the Hostname is owned by the company name and end user speculates the DNS domain name belongs to.
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.
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.
Does anyone remember what the point of SSL was? It's just so our users don't see the non SSL warning right?
You say that jokingly, but there's some truth to that. The need for TLS is proportional to the damage done by compromising the connection. Informational websites with no credentials do NOT need TLS, typically, and the push to add TLS more broadly has played a major role in lowering the bar for getting a cert (out of necessity), thus weakening an already weak system further.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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
Without TLS, how do you ensure that a man in the middle isn't altering the information that you retrieve from said "Informational websites with no credentials"?
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".
The registrars are *supposed* to do visual aliasing checks when issuing internationalized domain names. If that isn't happening, the failing party is clear. It isn't as though this hasn't been a known problem for years....
Check out my sci-fi/humor trilogy at PatriotsBooks.
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
Let's say, you entered paypal in Google and miraculously the second link leads to paypall.com
Wait.... Google lists a Fake website as Hit #2 in a search result, and people are ragging on LetsEncrypt? Clearly, the Search Engine is to blame here.
The way you safely access PayPal is DONT SEARCH FOR IT. you type http://www.paypal.com/ into your Browser address bar, AND you check the typing carefully before pressing enter.
Also, if you typo'd the website name, your browser should show an error page. And if you've ever visited www.paypal.com it should warn you that maybe you made a typo, before proceeding to access the different site.
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.
Depending on which CA, there won't be much extra verification.
The ones that don't do much extra by policy don't qualify to have their root certificate included in browsers.
Although, for some reason Chrome does not show the company name on Organization-Verified certificates.
Because OV certificates are the category you mention above, there isn't much extra qualification involved. Firefox also doesn't show OV certificates as green.
And that's not what HTTPS is for. As mentioned that's what the CA's provided, but it certainly was not a part of HTTPS.
As another commenter pointed out, DNSSEC and DANE will provide this functionality, instead of the CAs, in the future.
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.
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)
MiTM attack has nothing to do with JavaScript.
Well, Let's Encrypt certificates are now going to be treated like self-signed certificates. Don't believe me? Just wait and see.
With both Mozilla and Google as "major sponsors" of Let's Encrypt listed on the front page, I don't see how this will happen any time soon. If Microsoft and Apple distrust Let's Encrypt for following the same CA/Browser Forum Baseline Requirements as every other certificate authority issuing domain-validated (DV) certificates, the only way to avoid a double standard would be to distrust all DV certificates. And as of today, the service formerly known as Hotmail appears to be using a DV certificate.
A domain-validated certificate is for ensuring the authenticity of communications between your machine and a machine operated by the owner of a particular hostname. It isn't for ensuring that the owner of a particular hostname has any right under other applicable law, such as typosquatting provisions of trademark law, to use that hostname.
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".
You enable javascript for paypal.com and then anytime you visit paypall.com, your browser sits there not running any javascript.
Then phishers are going to make their sites compatible with NoScript, such as by computing the final DOM, serializing it to HTML, and sending that to the mark instead of the script that generates the DOM.
LetsEncrypt now offers a no cost solution to replace self-signed certs.
This is true only for servers with fully qualified domain names, not for internal servers with private IP addresses or made-up TLDs such as .local or .internal. Is every householder supposed to buy a domain to make HTTPS communication across the LAN with a router, printer, or streaming media server work?
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?
The ones that don't do much extra by policy don't qualify to have their root certificate included in browsers.
What do you mean by that? You suggested EV certs mean the CA sends boots on the ground and verifies the presence of your offices, But they don't.
In reality, what it means Is they ask you a series of questions whose answers will be checked using databases containing information gathered from public records.
Because OV certificates are the category you mention above, there isn't much extra qualification involved.
The CAs are not allowed to put in a Company Name they have not verified. They're basically just the same as the EVs. You upload some scanned documents, and then answer some questions, and you'll get either type of cert really quick,
except the EV has an arbitrarily higher price tag.
To be fair this is because browsers like Chrome (swiftly followed by Edge and Firefox) have all decided that the search bar SHOULD act exactly like search. They removed the dedicated search box in favour of a "smart" unified typing place that in my experience, fails to select the correct thing to do about 50% of the time.
It's almost impossible to just type a hostname into the Complete Unified New Technology bar and consistently have the browser load the site (unless you hack Firefox options; I don't use Chrome so I don't know if it's possible at all and I can't see a way to make Edge be sane). No - a simple word MUST mean you're searching for something even if it's locally resolvable and not a word in any language. Thanks Google et al, making the world a worse place, one step at a time.
"The purpose of these CAs is to Verify the Identity of the Domain Name for the purpose of establishing TLS connections. They verify DNS domain name Identity, Not Organizational Identity."
/. cert is also issued by "Let's Encrypt."
Your point? Unless there's a DNS compromise, AND a cert is issued by a widely accepted CA which doesn't verify the actual domain, it's not a real issue. Someone trusting a link to paypall.com isn't an https/cert issue, it's an issue of ignorance. It's not any more serious than a fishing attempt which looks for email responses, or Rachael from Cardholder Services calling and asking for a credit card number and someone believing them. And what if someone does create a real "Organizational Identity" of Paypall? Then the difference between DNS and organizational identity is nil. Ultimately, people have to exercise due diligence, or they'll get burned. Trying to tell them that there are technical solutions for their naivete is a counterproductive lie, only instilling a false sense of security.
What's really interesting is that the
"National Security is the chief cause of national insecurity." - Celine's First Law
Why are you encrypting traffic within your own private network?
Phishing attacks are prevented by Extended Validation.
No they're not. If you look at phishing stats before and after EV certs were introduced, there was zero change. Well, it actually got worse, but that's because it's been getting worse for years. The rate of change was a straight line, there wasn't even a noticeable bump brought about by EV certs.
What you actually should have said was:
CA revenue problems are prevented by Extended Validation certificates.
Except that they don't. Unless you can show me an example where they don't use any javascript in a login page.
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
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 ]
It's not PayPal itself, but the login page for Phil's Hobby Shop can work without JavaScript. The only part that changes with script off is that you have to submit with a blank password in order to enable "Show password as I type".
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.
Fair enough. Luckily, phishers don't bother with a non-javascript login page even though it is possible.
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
Indeed. PEBKAC is a limiting factor. Point is that people who check EVs are the same people who check the little lock symbol. There's no increased risk of a DV certificate going to phishers as phishers were just as good at phishing with no security at all.
I didn't use the words Boots on the ground, and no that is NOT and never was the expectation of EV. The expectation is that there are a policy and process through which they verify third party companies exist and are legitimate, and that this process is validated through an external auditor. This well and truly exists with most CAs and ... well we only recently ran a story about one where this process wasn't sufficient. Guess who no longer has their root cert in any browser.
In reality, what it means Is they ask you a series of questions whose answers will be checked using databases containing information gathered from public records.
Yes. That's no different to your mythical boots on the ground. It's also no different to the deed of my house, the shares I own in my company, and my entire personal identity. Documentation and answers show that you are who you claim to be.
They're basically just the same as the EVs.
The bar is set higher. There's a difference.
Yes they are. The fact that they don't work is entirely different to the concepts within the scope of discussion.
The scope of discussion is: Phishing attacks being prevented by certificates, and the extended risk of Let's Encrypt providing free DV certificates
What I said was: In summary: preventing phishing attacks is the scope of EVs not DVs.
Whether or not it works is irrelevant. The point it it got no worse through the freely available DVs.
You don't, but it almost never matters. MiTM attacks tend to be harder than passive sniffing, and there are very few reasons why any ISP in its right mind would do so. They're far more likely to do blocking, or redirect a streaming site to their own streaming site, or other absurdity that's easy to spot.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Google.com also involves authentication credentials. You can't usefully do a phishing attack against a website that involves no credentials, because there's nothing to phish.
Check out my sci-fi/humor trilogy at PatriotsBooks.
It's not always a home ISP that's doing subtle MITM modification. It might be someone malicious in the same coffee shop as you. Or it might be a government agency using the Fullscreen API to spoof the chrome of the entire desktop environment.
Yes they are. The fact that they don't work is entirely different to the concepts within the scope of discussion.
Whether or not it works is irrelevant.
"Here's a solution. It's gonna be great, you'll love it. The fact that it doesn't work is irrelevant".
Wait.... Donald, is that you? Mr. President?
Assuming DNSSec gets deployed as it should, someone in the same coffee shop will be able to passively snoop, but won't realistically be able to be in the middle of the communication unless the infrastructure is badly broken. After all, two hops over Wi-Fi should always realistically have higher latency than one hop plus a DHCP response. The biggest weakness is UDP-based DNS. For that matter, you could disable UDP-based DNS today, and you'd pretty much kill any hope of MiTM attacks by anybody other than your ISP. Arguably, you probably should.
At that point, your endpoint is untrusted, so the communication is untrusted, period. There is no security mechanism that can have any real benefit if you cannot trust the browser itself or the operating system under it.
Check out my sci-fi/humor trilogy at PatriotsBooks.
If by succeeding, you mean completely failing to have any significant role in online commerce, and not being a significant source of information beyond currently trending events, then sure. Call me when there's something equivalent to Wikipedia that's built into Facebook without linking out into the Internet as a whole, or something equivalent to Amazon, or something equivalent to airline and hotel reservation websites, or....
So no, Facebook is not succeeding as a replacement for the Internet—only for the very narrow slice of the Internet that was previously dominated by MySpace.
Check out my sci-fi/humor trilogy at PatriotsBooks.
If by succeeding, you mean completely failing to have any significant role in online commerce, and not being a significant source of information beyond currently trending events, then sure. Call me when there's something equivalent to Wikipedia that's built into Facebook without linking out into the Internet as a whole, or something equivalent to Amazon, or something equivalent to airline and hotel reservation websites, or....
So no, Facebook is not succeeding as a replacement for the Internet—only for the very narrow slice of the Internet that was previously dominated by MySpace.
Check out my sci-fi/humor trilogy at PatriotsBooks.
If by succeeding, you mean completely failing to have any significant role in online commerce, and not being a significant source of information beyond currently trending events, then sure. Call me when there's something equivalent to Wikipedia that's built into Facebook without linking out into the Internet as a whole, or something equivalent to Amazon, or something equivalent to airline and hotel reservation websites, or....
So no, Facebook is not succeeding as a replacement for the Internetâ"only for the very narrow slice of the Internet that was previously dominated by MySpace.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Oops. Slashdot's website broke badly. Submissions weren't showing up for minutes. And now I got three identical posts because the duplicate post detection also wasn't working. *sigh*. Sorry for the noise.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Assuming DNSSec gets deployed as it should
Not likely as long as domain registrars that bundle DNS service charge extra for DNSSec. <cough>GoDaddy</cough>
someone in the same coffee shop will be able to passively snoop, but won't realistically be able to be in the middle of the communication unless the infrastructure is badly broken.
It is in fact "badly broken." If Starbucks Wi-Fi is "attwifi" (as it often is) and an attacker with two radios makes a bridge with the other end having the SSID "Starbucks", a first-time visitor won't know the difference and will likely choose to associate to the rogue AP.
At that point, your endpoint is untrusted
In the case of Fullscreen API, HTTPS strengthens the identity of the entity that made the endpoint appear less trusted. Under current policy, when an origin goes full-screen for the first time, the browser presents a "cancel or allow" prompt showing the hostname in big letters. But with cleartext HTTP, the user can't be sure that he's communicating with the intended origin instead of an active attacker.