[9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[Anthony Martin]

OpenSSL 3.0 clients refuse to connect to servers that do not
support the renegotiation extension (RFC 5746) unless the default
configuration is changed to allow it. Since we do not support
renegotiation, we only need to make minor changes to the initial
handshake to comply with the specification:

1. For tlsClient, simply add the proper SCSV to the ClientHello
cipher list (cf. RFC 5746 § 3.3);

2. For tlsServer, respond with an empty renegotiation extension
in the ServerHello if we received either the SCSV or an empty
renegotiation extension in the ClientHello.

Since we close the hand file and never open it after the initial
handshake, we can rely on tls(3) to send the "no renegotiation"
alerts if subsequent handshake records are received.

---
diff e5d29a2bd91951a24fccecd958416856cecef444 d75905c2e41425e0add855e77527b016384c46ec
--- a/sys/src/libsec/port/tlshand.c	Tue Nov 8 14:11:29 2022
+++ b/sys/src/libsec/port/tlshand.c	Wed Nov 9 18:24:40 2022
@@ -68,6 +68,7 @@
 	uchar sec[MasterSecretSize];	// master secret
 	uchar srandom[RandomSize];	// server random
 	uchar crandom[RandomSize];	// client random
+	int reneg;			// secure renegotiation flag
 
 	Namedcurve *nc; // selected curve for ECDHE
 	// diffie hellman state
@@ -251,6 +252,7 @@
 	TLS_PSK_WITH_AES_128_CBC_SHA		= 0x008C,
 
 	TLS_FALLBACK_SCSV = 0x5600,
+	TLS_EMPTY_RENEGOTIATION_INFO_SCSV = 0x00FF,
 };
 
 // compression methods
@@ -271,6 +273,7 @@
 	Extec = 0x000a,
 	Extecp = 0x000b,
 	Extsigalgs = 0x000d,
+	Extreneg = 0xff01,
 };
 
 static Algs cipherAlgs[] = {
@@ -670,6 +673,16 @@
 						break;
 					}
 			break;
+		case Extreneg:
+			if(n < 1 || *p != (n -= 1))
+				goto Short;
+			if(*p != 0){
+				tlsError(c, EHandshakeFailure, "invalid renegotiation extension");
+				return -1;
+			}
+			c->sec->reneg = 1;
+			p++;
+
 		}
 	}
 
@@ -679,13 +692,37 @@
 	return -1; 
 } 
 
+static uchar*
+tlsServerExtensions(TlsConnection *c, int *plen)
+{
+	uchar *b, *p;
+	int m;
+
+	p = b = nil;
+
+	// RFC5746 - Renegotiation Indication
+	if(c->sec->reneg){
+		m = p - b;
+		b = erealloc(b, m + 2+2+1);
+		p = b + m;
+
+		put16(p, Extreneg), p += 2;	/* Type: renegotiation_info */
+		put16(p, 1), p += 2;		/* Length */
+		*p++ = 0;			/* Renegotiated Connection Length */
+	}
+
+	*plen = p - b;
+	return b;
+}
+
 static TlsConnection *
 tlsServer2(int ctl, int hand,
 	uchar *cert, int certlen,
 	char *pskid, uchar *psk, int psklen,
 	int (*trace)(char*fmt, ...), PEMChain *chp)
 {
-	int cipher, compressor, numcerts, i;
+	int cipher, compressor, numcerts, i, extlen;
+	uchar *ext;
 	TlsConnection *c;
 	Msg m;
 
@@ -741,8 +778,11 @@
 			goto Err;
 		}
 	}
+	if(lookupid(m.u.clientHello.ciphers, TLS_EMPTY_RENEGOTIATION_INFO_SCSV) >= 0)
+		c->sec->reneg = 1;
 	if(checkClientExtensions(c, m.u.clientHello.extensions) < 0)
 		goto Err;
