Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites (bleepingcomputer.com) 250
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.
also.. (Score:4, Interesting)
they are changing the name to "Let's Phish"
Comment removed (Score:5, Insightful)
Re: but you arent a traditional CA (Score:5, Insightful)
Re: (Score:2)
Re: (Score:3)
And the person who owns www.phishme.com will actually own the domain www.phishme.com which is the domain that will show up on the certificate he is asking to be issued. The authority chain here is entirely preserved.
Re: (Score:2)
Correct certs are about AUTHENTICATION, Its to make sure that when you put your CC info in you really are sending it to paypal.com and not someone else. However, if letsencrypt lets me register päypal.com and you can't easily see something is different, that certificate isn't helping you to authenticate any more, its essentially a really good fake id! I am going to confuse that with the real paypal.
Its not a question of determining if phishme.com is safe or not its a question of knowing who you are t
Re: (Score:2)
I am going to confuse that with the real paypal.
Except that's not the difference you get in a browser. If you connect to a site with a domain validation certificate like the one Lets Encrypt issues then all the browser will say is "Secure"
If you're wanting to guarantee that you're actually connecting to PayPal then that's a completely different certificate with a completely different process for a completely different purpose, and shock horror it is handled differently by the browser and displayed differently to the end user. Instead of "secure" the bro
Re: (Score:2)
Typosquatting has been a problem for twenty years and DV certs fo at least half that time. Why would this suddenly be Let's Encrypt's problem? $4.95 has never stopped phishing attacks before.
Any typosquatting solution is going to be entirely locale dependent - the only place to handle that is at the browser. Give Google and MoFo hell about never caring about this. For all I know the Khazak word for "hot pizza" looks like "citibank" but it's definitely not a job for Let's Encrypt to deny that pizza plac
Re: (Score:2)
You have a basic lack of understanding of the purpose of certs. They guarantee that if you try to connect to phishme.com that you indeed are connecting to phishme.com and not being MITMed. It is NOT the purpose of a cert to say that phishme.com is or is not a safe place to go. The onus of that remains upon you regardless of if you use HTTP or HTTPS.
Yea, but have you noticed that the general public has no idea how much of anything actually works, or frankly what most things are actually for? Most people have no real idea what that little lock icon means, so (assuming that someone managed to train them to look for such things at all), they think the lock icon means they are good to go. The slightly more subtle message of 'yea, this website IS who it says it is, but that doesn't mean it's not a criminal' is lost on these people.
So yea, it's a problem, bu
Re: (Score:2)
Domain certificates do not identify or authenticate anything more than the server claiming to be the domain, and Lets Encrypt does a good job of proving that, probably more so than most other CAs.
If you want extended validation (The one that makes your browser say "PayPal Ltd. [US]" in the title bar rather than simple displaying a little green lock, then that's a different process and a different certificate, one which Let's Encrypt does not issue.
Re: (Score:3, Informative)
Nope, not going to happen.
The entire reason this is happening is because the browser vendors got a stick up their ass and required HTTP/2 connections to be run over TLS. So Let's Encrypt fills in the same space for HTTPS as Cloudflare does for CDN. They are not there to police their customers, and will ignore lots of shit until someone actually takes them to court.
The solution has always been there. The self-signed certificate should never have been "this might be a dangerous site" warning. That is what the
Re: (Score:2)
Which is why I am advising all my corporate clients that do SSL intercept to either block site that have used and LE cert, or present the invalid/self signed warning to their users. These things are not better than self singed.
Re: (Score:2)
These things are not better than self singed
And they are not trying to be. Why would you block a CA issuing only DV certificates when their process 100% confirms that the requestor of the DV certificate is the server owner?
Do you not trust your communication to Slashdot to be secure?
Block all DVs (Score:2)
The process might in fact be to block all domain-validated (DV) certificates and allow organization-validated (OV) and Extended Validation (EV) certificates. This would parallel the policy implemented by the Comodo Dragon browser, which displays a warning for DV certificates [netcraft.com]:
Re: (Score:2)
Which is why I am advising all my corporate clients that do SSL intercept to...
...stop that insecure crap immediately [us-cert.gov], because you take security seriously and don't want to weaken their defenses. Right?
Re: (Score:2)
The entire reason this is happening is because the browser vendors got a stick up their ass and required HTTP/2 connections to be run over TLS.
And by that, you mean the browser vendors realized that "unsafe by default" is a shitty choice for a widely used Internet standard.
For the "HTTPS-everywhere" has basically made website operators costs double if they want to jump on that bandwagon because the bandwidth costs explode when they can no longer be cached.
Totally worth the tradeoff for making strong encryption the expected default.
How big is the DANE key? (Score:2)
[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".
Caching by you vs. by your ISP (Score:2)
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 configu
Re: (Score:2)
That "lock" icon in the address bar is generally enough to convince people that what theyre doing with their Visa is sane. now, with letsencrypt, its not so certain.
I do not disagree with anything you wrote but this conflates the idea of a secure connection to a website as being a legitimate website. This has never been true.
if you're not going to at least police fraud or abuse, youre opening the service up to become a haven for quick and easy phishing sites. if you ignore this now, you might as well pack up and leave. Chrome and Firefox will not hesitate to lower their trust in your service
Sadly, this is true and I think some basic safeguard requirements need to be put in place to prevent new registrants/hidden registrants from abusing the service.
if it turns into the .info and .biz of the internet.
Sir, how you denigrate my superbe site, InternetIsSrs.Biz!
Re: (Score:2)
allows dangerous sites to quickly and easily bypass an entire host of browser security checks designed to prevent people from entering bank card information and personal data into an unprotected site. That "lock" icon in the address bar is generally enough to convince people that what theyre doing with their Visa is sane. now, with letsencrypt, its not so certain.
Except that's not what it does at all. A lock does not imply a chain of trust. The actual name in the actual site is what implies a chain of trust and you don't get that name from Let's Encrypt or any of the several free services which provided certificates in the past. If I go to my own personal website my browser says "Secure". If I go to PayPal my browser says "PayPal, Inc [US]." No checks have been bypassed.
Also quite frankly, GOOD. I still greatly prefer only one phisher getting my credit card informat
Re: (Score:2)
Sorry wrong "chain of trust". You're talking about a chain of trust back to the CA. I.e. website claims that they are a specific server, they claim another authority validated that, and the other authority is a root authority trusted by the browser and they can show that through the certificate chain. That is the chain of trust that will break the lock and bring up warnings if it is not setup correctly.
The "chain of trust" (I shouldn't have used that phrase) I was talking about is that you're talking to a s
Re: (Score:2)
Nope. StartSSL had been issuing free low-validation certs since at least 2009, some six years before Let's Encrypt issued its first cert. The only substantive differences between Let's Encrypt and StartSSL, as far as I can tell, are:
Re: (Score:2)
The most complicated process of getting a cert was for a "private doma
Re: (Score:2)
The few times I've used Let's Encrypt was during testing phases, as a place-holder until I had the time to get a "real" cert. My company has an inane procedure to get purchase orders to pay for anything, so often it takes a couple of weeks to get to the point of being able to purchase anything via a "new vendor". If you can't afford $5 or so to get a year-long cert, then your either not serious about your site or doing something wrong.
Or you have more than the one subdomain that most CAs allow for $5 certs. Even with a limit of five for Let's Encrypt, it takes two certs for my main domain. Bare domain, www, images, git, homeserver, kinji, and I feek like I'm still forgetting one. A wildcard domain cert starts at two hundred bucks.
Re: (Score:2)
You can get the equivalent of key pinning using DNSSEC and TLSA.
Now if browsers vendors supported TLSA it would improve security because rogue CA's can't issue a cert for the name that will be accepted.
there still is a barrier to entry (Score:2)
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
Re: (Score:3)
Re: (Score:2)
You mean to say I can't name a site for finding pals to play with "playpal.com"? It's not LetsEncrypt job to find out what the use of a site is for.
Re: (Score:2)
Re: (Score:2)
Why? Demonstrate where the trust chain is broken?
Lets Encrypt issues DV certificates only, and that chain of trust is 100% preserved, much more so than the process with many other CAs.
Foundamental flaw of the CA infrastructure (Score:5, Interesting)
This story shows the fundamental flaw of the TLS CA infrastructure: it only certifies that the connection is established with the reported DNS domain name. That is not utterly useless, but not far from it.
The protection against man-in-the-middle attack is relevant only in a handful of cases. With home Internet access, MitM can more or less only be performed by network operators, who have a lot to lose if they are caught playing these games. It is more of an issue with public access, but still rather minor.
What would be really useful would be CA that certify the honesty of the sites. “If you see our green padlock, that means this site is reliable. If they scam you, we will refund you.”
I will not hold my breath.
Re: (Score:2)
With home Internet access, MitM can more or less only be performed by network operators,
How so? This is exactly what HTTPS prevents.
Re: (Score:2)
The protection against man-in-the-middle attack is relevant only in a handful of cases. With home Internet access, MitM can more or less only be performed by network operators, who have a lot to lose if they are caught playing these games. It is more of an issue with public access, but still rather minor.
There is no difference between protection from man in the middle attacks for home users and users using public access. The user (or software / browser on the user's computer) is either validating certificates or they are not. Validation includes checking cryptographic signatures, checking revocation lists, and checking that the subject matches the requested resource (web site). It is true that checking signatures requires keeping tabs on what certificate authorities are trusted, which is a difficult problem
Re: (Score:2)
With home Internet access, MitM can more or less only be performed by network operators
Oh wow are you wrong about that. There are a myriad of ways you can MitM a connection other than passive listening. The most popular way is through malware that routes your connection via some third party. Having home internet doesn't make you secure against MitM attacks in the slightest.
Re: (Score:2)
Answering to this and the others:
If you install malware on the target's computer, that is not a man-in-the-middle, and certificate will be of little protection anyway.
Re: (Score:2)
Re: (Score:2)
The protection against man-in-the-middle attack is relevant only in a handful of cases. With home Internet access, MitM can more or less only be performed by network operators, who have a lot to lose if they are caught playing these games. It is more of an issue with public access, but still rather minor.
You don't really know how SSL/TLS works do you?
Re: (Score:2)
You are entirely correct. It was the same when I was running a web store in the 90s. It took me all of 30 seconds to figure out that the only thing a Certificate Authority is certifying is that your credit card didn't bounce, and the only thing they're an authority on is processing credit cards.
Re: (Score:2)
What would be really useful would be CA that certify the honesty of the sites. “If you see our green padlock, that means this site is reliable. If they scam you, we will refund you.”
They already work the way you think. You just don't understand the difference between the green padlock and the green text that comes up with an OV or EV certificate.
The certificates issued to www.paypal.com will show a green padlock along with the very obvious text "PayPal Ltd [US]" next to it. The certificates issued to www.playpal.com will only show that little padlock indicating the channel is encrypted.
Re: (Score:2)
They cannot work the way I evoke when the CA is chosen by the server and not the client.
Re: (Score:2)
The CA IS chosen by the client. It is your prerogative who you trust to be a CA. The browsers only come with a list of defaults. Those list of defaults are based on what the browser vendors think is sane based on the performance of the authority. And quite frankly an authority that actually physically checks that a user is able to run a script that modifies a directory on a server within a domain in question is pretty damn authoritative on defining that a server belongs to a domain that it claims (the scope
Re: (Score:2)
The CA IS chosen by the client.
No, the CA is chosen by the server. The only choice for the client is to either trust or not trust. They cannot decide to use another CA with more guarantees.
defining that a server belongs to a domain that it claims
Which is all but useless, and exactly the source of the present thread.
silent s (Score:2, Insightful)
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 ?
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
If it doesn't authenticate anything then it is worthless
Oh but it does. A DV certificate authenticates that a computer responding on behalf of a domain is who it claims to be. Let's Encrypt is perfectly fine for that and does not issue any certificate with information that isn't completely authenticated. This is why they don't issue OV or EV certificates.
The S doesn't indicate anything to do with security and encryption. It indicates a different protocol to standard HTTP is being used. The various results of different certificates are shown differently by browse
Using PayPal in the domain name (Score:2)
Seems familiar (Score:4, Informative)
Something about road to hell being paved with good intentions.
The issue is not SSL, certs or lack thereof. The issue is the fact that among human population there exist several fairly consistent groups. One of these groups is "low information people" (not to call them "stupid"). Another group is "dishonest people". Yet another is "well intentioned people" who want to protect the former from the latter. But, as the "wily" are, by definition, loath to play by the rules and, in general, fairly smart - they will surely find ways to exploit whatever well intentioned thing to take advantage of the "low informed".
There isn't really any solution here.
Re: (Score:3)
"Low-information" is a silly PC circumlocation. There are perfectly appropriate terms such as "ignorant" and "naive" to use to describe people who don't know stuff.
More tips for browser makers (Score:5, Informative)
(... because I'm sure they read /. and value my opinion... )
1. NEVER hide ANY part of the URL. If the URL extends beyond the size of the location box, give a nice big '...' for people to click on to see it.
2. ALWAYS show a status bar that ALWAYS shows what URL I'll go to if I click a link. NEVER allow ANYTHING to change this behavior.
3. NEVER hide the protocol.
4. Don't allow 'data' URIs in the URL bar by default. https://www.wordfence.com/blog... [wordfence.com] (This also relates to #1)
5. Don't make SUCH a big damn deal about 'https' -- big green text, giant padlock icons, etc. I've been telling people for YEARS that an HTTPS connection to bankofamurica.ru is worth NOTHING.
This won't solve everything, but the least that browser makers can do is give people the tools they need to help them make good decisions. Long story short, QUIT HIDING SHIT!
6. Bonus: enough with all these new shit TLDs. Is a world where http://blog.google/ [blog.google] exists (note: it does) REALLY a better place than one where it doesn't? Or is it just more confusing?
Re: (Score:2)
2. ALWAYS show a status bar that ALWAYS shows what URL I'll go to if I click a link. NEVER allow ANYTHING to change this behavior.
Also, don't allow changing what is shown in that status bar, like custom text instead of that link.
Re: (Score:2)
1. Agree
2. Irrelevant. Sources from phishing attacks do not originate from within the browser. Most often they do from some external source (email being the most popular).
3. Irrelevant. No one cares about the protocol and the general public doesn't understand it so it does nothing to aid security. Even on browsers that hide the protocol people interested in it can identify it from the rest of the information in the URL bar (the colour / padlock icon).
4. Agree
5. They don't. There's a difference in the displa
Re: (Score:2)
1. NEVER hide ANY part of the URL. If the URL extends beyond the size of the location box, give a nice big '...' for people to click on to see it.
Given the example domains are of the form paypal.com.abc.xyz.tld (example: paypal.com.resolution-ticket.tk) maybe the tld should always be visible.
Re: (Score:2)
Two fixes. The bulky method shows if there's any onclick or onleavepage events going to fire when you click said link. The other method involves a few click to ban certain sites from running javascript.
Clarify "certificate identity" (Score:2)
Something doesn't add-up:
During the past year, Let's Encrypt has issued a total of 15,270 SSL certificates that contained the word "PayPal" in the domain name or the certificate identity.
(Emphasis mine).
But according to Let's Encrypt, their certificates don't say anything about identity:
Let’s Encrypt is going to be issuing Domain Validation (DV) certificates. On a technical level, a DV certificate asserts that a public key belongs to a domain – it says nothing else about a site’s content or who runs it. DV certificates do not include any information about a website’s reputation, real-world identity, or safety.
Can someone explain what the author meant by the term "certificate identity" in a Domain Validation certificate? It almost seems like the author of the article is conflating the concepts of DV certificates and EV certificates into one. Or am I wrong, and DV certs do indeed have an identity?
In researching this a bit, the CA security council [casecurity.org] as well as some certificate authorities [digicert.com]
How is this an abuse of Let's Encrypt? (Score:2)
Letsencrypt versus a 'real' CA (Score:4, Interesting)
I think most people here would spot a fake site without the ev,
Even CA's have issued 'bad' certs to people - Symantec and others have also failed the test.
Re:Letsencrypt versus a 'real' CA (Score:5, Informative)
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.
Let's be responsible (Score:2)
Encryption without trust = dangerous illusion (Score:2)
Years ago everyone who wanted an SSL cert had to provide actual corporate documentation reviewed by actual people. Everything was essentially "EV".
Then all the CA vendors said fuck it, lets make more money on volume without doing any work and switched to automated systems.
Finally Let's encrypt came along and said double fuck it not only will we use automated systems but we'll make it FREEEEEEEEE.
The end result is a phenomena well known to the technology industry. A race to the bottom where everyone ends u
Re: (Score:2)
You seem to imply because something is free and automated that there is a lack of trust. There is not. DV certificates still identify the server as responsible for responding on behalf of the domain in question.
What you're complaining about is trust beyond the machines and into the organisation and people behind the servers. This is something outside of the scope of DVs, outside of the scope of Lets Encrypt, and quite critically also handled and displayed differently to the user by the browsers.
There's noth
Wrong conclusion (Score:2)
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.
Re:Never saw that coming (Score:5, Insightful)
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.
Re:Never saw that coming (Score:5, Insightful)
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 [ietf.org]?
Re:Never saw that coming (Score:5, Informative)
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.
Re: (Score:3)
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.
Business model of a free site ?! (Score:3)
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
Re: (Score:2)
Re: (Score:3)
Re:Never saw that coming (Score:5, Informative)
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.
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:3)
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), goog
Revoke slashdot.org's certificate ! (Score:3)
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 [wikipedia.org]. Or to DJ Slash [mixcloud.com]. Or to Fatboy Slim's song [wikipedia.org].
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 go
Re: Never saw that coming (Score:5, Informative)
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.
Re: (Score:3)
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
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:3)
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 differ
Re: (Score:2)
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.
Re: (Score:2)
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"?
Re:Never saw that coming (Score:4)
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
Re:Phishing is good (Score:5, Informative)
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.
Re: (Score:2)
Re: (Score:3)
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 k
Re: (Score:2)
Normal people have no idea what https://paypal.com/ [paypal.com] is. For them https://paypal.co/ [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 "->
Re: (Score:2)
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 accoun
Re: (Score:2)
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 20
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Whats to stop a virus from dumping the autofill cache instead of capturing keystrokes? You've traded one problem for another.
Re: (Score:2)
A person who knows to install a NoScript plugin, also knows not to blindly use google search as an address bar.
Re: Phishing is good (Score:2)
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
Re: (Score:2)
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.
Secure Contexts and Fullscreen API (Score:3)
Why are you encrypting traffic within your own private network?
To avoid loss of functionality once the Fullscreen API [w3.org] becomes limited to secure contexts [pineight.com]. Browsers no longer support sensitive JavaScript APIs [github.io] over cleartext HTTP. There are plans to make Fullscreen API unavailable over cleartext HTTP [stackoverflow.com] because of demonstrated phishing attacks [feross.org]. Without the Fullscreen API, streaming video from a home NAS will be limited to a window.
Re: (Score:2)
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/ [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.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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/ [paypal.com] into their browser address bar.
Re: (Score:2)
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 [letsencrypt.org], 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 [live.com] appears to be using a DV certificate.