From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 7281 invoked from network); 23 Jan 2023 13:17:36 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 23 Jan 2023 13:17:36 -0000 Received: from mail-vs1-f53.google.com ([209.85.217.53]) by 9front; Mon Jan 23 08:16:16 -0500 2023 Received: by mail-vs1-f53.google.com with SMTP id t10so12804333vsr.3 for <9front@9front.org>; Mon, 23 Jan 2023 05:16:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:to:subject:message-id:date:from :references:in-reply-to:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=In3IDLn6UZxidGG3XfA3dVNjBHFS5eQJAVHR+FVm/uU=; b=gn+CG/NSE5YyV3SUj6/7Rm3CYAyaYRqxsFkSHMmZE0nLjWWLI/d2pr5TQCkcthja4R arN01dlZs7Mxa9aOyynLgegbSVq1NOl0Te1tqF9+rLcy4tFbzgHHFDp3FM1YsxFWxO3H xBkPCp0n1QjiXlsZ6bZe4QCcXlEflkR7gsOdF8YNi2jTx2wOabjP3/FmdpTJTWXhOC1T kYm7G6vyXrxTQFKkqLuNqeiFnDsnaiXEmXECNE4K8jDHoEen1EKtC74f2ofWQJ9PPfMb H//RbyLEQJEibdhH10A1LapiM9itZBy5OKewYNqH17wnacrwhxVRg/UsTEZQgCYlFO7b w2Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:to:subject:message-id:date:from :references:in-reply-to:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=In3IDLn6UZxidGG3XfA3dVNjBHFS5eQJAVHR+FVm/uU=; b=iJt9YmVf3dfIXLgvYnVMS+GNEnCAMwFELBfBG08jYSicL7fYqpYBSQsOu55hUq0t3f rJbUGjHGQ5Ml1Y2ha4evemRMUZdKAalYNiGsOH6beVkQeHzhjU731CnrvlZQY0ODKfKB 89h6XxeEDymizbRXY0FyVHtwNRTOVqQgXkQxfE9E9gxqPaAQ3mezFGZ1syPmndCxlwfZ 5Zds9Q8p7tI3F4t75cR0RPNXeg+BYKA0Q018gJ14PJFpzHmikWKSRJXZFuYIYEb/f9AM nnF2phzAqGeNf8S9vvRIg2enajrdmJy9N9ezp9AtHyo1BKnlTXuM9jgUELhgjc0xkF/y jkhg== X-Gm-Message-State: AFqh2kpPdurKWvAsvR473T6KSxI5XqZUiNNRMze/q+C7fMzXrRKvOWWN mAH4klLPoLMVFI9fylHogoTAowb1uh4YGPFb7xE1tozb X-Google-Smtp-Source: AMrXdXvmR58jQ6I8/3LZI/OauAUlTnKO1VWPNTh4dAtnnk7s819E1XjFvFEX5yKKKZH+PRdLiKwblwLplP653zcmINI= X-Received: by 2002:a67:ce0f:0:b0:3d3:c5a3:ae94 with SMTP id s15-20020a67ce0f000000b003d3c5a3ae94mr3234184vsl.75.1674479771738; Mon, 23 Jan 2023 05:16:11 -0800 (PST) MIME-Version: 1.0 Received: by 2002:ab0:5a66:0:0:0:0:0 with HTTP; Mon, 23 Jan 2023 05:16:11 -0800 (PST) In-Reply-To: References: <87988F72F1C2D20B16DE8DA47FB8C262@alice> From: hiro <23hiro@gmail.com> Date: Mon, 23 Jan 2023 14:16:11 +0100 Message-ID: To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: abstract secure markup grid Subject: Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension Reply-To: 9front@9front.org Precedence: bulk did you try explaining this to "The OpenSSL developers" ? also, is there no way in openssl to turn off this behavior? it seems like an industry-wide sabotage effort. On 1/23/23, Anthony Martin wrote: > hiro <23hiro@gmail.com> once said: >> your explanation of their secondary reasoning is good. the original >> assumptions that led to this extension are still invalid. > > The IETF TLS group had a lengthy discussion=C2=B9 about this > problem back in 2009 when Marsh Ray described his attacks=C2=B2. > > Martin Rex said: > > I can understand what it says, but I _really_ dislike it. > > The root of the problem is servers that perform (or at least > allow) TLS renegotiations and make flawed assumptions about > what a successful TLS renegotiation means for the data > previously received. > > What you're essentially asking for, is that a client should no > longer talk TLS to _any_ Server that doesn't support the new > extension. Not even to the good ones that neither offer nor > support renegotiation. > > This is discriminating against servers that have been playing > safe! > > Essentially we are going to hold TLS clients and the installed > base of good Servers responsible for the broken Servers out > there. That feels very wrong. > > Eric Rescorla responded: > > I'm not recommending that clients do that. What I'm trying to > say is that *if* a client wants to be totally sure then all it > can do is require the extension. I agree it's impractical (and > probably unwise) to suggest that they actually behave that > way. > > The OpenSSL developers have decided that clients should now > "do that" by default. > > Like it or not, OpenSSL is the apex predator. We can either > refuse to support v3.0 clients connecting to our servers or > make the minimal changes necessary to accommodate them. I > think we all know our place in the ecosystem. > > I'm not defending their decision. I just fixed the problem > months ago and moved on with my life. I was checking in to see > if you guys still wanted the patch or not. > > Cheers, > Anthony > > 1. https://mailarchive.ietf.org/arch/msg/tls/N7EcRpvK2ENs5IwWYv2p7nrUG8w/ > 2. > https://web.archive.org/web/20091107111709/http://www.extendedsubset.com/ >