From: Anthony Martin <ality@pbrane.org>
To: 9front@9front.org
Subject: Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension
Date: Mon, 23 Jan 2023 03:18:03 -0800 [thread overview]
Message-ID: <Y85s6z/imzZxd6Xh@alice> (raw)
In-Reply-To: <CAFSF3XNRCt7uv4WCsfwfu1Mq8o5ff2+QgpHCrLM_CcMOKf0eAw@mail.gmail.com>
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¹ about this
problem back in 2009 when Marsh Ray described his attacks².
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/
next prev parent reply other threads:[~2023-01-23 11:19 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-10 2:24 Anthony Martin
2023-01-18 15:07 ` [9front] " Anthony Martin
2023-01-19 4:30 ` [9front] " ori
2023-01-19 4:48 ` ori
2022-11-10 2:24 ` Anthony Martin
2023-01-28 21:20 ` ori
2023-01-28 21:59 ` cinap_lenrek
2023-01-19 9:50 ` Anthony Martin
2023-01-20 12:12 ` hiro
2023-01-20 21:05 ` Anthony Martin
2023-01-20 22:33 ` hiro
2023-01-21 3:48 ` Anthony Martin
2023-01-21 12:54 ` hiro
2023-01-21 17:29 ` Steve Simon
2023-01-22 16:00 ` hiro
2023-01-22 7:55 ` Anthony Martin
2023-01-22 16:10 ` hiro
2023-01-23 11:18 ` Anthony Martin [this message]
2023-01-23 13:16 ` hiro
2023-01-23 14:24 ` Ori Bernstein
2023-01-23 14:29 ` Ori Bernstein
2023-01-24 0:14 ` hiro
2023-01-24 0:16 ` hiro
2023-01-25 16:19 ` kemal
2023-01-25 16:39 ` hiro
2023-01-25 17:07 ` kemal
2023-01-25 17:18 ` hiro
2023-01-25 17:30 ` kemal
2023-01-25 17:36 ` kemal
2023-01-26 20:54 ` hiro
2023-01-26 21:52 ` Frank D. Engel, Jr.
2023-01-27 6:11 ` kemal
2023-01-27 10:55 ` hiro
2023-01-27 17:38 ` kemal
2023-01-23 16:23 ` hiro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y85s6z/imzZxd6Xh@alice \
--to=ality@pbrane.org \
--cc=9front@9front.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).