SSL Generators and security

Until you find out about the caveats... :smirk:

--dry-run doesn't work with run...

install doesn't update the installation configuration...

run acquires a certificate even if it's a duplicate of one nowhere near expiry...

:crazy_face:

4 Likes

@griffin That's some fine FUD towards certbot there...

3 Likes

I've been preparing a "questionnaire" for the certbot-devs. :grin:

I'm sure other ACME clients have their fair share of "questionable" behaviors.

When you're running out front, you make the easiest target...

4 Likes

A javascript/3rd-party client using a CSR only ensures the PrivateKey is not being shared; that client could store the AccountKey and use that to revoke existing Certificates or provision new certificates within the valid authorization period (which is 30 days).

Using a DNS Provider's API creates a lot of security concerns, as few providers have granular control of their API tokens -- and the same token can often be used to transfer away domains. (This article touches on that topic A Technical Deep Dive: Securing the Automation of ACME DNS Challenge Validation | Electronic Frontier Foundation ).

If you use a web-based or third-party client, only HTTP-01 should be used.

IMHO, third party / web based clients should be banned. I will not be surprised if, in the future, a web based client issues a bunch of commands to revoke or re-provision certificates without the domain owners consent, which then leads to the CA/B Forum levying a warning or penalty against the involved ACME Services... and then the third party services are banned. I am probably being optimistic here, but I think LetsEncrypt likely feel this way too, and are stuck trying to figure out how to handle these sorts of things in terms-of-service, as a lot of provisioning happens via large hosting providers who handle everything as a third party on behalf of a client.

5 Likes

Banning third-party and/or web-based clients is a technical challenge. If you remove CORS support, "JavaScript only" clients will be force to move server-side, just making it harder to see if they're stealing your data.

LE could require the request to come from an IP address that the hostname resolves to, but that would only work for simpler setups (load balancers, round robin DNS, and others would suffer).

Denying based on a blacklist (specific IPs from known third-party hostnames) would create a maintenance nightmare.

I'm guessing if LE could just flip a switch to disallow these, they'd already be gone.

2 Likes

And so would a good chunk of LE certificates that might be replaced with nothing (http). A lot of people don't possess the skill or circumstances to install and use a full-blown ACME client.

4 Likes

Are you the same guy that provided a link to a site that can be downloaded and run completely from the client PC?
https://gethttpsforfree.com/

If LE provided such a simple and downloadable solution, wouldn't that help reach even those that don't possess the skills and circumstances to use a full-blown ACME client?

The sites exist because they fill a need - I get that.
If you want to remove such sites (most of us do) - then those needs musts be filled in some other way.

5 Likes

I respect your opinion greatly, Jonathan, as I know your knowledge in this area is vast. I must ask though (and you already know this dilemma well): How can I trust the code in a first-party client not to steal my private keys AND my ACME account key? Does being a first-party client automatically result in greater trust than a third-party client? With my being a known member of this community, would your trust my website ACME client less than a relatively-unknown first-party client (without auditing all of its code first)? :slightly_smiling_face: Trust is an interesting thing...

To be clear though, I do agree completely about the CSR-only part though for trusting a client. Hence why my own client only accepts CSRs. I may have confused your final plea against website clients. If so, mea culpa for sure. I would love to take down every website that "generates your keys for you".

I suppose it's the opacity of website clients versus the supposed transparency of "first-party" clients (if anyone without vested interest bothers to audit them) that forms the crux of the issue.

4 Likes

I'm a little confused, Rudy. :woozy_face:

I did provide that in case the OP wants to see the most secure solution possible. :wink: I've used it, multiple times, but I don't recommend it to the faint of patience.

It's not the least bit user friendly and would require scripting of openssl commands or the like.

I agree completely about security over formality though. HTTPS by hook or by crook beats HTTP any day (given reasonable stability).

4 Likes

So we break the big problem down and smaller problems remain.
How does an totally unskilled user generate a secure private key?
[without which a CSR can't be made]
[without which third party delegation/integration becomes a real trust issue]

5 Likes

Using cPanel, like I do all the time? I've actually been meaning to generate that GoDaddy shared-hosting guide I promised. I decided at a point just to solve the problem. I suppose I should make the guide just for the sake of argument.

4 Likes

My bucket of likes has a hole in it :frowning:

7 Likes

I know the feeling. You need a fairy: :fairy:

3 Likes

With my being a known member of this community, would your trust my website ACME client less than a relatively-unknown first-party client (without auditing all of its code first)? :slightly_smiling_face: Trust is an interesting thing...

You make a compelling argument here. When I install a package like certbot, I assume (perhaps foolishly) that I can trust it because many people are using it... so someone probably would vouch for its integrity. There's a level of trust implied within that process, but perhaps there shouldn't be. Certainly it wouldn't be the first time a repo hosted malware or a package was compromised in some other way.

On the other hand, I still have a hard time accepting a web-based client as anything other than trouble. CPanel almost certainly already has an entire feature for fetching LE certs.

2 Likes

@jvanasco

I don't want you to misinterpret me though, my friend.

To be clear, I do agree completely about the CSR-only part for trusting a client. Hence why my own client only accepts CSRs. I may have confused your final plea against website clients. If so, mea culpa for sure. I would love to take down every website that "generates your keys for you". Those keys should be sent straight to https://pwnedkeys.com.

I suppose it's the opacity of website clients versus the supposed transparency of "first-party" clients (if anyone without vested interest bothers to audit them) that forms the crux of the issue.l

4 Likes

The problem is that not all cPanel providers support native generation of Let's Encrypt certs. GoDaddy shared hosting, I'm looking at you... :face_with_monocle:

4 Likes

Yeah, well... people do bad things when millions of dollars are concerned. Perhaps those writing web-based "SSL Generator" tools (I'm looking at you @griffin... :face_with_monocle:, LOL) should instead let those hosting their websites with GoDaddy go without TLS... then maybe GoDaddy would start to lose hosting revenue.

Or even better... find a really stupid simple way around GoDaddy's lack of LE support. Like a single PHP script that someone could upload to their GoDaddy shared hosting, then visit it... it would do the rest and save them from needing to manually renew every 90 days. I do, of course, realize the irony in suggesting such a script... it would only be marginally (if even) better than a third-party web-based approach.

3 Likes

Funny you should mention that... :grin:

Be on the lookout for what's coming soon...

I've already been developing this. It's way more than marginally better...

5 Likes

Hey guys, I created the SSL generator above, and I'm glad you are talking about the security aspect of these tools. Because that was one of my concerns when I build it.
And indeed none of the information should be stored in the backend. Everything works on the client side.

And honestly, if GoDaddy would just allow people to get a free SSL certificate in their dashboard (like pretty much every other web host), the need for these tools would be minimal.

That said it sounds like CSR could be a bit more secure, but it's not the most user-friendly way to generate these thing. A lot of people still get stuck when trying to verify their domain ownership with the txt file. CSR would just make it even harder for those people. Most people that use the tool just want to get rid of the "this site is not secured" warning in their browser.

3 Likes

It sounds like perhaps @griffin will be working on a PHP acme client. Maybe that'll become the gold-standard for users who need TLS but who cannot navigate (or don't have access to) a command line. It could be named "GoDaddySSLGenerator.php"... upload it, visit it and follow any instructions in the browser... it could even delete itself when it's done the job (@griffin - yes, these are feature requests :stuck_out_tongue_winking_eye:)

3 Likes