libssl problem : "invalid digest length" when connecting to outlook.office365.com:993

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

libssl problem : "invalid digest length" when connecting to outlook.office365.com:993

Sebastien Marie-3
Hi,

Moving the thread to bugs@ has it seems to be an issue with libssl.

When connecting with nc(1) to outlook.office365.com:993, on older system
is able to connect and verify the connection. On a recent system, the
handshake failed due to "invalid digest length".


on "old" -current (snapshot):
        OpenBSD 6.4-current (GENERIC.MP) #419: Wed Oct 31 18:14:06 MDT 2018

$ nc -vvc outlook.office365.com 993
Connection to outlook.office365.com 993 port [tcp/imaps] succeeded!
TLS handshake negotiated TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384 with host outlook.office365.com
Peer name: outlook.office365.com
Subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=outlook.com
Issuer: /C=US/O=DigiCert Inc/CN=DigiCert Cloud Services CA-1
Valid From: Wed Aug  1 02:00:00 2018
Valid Until: Sat Aug  1 14:00:00 2020
Cert Hash: SHA256:47be4a2af4d726b98ad723eed11ec6cb7b58a9cae90d5638e96fb2b037f21fcd
OCSP URL: http://ocspx.digicert.com
OCSP Stapling: good
  response_status=0 cert_status=0 crl_reason=0
  this update: Tue Nov 13 00:24:08 2018
  next update: Mon Nov 19 23:39:08 2018
  revocation:
* OK The Microsoft Exchange IMAP4 service is ready. [QQBNADUAUABSADAANAAwADIAQwBBADAAMAAwADMALgBlAHUAcgBwAHIAZAAwADQALgBwAHIAbwBkAC4AbwB1AHQAbABvAG8AawAuAGMAbwBtAA==]


but on more recent system (manually built system):
        OpenBSD 6.4-current (GENERIC.MP) #18: Sun Nov 11 15:45:56 CET 2018

$ nc -vvc outlook.office365.com 993
Connection to outlook.office365.com 993 port [tcp/imaps] succeeded!
nc: tls handshake failed (handshake failed: error:04FFF08F:rsa routines:CRYPTO_internal:invalid digest length)

Something changed.

Thanks.
--
Sebastien Marie

On Tue, Nov 13, 2018 at 07:58:00AM +0000, Mikolaj Kucharski wrote:

> Hi,
>
> I just upgraded base system to:
>
> OpenBSD 6.4-current (GENERIC.MP) #437: Mon Nov 12 20:06:01 MST 2018
>     [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> and all packages to the latest snapshot at the time:
>
> $ pkg_info -f quirks | awk -F: '/digital-signature/ {print $2}'
> 2018-11-11T21
>
> $ pkg_info -qI offlineimap
> offlineimap-7.2.1
>
> I'm seeing this while OfflineIMAP 7.2.1 talks to outlook.office365.com:
>
>
> Establishing connection to outlook.office365.com:993 (Remote)
> ERROR: Unknown SSL protocol connecting to host 'outlook.office365.com' for repository 'Remote'. OpenSSL responded:
> [SSL: BAD_SIGNATURE] bad signature (_ssl.c:730)
>
> ..and connection closes. Is this known problem? I don't see this problem
> when OfflineIMAP talks to Google.
>
> Regards,
>  Mikolaj
>

--
Sebastien Marie

Reply | Threaded
Open this post in threaded view
|

Re: libssl problem : "invalid digest length" when connecting to outlook.office365.com:993

Stuart Henderson
On 2018/11/13 09:37, Sebastien Marie wrote:
> Hi,
>
> Moving the thread to bugs@ has it seems to be an issue with libssl.
>
> When connecting with nc(1) to outlook.office365.com:993, on older system
> is able to connect and verify the connection. On a recent system, the
> handshake failed due to "invalid digest length".

This is from the "Stop keeping track of sigalgs by guessing it from
digest and pkey" commit, too many commits on top for a simple revert.

---------------------
PatchSet 3125
Date: 2018/11/10 01:19:09
Author: beck
Branch: HEAD
Tag: (none)
Log:
Stop keeping track of sigalgs by guessing it from digest and pkey,
just keep the sigalg around so we can remember what we actually
decided to use.
ok jsing@

Members:
        ssl_cert.c:1.69->1.70
        ssl_clnt.c:1.40->1.41
        ssl_lib.c:1.191->1.192
        ssl_locl.h:1.223->1.224
        ssl_sigalgs.c:1.3->1.4
        ssl_sigalgs.h:1.4->1.5
        ssl_srvr.c:1.54->1.55
        t1_lib.c:1.149->1.150

---------------------

Reply | Threaded
Open this post in threaded view
|

Re: libssl problem : "invalid digest length" when connecting to outlook.office365.com:993

Sebastien Marie-3
On Tue, Nov 13, 2018 at 11:28:23AM +0000, Stuart Henderson wrote:
> On 2018/11/13 09:37, Sebastien Marie wrote:
> > Hi,
> >
> > Moving the thread to bugs@ has it seems to be an issue with libssl.
> >
> > When connecting with nc(1) to outlook.office365.com:993, on older system
> > is able to connect and verify the connection. On a recent system, the
> > handshake failed due to "invalid digest length".

another regression with www.videolan.org . it isn't the exact same error
"wrong signature type".

on snapshot: OpenBSD 6.4-current (GENERIC.MP) #437: Mon Nov 12 20:06:01 MST 2018

$ nc -vvc www.videolan.org 443
Connection to www.videolan.org 443 port [tcp/https] succeeded!
nc: tls handshake failed (handshake failed: error:14009172:SSL routines:CONNECT_CR_KEY_EXCH:wrong signature type)


> This is from the "Stop keeping track of sigalgs by guessing it from
> digest and pkey" commit, too many commits on top for a simple revert.
>
> ---------------------
> PatchSet 3125
> Date: 2018/11/10 01:19:09
> Author: beck
> Branch: HEAD
> Tag: (none)
> Log:
> Stop keeping track of sigalgs by guessing it from digest and pkey,
> just keep the sigalg around so we can remember what we actually
> decided to use.
> ok jsing@
>
> Members:
>         ssl_cert.c:1.69->1.70
>         ssl_clnt.c:1.40->1.41
>         ssl_lib.c:1.191->1.192
>         ssl_locl.h:1.223->1.224
>         ssl_sigalgs.c:1.3->1.4
>         ssl_sigalgs.h:1.4->1.5
>         ssl_srvr.c:1.54->1.55
>         t1_lib.c:1.149->1.150
>
> ---------------------
>

--
Sebastien Marie

Reply | Threaded
Open this post in threaded view
|

Re: libssl problem : "invalid digest length" when connecting to outlook.office365.com:993

Stuart Henderson
On 2018/11/13 14:41, Sebastien Marie wrote:

> On Tue, Nov 13, 2018 at 11:28:23AM +0000, Stuart Henderson wrote:
> > On 2018/11/13 09:37, Sebastien Marie wrote:
> > > Hi,
> > >
> > > Moving the thread to bugs@ has it seems to be an issue with libssl.
> > >
> > > When connecting with nc(1) to outlook.office365.com:993, on older system
> > > is able to connect and verify the connection. On a recent system, the
> > > handshake failed due to "invalid digest length".
>
> another regression with www.videolan.org . it isn't the exact same error
> "wrong signature type".
>
> on snapshot: OpenBSD 6.4-current (GENERIC.MP) #437: Mon Nov 12 20:06:01 MST 2018
>
> $ nc -vvc www.videolan.org 443
> Connection to www.videolan.org 443 port [tcp/https] succeeded!
> nc: tls handshake failed (handshake failed: error:14009172:SSL routines:CONNECT_CR_KEY_EXCH:wrong signature type)
>

And this one is from ssl_sigalgs.c 1.8 "Fix pkey_ok to be less strange"

Reply | Threaded
Open this post in threaded view
|

Re: libssl problem : "invalid digest length" when connecting to outlook.office365.com:993

Bob Beck-3
In reply to this post by Stuart Henderson
This is fixed, I had the wrong hash NID in the legacy sigalgs.

Interesting fact:  when the client sends sigalgs in order of
preference, mircosoft processes all of them for every cipher type, and
therefore chooses the weakest ;)
On Tue, Nov 13, 2018 at 4:28 AM Stuart Henderson <[hidden email]> wrote:

>
> On 2018/11/13 09:37, Sebastien Marie wrote:
> > Hi,
> >
> > Moving the thread to bugs@ has it seems to be an issue with libssl.
> >
> > When connecting with nc(1) to outlook.office365.com:993, on older system
> > is able to connect and verify the connection. On a recent system, the
> > handshake failed due to "invalid digest length".
>
> This is from the "Stop keeping track of sigalgs by guessing it from
> digest and pkey" commit, too many commits on top for a simple revert.
>
> ---------------------
> PatchSet 3125
> Date: 2018/11/10 01:19:09
> Author: beck
> Branch: HEAD
> Tag: (none)
> Log:
> Stop keeping track of sigalgs by guessing it from digest and pkey,
> just keep the sigalg around so we can remember what we actually
> decided to use.
> ok jsing@
>
> Members:
>         ssl_cert.c:1.69->1.70
>         ssl_clnt.c:1.40->1.41
>         ssl_lib.c:1.191->1.192
>         ssl_locl.h:1.223->1.224
>         ssl_sigalgs.c:1.3->1.4
>         ssl_sigalgs.h:1.4->1.5
>         ssl_srvr.c:1.54->1.55
>         t1_lib.c:1.149->1.150
>
> ---------------------
>

