5 ms·
Because HTTPS is not as easy as HTTP. Sure there is Let's Encrypt and if you are facing Internet you are probably good to go. If you are on an internal networ
by BrandoElFollito 7y ago
Because HTTPS is not as easy as HTTP.
Sure there is Let's Encrypt and if you are facing Internet you are probably good to go.
If you are on an internal network, then good luck. You need to build a PKI, and then put into your devices the right certificate so that it is trusted.
If it was simpler, Apache would sing out its "It works!" in HTTPS and not HTTP.
- zurn 7y agoLet's Encrypt works on internal networks too. Fun fact: TLS doesn't require certificates, and some browsers even used to support HTTPS in these TLS modes many moons ago. See eg https://security.stackexchange.com/questions/23024/can-diffie-hellman-anonymous-be-used-as-a-cipher-for-ssl-for-one-way-certifiate#23025 https://security.stackexchange.com/questions/23024/can-diffi...
- BrandoElFollito 7y agoAh? That's good to know! How to set this up on a domain which is not connected to Internet? How is the check done?
- benoliver999 7y agoIt's not easy but iirc you can do it with a DNS-01 challenge, if your internal domain name is valid (doesn't have to resolve to anything though).
- BrandoElFollito 7y agoThe problem is that I also have domains which are completely internal, not known/resolvable outside
- cheschire 7y agoCould you run an internal CA server instead of self signing? At least then you reduce your attack surface if you’re compromised internally.
- BrandoElFollito 7y agoYes, this is what is being done today. My point was that HTTPS is (much) more complicated than bare HTTP and this is probably one of the reasons it is not taking over the web in a storm (though progress is undoubtedly there)
- tialaramex 7y agoThis is probably a bad idea and I'd recommend migrating off such names as a background task. Realistically you can't entirely deconflict these names. So you always have a risk of shadowing names from the public Internet. The public CAs spent years in denial over this (yes they used to sell publicly trusted certs for "private" names, this is now prohibited). Create internal.example.com and things get easier. To the extent security by obscurity is worth trying it's just as available this way (split horizon DNS etcetera)
- lixtra 7y ago> Realistically you can't entirely deconflict these names. So you always have a risk of shadowing names from the public Internet. It's totally save and legitimate for ycombinator to use secret.ycombinator.com on their intranet without telling anything about it to the outside internet.
- tialaramex 7y agoThose are names you own, and a CA will happily issue you certs for those names (but Let's Encrypt won't without a DNS record saying the name at least exists) The grandparent was, as I understand it, talking about names they don't own, for which you've no assurance somebody else won't own them (on the public Internet) tomorrow. This used to be very common, decades ago Microsoft even advised corporations to do it for their AD, but it's a bad idea.
- kuschku 7y agoWhat's with domains such as blubb.mysystem.local or foo.invalid? .invalid and .local are reserved domains and guaranteed to never be in use on the public internet - yet I can't get certificates for them
- zurn 7y agoIf you could get certificates for them, so could anyone else including your adversaries, since there is no system of ownership for them. It would be like issuing certs for https://192.168.1.1 https://192.168.1.1
- zurn 7y agoIt works over DNS. There is a lot written about it on the net, I don't have any specific recommended article.
- BrandoElFollito 7y agoI now how to do the check over DNS when the name is known outside - the problem is that I have my own internal domain not visible on Internet
- zurn 7y agoYou need a registered domain for this. It's a good idea for other reasons too.
- mook 7y agoLet's Encrypt only works on public domains that happen to not route externally. I can never (or at least, should never) get LE certificates for *.pikachu.local, but that's a perfectly valid hostname for a local machine.
- exhilaration 7y agoSo here's how I do it for internal network devices. I have a RaspberryPi running on 192.168.100.1 on my local network. On https://www.duckdns.org/ https://www.duckdns.org/ or whatever your favorite DNS provider is, I signed up for a free account and created myRaspberryPi.duckdns.org and pointed it to 192.168.100.1. While you're logged in, grab the DuckDNS API key. Next you need to use ACME or Caddy (I use the latter) and tell it to do the Let's Encrypt DNS challenge using DuckDNS. It looks like this for Caddy: # in the Caddyfile tls { dns duckdns } # in the CaddyEnvfile DUCKDNS_TOKEN=your-api-key-goes-here Then you start it like this: nohup caddy -http-port 80 -conf /etc/caddy/Caddyfile -envfile /etc/caddy/CaddyEnvFile -agree -email you@email.com & That's it, now I can go to https://myRaspberryPi.duckdns.org https://myRaspberryPi.duckdns.org and I've got HTTPS on my local network without anything exposed on the internet EXCEPT my device's internal IP. You've got to evaluate how much of a threat that is.
- fpgaminer 7y agoWouldn't this be subject to Let's Encrypt's rate limit of 50 certs per week for duckdns.org? Do they have an exception or are not enough people using this trick for it be a problem (yet)?
- exhilaration 7y agoThat is a really good point that I didn't consider.