+	ext = tlsServerExtensions(c, &extlen);
 	cipher = okCipher(m.u.clientHello.ciphers, psklen > 0, c->sec->nc != nil);
 	if(cipher < 0 || !setAlgs(c, cipher)) {
 		tlsError(c, EHandshakeFailure, "no matching cipher suite");
@@ -763,6 +803,7 @@
 	m.u.serverHello.cipher = cipher;
 	m.u.serverHello.compressor = compressor;
 	m.u.serverHello.sid = makebytes(nil, 0);
+	m.u.serverHello.extensions = makebytes(ext, extlen);
 	if(!msgSend(c, &m, AQueue))
 		goto Err;
 
@@ -2273,6 +2314,7 @@
 	for(i = 0; i < nelem(cipherAlgs); i++)
 		if(cipherAlgs[i].ok && isPSK(cipherAlgs[i].tlsid) == ispsk)
 			is->data[j++] = cipherAlgs[i].tlsid;
+	is->data[j++] = TLS_EMPTY_RENEGOTIATION_INFO_SCSV;
 	is->len = j;
 	return is;
 }

[9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[Anthony Martin]

OpenSSL 3.0 clients refuse to connect to servers that do not
support the renegotiation extension (RFC 5746) unless the default
configuration is changed to allow it. Since we do not support
renegotiation, we only need to make minor changes to the initial
handshake to comply with the specification:

1. For tlsClient, simply add the proper SCSV to the ClientHello
cipher list (cf. RFC 5746 § 3.3);

2. For tlsServer, respond with an empty renegotiation extension
in the ServerHello if we received either the SCSV or an empty
renegotiation extension in the ClientHello.

Since we close the hand file and never open it after the initial
handshake, we can rely on tls(3) to send the "no renegotiation"
alerts if subsequent handshake records are received.

---
diff bb36ba0617b5aa8263ea9b5ece8c1a5249fedc86 20060574cb77ba3655739f67fe290270ccc21cb9
--- a/sys/src/libsec/port/tlshand.c	Tue Jan 17 05:14:06 2023
+++ b/sys/src/libsec/port/tlshand.c	Wed Nov 9 18:24:40 2022
@@ -68,6 +68,7 @@
 	uchar sec[MasterSecretSize];	// master secret
 	uchar srandom[RandomSize];	// server random
 	uchar crandom[RandomSize];	// client random
+	int reneg;			// secure renegotiation flag
 
 	Namedcurve *nc; // selected curve for ECDHE
 	// diffie hellman state
@@ -251,6 +252,7 @@
 	TLS_PSK_WITH_AES_128_CBC_SHA		= 0x008C,
 
 	TLS_FALLBACK_SCSV = 0x5600,
+	TLS_EMPTY_RENEGOTIATION_INFO_SCSV = 0x00FF,
 };
 
 // compression methods
@@ -271,6 +273,7 @@
 	Extec = 0x000a,
 	Extecp = 0x000b,
 	Extsigalgs = 0x000d,
+	Extreneg = 0xff01,
 };
 
 static Algs cipherAlgs[] = {
@@ -670,6 +673,16 @@
 						break;
 					}
 			break;
+		case Extreneg:
+			if(n < 1 || *p != (n -= 1))
+				goto Short;
+			if(*p != 0){
+				tlsError(c, EHandshakeFailure, "invalid renegotiation extension");
+				return -1;
+			}
+			c->sec->reneg = 1;
+			p++;
+
 		}
 	}
 
@@ -679,13 +692,37 @@
 	return -1; 
 } 
 
+static uchar*
+tlsServerExtensions(TlsConnection *c, int *plen)
+{
+	uchar *b, *p;
+	int m;
+
+	p = b = nil;
+
+	// RFC5746 - Renegotiation Indication
+	if(c->sec->reneg){
+		m = p - b;
+		b = erealloc(b, m + 2+2+1);
+		p = b + m;
+
+		put16(p, Extreneg), p += 2;	/* Type: renegotiation_info */
+		put16(p, 1), p += 2;		/* Length */
+		*p++ = 0;			/* Renegotiated Connection Length */
+	}
+
+	*plen = p - b;
+	return b;
+}
+
 static TlsConnection *
 tlsServer2(int ctl, int hand,
 	uchar *cert, int certlen,
 	char *pskid, uchar *psk, int psklen,
 	int (*trace)(char*fmt, ...), PEMChain *chp)
 {
-	int cipher, compressor, numcerts, i;
+	int cipher, compressor, numcerts, i, extlen;
+	uchar *ext;
 	TlsConnection *c;
 	Msg m;
 
@@ -741,6 +778,8 @@
 			goto Err;
 		}
 	}
