Re: Negotiated cipher per proto (matching cipher in list missing). No further cipher order check has been done as order is determined by the client

[Kaushal Shriyan]

On Thu, Mar 12, 2020 at 1:01 AM Kyle Hamilton  wrote:

> ssl_prefer_server_ciphers on;
>
> On Wed, Mar 11, 2020, 11:58 Kaushal Shriyan 
> wrote:
>
>>
>>
>> On Wed, Mar 11, 2020 at 6:36 PM Michael Wojcik <
>> michael.woj...@microfocus.com> wrote:
>>
>>> To enforce the server's cipher order, use SSL_CTX_set_options(*ctx*,
>>> SSL_CTX_get_options(*ctx*) | SSL_OP_CIPHER_SERVER_PREFERENCE).
>>>
>>> https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_set_options.html
>>>
>>> --
>>>
>>>
>>> Testing server preferences
>>>  Has server cipher order? no (NOT ok)
>>>   ...
>>> No further cipher order check has been done as order is determined by
>>> the client
>>>
>>>
>>>
>> Hi Michael,
>>
>> Thanks for the email. I am not sure if i understand it completely. what
>> does the server's cipher order mean in layman's terms? Any example
>> regarding To enforce the server's cipher order, use
>> SSL_CTX_set_options(ctx, SSL_CTX_get_options(ctx) |
>> SSL_OP_CIPHER_SERVER_PREFERENCE) to set it in /etc/nginx/nginx.conf. I am
>> running Nginx web server.
>>
>> I have the below settings in /etc/nginx/nginx.conf
>>
>> server {
>> listen 443 ssl;
>> ssl_protocols TLSv1.2;
>> ssl_ciphers
>> ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
>> ssl_prefer_server_ciphers off;
>> }
>>
>> Please suggest. I look forward to hearing from you and thanks in advance.
>>
>> Best Regards,
>>
>> Kaushal
>>
>

Thanks Michael for the explanation and much appreciated. Thanks a lot, Kyle
for the reply.

Re: Negotiated cipher per proto (matching cipher in list missing). No further cipher order check has been done as order is determined by the client

[Kyle Hamilton]

ssl_prefer_server_ciphers on;

On Wed, Mar 11, 2020, 11:58 Kaushal Shriyan 
wrote:

>
>
> On Wed, Mar 11, 2020 at 6:36 PM Michael Wojcik <
> michael.woj...@microfocus.com> wrote:
>
>> To enforce the server's cipher order, use SSL_CTX_set_options(*ctx*,
>> SSL_CTX_get_options(*ctx*) | SSL_OP_CIPHER_SERVER_PREFERENCE).
>>
>> https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_set_options.html
>>
>> --
>>
>>
>> Testing server preferences
>>  Has server cipher order? no (NOT ok)
>>   ...
>> No further cipher order check has been done as order is determined by the
>> client
>>
>>
>>
> Hi Michael,
>
> Thanks for the email. I am not sure if i understand it completely. what
> does the server's cipher order mean in layman's terms? Any example
> regarding To enforce the server's cipher order, use
> SSL_CTX_set_options(ctx, SSL_CTX_get_options(ctx) |
> SSL_OP_CIPHER_SERVER_PREFERENCE) to set it in /etc/nginx/nginx.conf. I am
> running Nginx web server.
>
> I have the below settings in /etc/nginx/nginx.conf
>
> server {
> listen 443 ssl;
> ssl_protocols TLSv1.2;
> ssl_ciphers
> ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
> ssl_prefer_server_ciphers off;
> }
>
> Please suggest. I look forward to hearing from you and thanks in advance.
>
> Best Regards,
>
> Kaushal
>

Re: Question about handshake error

[Viktor Dukhovni]

On Wed, Mar 11, 2020 at 06:06:44PM +, Matt Caswell wrote:

