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

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

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

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

Re: Question about handshake error

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

Re: Question about handshake error

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

Re: Forthcoming OpenSSL release

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

Re: Forthcoming OpenSSL release

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

Re: Question about handshake error

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

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

(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

Re: Question about handshake error

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=

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

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 >

Re: Question about handshake error

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

Re: Question about handshake error

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

Re: Question about handshake error

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

Forthcoming OpenSSL release

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:

Re: Question about handshake error

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

Re: Question about handshake error

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

Re: Question about handshake error

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

Re: Question about handshake error

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

Re: Question about handshake error

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

Re: Question about handshake error

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

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

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

Re: Question about handshake error

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

Re: Question about handshake error

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

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

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

[FIPS] is EVP_des_ede_ecb permitted ?

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