Hacker News Reader

Comment by Santosh83 | Hacker News Reader

No joint announcement with other industry 'leaders' like Google and Microsoft? What is their stance on this? Will they be making similar changes to Chrome/Edge? And Mozilla? And maybe I am wrong but compromised certs are game over very soon aren't they? Reducing their lifetime to 'just' a year is still plenty of time to do enough damage seemingly, so what exactly does this high-handed change bring to the table? Another reason stated that it will keep the cert management folks busy and alert also sounds like grasping at straws to prop up the decision. I wonder what the entire reasons are...

View on HN

The goal is to promote automation and continue lowering certificate lifetimes as operations get better. This ultimately will allow for lifetimes short enough to be useful.

As for the other browsers, Google originally proposed SC22 (https://cabforum.org/pipermail/servercert-wg/2019-August/000...) last year and all the browsers voted for it. CAs voted it down at the time but there were rumblings via various back channels that several major CAs actually wanted the ballot to pass but for political reasons could not publicly support it.

So while Apple is acting “unilaterally” here, there is universal support among browser makers and tepid support from CAs. You should expect Google and Mozilla to follow suit in the next 6-12 months.

How will that automation verify that certificate is issued to the legal owner of the web site and not a hacker? Are the challenges used by Let's Encrypt secure? For me, automating certificate issuance will lead to less and less verification, to the point where having a valid certificate will become meaningless.

EDIT: to clarify - there are two bad things about Let's Encrypt:

1. It's automated

2. It's free

The fact that it's automated results in less human intervention along the way, which on one hand lowers costs, on the other hand makes it detecting scams harder (unless they deploy some really Machine Learning that detects frauds).

The fact that it's free means that there's no credit card number or other info that would help identify actual person that requested certificate issuance.

Together those things make things less secure, not more.

EDIT 2: Both types of Let's Encrypt challenges look like pushing down the responsibility to either web server owner or DNS service. Maybe that's a good thing, since at least there's one fewer party that can screw things up.

The challenges used to verify ownership and whether the task is automated or not are mostly orthogonal issues. I don't see how automating the renewal makes it less safe, if anything it removes human error from these tedious tasks.

How does doing it manually verify that certificate is issued to the legal owner of the web site and not a hacker?

It doesn’t. It actually opens up more opportunities for error, intentional or otherwise, that can possibly be exploited by a malicious actor.

Humans are actually detrimental to preventing abuse.

I think you may not be very familiar with Let’s Encrypt’s challenges. Allow me to briefly explain the gist of them:

The two most common challenges are an http challenge, and a DNS challenge. The http challenge gives you a response code to host as a file on the domain during the validation period. This challenge is, for all practical purposes, random, and cannot be guessed. Then, after your script tells Let’s Encrypt that the response to its challenge is available and up-to-date, Let’s Encrypt performs an http GET request to retrieve that response, and checks to ensure it is exactly what the script provided. Only then does it proceed with signing your CSR and giving you a valid certificate.

This requires (at least temporarily) a web server running on port 80 at the domain in question, and in order to break it you would need to be able to effectively either hijack the A record for the domain as read by Let’s Encrypt, or to break into the web server to properly issue a certificate that one then steals. Impossible? Probably not. Impractical? Very.

DNS challenge is even more secure, in my opinion, as it works the same but the response code is stored in a TXT record for Let’s Encrypt to validate. In order to break this you would need control of the DNS servers.

So, to put it rather simply, >Are the challenges used by Let’s Encrypt secure? Yes, so long as you trust your DNS and web servers not to be compromised. And if they are, it’s frankly game over anyway.

Now let’s contrast this with, for instance, getting a multi-year certificate from the likes of Verisign or similar: this (as far as I am aware) requires manual interaction, which can at least theoretically allow for human error, of which there are many chances.

Additionally, many more traditional CAs will let an inexperienced user have the CA generate the private key and then transmit it to the user. This opens up a LOT of dangerous possibilities, as now this private key is being saved and moved around, and could easily be missed and left on the workstation used to perform the work. Or a MitM attack could even snatch it in transit.

Honestly, I don’t think there is much (if any) point in still using manual verification. The human aspect of it also opens up chances for forgery, and so on.

Let’s Encrypt’s challenges are specifically designed to be difficult or impossible to hijack, and so far as I understand it the private key should never leave the server it will remain on.

So again, to answer your question succinctly and to the best of my knowledge: yes, the challenges used by Let’s Encrypt are most certainly secure.

> DNS challenge is even more secure, in my opinion, as it works the same but the response code is stored in a TXT record for Let’s Encrypt to validate. In order to break this you would need control of the DNS servers.

> Now let’s contrast this with, for instance, getting a multi-year certificate from the likes of Verisign or similar: this (as far as I am aware) requires manual interaction, which can at least theoretically allow for human error, of which there are many chances.

What I've never understood is how this doesn't ultimately just shift the security risk to my DNS registrar.

Instead of social-engineering the CA to give me a cert, I have to social-engineer the registrar to store a TXT record. I don't see why one should be significantly harder than the other.

> Additionally, many more traditional CAs will let an inexperienced user have the CA generate the private key and then transmit it to the user. This opens up a LOT of dangerous possibilities, as now this private key is being saved and moved around, and could easily be missed and left on the workstation used to perform the work. Or a MitM attack could even snatch it in transit.

Again, it's harder for a rogue CA to abuse my certificate - but instead, a rogue registrar could now easily manipulate my DNS record and receive a valid cert of its own.

I think there's an underlying assumption that your server, your DNS registrar, and all the CAs present in your root store are trustworthy. It may not be a particularly safe assumption, but it's presumably better than unverified TLS or trust on first use (for the majority of present day usecases).

If anything, I would expect universal adoption of automated verification methods to improve security. Instead of only needing to trick a single CA out of an entire root store into issuing a certificate, you would instead need to hijack the DNS listing without being noticed by _anyone_ (and hopefully all CAs, as well as everyone else, would be on the lookout for this).

This is correct. But perhaps even more correct would be to say it _consolidates_ the risk at your DNS registrar, since of course bad guys who seize control of your DNS records could anyway deny all service and capture anything unencrypted.

You should definitely not use an untrustworthy DNS registrar or registry for important things, but that was true regardless and it hasn't stopped the .com TLD (which is run very badly indeed) making a tremendous amount of money.

> What I've never understood is how this doesn't ultimately just shift the security risk to my DNS registrar. > Instead of social-engineering the CA to give me a cert, I have to social-engineer the registrar to store a TXT record. I don't see why one should be significantly harder than the other.

Rogue registrars aren't necessary: one can simply attack the registrar or interfere with the DNS traffic. These attacks have already been seen in the wild and are continuing today: check out info on DNSpionage (https://blog.talosintelligence.com/2019/04/dnspionage-brings...) and Sea Turtle (https://blog.talosintelligence.com/2019/04/seaturtle.html) attacks.

Meanwhile, Let's Encrypt has been making some interesting changes. For instance, they just introduced multi-perspective challenges (https://letsencrypt.org/2020/02/19/multi-perspective-validat...) in which they submit multiple challenges to the user from different network paths. Attackers hijacking network paths to interfere with challenges must then intercept all possible paths to a client, which is much harder.

That said, I'm not a fan of devolving our certificate validation to DNS--it's like building a castle on Jello. It wasn't designed to be a security-first protocol, and it's definitely showing its age.

> Additionally, many more traditional CAs will let an inexperienced user have the CA generate the private key

This should not be true for any CA in the Web PKI. If you have evidence that a CA trusted by Mozilla offers this service you should give that evidence to m.d.s.policy (or me and I'll see it gets passed on with attribution)

There have been resellers who offer this. These are independent businesses from the CAs, and it's even crazier to let them (basically middlemen with no oversight) pick your private keys or know what they are. But as separate businesses it's hard for us to effectively stop them.

>The fact that it's automated results in less human intervention along the way, which on one hand lowers costs, on the other hand makes it detecting scams harder (unless they deploy some really Machine Learning that detects frauds).

You think that other CAs manually issues their DV certificates?

>The fact that it's free means that there's no credit card number or other info that would help identify actual person that requested certificate issuance.

How do you feel about CAs that accept cryptocurrency, or accept prepaid credit cards?

CAs are free to come up with more complicated schemes for customers that think they need them, including systems that include humans in the loop if that's what is requested. It's kind of embarrassing that hasn't happened yet, but apparently "just buy long-term certificates instead of bothering to improve things" wins out unless there is external pressure.

That said, many CA verification processes are just less-standardized variants of the things LE does. If you can get LE to give you a fraudulent cert, you will also find another CA you can fool.

A customer can (and some high value customers do) proceed as follows:

* Pick a CA you can do business with. Let's say it's Sectigo as an example here

* Arrange a deal with Sectigo whereby they'll use an agreed process such as phoning a specific (confidential) contact number and speaking with Dave your Head of IT Security to confirm it's as expected before each certificate is issued for your names. Maybe this is a minimum volume deal like you'll pay them $2000 for the first up to 100 certificates per year and then $10 for each additional certificate.

* Set the CAA resource in your DNS for your names to require Sectigo as the only authorised CA.

Now when bad guys try to trick Sectigo it doesn't work because Sectigo calls Dave who shuts it down and you're onto them. If they instead try to trick say, Let's Encrypt the CAA resource says only Sectigo is allowed and the attack fails immediately.

The Ten Blessed Methods (of which Let's Encrypt offers three) are obligatory though, you can't make a deal with a CA to just skip it, they must use one of those methods. However if minimum friction is your goal you could find a CA that also operates as a DNS registrar for your names, whereupon one of the methods (3.2.2.4.12) means they only need to confirm this fact internally, no work for you.

> The fact that it's automated results in less human intervention along the way...

Let's Encrypt is far from unique in being heavily automated. If anything, its verifications are more stringent than those used by other major CAs.

> The fact that it's free means that there's no credit card number or other info that would help identify actual person that requested certificate issuance

Payment details are basically useless in terms of tracking abuse. Attackers have no lack of access to untraceable or fraudulent payment methods.

In regards to your edits, let me also mention that Let’s Encrypt does not offer (and indeed can not offer) “Extended Validation” certificates, due to things related to the two “bad things” you mention. However, extended validation certificates don’t in fact prevent fraud the way they are intended to — indeed, a security researcher managed to get ahold of a certificate for Stripe, Inc. simply by legally registering a corporation under that entity name elsewhere and purchasing a certificate for that legal company.[1] This issue with EV certificates — the fact that they are issued to a company as opposed to just a domain name — cause them to potentially pose a greater risk to web users.

[1] https://arstechnica.com/information-technology/2017/12/nope-...

Setting aside the question of Let's Encrypt challenges... even for OV or EV certificates, the CA does not verify the organization at the issuance of every certificate.

Instead, there is a verification process up front when you establish your company's account with the CA, and then each employee's account in the CA web application is associated with the verified company identity.

To be more specific, once the initial company verification is done, the CA relies on their authentication scheme to ensure that the person logging in and requesting a new EV certificate is authorized to do so for that company. The importance of authentication is why both MarkMonitor and CSC require 2FA, for example.

I can't think of a reason that such certificate issuance could not be automated. You would just need to have a machine-to-machine authentication scheme that you can trust and monitor. That is easier than Let's Encrypt's challenges because you can manually establish shared secrets in advance (i.e. API keys).

Google and Mozilla are both major backers of LetsEncrypt which is tackling this problem from the other side (issuing short-lived certificates and putting in a system to automatically update them).

Reply on news.ycombinator.com