> > if (!ssl_security_cert_sig(s, ctx, x, SSL_SECOP_CA_MD | vfy))
> > return SSL_R_CA_MD_TOO_WEAK;
> > return 1;
> > }
> 
> The exclusion comes in ssl_security_cert_sig - so I think OpenSSL
> behaves correctly:
> 
> static int ssl_security_cert_sig(SSL *s, SSL_CTX *ctx, X509 *x, int op)
> {
> /* Lookup signature algorithm digest */
> int secbits, nid, pknid;
> /* Don't check signature if self signed */
> if ((X509_get_extension_flags(x) & EXFLAG_SS) != 0)
> return 1;

So I failed to look just one more layer down the call stack. :-(
Thanks for the sanity check.

-- 
Viktor.

Re: Question about handshake error

[Matt Caswell]

On 11/03/2020 15:31, Viktor Dukhovni wrote:
> On Wed, Mar 11, 2020 at 03:12:26PM +, Matt Caswell wrote:
> 
>>> The signature algorithm security level is not expected to be enforced
>>> on self-signed certificates (root CAs).  How is it happening here?
>>
>> It isn't. In this case the client is openssl but the server is unknown.
>> The problem is on the server side. The server is refusing to continue a
>> handshake where the sigalgs do not include sha1 because the server is
>> misconfigured to include a root in the cert chain which has a SHA1
>> signature. The server is obviously inspecting the mis-configured chain,
>> seeing the SHA1 signature, and giving up. This is not an OpenSSL problem.
>>
> 
> I think the server could be OpenSSL, because why I made sure that
> self-signed CA signatures are not subjected to security levels in
> x509_vfy.c, the same exclusion does not appear to be present in:
> 
> int ssl_security_cert(SSL *s, SSL_CTX *ctx, X509 *x, int vfy, int is_ee)
> {
> if (vfy)
> vfy = SSL_SECOP_PEER;
> if (is_ee) {
> if (!ssl_security_cert_key(s, ctx, x, SSL_SECOP_EE_KEY | vfy))
> return SSL_R_EE_KEY_TOO_SMALL;
> } else {
> if (!ssl_security_cert_key(s, ctx, x, SSL_SECOP_CA_KEY | vfy))
> return SSL_R_CA_KEY_TOO_SMALL;
> }
> if (!ssl_security_cert_sig(s, ctx, x, SSL_SECOP_CA_MD | vfy))
> return SSL_R_CA_MD_TOO_WEAK;
> return 1;
> }
> 

The exclusion comes in ssl_security_cert_sig - so I think OpenSSL
behaves correctly:

static int ssl_security_cert_sig(SSL *s, SSL_CTX *ctx, X509 *x, int op)
{
/* Lookup signature algorithm digest */
int secbits, nid, pknid;
/* Don't check signature if self signed */
if ((X509_get_extension_flags(x) & EXFLAG_SS) != 0)
return 1;
if (!X509_get_signature_info(x, , , , NULL))
secbits = -1;
/* If digest NID not defined use signature NID */
if (nid == NID_undef)
nid = pknid;
if (s)
return ssl_security(s, op, secbits, nid, x);
else
return ssl_ctx_security(ctx, op, secbits, nid, x);
}

Matt

> which servers use to check *their own* chains.  This function needs to
> exclude self-signed certificates from the final "cert_sig" check.
> 
> The server's own chain is not always anchored to a root CA, so just
> excluding the "top" cert (as when peer certs are verified in the
> X.509 code) is not quite the right thing to do here, instead we
> should check is self-signed flag, something along the lines of:
> 
> if ((X509_get_extension_flags(x) & EXFLAG_SS) == 0
> && !ssl_security_cert_sig(s, ctx, x, SSL_SECOP_CA_MD | vfy))
> return SSL_R_CA_MD_TOO_WEAK;
> 

Re: Forthcoming OpenSSL release

[Matt Caswell]

On 11/03/2020 17:42, Sam Roberts wrote:
> Will it include ONLY the CVE fix, or will it include other fixes, such
> as to the getrandom() call on some archs?

It will include all fixes currently in the 1.1.1-dev branch including
commit eee565ec4 which is the 1.1.1 equivalent of the commit you mention.

Matt


> 
> commit 4dcb150ea30f9bbfa7946e6b39c30a86aca5ed02
> Author: Kurt Roeckx 
> Date:   Sat Sep 28 14:59:32 2019 +0200
> 
>   Add defines for __NR_getrandom for all Linux architectures
> 
>   Fixes: https://github.com/openssl/openssl/issues/10015
> 
>   Reviewed-by: Bernd Edlinger 
>   GH: https://github.com/openssl/openssl/pull/10044
> 
> See https://github.com/nodejs/node/pull/32002 for background.
> 
> On Wed, Mar 11, 2020 at 8:53 AM Matt Caswell  wrote:
>>
>> The OpenSSL project team would like to announce the forthcoming release
>> of OpenSSL version 1.1.1e.
>>
>> This release will be made available on Tuesday 17th March 2020 between
>> 1300-1700 UTC. This will contain one LOW severity fix for CVE-2019-1551
>> previously announced here:
>> https://www.openssl.org/news/secadv/20191206.txt
>>
>> Please see the following page for further details of severity levels:
>> https://www.openssl.org/policies/secpolicy.html
>>
>> Yours
>>
>> The OpenSSL Project Team
> 

Re: Forthcoming OpenSSL release

[Sam Roberts]

Will it include ONLY the CVE fix, or will it include other fixes, such
as to the getrandom() call on some archs?

commit 4dcb150ea30f9bbfa7946e6b39c30a86aca5ed02
Author: Kurt Roeckx 
Date:   Sat Sep 28 14:59:32 2019 +0200

  Add defines for __NR_getrandom for all Linux architectures

  Fixes: https://github.com/openssl/openssl/issues/10015

  Reviewed-by: Bernd Edlinger 
  GH: https://github.com/openssl/openssl/pull/10044

See https://github.com/nodejs/node/pull/32002 for background.

On Wed, Mar 11, 2020 at 8:53 AM Matt Caswell  wrote:
>
> The OpenSSL project team would like to announce the forthcoming release
> of OpenSSL version 1.1.1e.
>
> This release will be made available on Tuesday 17th March 2020 between
> 1300-1700 UTC. This will contain one LOW severity fix for CVE-2019-1551
> previously announced here:
> https://www.openssl.org/news/secadv/20191206.txt
>
> Please see the following page for further details of severity levels:
> https://www.openssl.org/policies/secpolicy.html
>
> Yours
>
> The OpenSSL Project Team

Re: Question about handshake error

[Matt Caswell]

On 11/03/2020 17:08, Niki Dinsey wrote:
> As for going back to the software vendor, I absolutely want to but don't
> hold out too much hope they will change anything. 
> I'm basically going to say this:
> 
> The certificate chain contains two redundant root certificates, these
> should be removed as there is no need to send root certificates and
> because they are signed with SHA1 stricter servers like Debian are
> dropping the connection.

Replace "stricter servers" with "stricter clients".

You might like to point them to my email explaining the issue in more
detail:

https://mta.openssl.org/pipermail/openssl-users/2020-March/012006.html


> 
> Does that sound about right?
> 
> As for the conversation with Viktor, it's all over my head! Can I just
> ignore and get back to work? Thanks again

Yes - ignore it. Viktor is suggesting that the unknown server that is
being used might actually be OpenSSL - in which case we might want to
make a change to our code so that it is more tolerant of this
mis-configuration. It makes no difference to you though.

Matt



> 
> Niki  
> 
> On Wed, 11 Mar 2020 at 15:33, Viktor Dukhovni
> mailto:openssl-us...@dukhovni.org>> wrote:
> 
> On Wed, Mar 11, 2020 at 11:31:51AM -0400, Viktor Dukhovni wrote:
> 
> > I think the server could be OpenSSL, because why I made sure that
> 
> s/why/while/.
> 
> > self-signed CA signatures are not subjected to security levels in
> > x509_vfy.c, the same exclusion does not appear to be present in:
> >
> >     int ssl_security_cert(SSL *s, SSL_CTX *ctx, X509 *x, int vfy,
> int is_ee)
> > [...]
> 
> -- 
>     Viktor.
> 
> 
> 
> -- 
> Niki Dinsey
> IS Manager
> 07974 214718
> 01235 849061 (x261)
> 
> Save the date: Abingdon's first 24hr *Giving Day - 18 March 2020*.
> Help support our ambition to double the number of bursaries across the
> Foundation.
> 
> 
> 
> 
> Abingdon School: A company limited by guarantee Registered in England
> and Wales. Company No. 3625063 
>  
> Registered Office: 
> Abingdon School 
> Park Road
> Abingdon 
> OX14 1DE 
> Registered Charity No. 1071298
>  
> All information in this message and attachments is confidential and may
> be legally privileged. Only intended recipients are authorised to use
> it. E-mail transmissions are not guaranteed to be secure or error free
> and the sender does not accept liability for such errors or omissions.
> The company will not accept any liability in respect of such
> communication that violates our ICT policies.

Re: Negotiated cipher per proto (matching cipher in list missing). No further cipher order check has been done as order is determined by the client

[Michael Wojcik]

(Please send messages to the list, not to me directly.)

In TLS, the client and server negotiate the cipher suite to use. The server 
makes the final decision. It can pick the client's most-preferred suite from 
among the ones they share, or it can pick the one it prefers. The current 
consensus seems to be that the best practice is to pick the suite the server 
most prefers. You can consult other references such as Ivan Ristic's 
/Bulletproof SSL and TLS/ book if you want more details.

Having the server pick the suite it prefers is known as enforcing the server's 
cipher-suite order.

The test you ran is complaining that the server does not enforce its 
cipher-suite order.

I explained how to do that in OpenSSL. How to do it in nginx is a question for 
the nginx project, not an OpenSSL problem.

Re: Question about handshake error

[Niki Dinsey]

Thanks Matt for your reply earlier, following your advice I've edited the
following line in my openssl.cnf file:

CipherString = DEFAULT@SECLEVEL=1

and it now works in s_client and curl:

niks@DESKTOP-O2VP5O2:/etc/ssl$ curl https://thankqcrm.accessacloud.com/
/?X-apikey=
{"Status":"OK","PageIndex":1,"PageSize":15,"PageCount":1,"Columns":[{"Name":"destinationCode","DataType":"Text","MaxLength":20},{"Name":"webDescriptionOverride","DataType":"Text","MaxLength":-1}],"Rows":[{"destinationCode":"BOARDING","webDescriptionOverride":"Boarding"},{"destinationCode":"BURSARYAS","webDescriptionOverride":"Bursaries"},{"destinationCode":"GIVING
DAY 2020","webDescriptionOverride":"GIVING DAY
2020"},{"destinationCode":"OTHER","webDescriptionOverride":"Other"},{"destinationCode":"PARTNER","webDescriptionOverride":"Partnerships"},{"destinationCode":"UNRESTRAS","webDescriptionOverride":"Unrestricted"}],"RecordCount":6,"RecordStartIndex":1}

Thanks so much for the help resolving the issue.

As for going back to the software vendor, I absolutely want to but don't
hold out too much hope they will change anything.
I'm basically going to say this:

The certificate chain contains two redundant root certificates, these
should be removed as there is no need to send root certificates and because
they are signed with SHA1 stricter servers like Debian are dropping the
connection.

Does that sound about right?

As for the conversation with Viktor, it's all over my head! Can I just
ignore and get back to work? Thanks again

Niki

On Wed, 11 Mar 2020 at 15:33, Viktor Dukhovni 
wrote:

> On Wed, Mar 11, 2020 at 11:31:51AM -0400, Viktor Dukhovni wrote:
>
> > I think the server could be OpenSSL, because why I made sure that
>
> s/why/while/.
>
> > self-signed CA signatures are not subjected to security levels in
> > x509_vfy.c, the same exclusion does not appear to be present in:
> >
> > int ssl_security_cert(SSL *s, SSL_CTX *ctx, X509 *x, int vfy, int
> is_ee)
> > [...]
>
> --
> Viktor.
>


-- 
Niki Dinsey
IS Manager
07974 214718
01235 849061 (x261)

-- 
Save the date: Abingdon's first 24hr *Giving Day - 18 March 2020*.Help 
support our ambition to double the number of bursaries across the 
Foundation.

 


-- 


Abingdon School: A company limited by guarantee Registered in England and 
Wales. Company No. 3625063 
 
Registered Office: 
Abingdon School 
Park 
Road
Abingdon 
OX14 1DE 
Registered Charity No. 1071298
 
All information 
in this message and attachments is confidential and may be legally 
privileged. Only intended recipients are authorised to use it. E-mail 
transmissions are not guaranteed to be secure or error free and the sender 
does not accept liability for such errors or omissions. The company will 
not accept any liability in respect of such communication that violates our 
ICT policies.

Re: Negotiated cipher per proto (matching cipher in list missing). No further cipher order check has been done as order is determined by the client

[Kaushal Shriyan]

On Wed, Mar 11, 2020 at 6:36 PM Michael Wojcik <
michael.woj...@microfocus.com> wrote:

> To enforce the server's cipher order, use SSL_CTX_set_options(*ctx*,
> SSL_CTX_get_options(*ctx*) | SSL_OP_CIPHER_SERVER_PREFERENCE).
>
> https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_set_options.html
>
> --
>
>
> Testing server preferences
>  Has server cipher order? no (NOT ok)
>   ...
> No further cipher order check has been done as order is determined by the
> client
>
>
>
Hi Michael,

Thanks for the email. I am not sure if i understand it completely. what
does the server's cipher order mean in layman's terms? Any example
regarding To enforce the server's cipher order, use
SSL_CTX_set_options(ctx, SSL_CTX_get_options(ctx) |
SSL_OP_CIPHER_SERVER_PREFERENCE) to set it in /etc/nginx/nginx.conf. I am
running Nginx web server.

I have the below settings in /etc/nginx/nginx.conf

server {
listen 443 ssl;
ssl_protocols TLSv1.2;
ssl_ciphers
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
}

Please suggest. I look forward to hearing from you and thanks in advance.

Best Regards,

Kaushal

Re: Question about handshake error

[Viktor Dukhovni]

On Wed, Mar 11, 2020 at 04:57:42PM +, Matt Caswell wrote:

> > Matt are you able to confirm whether the below is correct?  Perhaps
> > I should file a PR to address this if it is...
> 
> I will run some tests to confirm or deny what you think might be
> happening. Probably it will be tomorrow before I get to it.

That'd be great!  Thanks.

-- 
Viktor.

Re: Question about handshake error

[Matt Caswell]

On 11/03/2020 16:56, Viktor Dukhovni wrote:
> On Wed, Mar 11, 2020 at 03:12:26PM +, Matt Caswell wrote:
> 
>>> The signature algorithm security level is not expected to be enforced
>>> on self-signed certificates (root CAs).  How is it happening here?
>>
>> It isn't. In this case the client is openssl but the server is unknown.
>> The problem is on the server side. The server is refusing to continue a
>> handshake where the sigalgs do not include sha1 because the server is
>> misconfigured to include a root in the cert chain which has a SHA1
>> signature. The server is obviously inspecting the mis-configured chain,
>> seeing the SHA1 signature, and giving up. This is not an OpenSSL problem.
> 
> Matt are you able to confirm whether the below is correct?  Perhaps
> I should file a PR to address this if it is...

I will run some tests to confirm or deny what you think might be
happening. Probably it will be tomorrow before I get to it.

Matt


> 
> On Wed, Mar 11, 2020 at 11:32:58AM -0400, Viktor Dukhovni wrote:
> 
>>> self-signed CA signatures are not subjected to security levels in
>>> x509_vfy.c, the same exclusion does not appear to be present in:
>>>
>>> int ssl_security_cert(SSL *s, SSL_CTX *ctx, X509 *x, int vfy, int is_ee)
>>> [...]
> 

Re: Question about handshake error

[Viktor Dukhovni]

On Wed, Mar 11, 2020 at 03:12:26PM +, Matt Caswell wrote:

> > The signature algorithm security level is not expected to be enforced
> > on self-signed certificates (root CAs).  How is it happening here?
> 
> It isn't. In this case the client is openssl but the server is unknown.
> The problem is on the server side. The server is refusing to continue a
> handshake where the sigalgs do not include sha1 because the server is
> misconfigured to include a root in the cert chain which has a SHA1
> signature. The server is obviously inspecting the mis-configured chain,
> seeing the SHA1 signature, and giving up. This is not an OpenSSL problem.

Matt are you able to confirm whether the below is correct?  Perhaps
I should file a PR to address this if it is...

On Wed, Mar 11, 2020 at 11:32:58AM -0400, Viktor Dukhovni wrote:

> > self-signed CA signatures are not subjected to security levels in
> > x509_vfy.c, the same exclusion does not appear to be present in:
> > 
> > int ssl_security_cert(SSL *s, SSL_CTX *ctx, X509 *x, int vfy, int is_ee)
> > [...]

-- 
VIktor.

Forthcoming OpenSSL release

[Matt Caswell]

The OpenSSL project team would like to announce the forthcoming release
of OpenSSL version 1.1.1e.

This release will be made available on Tuesday 17th March 2020 between
1300-1700 UTC. This will contain one LOW severity fix for CVE-2019-1551
previously announced here:
https://www.openssl.org/news/secadv/20191206.txt

Please see the following page for further details of severity levels:
https://www.openssl.org/policies/secpolicy.html

Yours

The OpenSSL Project Team

Re: Question about handshake error

[Viktor Dukhovni]

On Wed, Mar 11, 2020 at 11:31:51AM -0400, Viktor Dukhovni wrote:

> I think the server could be OpenSSL, because why I made sure that

s/why/while/.

> self-signed CA signatures are not subjected to security levels in
> x509_vfy.c, the same exclusion does not appear to be present in:
> 
> int ssl_security_cert(SSL *s, SSL_CTX *ctx, X509 *x, int vfy, int is_ee)
> [...]

-- 
Viktor.

Re: Question about handshake error

[Viktor Dukhovni]

On Wed, Mar 11, 2020 at 03:12:26PM +, Matt Caswell wrote:

> > The signature algorithm security level is not expected to be enforced
> > on self-signed certificates (root CAs).  How is it happening here?
> 
> It isn't. In this case the client is openssl but the server is unknown.
> The problem is on the server side. The server is refusing to continue a
> handshake where the sigalgs do not include sha1 because the server is
> misconfigured to include a root in the cert chain which has a SHA1
> signature. The server is obviously inspecting the mis-configured chain,
> seeing the SHA1 signature, and giving up. This is not an OpenSSL problem.
> 

I think the server could be OpenSSL, because why I made sure that
self-signed CA signatures are not subjected to security levels in
x509_vfy.c, the same exclusion does not appear to be present in:

int ssl_security_cert(SSL *s, SSL_CTX *ctx, X509 *x, int vfy, int is_ee)
{
if (vfy)
vfy = SSL_SECOP_PEER;
if (is_ee) {
if (!ssl_security_cert_key(s, ctx, x, SSL_SECOP_EE_KEY | vfy))
return SSL_R_EE_KEY_TOO_SMALL;
} else {
if (!ssl_security_cert_key(s, ctx, x, SSL_SECOP_CA_KEY | vfy))
return SSL_R_CA_KEY_TOO_SMALL;
}
if (!ssl_security_cert_sig(s, ctx, x, SSL_SECOP_CA_MD | vfy))
return SSL_R_CA_MD_TOO_WEAK;
return 1;
}

which servers use to check *their own* chains.  This function needs to
exclude self-signed certificates from the final "cert_sig" check.

The server's own chain is not always anchored to a root CA, so just
excluding the "top" cert (as when peer certs are verified in the
X.509 code) is not quite the right thing to do here, instead we
should check is self-signed flag, something along the lines of:

if ((X509_get_extension_flags(x) & EXFLAG_SS) == 0
&& !ssl_security_cert_sig(s, ctx, x, SSL_SECOP_CA_MD | vfy))
return SSL_R_CA_MD_TOO_WEAK;

-- 
Viktor.

Re: Question about handshake error

[Matt Caswell]

On 11/03/2020 15:08, Viktor Dukhovni wrote:
> On Wed, Mar 11, 2020 at 12:15:32PM +, Matt Caswell wrote:
> 
>> I would recommend that the server operator removes both copies of the
>> root cert from its cert chain. Hopefully this should then mean that it
>> does not see the SHA1 root and will therefore continue the handshake. If
>> you can't get the server operator to make this change then, as a
>> workaround, you'd have to change your application configuration to add
>> back in the missing sigalgs and switch the security level to 0.
> 
> The signature algorithm security level is not expected to be enforced
> on self-signed certificates (root CAs).  How is it happening here?
> 

It isn't. In this case the client is openssl but the server is unknown.
The problem is on the server side. The server is refusing to continue a
handshake where the sigalgs do not include sha1 because the server is
misconfigured to include a root in the cert chain which has a SHA1
signature. The server is obviously inspecting the mis-configured chain,
seeing the SHA1 signature, and giving up. This is not an OpenSSL problem.

Matt

Re: Question about handshake error

[Viktor Dukhovni]

On Wed, Mar 11, 2020 at 12:15:32PM +, Matt Caswell wrote:

> I would recommend that the server operator removes both copies of the
> root cert from its cert chain. Hopefully this should then mean that it
> does not see the SHA1 root and will therefore continue the handshake. If
> you can't get the server operator to make this change then, as a
> workaround, you'd have to change your application configuration to add
> back in the missing sigalgs and switch the security level to 0.

The signature algorithm security level is not expected to be enforced
on self-signed certificates (root CAs).  How is it happening here?

-- 
Viktor.

Re: Question about handshake error

[Kurt Roeckx]

On Wed, Mar 11, 2020 at 12:15:32PM +, Matt Caswell wrote:
> 
> Debian 10 omits all the SHA1 entries from the above list. Note that
> Debian 10 will only allow SHA1 if the security level is explicitly set
> to 0 (via the -cipher "DEFAULT:@SECLEVEL=0" command line arg). Probably
> because the debian patch is the same as this one:
> 
> https://github.com/openssl/openssl/pull/10786

That patch is not applied. I assume that SECLEVEL=1 will allow
SHA1, but the default in Debian is SECLEVEL=2


Kurt

Re: Question about handshake error

[Kurt Roeckx]

On Wed, Mar 11, 2020 at 12:15:32PM +, Matt Caswell wrote:
> 
> I *think* what is happening is the server is checking the chain it has
> been configured with, spotting that it includes a SHA1 based signature
> and therefore refusing to respond at all because the client has not
> indicated SHA1 support. IIRC openssl is a little less strict in this
> regards and would send the certificate anyway if it doesn't have a
> better alternative.

That seems to be the same as:
https://github.com/openssl/openssl/issues/11236



Kurt

Re: Negotiated cipher per proto (matching cipher in list missing). No further cipher order check has been done as order is determined by the client

[Michael Wojcik]

To enforce the server's cipher order, use SSL_CTX_set_options(ctx, 
SSL_CTX_get_options(ctx) | SSL_OP_CIPHER_SERVER_PREFERENCE).

https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_set_options.html



Testing server preferences
 Has server cipher order? no (NOT ok)
  ...
No further cipher order check has been done as order is determined by the client

Re: Question about handshake error

[Matt Caswell]

On 11/03/2020 08:56, Niki Dinsey wrote:
> openssl s_client -connect thankqcrm.accessacloud.com:443
> 
> 
> * Debian 10 + 1.1.1d - Handshake Error  
> * Debian 9 + 1.1.0l - Working
> * Ubuntu 18.04 + 1.1.1  11 Sep 2018 -Working
> * Ubuntu 19.10 + 1.1.1c  28 May 2019 - Working
> * Ubuntu 20.04 + 1.1.1d - Handshake Error
> 
> The handshake errors can be bypassed using switch -tls1_1 on Debian 10
> 
> So I'm seeing a pattern here, as for what exactly I'm stumped! If
> anybody else can replicate using Debian 10 + 1.1.1d I'd appreciate it.
> But as for where to go from here I'm lost.

Hi Niki

I installed a Debian 10 VM and was able to reproduce this error.

AFAICT, this appears to be due to a combination of a server
mis-configuration, a slightly over-zealous server implementation
applying the standards, and a debian specific openssl patch.

I was able to isolate the difference between a successful handshake and
a failing handshake. This is in the "signature algorithms" (sigalgs)
extension of the ClientHello. This signals to the server what algorithms
the client is willing to accept for handshake and certificate signatures.

The important difference is that debian 10, by default, no longer seems
to include any sigalgs that are based on SHA1 due to security concerns
with that hash algorithm.

Looking at the certificate chain sent by the server it does indeed
include some certificates that are signed using SHA1. What is slightly
odd about the certificate chain sent be the server is that it includes
the root certificate - which is normally not sent (the client is
expected to have that certificate already in its trust store). It is
only the root certificate that is signed using SHA1. Even more strange
is that the server seems to be sending 2 copies of the root cert!

I *think* what is happening is the server is checking the chain it has
been configured with, spotting that it includes a SHA1 based signature
and therefore refusing to respond at all because the client has not
indicated SHA1 support. IIRC openssl is a little less strict in this
regards and would send the certificate anyway if it doesn't have a
better alternative.

I was able to get a successful connection from debian 10 using this
command line:

openssl s_client -connect thankqcrm.accessacloud.com:443 -sigalgs
"RSA+SHA256:RSA+SHA1" -cipher "DEFAULT:@SECLEVEL=0"

The full default sigalgs sent by a non-patched version of OpenSSL are:

ecdsa_secp256r1_sha256:ecdsa_secp384r1_sha384:ecdsa_secp521r1_sha512
:ed25519:ed448:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512
:rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512
:rsa_pkcs1_sha256:rsa_pkcs1_sha384:rsa_pkcs1_sha512:ECDSA+SHA224
:ECDSA+SHA1:RSA+SHA224:RSA+SHA1:DSA+SHA224:DSA+SHA256:DSA+SHA384
:DSA+SHA512

Debian 10 omits all the SHA1 entries from the above list. Note that
Debian 10 will only allow SHA1 if the security level is explicitly set
to 0 (via the -cipher "DEFAULT:@SECLEVEL=0" command line arg). Probably
because the debian patch is the same as this one:

https://github.com/openssl/openssl/pull/10786

Which was also applied to the mainline 1.1.1 dev branch - but we already
decided to revert it here:

https://github.com/openssl/openssl/pull/11282


I would recommend that the server operator removes both copies of the
root cert from its cert chain. Hopefully this should then mean that it
does not see the SHA1 root and will therefore continue the handshake. If
you can't get the server operator to make this change then, as a
workaround, you'd have to change your application configuration to add
back in the missing sigalgs and switch the security level to 0.

Matt

Re: Question about handshake error

[Niki Dinsey]

Sent this last night but got caught up for mod approval, switched images
for links.


Thanks so much for your replies, I really appreciate being able to talk
about this. I'm going to give you my full journey!

My normal prod server setup is Debian 10 LXC containers on a slightly older
Debian 9 host server running Proxmox 6 at OVH. This is where the problem
initially arose last week.

Any Debian 9 container on this server (all running 1.1.0l) connects fine:

https://drive.google.com/a/abingdon.org.uk/uc?id=1dGLmmaUe7ftQ_nbKtY67vONFp1HiDB3n

...but the Debian 10 containers all fail:

https://drive.google.com/a/abingdon.org.uk/uc?id=17slfkdhrSUP7Oi70KBWOBFZntJO6j-RC

My first thought was can I try to reproduce this on another Debian 10
server elsewhere.
I was able to reproduce this very easily using the Debian 'App' using
Windows 10 built-in Windows Subsystem for Linux (WSL) All I did was install
the WSL Debian app, apt update/upgrade and apt install openssl:

https://drive.google.com/a/abingdon.org.uk/uc?id=1Vo0lbZqAjrDidfFGNDOKpYHGjRp6Ba6U

I've also tried the Ubuntu App on WSL. Out of the box it uses 18.04 LTS and
OpenSSL 1.1.1 - It works!

https://drive.google.com/a/abingdon.org.uk/uc?id=1Vs8QInPE36BVz7j4G7N1wncmnrjZczax

I was suspicious about this '1.1.1 11 Sep 2018', and as I'm not too sure
how to upgrade this properly, I thought it was best just to upgrade the
Windows App Ubuntu VM to 19.10. This time the version was 1.1.1c 28 May
2019 and is still worked!

https://drive.google.com/a/abingdon.org.uk/uc?id=1h65oJB_iNAv3LW7henaV1LvLKgytV3ym

Again the OpenSSL version wasn't exactly the same 1.1.1c != 1.1.1d
Not really knowing how to upgrade OpenSSL without using apt, I thought I
might as well try to upgrade Ubuntu 20.04 LTS which isn't fully out yet but
worth a shot.
Finally, this development version of Ubuntu is running the same release of
OpenSSL 1.1.1d and guess what? It failed with the same error:

https://drive.google.com/a/abingdon.org.uk/uc?id=1MTMiEnB2rcDMecKh2mkXg-Dd-Gl3jAq5

This is when I thought it was time to jump on the mailing list.

Since you guys both mention it's working for you, I've also just ran this
on a brand new bare-metal server I've got for another project hosted at OVH
London. This again is Debian 10 / OpenSSL 1.1.1d and has the same result:

https://drive.google.com/a/abingdon.org.uk/uc?id=1G87_F2VqwbB2H1hNkOlsK0p3Prsikl-r


So in summary:

openssl s_client -connect thankqcrm.accessacloud.com:443

* Debian 10 + 1.1.1d - Handshake Error
* Debian 9 + 1.1.0l - Working
* Ubuntu 18.04 + 1.1.1  11 Sep 2018 -Working
* Ubuntu 19.10 + 1.1.1c  28 May 2019 - Working
* Ubuntu 20.04 + 1.1.1d - Handshake Error

The handshake errors can be bypassed using switch -tls1_1 on Debian 10

So I'm seeing a pattern here, as for what exactly I'm stumped! If anybody
else can replicate using Debian 10 + 1.1.1d I'd appreciate it. But as for
where to go from here I'm lost.

Again, thanks for your replies and help.

Niki


On Tue, 10 Mar 2020 at 18:03, Sergio NNX  wrote:

> It seems to work fine here!
>
>
>
>
>
>
>
>
>
>
> --
> *From:* openssl-users  on behalf of
> Matt Caswell 
> *Sent:* Wednesday, 11 March 2020 4:25 AM
> *To:* Niki Dinsey ; openssl-users@openssl.org
> 
> *Subject:* Re: Question about handshake error
>
>
>
> On 10/03/2020 17:05, Niki Dinsey wrote:
> > Hi there, I have an issue I can't seem to work out the answer to.
> >
> > Server: thankqcrm.accessacloud.com 
> >
> > root@willis:~# openssl version
> > OpenSSL 1.1.1d  10 Sep 2019
> > root@willis:~# openssl s_client -connect thankqcrm.accessacloud.com:443
> > 
>
> Running the exact same openssl version from my machine, and using the
> exact same s_client options as you, I get a successful connection.
>
> Some possibilities of what might be going wrong:
>
> 1) Is it possible there is some middlebox betwen you and the target
> server that is causing a problem for you on your network? Can you try
> connecting from s_client from a machine outside your corporate network?
>
> or
>
> 2) I have sometimes seen load balancers do strange things - where
> different machines in the cluster are configured differently to each
> other. This can mean different people see different results - or even if
> you run the same test at different times you see different results. This
> could explain why it works in 1.1.0 and not 1.1.1 (i.e. it actually is
> equally broken - but sometimes you hit the "right" server, and sometimes
> you hit the "wrong" server). You might want to try from a different
> machine and see if the same thing happens, and/or repeat the tests
> periodically (in the hope of hitting different servers in the cluster).
>
> or
>
> 3) Possibly there is some local problem with your s_client build. Does
> it work ok for other sites?
>
>
> Matt
>
>
> > CONNECTED(0004)
> > 140151269360768:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert

