Let's Encrypt Criticized Over Speedy HTTPS Certifications (threatpost.com) 207
100 million HTTPS certificates were issued in the last year by Let's Encrypt -- a free certificate authority founded by Mozilla, Cisco and the Electronic Frontier Foundation -- and they're now issuing more than 100,000 HTTPS certificates every day. Should they be performing more vetting? msm1267 shared this article from Kaspersky Lab's ThreatPost blog:
[S]ome critics are sounding alarm bells and warning that Let's Encrypt might be guilty of going too far, too fast, and delivering too much of a good thing without the right checks and balances in place. The primary concern has been that while the growth of SSL/TLS encryption is a positive trend, it also offers criminals an easy way to facilitate website spoofing, server impersonation, man-in-the-middle attacks, and a way to sneak malware through company firewalls... Critics do not contend Let's Encrypt is responsible for these types of abuses. Rather, because it is the 800-pound gorilla when it comes to issuing basic domain validation certificates, critics believe Let's Encrypt could do a better job vetting applicants to weed out bad actors... "I think there should be some type of vetting process. That would make it more difficult for malicious actors to get them," said Justin Jett, director of audit and compliance at Plixer, a network traffic analytics firm...
Josh Aas, executive director of the Internet Security Research Group, the organization that oversees Let's Encrypt, points out that its role is not to police the internet, rather its mission is to make communications secure. He added that, unlike commercial certificate authorities, it keeps a searchable public database of every single domain it issues. "When people get surprised at the number of PayPal phishing sites and get worked up about it, the reason they know about it is because we allow anyone to search our records," he said. Many other certificate authorities keep their databases of issued certificates private, citing competitive reasons and that customers don't want to broadcast the names of their servers... The reason people treat us like a punching bag is that we are big and we are transparent. "
The criticism intensified after Let's Encrypt announced they'd soon offer wildcard certificates for subdomains. But the article also cites security researcher Scott Helme, who "argued if encryption is to be available to all then that includes the small percent of bad actors. 'I don't think it's for Signal, or Let's Encrypt, to decide who should have access to encryption."
Josh Aas, executive director of the Internet Security Research Group, the organization that oversees Let's Encrypt, points out that its role is not to police the internet, rather its mission is to make communications secure. He added that, unlike commercial certificate authorities, it keeps a searchable public database of every single domain it issues. "When people get surprised at the number of PayPal phishing sites and get worked up about it, the reason they know about it is because we allow anyone to search our records," he said. Many other certificate authorities keep their databases of issued certificates private, citing competitive reasons and that customers don't want to broadcast the names of their servers... The reason people treat us like a punching bag is that we are big and we are transparent. "
The criticism intensified after Let's Encrypt announced they'd soon offer wildcard certificates for subdomains. But the article also cites security researcher Scott Helme, who "argued if encryption is to be available to all then that includes the small percent of bad actors. 'I don't think it's for Signal, or Let's Encrypt, to decide who should have access to encryption."
Strawman criticism (Score:5, Insightful)
Re: (Score:2)
You don't have to wonder (Score:2)
Re: (Score:3)
agreed (Score:2)
"I don't think it's for Signal, or Let's Encrypt, to decide who should have access to encryption."
Similarly, I don't think it makes a lick of sense that Google is a "super-authority" in deprecating entire CAs. That's rather close to a mechanism for monopoly.
Re: agreed (Score:5, Insightful)
That's a large part of why the CA model is broken. CAs shouldn't be competing at all; they're there to provide a service. Imagine if OpenPGP keyservers were competing... There's no reason for it unless you're a bad actor to begin with.
What LE is doing has helped people see that a security cert isn't something you should pay for, and that being signed by a CA doesn't mean anything, especially with the shitty politics Google et al have been playing at the CA level.
The well is poisoned, and the big boys are attacking the people who pointed it out.
Re: (Score:2)
At the same time I believe there is a difference between encryption for the target site and a certificate saying the site is owned by the people who claim they do. The standard for the former is likely to be lower than for the latter.
For example I want to know that the data for www.somedomain.mars is encrypted for said site, while for www.mybank.mars it is encrypted for the site and also owned by my bank.
The real question should be what should the expectations of a certificate for a given context and are th
Re: (Score:2)
Re: (Score:2)
If I'm reading your post correctly, it sounds like a BGP attack. I just did a quick check and found that LetsEncrypt does also check previously issued certificates, so if you've already got a (valid) cert for your domain, then it's going to be a lot harder to get LetsEncrypt to issue a cert to the spoofed domain (the attacker wouldn't have the original private key).
Re: agreed (Score:4, Insightful)
Personally I believe DANE [wikipedia.org] is the future of secure websites.
CA's could still be useful for vetting entities and ensuring the domain you are connecting to is owned by the Entity you are trying to connect to.
Much like how Extended Validation certs are made, but the CA's would really need to step up their game.
Re:agreed (Score:5, Insightful)
The fact that Chrome and FF use their own cert stores and update them unilaterally without the user ever knowing is absurd.
The browser should use the cert store on the OS. And the OS should update the certs. (And when MS updates certs, it should optionally present detailed info to the user about changes.)
The entire concept of CAs is built around trust in an environment where none of the actors and powers that be are trustworthy.
Re:agreed (Score:5, Insightful)
Often the only indication the user has that they are being MITMed is precisely because the browser did not use the OS cert store.
Re: (Score:2)
Often the only indication the user has that they are being MITMed is precisely because the browser did not use the OS cert store.
That's not a good reason for multiple cert stores managed by multiple parties. That's like having multiple gates to the same city where the North gate requires one set of ID and the South gate requires a different set.
Re: (Score:2)
Why is Microsoft better qualified to maintain certificate stores than Mozilla and Google? It's not like every browser maintaining its own store on a machine is a huge drain on resources. When it comes to security, diversity is a good thing. Or should the UN institute a global authority to maintain a certificate store for use on every browser on every device?
Re: (Score:3)
What's absurd is that you use someone else's CA store to begin with. I remove CA's I don't interact with. I never had a problem removing things like the Turkish or Netherlands government, nobody uses their certificates.
The problem is that Microsoft is the worst when it comes to vetting CA's because it could impact one of their "enterprise customers". As long as Microsoft puts their higher paying customer before you, they aren't trustworthy.
Re: (Score:2)
Errr.... Chrome uses Microsoft's certificate store on Windows.
Re: (Score:2)
Not always. Update Chrome and they'll blacklist/whitelist things in addition.
Re: (Score:2)
Because it makes sense. No, not all users. But users who care, and most importantly, the choice needs to be made when changes are made, especially to root level certs.
Nonsense (Score:5, Insightful)
My boss recently got an ESL certificate from a reputable tier-1 vendor. The validation was a complete joke: A guy with bad English asked him some questions over the phone that anybody could have found the answers to with a bit of work. The only security in place for ESL certs is that they are not that cheap, but that does not help against a targeted attack, because they are not really expensive either.
The bottom line is that certificates weakly ensure one thing: You are still talking to the same site on the next visit. They also ensure that small-time criminals will find it somewhat difficult to eavesdrop. And that is about it. In many cases, self-signed certificates will be more secure than that. The whole certificate-system is a bad joke, created by the utterly incompetent with too much trust and then corrupted by state-sponsored malicious actors. Incidentally, this is not a surprise. Basically all what is broken with the system now was predicted by perceptive people decades ago.
Re: Nonsense (Score:2, Funny)
Well of course ESL resulted in bad English
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
The theory behind the certificate chains is a web-of-trust sort of theory.
In practice, it doesn't really work that way: Users are either greeted with no prompt and an unsecured connection, a prompt with a secured connection, or no prompt with a secured connection.
That's all the user knows...and that's if they're even paying attention.
(There's a fourth user-case of "The key has changed!!!2!!," but that's something that doesn't generally happen because DNS hijacking is uncommon these days.)
I mean, I'm here a
Re: (Score:2)
In many cases, self-signed certificates will be more secure than that.
That's a good point.
Re: (Score:2)
A LetsEncrypt cert can only be issued to someone who controls the domain in question and so gets round the man-in-the-middle issue.
Re: (Score:2)
The biggest issue with self-signed certificates is that the client machine cannot verify if the certificate belongs to the domain owner.
That's why you should use a self-signed CA and use that to sign your working certs, rather than using self-signed working certs directly.
Re: (Score:2)
Re: (Score:2)
In many cases, self-signed certificates will be more secure than that.
Yes, this.
I have a (self-signed) CA that I sign all of the certs I used with, and share it with other people I personally know and trust.
I do not really trust certs signed by any other CA, because I don't know them and have no reason to trust them.
Follow the money (Score:5, Insightful)
"We're mad because Let's Encrypt makes it way too easy for the plebs to get a certificate without paying hundreds or thousands of dollars per year to a CA."
Re: Follow the money (Score:2)
If you know where to look, you can get them for about $4/yr.
dotdotdot (Score:2, Insightful)
and they're now issuing more than 100,000 HTTPS certificates every day. Should they be performing more vetting?
Why hold one CA to a completely different set of standards than every other CA?
The primary concern has been that while the growth of SSL/TLS encryption is a positive trend, it also offers criminals an easy way to facilitate website spoofing, server impersonation, man-in-the-middle attacks, and a way to sneak malware through company firewalls...
And how does any other CA prevent this after issuing certificates with the exact same level of proof of domain ownership?
Are you claiming that because it's free that criminals can now finally obtain certificates?
Criminal rings have profits and budgets orders of magnitude larger than most IT departments!
That logic is as ass backward as it possibly could be.
"I think there should be some type of vetting process. That would make it more difficult for malicious actors to get them," said Justin Jett, director of audit and compliance at Plixer, a network traffic analytics firm...
Then go get the CA/Browser Forum to amend their requirements that all CAs a
Because LE doesn't offer OV or EV certificates (Score:2)
Why hold one CA to a completely different set of standards than every other CA?
Because most other major CAs that offer domain-validated (DV) certificates also offer organization-validated (OV) or Extended Validation (EV) certificates for a higher price. Let's Encrypt does not.
Then go get the CA/Browser Forum to amend their requirements that all CAs and web browser makers follow.
Or write a browser extension to trust DV certificates less. Then you'll get a green bar on Twitter but a warning on Facebook. Comodo's Dragon browser, for example, has included something like this [netcraft.com], displaying a warning the first time the user visits a site using a DV certificate. The warning's text begins as foll
Re: (Score:2)
humans can't do anything useful with "almost everything might be dangerous".
Of course they can. They can opt into the walled garden of Nintendo, Sony, Microsoft, or Apple, for example, which in theory allow only vetted businesses to publish on their platforms.
Encryption bad? (Score:2)
All I want is to have encrypted connections. Why do I have to pay a shit-ton of money for connections to my server to be properly encrypted and not to be treated like a criminal by browsers? Let's Encrypt does this. Yes, they're not verified very well; neither are standard SSL certificate (I know; I bought some with pretty much zero verification).
Re: Encryption bad? (Score:3)
Re: (Score:2)
Isn't that what a self-signed certificate is for?
Re: Encryption bad? (Score:2)
Where is this "shit tonne of money" being spent?
Domain Validated Certificates can be purchased for about $4/yr, less if you buy multiple years.
Yes, but that's just a symptom of the problem. (Score:3)
One big reason for the volume of certificate issuance is that LetsEncrypt forces you to update your certificates at least once every 90 days. This means that the number of certificates issued is guaranteed to be at least 4x the number that would be issued by a traditional CA, and realistically, more like 12x or even 20x.
So yes, they should be criticized, but they should be criticized for the ridiculously short certificate expiration times that result in them issuing so many certificates each day, not for the number of certificates per se. That silly policy decision inherently limits the amount of verification that they can do, so even if they wanted to do more, they can't.
Re:Yes, but that's just a symptom of the problem. (Score:5, Informative)
Re: (Score:2)
That's not entirely true. Other CAs require the owner of the domain to confirm the validity of the request via email. The 90-day renewal period makes that approach more difficult, because nobody would be willing to go through that headache every 90 days. Instead, Let's Encrypt just checks to see if you've managed to convince the registrar or the DNS server to point the domain name at your server. So while they might not choose to do more validation even if there were longer validation periods, they woul
Re: (Score:2)
Wait... you actually use an email address at the domain as the contact email for the domain? Yikes.
Or do you mean that you can change the email on the domain? Because that may or may not be true, depending on whether you crack the account of the admin contact, the tech contact, or the billing contact.
Re: (Score:2)
Wait... you actually use an email address at the domain as the contact email for the domain? Yikes.
Or do you mean that you can change the email on the domain? Because that may or may not be true, depending on whether you crack the account of the admin contact, the tech contact, or the billing contact.
Some CAs will only do email verification to a subset of defined email addresses at the domain in question - e.g. hostmaster@example.com, postmaster@example.com etc.
Re: (Score:2)
Who said anything about spoofing? Suppose an attacker manages to crack into one of the servers that provides a domain's DNS. That same server won't provide DNS for the domain that hosts the tech contact's email.
No, from a security perspective, checking only that you control the web server is much, much weaker than checking to see if you're the tech contact for the domain, and IMO, they should never have been allowed to cut that corner. The only reason they had to do that was that they made the decision
Re: (Score:3)
That silly policy decision inherently limits the amount of verification that they can do, so even if they wanted to do more, they can't.
How? They are domain-verified certs that are issued by an automated process. How does changing their expiration date change anything?
Re: (Score:2)
So yes, they should be criticized, but they should be criticized for the ridiculously short certificate expiration times that result in them issuing so many certificates each day, not for the number of certificates per se. That silly policy decision inherently limits the amount of verification that they can do, so even if they wanted to do more, they can't.
Or possibly they know something that you don't.
The certificate revocation system is broken, doesn't work. CRLs didn't work for anything but the big sites and have been depreciated. OCSP doesn't work against man in the middle attacks, which is the primary attack vector.
What does work is the expiration date, once a certificate has expired it is safe. So you can improve things significantly by having a short certificate life span, shorter the better. To make this manageable you need to automate the acquisition
Re: (Score:2)
So yes, they should be criticized, but they should be criticized for the ridiculously short certificate expiration times
Why? The only reason to have long certificate expiration times is to reduce manual labour. When the system is scripted, renewal fully automated and doesn't cost anything, why would you critisize shot expiration times?
Re: (Score:2)
The point of the fast expiration is so browsers don't have to carry around ever-growing rejection lists for long-lived certs. If a cert is bad or the encryption model is bad or whatever, it'll expire before it becomes an issue.
You can't have it both ways. (Score:2)
Either you encourage encryption everywhere and make it easy to get a cert, or you stop nagging people every time they go to a plain http site and say http is just fine.
Pick one.
HTTPS is meant to ensure that your communications are secure. They can help protect you from hitting a site that isn't what it claims to be.
But issuing certs is not some magical means of "vetting" ANYTHING. The very idea is absurd. Anybody should be able to buy and get signed a cert for a site they own. It isn't anybody's job to ask
DV requires intercepting more connections (Score:2)
If there is no "vetting" then why have CA's? Just self-sign and call it a day.
Self-signing allows any ISP to intercept your connection and act as a man in the middle without your knowledge. A domain-validated certificate requires an attacker to intercept not only your connection to the web server but also the CA's connection to the domain's DNS server days or weeks earlier when the certificate was issued.
MITM instead of breaking encryption (Score:2)
Self-signed certs force encryption, so I'm not sure how an ISP would able to crack that encryption [...] The problem with self-signed certs is there is no mechanism that requires the cert owner to actually control the domain the cert, no way to ensure the server you are connecting to actually is who it ways it is.
You answered your own question. Instead of letting a subscriber connect to a server with a self-signed certificate, the ISP would intercept the connection, act as a server to the subscriber, and act as a client to the real server. Browser publishers warn for self-signed certificates but don't warn for DV certificates because they have agreed that https in the scheme means some level of verification that the domain and server share control.
Re: You can't have it both ways. (Score:2)
Re: (Score:2)
Vetting, as this article describes it, is verifying that the site asking for the cert is not intending to use it for nefarious purposes. Its lying about how CAs work in order to direct people to the pay services and away from LetsEncrypt.
Follow the money: he's using FUD tactics to direct people to pay services by saying that you can't trust the sites that use the free service, in order to try to get the vendors to stop accepting those certs.
But that's different from anybody throwing out a cert on a site cl
BS (Score:5, Insightful)
Calling BS on this. There is nothing inherently wrong with issuing certs. Regardless of who issues those certs, they can only be used to create a secure identified connections between a user and a server.
They definitely do not facilitate criminality any more than Apache2 does. This is just pure silliness. There's nothing wrong here. Bad guys can get certs from other sources just as easily as anyone else. They can get them from Let's Encrypt, too. So can everyone else. A certificate doesn't facilitate illegal activity. It's just for a secure connection.
Something tell me there's more to this than simply crying wolf about bad guys getting certs easily. Someone obviously would prefer that web hosts, big and small, don't get cheap (or free) certs to secure their connections from prying eyes.
While the justification might be 'bad guys are abusing this,' I'm still calling BS. Someone (or some *cough* three letter agency) is annoyed that people can easily secure their servers.
I'd go as far as to say, Let's Encrypt is having precisely the effect it sought to have. More secure connections on all HTTP traffic across the web. Anyone can TLS up their servers now with very little effort. Good job, Let's Encrypt, you're having a profound and ultimately awesome effect on the web's privacy and shielding from prying eyes. And that effect is a good one, especially when people are crying 'omg it's too easy to get certs now!' Good. Nothing like a very secure connection to give the middle finger to three letter agencies.
Re:BS (Score:5, Insightful)
Not only is it BS, it's the exact opposite.
Having in the past gotten a DV certificate through a normal vendor and now getting them through LetsEncrypt, it is quite clear that the process for LetsEncrypt is far more robust (actual proof I have access to the server by modifying it's contents as part of the handshake) than what most other CA's offer which for DV is based on little more than faith, and for EV based on talking to someone in an Indian call centre who can't understand you anyway.
Re: (Score:2)
Re: (Score:2)
Therein lies the problem. Far too long we've conditioned users to look for the lock. And now practically every site has a lock.
And therein lies a BIG problem if you use LetsEncrypt. Because a good chunk of LE certificates go towards phishing sites (no
Re: (Score:3)
That they can break TLS. This just makes it computationally harder for them, not impossible.
First of all, TLS has many and growing number of encryption methods and key exchange mechanisms. I have no doubt SOME of those methods are broken or easily broken into. Others are not so easy, and ridiculously computationally expensive to unwind. And there are always better ones being added as they are invented.
Additionally, the more encryption that is out there operating in the field, the more computationally expensive it's going to get to a) find data you're actually interested in, and b) decrypting th
Re: (Score:2)
Re: (Score:2)
Stop trying to fool the plebs that this is anything but a speed bump. Or perhaps you don't realize this yourself.
Not so sure that is true. Look at the examples of breeches in security we read about from time to time, including breeches in darknet security, and other illicit sites.
All of these breeches were achieved by social engineering, or someone making an oops, and LE swoops in. In some cases, we're seeing LE operate the illicit sites themselves to harvest data.
This is the important clue. They seem to need to get on the inside somehow, to get any data. This tells me, they're either incapable of breaching securi
Re: (Score:2)
Take your tinfoil hat off, RSA and ECC with 1024-bit keys and beyond is more than safe enough for the foreseeable future. Use 2048 or 4096 bit if you're paranoid. We have no quantum computers that can break these codes just yet, we actually have no idea whether it's even possible to make them.
Re: (Score:2)
In theory it's possible to break everything, given enough time. A single TLS session may take a few decades to break, how many of those do you want to break per day? It's unfeasible to break TLS except by very targeted MITM attacks (downgrading etc) by badly configured browsers and web servers.
False association. (Score:2)
The problem here has nothing to do with encryption and everything to do with the fact that companies have pushed the idea that if a connection is encrypted that the site is legitimate. The only thing that encryption does is ensure you connection cannot be spied on. The idea that encryption should be reserved for certain people is patently absurd.
Stop telling people that encryption equates to legitimacy and the problem is resolved.
Re: (Score:2)
Yeah, most phishing attack aren't even through MITM attack or eavesdropping, but social engineering. Companies should make sure their website name is stable and consistent, not branching into so many domains. If each company use the same domain for every web pages they have, then phishing attack would have been a lot more difficult already, as users can immediate recognize a cheap fake site, while those do MITM can be arrested as they leave more criminal evidence.
But no, first multi-national companies use
Have two cert grades (Score:4, Insightful)
Lets Encrypt verifies ownership of the domain. If you see the secured indicator in the browser, its a gaurantee that your actually talking to the server of the people who own that domain. So, if people watch out for the right domain as well as the secured indicator, it provides additional safety. So, people need to know the domains of critical sites they might use, and look carefully at that domain name. This is true as well, if there were no TLS being used. TLS provides additional gaurantees you really are talking to that domain and that no one is listening. Lets Encrypt makes things much more secure, rather than less security than before. However, certs with stronger vetting would verify ownership more of the domain a well as the certificate, maybe making sure that the domain is not hosting a malicious site that is spoofing a real bank or something.
There is a solution to this: have two grades of certificates, one with one star free certicates based on the Lets Encrypt model, for low risk sites and two stars for high risk.
Lets Encrypt, would not be an issue at all, furthermore, providing we do this: It might be a good idea, to have multiple security levels in the indicator, maybe one star for a Lets Encrypt type cert, maybe two stars for more intensive verification methods. this would allow the easy availability of Lets Encrypt to continue, but for banks etc to apply for the second star certificate for higher level of verification.
For many sites, like the personal website, Lets Encrypt is fine, without it those sites wouldnt encrypt anyway since its not worth the vast sums for a certificate from one of the commercial providers. For a bank, getting a cert with stronger vetting might make sense, and there is a better trade off for them to do it.
You could then train users to look for one star for low risk sites, two stars for ecommerce and banking stuff.
Re:Have two cert grades (Score:5, Interesting)
There is a solution to this: have two grades of certificates
You're right. There is a solution to this. It was developed 12 years ago in the form of EV certificates and has been in use for a long while along with a far better indicator than the one you proposed:
If you go to https://www.slashdot.org/ [slashdot.org] you will see a little green lock and the word "Secure"
If you go to https://www.bankofamerica.com/ [bankofamerica.com] you will see a little green lock and the words "Bank of America Corporation [US]"
No need for any fancy domain name URL checking.
Checks and Balances (Score:2)
To start with the second word, there should not be any "balances" in place when issuing DV certificates. It's not up to the CA to "balance" anything. A DV certificate achieves one purpose only beside facilitating encryption: certify that the server you are talking to is actually the one addressed in the URL. Nothing more. A DV certificate has nothing to do with the person or the company owning that server. It has nothing to do with the person who registered the domain. It is purely there to say the computer
My first response is "Fuck them" (Score:2)
Okay Google (and their lickspittles at Mozilla) decide to wall off stock http sites behind "danger" messages.
So anyone providing more than a cursory "I love me" page website has to run out and get a cert.
Let's Encrypt steps up and makes the process easy and mostly seamless.
Now people are bitching because they didn't draw out the process and make it more painful.
And they're worried about how a security mechanism can be used to make people LESS secure.
Maybe someone should have thought their way through this B
Green bar and Cert types (Score:3, Informative)
There is a list of requirements for CAs to obey for granting certs and they are stringently audited and then the auditors are audited. (and one auditor has failed). The EV audits are extremely thorough. Further any EV certificates that are issued now have to be added to a certificate transparency log https://en.wikipedia.org/wiki/... [wikipedia.org], so all EV certs that have been issued are publicly viewable and now auditable by everyone. (the log is a merkle tree so inclusion in the tree is easy to find and undetected changes are impossible).
Conclusion: If you are going to a website that you expect to be secure for banking or from a reputable company and the lock isn't green then you are likely visiting a spoofed or compromised page. If you are visiting Joe from down the streets cat pic site a DV cert is good enough.
Re: (Score:2)
The green lock only appears for sites with Extended Validation.
No it doesn't.
Domain Validation only requires that you control the domain to get the cert. It doesn't give you a green lock.
Yes it does.
Organization Validation has some checks and requires proof of control of the domain. It doesn't give you a green lock.
Yes it does.
Your advice is only true for users of Microsoft browsers and covers 20% of the market share. The green lock is provided to any encrypted connection with a valid certificate chain in Firefox, Chrome, and Safari. The entire concept of telling people to look at a colour or a symbol was completely stupid in the first place as colour doesn't convey information of "who" but only "what". If someone incorrectly gets an EV certificate due to an oversight at a CA (happens often e
Certificate public database? (Score:2)
Re: (Score:2)
So what's the big deal? (Score:3)
Re: (Score:2)
In the past it would be easy to understand that strange new connection from deep within an OS or network due to a lack of encryption.
It looks the same on every computer or network.
With lots of new encryption products that malware gets more places to hide as something the user could be encrypting.
Re: (Score:2)
- So you're saying that the green bar no longer means website is ok?
- Yes. Now it has to be a green padlock and a name of the organization, and you have to check it with magnifying glass because it's very easy to mistake l with I. see Mom, there's difference between AlliorBank and AIIiorBank. Do you see it? Do you?
I think a lot of these phishing problems are caused by people blinding following email links from "their bank" and not learning how to directly browse to a website (instead trusting Google to give them the valid link by searching for their bank's name). There's a pretty easy solution to this: Make a bookmark of the correct site and only use this bookmark to access the bank's site. Will that stop a DNS-based attack? No. But it will be effective against what a large percentage of what causes people to enter t
Re: (Score:2)
- So you're saying that the green bar no longer means website is ok?
- Yes. Now it has to be a green padlock and a name of the organization, and you have to check it with magnifying glass because it's very easy to mistake l with I. see Mom, there's difference between AlliorBank and AIIiorBank. Do you see it? Do you?
I think a lot of these phishing problems are caused by people blinding following email links from "their bank" and not learning how to directly browse to a website (instead trusting Google to give them the valid link by searching for their bank's name). There's a pretty easy solution to this: Make a bookmark of the correct site and only use this bookmark to access the bank's site. Will that stop a DNS-based attack? No. But it will be effective against what a large percentage of what causes people to enter their credentials on the wrong site.
Exactly. I taught my Dad to actually go to the bank web site and never trust links in email, etc. Then you can look for the green lock symbol.
Re: Green Bar is the probem. (Score:5, Insightful)
Re: Green Bar is the probem. (Score:5, Informative)
Comment removed (Score:5, Informative)
Re: (Score:2)
Re: Green Bar is the probem. (Score:4, Insightful)
>Words have meaning
Yes, and you're getting the meaning wrong.
>Secured was never ment to mean 'Encryypted', it was ment 'encrypted and you're talking to who you think you are'
That's still encrypted.
Re: (Score:3)
No. Secured was never ment to mean 'Encryypted', it was ment 'encrypted and you're talking to who you think you are'
And it does 100%. The word "Secure" and the little lock show up when a server proves via the certificate chain that they are who they are addressed in the address bar. Nothing more.
Your problem is you expect the computer to not follow your instruction, but rather interface with your brain. How is the computer supposed to know that when you address www.bankof4merica.com that you didn't actually want to talk to the scammer but actually wanted to talk to www.bankofamerica.com. If you told your mother the littl
Re: Green Bar is the probem. (Score:5, Informative)
NBow I have to explain to her that 'S does not stand for Secure
Of course it stands for "secure". You can rest assured in the comfort that when you type your Paypal password in at https://www.payypall.com/ [payypall.com] I or anyone else other than the operators of the scam site are unable to see your password.
Validation of companies was not part of getting an SSL certificate, not until 2005 anyway when the EV certificate was introduced. And it wasn't long after that browsers started displaying EV details differently which is why when I go to https://www.payypall.com/ [payypall.com] I see a green lock, but when I go to https://www.paypal.com/ [paypal.com] I see "Paypal Inc, [US]" written in the address bar.
Re:Green Bar is the probem. (Score:5, Informative)
I've spent better part of a day to explain to My Mom how to distinguish a safe website from unsafe one. You look at the Green Bar / Lock. Is it green? you are good to give them your name and CC details.
Now I'm going to her and have to explain, that no, things have changed
No, nothing has changed about what that green bar means: encrypted connection. You pushed a false idea on to your mother, an idea that companies planted and you blindly accepted.
Re: (Score:2)
At least in firefox blue used to mean a DV certificate while green meant an EV certificate. At some point they started using green for everything.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
and I'd maybe even agree with you if not for the fact that that it says 'Secured' Right there when I click that green lock. Not 'Encrypted', 'Secured'.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
CAs aren't the domain police (Score:2)
it was assumed that CA has an Authority to verify that this website is who it claims it is.
And when the only claim in question is "this site is operated by the same entity that owns the domain", a CA offering domain-validated certificates has an Authority to verify this claim. Let's Encrypt does this through either a cleartext HTTP connection to the server or DNS TXT records. Verifying whether the domain owner ought to continue to own that domain, or that the domain is not misleadingly similar to the name of a large business, is outside the scope of a domain-validated certificate.
Re: Green Bar is the probem. (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
It would be more correct to state that name lookups for DNS queries must match with case insensitivity. "example.com" is identical to "Example.com", or "ExAmPlE.CoM".
Re: Green Bar is the probem. (Score:2)
Re: (Score:2)
Ugh. Dude. Because S in HTTPS always stood for Encryption right?
The s stands for secure. Your connection to Paypal.com is just as secure as it is to any old scammer who is also encrypting via SSL. No one other than you and your favourite scammer will see your password. You're completely secure.
The fact that the CAs dropepd the ball, does not make the fact that Browsers pushed hard to make it so you can trust a green bar.
Browsers have differentiated levels of security in their green bar for a long time now. You may notice that the green bar looks very different when going to e.g. slashdot.org vs bankofamerica.com.
The little lock (which is what you mean by the green bar because you're not paying at
Re:Green Bar is the probem. (Score:4, Informative)
> Now I'm going to her and have to explain, that no, things have changed, if you see a green padlock, it no longer means someone at least had to fax some registration papers and pay few bucks so he's traceable.
Things have been changed for a LONG while then. I've been able to get SSL certs with a credit card and no verification outside of an email address from a major vendor since 2009. A wildcard at that.
Re: (Score:2)
Now I'm going to her and have to explain, that no, things have changed
Things changed 10 YEARS AGO with the introduction of EV certificates and changes in modern browsers like IE7, Firefox 12 and Chrome 1 in how certificates are handled. You are just a bit slow to catch up.