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 1s0NSH-003Ydx-V7 for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Apr 2024 15:25:41 +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 1s0NSD-00CMgq-Ea for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Apr 2024 15:25:38 +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 1s0NSD-00CMgi-54 for pgsql-hackers@lists.postgresql.org; Fri, 26 Apr 2024 15:25:38 +0000 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s0NSB-000AAZ-EU for pgsql-hackers@lists.postgresql.org; Fri, 26 Apr 2024 15:25:36 +0000 Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a587831809eso270795866b.1 for ; Fri, 26 Apr 2024 08:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714145134; x=1714749934; 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=CSR4bHt6ojA0kdVUy3DO6BHoCUhWGhnjHuKDa7CESA4=; b=kMWKXN9g9YFoUJl9WxQ/Jto3Fee4V9hwmBV4wrqJaEk0AL5rznXf72lmyOrphVYhJZ lvpsQlrFggK9H4La4YwxcN3xuxB/p5KEOwqgodB6dBSkM0vgLOY2dpia4oUjI/vcO9Ic VFDf4VCyHqVVH45zU5NywUD7xDQHW0EH6+7eKZB5fxZboQA+aldRYHiVChGgNOO4NxvH hkvBBsqxTrLi9q6tLjMfs5Ul6A/DB6xa81hpyR60XNB6aaJ4VwUUt7b/jlZtbYdWsWZC Y0mC34TI+qbSTtpdI0hS8FkkWAqs7TK6fDNK/HH6zqyII6Z1A/lWHVr18Na8r3IL0OI2 kyIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714145134; x=1714749934; 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=CSR4bHt6ojA0kdVUy3DO6BHoCUhWGhnjHuKDa7CESA4=; b=eBKkmXeQvGMpWZmA+WvDMsKXxemEK21ErCLO9iOHVV34YlIKDuqeOCB8La9jKrCEI9 pDo9882r798JaCev/LqylTRvij2vVsXzsp9Do2Fb+lhw98Ub0BR6iqN0vJs54Z55WEFU lAylrBwyxFK42Q1w7PgnuCzruS+9DZdLRyNB4xTgko9cTpYWhh+L4yFGFmkrp4W/E4ua AuKAJ/FYOpePGsykapj6UilfGu/3uqhFtxdRHLaT+Jev98pRYfOdO6osGjfPLtjDQpu2 gT/Hvor7C1J2qbH0U601jVHRBJG1x4gK48Y0n9TsP/bAeQDMCpDmIo30Q+LeDVdHThPx T6fA== X-Forwarded-Encrypted: i=1; AJvYcCXhI/9Dnv/7BFGQ+yTlsYywNBXSDpaFTxXesN2ulJP195IYQGWyM+SE0GvzRfo9SUAe0gh6iKWebaeilOKzN7pR7KrfZcyjvlSAMApHXWkFyhhk X-Gm-Message-State: AOJu0YzZe6VXyjie0oQ+jNdJ/0XG3FvNalrId0W7q9ZYuPpiBelIMMGn 2+ZVRQxphZQ0Wmn7uBWk/ws8wvJIhv6r+wU6+iah4siuMUcmJSaW0ozDSaTKpDbEIDmQxXoMFlM IDFq4bffRznRZpiprt+q+lBhWdYc= X-Google-Smtp-Source: AGHT+IEv4SmRvd1INgCH0zVOvLr2vT07zllOzPjp3x6TkkmMCjv+WON9oGDyW+gXviesTeO2JjTJndrD5+YGioCuDzo= X-Received: by 2002:a17:906:f288:b0:a58:872b:20e5 with SMTP id gu8-20020a170906f28800b00a58872b20e5mr2297207ejb.28.1714145133692; Fri, 26 Apr 2024 08:25:33 -0700 (PDT) MIME-Version: 1.0 References: <5a79ed71-b365-4b20-80bc-9c2bf97bf84b@iki.fi> In-Reply-To: From: Robert Haas Date: Fri, 26 Apr 2024 11:25:21 -0400 Message-ID: Subject: Re: Direct SSL connection with ALPN and HBA rules To: Heikki Linnakangas Cc: Jacob Champion , 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 5:50=E2=80=AFPM Heikki Linnakangas wrote: > On 25/04/2024 21:13, Jacob Champion wrote: > > On Thu, Apr 25, 2024 at 10:35=E2=80=AFAM Robert Haas wrote: > >> Maybe I'm missing something here, but why doesn't sslnegotiation > >> override sslmode completely? Or alternatively, why not remove > >> sslnegotiation entirely and just have more sslmode values? I mean > >> maybe this shouldn't happen categorically, but if I say I want to > >> require a direct SSL connection, to me that implies that I don't want > >> an indirect SSL connection, and I really don't want a non-SSL > >> connection. > > My thinking with sslnegotiation is that it controls how SSL is > negotiated with the server, if SSL is to be used at all. It does not > control whether SSL is used or required; that's what sslmode is for. I think this might boil down to the order in which someone thinks that different settings should be applied. It sounds like your mental model is that GSS settings are applied first, and then SSL settings are applied afterwards, and then within the SSL bucket you can select how you want to do SSL (direct or negotiated) and how required it is. My mental model is different: I imagine that since direct SSL happens from the first byte exchanged over the socket, direct SSL "happens first", making settings that pertain to negotiated GSS and negotiated SSL irrelevant. Because, logically, if you've decided to use direct SSL, you're not even going to get a chance to negotiate those things. I understand that the code as written works around that, by being able to open a new connection if it turns out that we need to negotiate that stuff after all, but IMHO that's rather confusing. --=20 Robert Haas EDB: http://www.enterprisedb.com