> On 7 Apr 2020, at 22:52, Vitaliy Makkoveev <[email protected]> wrote:
> 
> nc started to work but mutt doesn’t.
> mutt now complains "No authenticators available”.
With this diff applied of course.

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