+	if(lookupid(m.u.clientHello.ciphers, TLS_EMPTY_RENEGOTIATION_INFO_SCSV) >= 0)
+		c->sec->reneg = 1;
 	if(checkClientExtensions(c, m.u.clientHello.extensions) < 0)
 		goto Err;
 	cipher = okCipher(m.u.clientHello.ciphers, psklen > 0, c->sec->nc != nil);
@@ -763,6 +802,9 @@
 	m.u.serverHello.cipher = cipher;
 	m.u.serverHello.compressor = compressor;
 	m.u.serverHello.sid = makebytes(nil, 0);
+	ext = tlsServerExtensions(c, &extlen);
+	m.u.serverHello.extensions = makebytes(ext, extlen);
+	free(ext);
 	if(!msgSend(c, &m, AQueue))
 		goto Err;
 
@@ -2273,6 +2315,7 @@
 	for(i = 0; i < nelem(cipherAlgs); i++)
 		if(cipherAlgs[i].ok && isPSK(cipherAlgs[i].tlsid) == ispsk)
 			is->data[j++] = cipherAlgs[i].tlsid;
+	is->data[j++] = TLS_EMPTY_RENEGOTIATION_INFO_SCSV;
 	is->len = j;
 	return is;
 }

[9front] Re: [PATCH] libsec: add minimal support for the tls renegotiation extension

[Anthony Martin]

Anthony Martin <ality@pbrane.org> once said:
> OpenSSL 3.0 clients refuse to connect to servers that do not
> support the renegotiation extension (RFC 5746) unless the default
> configuration is changed to allow it. Since we do not support
> renegotiation, we only need to make minor changes to the initial
> handshake to comply with the specification:
>
> 1. For tlsClient, simply add the proper SCSV to the ClientHello
> cipher list (cf. RFC 5746 § 3.3);
>
> 2. For tlsServer, respond with an empty renegotiation extension
> in the ServerHello if we received either the SCSV or an empty
> renegotiation extension in the ClientHello.
>
> Since we close the hand file and never open it after the initial
> handshake, we can rely on tls(3) to send the "no renegotiation"
> alerts if subsequent handshake records are received.
>
> [...]

Ping.

Thanks,
  Anthony

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[ori]

Quoth Anthony Martin <ality@pbrane.org>:
> OpenSSL 3.0 clients refuse to connect to servers that do not
> support the renegotiation extension (RFC 5746) unless the default
> configuration is changed to allow it. Since we do not support
> renegotiation, we only need to make minor changes to the initial
> handshake to comply with the specification:
> 
> 1. For tlsClient, simply add the proper SCSV to the ClientHello
> cipher list (cf. RFC 5746 § 3.3);
> 
> 2. For tlsServer, respond with an empty renegotiation extension
> in the ServerHello if we received either the SCSV or an empty
> renegotiation extension in the ClientHello.
> 
> Since we close the hand file and never open it after the initial
> handshake, we can rely on tls(3) to send the "no renegotiation"
> alerts if subsequent handshake records are received.
> 

I'll have to find time to go over the changes this weekend in more
details, and actually read the RFC -- but from a quick read, it
looks like the 'ext' that you allocate in tlsServerExtensions gets leaked.

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[ori]

Quoth ori@eigenstate.org:
> Quoth Anthony Martin <ality@pbrane.org>:
> > OpenSSL 3.0 clients refuse to connect to servers that do not
> > support the renegotiation extension (RFC 5746) unless the default
> > configuration is changed to allow it. Since we do not support
> > renegotiation, we only need to make minor changes to the initial
> > handshake to comply with the specification:
> > 
> > 1. For tlsClient, simply add the proper SCSV to the ClientHello
> > cipher list (cf. RFC 5746 § 3.3);
> > 
> > 2. For tlsServer, respond with an empty renegotiation extension
> > in the ServerHello if we received either the SCSV or an empty
> > renegotiation extension in the ClientHello.
> > 
> > Since we close the hand file and never open it after the initial
> > handshake, we can rely on tls(3) to send the "no renegotiation"
> > alerts if subsequent handshake records are received.
> > 
> 
> I'll have to find time to go over the changes this weekend in more
> details, and actually read the RFC -- but from a quick read, it
> looks like the 'ext' that you allocate in tlsServerExtensions gets leaked.
> 

