From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 092A31FF09C for ; Mon, 02 Nov 2026 15:07:44 +0100 (CET) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id C4C68217CC; Mon, 02 Nov 2026 15:07:36 +0100 (CET) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 02 Nov 2026 15:07:32 +0100 Message-Id: Subject: Re: [PATCH common 2/2] ticket: sign RSA tickets with SHA-256 To: "Mark Atwood" , X-Mailer: aerc 0.20.0 References: <20261023185749.509347-2-mark@wolfssl.com> In-Reply-To: <20261023185749.509347-2-mark@wolfssl.com> From: "Shannon Sterz" X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1793628453008 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.665 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: 4JZYHWQISKF7ITIX72CEGHX2FAQE56YQ X-Message-ID-Hash: 4JZYHWQISKF7ITIX72CEGHX2FAQE56YQ X-MailFrom: s.sterz@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri Oct 23, 2026 at 8:57 PM CEST, Mark Atwood wrote: > Crypt::OpenSSL::RSA signs with SHA-1 unless told otherwise. NIST SP > 800-131A Rev. 2 no longer allows SHA-1 for creating digital signatures, > and a FIPS provider that enforces this makes assemble_rsa_ticket die, so > no ticket can be issued. > > Select SHA-256 explicitly before signing. The signature length only > depends on the RSA key size, so tickets keep their size. > > Nodes with the previous commit accept both hashes. Nodes running an > older version only verify SHA-1, so in a cluster with mixed versions a > ticket issued by an updated node is rejected by a not yet updated one, > for example on API requests that the updated node proxies to it. This > change should thus only roll out once the verification side has been > available for a while. One thing I wonder is whether we should maybe make this an opt-in as it can already break certain users' setups (as you mentioned). An opt-in would allow users that require a FIPS provider to use this already instead of having to wait for use decide when it's been "long enough". We can then eventually remove the opt-in check move everyone over. We could also write a file to `/etc/pve` that indicates what nodes of the cluster are ready to use the new hash function and switch automatically if all nodes are updated. This would handle this automatically, but would be more complex to implement. -->8 snip 8<--