Re: [openssl-users] Somewhat conflicting configuration and strange behaviour
On 14.12.2013 00:00, Dr. Stephen Henson wrote: How are you disabling RSA key exchange? by setting all ciphers beginning with RSA to no in FF If you disable RSA for authentication too you'll hit problems if you don't have a non-RSA certificate. So for example: ECDHE-ECDSA-3DES-EDE-SHA needs an ECDSA certificate (that's the same as ECDHE-ECDSA-DES-CBC3-SHA). can you please give an example of such an ECDSA certificate? You can disable RSA key exchange by appending the string !kRSA to the cipher string, for example: DEFAULT:!kRSA. Also if you want to support EDH ciphersuites you need to set some DH parameters and for ECDH a suitable curve. this the option in squid against my client: http_port 3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/cert/squid.pem cipher=DEFAULT:!kRSA options=NO_SSLv2,SINGLE_DH_USE dhparams=/etc/squid/cert/dhparam.pem Thanks, Walter smime.p7s Description: S/MIME Cryptographic Signature
Re: [openssl-users] Somewhat conflicting configuration and strange behaviour
On 12.12.2013 14:16, Erwann Abalea wrote: It's not strange. You removed the RSA-* from client side, the result is that the server can't match anything in common between what the client proposed and what the server accepts. The error you get has been sent by the server. The server is capable of ciphers DHE-* and others; the list is quite longer than the avaiable ciphers of the client ..., so I think this is quite strange ... openssl ciphers -V shows e.g. ECDHE-ECDSA-DES-CBC3-SHA the site https://cc.dcsec.uni-hannover.de/ shows this: ECDHE-ECDSA-3DES-EDE-SHA are these the same cipher suites but two confusing names? Walter smime.p7s Description: S/MIME Cryptographic Signature
Re: [openssl-users] Somewhat conflicting configuration and strange behaviour
Le 13/12/2013 19:30, Walter H. a écrit : On 12.12.2013 14:16, Erwann Abalea wrote: It's not strange. You removed the RSA-* from client side, the result is that the server can't match anything in common between what the client proposed and what the server accepts. The error you get has been sent by the server. The server is capable of ciphers DHE-* and others; the list is quite longer than the avaiable ciphers of the client ..., so I think this is quite strange ... The ClientHello message will show what ciphersuite is proposed by the client. You'll have to match it with what the server is willing to accept. openssl ciphers -V shows e.g. ECDHE-ECDSA-DES-CBC3-SHA the site https://cc.dcsec.uni-hannover.de/ shows this: ECDHE-ECDSA-3DES-EDE-SHA are these the same cipher suites but two confusing names? I'd say yes, but what is really exchanged is a list of 16 bits numbers, not names. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Somewhat conflicting configuration and strange behaviour
it dpends how many characters differ when sorted. in this case: ECDHE-ECDSA-DES-CBC3-SHA - 3AABDDDHHSSS * *** ** ECDHE-ECDSA-3DES-EDE-SHA - 3AACCEEHHSSS you can see (marked by *) that 6 characters don't match. now 6 is a triangular number, but the length of the entire cipher suite is 24, which isn't triangule (the closest is 21). so they're only going to inter-operate on tuesdays. andrew On Fri, Dec 13, 2013 at 07:30:02PM +0100, Walter H. wrote: On 12.12.2013 14:16, Erwann Abalea wrote: It's not strange. You removed the RSA-* from client side, the result is that the server can't match anything in common between what the client proposed and what the server accepts. The error you get has been sent by the server. The server is capable of ciphers DHE-* and others; the list is quite longer than the avaiable ciphers of the client ..., so I think this is quite strange ... openssl ciphers -V shows e.g. ECDHE-ECDSA-DES-CBC3-SHA the site https://cc.dcsec.uni-hannover.de/ shows this: ECDHE-ECDSA-3DES-EDE-SHA are these the same cipher suites but two confusing names? Walter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Somewhat conflicting configuration and strange behaviour
sorry, that was a bad joke i now regret sending. andrew On Fri, Dec 13, 2013 at 04:01:23PM -0300, Andrew Cooke wrote: it dpends how many characters differ when sorted. in this case: ECDHE-ECDSA-DES-CBC3-SHA - 3AABDDDHHSSS * *** ** ECDHE-ECDSA-3DES-EDE-SHA - 3AACCEEHHSSS you can see (marked by *) that 6 characters don't match. now 6 is a triangular number, but the length of the entire cipher suite is 24, which isn't triangule (the closest is 21). so they're only going to inter-operate on tuesdays. andrew On Fri, Dec 13, 2013 at 07:30:02PM +0100, Walter H. wrote: On 12.12.2013 14:16, Erwann Abalea wrote: It's not strange. You removed the RSA-* from client side, the result is that the server can't match anything in common between what the client proposed and what the server accepts. The error you get has been sent by the server. The server is capable of ciphers DHE-* and others; the list is quite longer than the avaiable ciphers of the client ..., so I think this is quite strange ... openssl ciphers -V shows e.g. ECDHE-ECDSA-DES-CBC3-SHA the site https://cc.dcsec.uni-hannover.de/ shows this: ECDHE-ECDSA-3DES-EDE-SHA are these the same cipher suites but two confusing names? Walter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Somewhat conflicting configuration and strange behaviour
Don't regret it, it wasn't that bad ;) -- Erwann ABALEA Le 13/12/2013 20:39, andrew cooke a écrit : sorry, that was a bad joke i now regret sending. andrew On Fri, Dec 13, 2013 at 04:01:23PM -0300, Andrew Cooke wrote: it dpends how many characters differ when sorted. in this case: ECDHE-ECDSA-DES-CBC3-SHA - 3AABDDDHHSSS * *** ** ECDHE-ECDSA-3DES-EDE-SHA - 3AACCEEHHSSS you can see (marked by *) that 6 characters don't match. now 6 is a triangular number, but the length of the entire cipher suite is 24, which isn't triangule (the closest is 21). so they're only going to inter-operate on tuesdays. andrew On Fri, Dec 13, 2013 at 07:30:02PM +0100, Walter H. wrote: On 12.12.2013 14:16, Erwann Abalea wrote: It's not strange. You removed the RSA-* from client side, the result is that the server can't match anything in common between what the client proposed and what the server accepts. The error you get has been sent by the server. The server is capable of ciphers DHE-* and others; the list is quite longer than the avaiable ciphers of the client ..., so I think this is quite strange ... openssl ciphers -V shows e.g. ECDHE-ECDSA-DES-CBC3-SHA the site https://cc.dcsec.uni-hannover.de/ shows this: ECDHE-ECDSA-3DES-EDE-SHA are these the same cipher suites but two confusing names? Walter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Somewhat conflicting configuration and strange behaviour
well, i realised i couldn't answer the question seriously... what is ECDHE-ECDSA-3DES-EDE-SHA ? the only reference i can find on the web is to google chrome and firefox accepting it (a grep of openssl 1.0.1e fails to find it). does any server actually provide it? if so, what mode does it use (EDE is saying something about DES - how to build 3DES from DES - rather than giving a mode, isn't it?)? andrew On Fri, Dec 13, 2013 at 08:51:44PM +0100, Erwann Abalea wrote: Don't regret it, it wasn't that bad ;) -- Erwann ABALEA Le 13/12/2013 20:39, andrew cooke a écrit : sorry, that was a bad joke i now regret sending. andrew On Fri, Dec 13, 2013 at 04:01:23PM -0300, Andrew Cooke wrote: it dpends how many characters differ when sorted. in this case: ECDHE-ECDSA-DES-CBC3-SHA - 3AABDDDHHSSS * *** ** ECDHE-ECDSA-3DES-EDE-SHA - 3AACCEEHHSSS you can see (marked by *) that 6 characters don't match. now 6 is a triangular number, but the length of the entire cipher suite is 24, which isn't triangule (the closest is 21). so they're only going to inter-operate on tuesdays. andrew On Fri, Dec 13, 2013 at 07:30:02PM +0100, Walter H. wrote: On 12.12.2013 14:16, Erwann Abalea wrote: It's not strange. You removed the RSA-* from client side, the result is that the server can't match anything in common between what the client proposed and what the server accepts. The error you get has been sent by the server. The server is capable of ciphers DHE-* and others; the list is quite longer than the avaiable ciphers of the client ..., so I think this is quite strange ... openssl ciphers -V shows e.g. ECDHE-ECDSA-DES-CBC3-SHA the site https://cc.dcsec.uni-hannover.de/ shows this: ECDHE-ECDSA-3DES-EDE-SHA are these the same cipher suites but two confusing names? Walter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Somewhat conflicting configuration and strange behaviour
On 13.12.2013 21:16, andrew cooke wrote: well, i realised i couldn't answer the question seriously... what is ECDHE-ECDSA-3DES-EDE-SHA ? the only reference i can find on the web is to google chrome and firefox accepting it (a grep of openssl 1.0.1e fails to find it). does any server actually provide it? if so, what mode does it use (EDE is saying something about DES - how to build 3DES from DES - rather than giving a mode, isn't it?)? andrew exact this is my problem - I need a ciphersuite from the OpenSSL list, that matches one of the FF list and doesn't make use of RSA for key exchange ... Thanks, Walter smime.p7s Description: S/MIME Cryptographic Signature
Re: [openssl-users] Somewhat conflicting configuration and strange behaviour
well, not really, because in practice the name has to match, so you are stuck (as the earlier answer says). i guess the answer is somewhere in the nss code... andrew On Fri, Dec 13, 2013 at 10:04:52PM +0100, Walter H. wrote: On 13.12.2013 21:16, andrew cooke wrote: well, i realised i couldn't answer the question seriously... what is ECDHE-ECDSA-3DES-EDE-SHA ? the only reference i can find on the web is to google chrome and firefox accepting it (a grep of openssl 1.0.1e fails to find it). does any server actually provide it? if so, what mode does it use (EDE is saying something about DES - how to build 3DES from DES - rather than giving a mode, isn't it?)? andrew exact this is my problem - I need a ciphersuite from the OpenSSL list, that matches one of the FF list and doesn't make use of RSA for key exchange ... Thanks, Walter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Somewhat conflicting configuration and strange behaviour
On Fri, Dec 13, 2013, Walter H. wrote: On 13.12.2013 21:16, andrew cooke wrote: well, i realised i couldn't answer the question seriously... what is ECDHE-ECDSA-3DES-EDE-SHA ? the only reference i can find on the web is to google chrome and firefox accepting it (a grep of openssl 1.0.1e fails to find it). does any server actually provide it? if so, what mode does it use (EDE is saying something about DES - how to build 3DES from DES - rather than giving a mode, isn't it?)? andrew exact this is my problem - I need a ciphersuite from the OpenSSL list, that matches one of the FF list and doesn't make use of RSA for key exchange ... How are you disabling RSA key exchange? If you disable RSA for authentication too you'll hit problems if you don't have a non-RSA certificate. So for example: ECDHE-ECDSA-3DES-EDE-SHA needs an ECDSA certificate (that's the same as ECDHE-ECDSA-DES-CBC3-SHA). You can disable RSA key exchange by appending the string !kRSA to the cipher string, for example: DEFAULT:!kRSA. Also if you want to support EDH ciphersuites you need to set some DH parameters and for ECDH a suitable curve. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl-users] Somewhat conflicting configuration and strange behaviour
From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Walter H. snip The server is capable of ciphers DHE-* and others; the list is quite longer than the avaiable ciphers of the client ..., so I think this is quite strange ... openssl ciphers -V shows e.g. ECDHE-ECDSA-DES-CBC3-SHA the site https://cc.dcsec.uni-hannover.de/ shows this: ECDHE-ECDSA-3DES-EDE-SHA are these the same cipher suites but two confusing names? Yes. 3DES, 3DES*EDE, DES*EDE, DES*EDE*3, DES*3 and TDES are all the same algorithm (whose rarely-used official name is TDEA). 'EDE' is superfluous now; back in the nineties when (what is now) TDES was being developed there was some discussion whether to use all 'forward' primitives (EEE) or a mix (EDE). EDE was selected and has long been the only one used. The TLS RFCs use _3DES_EDE_CBC_, originally named during the time it was worthwhile to say EDE, and since retained for compatibility and consistency. I believe SSL 3 spec did also. OpenSSL for some reason, way back when, used -DES-CBC3-, and now needs to keep that for compatibility, except on the (much newer and disjoint) PSK and SRP suites. Leaving out 'CBC' for block ciphers, as that website does (for all not just TDES), seemed reasonable before TLSv1.2. Now it's inconsistent and could be confusing. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Somewhat conflicting configuration and strange behaviour
It's not strange. You removed the RSA-* from client side, the result is that the server can't match anything in common between what the client proposed and what the server accepts. The error you get has been sent by the server. -- Erwann ABALEA Le 11/12/2013 22:34, Walter H. a écrit : Hello, Thanks for your reply; Very strange in FF when I disable the use of the RSA-* Ciphersuites in FF, then I get the following error Secure Connection failed Cannot communicate securely with peer: no common encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap) the certificate is mimicked by the origin certificate - look on the origin certificate of https://www.google.nl Thanks, Walter On 11.12.2013 20:56, Erwann Abalea wrote: Bonjour, The certificate specifies digitalSignature as its sole key usage. That means the certified key can only be used to sign data, and not perform any decrypt operation. If your server+client are negotiating a (EC)DHE-RSA-* ciphersuite, that's OK because the server's RSA private key will then be used to sign the (EC)DHE parameters and ephemeral public key, and the key exchange mechanism will be based on (EC)DHE. But if the negotiated ciphersuite is AES-* or DES-* or RC4-* or anything similar using RSA as the key exchange mechanism, it won't work because the private key will then be used to decrypt the premaster secret. Only NSS checks this, so Firefox under any OS, and Chrome under Linux. If you want to get rid of this message, choose either one of: - create a new certificate for your server with keyUsage=digitalSignature+keyEncipherment - setup your server to only allow (EC)DHE key exchange mechanisms, by tweaking its acceptable ciphersuites __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Somewhat conflicting configuration and strange behaviour
Bonjour, The certificate specifies digitalSignature as its sole key usage. That means the certified key can only be used to sign data, and not perform any decrypt operation. If your server+client are negotiating a (EC)DHE-RSA-* ciphersuite, that's OK because the server's RSA private key will then be used to sign the (EC)DHE parameters and ephemeral public key, and the key exchange mechanism will be based on (EC)DHE. But if the negotiated ciphersuite is AES-* or DES-* or RC4-* or anything similar using RSA as the key exchange mechanism, it won't work because the private key will then be used to decrypt the premaster secret. Only NSS checks this, so Firefox under any OS, and Chrome under Linux. If you want to get rid of this message, choose either one of: - create a new certificate for your server with keyUsage=digitalSignature+keyEncipherment - setup your server to only allow (EC)DHE key exchange mechanisms, by tweaking its acceptable ciphersuites -- Erwann ABALEA Le 11/12/2013 20:29, Walter H. a écrit : [...] can please someone tell me why I get in FF (in an old 3.6 and in an relatively actual one 24.2esr) This Connection is Untrusted www.google.nl uses an invalid security certificate. The certificate is not trusted because it was issued by an invalid CA certificate. (Error code: sec_error_inadequate_key_usage) [...] -BEGIN CERTIFICATE- MIIFPTCCBKagAwIBAgIUPXX9MOspr8vFn1yK/75ufujyNyMwDQYJKoZIhvcNAQEF BQAwRzELMAkGA1UEBhMCLS0xEDAOBgNVBAoTB1NvbWVPcmcxFDASBgNVBAsTC1Nv bWVPcmdVbml0MRAwDgYDVQQDEwdSb290IENBMB4XDTEzMTEyMDE1MTMzNloXDTE0 MDMyMDAwMDAwMFowZjELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWEx FjAUBgNVBAcMDU1vdW50YWluIFZpZXcxEzARBgNVBAoMCkdvb2dsZSBJbmMxFTAT BgNVBAMMDCouZ29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 9Rn9qpNvO67yqcBIcmbcosnL5egvWbLyxzCsoIpk6s6IhqyDuLW8NW6gGXAo7tT9 BwF14xZnVVvFj7Oq4Nrl7bARIjvf9YEOo4uvypfMhIckVV0XB1TLs8fXUgBOCCc2 lzYEqqphzaGnMR2SAlexj2sQalb35RsianHNCgw/DEMCAwEAAaOCAwUwggMBMIIC wwYDVR0RBIICujCCAraCDCouZ29vZ2xlLmNvbYINKi5hbmRyb2lkLmNvbYIWKi5h cHBlbmdpbmUuZ29vZ2xlLmNvbYISKi5jbG91ZC5nb29nbGUuY29tghYqLmdvb2ds ZS1hbmFseXRpY3MuY29tggsqLmdvb2dsZS5jYYILKi5nb29nbGUuY2yCDiouZ29v Z2xlLmNvLmlugg4qLmdvb2dsZS5jby5qcIIOKi5nb29nbGUuY28udWuCDyouZ29v Z2xlLmNvbS5hcoIPKi5nb29nbGUuY29tLmF1gg8qLmdvb2dsZS5jb20uYnKCDyou Z29vZ2xlLmNvbS5jb4IPKi5nb29nbGUuY29tLm14gg8qLmdvb2dsZS5jb20udHKC DyouZ29vZ2xlLmNvbS52boILKi5nb29nbGUuZGWCCyouZ29vZ2xlLmVzggsqLmdv b2dsZS5mcoILKi5nb29nbGUuaHWCCyouZ29vZ2xlLml0ggsqLmdvb2dsZS5ubIIL Ki5nb29nbGUucGyCCyouZ29vZ2xlLnB0gg8qLmdvb2dsZWFwaXMuY26CFCouZ29v Z2xlY29tbWVyY2UuY29tgg0qLmdzdGF0aWMuY29tggwqLnVyY2hpbi5jb22CECou dXJsLmdvb2dsZS5jb22CFioueW91dHViZS1ub2Nvb2tpZS5jb22CDSoueW91dHVi ZS5jb22CFioueW91dHViZWVkdWNhdGlvbi5jb22CCyoueXRpbWcuY29tggthbmRy b2lkLmNvbYIEZy5jb4IGZ29vLmdsghRnb29nbGUtYW5hbHl0aWNzLmNvbYIKZ29v Z2xlLmNvbYISZ29vZ2xlY29tbWVyY2UuY29tggp1cmNoaW4uY29tggh5b3V0dS5i ZYILeW91dHViZS5jb22CFHlvdXR1YmVlZHVjYXRpb24uY29tMAsGA1UdDwQEAwIH gDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA4xQFls1FpUScdCmifTkWCrjNrgUCbL56im1/9vSqM P8IplBopOikz3VnxBsyUVaR/yt8zzm158zYdIpA/rOX0WukwO4pAUoi6aw6Q+FoD ZG+3Qe0b7a22Mqgl45OlfljrAMfouvapjx8OA9COSM/2k2TtRnlEy7D929O2H6J6 CQ== -END CERTIFICATE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