wait, never mind, it looks like msgClear handles that.

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[Anthony Martin]

ori@eigenstate.org once said:
> > I'll have to find time to go over the changes this weekend in more
> > details, and actually read the RFC -- but from a quick read, it
> > looks like the 'ext' that you allocate in tlsServerExtensions gets leaked.
> >
>
> wait, never mind, it looks like msgClear handles that.

No, you're right. The call to makebytes returns a new copy.
I'll send an updated patch.

Thanks,
  Anthony

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[hiro]

On 11/10/22, Anthony Martin <ality@pbrane.org> wrote:
> OpenSSL 3.0 clients refuse to connect to servers that do not
> support the renegotiation extension (RFC 5746)

why? what's the logic behind it?

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[Anthony Martin]

hiro <23hiro@gmail.com> once said:
> On 11/10/22, Anthony Martin <ality@pbrane.org> wrote:
> > OpenSSL 3.0 clients refuse to connect to servers that do not
> > support the renegotiation extension (RFC 5746)
>
> why? what's the logic behind it?

"It has been more than a decade since RFC 5746 was published,
so there has been plenty of time for implmentation support to
roll out."

    - Benjamin Kaduk¹

Remember, they continue to support renegotiation in TLS
versions before 1.3 and it's insecure² without the RFC 5746
mitigation. It was removed in TLS 1.3. The Plan 9 TLS code
never supported it. Annoyance or clairvoyance? Who knows.

Cheers,
  Anthony

1. https://github.com/openssl/openssl/commit/72d2670bd21becfa6a64bb03fa55ad82d6d0c0f3
2. https://mailarchive.ietf.org/arch/msg/tls/N7EcRpvK2ENs5IwWYv2p7nrUG8w/

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[hiro]

if it got removed in TLS 1.3, what is the remaining (edge?) use case?

On 1/20/23, Anthony Martin <ality@pbrane.org> wrote:
> hiro <23hiro@gmail.com> once said:
>> On 11/10/22, Anthony Martin <ality@pbrane.org> wrote:
>> > OpenSSL 3.0 clients refuse to connect to servers that do not
>> > support the renegotiation extension (RFC 5746)
>>
>> why? what's the logic behind it?
>
> "It has been more than a decade since RFC 5746 was published,
> so there has been plenty of time for implmentation support to
> roll out."
>
>     - Benjamin Kaduk¹
>
> Remember, they continue to support renegotiation in TLS
> versions before 1.3 and it's insecure² without the RFC 5746
> mitigation. It was removed in TLS 1.3. The Plan 9 TLS code
> never supported it. Annoyance or clairvoyance? Who knows.
>
> Cheers,
>   Anthony
>
> 1.
> https://github.com/openssl/openssl/commit/72d2670bd21becfa6a64bb03fa55ad82d6d0c0f3
> 2. https://mailarchive.ietf.org/arch/msg/tls/N7EcRpvK2ENs5IwWYv2p7nrUG8w/
>

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[Anthony Martin]

hiro <23hiro@gmail.com> once said:
> if it got removed in TLS 1.3, what is the remaining (edge?) use case?

Are you asking what the point of the patch is? My intention
was to solve this:

% uname -rms
Linux 6.1.7-arch1-1 x86_64
% curl -v https://9front.org/ |[2] grep error
* OpenSSL/3.0.7: error:0A000152:SSL routines::unsafe legacy renegotiation disabled
%

Maybe I misunderstood your question.

Cheers,
  Anthony

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[hiro]

No, you're right, I just wonder what kept the openssl people from
fixing this problem on their side? Since we have unsafe renegotiations
disabled, we're doing the right and safe thing. so why can't they deal
with it?

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[Steve Simon]

from the point of view of not knowing the protocol at all, but…

could you still take part in the renegotiations but then refuse to accept anything insecure?

-Steve

> On 21 Jan 2023, at 12:54 pm, hiro <23hiro@gmail.com> wrote:
> 
> No, you're right, I just wonder what kept the openssl people from
> fixing this problem on their side? Since we have unsafe renegotiations
> disabled, we're doing the right and safe thing. so why can't they deal
> with it?

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[Anthony Martin]

