Slashdot Mirror
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.
You'll need an SPF record ... oh, and DKIM ... oh yeah, and DMARC ...
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?
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.
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.
If they did care about the end user's security, they wouldn't make stupid changes like not trusting end-user / admin installed CA certs by default.
Chrome opts in through its network security config file, and Firefox has its own TLS engine. So this affects mostly native apps that use Android's TLS engine.
Since when does removing / forbidding the user's input on trust somehow boost their security?!?!?
Malware has in the past added certificates as a means of intercepting apps' traffic. So have governments.
You know you can get a ssl cert for free and have it configured in like 30 seconds with certbot, right?
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.
A lot of people, including myself use LetsEncrypt on a CPanel based hosting account to generate certs for a website.
Are those local, self-signed certificates or something that is registered somewhere?
You could answer that question with five seconds on a search engine. Google Search for let's encrypt certificate transparency produces, as its first result, a document stating the following: "We submit all certificates to Certificate Transparency logs as we issue them."
In answer to your subject, from https://letsencrypt.org/certif...:
So LetsEncrypt certs will work fine with Chrome.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
IMO all certificates should be EV in the current internet if we want security.
I thought EV certificates were available only to corporations or LLCs, not to individuals. If someone puts up a site to show her personal portfolio, would you prefer to require her to incorporate first?
But the current situation - Let's decrypt being able to issue a DV for any EV issued domain, is completely wrong.
That's what certificate authority authorization (CAA) records are for. If a domain owner publishes a CAA record that doesn't include Let's Encrypt, Let's Encrypt will not issue a certificate for that domain.
Ctrl-F "letsencrypt" Worries eased.
Certificate authorities are entities that grant certificates. If certs were passed with DNS, a CA would still be needed, even if it's just the DNS server itself.
Of course then the CA could not be airgapped, and the system as a whole would be more interesting to attackers and have a much larger attack surface.
Right now there are warnings for certificates that are not trusted. If they do not have a path to a root of trust there is a warning. If they have been revoked there is a warning. If they are self-signed there is a warning.
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. Sounds good but who decides what constitutes a threat? The cert logging policy website indicates CA certificates are strange. They are not. They are mandatory for trust. Apparently the people who made this logging feature get to decide what is and is not a concern to the rest of us, without accepting the fundamental nature of PKI as being strange.
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.
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.
Just to get a ballpark figure to guide further discussion of your opinion on Let's Encrypt: How much do you think someone ought to have to pay per year in order to host a personal portfolio site?
Let's Encrypt certificates are issued under an intermediate that has always been cross-signed by IdenTrust, an older and more established CA.
Like a standard cert from someone else requires anything beyond rudimentary photochop skills?
Pinning would do a LOT more for security than the CAs ever have, but since that doesn't present any exciting new business opportunities, it remains unimplemented.
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 differentA DNS entry like with e-mail would work.
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.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
I think it's more a reaction to browsers popping up security warnings on all non-HTTPS sites.
On the one hand, getting public websites to use HTTPS is almost inarguably a good thing. On the other hand, getting intranets to use HTTPS is nearly useless, and getting mDNS devices to use HTTPS is impossible. That last one is going to be a real problem, and I'm really not sure how the industry is going to solve it. The only way I can think of would be to:
Either way, I'm pretty sure it can't be done practically without making some sort of changes to the standards themselves. That said, I can't be certain of that, because contrary to security best practices, the people who designed the X.509 specification will not make the specification available to security researchers unless they pay $130. So I can only speculate on what the standards say. Aren't standards grand?
Check out my sci-fi/humor trilogy at PatriotsBooks.
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".
Your ad here. Ask me how!
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.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat