[From nobody Sun Mar 22 08:41:06 2026
Received: (at 672456-done) by bugs.debian.org; 22 Mar 2026 08:38:54 +0000
X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02
 (2024-03-25) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-7.1 required=4.0 tests=BAYES_00,DKIM_SIGNED,
 DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HAS_BUG_NUMBER,
 RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS autolearn=ham
 autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 33; hammy, 104; neutral, 51; spammy,
 3. spammytokens:0.988-+--cheaper, 0.942-+--H*r:bugs.debian.org,
 0.932-+--today hammytokens:0.000-+--H*F:U*sebastian,
 0.000-+--H*F:D*breakpoint.cc, 0.000-+--H*RU:sk:chamill,
 0.000-+--H*r:sk:chamill, 0.000-+--H*rp:D*breakpoint.cc
Return-path: <sebastian@breakpoint.cc>
Received: from chamillionaire.breakpoint.cc ([91.216.245.30]:50700)
 by buxtehude.debian.org with esmtps
 (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
 (Exim 4.96) (envelope-from <sebastian@breakpoint.cc>)
 id 1w4EKk-009onl-29 for 672456-done@bugs.debian.org;
 Sun, 22 Mar 2026 08:38:54 +0000
Date: Sun, 22 Mar 2026 09:38:51 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=breakpoint.cc;
 s=2025; t=1774168732;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:mime-version:mime-version:content-type:content-type:
 in-reply-to:in-reply-to:references:references;
 bh=PFHG+xWgcUVNfahZGaXPFae6raG/rIKt2mC5z9uRFiw=;
 b=hHvWIxne5gkts/Cb6qxrnvi5f8zV09szbsGuIdkQF+Lt893SswGKWjP2qiyJDWk4XXQ8Hf
 jSCYC4szRnEz/dJsyfxPF80eta/vCrXjjkTp2ngRu4TmI8PhpUY3OdabqrG4fpBfrwkZNd
 RZF88UJllZr5t0/YqbEwGMu31moybk8794Iu5iSS1gfp9MRiLQ3JyS/8v+dt+k3K28Gh7a
 p/72u0UZ09/980MMXtaWESRBePhPpI1mGVDxVOIwvGxPdJkYo3DWKomRIjw1eaSZnjBOpT
 Q99PLHEC4ChA5UXjFU0d+qOzdIuyHgAeVuxNK7a0VxB/Xtr5AIIyaYoIQuomTQ==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=breakpoint.cc;
 s=2025e; t=1774168732;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:mime-version:mime-version:content-type:content-type:
 in-reply-to:in-reply-to:references:references;
 bh=PFHG+xWgcUVNfahZGaXPFae6raG/rIKt2mC5z9uRFiw=;
 b=Y+f48fLaagZsCDh57jndTqIVpWE9viIcK6kqwSE0VJcmo345qUm+75UucE2tRvvHGeaxSN
 PW6CeDkab+D94lBw==
From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
To: Henri Salo <henri@nerv.fi>, 672456-done@bugs.debian.org
Subject: Re: Bug#672456: CVE-2011-1473: SSL/TLS DoS via repeated SSL session
 renegotiations
Message-ID: <20260322083851.bEFhEkPx@breakpoint.cc>
References: <20120511081811.GA7876@kludge.henri.nerv.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20120511081811.GA7876@kludge.henri.nerv.fi>

On 2012-05-11 11:18:11 [+0300], Henri Salo wrote:
> It was reported [1] that a flaw exists in how openSSL handles SSL
> renegotiation.  Because of the processing power required to handle an SSL/TLS
> handshake, with renegotiation enabled, a user can send multiple handshakes per
> second due to the renegotiation request being permitted.  This could allow a
> malicious user to send multiple renegotiation requests and exhaust server
> resources.

This is protocol issue and there is nothing that can be done without
breaking the expectations on the other side.
Things that changed in the meantime and make me sleep well while closing
this:
- moving to an EC key makes this less of an issue because renegotiation
  with an EC key is cheaper than with RSA/ DH with equivalent security.
  EC keys is something that is widely supported now and even a few years
  back so I don't expect anyone saying "can't do EC".

- There is RFC 5746 (Secure Renegotiation) in place. This should address
  the repeated renegotiation issue.

- TLS v1.3 does not support renegotiation.

As of today I would say disable renegotiation and use TLS v1.3+ if this
is a concern.

Sebastian]