hiro <23hiro@gmail.com> once said:
> No, you're right, I just wonder what kept the openssl people from
> fixing this problem on their side? Since we have unsafe renegotiations
> disabled, we're doing the right and safe thing. so why can't they deal
> with it?

We never supported renegotiation, meaning after the initial
handshake we never send client or server hello messages and
the record layer (tls(3)) ends the connection if it receives
any handshake records after the data file is open.

But that doesn't mean the other side (e.g. OpenSSL) knows we
won't initiate a renegotiation. There is no indication in the
original protocol. Without implementing any of the mechanisms
in RFC 5746, there's no way to know a renegotiation will be
secure if it happens. The connection could be under attack.

RFC 5746 is called the "Renegotiation Indication" extension.

Does that make sense?

Cheers,
  Anthony

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[hiro]

> could you still take part in the renegotiations but then refuse to accept
> anything insecure?

yes, that's what they (try to) do generally. but it adds complexity.

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[hiro]

> But that doesn't mean the other side (e.g. OpenSSL) knows we
> won't initiate a renegotiation.

there are many things the other side doesn't know. why does it need to
care about that?

> there's no way to know a renegotiation will be
> secure if it happens.

again, there's no way to know a renegotiation will happen in the first
place, whether it would theoretically be secure is another issue.

> The connection could be under attack.

yes, else we would all be saving our time and use straight plaintext over tcp.

> Does that make sense?

your explanation of their secondary reasoning is good. the original
assumptions that led to this extension are still invalid.

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[Anthony Martin]

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/

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[hiro]

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 <ality@pbrane.org> 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¹ 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/
>

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[Ori Bernstein]

On Mon, 23 Jan 2023 14:16:11 +0100, hiro <23hiro@gmail.com> wrote:

> did you try explaining this to "The OpenSSL developers" ?
> 

I encourage you to try.

-- 
    Ori Bernstein

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[Ori Bernstein]

On Mon, 23 Jan 2023 09:24:53 -0500, Ori Bernstein <ori@eigenstate.org> wrote:

> On Mon, 23 Jan 2023 14:16:11 +0100, hiro <23hiro@gmail.com> wrote:
> 
> > did you try explaining this to "The OpenSSL developers" ?
> > 
> 
> I encourage you to try.

Also: they no longer use their mailing lists; you can
try to convince them to change behavior on their github
issue tracker:

	https://github.com/openssl/openssl/issues

-- 
    Ori Bernstein

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[hiro]

> 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.

1) your writeup of this issue is excellent and transparent

2) i agree it's unlikely openssl would listen to us

3) it's pragmatic to implement it and move on.

now this sabotage is well summarized on this mailinglist.

i think it should also be documented in the code and the commit message.
this way, no historian will ever misunderstand the code's existence as
a legitimization of openssl's practices.

errors happen, they can be reverted. but if the integrity of the
openssl developers is damaged, the community will only be able to look
at the summation of such events and find the people responsible and
prevent their continual involvement in this critical core internet
infrastructure.

maybe this is not the tipping point. but we'll get there only if we
keep awareness high. in the long run it will all have to get
addressed.

if anybody from here ever meets an openssl in person, we will have
something to discuss. i find this kind of practice unthinkable for
such an important project.

keep up the fight.

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[hiro]

> also, is there no way in openssl to turn off this behavior?

https://github.com/openssl/openssl/issues/16278#issuecomment-896157863

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[hiro]

also, maybe it's enough if we stop supporting tls1.2 ?
maybe tls1.1 and tls1.3 can be setup in a safe enough way already?

On 1/24/23, hiro <23hiro@gmail.com> wrote:
>> also, is there no way in openssl to turn off this behavior?
>
> https://github.com/openssl/openssl/issues/16278#issuecomment-896157863
>

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[kemal]

2023-01-23 13:16 GMT, hiro <23hiro@gmail.com>:
> 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.

i'd like to add to the discussion that i encountered with this
problem months ago, but with a custom firefox config:
https://github.com/arkenfox/user.js/blob/master/user.js#L423

i solved this "problem" by just disabling that setting, but it's
confusing that openssl adopted this practice too. i don't get
the point.

2023-01-24 0:16 GMT, hiro <23hiro@gmail.com>:
> also, maybe it's enough if we stop supporting tls1.2 ?
> maybe tls1.1 and tls1.3 can be setup in a safe enough way already?
that's a terrible idea, there are lots of clients that still don't have
tls 1.3, and tls 1.2 introduces tons of features that makes it more
secure than 1.1/1.0
plus someone would have to implement 1.3 :)

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[hiro]

