diff options
Diffstat (limited to 'cmd/pgproxy/README.md')
| -rw-r--r-- | cmd/pgproxy/README.md | 84 |
1 files changed, 42 insertions, 42 deletions
diff --git a/cmd/pgproxy/README.md b/cmd/pgproxy/README.md index 2e013072a..a867ad8ca 100644 --- a/cmd/pgproxy/README.md +++ b/cmd/pgproxy/README.md @@ -1,42 +1,42 @@ -# pgproxy - -The pgproxy server is a proxy for the Postgres wire protocol. [Read -more in our blog -post](https://tailscale.com/blog/introducing-pgproxy/) about it! - -The proxy runs an in-process Tailscale instance, accepts postgres -client connections over Tailscale only, and proxies them to the -configured upstream postgres server. - -This proxy exists because postgres clients default to very insecure -connection settings: either they "prefer" but do not require TLS; or -they set sslmode=require, which merely requires that a TLS handshake -took place, but don't verify the server's TLS certificate or the -presented TLS hostname. In other words, sslmode=require enforces that -a TLS session is created, but that session can trivially be -machine-in-the-middled to steal credentials, data, inject malicious -queries, and so forth. - -Because this flaw is in the client's validation of the TLS session, -you have no way of reliably detecting the misconfiguration -server-side. You could fix the configuration of all the clients you -know of, but the default makes it very easy to accidentally regress. - -Instead of trying to verify client configuration over time, this proxy -removes the need for postgres clients to be configured correctly: the -upstream database is configured to only accept connections from the -proxy, and the proxy is only available to clients over Tailscale. - -Therefore, clients must use the proxy to connect to the database. The -client<>proxy connection is secured end-to-end by Tailscale, which the -proxy enforces by verifying that the connecting client is a known -current Tailscale peer. The proxy<>server connection is established by -the proxy itself, using strict TLS verification settings, and the -client is only allowed to communicate with the server once we've -established that the upstream connection is safe to use. - -A couple side benefits: because clients can only connect via -Tailscale, you can use Tailscale ACLs as an extra layer of defense on -top of the postgres user/password authentication. And, the proxy can -maintain an audit log of who connected to the database, complete with -the strongly authenticated Tailscale identity of the client. +# pgproxy
+
+The pgproxy server is a proxy for the Postgres wire protocol. [Read
+more in our blog
+post](https://tailscale.com/blog/introducing-pgproxy/) about it!
+
+The proxy runs an in-process Tailscale instance, accepts postgres
+client connections over Tailscale only, and proxies them to the
+configured upstream postgres server.
+
+This proxy exists because postgres clients default to very insecure
+connection settings: either they "prefer" but do not require TLS; or
+they set sslmode=require, which merely requires that a TLS handshake
+took place, but don't verify the server's TLS certificate or the
+presented TLS hostname. In other words, sslmode=require enforces that
+a TLS session is created, but that session can trivially be
+machine-in-the-middled to steal credentials, data, inject malicious
+queries, and so forth.
+
+Because this flaw is in the client's validation of the TLS session,
+you have no way of reliably detecting the misconfiguration
+server-side. You could fix the configuration of all the clients you
+know of, but the default makes it very easy to accidentally regress.
+
+Instead of trying to verify client configuration over time, this proxy
+removes the need for postgres clients to be configured correctly: the
+upstream database is configured to only accept connections from the
+proxy, and the proxy is only available to clients over Tailscale.
+
+Therefore, clients must use the proxy to connect to the database. The
+client<>proxy connection is secured end-to-end by Tailscale, which the
+proxy enforces by verifying that the connecting client is a known
+current Tailscale peer. The proxy<>server connection is established by
+the proxy itself, using strict TLS verification settings, and the
+client is only allowed to communicate with the server once we've
+established that the upstream connection is safe to use.
+
+A couple side benefits: because clients can only connect via
+Tailscale, you can use Tailscale ACLs as an extra layer of defense on
+top of the postgres user/password authentication. And, the proxy can
+maintain an audit log of who connected to the database, complete with
+the strongly authenticated Tailscale identity of the client.
|