Chrome and Firefox Changes Spark the End of 'Extended Validation' Certificates (bleepingcomputer.com) 56
"Upcoming changes in Google Chrome and Mozilla Firefox may finally spark the end for Extended Validation certificates as the browsers plan to do away with showing a company's name in the address bar," reports Bleeping Computer.
When connecting to a secure web site, an installed SSL/TLS certificate will encrypt the communication between the browser and web server. These certificates come in a few different flavors, with some claiming to offer a more thorough verification process or extra perks. One certificate, called EV Certificates, are known for having a browser display the owner of the certificate directly in the browser's address bar. This allegedly makes the site feel more trustworthy to a visitor.
In reality, the different types of SSL/TLS certificates all serve a single purpose and that is to encrypt the communication between a browser and web site. Anything extra is seen by many as just a marketing gimmick to charge customers for a more expensive "trustworthy" certificate. In numerous blog posts, security researcher Troy Hunt has stated that EV Certificates will soon be dead as more and more sites switch away from them, because they are much harder to manage due to extra verification times, and because people have become to associate a padlock with a secure site rather than a company name.
With Safari already removing EV Certificate company info from the address bar, most mobile browsers not showing it, and Chrome and Mozilla desktop browsers soon to remove it, Hunt's predictions are coming true. EV Certificates will soon be dead.
AmiMoJo shared this post from Google's Chromium blog: Through our own research as well as a survey of prior academic work, the Chrome Security UX team has determined that the EV UI does not protect users as intended. Users do not appear to make secure choices (such as not entering password or credit card information) when the UI is altered or removed, as would be necessary for EV UI to provide meaningful protection. Further, the EV badge takes up valuable screen real estate, can present actively confusing company names in prominent UI, and interferes with Chrome's product direction towards neutral, rather than positive, display for secure connections. Because of these problems and its limited utility, we believe it belongs better in Page Info.
In reality, the different types of SSL/TLS certificates all serve a single purpose and that is to encrypt the communication between a browser and web site. Anything extra is seen by many as just a marketing gimmick to charge customers for a more expensive "trustworthy" certificate. In numerous blog posts, security researcher Troy Hunt has stated that EV Certificates will soon be dead as more and more sites switch away from them, because they are much harder to manage due to extra verification times, and because people have become to associate a padlock with a secure site rather than a company name.
With Safari already removing EV Certificate company info from the address bar, most mobile browsers not showing it, and Chrome and Mozilla desktop browsers soon to remove it, Hunt's predictions are coming true. EV Certificates will soon be dead.
AmiMoJo shared this post from Google's Chromium blog: Through our own research as well as a survey of prior academic work, the Chrome Security UX team has determined that the EV UI does not protect users as intended. Users do not appear to make secure choices (such as not entering password or credit card information) when the UI is altered or removed, as would be necessary for EV UI to provide meaningful protection. Further, the EV badge takes up valuable screen real estate, can present actively confusing company names in prominent UI, and interferes with Chrome's product direction towards neutral, rather than positive, display for secure connections. Because of these problems and its limited utility, we believe it belongs better in Page Info.
Scam (Score:2, Insightful)
Not to mention that extended validation certificates were just a scam to charge more money for the same service.
It's all BS; we need a REAL solution! (Score:3, Interesting)
There is no good reason to have these automated simple SSL certs when we could just self-sign everything!
Identity verification is a SEPARATE problem and should be handled separately. Create a 3rd party signing system - use it for automated domain identification like we have now but ALSO allow multiple signing parties. That would be 1st level identity...
Multiple signed 3rd parties should be possible!
Governments should sign certs for registered corporations. Corps already pay a fee to be incorporated and get
Re: (Score:2)
I essentially agree with you, but I think we should come at the problem another way:
Treat self-signed HTTPS connections the same as plaintext HTTP connections. They are in no way less secure. There is no reason to throw up a big warning screen and make the user click a bunch of times to actually see the site. Show a warning tooltip on password fields, sure, same as HTTP connections.
Also, verifying websites' SSL keys seems like one of the few problems that could actually be sensibly solved with a blockchain.
Re: (Score:2)
They are much less secure because they could be MITM'd, a lot more easily than domain-validated certs.
Re: (Score:2)
Self-signed HTTPS is less secure than plaintext HTTP because it could be MITM'd?
True sense of insecurity (Score:4, Insightful)
When the user types http:, the user expects it to be MITMable. The scheme provides a true sense of insecurity.
When the user types https:, the user expects it not to be MITMable. The scheme provides a false sense of security.
Re: (Score:2)
The average user doesn't type in "https" or even check the protocol, which is why browsers have lock icons and green address bars etc.
Re: (Score:2)
Besides that, there is a simple way to prevent MITM attacks with self-signed certs - the site owner registers them with centralized cert repository (e.g. SSL observatory). Thereafter the visitor's browser would check the self-signed cert against the repository and issu
Re: (Score:3)
Besides that, there is a simple way to prevent MITM attacks with self-signed certs - the site owner registers them with centralized cert repository (e.g. SSL observatory). Thereafter the visitor's browser would check the self-signed cert against the repository
If this were the case, the SSL observatory would be acting as a CA. So what's the difference between that and Let's Encrypt?
Re: (Score:2)
Let's Encrypt is acting as a CA in its own right and therefore takes on an additional burden in terms of checking a site's owner's identity, reissuing certs and so on.
How to put cert on file with SSL Observatory? (Score:2)
Then I must have misunderstood what you meant by "the site owner registers them with centralized cert repository (e.g. SSL observatory)." Google Search for ssl observatory turned up this page at EFF [eff.org] which appears to lack a way for a site owner to make a submission, and ssl observatory registration failed to turn up any obvious official form for placing a cert "on file."
Besides, in order to distinguish a site owner putting a cert "on file" from an attacker doing the same, it would assume the same sort of "bu
Re: (Score:3)
Not the way they are currently used. And certainly not the way my self-signed certificates are used. They are actually more secure because any attempt to MITM attack by any entity would be immediately detected by my browser, since my browser knows my self-signed certificates.
Relying on domain-validated certificates allows governments and other CA authorities to issue their own certificates for any domain and the browser shows it as trusted. Seems to me the CA authority system we are now using is open to
Re: (Score:3)
Not the way they are currently used. And certainly not the way my self-signed certificates are used. They are actually more secure because any attempt to MITM attack by any entity would be immediately detected by my browser, since my browser knows my self-signed certificates.
Relying on domain-validated certificates allows governments and other CA authorities to issue their own certificates for any domain and the browser shows it as trusted. Seems to me the CA authority system we are now using is open to more abuse and MITM attacks than self-signed certificates are. Isn't this what EV certificates were supposed to help mitigate?
It depends on the use case. Sounds like in your use case where you control both the browser's trusted CA list and the private web server where you are placing your self signed certificate, you are correct in that you have a very secure solution. Since you control both ends, you can be your own CA (which is what a issuing a self signed certificate is) and you can trust your own CA (which is what happens when you tell your browser to accept a self signed certificate.) However in the more common case for using
Re: It's all BS; we need a REAL solution! (Score:1)
Prove private key owner owns domain name (Score:3)
There is no good reason to have these automated simple SSL certs when we could just self-sign everything!
The reason for domain-validated certificates is to prove that the owner of the certificate's private key is also the owner of the domain name on the public Internet. However, it doesn't prove that the domain name's owner is a legitimate business, nor is it designed to prove anything about hostnames that are not public.
Re: (Score:2)
Firefox, Google, Apple are all on a virtue high horse anti-government agenda.
All the browser makers tout encryption as protection they provide to the plebs from the (overreaching) government, and encryption is already a race to bottom with Let’s encrypt.
Let’s not forget that the leading market share browser (backdoor in reality because of java script) is created and by an advertising agency whose real product is the data they mine of the browser user’s web visits.
So what's a little identit
crypto books (Score:2)
You're an idiot.
calm down, no need to call names.
also parent poster is right in that encryption and authentication are two separate concepts. They are both required (together with a bunch of other things) in order to establish a secure channel, but they are separate concepts none the less.
They are even implemented by completely different algorithms.
- encryption is implemented with stream cipher algorithms such as aes128 or chacha20
- authentication is implemented with public key systems such as RSA, ECDSA, ED25519
(with vari
Re: (Score:2)
Blithely asserting that authentication is not part of the problem is stupid, and I will certainly not refrain from calling out people who do so.
Re: (Score:2)
The domain-validated certificate proves that the server speaks for the owner of the domain name. But what proves that the domain name belongs to the business that the end user expects?
Re: (Score:2)
Technologically? Nothing.
Re: (Score:2)
By separating the two separate security problems; will make it easier to address their specific needs with different sets of standards.
Transport encryption being 1 goal, I only suggest self-signing because that is the existing system that has been lowered in trust due to automated signing services with little in the way of identity verification. I'm advocating just giving up and self-signing for this aspect instead of relying upon 3rd parties that offer little. I'm not saying using Domain keys couldn't be
Re: (Score:2)
You cannot separate them. Part and parcel of encryption is that you know you have the correct key for your communications partner. Without that knowledge, Eve can substitute her key for Bob's, with Alice none the wiser. If you keep insisting that you can attack these two problems separately then I stay with my original assessment.
Identity verification only requires third-party participation if Alice and Bob don't know each other and have no other communications channel. Otherwise they can fall back to out-o
Re: (Score:2)
There is no good reason to have these automated simple SSL certs when we could just self-sign everything!
We have that already. It's called DANE [ietf.org]. However, adoption has been poor, partially because it (rightfully) relies on DNSSEC, which has also seen little adoption.
Re: (Score:1)
Re: (Score:3)
I have a proxy server that intercepts HTTPS content, and replicates the connection with its own self-signed signature. For a bit of time, the browser called it "secure", when it was merely encrypted. It incorrectly implied that the self-signed certificate was just as secure as anything else.
Even if EV is a scam, it's an improvement in that a certificate isn't intercepted by a third party and either examined or tampered.
Re: (Score:2)
Not always. Some now defunct CAs actually did a pretty good job ob verifying the identity. What Verisign does is just a bad joke and matches your comment exactly.
Shocked and surprised (Score:2)
What I'm really shocked here is that the major browser vendors didn't go in the opposite direction. By that, I mean an approach where plain, garden-variety SSL certs get incrementally devalued. Right now, a password field on a non-SSL page will have most browsers showing all kinds of scary popups about transmitting passwords in clear.
I fully expected, at some point, browsers also starting to show the same scary popups on pages that use standard SSL certs, and only be content by password fields on pages that
Re: (Score:2)
Re: (Score:2)
What we really want is to ditch the CA cartel whatsoever, and go to DNSSEC/DANE. But for some reason the projects to implement that in browsers got mysteriously axed. While DNSSEC+DANE is not perfect, it would make MitM by government-level actors a lot harder. And would be strictly stronger than the current LetsEncrypt model: with LE or legacy CAs.
Re: (Score:2)
Answered own question (Score:2)
What CA cartel? There are 100s of CAs approved by CA/Browser forum
You appear to have answered your own question. CA/Browser Forum is the CArtel. It has failed, for example, to provide an effective mechanism for limiting a CA certificate's scope to a single LAN or to a single domain name in a reserved TLD. How would you obtain a certificate for a router, printer, or NAS on a home LAN, for example?
Re: (Score:2)
You can get a Letsencrypt cert for anything you can put in DNS.
Re: (Score:2)
How would you obtain a certificate for a router, printer, or NAS on a home LAN, for example?
You can get a Letsencrypt cert for anything you can put in DNS.
You can't put a domain name under a reserved TLD in DNS. Or would it be desirable to require each householder to purchase a domain name and expose his or her home LAN's internal hostnames to the world through Certificate Transparency logs?
Re: (Score:2)
For your home , if you want certificates, host your own CA using free CA software and you will be able to make your own issuance rules. You know to trust yourself, have a finite deployment to deploy your trusted CA cert, and most importantly don't need the whole world to trust your setup.
Public CAs are for internet-facing infrastructure.
Browsers don't yet support name constraints on CAs (Score:2)
For your home , if you want certificates, host your own CA using free CA software and you will be able to make your own issuance rules. You know to trust yourself
Except your client devices will do their best to make it hard to trust yourself, as a measure against intruders social engineering their marks to trust them. Mobile operating systems don't let the user add a trusted root certificate unless the user first sets up a PIN lock, and applications have to opt in to trusting non-preinstalled CAs in the Network Security Config [googleblog.com]. This would be a lot easier if user agents supported name constraints per RFC 5280 [ietf.org], such as within a particular subnet (such as 192.168.177/8
Re: (Score:2)
such as within a particular subnet (such as 192.168.177/8)
Typos like this may be part of why browsers don't yet support special UI for private CAs with name constraints. Though /24 was meant, it was too easy to typo.
Re: (Score:2)
Set up your own CA? It's really not that hard.
Then again, if you're inside your own network, nothing wrong with self-signed certs, as you can easily do out of band verification.
This is a non-problem.
Re: (Score:2)
Set up your own CA? It's really not that hard.
Even if it's not that hard to set up a CA on a desktop computer or a Raspberry Pi device, it may be hard to get a Chromebook, smartphone, or set-top streaming device to trust your CA or your self-signed certificate.
Re: (Score:2)
If your webhost didn't do that, they would get complaints from customers about the "NOT SECURE" warnings on the browser when they visit the site.
Reducing security with no justification (Score:4)
Re: (Score:2)
"Removing my ability to do this will make my browsing less secure when using these browsers"
-1, anti-informative
The article makes no claim that the ability to check the certificate chain is being removed.
Re: (Score:2)
This just in, password to be abolished because users keep setting them to "12345" and therefore not providing security users need.
TFA Doesn't Know WTF It's Talking About (Score:5, Informative)
Re: (Score:2)
It's a lot harder than that, at least in theory. The CAs check business records and registries and do telephone confirmations with the entities recorded in business registrations.
Re:TFA Doesn't Know WTF It's Talking About (Score:5, Interesting)
Anything extra is seen by many as just a marketing gimmick to charge customers for a more expensive "trustworthy" certificate." NO!!! If if the "single purpose" was encryption, browsers wouldn't throw a hissifit when a site uses a self-signed cert. CA-signed certificates are just as much about Identity
Yeah, I noticed this too. Though, I would go further and say certs are all about identity. There's lots of ways to encrypt. You don't need a cert by any stretch to do that part of the security. Certs are about the site you're connecting to being the site you expected to connect to. They frankly have very little to do with actual encryption, other than being the 'key' for the encryption, which loops right back to identity, the cert holder is the only entity that should have the private key after all.
Re: (Score:2)
You and the article are both conflating the technical purpose and the "human factor" purpose.
At a technical level a CA signed cert and a CA signed EV cert perform the exact same function.
As can your own personal-ca signed certs (presuming you create your cert with current hash methods and bit-sized keys)
On a human level is the only way they are treated different, and differently by different humans.
As you stated already, a personal-ca can easily be just as secure, and likely more so than a public CA, on a t
Re: (Score:2)
EV does not bring extra security.
By design, SSL/TLS can do only one thing: assert that a third party has certified that the server you are connecting to holds the private key corresponding to the public key with the server's name embedded in it. The quickest way to verify that is Domain Validation, where the CA sends an email to an address in the domain of the certificate CN, on the assumption that whoever controls the DNS also is the legitimate controller of the domain.
EV is a pseudo-secure solution assert
Hello, we are Bank of ARNERICA (Score:5, Interesting)
Conventional wisdom to prevent phishing used to be that financial sites had a TLS certificate, whereas hobbyist sites would have cleartext. With dirt-cheap resellers driving down the price of a domain-validated, and later StartCom and Let's Encrypt driving it to zero, the price of mounting an attack on a bank's domain using a near-homoglyph or typosquat attack (such as paypaI.com or bankofarnerica.com) fell in parallel.
For a while, Comodo tried to work around this by making the DV case appear more conspicuously dangerous. Its Dragon and IceDragon browsers, based on Chromium and Firefox respectively, treated domain-validated as less trustworthy, showing the same "lock with caution triangle" icon as for mixed passive content, whereas Extended Validation or otherwise organization-validated certificates got the ordinary lock. Some versions of these browsers would show an interstitial warning page when the user visits a website with a domain-validated certificate for the first time:
This was styled similarly to the warning for an invalid certificate, with an amber border instead of a red one. But as Facebook and other widely used commercial but non-financial sites also switched to DV certificates from Let's Encrypt, interstitials warnings for DV certificates became noise leading to warning fatigue. Thus Comodo's model never caught on upstream or with other browser publishers.
So with official versions of Chrome and Firefox no longer distinguishing EV certificates, what defense is there against phishing using a near-homoglyph or typosquat domain? Sending every domain that every user visits to Google LLC for a Safe Browsing check?
Re: (Score:3)
Re: (Score:2)
So with official versions of Chrome and Firefox no longer distinguishing EV certificates
They still distinguish them. They've changed the colour scheme of DV certificates. DV certificates no longer show a green lock. However your Bank of America example is precisely why removing the full company name from the address bar for an EV certificate is a dumb fucking idea.
Modern browsers suck for sysadmin support (Score:5, Interesting)
I'm so tired of logging into network/server hardware all day and both firefox and chrome bitch about certs and give me no way to "permanently accept" certificates.
Make them secure, but stop stripping out my choices to remember settings. Make a special setting, but stop removing features!
Re: (Score:2)
The solution is to not use self-signed certs. Either use a recognized CA or set up your own CA and add that to your trusted certs.
Of course, they make the whole process unreasonably expensive and stupidly complicated. I can't really blame people for not wanting to do it "the right way".
Re: (Score:2)
Chrome uses your operating system's certificate store, so install it as a trusted certificate there.