Show HN: Local development with .local domains and HTTPS (localcan.com)
Hi HN! I'm Jarek, and I've built this tool that allows publishing .local domains on the local network using mDNS.
It also has a reverse proxy that handles HTTPS termination and port forwarding.
I'm working on adding more features, like an index page with all available domains or allowing proxy redirects, so you could redirect from HTTP to HTTPS.
Let me know if you have any questions or feedback!
107 comments
[ 4.1 ms ] story [ 192 ms ] threadI can already access "myserverhost.local" from everything but android and OSX. Windows and Linux work fine automatically.
https://source.android.com/docs/core/ota/modular-system/dns-...
https://issuetracker.google.com/issues/140786115
I'd love to update my notes if that's the case.
Your linked article (the official source from Google) states "November 2021" [1], which by date would correspond to API Level 32 aka. Android 12.1.
Android 12.0 might also have the feature backported on some devices, according to some reports such as seen in the issue report for the feature [2].
Finally, the feature has apparently not been backported to Android 10 or 11, according to a blog post I found about this topic [3].
[1]: https://source.android.com/docs/core/ota/modular-system/dns-...
[2]: https://issuetracker.google.com/issues/140786115
[3]: https://www.esper.io/blog/android-dessert-bites-26-mdns-loca...
When do you expect to add Linux support? Until then, I'm using a devenv.sh Nix-based setup (without mDNS), with something like this: https://github.com/cachix/devenv/blob/main/examples/mkcert/d...
I'm pretty sure I'm misunderstanding the value-add of having TLS for localhost connections...
That being said I don't know why you would pay for an application that does this but I guess I'm not the target market.
https://developer.mozilla.org/en-US/docs/Web/Security/Secure...
It often feels like the noose is tightening tbh. There are things that contemporary "evergreen" web browsers just flat out refuse to do without https.
I think this is where they document this... https://www.chromium.org/Home/chromium-security/prefer-secur...
which I got from this stack overflow answer https://stackoverflow.com/a/34161385
.local tld is for the local subnet, not necessarily localhost.
If you're not using .local or .localhost, just add `tls internal` to your config to make Caddy issue certs using its local CA. Caddy attempts to auto-install its root CA cert, just like mkcert (almost identical code, in fact; see https://github.com/smallstep/truststore).
Probably some open source tools for this to set it up your self for free.
I have two devices, but I will never use them at the same time (and if I do by accident, I'd expect your software to stop working).
We don't do anything with mDNS though but we've thought about it; none of us use macs anymore but PRs are welcome to make that work. I don't have enough expertise with mDNS to confidently implement it myself, and especially less-so because the implementation would be different on every OS (needs build flags to change the implementation depending on the build target). And this would be free and open source, rather than this paid product.
You could probably lean on existing software to do most of the work.
That said, the tricky part to Windows' mDNS support is that the APIs to work with it are WinRT-only and you'll need a WinRT projection of one sort or another to use them.
I assume that's the case, but want to check I understand correctly.
Instead, pay $19 (instead of $29!) excl. VAT for a service that does this for you! God damn, I hate this industry.
Edit: I'm not trying to shame MacOS users. I'm just saying that Linux and MacOS users (Windows users don't use /etc/hosts so out of discussion) have very different behaviour regarding paying for software.
I've personally struggled to test https locally [1], and I'm sure others have too. The next time I have the problem, though, I'll save myself the configuration and spend $19.
[1] https://www.louzell.com/notes/serve_https_on_localhost.html
C:\Windows\System32\drivers\etc\hosts
$19 is only a couple minutes worth of engineering labour.
This is actually useful if you're running multiple servers on your network and don't want to remember the IPs of every single one of them. And not having to set up HTTPS for every single one of them is a plus.
Also you pay this once, this isn't some recurring charge every 10 minutes.
Obviously you’re not paying $19 for hosts file editing. Obviously! SSL cert generation is a pain in the ass, a tool that automates all of that for you is a valid tool. And I find the mDNS stuff really interesting, I do a lot of testing on mobile devices and connecting to my dev server from a phone can be really annoying.
If you don’t like the price that’s fine: don’t pay it. The market will decide whether this price is appropriate or not. An independent developer has made a tool that scratches their personal itch and made it available for others to use for a fee. And gets heaped with scorn for it. This place is an absolute cesspit sometimes.
In a professional context time is money. Setting up everything you’re discussing takes time and would need tweaking every time my network changes (not to mention require router access). $19 a year is a rounding error in terms of developer expenses. It’s entirely legitimate to pay for a tool to just do it for you.
Smart Alec replies are one thing but badly thought out Smart Alec replies contribute so very little.
mDNS is a QoL feature I am not sure is that useful.
I don't know that I'd buy this if I still had a mac, but I do think that paying for quality of life improvements can be worthwhile. For example, I do pay for a license of IntelliJ idea, even though VSCode costs $0, and I'm not even a full-time software dev.
Why?
Just switch to Linux and you will never ever had to deal with this weird stuff agian!
https://doc-kurento.readthedocs.io/en/latest/knowledge/selfs...
Should probably be a blog post. Would be happy to get comments on improvements or updates to the explained process. For now, I already gathered that Android seems to have finally added mDNS resolution support, which is nice as a whole Note banner can then be removed from that page. I also took note that maybe the whole thing can be simplified greatly with Caddy, albeit I think that getting into explaining mkcert is useful for readers who are new to that stuff and don't know how to generate their own SSL certs (like myself a month before writing all that).
The https://news.ycombinator.com/user?id=jarekceborski account was created 1 day ago, the only submission is this one https://news.ycombinator.com/user?id=jarekceborski and the only comments are on this submission https://news.ycombinator.com/threads?id=jarekceborski
Do I personally care? No. Am I bothered by the submission? Also no.
Still, downvoting you doesn't seem all that fair since you do raise a valid point.
It's not an insinuation. The submission author literally said: "I'm Jarek, and I've built this tool". It's an undeniable fact that the submitter is self-promoting. There's no mistake.
The submitter's profile also shows irrefutably that the HN account has never been used for anything except self-promotion.
Another problem is that it's not clear the submission is even on topic for Show HN. Is there anything that HN users can try? It just seems to be a "Buy" page. https://news.ycombinator.com/showhn.html
Every spammer is N=1.
> We don't know if the submitter has other active accounts that aren't in their real name.
That would be yet another HN guidelines violation: "Throwaway accounts are ok for sensitive information, but please don't create accounts routinely." https://news.ycombinator.com/newsguidelines.html
> If they are new to this site, can we be more welcoming?
Would you say the same to all spammers?
> This is cool content and made the front page.
There are a lot of cool paid products in the world. You're giving permission for everyone to just post their own "Buy" page here. That's not what HN is for. I'm a software developer myself, and while I have submitted some of my technical blog posts, I've never just submitted my product marketing pages.
And as I said in another comment, this shouldn't even be a "Show HN" post: https://news.ycombinator.com/item?id=36959608
https://news.ycombinator.com/from?site=localcan.com
bar-192-168-1-1.traefik.me
http://traefik.me/fullchain.pem
http://traefik.me/privkey.pem
However, given that allowing private IP resolution from a public DNS subdomain facilitates DNS rebinding attacks, it (and all equivalent approaches) will unfortunately be blocked by quite a few of the more sophisticated home routers out there, including a quite common brand in Germany.
Also, doesn't publishing a privkey for a public TLS certificate theoretically require it to be revoked under common browser CA standards...? Let's Encrypt seems to support it, at least: https://letsencrypt.org/docs/revoking/#using-the-certificate...
https://crt.sh/?id=9497801989&opt=ocsp
Update: Seems to have just happened – after restarting, Firefox now does not accept it anymore!
Right.
Why would you edit a local file (or create a record on your own local DNS), generate your own self-signed certificate, and immediately get a website that can be tested on your machine, on your local network or on your VPN, when you can pay someone $19 per device (MacOS only) for something less powerful?
I understand that everybody needs to make money for a living, but this seems like the digital equivalent of bottling tap water and asking people to pay for it.
That's intended as a criticism, but bottled water is a $300B market in the US alone. Most of which is tap water.
https://www.latimes.com/business/story/2021-09-28/bottled-wa...
Very clever, if I weren’t leaving the industry I would for sure grab a copy.
https://github.com/FiloSottile/mkcert
I've been working on getlocalcert[1] which explores this problem from the other end; how can we make TLS certificate management and trust root distribution easier? There's lots of interest in using certificates issued by public CAs for private domains. Especially the free ones from Let's Encrypt. This completely avoids trust root distribution challenges and concerns about trust roots being used to MITM traffic. My local DNS management story is admittedly currently a hand-wave[2], but I really like your approach. I was hoping we could pair our tools, but I think mDNS is for .local only, so we won't be compatible.
I'm curious about the trust root you're using. Lots of tools will create these without any nameConstraints, which is reasonable as client-side support has historically been poor[3], but restricting the root and any intermediaries to *.local can reduce the risk that a stolen trust root is used to MITM unrelated sites like google.com.
[1] https://www.getlocalcert.net/
[2] https://docs.getlocalcert.net/dns/
[3] https://alexsci.com/blog/name-non-constraint/
[1] https://linux.die.net/man/5/avahi-daemon.conf