Speaking with authority

I’ve just spent the better part of three hours arguing on IRC about Let’s Encrypt clients. After speaking with two others, I realised that nobody who I spoke with before knew their facts were facts.

Different people all told me various incorrect information, such as:

  • No ACME client supports doing a manual DNS TXT record for verification bootstrapping until you have an httpd up. (acme.sh, dehydrated, and certbot all support this.)
  • LE needs IPv4 for the HTTP challenge. (It worked fine for me with an IPv6-only host. I’m not sure which it would prefer if it had the choice between v6 and v4, or if it’d use Happy Eyeballs and connect to whichever responded first.)
  • It isn’t possible to step through the process manually as a debugging aid; you have to rely on your ACME client’s debugging facilities. (https://gethttpsforfree.com/ helped a tonne.)
  • You have to be listening for the HTTP challenge on port 80. (The TLS-ALPN-01 challenge type exists which will only ever use port 443 for the challenge.)
  • Critique of how I isolated each service on a separate VM so that they would be more secure, saying it was “over-convoluted”.

All of these people spoke with an air of authority. They sounded like they genuinely knew what they were talking about, and were trying to inform me of the limitations of ACME clients / Let’s Encrypt. Nobody actually knew the answer, but they thought they were right because it fit their experience.

When I speak to people about technology, whether in real life, on IRC, or on a mailing list, I always try to make the limitations of my knowledge clear. Many is the time I have said “I’m not sure if you can do that”, or “I don’t know if X supports Y“. And sure, on occasion I will say “I have never done Y and last I knew X couldn’t do that”. Note, however, that all of these are presented as statements from my hive of knowledge, and not presented as plain facts. The art of communication seems to be lost on far too many in the technology field.

There is no shame in not knowing the answer to something. It is certainly more helpful to say “I’m not sure you can do that”, instead of “you can’t do that”. I almost gave up on Let’s Encrypt and wrote another article on how useless it is, because I was told by people who used Let’s Encrypt that it had all of these limitations that made it seem useless, arbitrary, and ridiculous to me. (Thanks to Rich Felker of musl, and Freeyorp, for setting the record straight.)

Maybe we need a new term for this. “Organic FUD”, since it comes from the community itself? At any rate, I hope that in the future, more people note the limitations of their knowledge up-front rather than sounding authoritative about a subject they know little about.

Let’s Encrypt and why I still pay for TLS certificates

I am asked with alarming regularity why I am not using Let’s Encrypt for Web sites. This article answers that question.

I am asked with alarming regularity why I am not using Let’s Encrypt for my personal Web sites, and for Adélie‘s site, and for my mother’s art gallery site, and so on. “Why do you pay money for something you could have for free? And then you aren’t giving money to those evil CAs!”

TLS certificates are still very much “you get what you pay for”. Let’s Encrypt is free, and on paper it seems to be a great solution with roots in freedom and socialism. However, it has a number of large issues in practice that prevent me from being able to adopt it.

The first, and most evident, is the failure of the community to provide a single ACME client that is well-supported and provides configuration options. As of this writing, there are 49 different client implementations on the official site. The problems with them are as numerous as the offerings; my main complaint is that most of them require themselves to run as the root user to automatically write to sensitive certificate files that are owned by the Web server user and are chmod 400.

The second large issue I’ve seen is that most of these ‘automatic updates’ break. This can be due to administrator error – and since there is not one single option, there cannot be a single repository of knowledge. This can also be due to APIs or endpoints changing. I have seen an official Mozilla blog and Void Linux’s repository broken in the last week alone, all by botched ACME cron jobs. This solution is sold as “set and forget”, but it requires more effort than simply going to a site every year and inputting a CSR and privkey.

Other issues with Let’s Encrypt include: Let’s Encrypt lacks a “site seal” which is very important on e-commerce sites to foster user trust. Let’s Encrypt does not provide OV (let alone EV), which also compromises trust in people who know what to look for.

All in all, I think going forward Let’s Encrypt may be suitable for power users and people who run TLS servers off their home servers. It may even be suitable for some personal sites and blogs. But I don’t think it is a long-term solution for person who need trust, or those who have a complicated infrastructure (such as a distro, like Adélie).

Musings: More Python 3 compat, Project Sunrise, InspIRCd modules and Portage

Some good news: as I eix-sync’d this morning, I noticed that dev-python/ndg-httpsclient and dev-python/ipaddress now have Python 3 compatibility. That means two of the packages I had thought had no chance of being upgraded actually have been. As for my own efforts, I have been very busy with work and musl support patches lately, but I have been looking at fixing up the htop package next.

I’ve found Project Sunrise, a way for me to be able to contribute ebuilds to Gentoo in hopes of someday getting them in the master Portage repository. I’m hoping to add a few Python libraries first, then moving up to packaging SuperGameHerm and PyIRC once they’ve matured enough to be useable by external users.

While testing PyIRC, I needed to be able to use a few modules that are not a part of InspIRCd’s main package. Since Portage didn’t allow any way of including them in the installed package, I simply checked out the source code package, ran modulemanager to add the modules, then built only those modules. I copied them to the /usr/lib64/inspircd/modules directory and added them to modules.conf, and voila! Now I can do more IRCv3.2 testing.

Musings: SSH key types, PayPal API documentation, and more

I have a few random musings to arf about today.

Sleep is miserable. I don’t know why I even bother pretending to have a schedule to myself. Between work demands, personal issues, and the fact that I tend to favour going to sleep around the 05:00 hour naturally, it’s impossible. Sure, I can hold a “normal person” schedule indefinitely… if I have no external factors. But my life is full of external factors that make it impossible. And there are some people in my life that try and make me feel guilty for not being able to hold a schedule. It feels miserable.

In other news, PayPal’s API documentation for their SetExpressCheckout call lies. They say the xsi:type for the SolutionType is “ebl:SolutionTypeType”, but I found out the hard way that passing that as the type causes a SOAP Fault (and leaks the API password and signature out in the error message)! The only way I can find to do it properly is to set xmlns=”urn:ebay:apis:eBLBaseComponents” on the SolutionType node and then set xsi:type=”SolutionTypeType” (no ebl: namespace). Then the API accepts it fine. Who knows why their systems do what they do.

I investigated making a new SSH key that would be stronger than my current one. Unfortunately, it doesn’t seem I really have a choice in the matter. The only common denominator is RSA, as shown in this matrix:

Key Type Mac OS X NetBSD Debian
RSA Yes Yes Yes
DSA Yes Yes Yes
ed25519 No No No
ECDSA No Yes Yes
SSH Version / OS Version 5.6 / 10.8.5 5.9 / 6.1.5/i386. 6.0 / 8.0 “Jessie”.

Note that the following systems supported all listed key types:

  • Gentoo 20150623
  • FreeBSD 10.1
  • OpenBSD 5.6
  • Alpine Linux 3.2
  • Windows 2000

Truly a sad day when a 16 year old Windows OS has more SSH key types available (via mingw) than Mac OS X, NetBSD, and Debian combined. Looks like I’m sticking with RSA keys for the foreseeable future.