Reply | Threaded
Open this post in threaded view
|

Re: libssl problem : "invalid digest length" when connecting to outlook.office365.com:993

Bob Beck-3
In reply to this post by Stuart Henderson
On Tue, Nov 13, 2018 at 7:11 AM Stuart Henderson <[hidden email]> wrote:

>
> On 2018/11/13 14:41, Sebastien Marie wrote:
> > On Tue, Nov 13, 2018 at 11:28:23AM +0000, Stuart Henderson wrote:
> > > On 2018/11/13 09:37, Sebastien Marie wrote:
> > > > Hi,
> > > >
> > > > Moving the thread to bugs@ has it seems to be an issue with libssl.
> > > >
> > > > When connecting with nc(1) to outlook.office365.com:993, on older system
> > > > is able to connect and verify the connection. On a recent system, the
> > > > handshake failed due to "invalid digest length".
> >
> > another regression with www.videolan.org . it isn't the exact same error
> > "wrong signature type".
> >
> > on snapshot: OpenBSD 6.4-current (GENERIC.MP) #437: Mon Nov 12 20:06:01 MST 2018
> >
> > $ nc -vvc www.videolan.org 443
> > Connection to www.videolan.org 443 port [tcp/https] succeeded!
> > nc: tls handshake failed (handshake failed: error:14009172:SSL routines:CONNECT_CR_KEY_EXCH:wrong signature type)
> >
>
> And this one is from ssl_sigalgs.c 1.8 "Fix pkey_ok to be less strange"
>

I have worked around this, for now, however this is NOT a bug.  The
key they are using for the accepted sigalg does not use the right
curve,
So when we check for the curve, we should reject this signature ->
this site is doing it wrong.

I have disabled the check for now.  (meaning we will verify with the
wrong curve) and we'll revisit later depending on how much of a tire
fire related sites are.

Reply | Threaded
Open this post in threaded view
|

Re: libssl problem : "invalid digest length" when connecting to outlook.office365.com:993

Sebastien Marie-3
In reply to this post by Bob Beck-3
On Tue, Nov 13, 2018 at 08:40:58PM -0700, Bob Beck wrote:
> This is fixed, I had the wrong hash NID in the legacy sigalgs.
>
> Interesting fact:  when the client sends sigalgs in order of
> preference, mircosoft processes all of them for every cipher type, and
> therefore chooses the weakest ;)

now, I have another regression with ssl_sigalgs.c 1.10 :-)


$ nc -vvc -T ciphers=legacy -T protocols=legacy pop3.free.fr 995
Connection to pop3.free.fr 995 port [tcp/pop3s] succeeded!
nc: tls handshake failed (handshake failed: error:04FFF068:rsa routines:CRYPTO_internal:bad signature)


But if I use ssl_sigalgs.c 1.9, it is fine...

$ nc -vvc -T ciphers=legacy -T protocols=legacy pop3.free.fr 995
Connection to pop3.free.fr 995 port [tcp/pop3s] succeeded!
TLS handshake negotiated TLSv1/ECDHE-RSA-AES128-SHA with host pop3.free.fr
Peer name: pop3.free.fr
Subject: /CN=*.free.fr
Issuer: /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA
Valid From: Thu Jul 27 02:00:00 2017
Valid Until: Thu Aug  8 01:59:59 2019
Cert Hash: SHA256:9f32a1e1feee258fe14d103af98a017f208cd4795d88c681130919031e5d817d
OCSP URL: http://gp.symcd.com
+OK POP3 ready <1523817717.1542189303@popn2>


But it seems to me it it is odd: if I correctly understood, the change
occurs in tls1.2 stuff, and here the connection is done using tls1.

Thanks.
--
Sebastien Marie

Reply | Threaded
Open this post in threaded view
|

Re: libssl problem : "invalid digest length" when connecting to outlook.office365.com:993

Stuart Henderson
In reply to this post by Bob Beck-3
On 2018/11/13 20:43, Bob Beck wrote:

> I have worked around this, for now, however this is NOT a bug.  The
> key they are using for the accepted sigalg does not use the right
> curve,
> So when we check for the curve, we should reject this signature ->
> this site is doing it wrong.
>
> I have disabled the check for now.  (meaning we will verify with the
> wrong curve) and we'll revisit later depending on how much of a tire
> fire related sites are.
>

FWIW more "wrong signature type" errors (fixed with the workaround)
seen at:

https://ccache.samba.org/
https://rspamd.com/