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 1s6Guj-00BAba-7K for pgsql-hackers@arkaria.postgresql.org; Sun, 12 May 2024 21:39:25 +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 1s6Guh-00DLiU-5C for pgsql-hackers@arkaria.postgresql.org; Sun, 12 May 2024 21:39:23 +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 1s6Gug-00DLiM-Mc for pgsql-hackers@lists.postgresql.org; Sun, 12 May 2024 21:39:23 +0000 Received: from meesny.iki.fi ([195.140.195.201]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s6GuZ-000ghz-DC for pgsql-hackers@lists.postgresql.org; Sun, 12 May 2024 21:39:21 +0000 Received: from [192.168.1.115] (dsl-hkibng22-54f8db-125.dhcp.inet.fi [84.248.219.125]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: hlinnaka) by meesny.iki.fi (Postfix) with ESMTPSA id 4Vcwx94Pr7zyRw; Mon, 13 May 2024 00:39:08 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1715549951; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jyieHMnuuXbnaWa+LW6xdJopsFUl61hsnJtnEdmsSZ8=; b=NZ8vEIOnPrLPRmpZDIJauwYw3FjFuDclgMW6JQDj12mNr5El/D0RpeCImEJatnF4NHN4Mo JeM44r00gT2yzvZTx75DP+N8wJuEQvm6ToYOMUWSI7d3MFVaVWZYxlXyhOvIWMLW5sD08j cS2I9puQJPHJY7N6Jt8rsBEB9wAyRkw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1715549951; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jyieHMnuuXbnaWa+LW6xdJopsFUl61hsnJtnEdmsSZ8=; b=LbTxPBsewP8xozFnTMDJfRdMnRDPKUCC73GEH7G0SDHKrl0gXwUGcKfvUod7zCG/cCKcqX UalZ6VW9HoAExmCZSWiGsW0YNvQ8D+ad/U14QwBEMuU7wCAe2OX7nH8p9pV+Sd5IPYx1xS pa6ATI9Z2U5gzB68wZLvIsWsgrsmIoM= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=hlinnaka smtp.mailfrom=hlinnaka@iki.fi ARC-Seal: i=1; s=meesny; d=iki.fi; t=1715549951; a=rsa-sha256; cv=none; b=MAaWyxKxQH+RVkDzOS7Abu8oOFo6iQwCNx/7I9sY9iaobp9fGR9pdmVP009Wde7ivfIKRR TRO6bXO61bvCAs44s7FN9r692l/zeI1U/+OtKW6kjt6BYYwPPHgcGUlBdlmMOdS5bAVr/E 3XyTA0WBEYD79SJ9z4TVwWuxwcw3yVY= Message-ID: Date: Mon, 13 May 2024 00:39:07 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Direct SSL connection with ALPN and HBA rules To: Jelte Fennema-Nio Cc: Jacob Champion , Daniel Gustafsson , Robert Haas , Michael Paquier , Postgres hackers References: <5a79ed71-b365-4b20-80bc-9c2bf97bf84b@iki.fi> <3a6f126c-e1aa-4dcc-9252-9868308f6cf0@iki.fi> <1a717f65-7390-4111-8efd-c6e9b213805e@iki.fi> Content-Language: en-US From: Heikki Linnakangas In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 11/05/2024 23:45, Jelte Fennema-Nio wrote: > 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 I find that error-prone. For example: 1. Try to connect to a server with direct negotiation: psql "host=foobar dbname=mydb sslnegotiation=direct" 2. It fails. Maybe it was an old server? Let's change it to sslnegotiation=postgres. 3. Now it succeeds. Great! You might miss that by changing sslnegotiation to 'postgres', or by removing it altogether, you not only made it compatible with older server versions, but you also allowed falling back to a plaintext connection. Maybe you're fine with that, but maybe not. I'd like to nudge people to use sslmode=require, not rely on implicit stuff like this just to make connection strings a little shorter. I'm not a fan of sslrootcert=system implying sslmode=verify-full either, for the same reasons. But at least "sslrootcert" is a clearly security-related setting, so removing it might give you a pause, whereas sslnegotition is about performance and compatibility. In v18, I'd like to make sslmode=require the default. Or maybe introduce a new setting like "encryption=ssl|gss|none", defaulting to 'ssl'. If we want to encourage encryption, that's the right way to do it. (I'd still recommend everyone to use an explicit sslmode=require in their connection strings for many years, though, because you might be using an older client without realizing it.) -- Heikki Linnakangas Neon (https://neon.tech)