<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[nginx accepts SHA-224 signature algorithms in TLS 1.2]]></title><description><![CDATA[<p dir="auto">On Cloudron 9.2.0 (nginx 1.24.0, OpenSSL 3.0.13) the generated vhosts pin ssl_protocols and ship a curated ssl_ciphers list, but the TLS 1.2 signature algorithms are left at OpenSSL's defaults, which still include the SHA-224 variants. A client offering nothing but ECDSA+SHA224 gets a completed handshake with Peer signature type: ecdsa_sha224.</p>
<p dir="auto"><a href="https://en.internet.nl" target="_blank" rel="noopener noreferrer nofollow ugc">https://en.internet.nl</a> flags this under "Hash function for key exchange" as phase out, following the NCSC TLS guidelines 2025-05 §3.3.5, and notes it will likely be rated insufficient in a future update. It's the only remaining recommendation on an otherwise 100% site, and it sits in the platform's nginx configuration rather than anywhere an app or admin can reach.</p>
<p dir="auto">Since v10 is in the works — would this be worth picking up along the way?</p>
]]></description><link>https://forum.cloudron.io/topic/15793/nginx-accepts-sha-224-signature-algorithms-in-tls-1.2</link><generator>RSS for Node</generator><lastBuildDate>Sun, 09 Aug 2026 05:19:56 GMT</lastBuildDate><atom:link href="https://forum.cloudron.io/topic/15793.rss" rel="self" type="application/rss+xml"/><pubDate>Thu, 06 Aug 2026 10:36:48 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to nginx accepts SHA-224 signature algorithms in TLS 1.2 on Sat, 08 Aug 2026 09:51:13 GMT]]></title><description><![CDATA[<p dir="auto">Fair enough — you're right that it isn't exploitable. The client sends signature_algorithms and the server picks from the intersection, so nothing modern ends up on SHA-224 unless it explicitly asks for it, which is exactly what my test did.</p>
<p dir="auto">Where it still bites is compliance rather than security: organisations measured against the NCSC guidelines get it reported on every scan, and <a href="http://internet.nl" target="_blank" rel="noopener noreferrer nofollow ugc">internet.nl</a> states they expect to reclassify it from phase out to insufficient in a future update — at which point it stops being a recommendation and becomes a failed subtest. That's the only thing that really changes the calculus, and whether it's worth pre-empting is your call.</p>
<p dir="auto">Same algorithm turns up on the mail server for the same reason, which is in the other thread.</p>
]]></description><link>https://forum.cloudron.io/post/127933</link><guid isPermaLink="true">https://forum.cloudron.io/post/127933</guid><dc:creator><![CDATA[imc67]]></dc:creator><pubDate>Sat, 08 Aug 2026 09:51:13 GMT</pubDate></item><item><title><![CDATA[Reply to nginx accepts SHA-224 signature algorithms in TLS 1.2 on Sat, 08 Aug 2026 09:12:06 GMT]]></title><description><![CDATA[<p dir="auto">Since we don't set SignatureAlgorithms, the default comes from OpenSSL. It's there even in Ubuntu 26, OpenSSL 3.5.5 (27 Jan 2026).</p>
<p dir="auto">It's not a real security issue to have SHA-224 listed since preference is mostly client driven. Most of the modern servers will have SHA-256 (or PSS, never heard of that before I researched this).</p>
]]></description><link>https://forum.cloudron.io/post/127930</link><guid isPermaLink="true">https://forum.cloudron.io/post/127930</guid><dc:creator><![CDATA[girish]]></dc:creator><pubDate>Sat, 08 Aug 2026 09:12:06 GMT</pubDate></item></channel></rss>