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

Registrars treat DNSSEC as an upsell ($)

[tepples]

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

But without a fully qualified domain name, CAs shall not issue a trusted certificate. So we also need a reliable way to provide trustable names for devices on a non-technical users' home network that have a web-based administration interface, such as a modem, router, printer, or NAS.

What would be ideal is to support secure DNS with certificates in the DNS.

I agree that DANE would be ideal. But DANE relies on DNSSEC, which has faced practical problems that hinder adoption. Before about a year and a half ago, DNSSEC's root zone key was too short (1024 bit RSA) for browsers to accept as part of a certificate chain. And many domain name registrars bundle zone hosting with a domain, but a lot of these (such as GoDaddy) have charged more for zone hosting with DNSSEC than for zone hosting without DNSSEC.

Re: Registrars treat DNSSEC as an upsell ($)

[Monster_user]

Why do home devices need to have trusted SSL certs? They are not web facing, and if they have remote capabilities they are typically routed through a service provided by the manufacturer. There is no reason to go through the trouble of key generation and registration against a global root CA.

Besides, how is a global root CA supposed to verify the connection to a device on a non-routable IP/Subnet?

Re:Scam

[Anonymous Coward]

You know you can get a ssl cert for free and have it configured in like 30 seconds with certbot, right?

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.

Re:Let's Encrypt supports Certificate Transparency

[tepples]

Does Let's Encrypt verify identity, I can't find anything on their site about it.

Let's Encrypt is a domain-validating certificate authority, which issues domain-validated certificates. Every such CA verifies that the person requesting a certificate is the same person who controls the domain's DNS. What other sort of "identity" did you have in mind?

If a CA is not verifying identity then what use is their certificate?

If a domain registrar is not verifying identity then what use is their domain?

Re:Er, what about LetsEncrypt

[swillden]

In answer to your subject, from https://letsencrypt.org/certif...:

We are dedicated to transparency in our operations and in the certificates we issue. We submit all certificates to Certificate Transparency logs as we issue them. You can view all issued Let’s Encrypt certificates via these links:...

So LetsEncrypt certs will work fine with Chrome.

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.

Multiple routes, expiry, and CT block that

[tepples]

CAA records are useless when I hijack the DNS in the first place.

I'm interested to see how you plan to hijack the DNS in a way that evades the following three defenses:

Breadth of hijacking At what point would you hijack the DNS? A domain-validating certificate authority queries DNS through several Internet routes. How had you planned to hijack them all, especially if the domain's authoritative DNS servers are on different /16s? Expiry Certificates issued by Let's Encrypt expire after 90 days, and organizations may renew them at 60, 73, 85, or whatever day intervals. How long do you plan to keep up the DNS hijacking? Certificate Transparency If a CA issues an certificate to a hijacker, the domain's rightful owner can check CT logs and find your certificate. The policy change described in the featured article encourages CAs to keep their CT logs complete.

Re:Er, what about LetsEncrypt

[JesseMcDonald]

This logging system, it does not appear to provide any new services of meaningful value aside from making moderate-knowledgeable people more able to understand a cert and query it's nature.

The point of the Certificate Transparency logging system is to make it extremely difficult for any CAs to get away with quietly issuing extra certificates for your domains to state actors and others to enable them to carry out MitM attacks. Since any CA can issue certificates for any domain, this is a real threat which undermines confidence in the entire CA system; it's only as strong as its weakest link. With browsers enforcing CT logging this attack is no longer possible; the certificates will not be accepted unless they are first made public, and any CA that issued such certificates openly would immediately lose its trusted status and be finished as a CA.

Re:Another Google metadata sink?

[Curunir_wolf]

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.

This, from TFA (I know, right?): "Google engineers have also added a Chrome policy flag that allows sysadmins to disable the CT log-checking behavior in instances Chrome is deployed inside an intranet."

Re:Er, what about LetsEncrypt

[JesseMcDonald]

how hard would it be for them to work a command line flag like -gov to not log the certificate they are forging?

Not hard at all, but it doesn't matter since browsers won't accept the certificate if it isn't in the log. That's the point of making CT logging mandatory.