←back to thread

563 points joncfoo | 2 comments | | HN request time: 0.407s | source
Show context
8organicbits ◴[] No.41205729[source]
My biggest frustration with .internal is that it requires a private certificate authority. Lots of organizations struggle to fully set up trust for the private CA on all internal systems. When you add BYOD or contractor systems, it's a mess.

Using a publicly valid domain offers a number of benefits, like being able to use a free public CA like Lets Encrypt. Every machine will trust your internal certificates out of the box, so there is minimal toil.

Last year I built getlocalcert [1] as a free way to automate this approach. It allows you to register a subdomain, publish TXT records for ACME DNS certificate validation, and use your own internal DNS server for all private use.

[1] https://www.getlocalcert.net/

replies(12): >>41206030 #>>41206106 #>>41206231 #>>41206513 #>>41206719 #>>41206776 #>>41206828 #>>41207112 #>>41208240 #>>41208353 #>>41208964 #>>41210736 #
yjftsjthsd-h ◴[] No.41206513[source]
Do you mean to say that your biggest frustration with HTTPS on .internal is that it requires a private certificate authority? Because I'm running plain HTTP to .internal sites and it works fine.
replies(6): >>41206577 #>>41206657 #>>41206669 #>>41208198 #>>41208358 #>>41210486 #
j1elo ◴[] No.41206657[source]
Try running anything more complicated than a plain and basic web server! See what happens if you attempt to serve something that browsers deem to require a mandatory "Secure Context", so they will reject running it when using HTTP.

For example, you won't be able to run internal videocalls (no access to webcams!), or a web page able to scan QR codes.

Here's the full list:

* https://developer.mozilla.org/en-US/docs/Web/Security/Secure...

A true hassle for internal testing between hosts, to be honest. I just cannot run an in-development video app on my PC and connect from a phone or laptop to do some testing, without first worrying about certs at a point in development where they are superfluous and a loss of time.

replies(1): >>41206727 #
akira2501 ◴[] No.41206727[source]
localhost is a secure context. so.. presumably we're just waiting for .internal to be added to the white list.
replies(4): >>41206781 #>>41208009 #>>41208879 #>>41208887 #
Too ◴[] No.41208009[source]
No. The concept of a DMZ died decades ago. You could still be MITM within your company intranet. Any system designed these days should follow zero-trust principles.
replies(2): >>41208347 #>>41213871 #
tsimionescu ◴[] No.41208347[source]
Sure, but people still need to test things, and HTTPS greatly complicates things. Browsers' refusal to make it poasible to run anything unencrypted when you know what you're doing is extremely annoying, and has caused significant losses of productivity throughout the industry.

If they're so worried about users getting duped to activate the insecure mode, they could at least make it a compiler option and provide an entirely separate download in a separate place.

Also, don't get me started on HSTS and HSTS preloading making it impossible to inspect your own traffic with entities like Google. It's shameful that Firefox is even more strict about this idiocy than Chrome.

replies(2): >>41208716 #>>41210024 #
the8472 ◴[] No.41208716[source]
To inspect your own traffic you can use SSLKEYLOGFILE and then load it into wireshark.
replies(1): >>41208907 #
tsimionescu ◴[] No.41208907[source]
Most apps don't support SSLKEYLOGFILE. OpenSSL, the most popular TLS library, doesn't support it.
replies(1): >>41211234 #
1. haradion ◴[] No.41211234[source]
OpenSSL does provide a callback mechanism to allow for key logging, but the application does have to opt in. IIRC, at least Curl does support it by default.
replies(1): >>41212039 #
2. tsimionescu ◴[] No.41212039[source]
Yes, there are ways to do keylogging with OpenSSL. Even if the app doesn't support it, you can do it with LD_PRELOAD and external libraries that call those callbacks. But it's still a whole lot more work than just an env var, and then just not having all these problems in the first place, by avoiding unnecessary encryption. And it probably won't work on mobile.