There are plenty of old blog posts on the Internet regarding its benefits from an administrator point, but I want to speculate about the pros and cons from the perspective of a malicious actor.
Let’s Encrypt through its certbot or ACME client program allows an administrator to spin up a web site and achieve TLS from the Internet. It helps low budget administrators get certificates for their Web sites, which are recognize by a registered 3rd Party certification authority. This permits Web sites, such as my own to have a valid Web site. It also does so in an automated manner, meaning it’s also low touch from an administration stand point — effectively, set it and forget it.
What is ACME (certbot)?
In order to speculate on the pros and cons, let’s review what the ACME/certbot program allows an administrator to do. Once the Web site and its hosting/service software has been configured, the administrator then configures the certbot. The certbot is a utility software on the server that connects to the Let’s Encrypt servers, submits its certificate request, receives the signed certificate, updates the Web server service/daemon configuration, and then restarts or reloads the services.
Pros/Benefits
Low cost
When you configure your certbot, you need at least four things:
- an email address,
- a valid DNS hostname,
- Internet address, and
- administrative know-how.
An email addresses can be free, or it can be part of an organization; effectively, it allows Let’s Encrypt (as an organization) to contact the administrator if an issue is detected with the certificates or other communications. Email addresses are so easy to come by, it’s one of the many reasons for the proliferation of SPAM email. It can also be spoofed, and I receive many “malformed” emails so through compatibility reasons, it’s easy to even masquerade. If I were Let’s Encrypt, I’d add a verification step whereby the certificate isn’t registered when the administrator or user doesn’t validate it.
A valid DNS is fairly cheap, and for hosts within DHCP-assigned pools — like many ISPs, you can purchase Dynamic DNS. I did, and I am using it for genuine services. Do you like my blog? Generally, the certbot works by coordinating its signing using the host name in the request, like a callback. So, as long as the DNS host name has a forward resolving address, it’ll work fine with certbot.
The Internet address is a given so long as it’s globally accessible. RFC 1918, and other private IP address spaces, won’t work; however, the host can have a private address, and as long as the firewall permits port forwarding, the certbot should have little issue configuring the site.
Everybody can search the Web using Google, or another Web search service. There is an abundant amount of How-To blogs. Also, there are a lot of YouTube videos that can walk through configuration steps. Additionally, the certbot also comes with manual pages. Once you’ve installed the Web host, and the certbot, you can read the manual via man certbot I will say that understanding networks and having practice is greatly beneficial. Ultimately, the issue of “administrative know-how” boils down to time and practice.
Low “touch” and/or hands free
Once the certbot has been configured, all you need to do is run it on a periodic basis to refresh the certificates. I have a cron task that checks in with Let’s Encrypt on a weekly basis. If the certbot needs to change the certificate because it expired, it does so during check-in. There are also protocols for when a certificate or key becomes compromised; that’s not really hands free, but it’s there.
Provides Valid TLS Certificates
In the link that I provide, certbot does sign valid certificates. Common browsers, such as Mozilla Firefox, Google Chrome, Microsoft Edge, and etc, have Let’s Encrypt as a valid Certificate Authority. The link also talks about the difference between EV, OV, and DV; these are Domain Validation (DV), Organization Validation (OV), and Extended Validation (EV). In certbot’s basic form, it will perform Domain Validation; that is, during configuration, the Let’s Encrypt server will connect back to the host and perform some Web requests. When I was using relayd and httpd (on OpenBSD), I had to ensure that a path requested by certbot would not get an HTTP/302 Redirect while it performed these activities.
Quick Host Name Changes
As part of my dynamic DNS, I could register up to 25 host names. This is a fairly large pool, and when I spun up this WordPress instance, it didn’t take much to update certbot — merely updating the Web VirtualHosts and re-run the certbot.
Cons/Problems
Administrative Complexity
Again, from a malicious/offensive platform, spinning up a host, configuring its services, configuring the certbot, and possibly purchasing DNS and registrar is going to be costly. Some of it can be reduced, namely it could be possible to script these deployments so it can be pipelined; it can be reduced using CMS — like Ansible, but that’s added complexity. Or you could containerize the malicious deployment, which reduces spin up time and can simply be deployed on a container service.
“Paper Trail”
The registrar portion is the most paper trailing part of this — usually involving some form of credit card, and if a SaaS is used, it would also create a paper trail. It is possible to play a shell game, but that’s difficult.
Slow Reaping of Host Names
Since I haven’t attempted to spin down a host name, yet, I can’t comment about how long it takes to reap a host name. If I had to guess, Let’s Encrypt should invalidate and re-issue a new certificate once the Subject Alternative Name field needs updating. It wouldn’t surprise me if too many host name changes on Dynamic DNS causes a red flag to be risen, and I haven’t tested that to see if there are any limits. It may be articulated in a privacy policy, but I’d need to re-read them.
Easy Target to (D)DoS
If the host is done privately, on a private premises, denial-of-service would be very easy to apply on a single host. This is why IaaS is often preferred because the services generally offer some (D)DoS protection. Once the forwarding resolution name has been claimed, it basically helps attackers; it, effectively, paints a bullseye on the perpetrator when hosted privately.
Conclusion
It feels as though using certbot and dynamic or traditional DNS would lead to a higher probability of detection and mitigation by Blue Teams. If I were a Red Team crew hosting some node for collecting reconnaissance, I’d definitely try poisoning Web hosts by implementing some XSS or other persistence method. Most users don’t pay much attention, as long as the Web host has a green light, and this passivity on end-users is often coupled with few methods of reporting the situation. There is no Help Desk and CISO for the Web.