> i'd like to add to the discussion that i encountered with this
> problem months ago, but with a custom firefox config:
> https://github.com/arkenfox/user.js/blob/master/user.js#L423
>
> i solved this "problem" by just disabling that setting, but it's
> confusing that openssl adopted this practice too. i don't get
> the point.
>
> 2023-01-24 0:16 GMT, hiro <23hiro@gmail.com>:
>> also, maybe it's enough if we stop supporting tls1.2 ?
>> maybe tls1.1 and tls1.3 can be setup in a safe enough way already?
> that's a terrible idea, there are lots of clients that still don't have
> tls 1.3, and tls 1.2 introduces tons of features that makes it more
> secure than 1.1/1.0
> plus someone would have to implement 1.3 :)
>

i dont know enough. what is the actual minimum  tls version enforced
by clients (i.e. no downgrade attacks possible)

seems useless to even twitch that tls1.3 finger until they make sure
downgrades to 1.2 arent possible (on our server side at least)

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[kemal]

2023-01-25 16:39 GMT, hiro <23hiro@gmail.com>:
> i dont know enough. what is the actual minimum  tls version enforced
> by clients (i.e. no downgrade attacks possible)
>
> seems useless to even twitch that tls1.3 finger until they make sure
> downgrades to 1.2 arent possible (on our server side at least)
>
oh i see what you mean.
if both server and client supports 1.3, there's no way of a downgrade.
both sides will definitely use 1.3.
so implementing tls1.3 could also work.

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[hiro]

well i know thats not the case. tls 1.3 downgrade attacks are always
possible atm.
what i wasnt sure is if downgrades to tls1.1 are still possible in practice.
i was just hoping that maybe one could save some effort and skip a
version, but i guess not.
and anyway dragons are lurking in tls1.3, too.

On 1/25/23, kemal <kemalinanc8@gmail.com> wrote:
> 2023-01-25 16:39 GMT, hiro <23hiro@gmail.com>:
>> i dont know enough. what is the actual minimum  tls version enforced
>> by clients (i.e. no downgrade attacks possible)
>>
>> seems useless to even twitch that tls1.3 finger until they make sure
>> downgrades to 1.2 arent possible (on our server side at least)
>>
> oh i see what you mean.
> if both server and client supports 1.3, there's no way of a downgrade.
> both sides will definitely use 1.3.
> so implementing tls1.3 could also work.
>

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[kemal]

2023-01-25 17:18 GMT, hiro <23hiro@gmail.com>:
> well i know thats not the case. tls 1.3 downgrade attacks are always
> possible atm.
> what i wasnt sure is if downgrades to tls1.1 are still possible in
> practice.
> i was just hoping that maybe one could save some effort and skip a
> version, but i guess not.
> and anyway dragons are lurking in tls1.3, too.
>

yes, you're right, tls1.3 definitely has vulns. it's just that no
downgrade attack is known, but someone may find one :)

downgrading to tls 1.1 wouldn't help, afaik the extension can be
used with 1.0-1.2 so openssl probably checks for the extension
in those versions too.

even if we tried to, the tls 1.3 spec mandates that the highest
supported version must be stated as 1.2, and 1.3 support stated
in a new extension. so i think we can't downgrade the handshake
to 1.1 or 1.0.

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[kemal]

2023-01-25 17:30 GMT, kemal <kemalinanc8@gmail.com>:
> even if we tried to, the tls 1.3 spec mandates that the highest
> supported version must be stated as 1.2, and 1.3 support stated
> in a new extension. so i think we can't downgrade the handshake
> to 1.1 or 1.0.
>
actually, i'm wrong.
the client sends the first message. (clienthello)
so if we see that client supports at best 1.2, we could pretend
like we just support 1.1/1.0. but as i said before, the extension
can be used with 1.0 and 1.1, so this wouldn't help at all.

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[hiro]

i'm not sure what you're saying there. i think you don't understand
the basics behind what a downgrade even is.

me, i'm missing out on the details what the common clients out there
demand to find as a minimum version.

