Starting Today, Google Chrome Will Show Warnings for Non-Logged SSL Certificates (bleepingcomputer.com)

Starting today, Google Chrome will show a full-page warning whenever users are accessing an HTTPS website that's using an SSL certificate that has not been logged in a public Certificate Transparency (CT) log. From a report: By doing so, Chrome becomes the first browser to implement support for the Certificate Transparency Log Policy. Other browser makers have also agreed to support this mechanism in the future, albeit they have not provided more details. This new policy was first proposed by Google engineers in 2016, and was scheduled to enter into effect in October 2017, but was later delayed for 2018.

Comments

Another Google metadata sink?

[Anonymous Coward]

So how is this going to be implemented? Every SSL cert is going to be sent to Google for "verification" or is the CT log going to be local and the browser will just search it every time?

Re:Another Google metadata sink?

[squiggleslash]

Also what about locally signed certificates, using a corporate or Intranet CA, that's installed on all computers that might use those certs?

That was, at one point, considered a best practice, but I assume this'll break that.

Re:Another Google metadata sink?

[houstonbofh]

I am ready to break all cert warnings entirely. As a networking professional logging into self signed certs all day, the cure is FAR worse then the disease!

Re:Another Google metadata sink?

[Bert64]

You shouldn't be doing that, your networking devices should have proper certs or your client system should be configured to trust a corporate CA and the network devices then have certs from that. Chances are your job requires you to have elevated privileges on all manner of important networking devices, if someone was able to MITM you they could steal some powerful credentials.

The only times you should be logging into a device that uses a self signed cert are:

1, initial configuration
2, testing

In the same vein however, it seems browsers are disabling support for weaker algorithms by default, and preventing you from turning them back on. This represents a significant problem, as there are all kinds of old devices which we still need to access for various reasons.

Re:Another Google metadata sink?

[caseih]

Are you joking? Self-signed certificates are secure, arguably more secure than commercial CA-signed certificates because I had to register each and every one with the browser. I created the certs myself. A MITM attack is *instantly* detectable to browsers (and to me), unlike a MITM attack using bonafide signed certificates from a breached certificate authority. Browsers make using self-signed certificates somewhat awkward, which is unfortunate. Firefox tells me, incorrectly, that my self-signed certificate is not secure. That is complete nonsense of course.

Another secure method is to sign with your own certificate authority. Then you just have to convince the browser once to take your CA cert. Like the self-signed certificates, MITM attacks are instantly detectable. This method is preferable to self-signed certs when you have deal with more than a few.

In my mind for internal servers and devices, my own certificate authority is far more secure than using something like Let's Encrypt.

Re:Another Google metadata sink?

[Junta]

The CA model is particularly bad for 'internal' devices.

So one, for internal communications inside a home network, the warning is so scary that some devices decline to support https just to avoid the support call because a web browser called the device 'insecure'. Note that https with bad cert is considered 'terribly insecure to the point of blocking the site' and http without any cert whatsoever is 'ok'. Home networks are not going to go through the rigmarole of all this.

For another, my internal IT department is given the ability to sign a certificate for *any* site I visit to provide support for internal devices. I am not empowered as a user to elect to impose my own nameConstraints as I import the certificate, so to secure access to router.internal.mycompany.com, I give them access to impersonate my.bank.com

Even when the IT department has ability to sign certificates, either it's going to be uselessly lax (automatic granting of certs for whatever reason) or impractically difficult (every sign requires tedious interactions). Companies are terrible about implementing the right balance internally.

Assuming you overcame all this, you *still* will get a warning, because that internal IT department isn't going to have it registered in a CT log. If they *do*, then others can audit that log to discern details about their network and they have *another* class of security problem to tackle. Or chrome is deployed with a policy to disable this feature for the sake of the internal devices, *again* coming back to fixing internal network behavior requiring reducing security for the wider internet.

The problem is that roughly all discussions on this front focus on the typical 'internet' usage and fail to conceive of approaches that would make sense for internal networks.

Re:Er, what about LetsEncrypt

[crow]

No, we need warnings for certificates that aren't trusted. Otherwise SSL does nothing to prevent man-in-the-middle attacks.

What would be ideal is to support secure DNS with certificates in the DNS. Then you know you have the right certificate and don't need any certificate authorities at all. Of course, you have to trust the secure DNS. so it's just pushing the trust problem down the road.

Let's Encrypt supports Certificate Transparency

[tepples]

All websites with a fully qualified domain name qualify for a domain-validated certificate without charge from Let's Encrypt. Every certificate that Let's Encrypt issues is logged in CT.

Secure Contexts

[tepples]

Why do home devices need to have trusted SSL certs?

Because Service Workers and several other web platform APIs are restricted to secure contexts per W3C's spec. For example, a browser may restrict the Fullscreen API or Presentation API to secure contexts as a mitigation against phishing by replicating the chrome of the operating system and web browser. In such a browser, the web interface of a NAS on which video is stored will not be able to present the video in the full screen.

Re:Er, what about LetsEncrypt

[Anonymous Coward]

Perhaps, on the other hand, without letsencrypt most of us would not have websites. The poor people of the world would be completely cut off from having their own website, that was not the dream of the internet.

We cannot be putting restrictions that cut off chunks of the population because they do not meet our criteria, the internet and having your own website should be free and open to all.

In the bad old days you could only get an SSL certificate if you were incorporated, provided your contact phone number, real name, address, and pay a hefty sum of money. This was completely unacceptable and went entirely against the whole point of the internet. With letsencrypt the playing field has been leveled and this is a good thing and it is keeping the internet operational in the hands of the people.

Honestly though I am still of the opinion that we should completely eradicate centralized certificate authorities. The certificates should be there to provide encryption which they do whether they come from an authority or not. We should allow free self signed certificates with no warnings. I should not have to link myself up to some 3rd party of any kind to operate my website.

Re:Er, what about LetsEncrypt

[Actually, I do RTFA]

No, we need warnings for certificates that aren't trusted. Otherwise SSL does nothing to prevent man-in-the-middle attacks.

Sometimes, not protecting against a MITM attack is fine and I don't need to worry about preventing it. Examples include "being on a LAN and accessing something that is required to be behind https by W3C standards" or "local development of secure services before they're uploaded to test".