Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s5tbO-008pun-Tq for pgsql-hackers@arkaria.postgresql.org; Sat, 11 May 2024 20:45:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1s5tbL-0077TG-Ju for pgsql-hackers@arkaria.postgresql.org; Sat, 11 May 2024 20:45:51 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s5tbL-0077T8-A6 for pgsql-hackers@lists.postgresql.org; Sat, 11 May 2024 20:45:51 +0000 Received: from mail-yw1-f172.google.com ([209.85.128.172]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s5tbG-000XIW-MW for pgsql-hackers@lists.postgresql.org; Sat, 11 May 2024 20:45:50 +0000 Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-61ae4743d36so32637677b3.2 for ; Sat, 11 May 2024 13:45:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715460345; x=1716065145; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=clvOoM2zGzSRNpRahY9nzptR0T3aEw7G18Vuf2mA/W8=; b=QDMOXi6e0SqMPQmipKFHZKwhOZEyjoAbuwp2FCst6DpWmlGv40vSaPTqj8yzBPHDQx Yo6n1NskMK5XFQFwTx3gLSYuGf1bDIif+a0CFGVDUNEiLg01p3fQEQuxVaKQTs0j/qUv 2zrCfMHFX5YA2j2A94flw7BKPk0NsF66N4FVEti8LahtWlZY4Jg0HJFXo9y6nZiRt9xG kMeMDNHVqwjORjZlA6fH2/FITjcyuZtuqE8zcnTd/6+ITcavoGllcQZW41r2ri44GdHl 2mxwEx/VBohF5UlPUZYG+ye7qJ8fGLcw+mwJZqUMTE7AUUJlJj80WejsvXFdqvQhZYTw 2x9A== X-Forwarded-Encrypted: i=1; AJvYcCXo/jWJ8CMY3+80cO9SzxpJp/jTFLBeOgH4wNPZUWj5u4znonDmw63rO6tbMXZsqf0JUsOjjBc+2amnOTkrl7ZxlIlQzS8+vZgCSasmtEGQlq05 X-Gm-Message-State: AOJu0Yw7sxnBKv0BgK8wkaiRIZC0TRy8gI7ThToJ/5aPvlkUuy/molQ/ bY6puSfz56stjh6n/3VujYOl1QU06J4SKNiieyVL/lOZkf5Melu4Kel9aFpf6jCk38HSTh5jUDl tesasB5cPZShz5AZHjTIiIXz1W2wToDlnnPzZAQ== X-Google-Smtp-Source: AGHT+IF3VCTmKg+XPadO3w8FOla2X5vENLpsoEyq4deNDxaA8CMKt3Kg33nMAEgt2pM1ogrnG5zR6+18W607B0xwk40= X-Received: by 2002:a25:9f84:0:b0:dd0:bb34:1e77 with SMTP id 3f1490d57ef6-dee4f332e5bmr5041792276.53.1715460345193; Sat, 11 May 2024 13:45:45 -0700 (PDT) MIME-Version: 1.0 References: <5a79ed71-b365-4b20-80bc-9c2bf97bf84b@iki.fi> <3a6f126c-e1aa-4dcc-9252-9868308f6cf0@iki.fi> <1a717f65-7390-4111-8efd-c6e9b213805e@iki.fi> In-Reply-To: From: Jelte Fennema-Nio Date: Sat, 11 May 2024 22:45:38 +0200 Message-ID: Subject: Re: Direct SSL connection with ALPN and HBA rules To: Heikki Linnakangas Cc: Jacob Champion , Daniel Gustafsson , Robert Haas , Michael Paquier , Postgres hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, 10 May 2024 at 15:50, Heikki Linnakangas wrote: > New proposal: > > - Remove the "try both" mode completely, and rename "requiredirect" to > just "direct". So there would be just two modes: "postgres" and > "direct". On reflection, the automatic fallback mode doesn't seem very > useful. It would make sense as the default, because then you would get > the benefits automatically in most cases but still be compatible with > old servers. But if it's not the default, you have to fiddle with libpq > settings anyway to enable it, and then you might as well use the > "requiredirect" mode when you know the server supports it. There isn't > anything wrong with it as such, but given how much confusion there's > been on how this all works, I'd prefer to cut this back to the bare > minimum now. We can add it back in the future, and perhaps make it the > default at the same time. This addresses points 2. and 3. above. > > and: > > - Only allow sslnegotiation=direct with sslmode=require or higher. This > is what you, Jacob, wanted to do all along, and addresses point 1. > > Thoughts? Sounds mostly good to me. But I think we'd want to automatically increase sslmode to require if it is unset, but sslnegotation is set to direct. Similar to how we bump sslmode to verify-full if sslrootcert is set to system, but sslmode is unset. i.e. it seems unnecessary/unwanted to throw an error if the connection string only contains sslnegotiation=direct