RE: CBC issue with 1.0.1e?: hello timeout again
>From: owner-openssl-us...@openssl.org On Behalf Of Toland Hon >Sent: Thursday, 30 May, 2013 22:22 >I'm on Mac running OS X 10.8.3 and have 2 versions of openssl installed: >* Default: OpenSSL 0.9.8r 8 Feb 2011 >* Homebrew: OpenSSL 1.0.1e 11 Feb 2013 >My most recent version of ruby (1.9.3-p429) is linked with Homebrew's openssl >and [] I began having [timeout] to a particular website. >I noticed there was a recent security bulletin and a fix in regards to CBC ciphers: >http://www.openssl.org/news/secadv_20130205.txt >I was curious if this security fix introduced a bug that has problems >connecting to certain websites using CBC cipher >or is there something incorrectly configured on this server? The "Lucky13" issue wouldn't affect handshake at all. It would affect performance during data phase if there is (underlying) data alteration accidentally or due to attack. This is most likely another case of the frequently reported (and discussed) issue that 1.0.1 implements TLS1.2, which has more ciphersuites enabled by default and additional extensions, which together make the ClientHello bigger, and some server implementations apparently can't cope. It appears in at least many cases the cutoff is 256 bytes, suggesting these servers don't handle 2-byte length right. It's unlikely that this would be explicitly configured on a server, rather it would be an implementation flaw that previously did not cause a problem. It might occur in an older version of server software fixed in a newer version. For many details see http://rt.openssl.org/Ticket/Display.html?id=2771&user=guest&pass=guest Short answer is that restricting to TLS1(.0), and/or a smaller list of ciphersuites (but still enough to intersect with the server), likely works. Both do for me using 1.0.1e to your example host. You can use -msg in s_client to see exactly how much (and what) is sent for different options. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL connection issue with 1.0.1e
Sorry, openssl 1.0.1e eventually times out and returns: CONNECTED(0003) write:errno=54 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 322 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- //Toland (^_^x) On May 30, 2013, at 7:06 PM, Toland Hon wrote: > Hi, > > I'm on Mac running OS X 10.8.3 and have 2 versions of openssl installed: > > Default: OpenSSL 0.9.8r 8 Feb 2011 > Homebrew: OpenSSL 1.0.1e 11 Feb 2013 > > My most recent version of ruby (1.9.3-p429) is linked with Homebrew's openssl > and that's when I noticed I began having connection problems to a particular > website. > > Using 0.9.8r and running the following command: > openssl s_client -connect secure.networkmerchants.com:443 > > I get: > CONNECTED(0003) > depth=2 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 > VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary > Certification Authority - G5 > verify error:num=20:unable to get local issuer certificate > verify return:0 > --- > Certificate chain > 0 > s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Illinois/businessCategory=Private > Organization/serialNumber=61786708/C=US/ST=Illinois/L=Schaumburg/O=Network > Merchants, Inc./OU=E-Commerce/OU=Terms of use at www.verisign.com/rpa > (c)05/CN=secure.networkmerchants.com >i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at > https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation > SSL SGC CA > 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at > https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation > SSL SGC CA >i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, > Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary > Certification Authority - G5 > 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, > Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary > Certification Authority - G5 >i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority > --- > Server certificate > -BEGIN CERTIFICATE- > MIIGRDCCBSygAwIBAgIQU7qHQ3XVIaI9AqOwrVHOTTANBgkqhkiG9w0BAQUFADCB > vjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL > ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug > YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNjE4MDYGA1UEAxMv > VmVyaVNpZ24gQ2xhc3MgMyBFeHRlbmRlZCBWYWxpZGF0aW9uIFNTTCBTR0MgQ0Ew > HhcNMTEwNTE2MDAwMDAwWhcNMTMwNjA3MjM1OTU5WjCCASkxEzARBgsrBgEEAYI3 > PAIBAxMCVVMxGTAXBgsrBgEEAYI3PAIBAhQISWxsaW5vaXMxHTAbBgNVBA8TFFBy > aXZhdGUgT3JnYW5pemF0aW9uMREwDwYDVQQFEwg2MTc4NjcwODELMAkGA1UEBhMC > VVMxETAPBgNVBAgUCElsbGlub2lzMRMwEQYDVQQHFApTY2hhdW1idXJnMSAwHgYD > VQQKFBdOZXR3b3JrIE1lcmNoYW50cywgSW5jLjETMBEGA1UECxQKRS1Db21tZXJj > ZTEzMDEGA1UECxQqVGVybXMgb2YgdXNlIGF0IHd3dy52ZXJpc2lnbi5jb20vcnBh > IChjKTA1MSQwIgYDVQQDFBtzZWN1cmUubmV0d29ya21lcmNoYW50cy5jb20wggEi > MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcZgkSQ1dZp9Fh1D973IbDDM+s > Y3VuBDBgd+NZ9YDLdX2IiddIngO3bA72VCkFbDqzqGs3Vu6ZYKA858AZapGQQ67+ > kdxhvGKhS0oU4LQkcwhQPgSj6lxgwO6WnWWTPeB3pethgAo5dAgJarEWJJ7zBrHH > ES8h69Bt0PGXuB75GwiKZdwiRy+DIFDlm5XcopqHKZmbX3zlDtTxqdNbHClTf5os > FSUpx2fYrrpOa1N/TGM6nesnCnEQxJsY5LVwKJqd5CqsgtJKjh1d2eZquimtxiEn > z+PwQM4bWPTboLCH0egtZBw58cGKMAMzOePOJtlRj4cuXlnRqwHgrVdo2ZSVAgMB > AAGjggHOMIIByjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDBEBgNVHSAEPTA7MDkG > C2CGSAGG+EUBBxcGMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWdu > LmNvbS9jcHMwPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL0VWSW50bC1jcmwudmVy > aXNpZ24uY29tL0VWSW50bDIwMDYuY3JsMCgGA1UdJQQhMB8GCCsGAQUFBwMBBggr > BgEFBQcDAgYJYIZIAYb4QgQBMB8GA1UdIwQYMBaAFE5DyB127zdTek/yWG+U8zji > 1b3fMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVy > aXNpZ24uY29tMDkGCCsGAQUFBzAChi1odHRwOi8vRVZJbnRsLWFpYS52ZXJpc2ln > bi5jb20vRVZJbnRsMjAwNi5jZXIwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJ > aW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYk > aHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMA0GCSqGSIb3DQEB > BQUAA4IBAQAje/f6HFMBO+YPqbOpsnW4QAIGN4+X0idYL5VEzXWfGK7crahSDwJ2 > KSxqH9oCJ0qX3Mr+Mcp73ZMadX8Xk0iDPzO5DPHwrIVXdqn+xbHVUyc43v+SqIxF > eWEhak2xfW8wCauKjTACIpbEd6QK4ryEbDBWzPo3vl6wHwB2cVbELkNs8v/BW8Gq > QbPH5P/Y22z7v1Ro8O8lwvD1nOPP/CSD27sk8+IbIJ3W/BejRmXfaTDlAVAezJiW > emABKFED+WCof6OstvuZz99sThqOBWEJLm4XLPrRfgVDZF3pFqH7EEy9iQRnol+F > sKh5Wn8pK2EKQgxumf5dEyUkLk5RTtEw > -END CERTIFICATE- > subject=/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Illinois/businessCategory=Private > Organization/serialNumber=61786708/C=US/ST=Illinois/L=Schaumburg/O=Network > Merchants, Inc./OU=E-Commerce/OU=Terms of use at www.verisign.com/rpa > (c)05/CN=secure.networkmerchants.com > issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at > https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Va
CBC issue with 1.0.1e?
Hi, I'm on Mac running OS X 10.8.3 and have 2 versions of openssl installed: Default: OpenSSL 0.9.8r 8 Feb 2011 Homebrew: OpenSSL 1.0.1e 11 Feb 2013 My most recent version of ruby (1.9.3-p429) is linked with Homebrew's openssl and that's when I noticed I began having connection problems to a particular website. Using 0.9.8r and running the following command: openssl s_client -connect secure.networkmerchants.com:443 I get: CONNECTED(0003) depth=2 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Illinois/businessCategory=Private Organization/serialNumber=61786708/C=US/ST=Illinois/L=Schaumburg/O=Network Merchants, Inc./OU=E-Commerce/OU=Terms of use at www.verisign.com/rpa (c)05/CN=secure.networkmerchants.com i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority --- Server certificate -BEGIN CERTIFICATE- MIIGRDCCBSygAwIBAgIQU7qHQ3XVIaI9AqOwrVHOTTANBgkqhkiG9w0BAQUFADCB vjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNjE4MDYGA1UEAxMv VmVyaVNpZ24gQ2xhc3MgMyBFeHRlbmRlZCBWYWxpZGF0aW9uIFNTTCBTR0MgQ0Ew HhcNMTEwNTE2MDAwMDAwWhcNMTMwNjA3MjM1OTU5WjCCASkxEzARBgsrBgEEAYI3 PAIBAxMCVVMxGTAXBgsrBgEEAYI3PAIBAhQISWxsaW5vaXMxHTAbBgNVBA8TFFBy aXZhdGUgT3JnYW5pemF0aW9uMREwDwYDVQQFEwg2MTc4NjcwODELMAkGA1UEBhMC VVMxETAPBgNVBAgUCElsbGlub2lzMRMwEQYDVQQHFApTY2hhdW1idXJnMSAwHgYD VQQKFBdOZXR3b3JrIE1lcmNoYW50cywgSW5jLjETMBEGA1UECxQKRS1Db21tZXJj ZTEzMDEGA1UECxQqVGVybXMgb2YgdXNlIGF0IHd3dy52ZXJpc2lnbi5jb20vcnBh IChjKTA1MSQwIgYDVQQDFBtzZWN1cmUubmV0d29ya21lcmNoYW50cy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcZgkSQ1dZp9Fh1D973IbDDM+s Y3VuBDBgd+NZ9YDLdX2IiddIngO3bA72VCkFbDqzqGs3Vu6ZYKA858AZapGQQ67+ kdxhvGKhS0oU4LQkcwhQPgSj6lxgwO6WnWWTPeB3pethgAo5dAgJarEWJJ7zBrHH ES8h69Bt0PGXuB75GwiKZdwiRy+DIFDlm5XcopqHKZmbX3zlDtTxqdNbHClTf5os FSUpx2fYrrpOa1N/TGM6nesnCnEQxJsY5LVwKJqd5CqsgtJKjh1d2eZquimtxiEn z+PwQM4bWPTboLCH0egtZBw58cGKMAMzOePOJtlRj4cuXlnRqwHgrVdo2ZSVAgMB AAGjggHOMIIByjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDBEBgNVHSAEPTA7MDkG C2CGSAGG+EUBBxcGMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWdu LmNvbS9jcHMwPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL0VWSW50bC1jcmwudmVy aXNpZ24uY29tL0VWSW50bDIwMDYuY3JsMCgGA1UdJQQhMB8GCCsGAQUFBwMBBggr BgEFBQcDAgYJYIZIAYb4QgQBMB8GA1UdIwQYMBaAFE5DyB127zdTek/yWG+U8zji 1b3fMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVy aXNpZ24uY29tMDkGCCsGAQUFBzAChi1odHRwOi8vRVZJbnRsLWFpYS52ZXJpc2ln bi5jb20vRVZJbnRsMjAwNi5jZXIwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJ aW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYk aHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMA0GCSqGSIb3DQEB BQUAA4IBAQAje/f6HFMBO+YPqbOpsnW4QAIGN4+X0idYL5VEzXWfGK7crahSDwJ2 KSxqH9oCJ0qX3Mr+Mcp73ZMadX8Xk0iDPzO5DPHwrIVXdqn+xbHVUyc43v+SqIxF eWEhak2xfW8wCauKjTACIpbEd6QK4ryEbDBWzPo3vl6wHwB2cVbELkNs8v/BW8Gq QbPH5P/Y22z7v1Ro8O8lwvD1nOPP/CSD27sk8+IbIJ3W/BejRmXfaTDlAVAezJiW emABKFED+WCof6OstvuZz99sThqOBWEJLm4XLPrRfgVDZF3pFqH7EEy9iQRnol+F sKh5Wn8pK2EKQgxumf5dEyUkLk5RTtEw -END CERTIFICATE- subject=/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Illinois/businessCategory=Private Organization/serialNumber=61786708/C=US/ST=Illinois/L=Schaumburg/O=Network Merchants, Inc./OU=E-Commerce/OU=Terms of use at www.verisign.com/rpa (c)05/CN=secure.networkmerchants.com issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA --- No client certificate CA names sent --- SSL handshake has read 4574 bytes and written 448 bytes --- New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: DES-CBC3-SHA Session-ID: 2391920E06BE003508356E08F2638FA0712B05D8C6EFB2DBD4744CC5E2A9EA72 Session-ID-ctx: Master-Key: 84807A520CA2EE7DB5E0367B6DC4D8D3B6EB8F964CD78C6488BAD8D32E74E8DB974B1F9F48DBF3A13E2CE9442E6CFBE1 Key-Arg : None
RE: compilation problems: linking for srp
That's a linking error, not a compilation error. Make sure you compile against 1.0.1* headers *and* link with 1.0.1* libraries. I don't know what kind of build scheme curl uses, but it might easily require you have both headers and libraries in the same place, or in a fixed place. And make sure the openssl libraries used were NOT built with no-srp. (As far as I can see it's never the default and there's no reason to specify it, but it is possible.) Are you sure this is occuring for a static library? I would expect a *program* (including a test or utility program that might be built automatically with the library) to try to resolve, and maybe a dynamic library, but not a static library. OTOH that format looks like AIX to me, and I have known AIX to do surprising and weird things sometimes. _ From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Peresvet Bezdenezhnih Sent: Thursday, 30 May, 2013 08:58 To: openssl-users@openssl.org Subject: compilation problems. Hi. In openssl-1.0.1e there is such function/variables used: SSL_CTX_set_srp_username and SSL_CTX_set_srp_password. Because of them I got such compilation errors: ld: 0711-317 ERROR: Undefined symbol: .SSL_CTX_set_srp_username ld: 0711-317 ERROR: Undefined symbol: .SSL_CTX_set_srp_password when I'm trying to compile curl library as static. With older openssl versions all is ok. What library do I need to get rid of this problem? Regards, Peresvet.
RE: SSL_VERIFY_PEER and self-signed certificates
> From: owner-openssl-us...@openssl.org On Behalf Of Brice André > Sent: Thursday, 30 May, 2013 04:08 > I tested [s_client] and it seems to work properly, which, I > suppose, means that the problem resides in my client code. I > copy-pasted the output below. > I think so; see more below. > I just find something strange on the server : to write my server code, > I followed a tuto where they initialised a diffie-helman key in the > server side. I was not sure of the utility of that and thus, I > performed several tests with the command you provided : with and > without this initialisation on the server side. In both cases, this > works properly. So, I am a little bit confused about that. I would > want to remove that part, but I am not sure if it may be useful... > I presume you mean *temporary* Diffie-Hellman *parameters* i.e. SSL_CTX_set_tmp_dh (or _callback). The actual key using those parameters is generated inside openssl. This is for ciphersuites using "ephemeral" or "anonymous" DH key-exchange, abbreviated EDH or DHE (better to avoid confusing EDH with ECDH which is different) and ADH. SSL/TLS also defines ciphersuites using static Diffie-Hellman, but openssl does not implement them; plus you can't have a selfsigned cert for a (static) DH key. Your key is RSA so s_client by default and your client as posted supports both ciphersuites with DHE (DHE-RSA) and without (RSA, or akRSA to avoid ambiguity). Other kinds of key/cert would differ. I believe (but didn't check) that both will prefer DHE-RSA; thus you might observe the difference if either endpoint displays SSL_get_cipher_name(ssl) or equivalent after handshake, or when you use s_client which displays this among other things. The advantage of DHE-RSA over akRSA is "perfect forward secrecy": assuming the endpoints (together) put sufficient entropy into their DHE keys, the session keys cannot be recovered and thus logged session data cannot be decrypted even if the (server's) privatekey is later compromised. Google for more. In a situation where you're doing both endpoints (no interop) and trust your own key management, PFS probably doesn't have any benefit. > I joined my client code. The interesting function is > "wxSSLSocketClient::InitiateSSLSession". This code uses the wxWidgets > library and thus, it uses the wxSocketClient (wxWidgets socket > implementation) with a dedicated BIO so that openssl can handle it. > This code is extracted from the wxEMail project (I am the maintaniner > of this project). But, in this project, I did not implement the server > certificate check stuff. Thus, this version is slighlty modified to > perform those additional checks. > > You will easily identify which part is original code and which one is > not because original code was designed to work in static link as well > as dynamic link (with a manual load of library). So, in original code, > all ssl calls are encapsulated in a macro. The modified version > currenlty only support static link, and thus ssl calls are not > encapsulated in the macro. > It's a bit difficult to read through the clutter, but I don't see anything here which should cause the cert lookup to fail. If some calls were going to a different version openssl library(ies) somehow that might explain it, but with OPEN_SSL_STATIC_LINK defined I don't see how that would happen. Two things I do notice: - SSL_set_connect_state is redundant when using SSL_connect. (It is needed for "transparent" or "automatic" handshake.) - SSL_set_cipher_list "ALL" includes the anonymous suites that provide no authentication, which may conflict with your goal. Do you want your client to verify the server unconditionally, or only if the server "agrees" by choosing an authenticating suite? > Note that this code allows performing ssl connection on different > servers and thus, I really think that the BIO part and so on is OK. > The only part that has never been tested is the new part performing > the server certificate check. > I think you're down to an ordinary debugging problem here. In your shoes I would: - cut down the code to the minimum that reproduces the problem; your special BIO logically shouldn't matter, but cut it out anyway to be certain and simplify the code - use a (re)build with symbols and step through it using a good debugger (preferably gdb); in particular, after _load_verify ctx->cert_store->objs->stack should have num=1 (and data should point to a pointer that's actually to an X509_OBJECT that contains a pointer to the desired cert, but that's harder to look at), and the first time you get to X509_STORE_CTX_get1_issuer from X509_verify_cert for this case ctx->ctx->objs->stack the same. (The first ctx is a store_ctx and the second actually a store, which is confusing.) If not then backtrack to see why not; if so then step forward to see why it's not matched and accepted. - if I get to a point where what the debugger says happened is not what the source code
Re: PKCS12 keystore creation failing in fips mode
On Thu, May 30, 2013, Anamitra Dutta Majumdar (anmajumd) wrote: > Hello Steve , > > Thanks for your response. > > Is there a corresponding API where we can impose this descert option? > If you are using PKCS12_create() just set the certificate PBE algorithm to NID_pbe_WithSHA1And3_Key_TripleDES_CBC 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: PKCS12 keystore creation failing in fips mode
Hello Steve , Thanks for your response. Is there a corresponding API where we can impose this descert option? -Anamitra On 5/29/13 6:15 PM, "Dr. Stephen Henson" wrote: >On Wed, May 29, 2013, Anamitra Dutta Majumdar (anmajumd) wrote: > >> We are trying to create pkcs12 keystore in FIPS mode using OpenSSL 1.0.1 >> and it fails with the following error >> >> 9uo8bYe2YpDmqEgC[root@vos-i/usr/local/platform/bin/openssl pkcs12 >>-export >> -in tomcat.pem -inkey ../keys/tomcat_priv.pem -out tomcat.keystore >> Enter Export Password: >> Verifying - Enter Export Password: >> 4151633544:error:060A60A3:digital envelope >> routines:FIPS_CIPHERINIT:disabled for fips:fips_enc.c:142: >> 4151633544:error:06074078:digital envelope >> routines:EVP_PBE_CipherInit:keygen failure:evp_pbe.c:205: >> 4151633544:error:23077073:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 algor >> cipherinit error:p12_decr.c:83: >> 4151633544:error:2306C067:PKCS12 >>routines:PKCS12_item_i2d_encrypt:encrypt >> error:p12_decr.c:175: >> 4151633544:error:23073067:PKCS12 routines:PKCS12_pack_p7encdata:encrypt >> error:p12_add.c:202: >> >> >> The same command works in FIPS mode. >> >> So I have the following questions >> >> 1. Is there a way to work around issue and still be able to create >>pkcs12 >> format keystore in FIPS mode. >> 2. This command worked in earlier version of openssl like 0.9.8l in FIPS >> mode. What has changed in 1.0.1 >> That it has stopped working in FIPS mode. >> >> Any pointers will be appreciated. >> > >That's a bug in 1.0.1 in that it tries to use an unapproved algorithm in >FIPS >mode. > >Workaround: use the -descert option. > >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 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
compilation problems.
Hi. In openssl-1.0.1e there is such function/variables used: SSL_CTX_set_srp_username and SSL_CTX_set_srp_password. Because of them I got such compilation errors: ld: 0711-317 ERROR: Undefined symbol: .SSL_CTX_set_srp_username ld: 0711-317 ERROR: Undefined symbol: .SSL_CTX_set_srp_password when I'm trying to compile curl library as static. With older openssl versions all is ok. What library do I need to get rid of this problem? Regards, Peresvet.
Re: SSL_VERIFY_PEER and self-signed certificates
Hello, I tested your small program and it seems to work properly, which, I suppose, means that the problem resides in my client code. I copy-pasted the output below. I just find something strange on the server : to write my server code, I followed a tuto where they initialised a diffie-helman key in the server side. I was not sure of the utility of that and thus, I performed several tests with the command you provided : with and without this initialisation on the server side. In both cases, this works properly. So, I am a little bit confused about that. I would want to remove that part, but I am not sure if it may be useful... I joined my client code. The interesting function is "wxSSLSocketClient::InitiateSSLSession". This code uses the wxWidgets library and thus, it uses the wxSocketClient (wxWidgets socket implementation) with a dedicated BIO so that openssl can handle it. This code is extracted from the wxEMail project (I am the maintaniner of this project). But, in this project, I did not implement the server certificate check stuff. Thus, this version is slighlty modified to perform those additional checks. You will easily identify which part is original code and which one is not because original code was designed to work in static link as well as dynamic link (with a manual load of library). So, in original code, all ssl calls are encapsulated in a macro. The modified version currenlty only support static link, and thus ssl calls are not encapsulated in the macro. Note that this code allows performing ssl connection on different servers and thus, I really think that the BIO part and so on is OK. The only part that has never been tested is the new part performing the server certificate check. Thanks for your help. Regards, Brice D:\home\DbSync1>C:\OpenSSL-Win32\bin\openssl s_client -connect localhost:1212 -C Afile server.crt Loading 'screen' into random state - done CONNECTED(0738) depth=0 C = BE, ST = Hainaut, L = Charleroi, O = AMS-Solutions, CN = Brice Andre , emailAddress = brice.an...@xxx.be verify return:1 --- Certificate chain 0 s:/C=BE/ST=Hainaut/L=Charleroi/O=AMS-Solutions/CN=Brice Andre/emailAddress=br ice.an...@xxx.be i:/C=BE/ST=Hainaut/L=Charleroi/O=AMS-Solutions/CN=Brice Andre/emailAddress=br ice.an...@xxx.be --- Server certificate -BEGIN CERTIFICATE- MIIDnDCCAoQCCQDc4fMRV+0qfzANBgkqhkiG9w0BAQUFADCBjjELMAkGA1UEBhMC QkUxEDAOBgNVBAgTB0hhaW5hdXQxEjAQBgNVBAcTCUNoYXJsZXJvaTEWMBQGA1UE ChMNQU1TLVNvbHV0aW9uczEUMBIGA1UEAxMLQnJpY2UgQW5kcmUxKzApBgkqhkiG 9w0BCQEWHGJyaWNlLmFuZHJlQGFtcy1zb2x1dGlvbnMuYmUwIBcNMTMwNTI2MDUw MzUyWhgPMjA2ODAyMjcwNTAzNTJaMIGOMQswCQYDVQQGEwJCRTEQMA4GA1UECBMH SGFpbmF1dDESMBAGA1UEBxMJQ2hhcmxlcm9pMRYwFAYDVQQKEw1BTVMtU29sdXRp b25zMRQwEgYDVQQDEwtCcmljZSBBbmRyZTErMCkGCSqGSIb3DQEJARYcYnJpY2Uu YW5kcmVAYW1zLXNvbHV0aW9ucy5iZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAKEDpEF1+IOPim2EPvgVjOtdnSal4UjSdl1Bg2dTpGWZpUAwacoCT7kB sTwkGqgSHs/3Zt171oa14qZrBequpjcMCKOD/JLsMYNZaJLIhLIMHUbNiq0xEIeu dwy81MhwzKIKm/4SAta++x6/wLVGsgJ+GgLMEs7oDpAVgiOot1xV4SEUfsanrl8e QQkjP43pPTtWbdDsTZ4XKl2LStH5hFVnYAC7Y6KEbZJvkqcfMG92mSsOR/4JrSWe 0WtjBjoDhkPxnmlpuFkyfk5EFep5/Qg7Ut+fi0k4/9O28POXbFEwnstDqTbSJdsN N0C665u9167J+AmkeZ3n7z41HGgB1TcCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEA K7t53eIY+rMjyCk9IDtcD+SUDa4AltuVcSq0xADzjjtH+11QQvI4/l20eDBV/bnm HpbNZP2Z8jBnbrCn7bEOqY1HzQrc9KBipy+kbNHknq1MzcteB6b1qIOgr92A0e6A qVqaULuXKsIj0Ot/g6eh//e4IBJGOg+kbSpB3mDO9G9utP3W8KB7leUDmsBRW1ld tQ4wtmqknr1WZSXkxa4JDFDBwP6DWymbSl0S7xQO9/5kPWIubL77FxxUZ73jC/G+ iz+rAM2LrqN3Lppp3aH7gkH9pKTWciE7f8kEHfSUKU7LQ87bood0R8XOTvE5xuJq lJSl3bu6XXt/u/ZibObTyw== -END CERTIFICATE- subject=/C=BE/ST=Hainaut/L=Charleroi/O=AMS-Solutions/CN=Brice Andre/emailAddress =brice.an...@xxx.be issuer=/C=BE/ST=Hainaut/L=Charleroi/O=AMS-Solutions/CN=Brice Andre/emailAddress= brice.an...@xxx.be --- No client certificate CA names sent --- SSL handshake has read 1774 bytes and written 519 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: DHE-RSA-AES256-SHA Session-ID: 6F265E53749453BE5C3DD2BFFF4B99A1DBDA559AF76E8C8974A90ABEEED34AF1 Session-ID-ctx: Master-Key: 142C4C0BA297D034922C619C9C6EF658D66C476386CE0FECD502B3B990FD01BE FA3C6B067055860A7BD8632B69E49810 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket: - 86 89 a4 c4 44 8f a9 e4-0d 76 5f 7e 95 3c 3d aa Dv_~.<=. 0010 - 05 4b f0 33 bc 09 7e 08-42 0d f6 81 41 52 81 62 .K.3..~.B...AR.b 0020 - 0f cc 2d de 32 84 b2 57-28 fc c3 2c cc 4b 26 42 ..-.2..W(..,.K&B 0030 - 8b f0 8e 99 37 8e fb 63-50 fe ee c6 10 b1 37 da 7..cP.7. 0040 - 90 1c 03 ad cb 08 db ff-93 dc 40 1c a1 7a e1 43 ..@..z.C 0050 - f2 fc d2 3d 86 46 9a 88-d6 6f 25 62 aa 59 41 a9 ...=.F...o%b.YA. 0060 - a6 29 45 dc 47 3b a9 2f-60 bb 34 d2 42 74 d
