On 20-04-07 22:52:28, Vitaliy Makkoveev wrote:
> nc started to work but mutt doesn???t.
> mutt now complains "No authenticators available???.

That's unrelated and most likely a mutt configuration issue - you'll
probably need 'set smtp_authenticators = ' with login or whatever is
appropriate for this SMTP server.

> > On 7 Apr 2020, at 20:49, Joel Sing <[email protected]> wrote:
> > 
> > On 20-04-07 17:29:21, Vitaliy Makkoveev wrote:
> >> On Tue, Apr 07, 2020 at 01:53:07PM +0100, Stuart Henderson wrote:
> >>> Forwarded from Vitaliy Makkoveev on misc@:
> >>>> After upgrading from 3 days old snapshot to 6.7-beta snapshot mutt can't
> >>>> send mail via yahoo's smtps. Error is "SSL failed: error:1404B3F2:SSL
> >>>> routines:ST_CONNECT:sslv3 alert unexpected message". mutt on this machine
> >>>> restored from backup to old snapshot works fine.
> >>>> 
> >>>> .muttrc contains:
> >>>> 
> >>>> ---- cut begin
> >>>> set smtp_pass = 'password'
> >>>> set smtp_url = 'smtps://[email protected]:465/'
> >>>> set ssl_starttls = yes
> >>>> set ssl_force_tls = yes
> >>>> ---- cut end
> >>>> 
> >>>> Can anybody help?
> >>>> 
> >>>> 
> >>> 
> >>> $ nc -vvc smtp.mail.yahoo.com 465
> >>> Connection to smtp.mail.yahoo.com (188.125.73.26) 465 port [tcp/smtps] 
> >>> succeeded!
> >>> nc: tls handshake failed (handshake failed: error:1404B3F2:SSL 
> >>> routines:ST_CONNECT:sslv3 alert unexpected message)
> >>> 
> >>> Unless I screwed up testing I don't think it is the "Send a zero-length
> >>> session identifier if TLSv1.3 is not enabled" commit but I don't see 
> >>> anything
> >>> else is in the time window...
> >>> 
> >> nc under osx and redhat works fine with this command. mutt works fine
> >> too.
> > 
> > This is likely a change on Yahoo's end rather than libssl - that said,
> > they're correctly complaining about the session ID is changing between
> > our first and second ClientHello messages (since they're sending a
> > HelloRetryRequest). The following diff addresses the issue.
> > 
> > Index: tls13_client.c
> > ===================================================================
> > RCS file: /cvs/src/lib/libssl/tls13_client.c,v
> > retrieving revision 1.47
> > diff -u -p -r1.47 tls13_client.c
> > --- tls13_client.c  6 Apr 2020 16:28:38 -0000       1.47
> > +++ tls13_client.c  7 Apr 2020 17:41:02 -0000
> > @@ -58,6 +58,19 @@ tls13_client_init(struct tls13_ctx *ctx)
> > 
> >     arc4random_buf(s->s3->client_random, SSL3_RANDOM_SIZE);
> > 
> > +   /*
> > +    * The legacy session identifier should either be set to an
> > +    * unpredictable 32-byte value or zero length... a non-zero length
> > +    * legacy session identifier triggers compatibility mode (see RFC 8446
> > +    * Appendix D.4). In the pre-TLSv1.3 case a zero length value is used.
> > +    */
> > +   if (ctx->hs->max_version >= TLS1_3_VERSION) {
> > +           arc4random_buf(ctx->hs->legacy_session_id,
> > +               sizeof(ctx->hs->legacy_session_id));
> > +           ctx->hs->legacy_session_id_len =
> > +               sizeof(ctx->hs->legacy_session_id);
> > +   }
> > +
> >     return 1;
> > }
> > 
> > @@ -176,14 +189,6 @@ tls13_client_hello_build(struct tls13_ct
> >     if (!CBB_add_bytes(cbb, s->s3->client_random, SSL3_RANDOM_SIZE))
> >             goto err;
> > 
> > -   /* Either 32-random bytes or zero length... */
> > -   if (ctx->hs->max_version >= TLS1_3_VERSION) {
> > -           arc4random_buf(ctx->hs->legacy_session_id,
> > -               sizeof(ctx->hs->legacy_session_id));
> > -           ctx->hs->legacy_session_id_len =
> > -               sizeof(ctx->hs->legacy_session_id);
> > -   }
> > -
> >     if (!CBB_add_u8_length_prefixed(cbb, &session_id))
> >             goto err;
> >     if (!CBB_add_bytes(&session_id, ctx->hs->legacy_session_id,
> 

Reply via email to