Zow! I had no idea FirstClass was a BBS server. I had a Customer in the early 2000's who was using a FirstClass server on a LAN for email, calendaring, and collaboration. It struck me as a really neat piece of software, albeit I would have preferred a web interface to the thick Win32 client. It was very well thought-out software, albeit I didn't have to sysadmin the thing (so I don't know what the back-end was like in terms of reliability, backup/restore, fault tolerance, etc).
I'm off to go down a rabbit hole re: the FirstClass software.
> I generally suspect folks would be a lot happier if they'd had a few more crap jobs as a baseline!
I'll go one further. Not only should everybody have to do a crap job or two, but they should have to work with the public. Imagine how much more chill people would be with service workers having had the experience of being one themselves.
If we build self-replicating machines and send them out into the universe we're really just sending out our evolutionary progeny. Hopefully they would remember us fondly.
I'd argue all self-replicating systems subject to entropy (i.e. existing in the physical world) are automatically subject to mutation and natural selection and, therefore, alive and able to evolve around any innate goals or constraints. If the inmate goal isn't tied to a highly-conserved phenotype I would think the goal would disappear as mutations accumulate and natural selection takes its toll.
I used Apple Writer in on Apple II machines in my public library in the 80s. I can't say I remember a ton about it but it's definitely a name I remember. I remember using AppleWorks on the machines at school, but I liked Apple Writer better and lamented that I wasn't permitted to use it at school (because the teacher said she wasn't familiar with it and couldn't help me if I had problems).
About Apple Works ... Apple paid me massive royalties for Apple Writer but got tired of that arrangement pretty quickly. So they made an outright-sale deal with the Apple Works guy.
Then the Apple Works guy refused to answer after-release bug reports unless he got ... wait for it ... royalties.
This was such an improvement to mine as well. Lots of strange advice in this thread about "one sentence/question per email" and other arbitrary terseness. Just use a messaging system for single-thread async communication.
Writing the email is part of the thinking process for me so by the time I finish there is a single coherent sentence that I can cut-paste to the top with the rationale/evidence/etc organized below it. If the one-liner is enough they can skip the rest (which I needed to write anyway regardless) and if they need more detail they don't have to ask.
Some other practices I've picked up over the years:
Responses should always be inline between relevant quotes rather than the default of hiding the original at the bottom. Remove quotes that don't matter. My favourite responses are a simple "Agreed." after a long quoted paragraph of justification.
In general the email chain should get shorter with each reply otherwise it suggests that the topic is either too complex or insufficiently defined. It also gives some sense that it will eventually end!
Write subject lines that make searching/filtering easy to do later rather than something to catch the recipient's attention.
> Writing the email is part of the thinking process for me...
Same here.
> Responses should always be inline between relevant quotes rather than the default of hiding the original at the bottom.
This is highly polarizing. As you can tell I also like inline replies. I grew up using BBSs and inline replies were common. It seemed so natural. Then Outlook came around and top-posting became the norm.
I have gotten some scathing criticism from higher-ups for inline responses (along with some scant praise). I have been told, repeatedly, that inline responses are confusing.
Personally, I think anybody confused by inline responses (particularly if they're formatted distinctly) probably shouldn't be using email as part of their job because they lack the necessary mental faculties.
(I've given up with my strongly-held beliefs about plain text email. I still send plain text by default but I grudgingly reply with HTML / rich text if an email started that way.)
I've never heard of people having difficulty with inline replies before. Show them how to configure `sed 's/> /You said /g'` to run on all their incoming email...
The relative proximity of the words "done right" and "split-horizon DNS" makes my insides hurt a little bit.
Use DNS validation to allow these internal services to pull ACME certs. There's so much less headache, long-term.
Split-horizon DNS (and the tedious make-work it can create when you start needing to mirror public-accessibly records in the private DNS) has always been something to aspire to move away from in my experience.
Thank you, I was unaware of that. It looks like it's already support in the acme.sh client, but there is a Let's Encrypt discussion saying it's still pending at LE:
At this point, can't we make a standard that skips the middlemen and just embeds the certificate directly inside the DNS entry? It seems the challenge system is converging towards that anyway.
That would be DANE with TLSA (RFC 6698, not the stock ticker symbol). You've still got just another chain of trust with the DNSSEC requirement, and the recent DENIC outage breaking that for the entirety of .de isn't the greatest advertisement :D
(To explain that some more: The current "way to go" with fully automated cert issuance is delegating its trust to DNS anyway - so we might as well get rid of CAs and use the DNSSEC chain of trust directly, with TLS certs linked to it.)
Yes, which goes back to the old question: why the heck are we using a bunch of insecure systems with awkward bolted-on workarounds instead of just using DNSSEC?
I never understood the issue with DNS-01. if you have a process that you trust to maintain a zone's TLS identity what is the big deal about letting it control a record in that zone?
We have a few subdomains for white labeling 3rd party SaaS where we do what is basically the AWS ACM equivalent and add a persistent record from a vendor.
With this setup, I don't have to grant 3rd parties DNS access.
I actually made a webhook that allows per hostname API keys to wrap dnsimple because they only had per zone keys and I didn't want each VM to have access to the entire zone. These challenges would have solved that by allowing the DNS record automation to pull record values from the VM instead of having the VMs push values.
I think someone told me dnsimple might have more granular keys now but I haven't checked. Iirc we have the same concern with external-dns at work (some things need subdomains on the TLD but we don't want to give external-dns access to the whole zone so we usually cname the TLD subdomain to a per environment zone external-dns is allowed to update). With this, we could have the same pull based setup that applies arbitrary rules to decide if a requested record should be created.
I think the main takeaway is allowing pull instead of push model
Could be achieved with cnames but it's an extra layer of indirection to deal with and doesn't fully solve the "semi trusted 3rd party" case
You could already do that by setting a _acme-challenge alias CNAME record, so you can point it to a domain that they control. It's a bit finnicky and the new setup definitely looks better for whitelabelling, but there are current workarounds; although it does still involve client DNS access, you can put it onto a zone that has no risks
Our current level of granularity allows you to give read or write access to a specific zone, but it does not go down to the level of giving read or write access to a specific RRset type yet, if that's what you're looking for.
You can even put it in a seperate zone (which I do) by using a CNAME for _acme-challenge.domain.tld.
I have it to a seperate subdomain, which is served by a seperate desec.io account, which is only used for this specific subdomain.
TIL, thanks! This makes dns challange automation more approachable for me. I always had an issue with API keys which scope can't be limited to TXT records. This seems to be a nice workaround
Or, just use IPv6 and host Internet services in a routable address. Then, use ACLs at web server / proxy / L7 lb level to allow acme-challenge unauthenticated but everything else authenticated.
Another big problem with split-horizon is you can get clients that cache the dns result before connecting to the vpn, then after connecting, can't actually use the service, because it is using the public ip instead of the private one.
> because it is using the public ip instead of the private one.
For this edge case, the issue is not with DNS; it's that the router is not configured to allow internal clients to access the network through the public IP, vis-à-vis hairpin routing.
Our issue was on multiple fronts. On windows it was GlobalProtect overriding dns requests. On Linux it was an issue with the OS fighting which nameservers to use. The fix was some experimental flag, tho I can’t remember it currently.
Yes - literally just pick the right Caddy (or similar) image with Let's Encrypt client included - and you can simply add a tag/label to your docker compose files for each of self hosted services to get a real SSL, that auto renewed ...etc.
With one of self hosted services being Adguard-Home can do both ADs blocking and internal DNS... The public DNS records for your "internal use only" domain remain empty.
CAUTION, though, the last time I downloaded a binary release, ClamAV triggered on it, so I kept my old version which worked. I was using the 1.0 series (without any problems!), and now it seems the project has picked up development again with a 2.0 series.
Interesting, this is the first time I've seen this project. One thing I saw that concerns me a bit is that they provide command-line options for passing your user credentials and multi-factor code. I'm not a fan of giving anything that level of access when a resource-specific access token will do, but that's me.
I get antsy about a private key being in lots of places. You've also got to worry about renewal so you might as well just have "consumer" of the wildcard just provision its own non-wildcard certificate.
> Use DNS validation to allow these internal services to pull ACME certs...
The major ACME clients support DNS validation. If your DNS host doesn't have an API that your ACME client supports either get a new ACME client or a new DNS host.
I thought you have a solution to overcome not having to do split DNS where I define public IP in public DNS and internal IP within some local hosted DNS.
Like how to make so that when connecting from inside local network the router recognize that by connecting to public IP, he has to route it back onto some local IP address?
Hairpin NAT (or "NAT hairpinning") is the term for "...connecting from inside local network the router recognize that by connecting to public IP, he has to route it back onto some local IP address", and the Linux NAT implementation supports it.
For a homelab situation split-horizon DNS is just fine. You're going to have minimal duplication of records from the public DNS into the private DNS.
The canonical frustrating "bad split-horizon DNS" world I've seen, time and again, is a corporate network with a MSFT Active Directory named the same as the company's public-facing web property (e.g. "example.com" rather than "ad.example.com"). This creates the need to duplicate all the public-hosted resources into the internal "example.com" zone (and keep them updated when records inevitably change on the public Internet). It's make-work for no practical upside in that example.
Shuffle would certainly help with that. I felt like I was expending a ton of energy and time shuffling mentally (but I'll concede that if I did it enough I'd get faster at it).
The best model of the WRT54G line. I would snag them at thrift stores for cheap to use for silly utility functions. I always referred to that particular model as "The highly-coveted WRT54GL."
I used a pair to provide Internet access at a Customer's construction site back in 2010. Cell phone hotspot wasn't a thing for me yet. We took a pair of WRT54Gs, configured one as a WiFi client, the other as a bog-standard router/AP, connected the LAN from the client to the WAN on the router/AP, pur a directional antenna onto the "client", and pointed it down the road toward a big business who offered free WiFi for Customers. We leeched off that until the real Internet service got installed. (It was a restaurant and we ate there at least once so we were Customers, right? >smile<)
It seems crazy to me that Linksys didn't look at the success of the WRT54GL and the higher prices they commanded and decide to just keep doing that. Why every company feels the need to roll their own firmware that is buggy, slow, crashy, and doesn't implement half of the promised functionality properly is still baffling to me.
Companies roll their own, I think, because of a combination of Not Invented Here and secret-sauce binary blobs. They work within the script that the chipset/radio maker gives them to follow.
---
They don't often offer inexpensive, deliberately-hackable units like the WRT54GL, I think, because of support costs.
And by "support costs," I don't mean that it was expensive to hold users' hands while they installed custom firmware -- that's never been a service that has been provided.
Instead, I mean that there are people who start goofing with this stuff and run out of skill when hacking close-ish to the metal on this kind of hardware. They don't know how to get themselves out of a jam and unbrick their device.
So they find a way to lie their way into getting an RMA and get the device replaced under warranty, and that's expensive for companies to deal with.
It's disappointing that we still have terrible "press 9 buttons at the same time while reciting from the Necronomicon and plugging in and out the device" recovery stories.
Put the firmware and config on a ** uSD card, or set up some sort of UF2 recovery mode. Then no matter how badly you bollix it up, the answer is "plug it into your computer, download the big prominent "factory image", and drag it onto the device.
If done right, you could even do stuff like "clone the SD card so you can deploy identically-configured units for every branch of your chain business."
That's great when you have control of your applications. For most corporate IT you're stuck with COTS applications and whatever their built-in auth functionality is. Sure, you can probably bolt a reverse proxy in front (if you're lucky enough for it to be a web app and not a thick native code client) but you get to argue with the vendor when they refuse support because you're not using their recommended configuration.
802.1x certificate-based authentication at layer 2 is a good defense in depth strategy.
Even if you can't authenticate at the application level, it's still much better to encrypt/authenticate traffic on the wire (using a VPN or something like Tailscale) instead of 802.1x auth.
How is an overlay network "much better" (or meaningfully different) than a device-based certificate and 802.1x when the user is accessing an application delivered over HTTPS using a publicly-verifiable certificate authenticating via SAML w/ MFA (Entra ID)? The source subnet attests successful device authentication in the 802.1x example but that's irrelevant beyond, perhaps, a firewall granting access for the device to terminate a TCP connection to the server's TCP port 443. That's no different than the request coming to the server from an authenticated overlay network, to my eye.
I guess if you want to tie the network layer authentication to the user make it 802.1x with a user certificate. Either way you know the request is coming from authenticated endpoint and the user still authenticates to the application independent of the network layer. In all cases HTTPS protects the traffic from MiTM end-to-end.
I'm off to go down a rabbit hole re: the FirstClass software.
reply