11 ms·
Just want simple TLS for your .internal network?
- mike978 2y agoHow does this compare with smallstep step-ca certificates? https://github.com/smallstep/certificates https://github.com/smallstep/certificates
- nh2 2y agoI did some research, write-up and scripting about the state of X.509 Name Constraints, so that people you give your CA cert to don't need to trust you not to MitM them on other domains. Packaged into a convenient one-liner to create a wildcard cert under for the new .internal TLD. Please scrutinize! I use this to provide e.g. at home: https://octoprint.myhome.internal https://paperless.myhome.internal to provide transport encryption of these services in the local WiFi. Friends and family can add the CA root to their devices without having to worry about me MitM'ing their other connections.
- ulfbert_inc 2y agoNiklas, if you are reading this - it was a pleasure to interview with you some 6 (or so) years ago :) thanks for the script and the research, I will make use of it.
- nh2 2y agoThanks Vadzim, I remember -- happy to be useful :)
- vbezhenar 2y agoIs it possible to constrain existing CA? For example my government uses non-standard CA and some websites rely on it. But importing CA obviously makes them able to issue google.com and MITM me if they want to. And they already tried, so trust is broken. I imagine something like generating separate name-constrained certificate, sign existing CA with this name-constrained certificate (I think it's called cross-sign or something like that) and import things into OS, expecting that browser will use name-constraints of the "Root-Root" certificate. Could it work?
- deleted 2y ago[deleted]
- dinosaurdynasty 2y agoNamecoin has made utilities similar to this (in order to constrain all existing CAs from signing `.bit` domains) so I assume so.
- poincaredisk 2y agoYes, I do it in my work to restrict my company CA to company servers [1]. You generate your own CA, and cross sign other cert with any constraint you want. It works great, but requires some setup, and of course now you have your own personal CA to worry about. [1] Yes, company is ok with it, most of my team does it, and this makes everyone more secure. Win-win.
- dfox 2y agoI assume that the mentioned “some setup” involve not only distributing the new root CA, but also somehow prepopulating the old cross-signed certificate, as the services know nothing about that and thus will not send it in their cert chain. Or am I overlooking something?
- kassner 2y agoFrom the linked Netflix article: > The Trouble with Name Constraints > The Name Constraints extension lives on the certificate of a CA but can’t actually constrain what a bad actor does with that CA’s private key > Therefore, it is up to the TLS _client_ to verify that all constraints are satisfied > However, as we extended our test suite beyond basic tests we rapidly began to lose confidence. We created a battery of test certificates which moved the subject name between the certificate’s subject common name and Subject Alternate Name extension, which mixed the use of Name Constraint whitelisting and blacklisting, and which used both DNS names and IP names in the constraint. The result was that every browser (except for Firefox, which showed a 100% pass rate) and every HTTPS client (such as Java, Node.JS, and Python) allowed some sort of Name Constraint bypass. That’s the danger of any solution that requires trusting a self-signed CA. Better just trust the leaf certificate, maybe make it wildcard, so you only have to go through the trust-invalid-cert once?
- nh2 2y agoNote that statement is 7 years old, it prompted Netflix to make bettertls.com. The situation has improved since then, see the linked https://news.ycombinator.com/item?id=37544094 https://news.ycombinator.com/item?id=37544094
- deleted 2y ago[deleted]
- chgs 2y agoI wa t ti be able to import a cert into by browser and specify what to trust it for myself. “Only trust this cert for domain.com” did example. The name constraints can give me a hint what it’s designed for, but if I import a cert to MITM devsite.org, I don’t want that cert working for mybank.com.
- Havoc 2y agotbh the skill level require for a valid wildcard cert isn’t all that high either.
- kreetx 2y agoThis is about creating and using a domain-restricted CA, which is then used to create server certificates. Point being that your (tech savvy) friends are willing to install the CA because it can only ever validate some specific subdomains (and not MITM the entire internet).
- ndsipa_pomu 2y agoI prefer to assign an external name to an internal device and grab a free SSL cert from LetsEncrypt, but using DNS challenge instead as internal IP addresses aren't reachable by their servers.
- DandyDev 2y agoI do this as well, but be aware that these external names you're using for internal devices become a matter of public record this way. If that's okay for you (it is for me), then this is a good solution. The advantage is also that you run no risk of name clashes because you actually own the domain
- xfer 2y agoOr use a wildcard cert for all internal certs.
- ndsipa_pomu 2y agoThat could be a good idea, though it means that the certificate/key has to be well guarded.
- project2501a 2y agoPlease don't. Technical debt accumulates by force of practice.
- qwertox 2y agoIt's working good for me. My technical debt is to always make sure that I'm able to renew a certificate and that the distribution occurs successfully. I don't see how other solutions are less problematic.
- pridkett 2y agoThis is exactly what I do. After seeing how much of my internal network was exposed in certificate transparency logs, I noped out and just do a DNS challenge for a wildcard for almost everything. Now it’s have a nice script that distributes my key automatically to 20 or so hosts and apps and have a real SSL cert on everything from my UDM Pro to my Synology to random Raspberry Pis running containers. Most of which have domain names that only resolve on my local network. This is made possible by a fairly robust DNS setup that consists of not only giving A records to all my hosts automatically, but also adding in CNAMEs for services and blocking almost all outbound DNS, DNS over TLS, DoH, etc.
- dveeden2 2y agoVALIDITY_DAYS="3650" I'd rather see something with 90 days and ACME. Note sure why there isn't a simple certificate management tool that does this and maybe even brings a simple UI?
- juliuskiesian 2y agoHow does this compare to mkcert?
- kreetx 2y agomkcert might be getting this as well: https://github.com/FiloSottile/mkcert/pull/309/commits/922158ed6856077c8b07478d67e0a7a930b9051 https://github.com/FiloSottile/mkcert/pull/309/commits/92215... (this is linked from the current submission's readme)
- billpg 2y agoIs "name constraints" new? I wanted to do something similar a decade or two ago and found I'd have to be trusted for all domains, which I wanted to avoid.
- michaelt 2y agoIt's been around since ~2008 when rfc5280 was released. But it's long been stuck in a cycle of "CAs won't issue name-constrained certificates because not all clients support it properly" and "Clients don't bother to support it properly because CAs won't issue name-constrained certificates" And even if today's clients all support it properly - there will always be some users running ancient smart TVs and android phones that haven't received a software update in a decade.
- toast0 2y agoA decade ago, name constraints was available, but support wasn't really there. I was looking into making a company CA for internal tools, but I didn't want to be able to MITM employees going to unrelated sites, and I couldn't mandate specific browsers, so we ended up using a commercial CA for everything. It looks like support is fairly wide now, but you'd probably still need to test and confirm it works with all the tools you want, and there's still some risk to users in case the constraints don't catch everything.
- ninkendo 2y agoIf only there was a system to hint in DHCP (or a v6 RA) what certificate authority serves the .internal domain for the current network. Devices would treat .internal as special and would validate that the hinted CA only applied to that subdomain, and would only use that CA when connected to the corresponding network. Or maybe the DHCP/RA could hint at keys to use to validate DNSSEC for the internal DNS server, and the CA cert could live in a well-known TXT record… Then you could have all devices work with internal certs out of the box with no config. One can dream…
- globular-toast 2y agoI went down this path, but installing CA certificates is a pain. There isn't just one trust store per device, there are many. Make your own CA if want to find out how many there are... Like others I went with just having my own domain and getting real certs for things.
- egberts1 2y agoSo close, so close. Has everything, except the nigh to impossible DNSSEC-support for LAN; good stuff, nonetheless.
- klysm 2y agoBut a domain and use that for your internal network. You can use let’s encrypt and even get wildcard certs
- bluGill 2y agoLooks good, but I want to MitM my network. I want youtube.com to redirect to my internal server that only has a few approved videos. My kids do some nice piano lessons from youtube, but every time I let them they wait until I'm out of the room and then switch to something else. There are lots of other great educational videos on youtube, but also plenty to waste their time on. (I want this myself as well since I won't have ads on my internal youtube server - plus it will add an extra step and thus keep me from getting distracted to something that isn't a good use of my time to watch))
- EvanAnderson 2y ago> Looks good, but I want to MitM my network. Increasingly that kind of requirement puts you in the same camp as oppressive nation states. Being a network operator and wanting to MitM your DNS makes you a political actor. Devices you paid for, but don't actually own, will end-run your efforts by using their own hard-coded DNS servers. (See https://pc.nanog.org/static/published/meetings/NANOG77/2033/20191028_Vixie_Keynote_Dns_Wars__v1.pdf https://pc.nanog.org/static/published/meetings/NANOG77/2033/...)
- bluGill 2y agoFortunately I own my firewall. Though mostly I'm talking about linux machines that I own and control the software on. Though I fully understand I'm in the same camp as oppressive nation states. But until my kids get older I'm in charge, I need to set them up for success in life, which is a complex balance of letting them have freedom without allowing them to make too many bad decisions. Not getting their homework done because they are watching videos is on bad decisions I'm trying to prevent.
- throwway120385 2y agoImportantly, this is a reasonable thing to do because sites like Youtube are designed to draw their attention away from whatever important thing they're doing so that Youtube can serve them advertisements. So anyone thinking a parent trying to control what their kid watches is oppressive somehow is pretty deeply in the wrong. As a parent myself I would consider doing this to keep my son from falling into the traps that are set by giant multinational internet companies like Google to get him to form habits around Google instead of habits around what he wants or needs out of life. So really instead of thinking about this like "parents are acting like nation states" I think it's much better to think of it like "parents are countering corporate nation states."
- Wowfunhappy 2y agoIs there really any benefit of this over just using HTTP? What is the threat model in which an attacker could MitM your internal network?
- 8organicbits 2y agoI travel between networks with my phone and laptop. Software will ping out using whichever network I'm on, trying to connect to its backend. If I connect to hostile/compromised WiFi, those connections are at risk.
- feirlane 2y agoOn use-case I hit just recently is web apps hosted in my internal network, without https, Firefox won't allow me to click the "copy to clipboard" buttons on those pages
- poincaredisk 2y ago>What is the threat model in which an attacker could MitM your internal network? Police raid on your home/company. Malware on a router. Malicious actor in the server room. Possibilities are endless. SSL added and removed here ;-) (this is a reference, look it up if you don't recognize it)
- cesarb 2y ago> Malware on a router. It doesn't even have to be on the router, just the same network segment plus some ARP spoofing tricks (assuming your switch doesn't have ARP spoofing protections or they haven't been enabled) could be enough to MitM a connection.
- marginalia_nu 2y agoRouter malware is the one thing out of those thing that seem plausible. If you have physical access, TLS isn't much protection against eavesdropping. At that point they can just compromise your hardware instead.
- NotPractical 2y ago
- 8organicbits 2y agoA word of warning, client side support of name constraints may still be incomplete. I know it works on modern Firefox and Chrome, but there's lots of other software that uses HTTPS. This repo links to BetterTLS, which previously audited name constraint support, but BetterTLS only checked name constraint support at the intermediary certificates not at the trust anchors. I reported[1] the oversight a year back, but Netflix hasn't re-engineered the tests. Knowing how widely adopted name constraints are on the client side would be really useful, but I haven't seen a sound caniuse style analysis. Personally, I think the public CA route is better and I built a site that explores this[2]. [1] https://github.com/Netflix/bettertls/issues/19 https://github.com/Netflix/bettertls/issues/19 [2] https://www.getlocalcert.net/ https://www.getlocalcert.net/
- deleted 2y ago[deleted]
- christina97 2y agoDumb question: lots of folks are talking about name constraints not being understood by old clients since they don’t understand that extension. But is this not exactly the point of critical designation in extensions: is the client not supposed to fail if it comes across a critical extension it doesn’t understand?
- michaelt 2y agoFor one thing, the fact something's supposed to fail on unexpected input doesn't always mean it will fail. For another, some implementations thought they understood name constraints, but had bugs in their implementations. For example, applying name constraints correctly to the certificate's Subject Alternate Name but not applying them to the Common Name.
- dfox 2y agoAs for the overall X.509 ecosystem (not limited to name constraints), the certification validation logic of common clients accepts various subtly, but completely, invalid certificates because CAs used to sign (or even use as root certificate) various kinds of invalid certificates, one can probably even find a certificate, that should be logically trusted, but isn't even a valid DER encoding of the (TBS)Certificate.
- max_ 2y agoIs there a simple tutorial on how I can use the .internal domain for web applications within my own private network?
- deleted 2y ago[deleted]
- Am4TIfIsER0ppos 2y agoNo, why would I want that? Do I not trust my switches and routers to send the packets to the right host? Do I not trust my DNS to send the right address for the hostname? Do I not trust the other devices on the network to not be sniffing? Okay maybe that one. Browsers could stop with their false warnings about password forms being insecure then I'd be happy.
- nh2 2y agoARP, DHCP, DNS, are all unencrypted and spoofable protocols.
- Am4TIfIsER0ppos 2y agoBroadcast, broadcast, set by the previous. Question still is: do I trust the devices on my network?
- nh2 2y agoThat's a different question now. Before it was "do I not trust my switches and routers?". Now the question seems to be "do I trust all devices on my network?". If you have guests in your network, surely they have a different level fo trust. Anyway: If you trust _all_ devices on your network (including routers, PCs, phones, printers, light bulbs, air conditioners, thermostats, doorbells, scales, TVs, set-top boxes, coffee machines), and the software running on them to be bug-free, unrootkited unhackable, and upt-to-date, and their vendors to be perfectly honest and reliable, and those ones' employees, hardware, and software supply chain to be perfectly trustworthy, forever, then yes, you don't need any form of cryptography in your network. Otherwise, you need something like TLS for it to be secure.
- Am4TIfIsER0ppos 2y agoYeah I guess I did move the goalposts. Phones are a grey area. Printers and everything after are a no-no and people would be insane to connect them but the only people who know that are the only people who would use this or be capable of using this.
- rompledorph 2y agoI would like my public CA to sign me an intermediate certificate with my domain as named contraint. So I could use the built in trusted CAs
- jc__denton 2y agoOne headache I've had with internal LE certs is bots abusing the CT logs to attempt probing internal names. As a result, I started requesting wildcard certs from LE. Somehow that feels less secure, because even though I'd probably recognize abuse of the cert - friends and family wouldn't. It's the same reason I don't want less technically adept friends and family having to deal with my own CA. Install one arbitrary cert ... what's the problem with this random, sketch one I downloaded?
- cyberax 2y agoOne problem with wildcard certs is that any host can impersonate any host within the wildcard zone. It would be great to be able to get a certificate for an intermediary CA, that is limited to one domain. And then use this CA to issue certs as needed.
- speakspokespok 2y agoIf your audience is North American English speakers, on the login page, use "For the full experience". Using fullest in the context of 'lives life to the fullest' is grammatically correct but English is strange and for this context you'd want the former.
- xyst 2y agowonder if it's just better to not deal with name constraints and self signed certs. lets encrypt issues certs for domains with dns validation. so why wouldn't something like this work: - designate sub domain for private network usage (ie, *.internal.example.dev) - issue certificates using ACME compatible script/program (ie, lego) for devices (ie, dev1.internal.example.dev, dev2.internal.example.dev) don't have to deal with adding self signed certs to trust stores on devices. don't have to deal with messiness of name constraints compatibilities across apps. just plain ole TLS