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 1s6TXM-00CBGC-3H for pgsql-hackers@arkaria.postgresql.org; Mon, 13 May 2024 11:08:08 +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 1s6TXJ-0002e8-Q5 for pgsql-hackers@arkaria.postgresql.org; Mon, 13 May 2024 11:08:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s6TXJ-0002dz-DT for pgsql-hackers@lists.postgresql.org; Mon, 13 May 2024 11:08:05 +0000 Received: from lahtoruutu.iki.fi ([185.185.170.37]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s6TXB-000o2A-RO for pgsql-hackers@lists.postgresql.org; Mon, 13 May 2024 11:08:05 +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 lahtoruutu.iki.fi (Postfix) with ESMTPSA id 4VdGtM3zGvz49PyZ; Mon, 13 May 2024 14:07:53 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1715598476; 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=fvuuBopTb6exYf+3BreFeXgYyYEr9vyOa/kpLGsMMVE=; b=L6vvc9Y9sD2LpcJZCJtnV3iGWi+6scALd2CoqF/f/5ER5szAuj4SKcHWlRFkqx1kJugajR LQRqzO7ZNCbBa9tNziI/t3abcmeTwWNicdwNNkHofVv3QCzL011YpYdlkt11ApC9qESOQ1 0riCoXAWzWhCmT/zNWVA1UiZdmEo/1/OuqlMcOwgYuzdLYMkUpToEZrNmy0alNc5fllVbE aFj6Md8JSviGrT9z/FNjHZ/AN18VYtywHbsWjie2baB1bGxDfY30wcj6luRLq2OsOCOF/E r+EVPX3OsraQ+sX8C8OCYvPu1XoCSaSkOXVvC4wIsIfqg5U0ANPnglHaZNMpjg== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1715598476; a=rsa-sha256; cv=none; b=KnPgWx1CWpWU/0/AkSBtuJqpbT/6erxL/yVaUWCPY57ydETx8PQvddf/8me1olqT/VYtnL TOc2V4OohNX0MfwpXb4YYYfEgo78sTB4rXMgn3w5x9Xafl2DzEQglwVjRx6QAOgqMmrbpP jeoTYnA8BkEpN7DyIjWn3cwkqrvgwFZ2tBD3hoGKry2Y1py5x25uePqnBg42uKqfBin8eE U+eWvxfAZzEZ5dEcbdhGv/X+WlTj1KBx/ZE1A6T+188rU9Aatcr2mO+iIImy3KLjqZdUuY YI56W+Lk6itRG1vrD3Y6921tIUkO8LNpswH70Sb+P6bvNvsX8jwCsP+Bho4+jQ== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=hlinnaka smtp.mailfrom=hlinnaka@iki.fi ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1715598476; 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=fvuuBopTb6exYf+3BreFeXgYyYEr9vyOa/kpLGsMMVE=; b=ZEi8Nb5wHRpZHzcWI/JwJLGpNNo5RcI7HPVR+kBCUbUOh/ZIgOyGVT5u3srxq0ZHSn8jnd lKxryU01rRQH8K/sZOYvyfh8+dhSbdc/lYzJ6pI26rYJltjoJW+4GKqqOfZlHNeL64GiZR ihorMA/6PTpzQpOQbDMzGr0rpnshf0YORUq0AMO9MDi1H/dO5UZBNGvyEY118cR4rz8cYO sjuyFh/TsvCjuB/KzqqvLGe+Dz7B0R3aU1W9pmBXy0OY3edQ9AqdARyGB9U639yLlkICRm WVdsqzecnCciI3/Te8MDwd5QII9odldX5XwO1Rbhn9FTpY5VIN1RpoMLVzYGfA== Message-ID: Date: Mon, 13 May 2024 14:07:53 +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: <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 13/05/2024 12:50, Jelte Fennema-Nio wrote: > On Sun, 12 May 2024 at 23:39, Heikki Linnakangas wrote: >> 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.) > > I'm definitely a huge proponent of making the connection defaults more > secure. But as described above sslmode=require is still extremely > insecure and I don't think we gain anything substantial by making it > the default. I think the only useful secure default would be to use > sslmode=verify-full (with probably some automatic fallback to > sslmode=prefer when connecting to hardcoded IPs or localhost). Which > probably means that sslrootcert=system should also be made the > default. Which would mean that ~/.postgresql/root.crt would not be the > default anymore, which I personally think is fine but others likely > disagree. "channel_binding=require sslmode=require" also protects from MITM attacks. I think these options should be designed from the user's point of view, so that the user can specify the risks they're willing to accept, and the details of how that's accomplished are handled by libpq. For example, I'm OK with (tick all that apply): [ ] passive eavesdroppers seeing all the traffic [ ] MITM being able to hijack the session [ ] connecting without verifying the server's identity [ ] divulging the plaintext password to the server [ ] ... The requirements for whether SSL or GSS encryption is required, whether the server's certificate needs to signed with known CA, etc. can be derived from those. For example, if you need protection from eavesdroppers, SSL or GSS encryption must be used. If you need to verify the server's identity, it implies sslmode=verify-CA or channel_binding=true. If you don't want to divulge the password, it implies a suitable require_auth setting. I don't have a concrete proposal yet, but something like that. And the defaults for those are up for debate. psql could perhaps help by listing the above properties at the beginning of the session, something like: psql (16.2) WARNING: Connection is not encrypted. WARNING: The server's identity has not been verified Type "help" for help. postgres=# Although for the "divulge plaintext password to server" property, it's too late to print a warning after connecting, because the damage has already been done. A different line of thought is that to keep the attack surface as smal as possible, you should specify very explicitly what exactly you expect to happen in the authentication, and disallow any variance. For example, you expect SCRAM to be used, with a certificate signed by a particular CA, and if the server requests anything else, that's suspicious and the connection is aborted. We should make that possible too, but the above flexible risk-based approach seems good for the defaults. -- Heikki Linnakangas Neon (https://neon.tech)