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 1s6Zge-000RfY-GZ for pgsql-hackers@arkaria.postgresql.org; Mon, 13 May 2024 17:42:09 +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 1s6Zge-002zsP-EC for pgsql-hackers@arkaria.postgresql.org; Mon, 13 May 2024 17:42:08 +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 1s6Zge-002zrI-41 for pgsql-hackers@lists.postgresql.org; Mon, 13 May 2024 17:42:08 +0000 Received: from mail-yb1-f172.google.com ([209.85.219.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 1s6Zgb-00026x-6d for pgsql-hackers@lists.postgresql.org; Mon, 13 May 2024 17:42:06 +0000 Received: by mail-yb1-f172.google.com with SMTP id 3f1490d57ef6-de5ea7edb90so4744431276.1 for ; Mon, 13 May 2024 10:42:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715622124; x=1716226924; 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=xRahodgvFstgN4YVTm4juf4FQ9yz76v6iCC+Og0iG54=; b=QOdrVSARYX6nFy2RQjgPukD57Zd6GX1CODwcBONvrv5gtI8lBlO6C07oNT+/Zd2eZc 9z/0f4pbyCQE6Rhf44LZ6E4p0cGXaSDmKkrbQGw8mFb5JqcUC15U9NOp3barVjcvcOFW KQITiYmVu9e2FMR3mvHdmZtflSSL1AnAq3CB088ZsU8sc1BvLeaYeIVZiZ5DOTsGOwvR Dr+GYCt0veFZjlMw1/NwpRLwItmv6ROeUtdmTp2TdR4ZvyJc/Gr22HMIPvjxTzt75p6v Q3lSAuvQ5/hnB8Od8wt8bOI+VfFVekNLsftmP7K8wTOLE/VDhI0fi+Xl6cYeblMz5aoJ jjHw== X-Forwarded-Encrypted: i=1; AJvYcCVrSrA3eWhRkhHPUbfkv9Wob/xIK9MfsRlwuNXFUZb1/AmM9hQ4OHRngR7W0I86HIw1d914+WeBnSjr7c6QBVo8WHKrMGvrKqZeAarKEvP/fN0m X-Gm-Message-State: AOJu0Yz4P5E9OpuT0SZAStwvSEMqQXmZR26nJmg+k7ATnNSYq6TIIYo3 zwsop9YbpSHg6umBZ/Eeg3Xp/t4fOahg9MelZ2LGRJPWe/QkHqYW0SC9EzKbelizppMS1iycl5L wEEyG8FxbUfJDe8yHGf1wnOEpmJ3kAmqsKiRWEQ== X-Google-Smtp-Source: AGHT+IGSIVG5X5/9fjKxlVmevCNZT5sbPflBJdnPSC4QwTbVQ67mrp/mCmYCO1WV5Ndlqx6RZkQKt1zb57CwbTs1lW4= X-Received: by 2002:a25:5f06:0:b0:de5:4b25:8054 with SMTP id 3f1490d57ef6-dee4f380619mr8391676276.65.1715622124101; Mon, 13 May 2024 10:42:04 -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> <3fdaf4b1-82d1-45bb-8175-f97ff53a1f01@iki.fi> In-Reply-To: From: Jelte Fennema-Nio Date: Mon, 13 May 2024 19:41:58 +0200 Message-ID: Subject: Re: Direct SSL connection with ALPN and HBA rules To: Robert Haas Cc: Heikki Linnakangas , Jacob Champion , Daniel Gustafsson , 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 Mon, 13 May 2024 at 18:14, Robert Haas wrote: > I disagree with Jacob's assertion that sslmode=require has no security > benefits over sslmode=prefer. That seems like the kind of pessimism > that makes people hate security professionals. There have got to be > some attacks that are foreclosed by encrypting the connection, even if > you don't stop MITM attacks or other things that are more > sophisticated than running wireshark and seeing what goes by on the > wire. Like Jacob already said, I guess you meant me here. The main point I was trying to make is that sslmode=require is extremely insecure too, so if we're changing the default then I'd rather bite the bullet and actually make the default a secure one this time. No-ones browser trusts self-signed certs by default, but currently lots of people trust self-signed certs when connecting to their production database without realizing. IMHO the only benefit that sslmode=require brings over sslmode=prefer is detecting incorrectly configured servers i.e. servers that are supposed to support ssl but somehow don't due to a misconfigured GUC/pg_hba. Such "incorrectly configured server" detection avoids sending data to such a server, which an eavesdropper on the network could see. Which is definitely a security benefit, but it's an extremely small one. In all other cases sslmode=prefer brings exactly the same protection as sslmode=require, because sslmode=prefer encrypts the connection unless postgres actively tells the client to downgrade to plaintext (which never happens when the server is configured correctly).