On 1/25/23, kemal <kemalinanc8@gmail.com> wrote:
> 2023-01-25 17:30 GMT, kemal <kemalinanc8@gmail.com>:
>> even if we tried to, the tls 1.3 spec mandates that the highest
>> supported version must be stated as 1.2, and 1.3 support stated
>> in a new extension. so i think we can't downgrade the handshake
>> to 1.1 or 1.0.
>>
> actually, i'm wrong.
> the client sends the first message. (clienthello)
> so if we see that client supports at best 1.2, we could pretend
> like we just support 1.1/1.0. but as i said before, the extension
> can be used with 1.0 and 1.1, so this wouldn't help at all.
>

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[Frank D. Engel, Jr.]

Most common web browsers and many servers have dropped support for 
anything older than 1.2, so pretending to be 1.1 is not likely to be 
useful regardless.


On 1/26/23 3:54 PM, hiro wrote:
> i'm not sure what you're saying there. i think you don't understand
> the basics behind what a downgrade even is.
>
> me, i'm missing out on the details what the common clients out there
> demand to find as a minimum version.
>
> On 1/25/23, kemal <kemalinanc8@gmail.com> wrote:
>> 2023-01-25 17:30 GMT, kemal <kemalinanc8@gmail.com>:
>>> even if we tried to, the tls 1.3 spec mandates that the highest
>>> supported version must be stated as 1.2, and 1.3 support stated
>>> in a new extension. so i think we can't downgrade the handshake
>>> to 1.1 or 1.0.
>>>
>> actually, i'm wrong.
>> the client sends the first message. (clienthello)
>> so if we see that client supports at best 1.2, we could pretend
>> like we just support 1.1/1.0. but as i said before, the extension
>> can be used with 1.0 and 1.1, so this wouldn't help at all.
>>

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[kemal]

2023-01-26 21:52 GMT, Frank D. Engel, Jr. <fde101@fjrhome.net>:
> Most common web browsers and many servers have dropped support for
> anything older than 1.2, so pretending to be 1.1 is not likely to be
> useful regardless.

correct.
https://datatracker.ietf.org/doc/html/rfc8996
/lib/rfc/rfc8996

2023-01-26 20:54 GMT, hiro <23hiro@gmail.com>:
> i'm not sure what you're saying there. i think you don't understand
> the basics behind what a downgrade even is.
>
> me, i'm missing out on the details what the common clients out there
> demand to find as a minimum version.
>

i'm sorry, but i'm also not sure about what you're saying. why are
you asking this question?

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[hiro]

trying to make sure we're all able to argue based upon the same actual
real-world data.

me, i am too stupid to verify what you are saying. i tried.
firefox shows me the certificate, but not the used tls version. i have
no clue how to find out.

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[kemal]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

2023-01-27 10:55 GMT, hiro <23hiro@gmail.com>:
> trying to make sure we're all able to argue based upon the same actual
> real-world data.
>
> me, i am too stupid to verify what you are saying. i tried.
> firefox shows me the certificate, but not the used tls version. i have
> no clue how to find out.
>

no problem. you can click on the padlock in the url bar, and then
click on "secure connection" -> "more info". afterwards it should
pop up a window that shows information about the cipher, version
and certificate like in the attachment.

[-- Attachment #2: tls12.png --]
[-- Type: image/png, Size: 28813 bytes --]

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[ori]

Quoth Anthony Martin <ality@pbrane.org>:
> OpenSSL 3.0 clients refuse to connect to servers that do not
> support the renegotiation extension (RFC 5746) unless the default
> configuration is changed to allow it. Since we do not support
> renegotiation, we only need to make minor changes to the initial
> handshake to comply with the specification:
> 
> 1. For tlsClient, simply add the proper SCSV to the ClientHello
> cipher list (cf. RFC 5746 § 3.3);
> 
> 2. For tlsServer, respond with an empty renegotiation extension
> in the ServerHello if we received either the SCSV or an empty
> renegotiation extension in the ClientHello.
> 
> Since we close the hand file and never open it after the initial
> handshake, we can rely on tls(3) to send the "no renegotiation"
> alerts if subsequent handshake records are received.
> 

looks good; running this on shithub, will probably commit in the
next day or two assuming I don't run into problems.

thanks!

Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension

[cinap_lenrek]

lgtm.

--
cinap