tailscale / tailscale

The easiest, most secure way to use WireGuard and 2FA.
https://tailscale.com
BSD 3-Clause "New" or "Revised" License
17.22k stars 1.31k forks source link

FR: support using self-signed ip-only certificate in custom DERP server #11776

Closed networkhermit closed 4 weeks ago

networkhermit commented 1 month ago

What are you trying to do?

Not everyone has a domain name plus dns hosting. It's more accessible for users if we support using self-signed ip-only certificate in custom DERP server (just like k8s 6443 tls).

This issue had been brought up by #3647 and partially in #4082.

This feature is kind of implemented by a fork, ip_derper (which is regularly updated and just adding the patch for ip-based certificates):

https://github.com/yangchuansheng/ip_derper/blob/936de2789923d81b9eab538b50f124110dee6f9b/.github/workflows/main.yml#L21-L24

      - name: modify
        run: |
          cd tailscale
          sed -i '/hi.ServerName != m.hostname/,+2d' cmd/derper/cert.go

The above modification is not ideal for users who want to use domain-based tls certificates. I think some more appropriate minor fix could be the following: https://github.com/tailscale/tailscale/blob/226486eb9ae90a32c3bb6857b9dbc3dec605597c/cmd/derper/cert.go#L90-L93

 func (m *manualCertManager) getCertificate(hi *tls.ClientHelloInfo) (*tls.Certificate, error) {
-       if hi.ServerName != m.hostname {
+       if hi.ServerName != m.hostname && !(hi.ServerName == "" && net.ParseIP(m.hostname) != nil) {
                return nil, fmt.Errorf("cert mismatch with hostname: %q", hi.ServerName)
        }

So we could support well both domain-based certificates and the ip-based ones.

How should we solve this?

No response

What is the impact of not solving this?

Separate fork keeps patching this feature and some users fallback to that.

Anything else?

No response

bradfitz commented 4 weeks ago

Sorry, but this isn't a use case we want to support.

You're welcome to modify the Tailscale client or derper code for your own use.

networkhermit commented 4 weeks ago

Could you elaborate a bit more? As this feature is regularly brought up by other users.

If the official reponse to this feature is "make your own fork", then related issues in the future could get linked to the explanation.

bradfitz commented 4 weeks ago

People running their own DERP servers is a constant source of support costs for us. We provide the source code for transparency reasons and in theory it saves us money if people run their own, and it's better for users if their DERP servers are lower latency and close to them. So we do, and it's open source, and we support custom DERP servers.

And yet: so many people run them in bizarre unsupported ways and come to us for help, which we spend lots of time helping with.

We do not want yet another possible configuration to support and maintain in the code base, especially for something so fringe: LetsEncrypt is free, and domain names are often nearly free. So I'm skeptical there's enough demand for this feature to justify the various costs.

itsalongstory commented 1 day ago

LetsEncrypt is free, and domain names are often nearly free. So I'm skeptical there's enough demand for this feature to justify the various costs.

In some countries, domains without an ICP license are not permitted to provide web services. For individual users, obtaining an ICP license can be extremely cumbersome.

https://en.wikipedia.org/wiki/ICP_license

For these users, supporting deployment of self-signed certificates based on IP would be extremely convenient.