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 1s01ya-000C8L-72 for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Apr 2024 16:29:36 +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 1s01xX-000Ux9-ST for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Apr 2024 16:28:32 +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 1s01xX-000Ur8-Hi for pgsql-hackers@lists.postgresql.org; Thu, 25 Apr 2024 16:28:32 +0000 Received: from mail-qv1-xf2f.google.com ([2607:f8b0:4864:20::f2f]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s01xV-0001QE-9D for pgsql-hackers@lists.postgresql.org; Thu, 25 Apr 2024 16:28:31 +0000 Received: by mail-qv1-xf2f.google.com with SMTP id 6a1803df08f44-69b50b8239fso12344506d6.0 for ; Thu, 25 Apr 2024 09:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1714062507; x=1714667307; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=OguT3/BDRC7rPWgvvl8cYimColStAAFTNXbbc+/BzRY=; b=QS4OHQoHUttXfjPUccHNTR9c5LnOdHGtUKMvQ5F74J5pwuh3g6fEW+6VlXu0CJ6zg6 sXZkL2EHWi2SSVVeVMwYpd1pe6VdlrTBRLtOZxQRGs2cBKNvMF7sPk0s0HQTkuA3FBpu 0/Lt7ZAnVeILAyKotvjQ4OTJinSva2vMC20NP3yKKiiVfz91vAOaokwxcbnXkz8FXwJD ZxyVIpR4+R4e26Z+kfrV2kXBCg+uK2678Eul+HQ+bFbJ3wUP4NTTxz0kIHiHou94XuGF kyG+nTK3fdlSt7MZjFPJfQlRp0najRCsc0dBGQaMRBoBcBvH6Il0ViBz6ma4vMt0gn1q ttzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714062507; x=1714667307; h=content-transfer-encoding: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=OguT3/BDRC7rPWgvvl8cYimColStAAFTNXbbc+/BzRY=; b=lBjHGtZ+IrAiX2+FIg+O2cOUW+oS87Qm+hTKKL8VaoKOX0vMrGuCOfGDIAdbFi9tYG ySr9/oLsFqMVRI7Sp5jqk5mPrD38Oe9UmM9zZ7K6yLgLYbYJgIYDOiqc+iu0uEHHmCbe 2FE5ex5/0J0yCYvR4EVrp/E2DrZCLCiyqiYk+d5e2ZxdTfX1v7r+Yh0eJVTsgc60hJ6I V3r1NGZZXcJKBTpD24CaxgWklXaJ6l+MXS7QX6F99ztIRCLwzfMgLBgI1SSLIKtgWBBT sZpad+e6u9wrzjflJVCslmRkxzfm+CA+1/yIkI7z/b51IA/z2nMQIWg3yPP1BCPD2axM OOiw== X-Forwarded-Encrypted: i=1; AJvYcCVhk8wO+fzx6VADeRxXT+LM/ZL8G2AGWI/OYU/sNN55LE7ellSyJjaPf4nJMjYl3c1pp+wxXiPPFQ5LeaIv+vKNwQKpdduf4ZehadYsFOwtAtKa X-Gm-Message-State: AOJu0YyB+BLzkLJpDafx45u+dLO1zFJkmViSVaq2f5MHm1UPc3NEiJeF QPn8MLAnBorj7lfzjNfo4rlwZJh2mPYPE/wrOQG+7AoDzeUXj1aa9Fqh8tRTtFu3KUyt3Qa0YMt GP+KXArmzw0dfjDINiVLLckZzpoGoFgszLD/z X-Google-Smtp-Source: AGHT+IEOEEMAGrYytn8CABPgJfl7BFTaWoF0Lmv6OLPsosWa5DT62E4VIq4QJQTxBPesux/paDUi7BZ3MiJBu7Xt88c= X-Received: by 2002:a05:6214:5298:b0:696:b01d:da51 with SMTP id kj24-20020a056214529800b00696b01dda51mr5494061qvb.10.1714062507170; Thu, 25 Apr 2024 09:28:27 -0700 (PDT) MIME-Version: 1.0 References: <5a79ed71-b365-4b20-80bc-9c2bf97bf84b@iki.fi> In-Reply-To: From: Jacob Champion Date: Thu, 25 Apr 2024 09:28:16 -0700 Message-ID: Subject: Re: Direct SSL connection with ALPN and HBA rules To: Robert Haas Cc: Heikki Linnakangas , Michael Paquier , Postgres hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Apr 25, 2024 at 9:17=E2=80=AFAM Robert Haas = wrote: > > It is difficult to imagine a world in which we have both requiredirect > and forcedirect and people are not confused. Yeah... Any thoughts on a better scheme? require_auth was meant to lock down overly general authentication; maybe a require_proto or something could do the same for the transport? I hate that we have so many options that most people don't need but take precedence, especially when they're based on the existence of magic third-party environmental cues (e.g. Kerberos caches). And it was nice that we got sslrootcert=3Dsystem to turn on strong security and reject nonsensical combinations. If someone sets `requiredirect` and leaves the default sslmode, or chooses a weaker one... Is that really useful to someone? --Jacob