Re: 019_libssl.patch regression
Theo Buehler wrote:
> On Tue, Aug 11, 2020 at 05:26:22PM -0400, Predrag Punosevac wrote:
> > This is a regression report for 019_libssl.patch
> > After applying libssl binary patch to 6.7 release s-nail-14.9.19 can no
> > longer close STARTTLS IPMI session with Gmail server. I recompiled
> > s-nail and rebooted the machine. After reverting the patch s-nail works
> > as expected. Interestingly enough I can only see this with Gmail
> > servers. 019_libssl.patch doesn't break Hotmail IPMI connection. Patch
> > does break SMTP session with Gmail server in the same fashion as IPMI.
> > It just doesn't terminate cleanly. I don't know enough about the subject
> > to look further into the problem but I am 100% sure this is LibreSSL
> > bug.
>
> Thanks for the report. Could you give this patch a spin on a -stable
> system, that is, on top of the 019_libssl patch?
>
> Index: lib/libssl/tls13_legacy.c
> ===
> RCS file: /var/cvs/src/lib/libssl/tls13_legacy.c,v
> retrieving revision 1.3.4.2
> diff -u -p -r1.3.4.2 tls13_legacy.c
> --- lib/libssl/tls13_legacy.c 10 Aug 2020 18:59:47 - 1.3.4.2
> +++ lib/libssl/tls13_legacy.c 12 Aug 2020 18:46:12 -
> @@ -497,6 +497,7 @@ tls13_legacy_shutdown(SSL *ssl)
> if ((ret = tls13_record_layer_send_pending(ctx->rl)) !=
> TLS13_IO_SUCCESS)
> return tls13_legacy_return_code(ssl, ret);
> + ctx->close_notify_sent = 1;
^
Right on the money! That did the trick. The patch works for me. Theo
thank you so much for patching this so quickly. Thank you Steffen for
figuring out the problem from my initial report.
Cheers,
Predrag
> } else if (!ctx->close_notify_recv) {
> /*
>* If there is no application data pending, attempt to read more
Re: 019_libssl.patch regression
On Tue, Aug 11, 2020 at 05:26:22PM -0400, Predrag Punosevac wrote:
> This is a regression report for 019_libssl.patch
> After applying libssl binary patch to 6.7 release s-nail-14.9.19 can no
> longer close STARTTLS IPMI session with Gmail server. I recompiled
> s-nail and rebooted the machine. After reverting the patch s-nail works
> as expected. Interestingly enough I can only see this with Gmail
> servers. 019_libssl.patch doesn't break Hotmail IPMI connection. Patch
> does break SMTP session with Gmail server in the same fashion as IPMI.
> It just doesn't terminate cleanly. I don't know enough about the subject
> to look further into the problem but I am 100% sure this is LibreSSL
> bug.
Thanks for the report. Could you give this patch a spin on a -stable
system, that is, on top of the 019_libssl patch?
Index: lib/libssl/tls13_legacy.c
===
RCS file: /var/cvs/src/lib/libssl/tls13_legacy.c,v
retrieving revision 1.3.4.2
diff -u -p -r1.3.4.2 tls13_legacy.c
--- lib/libssl/tls13_legacy.c 10 Aug 2020 18:59:47 - 1.3.4.2
+++ lib/libssl/tls13_legacy.c 12 Aug 2020 18:46:12 -
@@ -497,6 +497,7 @@ tls13_legacy_shutdown(SSL *ssl)
if ((ret = tls13_record_layer_send_pending(ctx->rl)) !=
TLS13_IO_SUCCESS)
return tls13_legacy_return_code(ssl, ret);
+ ctx->close_notify_sent = 1;
} else if (!ctx->close_notify_recv) {
/*
* If there is no application data pending, attempt to read more
Re: 019_libssl.patch regression
Steffen Nurpmeso wrote in <20200812132648.kaxsj%stef...@sdaoden.eu>: |Steffen Nurpmeso wrote in | <20200812130039.lto3i%stef...@sdaoden.eu>: ||Predrag Punosevac wrote in || <20200811212622.ugmda%punoseva...@gmail.com>: |||This is a regression report for 019_libssl.patch | ... |||After applying libssl binary patch to 6.7 release s-nail-14.9.19 can no |||longer close STARTTLS IPMI session with Gmail server. I recompiled | ... ||Hmm. I can reproduce this here indeed. | ... || nail: >>> QUIT || nail: >>> SERVER: 221 2.0.0 closing connection g9sm1477447ejf.101 \ || - gsmtp || ||And here it hangs endlessly. For now i presume it hangs at || || while (!SSL_shutdown(s_tls)) /* XXX proper error handling;signals! */ ||; | |I can confirm we have an endless loop in SSL_shutdown() here. P.S.: this is ugly code. P.P.S.: new OpenSSL documents that SSL_read() should be used instead of a second SSL_shutdown(). I will ask about that on a openssl-user list when i find some head. But .. will this work with libressl too?? Thanks. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: 019_libssl.patch regression
Steffen Nurpmeso wrote in <20200812130039.lto3i%stef...@sdaoden.eu>: |Predrag Punosevac wrote in | <20200811212622.ugmda%punoseva...@gmail.com>: ||This is a regression report for 019_libssl.patch ... ||After applying libssl binary patch to 6.7 release s-nail-14.9.19 can no ||longer close STARTTLS IPMI session with Gmail server. I recompiled ... |Hmm. I can reproduce this here indeed. ... | nail: >>> QUIT | nail: >>> SERVER: 221 2.0.0 closing connection g9sm1477447ejf.101 - gsmtp | |And here it hangs endlessly. For now i presume it hangs at | | while (!SSL_shutdown(s_tls)) /* XXX proper error handling;signals! */ |; I can confirm we have an endless loop in SSL_shutdown() here. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: 019_libssl.patch regression
Hello Predrag, all.
Predrag Punosevac wrote in
<20200811212622.ugmda%punoseva...@gmail.com>:
|This is a regression report for 019_libssl.patch
|
|predrag@oko$ uname -a
|OpenBSD oko.int.bagdala2.net 6.7 GENERIC.MP#5 amd64
|predrag@oko$ syspatch -l
|001_wscons
|002_rpki
|003_ssh
|004_libssl
|005_unbound
|006_smtpd_sockaddr
|007_perl
|008_hid
|009_asr
|010_x509
|011_shmget
|012_tty
|013_tty
|014_iked
|015_rpki
|016_ximcp
|017_dix
|018_ximcp
|019_libssl
|
|After applying libssl binary patch to 6.7 release s-nail-14.9.19 can no
|longer close STARTTLS IPMI session with Gmail server. I recompiled
|s-nail and rebooted the machine. After reverting the patch s-nail works
|as expected. Interestingly enough I can only see this with Gmail
|servers. 019_libssl.patch doesn't break Hotmail IPMI connection. Patch
|does break SMTP session with Gmail server in the same fashion as IPMI.
|It just doesn't terminate cleanly. I don't know enough about the subject
|to look further into the problem but I am 100% sure this is LibreSSL
|bug.
Hmm. I can reproduce this here indeed.
nail: Resolving host smtp.gmail.com:587 ... done
nail: Connecting to 108.177.126.109:587 ... connected.
nail: >>> SERVER: 220 smtp.gmail.com ESMTP g9sm1477447ejf.101 - gsmtp
nail: >>> EHLO gmail.com
nail: >>> SERVER: 250-smtp.gmail.com at your service, [109.40.130.60]
...
nail: >>> STARTTLS
nail: >>> SERVER: 220 2.0.0 Ready to start TLS
nail: TLS: applying config: CipherString = TLSv1.2:!aNULL:!eNULL
nail: TLS: applying config: MinProtocol = TLSv1.2
nail: Certificate depth 2
nail: subject = /OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
nail: notBefore = Dec 15 08:00:00 2006 GMT
nail: notAfter = Dec 15 08:00:00 2021 GMT
nail: issuer = /OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
nail: Certificate depth 1
nail: subject = /C=US/O=Google Trust Services/CN=GTS CA 1O1
nail: notBefore = Jun 15 00:00:42 2017 GMT
nail: notAfter = Dec 15 00:00:42 2021 GMT
nail: issuer = /OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
nail: Certificate depth 0
nail: subject = /C=US/ST=California/L=Mountain View/O=Google
LLC/CN=smtp.gmail.com
nail: notBefore = Jul 15 08:33:08 2020 GMT
nail: notAfter = Oct 7 08:33:08 2020 GMT
nail: issuer = /C=US/O=Google Trust Services/CN=GTS CA 1O1
nail: Comparing subject_alt_name: need is
nail: TLS certificate ok
nail: TLS SHA256 fingerprint:
7B:2D:63:EC:E2:4C:D5:BB:33:00:A5:65:A0:67:DA:1B:C6:B8:1F:88:6E:6B:67:78:D7:6A:AC:93:94:6E:9F:9F
nail: TLS connection using ? / AEAD-AES256-GCM-SHA384
This ? is, interesting, the "None" of
static struct a_xtls_protocol const a_xtls_protocols[] = {
{"ALL", SSL_OP_NO_SSL_MASK, 0, FAL0, TRU1, FAL0, TRU1, {0}},
{"TLSv1.3\0", SSL_OP_NO_TLSv1_3, TLS1_3_VERSION, TRU1,TRU1,FAL0,FAL0,{0}},
{"TLSv1.2", SSL_OP_NO_TLSv1_2, TLS1_2_VERSION, TRU1, TRU1, FAL0, FAL0,
{0}},
{"TLSv1.1", SSL_OP_NO_TLSv1_1, TLS1_1_VERSION, TRU1, TRU1, FAL0, FAL0,
{0}},
{"TLSv1", SSL_OP_NO_TLSv1, TLS1_VERSION, TRU1, TRU1, FAL0, FAL0, {0}},
{"SSLv3", SSL_OP_NO_SSLv3, SSL3_VERSION, TRU1, TRU1, FAL0, FAL0, {0}},
{"SSLv2", SSL_OP_NO_SSLv2, SSL2_VERSION, TRU1, TRU1, FAL0, FAL0, {0}},
{"None", SSL_OP_NO_SSL_MASK, 0, TRU1, FAL0, TRU1, FAL0, {0}}
};
after
ver = SSL_version(sop->s_tls);
for(xpp = &a_xtls_protocols[1] /* [0] == ALL */;; ++xpp)
if(xpp->xp_version == ver || xpp->xp_last){
n_err(_("TLS connection using %s / %s\n"),
(xpp->xp_last ? n_qm : xpp->xp_name),
SSL_get_cipher(sop->s_tls));
break;
}
}
I have to look there when i have time, maybe!?!
nail: >>> EHLO gmail.com
nail: >>> SERVER: 250-smtp.gmail.com at your service, [109.40.130.60]
...
nail: >>> AUTH PLAIN
nail: >>> SERVER: 334
...
nail: >>> SERVER: 354 Go ahead g9sm1477447ejf.101 - gsmtp
...
nail: >>> .
nail: >>> SERVER: 250 2.0.0 OK 1597236652 g9sm1477447ejf.101 - gsmtp
nail: >>> QUIT
nail: >>> SERVER: 221 2.0.0 closing connection g9sm1477447ejf.101 - gsmtp
And here it hangs endlessly. For now i presume it hangs at
while (!SSL_shutdown(s_tls)) /* XXX proper error handling;signals! */
;
Because the final SMTP answer has been successfully received. But
i am a bit out of ideas at the moment since i need to -KILL it, no
other signal gets through, and our socket_close() does not catch
signals. I will look a bit.
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