Re: Negotiated cipher per proto (matching cipher in list missing). No further cipher order check has been done as order is determined by the client

[Kaushal Shriyan]

On Tue, Mar 10, 2020 at 9:56 PM Kaushal Shriyan 
wrote:

> Hi,
>
> I have run the below tests
>
> ./testssl.sh gsmasslciphers.digitalapicraft.com
>> ###
>> testssl.sh   3.1dev from https://testssl.sh/dev/
>> (e0c83b2 2020-02-24 14:21:28 -- )
>>   This program is free software. Distribution and
>>  modification under GPLv2 permitted.
>>   USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!
>>Please file bugs @ https://testssl.sh/bugs/
>> ###
>>  Using "OpenSSL 1.0.2-chacha (1.0.2k-dev)" [~183 ciphers]
>>  on Kaushals-MacBook-Pro:./bin/openssl.Darwin.x86_64
>>  (built: "Feb 22 09:55:43 2019", platform: "darwin64-x86_64-cc")
>>
>>  Start 2020-03-10 21:50:25-->> 13.234.216.57:443 (
>> gsmasslciphers.digitalapicraft.com) <<--
>>  rDNS (13.234.216.57):   --
>>  Service detected:   HTTP
>>
>>  Testing protocols via sockets except NPN+ALPN
>>  SSLv2  not offered (OK)
>>  SSLv3  not offered (OK)
>>  TLS 1  not offered
>>  TLS 1.1not offered
>>  TLS 1.2offered (OK)
>>  TLS 1.3not offered and downgraded to a weaker protocol
>>  NPN/SPDY   h2, http/1.1 (advertised)
>>  ALPN/HTTP2 h2, http/1.1 (offered)
>>  Testing cipher categories
>>  NULL ciphers (no encryption)  not offered (OK)
>>  Anonymous NULL Ciphers (no authentication)not offered (OK)
>>  Export ciphers (w/o ADH+NULL) not offered (OK)
>>  LOW: 64 Bit + DES, RC[2,4] (w/o export)   not offered (OK)
>>  Triple DES Ciphers / IDEA not offered
>>  Obsolete: SEED + 128+256 Bit CBC cipher   not offered
>>  Strong encryption (AEAD ciphers)  offered (OK)
>>
>>  Testing robust (perfect) forward secrecy, (P)FS -- omitting Null
>> Authentication/Encryption, 3DES, RC4
>>  PFS is offered (OK)  ECDHE-RSA-AES256-GCM-SHA384
>> ECDHE-RSA-AES128-GCM-SHA256
>>  Elliptic curves offered: secp256k1 prime256v1 secp384r1 secp521r1
>>
>>  Testing server preferences
>>  Has server cipher order? no (NOT ok)
>>  Negotiated protocol  TLSv1.2
>>  Negotiated cipherECDHE-RSA-AES128-GCM-SHA256, 521 bit ECDH
>> (P-521) -- inconclusive test, matching cipher in list missing, better see
>> below
>>  Negotiated cipher per proto  (matching cipher in list missing)
>>  ECDHE-RSA-AES256-GCM-SHA384:   TLSv1.2
>>  No further cipher order check has been done as order is determined by
>> the client
>>
>>  Testing server defaults (Server Hello)
>>  TLS extensions (standard)"server name/#0" "renegotiation
>> info/#65281" "EC point formats/#11" "session ticket/#35" "heartbeat/#15"
>> "next protocol/#13172" "application layer protocol negotiation/#16"
>>  Session Ticket RFC 5077 hint 86400 seconds, session tickets keys seems
>> to be rotated < daily
>>  SSL Session ID support   yes
>>  Session Resumption   Tickets: yes, ID: yes
>>  TLS clock skew   Random values, no fingerprinting possible
>>  Signature Algorithm  SHA256 with RSA
>>  Server key size  RSA 2048 bits
>>  Server key usage Digital Signature, Key Encipherment
>>  Server extended key usageTLS Web Server Authentication, TLS Web
>> Client Authentication
>>  Serial / Fingerprints03C871BF68E569B4330E4AFCFA7752AAB5D7 / SHA1
>> 8874D965CB96F4A4B8B4CCAE149B6F1999399BF8
>>   SHA256
>> BB56659442E2ED18778F7BB210823F3A81DA88F3AF79D0EE2104CE82DBB03C65
>>  Common Name (CN) gsmasslciphers.digitalapicraft.com
>>  subjectAltName (SAN) gsmasslciphers.digitalapicraft.com
>>  Issuer   Let's Encrypt Authority X3 (Let's Encrypt
>> from US)
>>  Trust (hostname) Ok via SAN (same w/o SNI)
>>  Chain of trust   Ok
>>  EV cert (experimental)   no
>>  ETS/"eTLS", visibility info  not present
>>  Certificate Validity (UTC)   89 >= 30 days (2020-03-10 09:40 -->
>> 2020-06-08 09:40)
>>  # of certificates provided   2
>>  Certificate Revocation List  --
>>  OCSP URI http://ocsp.int-x3.letsencrypt.org
>>  OCSP staplingnot offered
>>  OCSP must staple extension   --
>>  DNS CAA RR (experimental)not offered
>>  Certificate Transparency yes (certificate extension)
>>
>>  Testing HTTP header response @ "/"
>>  HTTP Status Code 200 OK
>>  HTTP clock skew  0 sec from localtime
>>  Strict Transport Security730 days=63072000 s, just this domain
>>  Public Key Pinning   --
>>  Server bannernginx/1.16.1
>>  Application banner   --
>>  Cookie(s)(none issued at "/")
>>  Security headers --
>>  Reverse Proxy banner --
>>
>>  Testing vulnerabilities
>>  Heartbleed (CVE-2014-0160)not vulnerable (OK), timed out
>>  CCS (CVE-2014-0224)   not vulnerable (OK)
>>  

[FIPS] is EVP_des_ede_ecb permitted ?

[Akshar Kanak]

Dear team
 In FIPS mode is the cipher "EVP_des_ede_ecb" permitted or not ?

If i check the openssl.org fipscansitor code then in the file
fips_des_selftest.c , I can see that the self test for only
EVP_des_ede3_ecb is being done .

In Centos openssl code (openssl-1.0.2k-19.el7.src.rpm) , in the file
fips_des_selftest.c , function FIPS_selftest_des() I can see that the self
test for both EVP_des_ede_ecb and EVP_des_ede3_ecb .

Thanks and regards
Akshar