> On 8 Apr 2020, at 19:26, Joel Sing <[email protected]> wrote:
>
> 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.
I reinstalled mutt and cyrus-sasl and mutt started to work.
Thanks for help.
>
>>> 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,
>>
