Too many letters.
.INTERNAL is now reserved for private-use applications
241–250 of 290 posts
Re: .INTERNAL is now reserved for private-use applications
#242Earlier quoted context omitted.
Sounds like you need to get better reverse proxies...? Making your site traffic RELY on the fact that you're using different certificates for different hosts sounds fragile as hell and it's just setting yourself up for even more pain in the future
It was the latest nginx at the time. I actually found a rather obscure issue on Github that touches on this problem, for those who are curious: https://github.com/kubernetes/ingress-nginx/issues/1681#issu... > We discovered a related issue where we have multiple ssl-passthrough upstreams that only use different hostnames. [...] nginx-ingress does not inspect the connection after the initial handshake - no matter if t…
That's a misunderstanding in your use of this ingress-controller "ssl-passthrough" feature.
> This feature is implemented by intercepting all traffic on the configured HTTPS port (default: 443) and handing it over to a local TCP proxy. This bypasses NGINX completely and introduces a non-negligible performance penalty.
> SSL Passthrough leverages SNI and reads the virtual domain from the TLS negotiation
So if you want multiple subdomains handled by the same ip address and using the same wildcard TLS cert, and chrome re-uses the connection for a different subdomain, nginx needs to handle/parse the http, and http-proxy to the backends. In this ssl-passthrough mode it can only look at the SNI host in the initial TLS handshake, and that's it, it can't look at the contents of the traffic. This is a limitation of http/tls/tcp, not of nginx.
Re: .INTERNAL is now reserved for private-use applications
#243Earlier quoted context omitted.
My frustration is because using a private CA is more difficult than it should be. You can't just add the CA to system trust stores on each device, because some applications, notably browsers and java, use their own trust stores, you have to add it to. You also can't scope the CA to just .internal, which means in a BYOD environment, you have to require your employees to trust you not to sign certs for other domains. A…
The Name Constraints extension can limit the applicability of a CA cert to certain subdomains or IP addresses.
How well supported is that?
Re: .INTERNAL is now reserved for private-use applications
#244Earlier quoted context omitted.
You’re basically saying that .internal can cause frustration when it is used without good reason. Fair enough, but also not surprising. When it is used for the intended reasons though, then there’s just no other solution. It’s a trade-off between conflicting goals. “Simply do X instead” doesn’t remove the trade-off.
What do you see as the intended reasons with no other solutions?
The reasons are explained in https://itp.cdn.icann.org/en/files/security-and-stability-ad....
Re: .INTERNAL is now reserved for private-use applications
#245Earlier quoted context omitted.
You’re basically saying that .internal can cause frustration when it is used without good reason. Fair enough, but also not surprising. When it is used for the intended reasons though, then there’s just no other solution. It’s a trade-off between conflicting goals. “Simply do X instead” doesn’t remove the trade-off.
What do you see as the intended reasons with no other solutions?
As a side point, there _needs_ to be something equivalent. People were doing all sorts of bad ideas before, and they had all the problems of .internal as well as the additional problems the hacks were causing -- like using .dev and then dealing with the fallout when the TLD was registered.
Re: .INTERNAL is now reserved for private-use applications
#246Earlier quoted context omitted.
Just use wildcard certs and internal subdomains remain internal information.
A fun tale about wildcard certificates for internal subdomains: The browser will gladly reuse an http2 connection with a resolved IP address. If you happen to have many subdomains pointing to a single ingress / reverse proxy that returns the same certificate for different Host headers, you can very well end up in a situation where the traffic will get messed up between services. To add to that - debugging that stuff…
There is definitely that. There is also some sort of strange bug with Chromium based browsers where you can get a tab to entirely fail making a certain connection. It will not even realize it is not connecting properly. That tab will be broken for that website until you close that tab and open a new one to navigate to that page.
If you close that tab and bring it back with command+shift+t, it still will fail to make that connection.
I noticed sometimes it responds to Close Idle Sockets and Flush Socket Pools in chrome://net-internals/#sockets.
I believe this regression came with Chrome 40 which brought H2 support. I know Chrome 38 never had this issue.
Re: .INTERNAL is now reserved for private-use applications
#247Earlier quoted context omitted.
.example is used for examples in documentation and stuff like that. .invalid means that a domain name is required but a valid name should not be used; for example, a false email address in a "From:" header in Usenet, to indicate that you cannot send email to the author in this way. .test is for a internal testing use, of DNS and other stuff. .localhost is for identifying the local computer. .internal is (presumably)…
Have a look at .ALT https://www.rfc-editor.org/rfc/rfc9476.html
I did not know about that; thank you for mentioning that to me
Re: .INTERNAL is now reserved for private-use applications
#248[flagged]
Re: .INTERNAL is now reserved for private-use applications
#249Is there an appliance or offline service to setup a private CA, do secure remote attestation, and issue certificates only to authenticated peers? Also preferably with fido2 support for administrative purposes.
Re: .INTERNAL is now reserved for private-use applications
#250Earlier quoted context omitted.
To inspect your own traffic you can use SSLKEYLOGFILE and then load it into wireshark.
Most apps don't support SSLKEYLOGFILE. OpenSSL, the most popular TLS library, doesn't support it.
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.