From c.holper at ades.at Mon May 2 05:01:44 2016 From: c.holper at ades.at (c.holper at ades.at) Date: Mon, 2 May 2016 07:01:44 +0200 Subject: [openssl-users] Missing ctrl-defines for GCM Message-ID: <5726DF38.1060705@ades.at> Hi! I am trying OpenSSL EVP for some AES-GCM encryption/decryption testing. Having Debian 8.4 (testing) my installed evp.h does not include the following defines I need. #define EVP_CTRL_AEAD_SET_IVLEN 0x9 #define EVP_CTRL_AEAD_GET_TAG 0x10 #define EVP_CTRL_AEAD_SET_TAG 0x11 If I set it manually it seems to work. I found it as "ctrl() values" on https://github.com/openssl/openssl/blob/master/include/openssl/evp.h. My distributions OpenSSL is 1.0.1k 8 Jan 2015. So 2 questions. - Why is it not included in my evp.h. Is it too old? - If it is too old, is it ok to define it by myself or is it a bad idea? Thanks for help! Chris From dmitry at addlive.com Mon May 2 05:56:27 2016 From: dmitry at addlive.com (Dmitry Sobinov) Date: Mon, 2 May 2016 15:56:27 +1000 Subject: [openssl-users] New DTLS association from the same IP:port Message-ID: Hi, Is there any way in OpenSSL to detect new connections over the same IP:port quartet on a server side? For example, when client reconnects from the same local IP:port, but the server still thinks that the old client is still alive. RFC 6347 4.2.8 specifies that the server side should send Hello Verify Request after receiving Client Hello on the existing association. However, OpenSSL just returns WANT_READ after passing Client Hello to SSL_read without actually sending back anything. What is the proper way to fix this behaviour? Thanks, Dmitry Sobinov -------------- next part -------------- An HTML attachment was scrubbed... URL: From shubham13099 at iiitd.ac.in Mon May 2 06:53:25 2016 From: shubham13099 at iiitd.ac.in (Shubham Chauhan) Date: Mon, 2 May 2016 12:23:25 +0530 Subject: [openssl-users] Storing session in file and reusing at client side Message-ID: Hello, I wanted to store the freshly negotiated ssl/tls session in a file and reuse it (via SSL_set_session()), in the next handshake. I was not able to do that since the handshake got terminated giving a fatal error - illegal parameters (47). Although this works perfectly fine when I store the session in a global variable at the client side and use it the next time. But I need to use the same session across multiple clients (I hope session does not store the IP and DNS entries). I had the following questions- 1). Why is the session, when stored in an external file, resulting into the "illegal parameter" error? 2). Is there some other way to handle the same session among different client *.c files? Something better than writing down the session in a file (well, even this does not seems to work for me!) It'll be great if someone could help me out on this. Thanks in advance. -- Regards Shubham Chauhan -------------- next part -------------- An HTML attachment was scrubbed... URL: From janjust at nikhef.nl Mon May 2 08:06:54 2016 From: janjust at nikhef.nl (Jan Just Keijser) Date: Mon, 02 May 2016 10:06:54 +0200 Subject: [openssl-users] [openssl-dev] Are you using "TLS proxy certificates"? In-Reply-To: <0215c1be002346f1a1496350f4a48b61@usma1ex-dag1mb1.msg.corp.akamai.com> References: <0215c1be002346f1a1496350f4a48b61@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <57270A9E.30806@nikhef.nl> Hi Rich, On 27/04/16 18:45, Salz, Rich wrote: > > If so, please let us know. Replies to me will be summarized for the > lists. > > what exactly do you mean by 'TLS proxy certificates' ? if you mean RFC3820 (5280) proxy certificates, then yes, we use them extensively within grid computing. regards, JJK / Jan Just Keijser Nikhef Amsterdam -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon May 2 14:04:08 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 2 May 2016 14:04:08 +0000 Subject: [openssl-users] [openssl-dev] Storing session in file and reusing at client side In-Reply-To: References: Message-ID: <20160502140408.GP3300@mournblade.imrryr.org> On Mon, May 02, 2016 at 12:23:25PM +0530, Shubham Chauhan wrote: > I wanted to store the freshly negotiated ssl/tls session in a file and > reuse it (via SSL_set_session()), in the next handshake. I was not able to > do that since the handshake got terminated giving a fatal error - illegal > parameters (47). Client-side sessions can be serialized via i2d_SSL_SESSION and the resulting binary data can be stored in a file for reuse by a client via d2i_SSL_SESSION() followed by SSL_set_session() (which copies the session, so you can free the session obtained via d2i at that point). Of course the client needs to want to reconnect to the same SSL peer with the same security policy, otherwise session reuse is unwise. -- Viktor. From shubham13099 at iiitd.ac.in Mon May 2 16:33:18 2016 From: shubham13099 at iiitd.ac.in (Shubham Chauhan) Date: Mon, 2 May 2016 22:03:18 +0530 Subject: [openssl-users] [openssl-dev] Storing session in file and reusing at client side In-Reply-To: <20160502140408.GP3300@mournblade.imrryr.org> References: <20160502140408.GP3300@mournblade.imrryr.org> Message-ID: Thanks Viktor. > > Client-side sessions can be serialized via i2d_SSL_SESSION and the > resulting binary data can be stored in a file for reuse by a client > via d2i_SSL_SESSION() followed by SSL_set_session() (which copies > the session, so you can free the session obtained via d2i at that > point). > > I did this thing using PEM_write_SSL_SESSION and PEM_write_SSL_SESSION respectively, which seemed to work for the server side session handling. But when I use the above mentioned methods, it gives me that illegal parameter (47) error. As a matter of fact, I was able to load the session_id into the Client hello message, and even the server method responded with the same session_id. But the next message was the fatal error which terminated the handshake. > Of course the client needs to want to reconnect to the same SSL > peer with the same security policy, otherwise session reuse is > unwise. > > I ensured I am using the same client_method (security policy), but still can't figure out why the error comes up. > -- > Viktor. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Regards Shubham Chauhan 2013099 B.Tech CSE -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Mon May 2 17:38:27 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 2 May 2016 19:38:27 +0200 Subject: [openssl-users] Changing IV in EVP API? Message-ID: <5ac747ef-7fe5-4fd7-bd65-3143a40d7b89@wisemo.com> While trying to convert some 3rd party code from direct calls to libcrypto functions to using the EVP API, I have run into a problem. I cannot find the EVP call to change the IV without changing (and reexpanding) the key. If the code should stay in the old (non-EVP) API, I similarly lack a way to call the CPU optimized AES functions (AESNI, HWAES, BSAES, VPAES) in the shared libcrypto.so . Seems there is no way to win? But I thought TLS 1.2 still needed the ability to efficiently change IV mid-stream? P.S. This is not GCM with its strange TLS specific IV formulas. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From steve at openssl.org Mon May 2 19:16:28 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 2 May 2016 19:16:28 +0000 Subject: [openssl-users] Changing IV in EVP API? In-Reply-To: <5ac747ef-7fe5-4fd7-bd65-3143a40d7b89@wisemo.com> References: <5ac747ef-7fe5-4fd7-bd65-3143a40d7b89@wisemo.com> Message-ID: <20160502191628.GA11778@openssl.org> On Mon, May 02, 2016, Jakob Bohm wrote: > While trying to convert some 3rd party code from direct calls > to libcrypto functions to using the EVP API, I have run into > a problem. > > I cannot find the EVP call to change the IV without changing > (and reexpanding) the key. > Try calling the EVP_*Init() function with all the parameters NULL except the IV and the EVP_CIPHER_CTX parameter. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From steve at openssl.org Mon May 2 20:06:48 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 2 May 2016 20:06:48 +0000 Subject: [openssl-users] Storing session in file and reusing at client side In-Reply-To: References: Message-ID: <20160502200648.GA13687@openssl.org> On Mon, May 02, 2016, Shubham Chauhan wrote: > Hello, > > I wanted to store the freshly negotiated ssl/tls session in a file and > reuse it (via SSL_set_session()), in the next handshake. I was not able to > do that since the handshake got terminated giving a fatal error - illegal > parameters (47). > > Although this works perfectly fine when I store the session in a global > variable at the client side and use it the next time. But I need to use the > same session across multiple clients (I hope session does not store the IP > and DNS entries). > > I had the following questions- > 1). Why is the session, when stored in an external file, resulting into the > "illegal parameter" error? > 2). Is there some other way to handle the same session among different > client *.c files? Something better than writing down the session in a file > (well, even this does not seems to work for me!) > Is it the server sending the error? Is the server running OpenSSL? Does it happen with the same client running the same software with the same IP address or does it only happen with different IP addresses? I'm wondering if the server rejects the attempt to resume from different IP addresses. Also see if you can reproduce the behaviour with s_client using -sess_out and -sess_in options. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From shubham13099 at iiitd.ac.in Mon May 2 20:24:32 2016 From: shubham13099 at iiitd.ac.in (Shubham Chauhan) Date: Tue, 3 May 2016 01:54:32 +0530 Subject: [openssl-users] Storing session in file and reusing at client side In-Reply-To: <20160502200648.GA13687@openssl.org> References: <20160502200648.GA13687@openssl.org> Message-ID: > Is it the server sending the error? No, it is the client sending the error. > Is the server running OpenSSL? Yes, I made the ssl_client and server (a simple chat functionality) scripts. > Does it happen with the same client running the same software with the > same IP address > or does it only happen with different IP addresses? > I ran the setup on localhost. it is independent of the IP thing. > I'm wondering if the server rejects the attempt to resume from different > IP addresses. I could reproduce the error on my local machine, so I guess that's not the issue. What I think is that it is more related to session contexts. Since every application will be having it's session context, the session_id might not be compatible across different application implementations What I was trying to do is to store the session negotiated between client1 and server1 (in a file, using PEM_read_ssl_session), and use the stored session in client2 and server2- (everything running on the same machine but different ports right now) I did the following- > Client side - read the stored session from the file, used SSL_set_session to set the session for the connection. > Server side - read the stored session from the file, used SSL_CTX_add_session, to add the session to the context. Observation - > Client hello - with the session_id from the file > Server hello - returned the same session_id > Fatal error (from client to server) - illegal parameter > Also see if you can reproduce the behaviour with s_client using -sess_out > and > -sess_in options. > I'll give it a try. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at samad.com.au Tue May 3 04:20:22 2016 From: alex at samad.com.au (Alex Samad) Date: Tue, 3 May 2016 14:20:22 +1000 Subject: [openssl-users] help with timestamping In-Reply-To: References: <5715B440.8000706@wisemo.com> <0ba87a40-3f78-478e-e96c-6a5c6c20e62c@wisemo.com> Message-ID: Got a bit further ======= #!/bin/bash rm -f /tmp/test.data* /tmp/sym.cer cat > /tmp/test.data < /tmp/symINT.cer << EOF # Signing cert public key #Issuer: C=US, O=Symantec Corporation, OU=Symantec Trust Network, CN=Symantec SHA256 TimeStamping CA #Subject: C=US, O=Symantec Corporation, OU=Symantec Trust Network, CN=Symantec SHA256 TimeStamping Signer - G1 -----BEGIN CERTIFICATE----- MIIFSzCCBDOgAwIBAgIQVPN9oXFnUbxqjQrSdLKLEzANBgkqhkiG9w0BAQsFADB3 MQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxKDAmBgNVBAMTH1N5bWFudGVj IFNIQTI1NiBUaW1lU3RhbXBpbmcgQ0EwHhcNMTYwMTEyMDAwMDAwWhcNMjcwNDEx MjM1OTU5WjCBgDELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBv cmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTEwLwYDVQQD EyhTeW1hbnRlYyBTSEEyNTYgVGltZVN0YW1waW5nIFNpZ25lciAtIEcxMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAn/vfjx+nz54+GsvraK3PJxzugVWp hwhY5YFNCRTg7dDz1A8/IbYeDjTU8WgKb32Pidny6qfYJTikjDbK7ijPM/h1Pdid z5LdVuP2sHlUZrVFgkNE0mqxqxeiw+XvAOon8yeIDoc89m68qez2uy5qdwYivfq4 f8MkB/c/u0yw/0PLk8oSqpUkAJCyKzai0t3Ss9GZMt3P9MxzFkmDfyTr7XhG0+5f bEJlG2eN8CYaDl6HblqPoIJ+bp/NJt69Ye9EXkWLqJTTHAQyof+kp6KqdwHbKt4P TJI2xmmsXISArSX17TDDaB0X2wpNmjR4WQGbawKFOOIncaIUVDBgkyBIIwIDAQAB o4IBxzCCAcMwDAYDVR0TAQH/BAIwADBmBgNVHSAEXzBdMFsGC2CGSAGG+EUBBxcD MEwwIwYIKwYBBQUHAgEWF2h0dHBzOi8vZC5zeW1jYi5jb20vY3BzMCUGCCsGAQUF BwICMBkaF2h0dHBzOi8vZC5zeW1jYi5jb20vcnBhMEAGA1UdHwQ5MDcwNaAzoDGG L2h0dHA6Ly90cy1jcmwud3Muc3ltYW50ZWMuY29tL3NoYTI1Ni10c3MtY2EuY3Js MBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMIMA4GA1UdDwEB/wQEAwIHgDB3BggrBgEF BQcBAQRrMGkwKgYIKwYBBQUHMAGGHmh0dHA6Ly90cy1vY3NwLndzLnN5bWFudGVj LmNvbTA7BggrBgEFBQcwAoYvaHR0cDovL3RzLWFpYS53cy5zeW1hbnRlYy5jb20v c2hhMjU2LXRzcy1jYS5jZXIwKAYDVR0RBCEwH6QdMBsxGTAXBgNVBAMTEFRpbWVT dGFtcC0yMDQ4LTQwHQYDVR0OBBYEFO1rYM87WPg+Msy/pOir6OqiUEJ/MB8GA1Ud IwQYMBaAFK9j1sqjToVy4Ke8QfMpojh/gHViMA0GCSqGSIb3DQEBCwUAA4IBAQCi jV5dHe5O0pP9T+X0babwiUVVuwjKqyShFiTJTxfBn/TdAprCR8Cp3IiJd8GGhvHV SZbz+x6Y1skdNSOImYpi4XWoTXinPewkgBWeaNQ6pMJM3HFslp2OHgwubFIBnlaQ P6Jeks222kEaJIOheqNf/o07bznRP0FfVhwnDOV8BdhnNojlsMLDBKNaVrgSBI7U nCRrG2a0vqAa4bXN7ONEpLE855LzWN3f6LFYS3BLzpAAzNyj0dJudRZURALvG1RE Y+i1cMi5R5pbRcRudpoYsfcQM8gLUfVVjP0hHkGPTj6QXYAByLwkfoZoFBUUNDV0 SbeHUinWll6ioxbUsNN7 -----END CERTIFICATE----- # CA for signing cert #Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2008 VeriSign, Inc. - For authorized use only, CN=VeriSign Universal Root Certification Authority #Subject: C=US, O=Symantec Corporation, OU=Symantec Trust Network, CN=Symantec SHA256 TimeStamping CA -----BEGIN CERTIFICATE----- MIIFODCCBCCgAwIBAgIQewWx1EloUUT3yYnSnBmdEjANBgkqhkiG9w0BAQsFADCB vTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwOCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MTgwNgYDVQQDEy9W ZXJpU2lnbiBVbml2ZXJzYWwgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0xNjAxMTIwMDAwMDBaFw0zMTAxMTEyMzU5NTlaMHcxCzAJBgNVBAYTAlVTMR0w GwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazEoMCYGA1UEAxMfU3ltYW50ZWMgU0hBMjU2IFRpbWVTdGFt cGluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALtZnVlVT52M cl0agaLrVfOwAa08cawyjwVrhponADKXak3JZBRLKbvC2Sm5Luxjs+HPPwtWkPhi G37rpgfi3n9ebUA41JEG50F8eRzLy60bv9iVkfPw7mz4rZY5Ln/BJ7h4OcWEpe3t r4eOzo3HberSmLU6Hx45ncP0mqj0hOHE0XxxxgYptD/kgw0mw3sIPk35CrczSf/K O9T1sptL4YiZGvXA6TMU1t/HgNuR7v68kldyd/TNqMz+CfWTN76ViGrF3PSxS9TO 6AmRX7WEeTWKeKwZMo8jwTJBG1kOqT6xzPnWK++32OTVHW0ROpL2k8mc40juu1MO 1DaXhnjFoTcCAwEAAaOCAXcwggFzMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E CDAGAQH/AgEAMGYGA1UdIARfMF0wWwYLYIZIAYb4RQEHFwMwTDAjBggrBgEFBQcC ARYXaHR0cHM6Ly9kLnN5bWNiLmNvbS9jcHMwJQYIKwYBBQUHAgIwGRoXaHR0cHM6 Ly9kLnN5bWNiLmNvbS9ycGEwLgYIKwYBBQUHAQEEIjAgMB4GCCsGAQUFBzABhhJo dHRwOi8vcy5zeW1jZC5jb20wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL3Muc3lt Y2IuY29tL3VuaXZlcnNhbC1yb290LmNybDATBgNVHSUEDDAKBggrBgEFBQcDCDAo BgNVHREEITAfpB0wGzEZMBcGA1UEAxMQVGltZVN0YW1wLTIwNDgtMzAdBgNVHQ4E FgQUr2PWyqNOhXLgp7xB8ymiOH+AdWIwHwYDVR0jBBgwFoAUtnf6aUhHn1MS1cLq BzJ2B9GXBxkwDQYJKoZIhvcNAQELBQADggEBAHXqsC3VNBlcMkX+DuHUT6Z4wW/X 6t3cT/OhyIGI96ePFeZAKa3mXfSi2VZkhHEwKt0eYRdmIFYGmBmNXXHy+Je8Cf0c kUfJ4uiNA/vMkC/WCmxOM+zWtJPITJBjSDlAIcTd1m6JmDy1mJfoqQa3CcmPU1dB kC/hHk1O3MoQeGxCbvC2xfhhXFL1TvZrjfdKer7zzf0D19n2A6gP41P3CnXsxnUu qmaFBJm3+AZX4cYO9uiv2uybGB+queM6AL/OipTLAduexzi7D1Kr0eOUA2AKTaD+ J20UMvw/l0Dhv5mJ2+Q5FL3a5NPD6itas5VYVQR9x5rsIwONhSrS/66pYYE= -----END CERTIFICATE----- EOF cat > /tmp/symCA.cer << EOF #Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2008 VeriSign, Inc. - For authorized use only, CN=VeriSign Universal Root Certification Authority #Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2008 VeriSign, Inc. - For authorized use only, CN=VeriSign Universal Root Certification Authority -----BEGIN CERTIFICATE----- MIIEuTCCA6GgAwIBAgIQQBrEZCGzEyEDDrvkEhrFHTANBgkqhkiG9w0BAQsFADCB vTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwOCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MTgwNgYDVQQDEy9W ZXJpU2lnbiBVbml2ZXJzYWwgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wODA0MDIwMDAwMDBaFw0zNzEyMDEyMzU5NTlaMIG9MQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAyMDA4IFZlcmlTaWduLCBJbmMuIC0gRm9y IGF1dGhvcml6ZWQgdXNlIG9ubHkxODA2BgNVBAMTL1ZlcmlTaWduIFVuaXZlcnNh bCBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAx2E3XrEBNNti1xWb/1hajCMj1mCOkdeQmIN65lgZOIzF 9uVkhbSicfvtvbnazU0AtMgtc6XHaXGVHzk8skQHnOgO+k1KxCHfKWGPMiJhgsWH H26MfF8WIFFE0XBPV+rjHOPMee5Y2A7Cs0WTwCznmhcrewA3ekEzeOEz4vMQGn+H LL729fdC4uW/h2KJXwBL38Xd5HVEMkE6HnFuacsLdUYI0crSK5XQz/u5QGtkjFdN /BMReYTtXlT2NJ8IAfMQJQYXStrxHXpma5hgZqTZ79IugvHw7wnqRMkVauIDbjPT rJ9VAMf2CGqUuV/c4DPxhGD5WycRtPwW8rtWaoAljQIDAQABo4GyMIGvMA8GA1Ud EwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMG0GCCsGAQUFBwEMBGEwX6FdoFsw WTBXMFUWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFI/l0xqGrI2Oa8PPgGrUSBgs exkuMCUWI2h0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28uZ2lmMB0GA1Ud DgQWBBS2d/ppSEefUxLVwuoHMnYH0ZcHGTANBgkqhkiG9w0BAQsFAAOCAQEASvj4 sAPmLGd75JR3Y8xuTPl9Dg3cyLk1uXBPY/ok+myDjEedO2Pzmvl2MpWRsXe8rJq+ seQxIcaBlVZaDrHC1LGmWazxY8u4TB1ZkErvkBYoH1quEPuBUDgMbMzxPcP1Y+Oz 4yHJJDnp/RVmRvQbEdBNc6N9Rvk97ahfYtTxP/jgdFcrGJ2BtMQo2pSXpXDrrB2+ BxHw1dvd5Yzw1TKwg+ZX4o+/vqGqvz0dtdQ46tewXDpPaj+PwGZsY6rp2aQW9IHR lRQOfc2VNNnSj3BzgXucfr2YYdhFh5iQxeuGMMY1v/D/w1WIg0vvBZIGcfK4mJO3 7M2CYfE45k+XmCpajQ== -----END CERTIFICATE----- EOF /usr/bin/openssl ts -query -data /tmp/test.data -sha256 -out /tmp/test.data.tsq -no_nonce /usr/bin/curl -s -H Content-Type:application/timestamp-query --data-binary @/tmp/test.data.tsq http://sha256timestamp.ws.symantec.com/sha256/timestamp -o /tmp/test.data.tsr #/usr/bin/openssl ts -query -data /tmp/test.data -sha256 | /usr/bin/curl -s -H Content-Type:application/timestamp-query --data-binary @- http://sha256timestamp.ws.symantec.com/sha256/timestamp > /tmp/test.data.tsr /usr/bin/openssl ts -reply -in /tmp/test.data.tsr -text > /tmp/test.data.tsr.txt #openssl ts -verify -data /tmp/test.data -in /tmp/test.data.tsr #openssl ts -verify -data /tmp/test.data -in /tmp/test.data.tsr -untrusted /tmp/symINT.cer openssl ts -verify -data /tmp/test.data -in /tmp/test.data.tsr -untrusted /tmp/symINT.cer -CAfile /tmp/symCA.cer ======= results in this Verification: FAILED 140328034314056:error:2F067065:time stamp routines:TS_CHECK_SIGNING_CERTS:ess signing certificate error:ts_rsp_verify.c:291: which lead me to this http://openssl.6102.n7.nabble.com/possible-Bug-in-OpenSSL-rfc-3161-TSA-service-tt43128.html#none Not sure if there has been any work on this since then. On 29 April 2016 at 11:25, Alex Samad wrote: > Okay I have the cert from sym > > -----BEGIN CERTIFICATE----- > MIIFSzCCBDOgAwIBAgIQVPN9oXFnUbxqjQrSdLKLEzANBgkqhkiG9w0BAQsFADB3 > MQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd > BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxKDAmBgNVBAMTH1N5bWFudGVj > IFNIQTI1NiBUaW1lU3RhbXBpbmcgQ0EwHhcNMTYwMTEyMDAwMDAwWhcNMjcwNDEx > MjM1OTU5WjCBgDELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBv > cmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTEwLwYDVQQD > EyhTeW1hbnRlYyBTSEEyNTYgVGltZVN0YW1waW5nIFNpZ25lciAtIEcxMIIBIjAN > BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAn/vfjx+nz54+GsvraK3PJxzugVWp > hwhY5YFNCRTg7dDz1A8/IbYeDjTU8WgKb32Pidny6qfYJTikjDbK7ijPM/h1Pdid > z5LdVuP2sHlUZrVFgkNE0mqxqxeiw+XvAOon8yeIDoc89m68qez2uy5qdwYivfq4 > f8MkB/c/u0yw/0PLk8oSqpUkAJCyKzai0t3Ss9GZMt3P9MxzFkmDfyTr7XhG0+5f > bEJlG2eN8CYaDl6HblqPoIJ+bp/NJt69Ye9EXkWLqJTTHAQyof+kp6KqdwHbKt4P > TJI2xmmsXISArSX17TDDaB0X2wpNmjR4WQGbawKFOOIncaIUVDBgkyBIIwIDAQAB > o4IBxzCCAcMwDAYDVR0TAQH/BAIwADBmBgNVHSAEXzBdMFsGC2CGSAGG+EUBBxcD > MEwwIwYIKwYBBQUHAgEWF2h0dHBzOi8vZC5zeW1jYi5jb20vY3BzMCUGCCsGAQUF > BwICMBkaF2h0dHBzOi8vZC5zeW1jYi5jb20vcnBhMEAGA1UdHwQ5MDcwNaAzoDGG > L2h0dHA6Ly90cy1jcmwud3Muc3ltYW50ZWMuY29tL3NoYTI1Ni10c3MtY2EuY3Js > MBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMIMA4GA1UdDwEB/wQEAwIHgDB3BggrBgEF > BQcBAQRrMGkwKgYIKwYBBQUHMAGGHmh0dHA6Ly90cy1vY3NwLndzLnN5bWFudGVj > LmNvbTA7BggrBgEFBQcwAoYvaHR0cDovL3RzLWFpYS53cy5zeW1hbnRlYy5jb20v > c2hhMjU2LXRzcy1jYS5jZXIwKAYDVR0RBCEwH6QdMBsxGTAXBgNVBAMTEFRpbWVT > dGFtcC0yMDQ4LTQwHQYDVR0OBBYEFO1rYM87WPg+Msy/pOir6OqiUEJ/MB8GA1Ud > IwQYMBaAFK9j1sqjToVy4Ke8QfMpojh/gHViMA0GCSqGSIb3DQEBCwUAA4IBAQCi > jV5dHe5O0pP9T+X0babwiUVVuwjKqyShFiTJTxfBn/TdAprCR8Cp3IiJd8GGhvHV > SZbz+x6Y1skdNSOImYpi4XWoTXinPewkgBWeaNQ6pMJM3HFslp2OHgwubFIBnlaQ > P6Jeks222kEaJIOheqNf/o07bznRP0FfVhwnDOV8BdhnNojlsMLDBKNaVrgSBI7U > nCRrG2a0vqAa4bXN7ONEpLE855LzWN3f6LFYS3BLzpAAzNyj0dJudRZURALvG1RE > Y+i1cMi5R5pbRcRudpoYsfcQM8gLUfVVjP0hHkGPTj6QXYAByLwkfoZoFBUUNDV0 > SbeHUinWll6ioxbUsNN7 > -----END CERTIFICATE----- > > > openssl x509 -in newsym1.cer -noout -subject > subject= /C=US/O=Symantec Corporation/OU=Symantec Trust > Network/CN=Symantec SHA256 TimeStamping Signer - G1 > > > Still getting > > openssl ts -verify -data SHA.sha -in SHA.sha.tsr -CApath newsym1.cer > Verification: FAILED > 139630315571016:error:2107C080:PKCS7 > routines:PKCS7_get0_signers:signer certificate not > found:pk7_smime.c:476: > > > > > > On 27 April 2016 at 14:53, Jakob Bohm wrote: >> OK, It looks like this signing service is (quite unusually) >> not providing the certificate in its message, which is quite >> unusual. >> >> All it provides is some information /about/ that certificate, >> specifically it provides the following info: >> >> The certificate was issued to C=US, O=Symantec Corporation, >> OU=Symantec Trust Network, >> CN=Symantec SHA256 TimeStamping Signer - G1 >> >> The certificate was issued by C=US, O=Symantec Corporation, >> OU=Symantec Trust Network, CN=Symantec SHA256 TimeStamping CA >> >> The certificate serial number (in hex) is >> 54 F3 7D A1 71 67 51 BC 6A 8D 0A D2 74 B2 8B 13 >> >> The certificate fingerprint (SHA-256) is >> 82 D5 56 DB DB 5D AD 5FA0 7B B6 07 26 A6 D8 6E >> 73 0B 5B B7 29 88 5B B6DE 4F F2 75 29 02 2C FC >> >> Someone with knowledge of the Symantec/Verisign/Thawte/GeoTrust/ >> TrustCenter repository web site may be able to use this >> information to download the missing certificates, but there >> is no information in this file that would allow a computer >> to do this. >> >> I wonder if changing some parameter in the timestamp request >> would cause the Symantec server to return a more complete >> timestamp token. >> >> Or maybe something else is failing. >> >> >> >> On 23/04/2016 00:54, Alex Samad wrote: >>> >>> Here is a dump. >>> >>> I can see the CN - but I could see that before. >>> >>> There is also a RSA - maybe a signature or maybe is the public key for the >>> cert. >>> >>> I would expect to see some signed data (sha + symantec cert + time) >>> and also the public cert ( and maybe the intermediaries..) >>> >>> >>> <30 82 03 AB> >>> 0 939: SEQUENCE { >>> <30 03> >>> 4 3: SEQUENCE { >>> <02 01> >>> 6 1: INTEGER 0 >>> : } >>> <30 82 03 A2> >>> 9 930: SEQUENCE { >>> <06 09> >>> 13 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) >>> : (PKCS #7) >>> >>> 24 915: [0] { >>> <30 82 03 8F> >>> 28 911: SEQUENCE { >>> <02 01> >>> 32 1: INTEGER 3 >>> <31 0D> >>> 35 13: SET { >>> <30 0B> >>> 37 11: SEQUENCE { >>> <06 09> >>> 39 9: OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1) >>> : (NIST Algorithm) >>> : } >>> : } >>> <30 82 01 1B> >>> 50 283: SEQUENCE { >>> <06 0B> >>> 54 11: OBJECT IDENTIFIER tSTInfo (1 2 840 113549 1 9 16 1 4) >>> : (S/MIME Content Types) >>> >>> 67 266: [0] { >>> <04 82 01 06> >>> 71 262: OCTET STRING, encapsulates { >>> <30 82 01 02> >>> 75 258: SEQUENCE { >>> <02 01> >>> 79 1: INTEGER 1 >>> <06 0B> >>> 82 11: OBJECT IDENTIFIER '2 16 840 1 113733 1 7 23 3' >>> <30 31> >>> 95 49: SEQUENCE { >>> <30 0D> >>> 97 13: SEQUENCE { >>> <06 09> >>> 99 9: OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 >>> 4 2 1) >>> : (NIST Algorithm) >>> <05 00> >>> 110 0: NULL >>> : } >>> <04 20> >>> 112 32: OCTET STRING >>> : 8C 6D 95 5B E0 CD 8B C9 .m.[.... >>> : DF 8C AB 57 45 C4 69 E6 ...WE.i. >>> : 7A B9 CE CB 14 8F 55 25 z.....U% >>> : 91 2E 57 37 3E 5C B8 D5 >>> : } >>> <02 14> >>> 146 20: INTEGER >>> : 57 0B 9C 3A 11 CA 31 8E W..:..1. >>> : 24 78 D3 68 0C 0F EF D9 $x.h.... >>> : 23 8E 06 AB #... >>> <18 0F> >>> 168 15: GeneralizedTime 19/04/2016 03:52:25 GMT >>> <30 03> >>> 185 3: SEQUENCE { >>> <02 01> >>> 187 1: INTEGER 30 >>> : } >>> <02 08> >>> 190 8: INTEGER 58 0E 59 D8 7F 39 6B 25 >>> >>> 200 134: [0] { >>> >>> 203 131: [4] { >>> <30 81 80> >>> 206 128: SEQUENCE { >>> <31 0B> >>> 209 11: SET { >>> <30 09> >>> 211 9: SEQUENCE { >>> <06 03> >>> 213 3: OBJECT IDENTIFIER countryName (2 5 4 6) >>> : (X.520 DN component) >>> <13 02> >>> 218 2: PrintableString 'US' >>> : } >>> : } >>> <31 1D> >>> 222 29: SET { >>> <30 1B> >>> 224 27: SEQUENCE { >>> <06 03> >>> 226 3: OBJECT IDENTIFIER organizationName (2 5 >>> 4 10) >>> : (X.520 DN component) >>> <13 14> >>> 231 20: PrintableString 'Symantec Corporation' >>> : } >>> : } >>> <31 1F> >>> 253 31: SET { >>> <30 1D> >>> 255 29: SEQUENCE { >>> <06 03> >>> 257 3: OBJECT IDENTIFIER >>> : organizationalUnitName (2 5 4 11) >>> : (X.520 DN component) >>> <13 16> >>> 262 22: PrintableString 'Symantec Trust >>> Network' >>> : } >>> : } >>> <31 31> >>> 286 49: SET { >>> <30 2F> >>> 288 47: SEQUENCE { >>> <06 03> >>> 290 3: OBJECT IDENTIFIER commonName (2 5 4 3) >>> : (X.520 DN component) >>> <13 28> >>> 295 40: PrintableString 'Symantec SHA256 >>> TimeStamping Signer - G1' >>> : } >>> : } >>> : } >>> : } >>> : } >>> : } >>> : } >>> : } >>> : } >>> <31 82 02 5A> >>> 337 602: SET { >>> <30 82 02 56> >>> 341 598: SEQUENCE { >>> <02 01> >>> 345 1: INTEGER 1 >>> <30 81 8B> >>> 348 139: SEQUENCE { >>> <30 77> >>> 351 119: SEQUENCE { >>> <31 0B> >>> 353 11: SET { >>> <30 09> >>> 355 9: SEQUENCE { >>> <06 03> >>> 357 3: OBJECT IDENTIFIER countryName (2 5 4 6) >>> : (X.520 DN component) >>> <13 02> >>> 362 2: PrintableString 'US' >>> : } >>> : } >>> <31 1D> >>> 366 29: SET { >>> <30 1B> >>> 368 27: SEQUENCE { >>> <06 03> >>> 370 3: OBJECT IDENTIFIER organizationName (2 5 4 10) >>> : (X.520 DN component) >>> <13 14> >>> 375 20: PrintableString 'Symantec Corporation' >>> : } >>> : } >>> <31 1F> >>> 397 31: SET { >>> <30 1D> >>> 399 29: SEQUENCE { >>> <06 03> >>> 401 3: OBJECT IDENTIFIER organizationalUnitName (2 5 >>> 4 11) >>> : (X.520 DN component) >>> <13 16> >>> 406 22: PrintableString 'Symantec Trust Network' >>> : } >>> : } >>> <31 28> >>> 430 40: SET { >>> <30 26> >>> 432 38: SEQUENCE { >>> <06 03> >>> 434 3: OBJECT IDENTIFIER commonName (2 5 4 3) >>> : (X.520 DN component) >>> <13 1F> >>> 439 31: PrintableString 'Symantec SHA256 TimeStamping >>> CA' >>> : } >>> : } >>> : } >>> <02 10> >>> 472 16: INTEGER 54 F3 7D A1 71 67 51 BC 6A 8D 0A D2 74 >>> B2 8B 13 >>> : } >>> <30 0B> >>> 490 11: SEQUENCE { >>> <06 09> >>> 492 9: OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1) >>> : (NIST Algorithm) >>> : } >>> >>> 503 164: [0] { >>> <30 1A> >>> 506 26: SEQUENCE { >>> <06 09> >>> 508 9: OBJECT IDENTIFIER contentType (1 2 840 113549 1 9 >>> 3) >>> : (PKCS #9) >>> <31 0D> >>> 519 13: SET { >>> <06 0B> >>> 521 11: OBJECT IDENTIFIER tSTInfo (1 2 840 113549 1 9 >>> 16 1 4) >>> : (S/MIME Content Types) >>> : } >>> : } >>> <30 1C> >>> 534 28: SEQUENCE { >>> <06 09> >>> 536 9: OBJECT IDENTIFIER signingTime (1 2 840 113549 1 9 >>> 5) >>> : (PKCS #9) >>> <31 0F> >>> 547 15: SET { >>> <17 0D> >>> 549 13: UTCTime 19/04/2016 03:52:25 GMT >>> : } >>> : } >>> <30 2F> >>> 564 47: SEQUENCE { >>> <06 09> >>> 566 9: OBJECT IDENTIFIER messageDigest (1 2 840 113549 1 >>> 9 4) >>> : (PKCS #9) >>> <31 22> >>> 577 34: SET { >>> <04 20> >>> 579 32: OCTET STRING >>> : 98 1B CF E1 5D 96 79 D6 ....].y. >>> : 47 53 3E 27 A1 0C 57 4E GS>'..WN >>> : 62 48 8E 43 F8 B5 17 D4 bH.C.... >>> : 1C 8F 9A 86 ED D7 A6 B4 >>> : } >>> : } >>> <30 37> >>> 613 55: SEQUENCE { >>> <06 0B> >>> 615 11: OBJECT IDENTIFIER >>> : signingCertificateV2 (1 2 840 113549 1 9 16 2 >>> 47) >>> : (S/MIME Authenticated Attributes) >>> <31 28> >>> 628 40: SET { >>> <30 26> >>> 630 38: SEQUENCE { >>> <30 24> >>> 632 36: SEQUENCE { >>> <30 22> >>> 634 34: SEQUENCE { >>> <04 20> >>> 636 32: OCTET STRING >>> : 82 D5 56 DB DB 5D AD 5F ..V..]._ >>> : A0 7B B6 07 26 A6 D8 6E .{..&..n >>> : 73 0B 5B B7 29 88 5B B6 s.[.).[. >>> : DE 4F F2 75 29 02 2C FC >>> : } >>> : } >>> : } >>> : } >>> : } >>> : } >>> <30 0B> >>> 670 11: SEQUENCE { >>> <06 09> >>> 672 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 >>> 1) >>> : (PKCS #1) >>> : } >>> <04 82 01 00> >>> 683 256: OCTET STRING >>> : 77 60 BE 64 F1 4C 04 B9 w`.d.L.. >>> : 4D 64 39 59 DC 53 27 02 Md9Y.S'. >>> : 06 1F 0C C7 31 EC 5B A2 ....1.[. >>> : 79 FB CA A3 07 DE D3 E6 y....... >>> : 88 CE 84 37 4C 20 EF DF ...7L .. >>> : 9B BB D4 0B 6F DC 42 05 ....o.B. >>> : DA 8D 22 EF 24 A8 46 68 ..".$.Fh >>> : 79 DA CB B5 A9 CD F6 7E y......~ >>> : D5 B8 D4 DD B4 44 5F 40 .....D_@ >>> : 0A A2 59 C8 3B 2C 52 6F ..Y.;,Ro >>> : BE 88 6C D3 A4 F6 3C B1 ..l...<. >>> : 52 27 25 E3 E9 6F 4A 2B R'%..oJ+ >>> : C6 C4 CD EA 73 65 6C 04 ....sel. >>> : 9A A4 79 4E A4 95 F4 F7 ..yN.... >>> : 1C C6 2E E8 D3 4B 01 8F .....K.. >>> : F2 0B 80 6C 28 67 3E 10 ...l(g>. >>> : D7 76 1E C5 4E BF 87 37 .v..N..7 >>> : CB 99 51 81 74 5C 50 57 ..Q.t\PW >>> : 80 3F 5D 3E 84 76 12 0A .?]>.v.. >>> : B0 A3 99 DF E5 3B A4 8F .....;.. >>> : DE 04 50 A8 E6 D0 00 6D ..P....m >>> : 61 21 B1 A9 A9 D6 05 79 a!.....y >>> : 0A 00 FA D5 1D A6 D6 F8 ........ >>> : 6A 22 07 E5 BC 01 C1 E0 j"...... >>> : 10 09 BD 92 09 B5 B7 29 .......) >>> : 8B 6A 4D 28 C4 63 7A 4C .jM(.czL >>> : 8E 7A AF 87 5D BE A4 BD .z..]... >>> : C1 20 9A D0 82 57 03 21 . ...W.! >>> : F3 E2 6F F5 44 22 F9 27 ..o.D".' >>> : 41 9C 66 27 BB 52 39 E2 A.f'.R9. >>> : 4B C8 2B 82 58 AC 0E AF K.+.X... >>> : 8D AE A5 C7 A5 1A A3 5E >>> : } >>> : } >>> : } >>> : } >>> : } >>> : } >>> >>> On 19 April 2016 at 14:29, Jakob Bohm wrote: >>>> >>>> On 19/04/2016 05:55, Alex Samad wrote: >>>>> >>>>> Hi >>>>> >>>>> I have a SHA.sha file >>>>> >>>>> /usr/bin/openssl ts -query -data SHA.sha -sha256 | /usr/bin/curl -s -H >>>>> Content-Type:application/timestamp-query --data-binary @- >>>>> http://sha256timestamp.ws.symantec.com/sha256/timestamp > SHA.sha.tsr >>>>> >>>>> /usr/bin/openssl ts -reply -in SHA.sha.tsr -text > SHA.sha.ts.txt >>>>> >>>>> >>>>> cat SHA.sha.ts.txt >>>>> Status info: >>>>> Status: Granted. >>>>> Status description: unspecified >>>>> Failure info: unspecified >>>>> >>>>> TST info: >>>>> Version: 1 >>>>> Policy OID: 2.16.840.1.113733.1.7.23.3 >>>>> Hash Algorithm: sha256 >>>>> Message data: >>>>> 0000 - 8c 6d 95 5b e0 cd 8b c9-df 8c ab 57 45 c4 69 e6 >>>>> .m.[.......WE.i. >>>>> 0010 - 7a b9 ce cb 14 8f 55 25-91 2e 57 37 3e 5c b8 d5 >>>>> z.....U%..W7>\.. >>>>> Serial number: 0x570B9C3A11CA318E2478D3680C0FEFD9238E06AB >>>>> Time stamp: Apr 19 03:52:25 2016 GMT >>>>> Accuracy: 0x1E seconds, unspecified millis, unspecified micros >>>>> Ordering: no >>>>> Nonce: 0x580E59D87F396B25 >>>>> TSA: DirName:/C=US/O=Symantec Corporation/OU=Symantec Trust >>>>> Network/CN=Symantec SHA256 TimeStamping Signer - G1 >>>>> Extensions: >>>>> >>>>> >>>>> But when I go to verify it >>>>> >>>>> openssl ts -verify -data SHA.sha -in SHA.sha.tsr >>>>> Verification: FAILED >>>>> 140569777235784:error:2107C080:PKCS7 >>>>> routines:PKCS7_get0_signers:signer certificate not >>>>> found:pk7_smime.c:476: >>>>> >>>>> is this because I didn't provide a cert to sign it with ? >>>> >>>> No, it is because it cannot find the certificate that Symantec >>>> used to sign the response, specifically the certificate with >>>> Subject name "/C=US/O=Symantec Corporation/OU=Symantec Trust >>>> Network/CN=Symantec SHA256 TimeStamping Signer - G1". >>>> >>>> I am kind of disappointed in how little detail is included in >>>> the output from ts -reply -text, I expected it to output all >>>> the fields, similar to what other openssl commands do when >>>> passed the -text option. >>>> >>>> So I guess the next step would be to dump SHA.sha.tsr using >>>> Peter Gutmann's dumpasn1.c program, something like >>>> >>>> openssl base64 -d -in SHA.sha.tsr -out SHA.sha.tsr.bin >>>> dumpasn1 -v SHA.sha.tsr.bin >>>> >>>> >> >> >> Enjoy >> >> Jakob >> -- >> Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com >> Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 >> This public discussion message is non-binding and may contain errors. >> WiseMo - Remote Service Management for PCs, Phones and Embedded >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From minfrin at sharp.fm Tue May 3 12:25:01 2016 From: minfrin at sharp.fm (Graham Leggett) Date: Tue, 3 May 2016 14:25:01 +0200 Subject: [openssl-users] openssl verify reporting errors where there are none Message-ID: Hi all, I am trying to use ?openssl verify? as a sanity check to determine whether a set of certificates are sane and valid in a script that issues (or reissues) the certificates, and I?m struggling with the output of the ?openssl verify? command. This is output I get while verifying three certificates in a chain: minfrin at localhost:~$ openssl verify -issuer_checks -trusted root-ca.crt -untrusted intermediate.crt cert.crt cert.crt: [stuff] error 29 at 0 depth lookup:subject issuer mismatch [stuff] error 29 at 0 depth lookup:subject issuer mismatch [stuff] error 29 at 0 depth lookup:subject issuer mismatch [stuff] error 29 at 0 depth lookup:subject issuer mismatch OK In theory the command just told me everything is ok. In practise, that command told the person running the script that 4 separate errors are present, which obviously in this case is not the case. Is there a way to suppress these spurious messages so I only see actual errors? Regards, Graham ? From steve at openssl.org Tue May 3 13:27:17 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 3 May 2016 13:27:17 +0000 Subject: [openssl-users] openssl verify reporting errors where there are none In-Reply-To: References: Message-ID: <20160503132717.GA832@openssl.org> On Tue, May 03, 2016, Graham Leggett wrote: > Hi all, > > I am trying to use ???openssl verify??? as a sanity check to determine whether a set of certificates are sane and valid in a script that issues (or reissues) the certificates, and I???m struggling with the output of the ???openssl verify??? command. > > This is output I get while verifying three certificates in a chain: > > minfrin at localhost:~$ openssl verify -issuer_checks -trusted root-ca.crt -untrusted intermediate.crt cert.crt > Is there a way to suppress these spurious messages so I only see actual errors? > Don't use -issuer_checks: it prints debugging information about certificates rejected during the verify process and it is quite normal for you to get that kind of output. Since this option is often the cause of confusion it has been removed from OpenSSL 1.1.0. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From openssl at openssl.org Tue May 3 14:02:15 2016 From: openssl at openssl.org (OpenSSL) Date: Tue, 3 May 2016 14:02:15 +0000 Subject: [openssl-users] OpenSSL version 1.0.1t published Message-ID: <20160503140215.GA9895@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.1t released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.1t of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.0.1-notes.html OpenSSL 1.0.1t is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.1t.tar.gz Size: 4556447 SHA1 checksum: a684ba59d6721a90f354b1953e19611646be7e7d SHA256 checksum: 4a6ee491a2fdb22e519c76fdc2a628bb3cec12762cd456861d207996c8a07088 The checksums were calculated using the following commands: openssl sha1 openssl-1.0.1t.tar.gz openssl sha256 openssl-1.0.1t.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXKKyEAAoJENnE0m0OYESRqdwH/19mvgPkcFwhZf8BEOcLNp8R ZMm6Equ16mZ6V/cpFiQX8YgFE3+4xAZu8c7K8luolVB/T5Y6DT7hk6j0T2HNyg39 osuKPrJI88MBGSGOyxE0mxtoktbM5TKQpkEhlUrqRkr3CA8Lr6IVDyG5xNHnKoPx 1BX0UdbCPWn3hHqcCVbQ4c5ShkDO8fRvtBp0btiwjdui8j2sTMzYHwvpWYhjj44o kOHeqXYmi++rWE9yRlH0ZhKg2RiRR7a2PEoe4eVgz3OCmiY9l4HsvJgA+yxkA0PH 2ZkitzB36UGDOEZm/6+/BbH2GzwXByrK3j01NGNAZlIQIehHepG/DT3THwE6kk4= =L527 -----END PGP SIGNATURE----- From openssl at openssl.org Tue May 3 14:02:32 2016 From: openssl at openssl.org (OpenSSL) Date: Tue, 3 May 2016 14:02:32 +0000 Subject: [openssl-users] OpenSSL version 1.0.2h published Message-ID: <20160503140232.GA9948@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.2h released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2h of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2h is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2h.tar.gz Size: 5274412 SHA1 checksum: 577585f5f5d299c44dd3c993d3c0ac7a219e4949 SHA256 checksum: 1d4007e53aad94a5b2002fe045ee7bb0b3d98f1a47f8b2bc851dcd1c74332919 The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2h.tar.gz openssl sha256 openssl-1.0.2h.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXKKvFAAoJENnE0m0OYESRrO8H/A2os59q+XwypwIsCVMw7TQF VlWEifT5DymXQosTQEQCZObi+JYsKNtl4ZijSiW13ZLKHC7hmTq4ml8AOEjZ+jfr V7fyvd/Mmz+6hut2F0b1/HhUKiOQkmvMksNSHhBk7NT+Kqb8MahCjDVqg6MbCx4r wdLLL5NEg4aUyAy6imK/KWsGuj6UfRXY+OaUmBslLMKwunvFR2SUht9E/iL1a492 9SSA+geJ0YQfqKTIVNaVzsz39gwUKrA2JVXJhUPF7e+9VElB5RyBB8IVuK5ce+5K xkzzLpqJE9U0yIN/os40b5jxwjNulHgnK/2xeAnAo2qT5nQWj2MPpYheJWA+jjU= =sGzF -----END PGP SIGNATURE----- From openssl at openssl.org Tue May 3 14:04:55 2016 From: openssl at openssl.org (OpenSSL) Date: Tue, 3 May 2016 14:04:55 +0000 Subject: [openssl-users] OpenSSL Security Advisory Message-ID: <20160503140455.GA10341@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL Security Advisory [3rd May 2016] ======================================== Memory corruption in the ASN.1 encoder (CVE-2016-2108) ====================================================== Severity: High This issue affected versions of OpenSSL prior to April 2015. The bug causing the vulnerability was fixed on April 18th 2015, and released as part of the June 11th 2015 security releases. The security impact of the bug was not known at the time. In previous versions of OpenSSL, ASN.1 encoding the value zero represented as a negative integer can cause a buffer underflow with an out-of-bounds write in i2c_ASN1_INTEGER. The ASN.1 parser does not normally create "negative zeroes" when parsing ASN.1 input, and therefore, an attacker cannot trigger this bug. However, a second, independent bug revealed that the ASN.1 parser (specifically, d2i_ASN1_TYPE) can misinterpret a large universal tag as a negative zero value. Large universal tags are not present in any common ASN.1 structures (such as X509) but are accepted as part of ANY structures. Therefore, if an application deserializes untrusted ASN.1 structures containing an ANY field, and later reserializes them, an attacker may be able to trigger an out-of-bounds write. This has been shown to cause memory corruption that is potentially exploitable with some malloc implementations. Applications that parse and re-encode X509 certificates are known to be vulnerable. Applications that verify RSA signatures on X509 certificates may also be vulnerable; however, only certificates with valid signatures trigger ASN.1 re-encoding and hence the bug. Specifically, since OpenSSL's default TLS X509 chain verification code verifies the certificate chain from root to leaf, TLS handshakes could only be targeted with valid certificates issued by trusted Certification Authorities. OpenSSL 1.0.2 users should upgrade to 1.0.2c OpenSSL 1.0.1 users should upgrade to 1.0.1o This vulnerability is a combination of two bugs, neither of which individually has security impact. The first bug (mishandling of negative zero integers) was reported to OpenSSL by Huzaifa Sidhpurwala (Red Hat) and independently by Hanno B??ck in April 2015. The second issue (mishandling of large universal tags) was found using libFuzzer, and reported on the public issue tracker on March 1st 2016. The fact that these two issues combined present a security vulnerability was reported by David Benjamin (Google) on March 31st 2016. The fixes were developed by Steve Henson of the OpenSSL development team, and David Benjamin. The OpenSSL team would also like to thank Mark Brand and Ian Beer from the Google Project Zero team for their careful analysis of the impact. The fix for the "negative zero" memory corruption bug can be identified by commits 3661bb4e7934668bd99ca777ea8b30eedfafa871 (1.0.2) and 32d3b0f52f77ce86d53f38685336668d47c5bdfe (1.0.1) Padding oracle in AES-NI CBC MAC check (CVE-2016-2107) ====================================================== Severity: High A MITM attacker can use a padding oracle attack to decrypt traffic when the connection uses an AES CBC cipher and the server support AES-NI. This issue was introduced as part of the fix for Lucky 13 padding attack (CVE-2013-0169). The padding check was rewritten to be in constant time by making sure that always the same bytes are read and compared against either the MAC or padding bytes. But it no longer checked that there was enough data to have both the MAC and padding bytes. OpenSSL 1.0.2 users should upgrade to 1.0.2h OpenSSL 1.0.1 users should upgrade to 1.0.1t This issue was reported to OpenSSL on 13th of April 2016 by Juraj Somorovsky using TLS-Attacker. The fix was developed by Kurt Roeckx of the OpenSSL development team. EVP_EncodeUpdate overflow (CVE-2016-2105) ========================================= Severity: Low An overflow can occur in the EVP_EncodeUpdate() function which is used for Base64 encoding of binary data. If an attacker is able to supply very large amounts of input data then a length check can overflow resulting in a heap corruption. Internally to OpenSSL the EVP_EncodeUpdate() function is primarly used by the PEM_write_bio* family of functions. These are mainly used within the OpenSSL command line applications. These internal uses are not considered vulnerable because all calls are bounded with length checks so no overflow is possible. User applications that call these APIs directly with large amounts of untrusted data may be vulnerable. (Note: Initial analysis suggested that the PEM_write_bio* were vulnerable, and this is reflected in the patch commit message. This is no longer believed to be the case). OpenSSL 1.0.2 users should upgrade to 1.0.2h OpenSSL 1.0.1 users should upgrade to 1.0.1t This issue was reported to OpenSSL on 3rd March 2016 by Guido Vranken. The fix was developed by Matt Caswell of the OpenSSL development team. EVP_EncryptUpdate overflow (CVE-2016-2106) ========================================== Severity: Low An overflow can occur in the EVP_EncryptUpdate() function. If an attacker is able to supply very large amounts of input data after a previous call to EVP_EncryptUpdate() with a partial block then a length check can overflow resulting in a heap corruption. Following an analysis of all OpenSSL internal usage of the EVP_EncryptUpdate() function all usage is one of two forms. The first form is where the EVP_EncryptUpdate() call is known to be the first called function after an EVP_EncryptInit(), and therefore that specific call must be safe. The second form is where the length passed to EVP_EncryptUpdate() can be seen from the code to be some small value and therefore there is no possibility of an overflow. Since all instances are one of these two forms, it is believed that there can be no overflows in internal code due to this problem. It should be noted that EVP_DecryptUpdate() can call EVP_EncryptUpdate() in certain code paths. Also EVP_CipherUpdate() is a synonym for EVP_EncryptUpdate(). All instances of these calls have also been analysed too and it is believed there are no instances in internal usage where an overflow could occur. This could still represent a security issue for end user code that calls this function directly. OpenSSL 1.0.2 users should upgrade to 1.0.2h OpenSSL 1.0.1 users should upgrade to 1.0.1t This issue was reported to OpenSSL on 3rd March 2016 by Guido Vranken. The fix was developed by Matt Caswell of the OpenSSL development team. ASN.1 BIO excessive memory allocation (CVE-2016-2109) ===================================================== Severity: Low When ASN.1 data is read from a BIO using functions such as d2i_CMS_bio() a short invalid encoding can casuse allocation of large amounts of memory potentially consuming excessive resources or exhausting memory. Any application parsing untrusted data through d2i BIO functions is affected. The memory based functions such as d2i_X509() are *not* affected. Since the memory based functions are used by the TLS library, TLS applications are not affected. OpenSSL 1.0.2 users should upgrade to 1.0.2h OpenSSL 1.0.1 users should upgrade to 1.0.1t This issue was reported to OpenSSL on 4th April 2016 by Brian Carpenter. The fix was developed by Stephen Henson of the OpenSSL development team. EBCDIC overread (CVE-2016-2176) =============================== Severity: Low ASN1 Strings that are over 1024 bytes can cause an overread in applications using the X509_NAME_oneline() function on EBCDIC systems. This could result in arbitrary stack data being returned in the buffer. OpenSSL 1.0.2 users should upgrade to 1.0.2h OpenSSL 1.0.1 users should upgrade to 1.0.1t This issue was reported to OpenSSL on 5th March 2016 by Guido Vranken. The fix was developed by Matt Caswell of the OpenSSL development team. Note ==== As per our previous announcements and our Release Strategy (https://www.openssl.org/policies/releasestrat.html), support for OpenSSL version 1.0.1 will cease on 31st December 2016. No security updates for that version will be provided after that date. Users of 1.0.1 are advised to upgrade. Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20160503.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXKK1XAAoJENnE0m0OYESRoEEH/RWG0sYKTrsYFC7Pqv56Pm1y DuH3txuEMI+P+vS4o0NVVOdhRgxNI4dDef/g60g+sCZlgD7lSJkw0iLvTn+/DvZg W+9b7VQlvqBG8HnvHsrHk11IT4eTg6nvjX0SsCU80feh3c4owpyht/meFYb4RCrJ 9UNCkyhaUNNXVwz3so9PgMpLugDEiymjjTyO4C/nb5vpVLHUP0qy6KPIlMPJD1mc wfU4kSwNzPwiCWHSYheaCbhPv8R+mQnX/LnwDeog913ojLdOGqTG8m392uf9Njzj SgBTrTPCE343qkyRgK8aKVxpu/TkCtGiSHCrqi0/2WrX0JZnuq2kUWKERO2ai1c= =2Tl5 -----END PGP SIGNATURE----- From Michal.Trojnara at stunnel.org Tue May 3 18:43:39 2016 From: Michal.Trojnara at stunnel.org (=?UTF-8?Q?Micha=c5=82_Trojnara?=) Date: Tue, 3 May 2016 20:43:39 +0200 Subject: [openssl-users] stunnel 5.32 released Message-ID: <5728F15B.8070406@stunnel.org> Dear Users, I have released version 5.32 of stunnel. The ChangeLog entry: Version 5.32, 2016.05.03, urgency: HIGH * Security bugfixes - OpenSSL DLLs updated to version 1.0.2h. https://www.openssl.org/news/secadv_20160503.txt * New features - New "socket = a:IPV6_V6ONLY=yes" option to only bind IPv6. - Memory leak detection. - Improved compatibility with the current OpenSSL 1.1.0-dev tree. - Added/fixed Red Hat scripts (thx to Andrew Colin Kissa). * Bugfixes - Workaround for a WinCE sockets quirk (thx to Richard Kraemer). - Fixed data alignment on 64-bit MSVC (thx to Yuris W. Auzins). Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 0ee64774d7a720f3ffd129b08557ee0882704c7f65b859c40e315a175b68a6fd stunnel-5.32.tar.gz 6e79f3e6f811f4efdbac65c2ce475db93aa4033e71e93a8bbc5c5a08036f932a stunnel-5.32-installer.exe bdb15e548c7985b01cadb21939d71f450aa044dcd955b97648821298ac1eeea1 stunnel-5.32-android.zip Best regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 884 bytes Desc: OpenPGP digital signature URL: From nospam001-lists at jankoh.mooo.com Tue May 3 22:21:57 2016 From: nospam001-lists at jankoh.mooo.com (Jan Kohnert) Date: Wed, 04 May 2016 00:21:57 +0200 Subject: [openssl-users] i2d_PKCS7_bio() very slow for large file when reading in memory In-Reply-To: <20160429152302.GB12313@openssl.org> References: <5664520.8aEQkn2sHV@kohni> <11905957.HbcaOcXK1q@kohni> <20160429152302.GB12313@openssl.org> Message-ID: <1934446.8WQuijrOi1@kohni> Hi, Am Freitag, 29. April 2016, 15:23:02 schrieb Dr. Stephen Henson: > Memory BIOs can be very inefficient when they contain a lot of data and it > is read in small chunks: each read copies the remaining data to the start > of the memory block. If your message uses indefinite length encoding that > could well happen. I wasn't aware of that, thanks! > If you read the data into a block of memory and call d2i_CMS_ContentInfo() > on it you shouldn't get this problem. Alternatively if you have to use a > memory BIO you can retrieve the pointer to the contained memory block using > BIO_get_mem_data() and call d2i_CMS_ContentInfo() on the result. > > A third option of to make the BIO read only and call d2i_CMS_bio() on that: > read only memory BIOs are handled more efficiently. I'll give your thoughts a shot! Thanks again, I'll post the results as soon as I'm able! -- MfG Jan From venki.manikanta at gmail.com Wed May 4 06:15:56 2016 From: venki.manikanta at gmail.com (mani kanta) Date: Wed, 4 May 2016 11:45:56 +0530 Subject: [openssl-users] While ssl handshake happens, getting error Operation not allowed in fips mode Message-ID: Hello, While the SSL handshake is happening,I am getting the error as below SSL_connect error:0408E09E:rsa routines:PKEY_RSA_SIGN:operation not allowed in fips mode. ssl handshake went well up to client sending key exchange to server and failing in the process of send client verify. Why this error happens ? and How to overcome this ? Background: 1. I built Openssl in FIPS mode. From the supplicant (application) I called FIPS_mode_set(1) API. In my use-case I am trying to connect WPA2 Enterprise Wi-Fi network which has EAP-TLS configured (used radius server to setup EAP-TLS). 2. From the network packets it is confirmed that the client and the server agreed on to use TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 cipher suit. Also found that if in case TLS_RSA_WITH_AES_256_CBC_SHA256 cipher suit is selected then also it throws the same above mentioned error. 3. I am using openssl verson 1.0.2f(client side). radius server(3.0.11) . Server is running in ubuntu 14.04 Please let me know if you need any further information. Thank you in advance. Regards, Venkat. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed May 4 09:33:24 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 4 May 2016 11:33:24 +0200 Subject: [openssl-users] While ssl handshake happens, getting error Operation not allowed in fips mode In-Reply-To: References: Message-ID: On 04/05/2016 08:15, mani kanta wrote: > > Hello, > > While the SSL handshake is happening,I am getting the error as below > SSL_connect error:0408E09E:rsa routines:PKEY_RSA_SIGN:operation not > allowed in fips mode. > ssl handshake went well up to client sending key exchange to server > and failing in the process of send client verify. Why this error > happens ? and How to overcome this ? > > Background: > 1. I built Openssl in FIPS mode. From the supplicant (application) I > called FIPS_mode_set(1) API. In my use-case I am trying to connect > WPA2 Enterprise Wi-Fi network which has EAP-TLS configured (used > radius server to setup EAP-TLS). > > 2. From the network packets it is confirmed that the client and the > server agreed on to use TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 cipher > suit. Also found that if in case TLS_RSA_WITH_AES_256_CBC_SHA256 > cipher suit is selected then also it throws the same above mentioned > error. > > 3. I am using openssl verson 1.0.2f(client side). radius > server(3.0.11) . Server is running in ubuntu 14.04 > > Is your RSA key too short (FIPS mode imposes a minimum key length by refusing to use shorter keys). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From noadsplease at web.de Wed May 4 10:21:08 2016 From: noadsplease at web.de (Dirk Menstermann) Date: Wed, 4 May 2016 12:21:08 +0200 Subject: [openssl-users] Problems with OpenSSL 1.0.2 h Message-ID: <9abc3eea-a9b6-18c9-94d3-5d49ffbd543f@web.de> Hi, I've trouble with the newest OpenSSL as I'm operating a webserver application that answers with HTTP1.x and HTTP2. I registered the ALPN callback and in this the cipher list was adjusted "SSL_set_cipher_list (ssl, "ECDHE-RSA-AES128-GCM-SHA256")" if H2 was negotiated. With versions < OpenSSL 1.0.2h this works, but now it seems that this cipher selection will be ignored, resulting in using a cipher that is black listed for HTTP2 (Firefox and Chrome refuse to connect) Was there an indented change or is there an official way to select the cipher based on the ALPN extension value? Thank you Dirk From bkaduk at akamai.com Wed May 4 16:04:41 2016 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 4 May 2016 11:04:41 -0500 Subject: [openssl-users] Problems with OpenSSL 1.0.2 h In-Reply-To: <9abc3eea-a9b6-18c9-94d3-5d49ffbd543f@web.de> References: <9abc3eea-a9b6-18c9-94d3-5d49ffbd543f@web.de> Message-ID: <572A1D99.5070003@akamai.com> Hello, On 05/04/2016 05:21 AM, Dirk Menstermann wrote: > Hi, > > I've trouble with the newest OpenSSL as I'm operating a webserver application > that answers with HTTP1.x and HTTP2. > > I registered the ALPN callback and in this the cipher list was adjusted > "SSL_set_cipher_list (ssl, "ECDHE-RSA-AES128-GCM-SHA256")" if H2 was negotiated. > > With versions < OpenSSL 1.0.2h this works, but now it seems that this cipher > selection will be ignored, resulting in using a cipher that is black listed for > HTTP2 (Firefox and Chrome refuse to connect) > > Was there an indented change or is there an official way to select the cipher > based on the ALPN extension value? > There was an intended change to the order in which ALPN extensions were processed, see https://github.com/openssl/openssl/commit/af2db04c9979554ada88d969da6332a827a47599 -- ALPN is now processed after SNI, since the ALPN callback is attached to the SSL_CTX, and SNI processing is likely to swap out the SSL_CTX in use. It does look like "late" TLS extensions are now handled after cipher selection, so the ALPN callback can no longer affect the negotiated cipher. Even at the specification level, how all the TLS extensions are supposed to interact with each other and the rest of the handshake is not terribly well specified, so adding -dev to discuss what the desired behavior actually is. -Ben From tshort at akamai.com Wed May 4 16:16:19 2016 From: tshort at akamai.com (Short, Todd) Date: Wed, 4 May 2016 16:16:19 +0000 Subject: [openssl-users] Problems with OpenSSL 1.0.2 h In-Reply-To: <572A1D99.5070003@akamai.com> References: <9abc3eea-a9b6-18c9-94d3-5d49ffbd543f@web.de> <572A1D99.5070003@akamai.com> Message-ID: <01226300-B4C2-47B7-B75E-A434B9901347@akamai.com> Have you tried to configure this cipher at the top of your cipher list initially with SSL_OP_SERVER_CIPHER_PREFERENCE? -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On May 4, 2016, at 12:04 PM, Benjamin Kaduk > wrote: Hello, On 05/04/2016 05:21 AM, Dirk Menstermann wrote: Hi, I've trouble with the newest OpenSSL as I'm operating a webserver application that answers with HTTP1.x and HTTP2. I registered the ALPN callback and in this the cipher list was adjusted "SSL_set_cipher_list (ssl, "ECDHE-RSA-AES128-GCM-SHA256")" if H2 was negotiated. With versions < OpenSSL 1.0.2h this works, but now it seems that this cipher selection will be ignored, resulting in using a cipher that is black listed for HTTP2 (Firefox and Chrome refuse to connect) Was there an indented change or is there an official way to select the cipher based on the ALPN extension value? There was an intended change to the order in which ALPN extensions were processed, see https://github.com/openssl/openssl/commit/af2db04c9979554ada88d969da6332a827a47599 -- ALPN is now processed after SNI, since the ALPN callback is attached to the SSL_CTX, and SNI processing is likely to swap out the SSL_CTX in use. It does look like "late" TLS extensions are now handled after cipher selection, so the ALPN callback can no longer affect the negotiated cipher. Even at the specification level, how all the TLS extensions are supposed to interact with each other and the rest of the handshake is not terribly well specified, so adding -dev to discuss what the desired behavior actually is. -Ben -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From ohaya at yahoo.com Wed May 4 16:29:23 2016 From: ohaya at yahoo.com (o haya) Date: Wed, 4 May 2016 16:29:23 +0000 (UTC) Subject: [openssl-users] Problems with ""sequencing" of FakeBasicAuth vs. Require using client certs for Authentication References: <1509525111.6059699.1462379363083.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1509525111.6059699.1462379363083.JavaMail.yahoo@mail.yahoo.com> [My apologies for this cross-post, but I think that I realized after I posted this on the Apache mailing list that it might be more appropriate here, as "SSLOptions +FakeBasicAuth" is under mod_ssl...] Hi, We are trying to use client certs with Apache 2.4.x (2.4.16, with openssl version 1.0.1e fips) and to have Apache check the client cert strings against users in an LDAP (and OpenDS instance but are encountering what appears to be a timing problem between when Apache authz_core is doing the authentication vs. when the FakeBasicAuth is happening. We CAN already do username/password (Basic) authentication against the LDAP using something like: AuthType Basic AuthName "xyz" AuthBasicProvider ldap AuthBasicLDAPURL AuthBASICLDAPDN AuthBASICLDAPPassword Require valid-user and that works fine (so the LDAP part appears to be working ok). However, if we use client certs and do the following: SSLVerifyClient required SSLOptions +FakeBasicAuth AuthType Basic AuthName "xyz" AuthBasicProvider ldap AuthBasicLDAPURL AuthBASICLDAPDN AuthBASICLDAPPassword Require valid-user then it doesn't work. Looking at the Apache logs, what we see when this fails is: mod_authz_core: AH01626: authorization result of Require valid-user : denied (no authenticated user yet) then mod_authz_core: AH01626: authorization result of : denied (no authenticated user yet) then ssl: AH02036: Faking HTTP Basic Auth header: "Authorization: Basic xxxxxxxxxxxxx" >From the logging (as above), it seems like mod_authz_core is denying the authentication (because there is no authenticated user yet) BEFORE the Basic Auth "Faking" occurs, and thus, BEFORE the LDAP authentication occurs. Does anyone know if this interpretation of what is happening correct? And, if so, is there some way to configure Apache so that it does the authentication vs. authentication checking in "the correct" order/sequence? Thanks! Jim P.S. I have also tried moving the LoadModule for mod_ssl to the last one but that didn't make a difference. From rsalz at akamai.com Wed May 4 16:33:53 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 4 May 2016 16:33:53 +0000 Subject: [openssl-users] Problems with ""sequencing" of FakeBasicAuth vs. Require using client certs for Authentication In-Reply-To: <1509525111.6059699.1462379363083.JavaMail.yahoo@mail.yahoo.com> References: <1509525111.6059699.1462379363083.JavaMail.yahoo.ref@mail.yahoo.com> <1509525111.6059699.1462379363083.JavaMail.yahoo@mail.yahoo.com> Message-ID: > [My apologies for this cross-post, but I think that I realized after I posted this > on the Apache mailing list that it might be more appropriate here, as > "SSLOptions +FakeBasicAuth" is under mod_ssl...] The apache mailing list(s) are probably a better forum -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From ohaya at yahoo.com Wed May 4 17:06:50 2016 From: ohaya at yahoo.com (o haya) Date: Wed, 4 May 2016 17:06:50 +0000 (UTC) Subject: [openssl-users] Problems with ""sequencing" of FakeBasicAuth vs. Require using client certs for Authentication References: <1860795874.6002091.1462381610242.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1860795874.6002091.1462381610242.JavaMail.yahoo@mail.yahoo.com> Hi, Ok, thanks! Jim -------------------------------------------- On Wed, 5/4/16, Salz, Rich wrote: Subject: RE: [openssl-users] Problems with ""sequencing" of FakeBasicAuth vs. Require using client certs for Authentication To: "o haya" , "openssl-users at openssl.org" Date: Wednesday, May 4, 2016, 12:33 PM > [My apologies for this cross-post, but I think that I realized after I posted this > on the Apache mailing list that it might be more appropriate here, as > "SSLOptions +FakeBasicAuth" is under mod_ssl...] The apache mailing list(s) are probably a better forum --? Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From noloader at gmail.com Thu May 5 05:06:45 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 5 May 2016 01:06:45 -0400 Subject: [openssl-users] Get effective OPENSSLDIR path at runtime? Message-ID: Hi Everyone, opensslconf.h has a macro for the configured OpenSSL directory. We can find the configured location of opendssl.cnf by using OPENSSLDIR. However, the path can be influenced by `-config` options (for openssl apps) and the `OPENSSL_CONF` environmental variable at runtime. How can we get effective OPENSSLDIR path at runtime? Thanks in advance. From marquess at opensslfoundation.org Thu May 5 20:41:00 2016 From: marquess at opensslfoundation.org (Steve Marquess) Date: Thu, 5 May 2016 16:41:00 -0400 Subject: [openssl-users] good riddance to PayPal Message-ID: <572BAFDC.2090009@opensslfoundation.org> We've had a PayPal account for years, as the most convenient way for individuals to send small donations. However, as the person who has managed that account I can attest that PayPal has always been rather annoying to deal with, and I've finally hit my limit. I'm in the process of closing that account (something PayPal makes unnecessarily difficult and protracted). I was able to refund most of the recent donations that we were unable to recover, leaving a balance of $259.45 that will either be forfeited to PayPal or (hopefully) refunded by them back to the original donors. The PayPal donate link ("button") on our web site has been removed. I've asked PayPal to block any future inbound transactions while we fight over the account closure, but can't be confident that was done. Please do not donate via PayPal to any account claiming to represent us; such donations won't go to us and may not ever be returned to you. This closure of the only convenient means of receiving small donations does not mean that we do not value such donations. Those of you who have donated via PayPal, many via recurring donations, have our gratitude and thanks. I regret that there is no clear alternative to switch to instead (suggestions welcome if there are options I'm unaware of). -Steve M. -- Steve Marquess OpenSSL Software Foundation 20-22 Wenlock Road London N1 7GU United Kingdom +44 1785508015 +1 301 874 2571 direct marquess at opensslfoundation.org stevem at openssl.org From nospam001-lists at jankoh.mooo.com Thu May 5 21:13:04 2016 From: nospam001-lists at jankoh.mooo.com (Jan Kohnert) Date: Thu, 05 May 2016 23:13:04 +0200 Subject: [openssl-users] i2d_PKCS7_bio() very slow for large file when reading in memory In-Reply-To: <1934446.8WQuijrOi1@kohni> References: <5664520.8aEQkn2sHV@kohni> <20160429152302.GB12313@openssl.org> <1934446.8WQuijrOi1@kohni> Message-ID: <2299054.VBRee1lCDy@kohni> Hi again, I promised to update, when results are ready? Am Mittwoch, 4. Mai 2016, 00:21:57 schrieb Jan Kohnert: > Am Freitag, 29. April 2016, 15:23:02 schrieb Dr. Stephen Henson: > > If you read the data into a block of memory and call d2i_CMS_ContentInfo() > > on it you shouldn't get this problem. Alternatively if you have to use a > > memory BIO you can retrieve the pointer to the contained memory block > > using > > BIO_get_mem_data() and call d2i_CMS_ContentInfo() on the result. > > > > A third option of to make the BIO read only and call d2i_CMS_bio() on > > that: > > read only memory BIOs are handled more efficiently. The code now reads: ---------------------------------- // init, keys, certs, stuff... // read file BIO *bioCryptedData = NULL; bioCryptedData = BIO_new_file( dataFile, "r" ); // infile DER to internal format PKCS7 *cryptData = NULL; d2i_PKCS7_bio( bioCryptedData, &cryptData ); // decrypt BIO *bioSignedData = NULL; bioSignedData = BIO_new( BIO_s_mem() ); PKCS7_decrypt(cryptData, m_PKey, NULL, bioSignedData, NULL); // magic from ML long length = 0; unsigned char *pointer = NULL; length = BIO_get_mem_data(bioSignedData, &pointer); CMS_ContentInfo *signedData = NULL; d2i_CMS_ContentInfo(&signedData, (const unsigned char **) &pointer, length); // verify BIO *bioClearText = NULL; bioClearText = BIO_new_file( clearFile, "w" ) ); CMS_verify(signedData, NULL, m_VeriStore, NULL, bioClearText, NULL); // do stuff with the decrypted file, close bio's etc... ---------------------------------- And BOOOM! The decryption/verification of my 65MiB testfile reduces from >10m to <2sec. *yeah* Thanks again, folks! -- MfG Jan From luis.daniel.lucio at gmail.com Thu May 5 22:34:38 2016 From: luis.daniel.lucio at gmail.com (Luis Daniel Lucio Quiroz) Date: Thu, 5 May 2016 18:34:38 -0400 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <572BAFDC.2090009@opensslfoundation.org> References: <572BAFDC.2090009@opensslfoundation.org> Message-ID: What about stripe? Le 5 mai 2016 4:57 PM, "Steve Marquess" a ?crit : > We've had a PayPal account for years, as the most convenient way for > individuals to send small donations. However, as the person who has > managed that account I can attest that PayPal has always been rather > annoying to deal with, and I've finally hit my limit. I'm in the process > of closing that account (something PayPal makes unnecessarily difficult > and protracted). I was able to refund most of the recent donations that > we were unable to recover, leaving a balance of $259.45 that will either > be forfeited to PayPal or (hopefully) refunded by them back to the > original donors. > > The PayPal donate link ("button") on our web site has been removed. I've > asked PayPal to block any future inbound transactions while we fight > over the account closure, but can't be confident that was done. Please > do not donate via PayPal to any account claiming to represent us; such > donations won't go to us and may not ever be returned to you. > > This closure of the only convenient means of receiving small donations > does not mean that we do not value such donations. Those of you who have > donated via PayPal, many via recurring donations, have our gratitude and > thanks. I regret that there is no clear alternative to switch to instead > (suggestions welcome if there are options I'm unaware of). > > -Steve M. > > -- > Steve Marquess > OpenSSL Software Foundation > 20-22 Wenlock Road > London N1 7GU > United Kingdom > +44 1785508015 > +1 301 874 2571 direct > marquess at opensslfoundation.org > stevem at openssl.org > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stevem at openssl.org Thu May 5 22:59:46 2016 From: stevem at openssl.org (Steve Marquess) Date: Thu, 5 May 2016 18:59:46 -0400 Subject: [openssl-users] good riddance to PayPal In-Reply-To: References: <572BAFDC.2090009@opensslfoundation.org> Message-ID: <572BD062.6080805@openssl.org> On 05/05/2016 06:34 PM, Luis Daniel Lucio Quiroz wrote: > What about stripe? > > ... I think I may have looked at that before, but I'll revisit it. Note we would qualify to have a direct "merchant account" with one of the major credit card processors, but found out there is a requirement that the web site on which payments are processed be located in the U.S. Our servers are all in Europe, appropriately so. -Steve M. -- Steve Marquess OpenSSL Software Foundation 20-22 Wenlock Road London N1 7GU United Kingdom +44 1785508015 +1 301 874 2571 direct marquess at opensslfoundation.org stevem at openssl.org From debbie10t at gmail.com Thu May 5 23:52:20 2016 From: debbie10t at gmail.com (debbie10t) Date: Fri, 6 May 2016 00:52:20 +0100 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <572BAFDC.2090009@opensslfoundation.org> References: <572BAFDC.2090009@opensslfoundation.org> Message-ID: <572BDCB4.4080809@gmail.com> Hello, On 05/05/16 21:41, Steve Marquess wrote: > We've had a PayPal account for years, as the most convenient way for > individuals to send small donations. However, as the person who has > managed that account I can attest that PayPal has always been rather > annoying to deal with, and I've finally hit my limit. I'm in the process > of closing that account (something PayPal makes unnecessarily difficult > and protracted). I was able to refund most of the recent donations that > we were unable to recover, leaving a balance of $259.45 that will either > be forfeited to PayPal or (hopefully) refunded by them back to the > original donors. > > The PayPal donate link ("button") on our web site has been removed. I've > asked PayPal to block any future inbound transactions while we fight > over the account closure, but can't be confident that was done. Please > do not donate via PayPal to any account claiming to represent us; such > donations won't go to us and may not ever be returned to you. > > This closure of the only convenient means of receiving small donations > does not mean that we do not value such donations. Those of you who have > donated via PayPal, many via recurring donations, have our gratitude and > thanks. I regret that there is no clear alternative to switch to instead > (suggestions welcome if there are options I'm unaware of). > > -Steve M. > I do hope an excellent solution can be found. Apologies in advance for this probably going off topic. Steve, could you possibly provide any details of how Paypal caused you to "finally hit your limit" ? (your blog would be great) I am sure I am not the only curious person reading this ;) Many Thanks -- From marquess at opensslfoundation.org Fri May 6 00:08:35 2016 From: marquess at opensslfoundation.org (Steve Marquess) Date: Thu, 5 May 2016 20:08:35 -0400 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <572BDCB4.4080809@gmail.com> References: <572BAFDC.2090009@opensslfoundation.org> <572BDCB4.4080809@gmail.com> Message-ID: <572BE083.40500@opensslfoundation.org> On 05/05/2016 07:52 PM, debbie10t wrote: > Hello, > > On 05/05/16 21:41, Steve Marquess wrote: >> We've had a PayPal account for years, as the most convenient way for >> individuals to send small donations. However, as the person who has >> managed that account I can attest that PayPal has always been rather >> annoying to deal with, and I've finally hit my limit. ... > > I do hope an excellent solution can be found. > > Apologies in advance for this probably going off topic. > > Steve, could you possibly provide any details of how Paypal > caused you to "finally hit your limit" ? > (your blog would be great) > > I am sure I am not the only curious person reading this ;) Well, I don't want to turn this into a PayPal bashing session ... I do recognize that they have a huge number of customers, that fraud is a constant problem, and that they need to economize on the human element in their customer support operations. But briefly put, the last straw in this case was yet another "your account has been limited" drill where access to our funds is blocked and we're now required to send in copies of my passport and social security card, and battle with their tedious voice response system. This time that initial call took only 28 minutes, quicker than usual, but I'm tired of never knowing when they will arbitrarily slam some sort of arbitrary restriction on the account that takes hours of my time to resolve. I'll still need at least one more call to close the account ... sigh. -Steve M. -- Steve Marquess OpenSSL Software Foundation 20-22 Wenlock Road London N1 7GU United Kingdom +44 1785508015 +1 301 874 2571 direct marquess at opensslfoundation.org stevem at openssl.org From debbie10t at gmail.com Fri May 6 00:28:21 2016 From: debbie10t at gmail.com (debbie10t) Date: Fri, 6 May 2016 01:28:21 +0100 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <572BE083.40500@opensslfoundation.org> References: <572BAFDC.2090009@opensslfoundation.org> <572BDCB4.4080809@gmail.com> <572BE083.40500@opensslfoundation.org> Message-ID: <572BE525.2050405@gmail.com> On 06/05/16 01:08, Steve Marquess wrote: > On 05/05/2016 07:52 PM, debbie10t wrote: >> Hello, >> >> On 05/05/16 21:41, Steve Marquess wrote: >>> We've had a PayPal account for years, as the most convenient way for >>> individuals to send small donations. However, as the person who has >>> managed that account I can attest that PayPal has always been rather >>> annoying to deal with, and I've finally hit my limit. ... >> I do hope an excellent solution can be found. >> >> Apologies in advance for this probably going off topic. >> >> Steve, could you possibly provide any details of how Paypal >> caused you to "finally hit your limit" ? >> (your blog would be great) >> >> I am sure I am not the only curious person reading this ;) > Well, I don't want to turn this into a PayPal bashing session ... I do > recognize that they have a huge number of customers, that fraud is a > constant problem, and that they need to economize on the human element > in their customer support operations. But briefly put, the last straw in > this case was yet another "your account has been limited" drill where > access to our funds is blocked and we're now required to send in copies > of my passport and social security card, and battle with their tedious > voice response system. This time that initial call took only 28 minutes, > quicker than usual, but I'm tired of never knowing when they will > arbitrarily slam some sort of arbitrary restriction on the account that > takes hours of my time to resolve. I'll still need at least one more > call to close the account ... sigh. > > -Steve M. > Steve, thank you for your clearly honest reply, I too share a hatred of voice response systems .. i prefer to press a button too .. "If i can call the xx digit international number i can surely press one or two more .. " Alternative suggestion to quitting Paypal outright: Get somebody you trust to handle Them // "as the most convenient way .. " * not a paypal stooge .. think a little "out of the box" thinking may help :) Highest regards -- From jb-openssl at wisemo.com Fri May 6 08:37:35 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 6 May 2016 10:37:35 +0200 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <572BD062.6080805@openssl.org> References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> Message-ID: On 06/05/2016 00:59, Steve Marquess wrote: > On 05/05/2016 06:34 PM, Luis Daniel Lucio Quiroz wrote: >> What about stripe? >> >> ... > I think I may have looked at that before, but I'll revisit it. > > Note we would qualify to have a direct "merchant account" with one of > the major credit card processors, but found out there is a requirement > that the web site on which payments are processed be located in the U.S. > Our servers are all in Europe, appropriately so. There are global payment processors in Europe too, usually covering only companies/websites in one country. For example our web sites currently accept payments via a Merchant account in our home country, set up via a local dedicated payment front end service known as DIBS, which does the heavy lifting of being PCI certified, and also assures our customers that their credit card details are never shared back to our servers. Basically, the end user enters their credit card on their site during the transaction, and we get the final result as they link back to our site at the end. Of note is that while our company is in the country of the Merchant account and service provider, our servers are elsewhere entirely. So it should be possible to find a similar service in the country where the OpenSSL is legally based, but please avoid services that make users set up accounts or otherwise complicate the transaction, such as "Money Bookers" or PayPal. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From michel.sales at free.fr Fri May 6 08:40:29 2016 From: michel.sales at free.fr (Michel) Date: Fri, 6 May 2016 10:40:29 +0200 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <572BD062.6080805@openssl.org> References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> Message-ID: <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> Hi steve, Isn't it conceivable to ask one of the European payment service provider to sponsor you by offering a free account / accesss to their plateform ? I know some which are secured only with the help of your product. They should be proud to help in return. :-) -----Message d'origine----- De?: openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de Steve Marquess Envoy??: vendredi 6 mai 2016 01:00 ??: openssl-users at openssl.org Objet?: Re: [openssl-users] good riddance to PayPal Note we would qualify to have a direct "merchant account" with one of the major credit card processors, but found out there is a requirement that the web site on which payments are processed be located in the U.S. Our servers are all in Europe, appropriately so. From marquess at opensslfoundation.org Fri May 6 10:36:20 2016 From: marquess at opensslfoundation.org (Steve Marquess) Date: Fri, 6 May 2016 06:36:20 -0400 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> Message-ID: <572C73A4.8090603@opensslfoundation.org> On 05/06/2016 04:40 AM, Michel wrote: > Hi steve, > > Isn't it conceivable to ask one of the European payment service provider to > sponsor you by offering a free account / accesss to their plateform ? > I know some which are secured only with the help of your product. > They should be proud to help in return. > :-) In my role as the OpenSSL beancounter I've run into a more general issue with non-U.S. banks. The great bulk of our donation funding comes from outside the U.S. and is spent outside the U.S., and really shouldn't need to reside in or even transit through the U.S. But, since I'm American and know that country best that's where I set up the OpenSSL legal entities and bank accounts years ago. I've been trying unsuccessfully to transition our funding to a non-U.S. bank for some time. But, we're an unusual organization (banks don't like unusual) and I also am operating under a severe handicap known as "FATCA", the TL;DR of which being that when a bank sees I'm calling from a U.S. number and speaking with an obvious U.S. accent they can't dismiss me fast enough, usually before I get the chance to emphasize that no "U.S. person" needs to have signature authority for the account. I've been through this drill with dozens of banks, from Estonia to Singapore. We've gotten as far as opening an account with an initial deposit, only to have that bank close the account for unspecified reasons a week later. I've spent an unbelievable amount of time on this. If there is a non-U.S. bank willing to have OpenSSL as a customer I'd love to talk to them. We've even created non-U.S. corporate entities (in IoM and BVI) for that purpose; after many months they remain bankless. -Steve M. -- Steve Marquess OpenSSL Software Foundation 20-22 Wenlock Road London N1 7GU United Kingdom +44 1785508015 +1 301 874 2571 direct marquess at opensslfoundation.org stevem at openssl.org From jb-openssl at wisemo.com Fri May 6 10:52:49 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 6 May 2016 12:52:49 +0200 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <572C73A4.8090603@opensslfoundation.org> References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> <572C73A4.8090603@opensslfoundation.org> Message-ID: On 06/05/2016 12:36, Steve Marquess wrote: > On 05/06/2016 04:40 AM, Michel wrote: >> Hi steve, >> >> Isn't it conceivable to ask one of the European payment service provider to >> sponsor you by offering a free account / accesss to their plateform ? >> I know some which are secured only with the help of your product. >> They should be proud to help in return. >> :-) > In my role as the OpenSSL beancounter I've run into a more general issue > with non-U.S. banks. The great bulk of our donation funding comes from > outside the U.S. and is spent outside the U.S., and really shouldn't > need to reside in or even transit through the U.S. But, since I'm > American and know that country best that's where I set up the OpenSSL > legal entities and bank accounts years ago. > > I've been trying unsuccessfully to transition our funding to a non-U.S. > bank for some time. But, we're an unusual organization (banks don't like > unusual) and I also am operating under a severe handicap known as > "FATCA", the TL;DR of which being that when a bank sees I'm calling from > a U.S. number and speaking with an obvious U.S. accent they can't > dismiss me fast enough, usually before I get the chance to emphasize > that no "U.S. person" needs to have signature authority for the account. > I've been through this drill with dozens of banks, from Estonia to > Singapore. We've gotten as far as opening an account with an initial > deposit, only to have that bank close the account for unspecified > reasons a week later. I've spent an unbelievable amount of time on this. > > If there is a non-U.S. bank willing to have OpenSSL as a customer I'd > love to talk to them. We've even created non-U.S. corporate entities (in > IoM and BVI) for that purpose; after many months they remain bankless. > > Consider having the non-U.S. person do the account setup too. Banks are as scared of US jurisdiction as crypto engineers. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From rsalz at akamai.com Fri May 6 11:45:31 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 6 May 2016 11:45:31 +0000 Subject: [openssl-users] good riddance to PayPal In-Reply-To: References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> <572C73A4.8090603@opensslfoundation.org> Message-ID: > Consider having the non-U.S. person do the account setup too. > > Banks are as scared of US jurisdiction as crypto engineers. Yeah, we've done that. Even to the point where one of the team was going to get on a plane to fly to the Isle of Mann. It's amazingly painful and difficult and so far not productive. If folks want to give OpenSSL money, mail a check or cash. From marquess at openssl.com Fri May 6 12:06:48 2016 From: marquess at openssl.com (Steve Marquess) Date: Fri, 6 May 2016 08:06:48 -0400 Subject: [openssl-users] good riddance to PayPal In-Reply-To: References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> <572C73A4.8090603@opensslfoundation.org> Message-ID: <572C88D8.2090007@openssl.com> On 05/06/2016 07:45 AM, Salz, Rich wrote: >> Consider having the non-U.S. person do the account setup too. >> >> Banks are as scared of US jurisdiction as crypto engineers. > > Yeah, we've done that. Even to the point where one of the team was going to get on a plane to fly to the Isle of Mann. > > It's amazingly painful and difficult and so far not productive. > > ... FATCA means that no "U.S. person" can have any access to the bank account; we are well and painfully aware of that, and it's not a problem. Only three of us fall in that category anyway; OpenSSL is not a U.S. centric organization. Our U.S. connections are only due to the circumstantial fact that the OpenSSL team member (me) who initially set up our banking arrangements happened to be American. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From jb-openssl at wisemo.com Fri May 6 13:14:26 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 6 May 2016 15:14:26 +0200 Subject: [openssl-users] good riddance to PayPal In-Reply-To: References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> <572C73A4.8090603@opensslfoundation.org> Message-ID: <49b20b9e-a029-2ba3-bbaa-399a36204eb3@wisemo.com> On 06/05/2016 13:45, Salz, Rich wrote: >> Consider having the non-U.S. person do the account setup too. >> >> Banks are as scared of US jurisdiction as crypto engineers. > Yeah, we've done that. Even to the point where one of the team was going to get on a plane to fly to the Isle of Mann. > > It's amazingly painful and difficult and so far not productive. > > If folks want to give OpenSSL money, mail a check or cash. I was thinking of the more simple solution of setting up the account in the same non-US bank where the team member does his other business. Lots of this tends to get easier when the person is an existing customer and the bank is nearby. Each non-US team member presumably has at least one existing bank relationship and presumably knowledge and/or easy access to information on how to set up an independent legal entity in his/her own country. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From marquess at opensslfoundation.org Fri May 6 13:26:10 2016 From: marquess at opensslfoundation.org (Steve Marquess) Date: Fri, 6 May 2016 09:26:10 -0400 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <49b20b9e-a029-2ba3-bbaa-399a36204eb3@wisemo.com> References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> <572C73A4.8090603@opensslfoundation.org> <49b20b9e-a029-2ba3-bbaa-399a36204eb3@wisemo.com> Message-ID: <572C9B72.1010503@opensslfoundation.org> On 05/06/2016 09:14 AM, Jakob Bohm wrote: > On 06/05/2016 13:45, Salz, Rich wrote: >>> Consider having the non-U.S. person do the account setup too. >>> >>> Banks are as scared of US jurisdiction as crypto engineers. >> Yeah, we've done that. Even to the point where one of the team was >> going to get on a plane to fly to the Isle of Mann. >> >> It's amazingly painful and difficult and so far not productive. >> >> If folks want to give OpenSSL money, mail a check or cash. > I was thinking of the more simple solution of setting up > the account in the same non-US bank where the team member > does his other business. Lots of this tends to get easier > when the person is an existing customer and the bank is > nearby. > > Each non-US team member presumably has at least one existing > bank relationship and presumably knowledge and/or easy access > to information on how to set up an independent legal entity > in his/her own country. Personal bank accounts, yes. But, we don't want to entangle OpenSSL funds with any team members personal finances. Those funds need to be held by an independent OpenSSL legal entity (of which there are already several). Also keep in mind that most of my colleagues are hardcore geeks best suited to wrangling OpenSSL code. I try to handle as many paperwork hassles as possible to free them for that more important activity. As for setting up "an independent legal entity", we have engaged a number of (expensive) accountants and attorneys to that end, and along the way have created two non-U.S. legal entities. The bank account(s) those entities would need to be of any value have proven to be the bigger challenge. The issue is still being actively worked, and I'm sure we'll solve it eventually. I initially (as someone who has created multiple U.S. companies) thought it would be as easy as you assume. It's been an education. -Steve M. -- Steve Marquess OpenSSL Software Foundation 20-22 Wenlock Road London N1 7GU United Kingdom +44 1785508015 +1 301 874 2571 direct marquess at opensslfoundation.org stevem at openssl.org From murugesh.pitchaiah at gmail.com Fri May 6 13:47:46 2016 From: murugesh.pitchaiah at gmail.com (murugesh pitchaiah) Date: Fri, 6 May 2016 19:17:46 +0530 Subject: [openssl-users] OCSP_basic_verify certs Message-ID: Hi, I am implementing the OCSP for my application. Have a doubt on the 'certs' argument for the API "OCSP_basic_verify": int OCSP_basic_verify(OCSP_BASICRESP *bs, STACK_OF(X509) *certs, X509_STORE *st, unsigned long flags); Here the second argument 'certs'. I understand we need to push the below to this STACK_OF(X509): 1) Issuer certificate 2) Signature CA certificates - to support trusted responder model I have multiple signature CA certificates as individual PEM format files (say 5 PEM files), inside a directory (say /config/ssl/signature-ca). How can i push all these 5 signature CA certs to this STACK_OF (X509) using sk_X509_push ? Any openSSL library API is there to push all files from a directory to this STACK_OF(X509) ? Thanks & Regards, Murugesh P. From aeh at db.org Fri May 6 13:41:34 2016 From: aeh at db.org (Alfred E. Heggestad) Date: Fri, 6 May 2016 15:41:34 +0200 Subject: [openssl-users] [PATCH] dtls: reduce initial timeout value to 500ms Message-ID: <572C9F0E.9020406@db.org> Hi, we are using OpenSSL in our product, mainly the DTLS-SRTP part to exchange keys for SRTP using DTLS. Our network environment is rather hostile, with highly variable bandwidth, some packet loss and some connections with slightly high RTT. the current DTLS stack in OpenSSL (v1.0.2) starts with a timeout value of 1 second, which is doubled for every retransmit. For us this is too high. I would like to reduce the initial value to around 500ms, and preferably make it run-time configurable. the patch below is a working patch, attached for the purpose of discussion. From 70a72c5102bab63373169615d3b26ded8399f227 Mon Sep 17 00:00:00 2001 From: "Alfred E. Heggestad" Date: Fri, 6 May 2016 15:31:20 +0200 Subject: [PATCH] dtls: reduce initial timeout from 1.0 to 0.5 seconds --- ssl/d1_lib.c | 9 +++++++-- ssl/d1_pkt.c | 2 +- ssl/dtls1.h | 4 ++-- 3 files changed, 10 insertions(+), 5 deletions(-) diff --git a/ssl/d1_lib.c b/ssl/d1_lib.c index ee78921..027d893 100644 --- a/ssl/d1_lib.c +++ b/ssl/d1_lib.c @@ -359,6 +359,8 @@ const SSL_CIPHER *dtls1_get_cipher(unsigned int u) void dtls1_start_timer(SSL *s) { + struct timeval diff; + #ifndef OPENSSL_NO_SCTP /* Disable timer for SCTP */ if (BIO_dgram_is_sctp(SSL_get_wbio(s))) { @@ -369,14 +371,17 @@ void dtls1_start_timer(SSL *s) /* If timer is not set, initialize duration with 1 second */ if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec == 0) { - s->d1->timeout_duration = 1; + s->d1->timeout_duration = 0.5; } /* Set timeout to current time */ get_current_time(&(s->d1->next_timeout)); /* Add duration to current time */ - s->d1->next_timeout.tv_sec += s->d1->timeout_duration; + diff.tv_sec = 0; + diff.tv_usec = 1000000*s->d1->timeout_duration; + timeradd(&s->d1->next_timeout, &diff, &s->d1->next_timeout); + BIO_ctrl(SSL_get_rbio(s), BIO_CTRL_DGRAM_SET_NEXT_TIMEOUT, 0, &(s->d1->next_timeout)); } diff --git a/ssl/d1_pkt.c b/ssl/d1_pkt.c index fe30ec7..3330fd6 100644 --- a/ssl/d1_pkt.c +++ b/ssl/d1_pkt.c @@ -1502,7 +1502,7 @@ int do_dtls1_write(SSL *s, int type, const unsigned char *buf, * will happen with non blocking IO */ if (s->s3->wbuf.left != 0) { - OPENSSL_assert(0); /* XDTLS: want to see if we ever get here */ + /*OPENSSL_assert(0);*/ /* XDTLS: want to see if we ever get here */ return (ssl3_write_pending(s, type, buf, len)); } diff --git a/ssl/dtls1.h b/ssl/dtls1.h index 30bbcf2..077fee5 100644 --- a/ssl/dtls1.h +++ b/ssl/dtls1.h @@ -225,8 +225,8 @@ typedef struct dtls1_state_st { * Indicates when the last handshake msg or heartbeat sent will timeout */ struct timeval next_timeout; - /* Timeout duration */ - unsigned short timeout_duration; + /* Timeout duration in Seconds */ + double timeout_duration; /* * storage for Alert/Handshake protocol data received but not yet * processed by ssl3_read_bytes: -- 1.9.3 (Apple Git-50) From jb-openssl at wisemo.com Fri May 6 14:29:26 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 6 May 2016 16:29:26 +0200 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <572C9B72.1010503@opensslfoundation.org> References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> <572C73A4.8090603@opensslfoundation.org> <49b20b9e-a029-2ba3-bbaa-399a36204eb3@wisemo.com> <572C9B72.1010503@opensslfoundation.org> Message-ID: On 06/05/2016 15:26, Steve Marquess wrote: > On 05/06/2016 09:14 AM, Jakob Bohm wrote: >> On 06/05/2016 13:45, Salz, Rich wrote: >>>> Consider having the non-U.S. person do the account setup too. >>>> >>>> Banks are as scared of US jurisdiction as crypto engineers. >>> Yeah, we've done that. Even to the point where one of the team was >>> going to get on a plane to fly to the Isle of Mann. >>> >>> It's amazingly painful and difficult and so far not productive. >>> >>> If folks want to give OpenSSL money, mail a check or cash. >> I was thinking of the more simple solution of setting up >> the account in the same non-US bank where the team member >> does his other business. Lots of this tends to get easier >> when the person is an existing customer and the bank is >> nearby. >> >> Each non-US team member presumably has at least one existing >> bank relationship and presumably knowledge and/or easy access >> to information on how to set up an independent legal entity >> in his/her own country. > Personal bank accounts, yes. But, we don't want to entangle OpenSSL > funds with any team members personal finances. Those funds need to be > held by an independent OpenSSL legal entity (of which there are already > several). Also keep in mind that most of my colleagues are hardcore > geeks best suited to wrangling OpenSSL code. I try to handle as many > paperwork hassles as possible to free them for that more important activity. I was trying to say that retail banks can be very helpful when an existing personal account holder wants to set up a business account with themselves as a signatory (but not owner). Especially if the legal entity (new or existing) is also within their jurisdiction. Things like checking if the person is who his says he is, checking if the initial deposit is from a suspect source etc. become much simpler when the bank recognizes the person as someone they have worked with for years and the initial money source as an account that was the correspondent with past checks or other traceable transfers to/from that known person (all according to the banks own records). Throw in the prospect of earning transaction fees on an associated Merchant account, and motivation can grow further. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From bgiles at coyotesong.com Fri May 6 14:44:31 2016 From: bgiles at coyotesong.com (Bear Giles) Date: Fri, 6 May 2016 08:44:31 -0600 Subject: [openssl-users] good riddance to PayPal In-Reply-To: References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <572C73A4.8090603@opensslfoundation.org> <49b20b9e-a029-2ba3-bbaa-399a36204eb3@wisemo.com> <572C9B72.1010503@opensslfoundation.org> Message-ID: Is it possible to set up two accounts, one US and one non-US, and then just transfer funds between them? It would be more work than setting up a single account but would eliminate a single point of failure risk. Bear On Fri, May 6, 2016 at 8:29 AM, Jakob Bohm wrote: > On 06/05/2016 15:26, Steve Marquess wrote: > >> On 05/06/2016 09:14 AM, Jakob Bohm wrote: >> >>> On 06/05/2016 13:45, Salz, Rich wrote: >>> >>>> Consider having the non-U.S. person do the account setup too. >>>>> >>>>> Banks are as scared of US jurisdiction as crypto engineers. >>>>> >>>> Yeah, we've done that. Even to the point where one of the team was >>>> going to get on a plane to fly to the Isle of Mann. >>>> >>>> It's amazingly painful and difficult and so far not productive. >>>> >>>> If folks want to give OpenSSL money, mail a check or cash. >>>> >>> I was thinking of the more simple solution of setting up >>> the account in the same non-US bank where the team member >>> does his other business. Lots of this tends to get easier >>> when the person is an existing customer and the bank is >>> nearby. >>> >>> Each non-US team member presumably has at least one existing >>> bank relationship and presumably knowledge and/or easy access >>> to information on how to set up an independent legal entity >>> in his/her own country. >>> >> Personal bank accounts, yes. But, we don't want to entangle OpenSSL >> funds with any team members personal finances. Those funds need to be >> held by an independent OpenSSL legal entity (of which there are already >> several). Also keep in mind that most of my colleagues are hardcore >> geeks best suited to wrangling OpenSSL code. I try to handle as many >> paperwork hassles as possible to free them for that more important >> activity. >> > I was trying to say that retail banks can be very helpful > when an existing personal account holder wants to set up a > business account with themselves as a signatory (but not > owner). Especially if the legal entity (new or existing) > is also within their jurisdiction. > > Things like checking if the person is who his says he is, > checking if the initial deposit is from a suspect source > etc. become much simpler when the bank recognizes the > person as someone they have worked with for years and the > initial money source as an account that was the > correspondent with past checks or other traceable > transfers to/from that known person (all according to the > banks own records). > > Throw in the prospect of earning transaction fees on an > associated Merchant account, and motivation can grow > further. > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Fri May 6 15:06:28 2016 From: marquess at openssl.com (Steve Marquess) Date: Fri, 6 May 2016 11:06:28 -0400 Subject: [openssl-users] good riddance to PayPal In-Reply-To: References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> <572C73A4.8090603@opensslfoundation.org> <49b20b9e-a029-2ba3-bbaa-399a36204eb3@wisemo.com> <572C9B72.1010503@opensslfoundation.org> Message-ID: <572CB2F4.5020307@openssl.com> On 05/06/2016 10:29 AM, Jakob Bohm wrote: > On 06/05/2016 15:26, Steve Marquess wrote: >> On 05/06/2016 09:14 AM, Jakob Bohm wrote: >>> On 06/05/2016 13:45, Salz, Rich wrote: >>>>> Consider having the non-U.S. person do the account setup too. >>>>> >>>>> Banks are as scared of US jurisdiction as crypto engineers. >>>> Yeah, we've done that. Even to the point where one of the team was >>>> going to get on a plane to fly to the Isle of Mann. >>>> >>>> It's amazingly painful and difficult and so far not productive. >>>> >>>> If folks want to give OpenSSL money, mail a check or cash. >>> I was thinking of the more simple solution of setting up >>> the account in the same non-US bank where the team member >>> does his other business. Lots of this tends to get easier >>> when the person is an existing customer and the bank is >>> nearby. >>> >>> Each non-US team member presumably has at least one existing >>> bank relationship and presumably knowledge and/or easy access >>> to information on how to set up an independent legal entity >>> in his/her own country. >> Personal bank accounts, yes. But, we don't want to entangle OpenSSL >> funds with any team members personal finances. Those funds need to be >> held by an independent OpenSSL legal entity (of which there are already >> several). Also keep in mind that most of my colleagues are hardcore >> geeks best suited to wrangling OpenSSL code. I try to handle as many >> paperwork hassles as possible to free them for that more important >> activity. > I was trying to say that retail banks can be very helpful > when an existing personal account holder wants to set up a > business account with themselves as a signatory (but not > owner). Especially if the legal entity (new or existing) > is also within their jurisdiction. > > Things like checking if the person is who his says he is, > checking if the initial deposit is from a suspect source > etc. become much simpler when the bank recognizes the > person as someone they have worked with for years and the > initial money source as an account that was the > correspondent with past checks or other traceable > transfers to/from that known person (all according to the > banks own records). That is definitely true, which is how I was able to get our local U.S. bank here to allow signature access to our accounts by non-U.S. colleagues. It's important that our OpenSSL funding not be accessible by only one person, as that person could be run over by a beer truck. Unfortunately a U.S. bank is less than ideal for a non-U.S. centric organization with funding largely originating from, and spent, outside the U.S. We have been less successful in finding a non-U.S. bank willing to have us as a customer, and not for lack of trying. If you know of a *specific* bank that would help us please name it (offline if need be). If we haven't already tried them we will. > Throw in the prospect of earning transaction fees on an > associated Merchant account, and motivation can grow > further. The U.S. payment processors I've talked to don't like the fact that our web servers are all located outside the U.S. Based on an offline tip from another user I've spent a good part of this morning on the phone with a global payments provider; we're at the familiar "uh, we'll have to run this by underwriting" stage. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From marquess at openssl.com Fri May 6 15:13:41 2016 From: marquess at openssl.com (Steve Marquess) Date: Fri, 6 May 2016 11:13:41 -0400 Subject: [openssl-users] good riddance to PayPal In-Reply-To: References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <572C73A4.8090603@opensslfoundation.org> <49b20b9e-a029-2ba3-bbaa-399a36204eb3@wisemo.com> <572C9B72.1010503@opensslfoundation.org> Message-ID: <572CB4A5.8050802@openssl.com> On 05/06/2016 10:44 AM, Bear Giles wrote: > Is it possible to set up two accounts, one US and one non-US, and then > just transfer funds between them? It would be more work than setting up > a single account but would eliminate a single point of failure risk. Our U.S. bank has been great to work with, and we'll probably keep some limited funding with them indefinitely. One drawback of that bank is that they are unable to accept inbound Swift transactions. It's the non-U.S. bank account that has been the challenge. It took me awhile to figure out that FATCA was a fatal impediment to having any involvement by U.S. citizens (e.g. me), but that's not essential. We've switched our strategy to having no "U.S. person" involvement in our non-U.S. corporate entities, but still haven't been able to find a bank that will have us as a customer. Given our difficulties to date, and the experience with apparently successfully opening an account only to have that bank abruptly close it a week later, I definitely would like to have more than one non-U.S. account. At present the OpenSSL entities have multiple U.S. bank accounts; managing multiple existing accounts isn't the problem. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From kgoldman at us.ibm.com Fri May 6 21:41:01 2016 From: kgoldman at us.ibm.com (Ken Goldman) Date: Fri, 6 May 2016 17:41:01 -0400 Subject: [openssl-users] We're working on license changes In-Reply-To: <70db214b09054cf1897cacf512a5f54d@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <70db214b09054cf1897cacf512a5f54d@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: Is there any status update on this? On 7/31/2015 10:37 AM, Salz, Rich wrote: > Please see https://www.openssl.org/blog/blog/2015/08/01/cla/ for some > more details. > > Summary: Moving to Apache 2, CLA?s coming, it will take time. From rsalz at akamai.com Fri May 6 22:00:23 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 6 May 2016 22:00:23 +0000 Subject: [openssl-users] We're working on license changes In-Reply-To: References: <70db214b09054cf1897cacf512a5f54d@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <08dfdda4f27d42aa8e779c6e4cc95e92@usma1ex-dag1mb1.msg.corp.akamai.com> Nothing to say publically at this time. We are still working on things. It will take awhile. > Is there any status update on this? > > On 7/31/2015 10:37 AM, Salz, Rich wrote: > > Please see https://www.openssl.org/blog/blog/2015/08/01/cla/ for some > > more details. > > > > Summary: Moving to Apache 2, CLA?s coming, it will take time. From openSSL at MoreThan.org Fri May 6 12:33:28 2016 From: openSSL at MoreThan.org (Mike) Date: Fri, 6 May 2016 07:33:28 -0500 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <572C88D8.2090007@openssl.com> References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> <572C73A4.8090603@opensslfoundation.org> <572C88D8.2090007@openssl.com> Message-ID: <20160506073328.0266503f@core2quad.morethan.org> On Fri, 6 May 2016 08:06:48 -0400 Steve Marquess wrote: > On 05/06/2016 07:45 AM, Salz, Rich wrote: > >> Consider having the non-U.S. person do the account setup too. > >> > >> Banks are as scared of US jurisdiction as crypto engineers. > > > > Yeah, we've done that. Even to the point where one of the team was > > going to get on a plane to fly to the Isle of Mann. > > > > It's amazingly painful and difficult and so far not productive. > > > > ... > > FATCA means that no "U.S. person" can have any access to the bank > account; we are well and painfully aware of that, and it's not a > problem. Only three of us fall in that category anyway; OpenSSL is > not a U.S. centric organization. Our U.S. connections are only due to > the circumstantial fact that the OpenSSL team member (me) who > initially set up our banking arrangements happened to be American. > Lower left column: https://www.irs.gov/Businesses/Corporations/Foreign-Account-Tax-Compliance-Act-FATCA You just have to love that: ...in addition to FoBAR reporting. ;) = = = = = Seriously, As copyright owners you can rescind license permissions as you wish. Contact this person: https://www.irs.gov/uac/Commissioner-John-Koskinen and give them 30 days to purge any and all use of OpenSSL from the irs.gov network. A specific license withdrawal. You should at least be able to start a useful conversation that way. Mike > -Steve M. > From rsalz at akamai.com Sat May 7 00:40:35 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 7 May 2016 00:40:35 +0000 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <20160506073328.0266503f@core2quad.morethan.org> References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> <572C73A4.8090603@opensslfoundation.org> <572C88D8.2090007@openssl.com> <20160506073328.0266503f@core2quad.morethan.org> Message-ID: <55743cd43c5f444c9499fea72763d55a@usma1ex-dag1mb1.msg.corp.akamai.com> > Seriously, > As copyright owners you can rescind license permissions as you wish. > > Contact this person: > https://www.irs.gov/uac/Commissioner-John-Koskinen > and give them 30 days to purge any and all use of OpenSSL from the irs.gov > network. > A specific license withdrawal. > > You should at least be able to start a useful conversation that way. Sure, like "how about audits Mr {Salz,Marquess,Dukhovni}" -- some of us are US Citizens :) More importantly, it violates the spirit of OSS... From openssl.org at 18informatique.com Mon May 9 07:16:07 2016 From: openssl.org at 18informatique.com (mlrx) Date: Mon, 9 May 2016 09:16:07 +0200 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <572CB2F4.5020307@openssl.com> References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> <572C73A4.8090603@opensslfoundation.org> <49b20b9e-a029-2ba3-bbaa-399a36204eb3@wisemo.com> <572C9B72.1010503@opensslfoundation.org> <572CB2F4.5020307@openssl.com> Message-ID: <57303937.80508@18informatique.com> Le 06/05/2016 17:06, Steve Marquess a ?crit : > [...] > > That is definitely true, which is how I was able to get our local U.S. > bank here to allow signature access to our accounts by non-U.S. > colleagues. It's important that our OpenSSL funding not be accessible by > only one person, as that person could be run over by a beer truck. > > Unfortunately a U.S. bank is less than ideal for a non-U.S. centric > organization with funding largely originating from, and spent, outside > the U.S. > > We have been less successful in finding a non-U.S. bank willing to have > us as a customer, and not for lack of trying. If you know of a > *specific* bank that would help us please name it (offline if need be). > If we haven't already tried them we will. > >> Throw in the prospect of earning transaction fees on an >> associated Merchant account, and motivation can grow >> further. > > The U.S. payment processors I've talked to don't like the fact that our > web servers are all located outside the U.S. Based on an offline tip > from another user I've spent a good part of this morning on the phone > with a global payments provider; we're at the familiar "uh, we'll have > to run this by underwriting" stage. > > -Steve M. Hello, Maybe the french ethical and cooperative bank "LA NEF" ? Their views must be reconciled with the "free world." Their status has recently changed to become a full-power rights bank; their range of service is not yet complete but they are working hard to make them born. best regards, -- benoist -- benoist From noloader at gmail.com Mon May 9 08:36:45 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 9 May 2016 04:36:45 -0400 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <572BAFDC.2090009@opensslfoundation.org> References: <572BAFDC.2090009@opensslfoundation.org> Message-ID: On Thu, May 5, 2016 at 4:41 PM, Steve Marquess wrote: > We've had a PayPal account for years, as the most convenient way for > individuals to send small donations. However, as the person who has > managed that account I can attest that PayPal has always been rather > annoying to deal with, and I've finally hit my limit. PayPal is renowned for poor customer service; confer, http://www.google.com/search?q=paypal+sucks. Get some bumper stickers and pins made up with the OpenSSL logo. Sell them on Amazon and eBay for the value of a donation - $10, $25, etc. Based on some estimates, Amazon and eBay will provide the Foundation's presence at online retail stores that handle 75% of online spending (c., http://www.marketwatch.com/story/amazon-will-account-for-more-than-half-of-2015-e-commerce-growth-says-macquarie-2015-12-22). Jeff From matt at openssl.org Mon May 9 08:49:35 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 9 May 2016 09:49:35 +0100 Subject: [openssl-users] [PATCH] dtls: reduce initial timeout value to 500ms In-Reply-To: <572C9F0E.9020406@db.org> References: <572C9F0E.9020406@db.org> Message-ID: <57304F1F.5080408@openssl.org> On 06/05/16 14:41, Alfred E. Heggestad wrote: > Hi, > > > we are using OpenSSL in our product, mainly the DTLS-SRTP part to > exchange keys for SRTP using DTLS. Our network environment is rather > hostile, with highly variable bandwidth, some packet loss and some > connections with slightly high RTT. > > > the current DTLS stack in OpenSSL (v1.0.2) starts with a timeout > value of 1 second, which is doubled for every retransmit. For us this > is too high. I would like to reduce the initial value to around 500ms, > and preferably make it run-time configurable. > > > > the patch below is a working patch, attached for the purpose of > discussion. > So this patch just replaces one hard-coded value with another. The previous default (presumably) works for others (at least I don't recall this issue coming up before) - but isn't working for you. Wouldn't it be better to keep the default as it is, but provide a mechanism for changing it for those that want to? BTW, this discussion is probably better placed on openssl-dev as it is about development of OpenSSL itself. Matt > > > > From 70a72c5102bab63373169615d3b26ded8399f227 Mon Sep 17 00:00:00 2001 > From: "Alfred E. Heggestad" > Date: Fri, 6 May 2016 15:31:20 +0200 > Subject: [PATCH] dtls: reduce initial timeout from 1.0 to 0.5 seconds > > --- > ssl/d1_lib.c | 9 +++++++-- > ssl/d1_pkt.c | 2 +- > ssl/dtls1.h | 4 ++-- > 3 files changed, 10 insertions(+), 5 deletions(-) > > diff --git a/ssl/d1_lib.c b/ssl/d1_lib.c > index ee78921..027d893 100644 > --- a/ssl/d1_lib.c > +++ b/ssl/d1_lib.c > @@ -359,6 +359,8 @@ const SSL_CIPHER *dtls1_get_cipher(unsigned int u) > > void dtls1_start_timer(SSL *s) > { > + struct timeval diff; > + > #ifndef OPENSSL_NO_SCTP > /* Disable timer for SCTP */ > if (BIO_dgram_is_sctp(SSL_get_wbio(s))) { > @@ -369,14 +371,17 @@ void dtls1_start_timer(SSL *s) > > /* If timer is not set, initialize duration with 1 second */ > if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec > == 0) { > - s->d1->timeout_duration = 1; > + s->d1->timeout_duration = 0.5; > } > > /* Set timeout to current time */ > get_current_time(&(s->d1->next_timeout)); > > /* Add duration to current time */ > - s->d1->next_timeout.tv_sec += s->d1->timeout_duration; > + diff.tv_sec = 0; > + diff.tv_usec = 1000000*s->d1->timeout_duration; > + timeradd(&s->d1->next_timeout, &diff, &s->d1->next_timeout); > + > BIO_ctrl(SSL_get_rbio(s), BIO_CTRL_DGRAM_SET_NEXT_TIMEOUT, 0, > &(s->d1->next_timeout)); > } > diff --git a/ssl/d1_pkt.c b/ssl/d1_pkt.c > index fe30ec7..3330fd6 100644 > --- a/ssl/d1_pkt.c > +++ b/ssl/d1_pkt.c > @@ -1502,7 +1502,7 @@ int do_dtls1_write(SSL *s, int type, const > unsigned char *buf, > * will happen with non blocking IO > */ > if (s->s3->wbuf.left != 0) { > - OPENSSL_assert(0); /* XDTLS: want to see if we ever get > here */ > + /*OPENSSL_assert(0);*/ /* XDTLS: want to see if we ever > get here */ > return (ssl3_write_pending(s, type, buf, len)); > } > > diff --git a/ssl/dtls1.h b/ssl/dtls1.h > index 30bbcf2..077fee5 100644 > --- a/ssl/dtls1.h > +++ b/ssl/dtls1.h > @@ -225,8 +225,8 @@ typedef struct dtls1_state_st { > * Indicates when the last handshake msg or heartbeat sent will > timeout > */ > struct timeval next_timeout; > - /* Timeout duration */ > - unsigned short timeout_duration; > + /* Timeout duration in Seconds */ > + double timeout_duration; > /* > * storage for Alert/Handshake protocol data received but not yet > * processed by ssl3_read_bytes: From marquess at openssl.com Tue May 10 14:47:13 2016 From: marquess at openssl.com (Steve Marquess) Date: Tue, 10 May 2016 10:47:13 -0400 Subject: [openssl-users] Attack of the FIPS 140-2 Clones Message-ID: <5731F471.5030503@openssl.com> If you neither know nor care what FIPS 140-2 is, count yourself lucky and move on (even if you're a Star Wars fan; this isn't nearly as entertaining). The "Alternative Scenario 1A/1B" aka "clone" aka "rebrand" validations have been an endless source of confusion, even for the accredited test labs and the CMVP. The one bright spot is that these clone validations indirectly expand the number of formally tested platforms ("Operational Environments" in FIPS-speak) available to all OpenSSL FIPS Object Module users. I've added a new section, 2.10, to the OpenSSL FIPS User Guide that summarizes this set of platforms: https://www.openssl.org/docs/fips/UserGuide-2.0.pdf As of today there are nine such clone validations, in addition to the ancestral #1747 validation all are derived from. Collectively they cover 178 unique platforms which are listed in alphabetical order in table 2.10b. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From marquess at opensslfoundation.org Tue May 10 16:51:25 2016 From: marquess at opensslfoundation.org (Steve Marquess) Date: Tue, 10 May 2016 12:51:25 -0400 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <572BAFDC.2090009@opensslfoundation.org> References: <572BAFDC.2090009@opensslfoundation.org> Message-ID: <5732118D.8090104@opensslfoundation.org> On 05/05/2016 04:41 PM, Steve Marquess wrote: > We've had a PayPal account for years, as the most convenient way for > individuals to send small donations. However, as the person who has > managed that account I can attest that PayPal has always been rather > annoying to deal with, and I've finally hit my limit. I'm in the process > of closing that account (something PayPal makes unnecessarily difficult > and protracted). I was able to refund most of the recent donations that > we were unable to recover, leaving a balance of $259.45 that will either > be forfeited to PayPal or (hopefully) refunded by them back to the > original donors. > > The PayPal donate link ("button") on our web site has been removed. I've > asked PayPal to block any future inbound transactions while we fight > over the account closure, but can't be confident that was done. Please > do not donate via PayPal to any account claiming to represent us; such > donations won't go to us and may not ever be returned to you. > > This closure of the only convenient means of receiving small donations > does not mean that we do not value such donations. Those of you who have > donated via PayPal, many via recurring donations, have our gratitude and > thanks. I regret that there is no clear alternative to switch to instead > (suggestions welcome if there are options I'm unaware of). > > -Steve M. > After another half hour of "your call is important to us" recordings, I have apparently succeeded in closing our PayPal account. I was promised that the 29 donations totaling $258.48 that I was unable to either withdraw or refund will be refunded directly by PayPal. Thanks again to all the donors who have support OpenSSL, via PayPal or other means. I'm looking into alternatives for account free online payments, so far without success. -Steve M. -- Steve Marquess OpenSSL Software Foundation 20-22 Wenlock Road London N1 7GU United Kingdom +44 1785508015 +1 301 874 2571 direct marquess at opensslfoundation.org stevem at openssl.org From tshort at akamai.com Wed May 11 15:41:30 2016 From: tshort at akamai.com (Short, Todd) Date: Wed, 11 May 2016 15:41:30 +0000 Subject: [openssl-users] ssl connect failed In-Reply-To: References: Message-ID: <49FEB68D-889A-4840-9918-7036E3AD4D52@akamai.com> There are ALPN/NPN callbacks that need to be set. Documentation was added recently to 1.0.2: https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_alpn_select_cb.html -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Apr 20, 2016, at 5:53 AM, james sqawz > wrote: Hi all, I want to add two extension field in CLIENT HELLO request. Extension: next protocol negotiation Extension:application layer protocol negotiation For that purpose which API/function of openssl I will call? Thanks Pranab On Mon, Apr 18, 2016 at 6:16 PM, james sqawz > wrote: Hi all, Thanks for the providing the forum for discussion on TLS/OPENSSL related issue. I am very new to openssl. Currently I am trying to implement HTTP over TLS.(TLS Version 1.2) For that purpose I send connect request to the server,but connection is getting failed. Following fields are abscent in my ssl packet. Extension: server name present Extension:application layer protocol negotiation Apart from that I did not set path of Server Certificate. Shall these impact my connect request. Can somebody help. Thanks James -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvp at forthepolls.org Wed May 11 18:46:10 2016 From: jvp at forthepolls.org (=?UTF-8?Q?Johann_v._Preu=c3=9fen?=) Date: Wed, 11 May 2016 11:46:10 -0700 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <572CB2F4.5020307@openssl.com> References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> <572C73A4.8090603@opensslfoundation.org> <49b20b9e-a029-2ba3-bbaa-399a36204eb3@wisemo.com> <572C9B72.1010503@opensslfoundation.org> <572CB2F4.5020307@openssl.com> Message-ID: <57337DF2.407@forthepolls.org> Marquess: your treasury re-alignment might be simplified a bit if you look to an on-line-type bank such as Ally Bank. while they are not on the SWIFT network, they use Chase -- like many intermediate-sized banks -- and benefit from having the "wholesale" rate between themselves. this enables Ally to give you free in-coming SWIFT and free in-coming/out-going domestic US wire transfers. out-going SWIFT is only $10. out-going ACH is also free, but they do not provide an API for in-coming ACH so that would require a third-party processor to make that happen on a web-site or automated/directed basis. fortunately, such a processor is dwolla which has several API's in different codings and offers free in-/out-processing with clearance that usually happens no later than the second day after initiation. since ACH has a built-in deferred relay of the next business day after preliminary settlement, this speed is about as good as it gets. since using a dwolla API also lifts the PCI responsibility from openssl, you would receive all your US-based donations at no-cost, quickly, and without much regulatory worry. in fact, dwolla allows you to tie in more than a single bank account so that you can choose where to "sweep" accumulated funds according to momentary needs. dwolla also has a "white-label" API that totally obscures their role in the process. they do charge for this, but the fact that your org is so prominent in the net security field would no doubt favorably prompt them to throw this service in for free just so they could tout openssl as a client. i am also certain they would be more than happy to provide free app customization tailored to openssl's specific needs. if multi-currency is a concern, Citibank offers primary bank account and card services in NYC and London permitting a wide range of denominations (USD, GBP, EURO, et cetera) from which to base such transactions. also, NYC/London do not have to be the same denomination and enjoy free inter-account transfers. from my experience, Citi also runs currency translations with much narrower spreads than other large banks and third-party gateways. as might be expected for this mega bank, their basket of services over-flows and they are lower-cost than other major banks when the services are not free! you have mentioned server-siting and non-US personnel as control agents as somewhat problematic. i might suggest a simple and very low-cost means of obviating these concerns. if openssl were to incorporate as a type IRS Reg 501(c)(3) it would satisfy US Treasury Reg's and make life a lot easier. in California (one of the lowest-cost states) that would cost you $30 to incorporate, $20 to file the SI-100 info form, and $25 to register with the FTB. you would also have to register with the CA Attorney General, but that is free. thus, for a start-up fee of $75 and a bi-annual SI-100 fee of $20 you would be in business and could open any US-based bank account your heart desires and make possible using a bank such as Citibank with accounts both in NYC and London to meet your international banking needs. since the corporation is a domestic one, bank signature cards can be initiated for anyone no matter where they may be citizens/domiciled. server siting is no problem for ACH since the natural limitation of the sending/receiving accounts being US-based means where the servers might be is totally unimportant. at this time, i am not a client or agent of any of the firms herein mentioned and i do not look to receiving any remuneration resulting from any of my suggestions. -- Thank you, Johann v. Preu?en On 2016.May.06 08:06, Steve Marquess wrote: > On 05/06/2016 10:29 AM, Jakob Bohm wrote: >> On 06/05/2016 15:26, Steve Marquess wrote: >>> On 05/06/2016 09:14 AM, Jakob Bohm wrote: >>>> On 06/05/2016 13:45, Salz, Rich wrote: >>>>>> Consider having the non-U.S. person do the account setup too. >>>>>> >>>>>> Banks are as scared of US jurisdiction as crypto engineers. >>>>> Yeah, we've done that. Even to the point where one of the team was >>>>> going to get on a plane to fly to the Isle of Mann. >>>>> >>>>> It's amazingly painful and difficult and so far not productive. >>>>> >>>>> If folks want to give OpenSSL money, mail a check or cash. >>>> I was thinking of the more simple solution of setting up >>>> the account in the same non-US bank where the team member >>>> does his other business. Lots of this tends to get easier >>>> when the person is an existing customer and the bank is >>>> nearby. >>>> >>>> Each non-US team member presumably has at least one existing >>>> bank relationship and presumably knowledge and/or easy access >>>> to information on how to set up an independent legal entity >>>> in his/her own country. >>> Personal bank accounts, yes. But, we don't want to entangle OpenSSL >>> funds with any team members personal finances. Those funds need to be >>> held by an independent OpenSSL legal entity (of which there are already >>> several). Also keep in mind that most of my colleagues are hardcore >>> geeks best suited to wrangling OpenSSL code. I try to handle as many >>> paperwork hassles as possible to free them for that more important >>> activity. >> I was trying to say that retail banks can be very helpful >> when an existing personal account holder wants to set up a >> business account with themselves as a signatory (but not >> owner). Especially if the legal entity (new or existing) >> is also within their jurisdiction. >> >> Things like checking if the person is who his says he is, >> checking if the initial deposit is from a suspect source >> etc. become much simpler when the bank recognizes the >> person as someone they have worked with for years and the >> initial money source as an account that was the >> correspondent with past checks or other traceable >> transfers to/from that known person (all according to the >> banks own records). > That is definitely true, which is how I was able to get our local U.S. > bank here to allow signature access to our accounts by non-U.S. > colleagues. It's important that our OpenSSL funding not be accessible by > only one person, as that person could be run over by a beer truck. > > Unfortunately a U.S. bank is less than ideal for a non-U.S. centric > organization with funding largely originating from, and spent, outside > the U.S. > > We have been less successful in finding a non-U.S. bank willing to have > us as a customer, and not for lack of trying. If you know of a > *specific* bank that would help us please name it (offline if need be). > If we haven't already tried them we will. > >> Throw in the prospect of earning transaction fees on an >> associated Merchant account, and motivation can grow >> further. > The U.S. payment processors I've talked to don't like the fact that our > web servers are all located outside the U.S. Based on an offline tip > from another user I've spent a good part of this morning on the phone > with a global payments provider; we're at the familiar "uh, we'll have > to run this by underwriting" stage. > > -Steve M. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3825 bytes Desc: S/MIME Cryptographic Signature URL: From marquess at openssl.com Wed May 11 20:00:57 2016 From: marquess at openssl.com (Steve Marquess) Date: Wed, 11 May 2016 16:00:57 -0400 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <57337DF2.407@forthepolls.org> References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> <572C73A4.8090603@opensslfoundation.org> <49b20b9e-a029-2ba3-bbaa-399a36204eb3@wisemo.com> <572C9B72.1010503@opensslfoundation.org> <572CB2F4.5020307@openssl.com> <57337DF2.407@forthepolls.org> Message-ID: <57338F79.103@openssl.com> On 05/11/2016 02:46 PM, Johann v. Preu?en wrote: > Marquess: > > your treasury re-alignment might be simplified a bit if you look to an > on-line-type bank such as Ally Bank. ... It's a U.S. bank. We already have multiple U.S. bank accounts. > you have mentioned server-siting and non-US personnel as control agents > as somewhat problematic. i might suggest a simple and very low-cost > means of obviating these concerns. if openssl were to incorporate as a > type IRS Reg 501(c)(3) it would satisfy US Treasury Reg's and make life > a lot easier. ... Yes, it would indeed, and if I had a nickel for each time I've heard this suggestion I'd had enough beer I'd need never face sobriety again. We have pursued 501(c) with several attorneys, all of which have advised us that our chances of successfully obtaining 501(c)(3) or 501(c)(6) status are nil. Apparently the IRS does not look kindly on our type of open source project. That is one of the reasons we need to relocate outside of U.S. jurisdiction. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From jvp at forthepolls.org Wed May 11 20:56:14 2016 From: jvp at forthepolls.org (=?UTF-8?Q?Johann_v._Preu=c3=9fen?=) Date: Wed, 11 May 2016 13:56:14 -0700 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <57338F79.103@openssl.com> References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> <572C73A4.8090603@opensslfoundation.org> <49b20b9e-a029-2ba3-bbaa-399a36204eb3@wisemo.com> <572C9B72.1010503@opensslfoundation.org> <572CB2F4.5020307@openssl.com> <57337DF2.407@forthepolls.org> <57338F79.103@openssl.com> Message-ID: <57339C6E.10705@forthepolls.org> i am somewhat surprised your attorneys have not mentioned the most simplistic solution. if the sole purpose for incorporating is to implement banking, there is actually no need to register for an IRS letter. if you satisfy the state regulations and obtain an EIN you are fine. the IRS letter does give safe harbor to donors that the amounts given are federally deductible. of course, to your major donors who provide moneys under grants and/or contracts there is no practical tax-wise difference between "gift" and "business expense". if you would like the specifics re CA, here are the applicable links granting freedom from CA taxation and franchise fees and establishing subsequent Federal tax-filing status: *the state equivalent of IRC 501(c)(3):* https://www.ftb.ca.gov/businesses/Exempt_organizations/Types_of_Exemptions.shtml#d23701 *your qualifications under "Scientific" endeavors:* https://www.ftb.ca.gov/businesses/Exempt_organizations/Types_of_Exemptions.shtml#Scientific *your qualifications under "Educational" endeavors:* https://www.ftb.ca.gov/businesses/Exempt_organizations/Types_of_Exemptions.shtml#Educational_org all of that said, there are plenty of examples of open-source org's that are already IRS-recognized under IRC 501(c)(3) such as Software in the Public Interest, Apache, Eclipse Foundation, Open Source Initiative, Linux Foundation, Software Freedom Conservancy, and many more. i have noticed, though, what your attorneys have related to you in that the IRS has recently seemed to turn a blind eye to the "public benefit" clause when it comes to open-source software. this is a trend of just a couple of years and turns from the path they had followed for decades in granting acceptance. if someone took the time to copy/edit one of these org's by-laws and submitted to the IRS they would be hard-pressed to deny based on the facts and would have to reveal a decidedly philosophical reason which would be wide open to appeal. naturally, i have no idea if any of this extra effort would yield anything meaningful to openssl. certainly, qualifying for non-profit status in CA actually grants you what you really need and does not require any extra efforts. -- Thank you, Johann v. Preu?en On 2016.May.11 13:00, Steve Marquess wrote: > On 05/11/2016 02:46 PM, Johann v. Preu?en wrote: >> Marquess: >> >> your treasury re-alignment might be simplified a bit if you look to an >> on-line-type bank such as Ally Bank. ... > It's a U.S. bank. We already have multiple U.S. bank accounts. > >> you have mentioned server-siting and non-US personnel as control agents >> as somewhat problematic. i might suggest a simple and very low-cost >> means of obviating these concerns. if openssl were to incorporate as a >> type IRS Reg 501(c)(3) it would satisfy US Treasury Reg's and make life >> a lot easier. ... > Yes, it would indeed, and if I had a nickel for each time I've heard > this suggestion I'd had enough beer I'd need never face sobriety again. > > We have pursued 501(c) with several attorneys, all of which have advised > us that our chances of successfully obtaining 501(c)(3) or 501(c)(6) > status are nil. Apparently the IRS does not look kindly on our type of > open source project. > > That is one of the reasons we need to relocate outside of U.S. jurisdiction. > > -Steve M. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3825 bytes Desc: S/MIME Cryptographic Signature URL: From marquess at opensslfoundation.org Wed May 11 21:15:49 2016 From: marquess at opensslfoundation.org (Steve Marquess) Date: Wed, 11 May 2016 17:15:49 -0400 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <57339C6E.10705@forthepolls.org> References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> <572C73A4.8090603@opensslfoundation.org> <49b20b9e-a029-2ba3-bbaa-399a36204eb3@wisemo.com> <572C9B72.1010503@opensslfoundation.org> <572CB2F4.5020307@openssl.com> <57337DF2.407@forthepolls.org> <57338F79.103@openssl.com> <57339C6E.10705@forthepolls.org> Message-ID: <5733A105.6020000@opensslfoundation.org> On 05/11/2016 04:56 PM, Johann v. Preu?en wrote: > i am somewhat surprised your attorneys have not mentioned the most > simplistic solution. if the sole purpose for incorporating is to > implement banking, there is actually no need to register for an IRS > letter. if you satisfy the state regulations and obtain an EIN you are > fine. the IRS letter does give safe harbor to donors that the amounts > given are federally deductible. of course, to your major donors who > provide moneys under grants and/or contracts there is no practical > tax-wise difference between "gift" and "business expense". > > ... State taxation isn't a problem; OpenSSL Software Foundation is incorporated in Delaware which has no tax. U.S. tax deductibility is largely irrelevant to our donors, most of which are outside the U.S. > > all of that said, there are plenty of examples of open-source org's that > are already IRS-recognized under IRC 501(c)(3) such as Software in the > Public Interest, Apache, Eclipse Foundation, Open Source Initiative, > Linux Foundation, Software Freedom Conservancy, and many more. i have > noticed, though, what your attorneys have related to you in that the IRS > has recently seemed to turn a blind eye to the "public benefit" clause > when it comes to open-source software. this is a trend of just a couple Bingo. > of years and turns from the path they had followed for decades in > granting acceptance. if someone took the time to copy/edit one of these > org's by-laws and submitted to the IRS they would be hard-pressed to > deny based on the facts and would have to reveal a decidedly > philosophical reason which would be wide open to appeal. naturally, i > have no idea if any of this extra effort would yield anything meaningful > to openssl. ... Be my guest and go for it, but I do have a good idea if it would yield anything meaningful because I've been working this issue in detail for a couple of years now. Our attorneys (we've checked with several, and with ones experienced with 501(c)) don't see a viable path worth the substantial investment it would cost us. -Steve M. -- Steve Marquess OpenSSL Software Foundation 20-22 Wenlock Road London N1 7GU United Kingdom +44 1785508015 +1 301 874 2571 direct marquess at opensslfoundation.org stevem at openssl.org From jvp at forthepolls.org Wed May 11 22:04:35 2016 From: jvp at forthepolls.org (=?UTF-8?Q?Johann_v._Preu=c3=9fen?=) Date: Wed, 11 May 2016 15:04:35 -0700 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <5733A105.6020000@opensslfoundation.org> References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> <572C73A4.8090603@opensslfoundation.org> <49b20b9e-a029-2ba3-bbaa-399a36204eb3@wisemo.com> <572C9B72.1010503@opensslfoundation.org> <572CB2F4.5020307@openssl.com> <57337DF2.407@forthepolls.org> <57338F79.103@openssl.com> <57339C6E.10705@forthepolls.org> <5733A105.6020000@opensslfoundation.org> Message-ID: <5733AC73.9020907@forthepolls.org> i am sorry if i have wasted your time on non-profit formation and taxation issues when i put my CPA hat on. i originally meant to point out some banking alternatives and how to make certain you could qualify and control such with the non-profit formation as a means and California as a low-cost conduit. if you are already set up in DE, you can take advantage of the free in-/out-ACH, web API's, and mass-pay at dwolla (tied to any existing bank account(s) you have now or in the future) and internationally-scoped banking through Citi or some such. i suggested Ally Bank only because they offer free services: in-bound SWIFT, in-/out-bound domestic US wire transfers, and checking. also, their $10 fee for out-bound SWIFT is the lowest i know of for non-analysis (low running-balance) checking acct's. -- Thank you, Johann v. Preu?en On 2016.May.11 14:15, Steve Marquess wrote: > On 05/11/2016 04:56 PM, Johann v. Preu?en wrote: >> i am somewhat surprised your attorneys have not mentioned the most >> simplistic solution. if the sole purpose for incorporating is to >> implement banking, there is actually no need to register for an IRS >> letter. if you satisfy the state regulations and obtain an EIN you are >> fine. the IRS letter does give safe harbor to donors that the amounts >> given are federally deductible. of course, to your major donors who >> provide moneys under grants and/or contracts there is no practical >> tax-wise difference between "gift" and "business expense". >> >> ... > State taxation isn't a problem; OpenSSL Software Foundation is > incorporated in Delaware which has no tax. U.S. tax deductibility is > largely irrelevant to our donors, most of which are outside the U.S. > >> all of that said, there are plenty of examples of open-source org's that >> are already IRS-recognized under IRC 501(c)(3) such as Software in the >> Public Interest, Apache, Eclipse Foundation, Open Source Initiative, >> Linux Foundation, Software Freedom Conservancy, and many more. i have >> noticed, though, what your attorneys have related to you in that the IRS >> has recently seemed to turn a blind eye to the "public benefit" clause >> when it comes to open-source software. this is a trend of just a couple > Bingo. > >> of years and turns from the path they had followed for decades in >> granting acceptance. if someone took the time to copy/edit one of these >> org's by-laws and submitted to the IRS they would be hard-pressed to >> deny based on the facts and would have to reveal a decidedly >> philosophical reason which would be wide open to appeal. naturally, i >> have no idea if any of this extra effort would yield anything meaningful >> to openssl. ... > Be my guest and go for it, but I do have a good idea if it would yield > anything meaningful because I've been working this issue in detail for a > couple of years now. Our attorneys (we've checked with several, and with > ones experienced with 501(c)) don't see a viable path worth the > substantial investment it would cost us. > > -Steve M. > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3825 bytes Desc: S/MIME Cryptographic Signature URL: From marquess at opensslfoundation.org Thu May 12 13:39:28 2016 From: marquess at opensslfoundation.org (Steve Marquess) Date: Thu, 12 May 2016 09:39:28 -0400 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <5733AC73.9020907@forthepolls.org> References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> <572C73A4.8090603@opensslfoundation.org> <49b20b9e-a029-2ba3-bbaa-399a36204eb3@wisemo.com> <572C9B72.1010503@opensslfoundation.org> <572CB2F4.5020307@openssl.com> <57337DF2.407@forthepolls.org> <57338F79.103@openssl.com> <57339C6E.10705@forthepolls.org> <5733A105.6020000@opensslfoundation.org> <5733AC73.9020907@forthepolls.org> Message-ID: <57348790.9080903@opensslfoundation.org> On 05/11/2016 06:04 PM, Johann v. Preu?en wrote: > i am sorry if i have wasted your time on non-profit formation and > taxation issues when i put my CPA hat on. i originally meant to point > out some banking alternatives and how to make certain you could qualify > and control such with the non-profit formation as a means and California > as a low-cost conduit. Not a waste; despite working these issues for some time I remain ever hopeful that there is indeed a simple solution that has to date escaped us. Or even a complex one for that matter. I have also conflated other issues in what started out as an online payment thread :-) > > if you are already set up in DE, you can take advantage of the free > in-/out-ACH, web API's, and mass-pay at dwolla (tied to any existing > bank account(s) you have now or in the future) and > internationally-scoped banking through Citi or some such. i suggested > Ally Bank only because they offer free services: in-bound SWIFT, > in-/out-bound domestic US wire transfers, and checking. also, their $10 > fee for out-bound SWIFT is the lowest i know of for non-analysis (low > running-balance) checking acct's. Citibank and Ally are both U.S. banks, we already have multiple U.S. bank accounts. We don't do a lot of transactions (other than online donation payments) so the per-transaction fees are not a major consideration, nor are they onerous with our current U.S. bank. Dwolla I'll call when they open for business. I suspect we'll run into the U.S. web server location issue, but I'll check. -Steve M. -- Steve Marquess OpenSSL Software Foundation 20-22 Wenlock Road London N1 7GU United Kingdom +44 1785508015 +1 301 874 2571 direct marquess at opensslfoundation.org stevem at openssl.org From marquess at openssl.com Thu May 12 16:42:08 2016 From: marquess at openssl.com (Steve Marquess) Date: Thu, 12 May 2016 12:42:08 -0400 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <57348790.9080903@opensslfoundation.org> References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> <572C73A4.8090603@opensslfoundation.org> <49b20b9e-a029-2ba3-bbaa-399a36204eb3@wisemo.com> <572C9B72.1010503@opensslfoundation.org> <572CB2F4.5020307@openssl.com> <57337DF2.407@forthepolls.org> <57338F79.103@openssl.com> <57339C6E.10705@forthepolls.org> <5733A105.6020000@opensslfoundation.org> <5733AC73.9020907@forthepolls.org> <57348790.9080903@opensslfoundation.org> Message-ID: <5734B260.4010001@openssl.com> On 05/12/2016 09:39 AM, Steve Marquess wrote: > On 05/11/2016 06:04 PM, Johann v. Preu?en wrote: >> i am sorry if i have wasted your time on non-profit formation and >> taxation issues when i put my CPA hat on. i originally meant to point >> out some banking alternatives and how to make certain you could qualify >> and control such with the non-profit formation as a means and California >> as a low-cost conduit. > > Not a waste; despite working these issues for some time I remain ever > hopeful that there is indeed a simple solution that has to date escaped > us. Or even a complex one for that matter. > > ... > > Dwolla I'll call when they open for business. I suspect we'll run into > the U.S. web server location issue, but I'll check. > > -Steve M. > That was a short call; Dwolla only handles payments from within the U.S., and the great bulk of our donations come from outside the U.S. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From jvp at forthepolls.org Thu May 12 18:23:22 2016 From: jvp at forthepolls.org (=?UTF-8?Q?Johann_v._Preu=c3=9fen?=) Date: Thu, 12 May 2016 11:23:22 -0700 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <5734B260.4010001@openssl.com> References: <572BAFDC.2090009@opensslfoundation.org> <572BD062.6080805@openssl.org> <000901d1a772$f2f6b5a0$d8e420e0$@sales@free.fr> <572C73A4.8090603@opensslfoundation.org> <49b20b9e-a029-2ba3-bbaa-399a36204eb3@wisemo.com> <572C9B72.1010503@opensslfoundation.org> <572CB2F4.5020307@openssl.com> <57337DF2.407@forthepolls.org> <57338F79.103@openssl.com> <57339C6E.10705@forthepolls.org> <5733A105.6020000@opensslfoundation.org> <5733AC73.9020907@forthepolls.org> <57348790.9080903@opensslfoundation.org> <5734B260.4010001@openssl.com> Message-ID: <5734CA1A.6050209@forthepolls.org> dwolla: yes, i keyed off your comment re getting your last $'s from paypal and thought they would work for your donations: US, at least. and then somebody like Citi (a globally top-three credit card issuer) could handle accounts in GBP and EURO in London with a relatively small translation cost for Nordics and other Euro-peripherals into either London pool. the rest of the globe would probably be cheaper to come into NYC in USD. if you spend in GBP/EURO you would do so from those accounts with no translation costs. of course, you can concentrate the funds where ever you might need them as the need arises. OK, that type of a system takes a bit of effort to get going; but then it is quite low-cost and easy to actually run. *however, if you are looking for some sort of a paypal "drop-in" one that i am familiar with is propay.* * they have some concessionary pricing for non-profits (you can just provide proof of your "exempt" DE status). * i am not sure what their currency translation hits might be since i only know about a US set-up. * they do non-swipe cards at 2.2%+$0.25 (no surprise: except for Am Ex which you do not have to accept). * they do ACH, but have a percentage applied (less than 1%) instead of a much lower per-transaction fee. * transaction fees might get even lower if your volume is attractive to them. * no other fees at all. * they also have a bunch of API's you can choose from. * one added feature that may interest you is they have a means whereby you can post an anchor in social media sites to capture donations back to their system. * they also do the maximum PCI isolation so that you do not have to worry re that. * they have an "auto-sweep" function every couple of days for depositing into your current bank account which can be altered to your own preferred schedule. * you can establish multiple accounts if you have FX disbursement needs such as GBP and/or Euro and then there would be no attendant translation costs. of course, this is also a place where you can leverage your org's rep to possibly get even better terms. you could start at their non-profit page and look on from there and see if there are more features i do not know about: http://www.propay.com/affiliate/charity/?refid=charity -- Thank you, Johann v. Preu?en On 2016.May.12 09:42, Steve Marquess wrote: > On 05/12/2016 09:39 AM, Steve Marquess wrote: >> On 05/11/2016 06:04 PM, Johann v. Preu?en wrote: >>> i am sorry if i have wasted your time on non-profit formation and >>> taxation issues when i put my CPA hat on. i originally meant to point >>> out some banking alternatives and how to make certain you could qualify >>> and control such with the non-profit formation as a means and California >>> as a low-cost conduit. >> Not a waste; despite working these issues for some time I remain ever >> hopeful that there is indeed a simple solution that has to date escaped >> us. Or even a complex one for that matter. >> >> ... >> >> Dwolla I'll call when they open for business. I suspect we'll run into >> the U.S. web server location issue, but I'll check. >> >> -Steve M. >> > That was a short call; Dwolla only handles payments from within the > U.S., and the great bulk of our donations come from outside the U.S. > > -Steve M. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3825 bytes Desc: S/MIME Cryptographic Signature URL: From janjust at nikhef.nl Fri May 13 11:08:23 2016 From: janjust at nikhef.nl (Jan Just Keijser) Date: Fri, 13 May 2016 13:08:23 +0200 Subject: [openssl-users] s_client/s_server trouble Message-ID: <5735B5A7.8010709@nikhef.nl> hi all, I've just run into something weird with openssl 1.0.1 and s_client+s_server: - I've downloaded and compiled a static version of openssl 1.0.1t on Linux - I've set up a PKI with a ca.crt file and a server.crt/server.key keypair - next , I run ~/src/openssl-1.0.1t/apps/openssl s_server -CAfile ca.crt -cert server.crt -key server.key -dhparam dh2048.pem - then, with s_client ~/src/openssl-1.0.1t/apps/openssl s_client -CAfile ca.crt -connect 127.0.0.1:4433 and I always end up with Verify return code: 21 (unable to verify the first certificate) If I either change s_server *or* s_client to use openssl 0.9.8 then the above commands work! What am I missing here? TIA, JJK / Jan Just Keijser From master at 8bitrebellion.net Fri May 13 14:35:13 2016 From: master at 8bitrebellion.net (Tucker Moreau) Date: Fri, 13 May 2016 07:35:13 -0700 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <572BAFDC.2090009@opensslfoundation.org> References: <572BAFDC.2090009@opensslfoundation.org> Message-ID: Hey, Have you considered reaching out to a group like Software in the Public Interest and accepting donations through them? It's how Debian, Arch, and several others take donations exactly so they don't have to deal with the trouble of banks that you're going through now. Admittedly, it sounds somewhat worrying that OpenSSL itself wouldn't hold the funds directly this way, but I suppose it's better than having the funds indefinitely locked in PayPal or not being able to take donations at all. On Thu, May 5, 2016 at 1:41 PM, Steve Marquess wrote: > We've had a PayPal account for years, as the most convenient way for > individuals to send small donations. However, as the person who has > managed that account I can attest that PayPal has always been rather > annoying to deal with, and I've finally hit my limit. I'm in the process > of closing that account (something PayPal makes unnecessarily difficult > and protracted). I was able to refund most of the recent donations that > we were unable to recover, leaving a balance of $259.45 that will either > be forfeited to PayPal or (hopefully) refunded by them back to the > original donors. > > The PayPal donate link ("button") on our web site has been removed. I've > asked PayPal to block any future inbound transactions while we fight > over the account closure, but can't be confident that was done. Please > do not donate via PayPal to any account claiming to represent us; such > donations won't go to us and may not ever be returned to you. > > This closure of the only convenient means of receiving small donations > does not mean that we do not value such donations. Those of you who have > donated via PayPal, many via recurring donations, have our gratitude and > thanks. I regret that there is no clear alternative to switch to instead > (suggestions welcome if there are options I'm unaware of). > > -Steve M. > > -- > Steve Marquess > OpenSSL Software Foundation > 20-22 Wenlock Road > London N1 7GU > United Kingdom > +44 1785508015 > +1 301 874 2571 direct > marquess at opensslfoundation.org > stevem at openssl.org > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From marquess at opensslfoundation.org Fri May 13 14:56:07 2016 From: marquess at opensslfoundation.org (Steve Marquess) Date: Fri, 13 May 2016 10:56:07 -0400 Subject: [openssl-users] good riddance to PayPal In-Reply-To: References: <572BAFDC.2090009@opensslfoundation.org> Message-ID: <5735EB07.4090309@opensslfoundation.org> On 05/13/2016 10:35 AM, Tucker Moreau wrote: > Hey, > > Have you considered reaching out to a group like Software in the > Public Interest and accepting donations through them? It's how Debian, > Arch, and several others take donations exactly so they don't have to > deal with the trouble of banks that you're going through now. > Admittedly, it sounds somewhat worrying that OpenSSL itself wouldn't > hold the funds directly this way, but I suppose it's better than > having the funds indefinitely locked in PayPal or not being able to > take donations at all. We have considered this approach, in detail, and the comfort level isn't there. A requirement of their 501(c) status for such organizations is that they can't make any commitments as to how funds raised in our name will be spent. We would have to trust their good judgment in deciding how those funds were used. We found that such arrangements haven't always worked out as intended, and at any rate the OpenSSL team places a very high priority on maintaining independence from undue outside influence. If this outside charity were to accumulate a significant amount of funding then that would constitute undue influence. FWiW when this was discussed I made exactly that argument to my colleagues; that we'd be better off entrusting a third party with donations than losing them entirely. But, there was a strong consensus that clearly established independence trumped any hypothetical financial gain. We have turned down other donations-with-strings opportunities in the past for similar reasons. Also, while we value the individual donations received via PayPal, the bulk of our donation funding has been received via bank transfers (Swift/ACH), and that is unaffected by the closing of our PayPal account. -Steve M. -- Steve Marquess OpenSSL Software Foundation 20-22 Wenlock Road London N1 7GU United Kingdom +44 1785508015 +1 301 874 2571 direct marquess at opensslfoundation.org stevem at openssl.org From jonetsu at teksavvy.com Fri May 13 15:47:29 2016 From: jonetsu at teksavvy.com (jonetsu) Date: Fri, 13 May 2016 08:47:29 -0700 (MST) Subject: [openssl-users] FIPS 186-4 support ? Message-ID: <1463154449467-66153.post@n7.nabble.com> Hello, Is there anything new regarding the prime number requirement handling for FIPS 186-4, as far as supporting it ? I asked some time ago. Just want to see if anything has changed, if there's anything planned. - thanks ! -- View this message in context: http://openssl.6102.n7.nabble.com/FIPS-186-4-support-tp66153.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From sbrdbry at gmail.com Sat May 14 19:38:40 2016 From: sbrdbry at gmail.com (Stuart Bradbury) Date: Sat, 14 May 2016 20:38:40 +0100 Subject: [openssl-users] FIPS errors Message-ID: This is happening with all Linux distributions in OpenStack cloud instances where OpenStack has been installed via Packstack on Centos 7 in a VMware virtual machine. There don't seem to be any references to problems of this nature on the forums. $ sudo wget https://download.fedoraproject.org/pub/fedora/linux/releases/23/Cloud/x86_64/Images/Fedora-Cloud-Base-23-20151030.x86_64.qcow2 OpenSSL: error:2D06D075:FIPS routines:fips_pkey_signature_test:test failure OpenSSL: error:2D08E06B:FIPS routines:FIPS_CHECK_EC:pairwise test failed OpenSSL: error:1409802B:SSL routines:ssl3_send_client_key_exchange:reason(43) Unable to establish SSL connection. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wouter.verhelst at fedict.be Tue May 17 08:52:21 2016 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Tue, 17 May 2016 10:52:21 +0200 Subject: [openssl-users] good riddance to PayPal In-Reply-To: <5735EB07.4090309@opensslfoundation.org> References: <572BAFDC.2090009@opensslfoundation.org> <5735EB07.4090309@opensslfoundation.org> Message-ID: <573ADBC5.4060505@fedict.be> On 13-05-16 16:56, Steve Marquess wrote: > We have considered this approach, in detail, and the comfort level isn't > there. A requirement of their 501(c) status for such organizations is > that they can't make any commitments as to how funds raised in our name > will be spent. AIUI, the reason for that is solely that they cannot agree to make any payments that could be considered to be illegal. This is for obvious reasons; other than that, SPI does not set any rules on what member projects choose to do with their funds: "Member projects are free to use the funds allocated to them at their descretion, as long as such usage is consistent with U.S. laws and regulations, and within the constraints of SPI's certificate of incorporation and bylaws" (from http://spi-inc.org/donations/) The certificate of incorporation and bylaws do not seem to impose any further restrictions--but don't take my word for it (they're both available on their website). > We would have to trust their good judgment in deciding > how those funds were used. Actually, as a member project, you would gain the right to vote or stand for election in SPI's internal elections, and in doing so would be able to exert influence over SPI's decisions. -- Wouter Verhelst From Walter.H at mathemainzel.info Wed May 18 17:26:28 2016 From: Walter.H at mathemainzel.info (Walter H.) Date: Wed, 18 May 2016 19:26:28 +0200 Subject: [openssl-users] Certificate validating (openssl -verify ...) and interpreting messages Message-ID: <573CA5C4.5080809@mathemainzel.info> Hello, when running this: openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.trust.crt -trusted_first -untrusted /tmp/chain.pem /tmp/cert.pem /tmp/chain.pem contains a root certificate /tmp/cert.pem contains a certificate that was signed by this root certificate; I get the following output /tmp/cert.pem: CN = ..., O = ..., ST = ..., C = ... error 19 at 1 depth lookup:self signed certificate in certificate chain of couse the number 19 means 'self signed certificate in certificate chain' as shown here: https://www.openssl.org/docs/manmaster/apps/verify.html but what does the number 1 (at ... depth) say? does this reference a certificate of the whole chain, if so, which one the root or the other one? Thanks for help; Greetings from Austria, Walter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4312 bytes Desc: S/MIME Cryptographic Signature URL: From openssl at jordan.maileater.net Wed May 18 17:43:51 2016 From: openssl at jordan.maileater.net (Jordan Brown) Date: Wed, 18 May 2016 10:43:51 -0700 Subject: [openssl-users] Reload certificates? Message-ID: <4f52c5c5-8c6c-6a9e-eb7f-da63cb96cc7c@jordan.maileater.net> We have OpenSSL consumers (primarily but not exclusively OpenLDAP). Some of them are long-running processes. We'd like to be able to update the list of trusted certificates and have the changes take effect, without needing to restart those long-running processes and preferably without needing to interact with them in any way. It *looks* like the "file" style of certificate store is loaded once only, at the time it's specified, and never reloaded again for the life of a particular SSL context. Similarly, it looks like in the "directory" style of certificate store once a particular certificate has been loaded, it's never unloaded, even if the underlying file is deleted. It looks like the only way to see changes (and especially deletions) is to create a new SSL context. In addition to the difficulty of getting middleware to do that, it seems like the middleware would need to either watch the files and directories on its own, or always create new SSL contexts for new connections, or something else similarly intrusive. Is there something I'm missing? Would it be reasonable to have OpenSSL watch the metadata on the file or directory and, on change, discard cached certificates and, for a file, reload the file? -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed May 18 17:51:26 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 18 May 2016 17:51:26 +0000 Subject: [openssl-users] Reload certificates? In-Reply-To: <4f52c5c5-8c6c-6a9e-eb7f-da63cb96cc7c@jordan.maileater.net> References: <4f52c5c5-8c6c-6a9e-eb7f-da63cb96cc7c@jordan.maileater.net> Message-ID: > Is there something I'm missing? Nope. > Would it be reasonable to have OpenSSL watch the metadata on the file or directory and, on change, discard cached certificates and, for a file, reload the file? Unlikely to happen :) -- Jordan Brown, Oracle Solaris From scott_n at xypro.com Wed May 18 17:52:21 2016 From: scott_n at xypro.com (Scott Neugroschl) Date: Wed, 18 May 2016 17:52:21 +0000 Subject: [openssl-users] Reload certificates? In-Reply-To: <4f52c5c5-8c6c-6a9e-eb7f-da63cb96cc7c@jordan.maileater.net> References: <4f52c5c5-8c6c-6a9e-eb7f-da63cb96cc7c@jordan.maileater.net> Message-ID: I believe that's specific to the servers in question. Often you can "restart" a server by giving it a SIGHUP. I don't know if slapd and slurpd will respond in the way you want. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jordan Brown Sent: Wednesday, May 18, 2016 10:44 AM To: openssl-users at openssl.org Subject: [openssl-users] Reload certificates? We have OpenSSL consumers (primarily but not exclusively OpenLDAP). Some of them are long-running processes. We'd like to be able to update the list of trusted certificates and have the changes take effect, without needing to restart those long-running processes and preferably without needing to interact with them in any way. It *looks* like the "file" style of certificate store is loaded once only, at the time it's specified, and never reloaded again for the life of a particular SSL context. Similarly, it looks like in the "directory" style of certificate store once a particular certificate has been loaded, it's never unloaded, even if the underlying file is deleted. It looks like the only way to see changes (and especially deletions) is to create a new SSL context. In addition to the difficulty of getting middleware to do that, it seems like the middleware would need to either watch the files and directories on its own, or always create new SSL contexts for new connections, or something else similarly intrusive. Is there something I'm missing? Would it be reasonable to have OpenSSL watch the metadata on the file or directory and, on change, discard cached certificates and, for a file, reload the file? -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at jordan.maileater.net Wed May 18 17:58:10 2016 From: openssl at jordan.maileater.net (Jordan Brown) Date: Wed, 18 May 2016 10:58:10 -0700 Subject: [openssl-users] Reload certificates? In-Reply-To: References: <4f52c5c5-8c6c-6a9e-eb7f-da63cb96cc7c@jordan.maileater.net> Message-ID: <842eafd7-af4b-2aab-1348-259e14888f24@jordan.maileater.net> On 5/18/2016 10:52 AM, Scott Neugroschl wrote: > > I believe that?s specific to the servers in question. Often you can > ?restart? a server by giving it a SIGHUP. I don?t know if slapd and > slurpd will respond in the way you want. > I'm thinking more of long-running client applications. Because the various software stacks with OpenSSL at their base can be loaded into any number of client applications, it would be best if we didn't have to track down all of the consumers and notify them that they needed to recreate their SSL contexts. (Plus there's the difficulty of getting those various consumers, some of which may be externally-sourced software, to accept such a request.) > > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *Jordan Brown > *Sent:* Wednesday, May 18, 2016 10:44 AM > *To:* openssl-users at openssl.org > *Subject:* [openssl-users] Reload certificates? > > > > We have OpenSSL consumers (primarily but not exclusively OpenLDAP). > Some of them are long-running processes. > > We'd like to be able to update the list of trusted certificates and > have the changes take effect, without needing to restart those > long-running processes and preferably without needing to interact with > them in any way. > > It *looks* like the "file" style of certificate store is loaded once > only, at the time it's specified, and never reloaded again for the > life of a particular SSL context. Similarly, it looks like in the > "directory" style of certificate store once a particular certificate > has been loaded, it's never unloaded, even if the underlying file is > deleted. It looks like the only way to see changes (and especially > deletions) is to create a new SSL context. In addition to the > difficulty of getting middleware to do that, it seems like the > middleware would need to either watch the files and directories on its > own, or always create new SSL contexts for new connections, or > something else similarly intrusive. > > Is there something I'm missing? > > Would it be reasonable to have OpenSSL watch the metadata on the file > or directory and, on change, discard cached certificates and, for a > file, reload the file? > > -- > > Jordan Brown, Oracle Solaris > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at jordan.maileater.net Wed May 18 18:00:35 2016 From: openssl at jordan.maileater.net (Jordan Brown) Date: Wed, 18 May 2016 11:00:35 -0700 Subject: [openssl-users] Reload certificates? In-Reply-To: References: <4f52c5c5-8c6c-6a9e-eb7f-da63cb96cc7c@jordan.maileater.net> Message-ID: <0e6101f2-89aa-285d-6777-c5ad1f0947a2@jordan.maileater.net> On 5/18/2016 10:51 AM, Salz, Rich wrote: >> Would it be reasonable to have OpenSSL watch the metadata on the file or directory and, on change, discard cached certificates and, for a file, reload the file? > Unlikely to happen :) Are you saying that because nobody is interested in doing the development work, or because there's some reason why it would be a bad idea? -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From Richard.Koenning at ts.fujitsu.com Wed May 18 18:00:59 2016 From: Richard.Koenning at ts.fujitsu.com (=?ISO-8859-1?Q?Richard_K=F6nning?=) Date: Wed, 18 May 2016 20:00:59 +0200 Subject: [openssl-users] Reload certificates? In-Reply-To: References: <4f52c5c5-8c6c-6a9e-eb7f-da63cb96cc7c@jordan.maileater.net> Message-ID: <573CADDB.80800@ts.fujitsu.com> On 18.05.2016 19:51, Salz, Rich wrote: >> Is there something I'm missing? > Nope. From the description of SSL_CTX_load_verify_locations i would have expected that certificates loaded via the CApath mechanism are loaded anew for every verification process. If this is not the case an appropriate note in that description would be very nice. Ciao, Richard From jb-openssl at wisemo.com Wed May 18 18:25:20 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 18 May 2016 20:25:20 +0200 Subject: [openssl-users] Reload certificates? In-Reply-To: <0e6101f2-89aa-285d-6777-c5ad1f0947a2@jordan.maileater.net> References: <4f52c5c5-8c6c-6a9e-eb7f-da63cb96cc7c@jordan.maileater.net> <0e6101f2-89aa-285d-6777-c5ad1f0947a2@jordan.maileater.net> Message-ID: <59615e86-2738-ca6a-573e-775353ef3239@wisemo.com> On 18/05/2016 20:00, Jordan Brown wrote: > On 5/18/2016 10:51 AM, Salz, Rich wrote: >>> Would it be reasonable to have OpenSSL watch the metadata on the file or directory and, on change, discard cached certificates and, for a file, reload the file? >> Unlikely to happen :) > > Are you saying that because nobody is interested in doing the > development work, or because there's some reason why it would be a bad > idea? > I am guessing this is because watching for file system metadata changes is very OS specific and far outside the small subset of OS functionality already abstracted by the OS portability layers inside OpenSSL. Perhaps a simpler solution would be if certificates cached from the "CApath" mechanism would not be reused beyond a time limit of e.g. 12 hours. Similarly, for any self-loading mechanism, cached CRLs should be reloaded at the earlier of e.g. 12 hours and their "Not After" time. Of cause mechanisms that load all the data (CAs, CRLs etc.) at program startup cannot do reloads because that would fail when chroot or other security mechanisms disable the relevant access permission shortly after program startup (to prevent a security-compromised process from accessing / changing data it is not supposed to change during normal operations). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From openssl-users at dukhovni.org Wed May 18 19:10:16 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 18 May 2016 15:10:16 -0400 Subject: [openssl-users] Certificate validating (openssl -verify ...) and interpreting messages In-Reply-To: <573CA5C4.5080809@mathemainzel.info> References: <573CA5C4.5080809@mathemainzel.info> Message-ID: <57642D62-43F1-4182-8ABE-2CF9C6CCD2DE@dukhovni.org> > On May 18, 2016, at 1:26 PM, Walter H. wrote: > > openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.trust.crt -trusted_first -untrusted /tmp/chain.pem /tmp/cert.pem > > /tmp/chain.pem contains a root certificate > /tmp/cert.pem contains a certificate that was signed by this root certificate; > > I get the following output > > /tmp/cert.pem: CN = ..., O = ..., ST = ..., C = ... > error 19 at 1 depth lookup:self signed certificate in certificate chain > > of couse the number 19 means 'self signed certificate in certificate chain' > as shown here: https://www.openssl.org/docs/manmaster/apps/verify.html > > but what does the number 1 (at ... depth) say? It means that while constructing a chain, the immediate issue of the leaf certificate was an untrusted self-signed certificate. The leaf certificate has depth 1, its issuer has depth 0. -- Viktor. From Walter.H at mathemainzel.info Wed May 18 19:38:14 2016 From: Walter.H at mathemainzel.info (Walter H.) Date: Wed, 18 May 2016 21:38:14 +0200 Subject: [openssl-users] Certificate validating (openssl -verify ...) and interpreting messages In-Reply-To: <57642D62-43F1-4182-8ABE-2CF9C6CCD2DE@dukhovni.org> References: <573CA5C4.5080809@mathemainzel.info> <57642D62-43F1-4182-8ABE-2CF9C6CCD2DE@dukhovni.org> Message-ID: <573CC4A6.9030905@mathemainzel.info> On 18.05.2016 21:10, Viktor Dukhovni wrote: >> On May 18, 2016, at 1:26 PM, Walter H. wrote: >> >> openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.trust.crt -trusted_first -untrusted /tmp/chain.pem /tmp/cert.pem >> >> /tmp/chain.pem contains a root certificate >> /tmp/cert.pem contains a certificate that was signed by this root certificate; >> >> I get the following output >> >> /tmp/cert.pem: CN = ..., O = ..., ST = ..., C = ... >> error 19 at 1 depth lookup:self signed certificate in certificate chain >> >> of couse the number 19 means 'self signed certificate in certificate chain' >> as shown here: https://www.openssl.org/docs/manmaster/apps/verify.html >> >> but what does the number 1 (at ... depth) say? > It means that while constructing a chain, the immediate issue of the > leaf certificate was an untrusted self-signed certificate. The leaf > certificate has depth 1, its issuer has depth 0. > Ah, ok; in case there had been a chain with 3 certificates 2 means the leaf certificate, 1 means the issuing intermediate and 0 means the self signed root? Thanks, Walter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4312 bytes Desc: S/MIME Cryptographic Signature URL: From jb-openssl at wisemo.com Wed May 18 20:36:39 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 18 May 2016 22:36:39 +0200 Subject: [openssl-users] Certificate validating (openssl -verify ...) and interpreting messages In-Reply-To: <573CC4A6.9030905@mathemainzel.info> References: <573CA5C4.5080809@mathemainzel.info> <57642D62-43F1-4182-8ABE-2CF9C6CCD2DE@dukhovni.org> <573CC4A6.9030905@mathemainzel.info> Message-ID: <1431e1a6-5bde-d307-a786-cf5a1f3ce41a@wisemo.com> On 18/05/2016 21:38, Walter H. wrote: > On 18.05.2016 21:10, Viktor Dukhovni wrote: >>> On May 18, 2016, at 1:26 PM, Walter H. >>> wrote: >>> >>> openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.trust.crt >>> -trusted_first -untrusted /tmp/chain.pem /tmp/cert.pem >>> >>> /tmp/chain.pem contains a root certificate >>> /tmp/cert.pem contains a certificate that was signed by this root >>> certificate; >>> >>> I get the following output >>> >>> /tmp/cert.pem: CN = ..., O = ..., ST = ..., C = ... >>> error 19 at 1 depth lookup:self signed certificate in certificate chain >>> >>> of couse the number 19 means 'self signed certificate in certificate >>> chain' >>> as shown here: https://www.openssl.org/docs/manmaster/apps/verify.html >>> >>> but what does the number 1 (at ... depth) say? >> It means that while constructing a chain, the immediate issue of the >> leaf certificate was an untrusted self-signed certificate. The leaf >> certificate has depth 1, its issuer has depth 0. >> > Ah, ok; in case there had been a chain with 3 certificates > 2 means the leaf certificate, 1 means the issuing intermediate and 0 > means the self signed root? No, 0 is always the leaf, 1 is always the issuer of the leaf 2 is always the issuer of the issuer of the leaf etc. So for a chain with 3 certificates, 2 is the root. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From hokusai at gmx.ch Thu May 19 07:08:32 2016 From: hokusai at gmx.ch (hokusai at gmx.ch) Date: Thu, 19 May 2016 09:08:32 +0200 Subject: [openssl-users] Debug information in pdb file Message-ID: An HTML attachment was scrubbed... URL: From janjust at nikhef.nl Thu May 19 15:26:57 2016 From: janjust at nikhef.nl (Jan Just Keijser) Date: Thu, 19 May 2016 17:26:57 +0200 Subject: [openssl-users] s_client/s_server trouble In-Reply-To: <5735B5A7.8010709@nikhef.nl> References: <5735B5A7.8010709@nikhef.nl> Message-ID: <573DDB41.4000702@nikhef.nl> Hi all, no one has seen this as well? I've seen other mails fly by on openssl-users after I posted this, yet no response to my query, nor to a previous mail I sent (about pkcs7). Should I file bug reports instead? thx, JJK / Jan Just Keijser Jan Just Keijser wrote: > hi all, > > I've just run into something weird with openssl 1.0.1 and > s_client+s_server: > > - I've downloaded and compiled a static version of openssl 1.0.1t on > Linux > - I've set up a PKI with a ca.crt file and a server.crt/server.key > keypair > - next , I run > > ~/src/openssl-1.0.1t/apps/openssl s_server -CAfile ca.crt -cert > server.crt -key server.key -dhparam dh2048.pem > > - then, with s_client > > ~/src/openssl-1.0.1t/apps/openssl s_client -CAfile ca.crt -connect > 127.0.0.1:4433 > > and I always end up with > > Verify return code: 21 (unable to verify the first certificate) > > If I either change s_server *or* s_client to use openssl 0.9.8 then > the above commands work! > > What am I missing here? > > > TIA, > > JJK / Jan Just Keijser > From jb-openssl at wisemo.com Thu May 19 15:58:11 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 19 May 2016 17:58:11 +0200 Subject: [openssl-users] s_client/s_server trouble In-Reply-To: <573DDB41.4000702@nikhef.nl> References: <5735B5A7.8010709@nikhef.nl> <573DDB41.4000702@nikhef.nl> Message-ID: <1cbddaf0-82bd-cd1e-5e93-b8aeb65c5c43@wisemo.com> What kind (and size) of keys are in your certificates? That sounds like the most likely issue. On 19/05/2016 17:26, Jan Just Keijser wrote: > Hi all, > > no one has seen this as well? I've seen other mails fly by on > openssl-users after I posted this, yet no response to my query, nor to > a previous mail I sent (about pkcs7). Should I file bug reports instead? > > > Jan Just Keijser wrote: >> hi all, >> >> I've just run into something weird with openssl 1.0.1 and >> s_client+s_server: >> >> - I've downloaded and compiled a static version of openssl 1.0.1t on >> Linux >> - I've set up a PKI with a ca.crt file and a server.crt/server.key >> keypair >> - next , I run >> >> ~/src/openssl-1.0.1t/apps/openssl s_server -CAfile ca.crt -cert >> server.crt -key server.key -dhparam dh2048.pem >> >> - then, with s_client >> >> ~/src/openssl-1.0.1t/apps/openssl s_client -CAfile ca.crt -connect >> 127.0.0.1:4433 >> >> and I always end up with >> >> Verify return code: 21 (unable to verify the first certificate) >> >> If I either change s_server *or* s_client to use openssl 0.9.8 then >> the above commands work! >> >> What am I missing here? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From openssl-users at dukhovni.org Thu May 19 16:19:42 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 19 May 2016 16:19:42 +0000 Subject: [openssl-users] s_client/s_server trouble In-Reply-To: <1cbddaf0-82bd-cd1e-5e93-b8aeb65c5c43@wisemo.com> References: <5735B5A7.8010709@nikhef.nl> <573DDB41.4000702@nikhef.nl> <1cbddaf0-82bd-cd1e-5e93-b8aeb65c5c43@wisemo.com> Message-ID: <20160519161941.GZ3300@mournblade.imrryr.org> On Thu, May 19, 2016 at 05:58:11PM +0200, Jakob Bohm wrote: > What kind (and size) of keys are in your certificates? > > That sounds like the most likely issue. Perhaps that dhparam2049.pem does not actually contain a 2048-bit prime. I don't recall a floor on RSA key sizes in 1.0.1. The CHANGES file lists for 1.0.1q: *) Reject DH handshakes with parameters shorter than 1024 bits. [Kurt Roeckx] Otherwise, I don't see any enforcement of key size floors in 1.0.1. > > >- I've set up a PKI with a ca.crt file and a server.crt/server.key > > > keypair Not posting the certs makes it rather difficult to offer any help. > > >- next , I run > >> > >> ~/src/openssl-1.0.1t/apps/openssl s_server -CAfile ca.crt -cert > >>server.crt -key server.key -dhparam dh2048.pem I don't see a "-accept 4433" in that command. > >>- then, with s_client > >> > >> ~/src/openssl-1.0.1t/apps/openssl s_client -CAfile ca.crt -connect > >>127.0.0.1:4433 What's listening on "4433"? > >>and I always end up with > >> > >> Verify return code: 21 (unable to verify the first certificate) > >> > >>If I either change s_server *or* s_client to use openssl 0.9.8 then the > >>above commands work! With 0.9.8 s_client or s_server will be able to use the default CApath that is probably hashed with the 0.9.8-compatible hash algorithm, allowing either or both to construct a more complete chain, Likely the "ca.crt" you're using is not the (immediate?) issuer of the server certificate. -- Viktor. From jb-openssl at wisemo.com Thu May 19 16:31:54 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 19 May 2016 18:31:54 +0200 Subject: [openssl-users] s_client/s_server trouble In-Reply-To: <20160519161941.GZ3300@mournblade.imrryr.org> References: <5735B5A7.8010709@nikhef.nl> <573DDB41.4000702@nikhef.nl> <1cbddaf0-82bd-cd1e-5e93-b8aeb65c5c43@wisemo.com> <20160519161941.GZ3300@mournblade.imrryr.org> Message-ID: On 19/05/2016 18:19, Viktor Dukhovni wrote: > With 0.9.8 s_client or s_server will be able to use the default > CApath that is probably hashed with the 0.9.8-compatible hash > algorithm, allowing either or both to construct a more complete > chain, Indeed, I find it very confusing that specifying -CAfile or -CApath to the various "apps" doesn't override the default value of the other, causing various tests to trust additional certificates not intended to be trusted by that test. This hit me when I was trying to test yesterdays question about the numbering of certificate depths in error messages, as openssl verify kept accepting the test case despite using a CAfile without the relevant root. I had to pass in a dummy (empty) -CApath to get the expected results. Also, passing an empty file (such as /dev/null) for -CAfile causes an error, forcing the use of an irrelevant certificate file to trust an empty list of certificates. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From openssl-users at dukhovni.org Thu May 19 16:59:24 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 19 May 2016 16:59:24 +0000 Subject: [openssl-users] s_client/s_server trouble In-Reply-To: References: <5735B5A7.8010709@nikhef.nl> <573DDB41.4000702@nikhef.nl> <1cbddaf0-82bd-cd1e-5e93-b8aeb65c5c43@wisemo.com> <20160519161941.GZ3300@mournblade.imrryr.org> Message-ID: <20160519165924.GB3300@mournblade.imrryr.org> On Thu, May 19, 2016 at 06:31:54PM +0200, Jakob Bohm wrote: > >With 0.9.8 s_client or s_server will be able to use the default > >CApath that is probably hashed with the 0.9.8-compatible hash > >algorithm, allowing either or both to construct a more complete > >chain, > > Indeed, I find it very confusing that specifying -CAfile > or -CApath to the various "apps" doesn't override the > default value of the other, causing various tests to trust > additional certificates not intended to be trusted by that > test. Yes, this is why I suggested additional controls to disable the built-in paths in 1.1.0, which are now available: NAME s_client - SSL/TLS client program SYNOPSIS openssl s_client ... [-CApath directory] [-CAfile filename] [-no-CAfile] [-no-CApath] ... So for "total" control: openssl s_client -CAfile cafile.pem -no-CApath ... openssl s_server -CAfile cafile.pem -no-CApath ... There is perhaps an oversight in s_server, because the -no-CA{file,path} options don't seem to apply to the secondary context for SNI, which always gets the default paths: if ((!SSL_CTX_load_verify_locations(ctx2, CAfile, CApath)) || (!SSL_CTX_set_default_verify_paths(ctx2))) { ERR_print_errors(bio_err); } That's likely surprising, and probably should be fixed for the final release. -- Viktor. From Victor_Webber at DellTeam.com Thu May 19 21:02:52 2016 From: Victor_Webber at DellTeam.com (Victor_Webber at DellTeam.com) Date: Thu, 19 May 2016 21:02:52 +0000 Subject: [openssl-users] Async BIO Message-ID: <1463691772037.26475@DellTeam.com> Has anyone implemented the asynchronous version of the SSL_xxx(). It is nice to see that they appear to be supported, but I would like to know if anyone has actually implemented an application which uses the asynch version of the calls. I looked at the source, and there were a few niche areas where there were some shortcomings in handling a completely non-blocking implementation. vw -------------- next part -------------- An HTML attachment was scrubbed... URL: From aeh at db.org Fri May 20 07:55:35 2016 From: aeh at db.org (Alfred E. Heggestad) Date: Fri, 20 May 2016 09:55:35 +0200 Subject: [openssl-users] Async BIO In-Reply-To: <1463691772037.26475@DellTeam.com> References: <1463691772037.26475@DellTeam.com> Message-ID: <573EC2F7.20205@db.org> On 19/05/16 23:02, Victor_Webber at DellTeam.com wrote: > Has anyone implemented the asynchronous version of the SSL_xxx(). It is nice to see that they appear to be supported, but I would like to know if anyone has > actually implemented an application which uses the asynch version of the calls. > > > I looked at the source, and there were a few niche areas where there were some shortcomings in handling a completely non-blocking implementation. > Hi Victor, we have been using the async BIO interface of OpenSSL for a long time now, in the libre protocol stack project [1]. main usage of OpenSSL is TLS/DTLS for application level protocols such as SIP and HTTPS. it is important and to use the CRYPTO locking api if the application is multithreaded, and to clear the global error queue by calling ERR_clear_error() in case of ANY errors (otherwise the next function call might return that error and it becomes impossible to debug). after this was implemented properly, we have not have a single crash in many months. The applications using this code varies from embedded systems to large scale servers. /alfred [1] http://www.creytiv.com/re.html From janjust at nikhef.nl Sat May 21 19:01:12 2016 From: janjust at nikhef.nl (Jan Just Keijser) Date: Sat, 21 May 2016 21:01:12 +0200 Subject: [openssl-users] s_client/s_server trouble In-Reply-To: <20160519161941.GZ3300@mournblade.imrryr.org> References: <5735B5A7.8010709@nikhef.nl> <573DDB41.4000702@nikhef.nl> <1cbddaf0-82bd-cd1e-5e93-b8aeb65c5c43@wisemo.com> <20160519161941.GZ3300@mournblade.imrryr.org> Message-ID: Hi all, thanks for all the pointers - it was indeed a problem with the certificates. cheers, JJK / Jan Just Keijser On 19/05/16 18:19, Viktor Dukhovni wrote: > On Thu, May 19, 2016 at 05:58:11PM +0200, Jakob Bohm wrote: > >> What kind (and size) of keys are in your certificates? >> >> That sounds like the most likely issue. > Perhaps that dhparam2049.pem does not actually contain a 2048-bit > prime. I don't recall a floor on RSA key sizes in 1.0.1. > > The CHANGES file lists for 1.0.1q: > > *) Reject DH handshakes with parameters shorter than 1024 bits. > [Kurt Roeckx] > > Otherwise, I don't see any enforcement of key size floors in 1.0.1. > >>>> - I've set up a PKI with a ca.crt file and a server.crt/server.key >>>> keypair > Not posting the certs makes it rather difficult to offer any help. > >>>> - next , I run >>>> >>>> ~/src/openssl-1.0.1t/apps/openssl s_server -CAfile ca.crt -cert >>>> server.crt -key server.key -dhparam dh2048.pem > I don't see a "-accept 4433" in that command. > >>>> - then, with s_client >>>> >>>> ~/src/openssl-1.0.1t/apps/openssl s_client -CAfile ca.crt -connect >>>> 127.0.0.1:4433 > What's listening on "4433"? > >>>> and I always end up with >>>> >>>> Verify return code: 21 (unable to verify the first certificate) >>>> >>>> If I either change s_server *or* s_client to use openssl 0.9.8 then the >>>> above commands work! > With 0.9.8 s_client or s_server will be able to use the default > CApath that is probably hashed with the 0.9.8-compatible hash > algorithm, allowing either or both to construct a more complete > chain, > > Likely the "ca.crt" you're using is not the (immediate?) issuer > of the server certificate. > From mario.scalabrino at yahoo.it Mon May 23 10:25:33 2016 From: mario.scalabrino at yahoo.it (Mario Scalabrino) Date: Mon, 23 May 2016 12:25:33 +0200 Subject: [openssl-users] Help for Bug - time stamp routines:TS_CHECK_SIGNING_CERTS:ess signing, certificate error:ts_rsp_verify.c:291: Message-ID: <88cc5171-a11f-54a7-caf4-24deebce307e@yahoo.it> Dear openssl users, I'm struggling with the error below, I wrote to Openssl development in February 2016 but they are busy with the next release, I see they are aware of it in git/openssl and working on it. https://github.com/openssl/openssl/pull/771 The bug is in the command ts -verify |************** openssl ts -verify -digest e16db7d30581e44a5540f19553852b5a4e4e26f9adc365cc846f94038ee33025 \ -in /tmp/namirial.tsr -CAfile /tmp/NamirialCATSA.pem Verification: FAILED 140236013643424:error:2F067065:time stamp routines:TS_CHECK_SIGNING_CERTS:ess signing certificate error:ts_rsp_verify.c:291:| ***************** I need to verify programmatically that every timestamped document its' ok, it is very important for me to provide reliable timestamping from a trusted qualified European Union Timestamping Authority. From what I understood the bug relates to the fact that the new TSA's certificates are not compatible with the old way openssl reads them, or their attribute or hashing. My understanding of it is very basic. *Is there a patch that I can apply? *The bug has been found in 2013 http://openssl.6102.n7.nabble.com/possible-Bug-in-OpenSSL-rfc-3161-TSA-service-tt43128.html#none I also opened a thread here http://stackoverflow.com/questions/35914327/error-0x2f067065-in-ts-rsp-verify-c291/35916523?noredirect=1#comment62213243_35916523 It seems that it has been mentioned also here in git https://github.com/elabftw/elabftw/issues/242 https://github.com/openssl/openssl/pull/771 Here's my environment Ubuntu 14.04 LTS guest of a Virtualbox VM in an openstack IaaS. |OpenSSL 1.0.1f 6 Jan 2014 | |||Server Info: Apache/2.4.18 (Ubuntu) PHP Version: 5.5.34-1+deb.sury.org~trusty+1| mysql Ver 14.14 Distrib 5.5.49, for debian-linux-gnu (x86_64) using readline 6.3 Could you please help? Thank you in advance Cheers Msca -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon May 23 13:15:45 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 23 May 2016 13:15:45 +0000 Subject: [openssl-users] 1.1 release being delayed Message-ID: ... in case you haven't noticed :) Our announced release date for 1.1 has come and gone. We want to close many more bugs before we release it. In the meantime, please test against master or a daily snapshot or the last beta release. Thanks for your patience! -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From doctor at doctor.nl2k.ab.ca Mon May 23 15:43:41 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Mon, 23 May 2016 09:43:41 -0600 Subject: [openssl-users] 1.1 release being delayed In-Reply-To: References: Message-ID: <20160523154341.GB23295@doctor.nl2k.ab.ca> On Mon, May 23, 2016 at 01:15:45PM +0000, Salz, Rich wrote: > ... in case you haven't noticed :) Our announced release date for 1.1 has come and gone. > > We want to close many more bugs before we release it. In the meantime, please test against master or a daily snapshot or the last beta release. > > Thanks for your patience! > No problem and hopefully for app developers will come on board. > > -- > Senior Architect, Akamai Technologies > IM: richsalz at jabber.at Twitter: RichSalz > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Abuse a man unjustly, and you will make friends for him. -Edgar Watson Howe From mario.scalabrino at yahoo.it Mon May 23 20:32:46 2016 From: mario.scalabrino at yahoo.it (Mario Scalabrino) Date: Mon, 23 May 2016 22:32:46 +0200 Subject: [openssl-users] help with timestamping In-Reply-To: References: Message-ID: <8d6b5042-b328-c209-1070-0a02791c8615@yahoo.it> It seems that we have the same problem. I just opened a thread here https://mta.openssl.org/pipermail/openssl-users/2016-May/003733.html It seems that a group of experts found a workaround here. https://github.com/elabftw/elabftw/issues/242 Maybe you're expert enough to understand how to use their javaclient to make the verification, while we wait openssl to correct the bug. I cannot understand how to do it. I would appreciate, if you succeed, to explain me how to do it. From jeroen.ooms at stat.ucla.edu Mon May 23 22:06:55 2016 From: jeroen.ooms at stat.ucla.edu (Jeroen Ooms) Date: Tue, 24 May 2016 00:06:55 +0200 Subject: [openssl-users] EVP_PKEY_keygen fails on Travis with "invalid operation" Message-ID: I wrote some simple bindings to generate an ecdsa key: int nid = my_nist2nid(curve); EVP_PKEY_CTX *ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_EC, NULL); bail(EVP_PKEY_keygen_init(ctx) > 0); bail(EVP_PKEY_CTX_set_ec_paramgen_curve_nid(ctx, nid)); EVP_PKEY *pkey = NULL; bail(EVP_PKEY_keygen(ctx, &pkey) > 0); This works on all platforms that I tested, but on Travis CI the final call fails with error: In EVP_PKEY_CTX_ctrl: invalid operation I am using a standard Ubuntu 14.04 with libssl-dev. What might be the problem here? From gnfkdlqmfjscl at hotmail.com Tue May 24 07:21:24 2016 From: gnfkdlqmfjscl at hotmail.com (Kim kim) Date: Tue, 24 May 2016 07:21:24 +0000 Subject: [openssl-users] Is a certificate supposed to certify a device ... Message-ID: Hello, I am a non English native and just a newbie, the opposite of an IT expert, and am totally stuck on this. If any of you can kindly give any advice on my stupid or basic questions I would indeed greatly, greatly appreciate your help: Some while ago, for the first time in my life I (installed servers and) created certificates/keys, in order to use Openvpn on my stuffs. I successfully created those but then I felt I needed to figure out much more about other parts of server security, so I couldn't use those immediately but just leave those alone. What I've done was, - I wanted to use Openvpn on my work and all other stuffs (I'm not an expert; I just wanted to learn and do the basic things, if I can.). - After reading some documents I understood/thought I should have "server" in order to use Openvpn. (Until then, I only have Microsoft Windows (not server) and virtual machine guest Windows (not server) on it.) - So I installed some Linux "server(s)" as guest os(es), for the first time in my life. here what I actually did was: 1. installed A server, 2. following the instructions on the Openvpn website etc, completed the steps issuing cerficates (CA, server, client) using easy-rsa, 3. installed B server as another guest os, 2. completed the issueing certificates (CA, server, client) steps. - But I felt I should learn and configure the rest part of server security in order to actually start using the system(s), so I couldn't go further at that time; so I just quit going further and had to leave those alone, without doing anything on it. - disconnected the internet connections from those guest OSes. And then i've been worried about the certificates and keys that were properly issued at that time, I believe. I don't know what I have to be worried about actually and even if I really have to be worried about any things regarding it or not. At that time I created the certificates mainly for the use of all my basic(?)/initial(?) system, so the CAs, servers, and clients cerfiticates were only created and as far as I remember I didn't send these to others or share with any. But I'm worried as I hear server can be hacked very quickly after created... Haven't deleted/couldn't delete those two servers because I don't know if it will be needed, if the certificates and keys need to be revoked.... I wonder, do I have to revoke all the cerfiticates and keys, including CA itself? Do I revoke the CAs using the same CAs? (And actually I had a window os, not server, too before installing those two servers, in which I also issued some certs and keys to use Openvpn (until then I didn't think about the need of "server" for using Openvpn), but then I just completely deleted the window device itself without making any revocation or whatsoever.. so currently I don't even have that system... Can I still even revoke those certificates and keys issued on the deleted device? how?...) I now really need to proceed with my stuffs but I'm still stuck on it. I don't know what should I do to delete any risk/danger remaining, if any. Or can I simply delete these two servers) without revoking(?) any or whatsoever, without anything to worry about? Is a certificate supposed to certify a device (either CA, server or client)? So therefore don't I have to be even worried about the certs and keys if I no longer use the device itself (or if I delete the device itself)? What is the bottom line for compromised etc certificates/keys (maybe in security perspective or whatsoever...)? I look forward to hearing from you. Thank you very much for your time and your help indeed! Best regards, Kim -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandre.klein at tanukisoftware.com Tue May 24 09:05:34 2016 From: alexandre.klein at tanukisoftware.com (Alexandre Klein) Date: Tue, 24 May 2016 18:05:34 +0900 Subject: [openssl-users] make test failed on HPUX parisc Message-ID: Hi, I would like to build openssl 1.0.2h on my HPUX but it failed when running the tests (v3nametest). My machine: HPUX PARISC B11.11 B9007AA B.11.11.20 HP C/aC++ Developer's Bundle I'm using "hpux-parisc2-cc". I modified Configure to use +DAportable: "hpux-parisc2-cc","cc:+DAportable +O3 ... "hpux-parisc2-cc","cc:+DA2.0 +DS2.0 +O3 ... $ ./Configure hpux-parisc2-cc --prefix=path/to/folder no-shared no-zlib no-zlib-dynamic no-rc5 no-idea no-ec no-ecdh no-ecdsa no-asm no-mdc2 no-bf no-cast no-md2 no-rc4 no-jpake no-gmp $ make depend $ make $ make test Then it is failing when running: ../util/shlib_wrap.sh ./v3nametest set CN: host: [a] does not match [a] set CN: host-no-wildcards: [a] does not match [a] set CN: host: [b] does not match [b] set CN: host-no-wildcards: [b] does not match [b] ... set rfc822Name: email: [Postmaster at example.com] does not match [ Postmaster at example.com] set rfc822Name: email: [postmaster at EXAMPLE.COM] does not match [ postmaster at example.com] set rfc822Name: email: [postmaster at EXAMPLE.COM] does not match [ postmaster at EXAMPLE.COM] Makefile:347: recipe for target 'test_v3name' failed make[1]: Leaving directory '/home/alex/workspace/openssl/temp/test' Makefile:460: recipe for target 'tests' failed make[1]: *** [test_v3name] Error 1 make: *** [tests] Error 2 As far as I remember, it was no problem when building 1.0.1f on this machine. Is there something that I am missing? Please let me know if you would like to see the full log file (or some parts). Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue May 24 10:01:30 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 24 May 2016 12:01:30 +0200 Subject: [openssl-users] Is a certificate supposed to certify a device ... In-Reply-To: References: Message-ID: A certificate certifies whatever it says it certifies, nothing else. More precisely, an X.509 certificate of the kind used with OpenSSL, OpenVPN etc. certifies that: The secret private key that corresponds to the public key listed in the certificate is known only to something or someone for whom the combination of all the other things said in the certificate are true, and that whomever is listed in the certificate as the "Issuer" has verified that to be true. So for example, if your OpenVPN certificate says that "YourLinuxVM certifies that only YourLinuxVM has a copy of the private key for some public key, and that this key is intended for OpenVPN use between May 20th 2016 and May 20th 2017", that in itself is not much of a statement. A more important statement is the fact that you somehow installed a copy of that certificate at the other end of the VPN tunnel and told that end to trust that certificate as something relevant to the OpenVPN use. If you have reason to believe a private key may have been stolen/copied to a dangerous place, you should "revoke" the certificate that says knowledge of that private key means anything, then generate a new key plus certificate and install that. Replacing keys like that is pretty routine, just like changing passwords is routine, except that with keys and certificates, you don't have to think up a new password, because the computer does that for you. As for the risk of instant compromise of a new machine as it is being installed, there are two standard countermeasures: 1. Don't allow the Internet to contact that machine until it has been completely installed with all the security updates provided by whichever Linux distribution (branded collection of prebuilt software, such as Red Hat, Fedora, Ubuntu, Debian etc.) you are using. This should be done by not opening any real ports for that machine in your firewall/router except for whatever is needed by the install process itself. 2. Use a server operating system with a lot less security bugs than e.g. Windows Server 2003, depending on which Linux distribution and which version of that you used, you may already have done that. On 24/05/2016 09:21, Kim kim wrote: > > Hello, > > > I am a non English native and just a newbie, the opposite of an IT > expert, and am totally stuck on this. If any of you can kindly give > any advice on my stupid or basic questions I would indeed greatly, > greatly appreciate your help: > > > Some while ago, for the first time in my life I (installed servers > and) created certificates/keys, in order to use Openvpn on my stuffs. > I successfully created those but then I felt I needed to figure out > much more about other parts of server security, so I couldn't use > those immediately but just leave those alone. > > > What I've done was, > > - I wanted to use Openvpn on my work and all other stuffs (I'm not an > expert; I just wanted to learn and do the basic things, if I can.). > > - After reading some documents I understood/thought I should have > "server" in order to use Openvpn. (Until then, I only have Microsoft > Windows (not server) and virtual machine guest Windows (not server) on > it.) > > - So I installed some Linux "server(s)" as guest os(es), for the first > time in my life. > > here what I actually did was: 1. installed A server, 2. following > the instructions on the Openvpn website etc, completed the steps > issuing cerficates (CA, server, client) using easy-rsa, 3. installed B > server as another guest os, 2. completed the issueing certificates > (CA, server, client) steps. > > - But I felt I should learn and configure the rest part of server > security in order to actually start using the system(s), so I couldn't > go further at that time; so I just quit going further and had to leave > those alone, without doing anything on it. > > - disconnected the internet connections from those guest OSes. > > > And then i've been worried about the certificates and keys that were > properly issued at that time, I believe. I don't know what I have to > be worried about actually and even if I really have to be worried > about any things regarding it or not. > > At that time I created the certificates mainly for the use of all my > basic(?)/initial(?) system, so the CAs, servers, and clients > cerfiticates were only created and as far as I remember I didn't > send these to others or share with any. > > But I'm worried as I hear server can be hacked very quickly after > created... > > Haven't deleted/couldn't delete those two servers because I don't know > if it will be needed, if the certificates and keys need to be revoked.... > > > I wonder, do I have to revoke all the cerfiticates and keys, including > CA itself? Do I revoke the CAs using the same CAs? > > (And actually I had a window os, not server, too before installing > those two servers, in which I also issued some certs and keys to use > Openvpn (until then I didn't think about the need of "server" for > using Openvpn), but then I just completely deleted the window device > itself without making any revocation or whatsoever.. so currently I > don't even have that system... Can I still even revoke those > certificates and keys issued on the deleted device? how?...) > > > I now really need to proceed with my stuffs but I'm still stuck on it. > > I don't know what should I do to delete any risk/danger remaining, if > any. Or can I simply delete these two servers) without revoking(?) any > or whatsoever, without anything to worry about? > > Is a certificate supposed to certify a device (either CA, server or > client)? *So therefore don't I have to be even worried about the certs > and keys if I no longer use the device itself (or if I delete the > device itself)?* What is the bottom line for compromised etc > certificates/keys (maybe in security perspective or whatsoever...)? > > > I look forward to hearing from you. > > Thank you very much for your time and your help indeed! > > > Best regards, > Kim > > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From pbellino at mrv.com Tue May 24 11:56:20 2016 From: pbellino at mrv.com (Philip Bellino) Date: Tue, 24 May 2016 11:56:20 +0000 Subject: [openssl-users] Looking for the Changelog in openssl-fips-2.0.12 Message-ID: Hello, I am looking for the Changelog that explains the changes between openssl-fips-2.0.9 and 2.0.12. The README.FIPS that comes with 2.0.12 points here: https://www.openssl.org/docs/fips but I cannot find the changes. Any help would be most appreciated. Thanks, Phil [E-Banner] MRV Communications is a global supplier of packet and optical solutions that power the world's largest networks. Our products combine innovative hardware with intelligent software to make networks smarter, faster and more efficient. The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Tue May 24 13:15:10 2016 From: marquess at openssl.com (Steve Marquess) Date: Tue, 24 May 2016 09:15:10 -0400 Subject: [openssl-users] Looking for the Changelog in openssl-fips-2.0.12 In-Reply-To: References: Message-ID: <574453DE.6010902@openssl.com> On 05/24/2016 07:56 AM, Philip Bellino wrote: > Hello, > > I am looking for the Changelog that explains the changes between > openssl-fips-2.0.9 and 2.0.12. > > > > The README.FIPS that comes with 2.0.12 points here: > https://www.openssl.org/docs/fips but I cannot find the changes. > > > > Any help would be most appreciated. Look at the Security Policy document, "Modification History": http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2398.pdf Since in general we aren't allowed to add new functionality or even to fix security vulnerabilities for validated modules, the only reason to use a newer module revision (2.0.12) instead of an older one (2.0.9) is that the older one lacks support for your specific platform(s) of interest; there is no advantage in updating already fielded modules like you would for OpenSSL proper or other more conventionally maintained software. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From debbie10t at gmail.com Tue May 24 13:58:01 2016 From: debbie10t at gmail.com (debbie10t) Date: Tue, 24 May 2016 14:58:01 +0100 Subject: [openssl-users] Is a certificate supposed to certify a device ... In-Reply-To: References: Message-ID: <57445DE9.1050702@gmail.com> Hi Kim kim. you would get more appropriate advise for OpenVPN from: https://forums.openvpn.net/ Also see the OpenVPN HOWTO located there .. The manual page can also be very helpful: https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage The openvpn users mailing list is also a great source of help. Find the mailing lists at: https://openvpn.net/index.php/open-source/documentation/miscellaneous/61-mailing-lists.html With regard to your specific problem: If you have deleted your server side copies of the ca.key and ca.crt then all the associated server & client certificates/keys will be useless and can *never* be used by openvpn again. You would have to recreate a new PKI from scratch. Regards -- On 24/05/16 08:21, Kim kim wrote: > Hello, > > > I am a non English native and just a newbie, the opposite of an IT expert, and am totally stuck on this. If any of you can kindly give any advice on my stupid or basic questions I would indeed greatly, greatly appreciate your help: > > > Some while ago, for the first time in my life I (installed servers and) created certificates/keys, in order to use Openvpn on my stuffs. I successfully created those but then I felt I needed to figure out much more about other parts of server security, so I couldn't use those immediately but just leave those alone. > > > What I've done was, > > - I wanted to use Openvpn on my work and all other stuffs (I'm not an expert; I just wanted to learn and do the basic things, if I can.). > > - After reading some documents I understood/thought I should have "server" in order to use Openvpn. (Until then, I only have Microsoft Windows (not server) and virtual machine guest Windows (not server) on it.) > > - So I installed some Linux "server(s)" as guest os(es), for the first time in my life. > > here what I actually did was: 1. installed A server, 2. following the instructions on the Openvpn website etc, completed the steps issuing cerficates (CA, server, client) using easy-rsa, 3. installed B server as another guest os, 2. completed the issueing certificates (CA, server, client) steps. > > - But I felt I should learn and configure the rest part of server security in order to actually start using the system(s), so I couldn't go further at that time; so I just quit going further and had to leave those alone, without doing anything on it. > > - disconnected the internet connections from those guest OSes. > > > And then i've been worried about the certificates and keys that were properly issued at that time, I believe. I don't know what I have to be worried about actually and even if I really have to be worried about any things regarding it or not. > > At that time I created the certificates mainly for the use of all my basic(?)/initial(?) system, so the CAs, servers, and clients cerfiticates were only created and as far as I remember I didn't send these to others or share with any. > > But I'm worried as I hear server can be hacked very quickly after created... > > Haven't deleted/couldn't delete those two servers because I don't know if it will be needed, if the certificates and keys need to be revoked.... > > > I wonder, do I have to revoke all the cerfiticates and keys, including CA itself? Do I revoke the CAs using the same CAs? > > (And actually I had a window os, not server, too before installing those two servers, in which I also issued some certs and keys to use Openvpn (until then I didn't think about the need of "server" for using Openvpn), but then I just completely deleted the window device itself without making any revocation or whatsoever.. so currently I don't even have that system... Can I still even revoke those certificates and keys issued on the deleted device? how?...) > > > I now really need to proceed with my stuffs but I'm still stuck on it. > > I don't know what should I do to delete any risk/danger remaining, if any. Or can I simply delete these two servers) without revoking(?) any or whatsoever, without anything to worry about? > > Is a certificate supposed to certify a device (either CA, server or client)? So therefore don't I have to be even worried about the certs and keys if I no longer use the device itself (or if I delete the device itself)? What is the bottom line for compromised etc certificates/keys (maybe in security perspective or whatsoever...)? > > > I look forward to hearing from you. > > Thank you very much for your time and your help indeed! > > Best regards, > Kim > > From openssl-users at dukhovni.org Tue May 24 15:19:44 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 24 May 2016 15:19:44 +0000 Subject: [openssl-users] make test failed on HPUX parisc In-Reply-To: References: Message-ID: <20160524151944.GR3300@mournblade.imrryr.org> On Tue, May 24, 2016 at 06:05:34PM +0900, Alexandre Klein wrote: > > I'm using "hpux-parisc2-cc". I modified Configure to use +DAportable: > "hpux-parisc2-cc","cc:+DAportable +O3 ... > "hpux-parisc2-cc","cc:+DA2.0 +DS2.0 +O3 ... For meaningful help, post an unedited "diff" between the original and your version. The original Configure file has: "hpux-parisc2-cc","cc:+DA2.0 +DS2.0 +O3 +Optrs_strongly_typed -Ae +ESlit -DB_ENDIAN -DMD32_XARRAY -D_REENTRANT::::-Wl,+s -ldld:SIXTY_FOUR_BIT MD2_CHAR RC4_INDEX RC4_CHAR DES_UNROLL DES_RISC1 DES_INT:".eval{my $asm=$parisc20_asm;$asm=~s/2W\./2\./;$asm=~s/:64/:32/;$asm}.":dl:hpux-shared:+Z:-b:.sl.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::/pa20_32", "hpux64-parisc2-cc","cc:+DD64 +O3 +Optrs_strongly_typed -Ae +ESlit -DB_ENDIAN -DMD32_XARRAY -D_REENTRANT::::-ldl:SIXTY_FOUR_BIT_LONG MD2_CHAR RC4_INDEX RC4_CHAR DES_UNROLL DES_RISC1 DES_INT:${parisc20_asm}:dlfcn:hpux-shared:+Z:+DD64 -b:.sl.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::/pa20_64", > $ ./Configure hpux-parisc2-cc --prefix=path/to/folder no-shared no-zlib > no-zlib-dynamic no-rc5 no-idea no-ec no-ecdh no-ecdsa no-asm no-mdc2 no-bf > no-cast no-md2 no-rc4 no-jpake no-gmp In particular you sure you want "no-asm" and "no-shared"? Those targets seem to be designed for shared builds with asm. -- Viktor. From christian_adja at yahoo.it Tue May 24 15:43:36 2016 From: christian_adja at yahoo.it (Christian Adja) Date: Tue, 24 May 2016 15:43:36 +0000 (UTC) Subject: [openssl-users] I: Question on ccm mode in openssl In-Reply-To: <340429138.3195833.1464103289720.JavaMail.yahoo@mail.yahoo.com> References: <340429138.3195833.1464103289720.JavaMail.yahoo.ref@mail.yahoo.com> <340429138.3195833.1464103289720.JavaMail.yahoo@mail.yahoo.com> Message-ID: <932315475.3200019.1464104616091.JavaMail.yahoo@mail.yahoo.com> Il Marted? 24 Maggio 2016 17:21, Christian Adja ha scritto: Good morning, i'm a master student at telecom paristech, i France, i'm working on openssl to add ieee and etsi certs for client. I saw that the ccm mode is not implemented in current openssl 1.0.2g version. So i would know if there a way to add the ccm mode? Thanks. Best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From norm.green at gemtalksystems.com Tue May 24 16:57:30 2016 From: norm.green at gemtalksystems.com (Norm Green) Date: Tue, 24 May 2016 09:57:30 -0700 Subject: [openssl-users] Diffie-Hellman Questions Message-ID: <34db33c7-88e2-0bcd-92b5-114d01b0697c@gemtalksystems.com> I need some clarifications on the DH implementation in OpenSSL. Currently I'm using version 1.0.2h 1) The wiki says don't use ADH, presumably because ADH provides encryption but not authentication and is exposed to man in the middle attacks. Is that the only reason? 2) Are the same encryption keys used every time with ADH? 3) Is it possible to use ephemeral DH without using certificates? I was not able to get that to work. 4) What is the best practice for establishing an anonymous encrypted channel using OpenSSL? Norm Green From rsalz at akamai.com Tue May 24 17:08:38 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 24 May 2016 17:08:38 +0000 Subject: [openssl-users] Diffie-Hellman Questions In-Reply-To: <34db33c7-88e2-0bcd-92b5-114d01b0697c@gemtalksystems.com> References: <34db33c7-88e2-0bcd-92b5-114d01b0697c@gemtalksystems.com> Message-ID: <23544be40f4647c986ddd11e8df421f0@usma1ex-dag1mb1.msg.corp.akamai.com> > 1) The wiki says don't use ADH, presumably because ADH provides > encryption but not authentication and is exposed to man in the middle > attacks. Is that the only reason? Use ECDH, it's less expensive computationally. > 2) Are the same encryption keys used every time with ADH? Yes. That's the other BIG reason :) You really want ephemeral, and therefore ECDH > 3) Is it possible to use ephemeral DH without using certificates? I was not > able to get that to work. Yes. This is "null" auth. > 4) What is the best practice for establishing an anonymous encrypted > channel using OpenSSL? Postfix does this kind of thing, as does other SMTP software. Look around for 'opportunistic encryption' perhaps. From norm.green at gemtalksystems.com Tue May 24 17:33:42 2016 From: norm.green at gemtalksystems.com (Norm Green) Date: Tue, 24 May 2016 10:33:42 -0700 Subject: [openssl-users] Diffie-Hellman Questions In-Reply-To: <23544be40f4647c986ddd11e8df421f0@usma1ex-dag1mb1.msg.corp.akamai.com> References: <34db33c7-88e2-0bcd-92b5-114d01b0697c@gemtalksystems.com> <23544be40f4647c986ddd11e8df421f0@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <2529d2e4-b94c-e3a7-5df1-d61e00df46e2@gemtalksystems.com> Thanks Rich. More newbie questions. Looking at the available ciphers I see this: >./openssl ciphers -v 'ALL:aNULL' |grep ECDH |grep "Au=None" AECDH-AES256-SHA SSLv3 Kx=ECDH Au=None Enc=AES(256) Mac=SHA1 AECDH-AES128-SHA SSLv3 Kx=ECDH Au=None Enc=AES(128) Mac=SHA1 AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1 AECDH-DES-CBC3-SHA SSLv3 Kx=ECDH Au=None Enc=3DES(168) Mac=SHA1 AECDH-NULL-SHA SSLv3 Kx=ECDH Au=None Enc=None Mac=SHA1 1) What arg to SSL_CTX_set_cipher_list() to I need to use to get these? I previously tried "kEECDH:kEDH" and that didn't work. 2) These ciphers all report as SSLv3. Do I have to use SSLv3 client/server methods to get access to these ciphers? I was using TLS 1.2 (TLSv1_2_server_method()) methods. Norm Green On 5/24/16 10:08, Salz, Rich wrote: >> 1) The wiki says don't use ADH, presumably because ADH provides >> encryption but not authentication and is exposed to man in the middle >> attacks. Is that the only reason? > Use ECDH, it's less expensive computationally. > >> 2) Are the same encryption keys used every time with ADH? > Yes. That's the other BIG reason :) You really want ephemeral, and therefore ECDH > >> 3) Is it possible to use ephemeral DH without using certificates? I was not >> able to get that to work. > Yes. This is "null" auth. > >> 4) What is the best practice for establishing an anonymous encrypted >> channel using OpenSSL? > Postfix does this kind of thing, as does other SMTP software. Look around for 'opportunistic encryption' perhaps. From rsalz at akamai.com Tue May 24 17:45:56 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 24 May 2016 17:45:56 +0000 Subject: [openssl-users] Diffie-Hellman Questions In-Reply-To: <2529d2e4-b94c-e3a7-5df1-d61e00df46e2@gemtalksystems.com> References: <34db33c7-88e2-0bcd-92b5-114d01b0697c@gemtalksystems.com> <23544be40f4647c986ddd11e8df421f0@usma1ex-dag1mb1.msg.corp.akamai.com> <2529d2e4-b94c-e3a7-5df1-d61e00df46e2@gemtalksystems.com> Message-ID: <8c2b3842b28041b494be46e73e8f0a3f@usma1ex-dag1mb1.msg.corp.akamai.com> > >./openssl ciphers -v 'ALL:aNULL' |grep ECDH |grep "Au=None" > AECDH-AES256-SHA SSLv3 Kx=ECDH Au=None Enc=AES(256) Mac=SHA1 > AECDH-AES128-SHA SSLv3 Kx=ECDH Au=None Enc=AES(128) Mac=SHA1 > AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1 > AECDH-DES-CBC3-SHA SSLv3 Kx=ECDH Au=None Enc=3DES(168) > Mac=SHA1 > AECDH-NULL-SHA SSLv3 Kx=ECDH Au=None Enc=None Mac=SHA1 > > 1) What arg to SSL_CTX_set_cipher_list() to I need to use to get these? > I previously tried "kEECDH:kEDH" and that didn't work. Use one of the names in the first column. > 2) These ciphers all report as SSLv3. That is the protocol version where they were first defined. From 3vdsea+cmbrhsm95uy28 at sharklasers.com Tue May 24 17:52:58 2016 From: 3vdsea+cmbrhsm95uy28 at sharklasers.com (stas730) Date: Tue, 24 May 2016 10:52:58 -0700 (MST) Subject: [openssl-users] Certificate Transparency: OCSP response Message-ID: <1464112378889-66295.post@n7.nabble.com> I want to test all 3 types of CT. I know how to implement two: TLS extension & X.509 extension. But how to implement OCSP response? I can add response file, but how to change OID? -- View this message in context: http://openssl.6102.n7.nabble.com/Certificate-Transparency-OCSP-response-tp66295.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From norm.green at gemtalksystems.com Tue May 24 19:39:38 2016 From: norm.green at gemtalksystems.com (Norm Green) Date: Tue, 24 May 2016 12:39:38 -0700 Subject: [openssl-users] Diffie-Hellman Questions In-Reply-To: <8c2b3842b28041b494be46e73e8f0a3f@usma1ex-dag1mb1.msg.corp.akamai.com> References: <34db33c7-88e2-0bcd-92b5-114d01b0697c@gemtalksystems.com> <23544be40f4647c986ddd11e8df421f0@usma1ex-dag1mb1.msg.corp.akamai.com> <2529d2e4-b94c-e3a7-5df1-d61e00df46e2@gemtalksystems.com> <8c2b3842b28041b494be46e73e8f0a3f@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <2a79a371-ab8b-3dca-d96d-6849b40afbb0@gemtalksystems.com> I've tried both: SSL_CTX_set_cipher_list("AECDH") and: SSL_CTX_set_cipher_list("AECDH-AES256-SHA") on both the client and server side, both of which result in the dreaded "no shared cipher" error: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1417: The following works but is not what I want: SSL_CTX_set_cipher_list("ADH") Any suggestions on how to proceed? Norm Green On 5/24/16 10:45, Salz, Rich wrote: >> >./openssl ciphers -v 'ALL:aNULL' |grep ECDH |grep "Au=None" >> AECDH-AES256-SHA SSLv3 Kx=ECDH Au=None Enc=AES(256) Mac=SHA1 >> AECDH-AES128-SHA SSLv3 Kx=ECDH Au=None Enc=AES(128) Mac=SHA1 >> AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1 >> AECDH-DES-CBC3-SHA SSLv3 Kx=ECDH Au=None Enc=3DES(168) >> Mac=SHA1 >> AECDH-NULL-SHA SSLv3 Kx=ECDH Au=None Enc=None Mac=SHA1 >> >> 1) What arg to SSL_CTX_set_cipher_list() to I need to use to get these? >> I previously tried "kEECDH:kEDH" and that didn't work. > Use one of the names in the first column. > >> 2) These ciphers all report as SSLv3. > That is the protocol version where they were first defined. > > From rsalz at akamai.com Tue May 24 19:41:40 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 24 May 2016 19:41:40 +0000 Subject: [openssl-users] Diffie-Hellman Questions In-Reply-To: <2a79a371-ab8b-3dca-d96d-6849b40afbb0@gemtalksystems.com> References: <34db33c7-88e2-0bcd-92b5-114d01b0697c@gemtalksystems.com> <23544be40f4647c986ddd11e8df421f0@usma1ex-dag1mb1.msg.corp.akamai.com> <2529d2e4-b94c-e3a7-5df1-d61e00df46e2@gemtalksystems.com> <8c2b3842b28041b494be46e73e8f0a3f@usma1ex-dag1mb1.msg.corp.akamai.com> <2a79a371-ab8b-3dca-d96d-6849b40afbb0@gemtalksystems.com> Message-ID: <8afa6bfcd81d42b19830012907ff49d5@usma1ex-dag1mb1.msg.corp.akamai.com> > Any suggestions on how to proceed? Sorry, no. From Erwann.Abalea at docusign.com Tue May 24 19:54:46 2016 From: Erwann.Abalea at docusign.com (Erwann Abalea) Date: Tue, 24 May 2016 19:54:46 +0000 Subject: [openssl-users] (SPAM) I: Question on ccm mode in openssl In-Reply-To: <932315475.3200019.1464104616091.JavaMail.yahoo@mail.yahoo.com> References: <340429138.3195833.1464103289720.JavaMail.yahoo.ref@mail.yahoo.com> <340429138.3195833.1464103289720.JavaMail.yahoo@mail.yahoo.com> <932315475.3200019.1464104616091.JavaMail.yahoo@mail.yahoo.com> Message-ID: <115EE36A-95EA-4549-AB75-3E4331700A19@docusign.com> Bonjour, CCM mode is already implemented in OpenSSL. Cordialement, Erwann Abalea Le 24 mai 2016 ? 17:43, Christian Adja > a ?crit : Il Marted? 24 Maggio 2016 17:21, Christian Adja > ha scritto: Good morning, i'm a master student at telecom paristech, i France, i'm working on openssl to add ieee and etsi certs for client. I saw that the ccm mode is not implemented in current openssl 1.0.2g version. So i would know if there a way to add the ccm mode? Thanks. Best regards -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Tue May 24 22:52:26 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 24 May 2016 22:52:26 +0000 Subject: [openssl-users] Diffie-Hellman Questions In-Reply-To: <2a79a371-ab8b-3dca-d96d-6849b40afbb0@gemtalksystems.com> References: <34db33c7-88e2-0bcd-92b5-114d01b0697c@gemtalksystems.com> <23544be40f4647c986ddd11e8df421f0@usma1ex-dag1mb1.msg.corp.akamai.com> <2529d2e4-b94c-e3a7-5df1-d61e00df46e2@gemtalksystems.com> <8c2b3842b28041b494be46e73e8f0a3f@usma1ex-dag1mb1.msg.corp.akamai.com> <2a79a371-ab8b-3dca-d96d-6849b40afbb0@gemtalksystems.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Norm Green > Sent: Tuesday, May 24, 2016 13:40 > > I've tried both: > > SSL_CTX_set_cipher_list("AECDH") > > and: > > SSL_CTX_set_cipher_list("AECDH-AES256-SHA") > > on both the client and server side, both of which result in the dreaded > "no shared cipher" error: > > error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared > cipher:s3_srvr.c:1417: You might run a wire trace to see what suites the client is actually advertising. And you are using TLS, right? For AECDH* (or any ECC suite), don't you have to tell OpenSSL what curve to use? I haven't implemented that bit myself in any applications, but my understanding is that with OpenSSL 1.0.2 you can just call SSL_CTX_set_ecdh_auto(ctx, 1). With 1.0.1 you have to specify a particular named curve with SSL_CTX_set_tmp_ecdh. -- Michael Wojcik Technology Specialist, Micro Focus From alexandre.klein at tanukisoftware.com Wed May 25 10:00:45 2016 From: alexandre.klein at tanukisoftware.com (Alexandre Klein) Date: Wed, 25 May 2016 19:00:45 +0900 Subject: [openssl-users] make test failed on HPUX parisc In-Reply-To: <20160524151944.GR3300@mournblade.imrryr.org> References: <20160524151944.GR3300@mournblade.imrryr.org> Message-ID: Thanks Viktor for your reply. I forgot to mention that I can compile 1.0.2h 64-bit version on the same machine. The only problem is when building the 32-bit version of OpenSSL. Here is full line: "hpux-parisc2-cc","cc:+DAportable +O3 +Optrs_strongly_typed -Ae +ESlit -DB_ENDIAN -DMD32_XARRAY -D_REENTRANT::::-Wl,+s -ldld:SIXTY_FOUR_BIT MD2_CHAR RC4_INDEX RC4_CHAR DES_UNROLL DES_ RISC1 DES_INT:".eval{my $asm=$parisc20_asm;$asm=~s/2W\./2\./;$asm=~s/:64/:32/;$asm}.":dl:hpux-shared:+Z:-b:.sl.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::/pa20_32", The only difference is: - I removed "+DA2.0 +DS2.0" - I added "+DAportable" If I use the original line, then I have the same error. Alexandre Klein Tanuki Software, Ltd. 6-18-10-4F Nishi-Kasai, Edogawa-ku Tokyo 134-0088 Japan Tel: +81-3-3878-3211 Fax: +81-3-3878-0313 http://www.tanukisoftware.com On Wed, May 25, 2016 at 12:19 AM, Viktor Dukhovni < openssl-users at dukhovni.org> wrote: > On Tue, May 24, 2016 at 06:05:34PM +0900, Alexandre Klein wrote: > > > > > I'm using "hpux-parisc2-cc". I modified Configure to use +DAportable: > > "hpux-parisc2-cc","cc:+DAportable +O3 ... > > "hpux-parisc2-cc","cc:+DA2.0 +DS2.0 +O3 ... > > For meaningful help, post an unedited "diff" between the original > and your version. > > The original Configure file has: > > "hpux-parisc2-cc","cc:+DA2.0 +DS2.0 +O3 +Optrs_strongly_typed -Ae > +ESlit -DB_ENDIAN -DMD32_XARRAY -D_REENTRANT::::-Wl,+s -ldld:SIXTY_FOUR_BIT > MD2_CHAR RC4_INDEX RC4_CHAR DES_UNROLL DES_RISC1 DES_INT:".eval{my > $asm=$parisc20_asm;$asm=~s/2W\./2\./;$asm=~s/:64/:32/;$asm}.":dl:hpux-shared:+Z:-b:.sl.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::/pa20_32", > "hpux64-parisc2-cc","cc:+DD64 +O3 +Optrs_strongly_typed -Ae +ESlit > -DB_ENDIAN -DMD32_XARRAY -D_REENTRANT::::-ldl:SIXTY_FOUR_BIT_LONG MD2_CHAR > RC4_INDEX RC4_CHAR DES_UNROLL DES_RISC1 > DES_INT:${parisc20_asm}:dlfcn:hpux-shared:+Z:+DD64 > -b:.sl.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::/pa20_64", > > > $ ./Configure hpux-parisc2-cc --prefix=path/to/folder no-shared no-zlib > > no-zlib-dynamic no-rc5 no-idea no-ec no-ecdh no-ecdsa no-asm no-mdc2 > no-bf > > no-cast no-md2 no-rc4 no-jpake no-gmp > > In particular you sure you want "no-asm" and "no-shared"? Those > targets seem to be designed for shared builds with asm. > > -- > Viktor. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.hartley at taxcomputersystems.com Wed May 25 10:20:32 2016 From: andrew.hartley at taxcomputersystems.com (Andrew Hartley) Date: Wed, 25 May 2016 10:20:32 +0000 Subject: [openssl-users] openssl-1.1.0 - static linkage Message-ID: I have previously used openssl-1.0.2 and was using it with static linkage into my program on Windows. I built it statically using the nt.mak file. I have now downloaded the source for openssl-1.1.0 and wish to build it statically. If I use the defaults, all builds fine with nmake and then installs into my path as setup with the prefix configure option. If I then configure with no-shared to generate a static library, I gets loads of "error LNK2019 : unresolved external symbol" errors. Would someone please advise me on how to successfully build openssl-1.1.0 statically. Many thanks Andrew ______________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.hartley at taxcomputersystems.com Wed May 25 10:40:18 2016 From: andrew.hartley at taxcomputersystems.com (Andrew Hartley) Date: Wed, 25 May 2016 10:40:18 +0000 Subject: [openssl-users] openssl-1.1.0 - static linkage In-Reply-To: References: Message-ID: <5880db5979194c3d963377911e1f382b@MailSvr.tcsl.taxcomputersystems.com> I have now worked out what to do. I did a clean with: ? nmake clean and then successfully build the library with the no-shared config option. Andrew From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Andrew Hartley Sent: 25 May 2016 11:21 To: openssl-users at openssl.org Subject: [openssl-users] openssl-1.1.0 - static linkage I have previously used openssl-1.0.2 and was using it with static linkage into my program on Windows. I built it statically using the nt.mak file. I have now downloaded the source for openssl-1.1.0 and wish to build it statically. If I use the defaults, all builds fine with nmake and then installs into my path as setup with the prefix configure option. If I then configure with no-shared to generate a static library, I gets loads of "error LNK2019 : unresolved external symbol" errors. Would someone please advise me on how to successfully build openssl-1.1.0 statically. Many thanks Andrew ______________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________ ______________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.hartley at taxcomputersystems.com Wed May 25 11:19:40 2016 From: andrew.hartley at taxcomputersystems.com (Andrew Hartley) Date: Wed, 25 May 2016 11:19:40 +0000 Subject: [openssl-users] openssl-1.1.0 - Linker error on Windows Message-ID: <50755307e79d4bf982fd659236a40047@MailSvr.tcsl.taxcomputersystems.com> I've built the openssl-1.1.0 library with no-shared config option on Windows. I've linked the library to my application and fixed the few issues with EVP_MD_CTX deprication. When I build my application I get the following link errors: 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertFreeCertificateContext at 4 referenced in function _capi_free_key 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertGetCertificateContextProperty at 16 referenced in function _capi_get_prov_info 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertOpenStore at 20 referenced in function _capi_open_store 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertFindCertificateInStore at 24 referenced in function _capi_find_cert 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertEnumCertificatesInStore at 8 referenced in function _capi_find_cert 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertCloseStore at 8 referenced in function _capi_find_key 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertDuplicateCertificateContext at 4 referenced in function _capi_load_ssl_client_cert Any advice on how this is to be fixed? Andrew ______________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Wed May 25 13:59:41 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 25 May 2016 13:59:41 +0000 Subject: [openssl-users] openssl-1.1.0 - Linker error on Windows In-Reply-To: <50755307e79d4bf982fd659236a40047@MailSvr.tcsl.taxcomputersystems.com> References: <50755307e79d4bf982fd659236a40047@MailSvr.tcsl.taxcomputersystems.com> Message-ID: [Ugh, HTML email, which Outlook is still incapable of processing correctly.] > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Andrew Hartley > Sent: Wednesday, May 25, 2016 05:20 > I?ve built the openssl-1.1.0 library with no-shared config option on Windows.? I?ve linked the library to my application > and fixed the few issues with EVP_MD_CTX deprication.? When I build my application I get the following link errors: ? > 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertFreeCertificateContext at 4 referenced in function _capi_free_key You have the CAPI engine linked into libcrypto (rather than configuring it for dynamic loading), so you need to link against the Windows CAPI library, which is crypt32.lib. Add /Lcrypt32, either when you create libcrypto or when you link your application. -- Michael Wojcik Technology Specialist, Micro Focus From matt at openssl.org Wed May 25 14:04:37 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 25 May 2016 15:04:37 +0100 Subject: [openssl-users] openssl-1.1.0 - Linker error on Windows In-Reply-To: References: <50755307e79d4bf982fd659236a40047@MailSvr.tcsl.taxcomputersystems.com> Message-ID: <5745B0F5.9090607@openssl.org> On 25/05/16 14:59, Michael Wojcik wrote: > [Ugh, HTML email, which Outlook is still incapable of processing > correctly.] > >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On >> Behalf Of Andrew Hartley Sent: Wednesday, May 25, 2016 05:20 > >> I?ve built the openssl-1.1.0 library with no-shared config option >> on Windows. I?ve linked the library to my application > and fixed >> the few issues with EVP_MD_CTX deprication. When I build my >> application I get the following link errors: > >> 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external >> symbol __imp__CertFreeCertificateContext at 4 referenced in function >> _capi_free_key > > You have the CAPI engine linked into libcrypto (rather than > configuring it for dynamic loading) IIRC it is no longer possible to build for static linking but dynamically load engines (there be dragons). >, so you need to link against the > Windows CAPI library, which is crypt32.lib. Add /Lcrypt32, either > when you create libcrypto or when you link your application. > Another possibility, if you are not using the CAPI engine, is to disable it during the OpenSSL build using the no-capieng Configure option. Matt From Michael.Wojcik at microfocus.com Wed May 25 14:35:27 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 25 May 2016 14:35:27 +0000 Subject: [openssl-users] openssl-1.1.0 - Linker error on Windows In-Reply-To: <5745B0F5.9090607@openssl.org> References: <50755307e79d4bf982fd659236a40047@MailSvr.tcsl.taxcomputersystems.com> <5745B0F5.9090607@openssl.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Matt Caswell > Sent: Wednesday, May 25, 2016 08:05 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] openssl-1.1.0 - Linker error on Windows > > > On 25/05/16 14:59, Michael Wojcik wrote: > > > >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > >> Behalf Of Andrew Hartley Sent: Wednesday, May 25, 2016 05:20 > > > >> I?ve built the openssl-1.1.0 library with no-shared config option > >> on Windows. I?ve linked the library to my application > and fixed > >> the few issues with EVP_MD_CTX deprication. When I build my > >> application I get the following link errors: > > > >> 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external > >> symbol __imp__CertFreeCertificateContext at 4 referenced in function > >> _capi_free_key > > > > You have the CAPI engine linked into libcrypto (rather than > > configuring it for dynamic loading) > > IIRC it is no longer possible to build for static linking but > dynamically load engines (there be dragons). Perhaps not. I have a hybrid engine mechanism where I build OpenSSL as a static library but as sharable code, link it statically into my own shared library (DLL on Windows, shared object on Linux/UNIX), and add an engine at runtime. The engine is implemented in my library, so it's not actually dynamically loaded, but it isn't statically linked into OpenSSL either. That seems to work fine, at least for 1.0.1 and 1.0.2. (Of course, Configure doesn't actually support building OpenSSL as static libraries of sharable code, so we have to edit the configurations we use with each release. But such is life.) > >, so you need to link against the > > Windows CAPI library, which is crypt32.lib. Add /Lcrypt32, either > > when you create libcrypto or when you link your application. > > Another possibility, if you are not using the CAPI engine, is to disable > it during the OpenSSL build using the no-capieng Configure option. Yes. I was assuming Andrew wanted CAPI support and had configured it explicitly, but that isn't a safe assumption. If he doesn't need it, then disabling it in the configure options is the most sensible course. -- Michael Wojcik Technology Specialist, Micro Focus From andrew.hartley at taxcomputersystems.com Wed May 25 14:43:57 2016 From: andrew.hartley at taxcomputersystems.com (Andrew Hartley) Date: Wed, 25 May 2016 14:43:57 +0000 Subject: [openssl-users] openssl-1.1.0 - Linker error on Windows In-Reply-To: References: <50755307e79d4bf982fd659236a40047@MailSvr.tcsl.taxcomputersystems.com> <5745B0F5.9090607@openssl.org> Message-ID: <2f29297600e945fbb778c1bdabb60060@MailSvr.tcsl.taxcomputersystems.com> -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Michael Wojcik Sent: 25 May 2016 15:35 To: openssl-users at openssl.org Subject: Re: [openssl-users] openssl-1.1.0 - Linker error on Windows > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf Of Matt Caswell > Sent: Wednesday, May 25, 2016 08:05 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] openssl-1.1.0 - Linker error on Windows > > > On 25/05/16 14:59, Michael Wojcik wrote: > > > >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > >> Behalf Of Andrew Hartley Sent: Wednesday, May 25, 2016 05:20 > > > >> I've built the openssl-1.1.0 library with no-shared config option > >> on Windows. I've linked the library to my application > and fixed > >> the few issues with EVP_MD_CTX deprication. When I build my > >> application I get the following link errors: > > > >> 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external > >> symbol __imp__CertFreeCertificateContext at 4 referenced in function > >> _capi_free_key > > > > You have the CAPI engine linked into libcrypto (rather than > > configuring it for dynamic loading) > > IIRC it is no longer possible to build for static linking but > dynamically load engines (there be dragons). Perhaps not. I have a hybrid engine mechanism where I build OpenSSL as a static library but as sharable code, link it statically into my own shared library (DLL on Windows, shared object on Linux/UNIX), and add an engine at runtime. The engine is implemented in my library, so it's not actually dynamically loaded, but it isn't statically linked into OpenSSL either. That seems to work fine, at least for 1.0.1 and 1.0.2. (Of course, Configure doesn't actually support building OpenSSL as static libraries of sharable code, so we have to edit the configurations we use with each release. But such is life.) > >, so you need to link against the > > Windows CAPI library, which is crypt32.lib. Add /Lcrypt32, either > >when you create libcrypto or when you link your application. > > Another possibility, if you are not using the CAPI engine, is to > disable it during the OpenSSL build using the no-capieng Configure option. Yes. I was assuming Andrew wanted CAPI support and had configured it explicitly, but that isn't a safe assumption. If he doesn't need it, then disabling it in the configure options is the most sensible course. I've switched it off via the configure options. All working fine now thank you. Andrew ______________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________ From matt at openssl.org Wed May 25 14:51:50 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 25 May 2016 15:51:50 +0100 Subject: [openssl-users] openssl-1.1.0 - Linker error on Windows In-Reply-To: References: <50755307e79d4bf982fd659236a40047@MailSvr.tcsl.taxcomputersystems.com> <5745B0F5.9090607@openssl.org> Message-ID: <5745BC06.5040401@openssl.org> On 25/05/16 15:35, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On >> Behalf Of Matt Caswell Sent: Wednesday, May 25, 2016 08:05 To: >> openssl-users at openssl.org Subject: Re: [openssl-users] >> openssl-1.1.0 - Linker error on Windows >> >> >> On 25/05/16 14:59, Michael Wojcik wrote: >>> >>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] >>>> On Behalf Of Andrew Hartley Sent: Wednesday, May 25, 2016 >>>> 05:20 >>> >>>> I?ve built the openssl-1.1.0 library with no-shared config >>>> option on Windows. I?ve linked the library to my application > >>>> and fixed the few issues with EVP_MD_CTX deprication. When I >>>> build my application I get the following link errors: >>> >>>> 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved >>>> external symbol __imp__CertFreeCertificateContext at 4 referenced >>>> in function _capi_free_key >>> >>> You have the CAPI engine linked into libcrypto (rather than >>> configuring it for dynamic loading) >> >> IIRC it is no longer possible to build for static linking but >> dynamically load engines (there be dragons). > > Perhaps not. I have a hybrid engine mechanism where I build OpenSSL > as a static library but as sharable code, link it statically into my > own shared library (DLL on Windows, shared object on Linux/UNIX), and > add an engine at runtime. The engine is implemented in my library, so > it's not actually dynamically loaded, but it isn't statically linked > into OpenSSL either. That seems to work fine, at least for 1.0.1 and > 1.0.2. The problem is that OpenSSL maintains global state. If you've built OpenSSL as a shared library then any applications or dynamically loaded engines all load the same shared library and all have the same global state. If your application is linked statically to OpenSSL and then dynamically loads engines which are also linked to OpenSSL...then you essentially get *two* copies of the state! 1.0.1 and 1.0.2 have some hacks to deal with this for some of the obvious areas where this will cause problems in engines (e.g. error queues). You can just about get away with it if you're lucky - but they really are hacks and you could come unstuck in some corner cases. In 1.1.0 it was decided that that was an untenable position. Matt From Michael.Wojcik at microfocus.com Wed May 25 16:18:52 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 25 May 2016 16:18:52 +0000 Subject: [openssl-users] make test failed on HPUX parisc In-Reply-To: References: <20160524151944.GR3300@mournblade.imrryr.org> Message-ID: This is probably not very useful, but just as another data point: 32-bit OpenSSL 1.0.2g passes "make test" on HP-UX 11.31 for ia64 (Itanium). I have no idea whether the difference is in the OpenSSL version, the HP-UX version, the CPU type, or some configuration option. Unfortunately we no longer regularly build OpenSSL on HP-UX for PA-RISC, so I can't easily test 1.0.2g there. If I get a chance, I'll poke around to see if we still have a PA-RISC machine I could use to try to reproduce the problem with 1.0.2h. -- Michael Wojcik Technology Specialist, Micro Focus From 3vdsea+cmbrhsm95uy28 at sharklasers.com Wed May 25 15:47:24 2016 From: 3vdsea+cmbrhsm95uy28 at sharklasers.com (stas730) Date: Wed, 25 May 2016 08:47:24 -0700 (MST) Subject: [openssl-users] Certificate Transparency: OCSP response In-Reply-To: <1464112378889-66295.post@n7.nabble.com> References: <1464112378889-66295.post@n7.nabble.com> Message-ID: <1464191244635-66328.post@n7.nabble.com> Please, send mesaage! -- View this message in context: http://openssl.6102.n7.nabble.com/Certificate-Transparency-OCSP-response-tp66295p66328.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From norm.green at gemtalksystems.com Wed May 25 20:31:28 2016 From: norm.green at gemtalksystems.com (Norm Green) Date: Wed, 25 May 2016 13:31:28 -0700 Subject: [openssl-users] Diffie-Hellman Questions In-Reply-To: References: <34db33c7-88e2-0bcd-92b5-114d01b0697c@gemtalksystems.com> <23544be40f4647c986ddd11e8df421f0@usma1ex-dag1mb1.msg.corp.akamai.com> <2529d2e4-b94c-e3a7-5df1-d61e00df46e2@gemtalksystems.com> <8c2b3842b28041b494be46e73e8f0a3f@usma1ex-dag1mb1.msg.corp.akamai.com> <2a79a371-ab8b-3dca-d96d-6849b40afbb0@gemtalksystems.com> Message-ID: Yes! That was the problem. In order to use cipher "AECDH", SSL_CTX_set_ecdh_auto(ctx, 1) must be called first. Thanks Michael!! Norm On 5/24/16 15:52, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Norm Green >> Sent: Tuesday, May 24, 2016 13:40 >> >> I've tried both: >> >> SSL_CTX_set_cipher_list("AECDH") >> >> and: >> >> SSL_CTX_set_cipher_list("AECDH-AES256-SHA") >> >> on both the client and server side, both of which result in the dreaded >> "no shared cipher" error: >> >> error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared >> cipher:s3_srvr.c:1417: > You might run a wire trace to see what suites the client is actually advertising. > > And you are using TLS, right? > > For AECDH* (or any ECC suite), don't you have to tell OpenSSL what curve to use? I haven't implemented that bit myself in any applications, but my understanding is that with OpenSSL 1.0.2 you can just call SSL_CTX_set_ecdh_auto(ctx, 1). With 1.0.1 you have to specify a particular named curve with SSL_CTX_set_tmp_ecdh. > From openssl-users at dukhovni.org Wed May 25 20:41:06 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 25 May 2016 20:41:06 +0000 Subject: [openssl-users] Diffie-Hellman Questions In-Reply-To: <23544be40f4647c986ddd11e8df421f0@usma1ex-dag1mb1.msg.corp.akamai.com> References: <34db33c7-88e2-0bcd-92b5-114d01b0697c@gemtalksystems.com> <23544be40f4647c986ddd11e8df421f0@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160525204106.GB3300@mournblade.imrryr.org> On Tue, May 24, 2016 at 05:08:38PM +0000, Salz, Rich wrote: > > 2) Are the same encryption keys used every time with ADH? > > Yes. That's the other BIG reason :) You really want ephemeral, and therefore ECDH NO, Rich is making a mistake, ADH is ephemeral of necessity, since without long-term keys in certificates it is impossible to use long-term keys whose disclosure might later compromise confidentiality. > > 3) Is it possible to use ephemeral DH without using certificates? I was not > > able to get that to work. > > Yes. This is "null" auth. Essentially: aNULL == (ADH || AECDH). -- Viktor. From openssl-users at dukhovni.org Wed May 25 20:58:36 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 25 May 2016 20:58:36 +0000 Subject: [openssl-users] Diffie-Hellman Questions In-Reply-To: <8c2b3842b28041b494be46e73e8f0a3f@usma1ex-dag1mb1.msg.corp.akamai.com> References: <34db33c7-88e2-0bcd-92b5-114d01b0697c@gemtalksystems.com> <23544be40f4647c986ddd11e8df421f0@usma1ex-dag1mb1.msg.corp.akamai.com> <2529d2e4-b94c-e3a7-5df1-d61e00df46e2@gemtalksystems.com> <8c2b3842b28041b494be46e73e8f0a3f@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160525205836.GC3300@mournblade.imrryr.org> On Tue, May 24, 2016 at 05:45:56PM +0000, Salz, Rich wrote: > > >./openssl ciphers -v 'ALL:aNULL' |grep ECDH |grep "Au=None" > > AECDH-AES256-SHA SSLv3 Kx=ECDH Au=None Enc=AES(256) Mac=SHA1 > > AECDH-AES128-SHA SSLv3 Kx=ECDH Au=None Enc=AES(128) Mac=SHA1 > > AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1 > > AECDH-DES-CBC3-SHA SSLv3 Kx=ECDH Au=None Enc=3DES(168) Mac=SHA1 > > AECDH-NULL-SHA SSLv3 Kx=ECDH Au=None Enc=None Mac=SHA1 > > > > 1) What arg to SSL_CTX_set_cipher_list() to I need to use to get these? > > I previously tried "kEECDH:kEDH" and that didn't work. > > Use one of the names in the first column. No. To avoid overly-specific settings: # To insist on anon ciphersuites: OpenSSL 1.0.x: ALL+aNULL OpenSSL 1.1.x: ALL+aNULL:@SECLEVEL=0 # To prefer anon ciphersuites: OpenSSL 1.0.x: aNULL:-aNULL:ALL OpenSSL 1.1.x: aNULL:-aNULL:ALL:@SECLEVEL=0 # To tolerate anon ciphersuites without explicit preference: OpenSSL 1.0.x: ALL OpenSSL 1.1.x: ALL:@SECLEVEL=0 In OpenSSL 1.1.0 I wanted to implement @AUTHLEVEL, to support @SECLEVEL=1 for ciphers, while allowing anon auth, but that did not make it into the code early enough: ssl/ssl_cert.c: /* * XXX: Separate @AUTHSECLEVEL and @TLSSECLEVEL would be useful at some * point, for now a single @SECLEVEL sets the same policy for TLS crypto * and PKI authentication. */ X509_VERIFY_PARAM_set_auth_level(param, SSL_get_security_level(s)); That is perhaps still technically possible for 1.1.0, but almost certainly too late, it is not a bug fix, and we're near the final release. I'd like to add that for the next release. -- Viktor. From jeremy.farrell at oracle.com Wed May 25 21:10:11 2016 From: jeremy.farrell at oracle.com (Jeremy Farrell) Date: Wed, 25 May 2016 22:10:11 +0100 Subject: [openssl-users] Diffie-Hellman Questions In-Reply-To: References: <34db33c7-88e2-0bcd-92b5-114d01b0697c@gemtalksystems.com> <23544be40f4647c986ddd11e8df421f0@usma1ex-dag1mb1.msg.corp.akamai.com> <2529d2e4-b94c-e3a7-5df1-d61e00df46e2@gemtalksystems.com> <8c2b3842b28041b494be46e73e8f0a3f@usma1ex-dag1mb1.msg.corp.akamai.com> <2a79a371-ab8b-3dca-d96d-6849b40afbb0@gemtalksystems.com> Message-ID: Interesting; is this a server-side requirement? I ask because with 1.0.2g my client using "AECDH+AES:ADH+AES" makes a TLS 1.2 connection with AECDH-AES256-SHA without calling this function or similar. Regards, jjf On 25/05/2016 21:31, Norm Green wrote: > Yes! That was the problem. In order to use cipher "AECDH", > SSL_CTX_set_ecdh_auto(ctx, 1) must be called first. > > Thanks Michael!! > > Norm > > > On 5/24/16 15:52, Michael Wojcik wrote: >>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On >>> Behalf >>> Of Norm Green >>> Sent: Tuesday, May 24, 2016 13:40 >>> >>> I've tried both: >>> >>> SSL_CTX_set_cipher_list("AECDH") >>> >>> and: >>> >>> SSL_CTX_set_cipher_list("AECDH-AES256-SHA") >>> >>> on both the client and server side, both of which result in the dreaded >>> "no shared cipher" error: >>> >>> error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared >>> cipher:s3_srvr.c:1417: >> You might run a wire trace to see what suites the client is actually >> advertising. >> >> And you are using TLS, right? >> >> For AECDH* (or any ECC suite), don't you have to tell OpenSSL what >> curve to use? I haven't implemented that bit myself in any >> applications, but my understanding is that with OpenSSL 1.0.2 you can >> just call SSL_CTX_set_ecdh_auto(ctx, 1). With 1.0.1 you have to >> specify a particular named curve with SSL_CTX_set_tmp_ecdh. -- J. J. Farrell Not speaking for Oracle -------------- next part -------------- An HTML attachment was scrubbed... URL: From norm.green at gemtalksystems.com Wed May 25 21:58:35 2016 From: norm.green at gemtalksystems.com (Norm Green) Date: Wed, 25 May 2016 14:58:35 -0700 Subject: [openssl-users] Diffie-Hellman Questions In-Reply-To: References: <34db33c7-88e2-0bcd-92b5-114d01b0697c@gemtalksystems.com> <23544be40f4647c986ddd11e8df421f0@usma1ex-dag1mb1.msg.corp.akamai.com> <2529d2e4-b94c-e3a7-5df1-d61e00df46e2@gemtalksystems.com> <8c2b3842b28041b494be46e73e8f0a3f@usma1ex-dag1mb1.msg.corp.akamai.com> <2a79a371-ab8b-3dca-d96d-6849b40afbb0@gemtalksystems.com> Message-ID: <52bd61ce-c0ae-c9ac-b104-7d96df690ca0@gemtalksystems.com> Yes, it's only required on the server. Norm Green On 5/25/16 14:10, Jeremy Farrell wrote: > Interesting; is this a server-side requirement? I ask because with > 1.0.2g my client using "AECDH+AES:ADH+AES" makes a TLS 1.2 connection > with AECDH-AES256-SHA without calling this function or similar. > > Regards, > jjf > > On 25/05/2016 21:31, Norm Green wrote: >> Yes! That was the problem. In order to use cipher "AECDH", >> SSL_CTX_set_ecdh_auto(ctx, 1) must be called first. >> >> Thanks Michael!! >> >> Norm >> >> >> On 5/24/16 15:52, Michael Wojcik wrote: >>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On >>>> Behalf >>>> Of Norm Green >>>> Sent: Tuesday, May 24, 2016 13:40 >>>> >>>> I've tried both: >>>> >>>> SSL_CTX_set_cipher_list("AECDH") >>>> >>>> and: >>>> >>>> SSL_CTX_set_cipher_list("AECDH-AES256-SHA") >>>> >>>> on both the client and server side, both of which result in the >>>> dreaded >>>> "no shared cipher" error: >>>> >>>> error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared >>>> cipher:s3_srvr.c:1417: >>> You might run a wire trace to see what suites the client is actually >>> advertising. >>> >>> And you are using TLS, right? >>> >>> For AECDH* (or any ECC suite), don't you have to tell OpenSSL what >>> curve to use? I haven't implemented that bit myself in any >>> applications, but my understanding is that with OpenSSL 1.0.2 you >>> can just call SSL_CTX_set_ecdh_auto(ctx, 1). With 1.0.1 you have to >>> specify a particular named curve with SSL_CTX_set_tmp_ecdh. > > -- > J. J. Farrell > Not speaking for Oracle > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed May 25 22:39:33 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 25 May 2016 22:39:33 +0000 Subject: [openssl-users] Diffie-Hellman Questions In-Reply-To: <20160525204106.GB3300@mournblade.imrryr.org> References: <34db33c7-88e2-0bcd-92b5-114d01b0697c@gemtalksystems.com> <23544be40f4647c986ddd11e8df421f0@usma1ex-dag1mb1.msg.corp.akamai.com> <20160525204106.GB3300@mournblade.imrryr.org> Message-ID: <465caec4c6534b88b5d03bf06afa9efb@usma1ex-dag1mb1.msg.corp.akamai.com> > NO, Rich is making a mistake, ADH is ephemeral of necessity, since without > long-term keys in certificates it is impossible to use long-term keys whose > disclosure might later compromise confidentiality. Except that your code can always use the same keypair if it screws up the callback. And that's what I meant. But Viktor's advice is spot-on. From Michael.Wojcik at microfocus.com Wed May 25 23:45:20 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 25 May 2016 23:45:20 +0000 Subject: [openssl-users] openssl-1.1.0 - Linker error on Windows In-Reply-To: <5745BC06.5040401@openssl.org> References: <50755307e79d4bf982fd659236a40047@MailSvr.tcsl.taxcomputersystems.com> <5745B0F5.9090607@openssl.org> <5745BC06.5040401@openssl.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Matt Caswell > Sent: Wednesday, May 25, 2016 08:52 > > On 25/05/16 15:35, Michael Wojcik wrote: > >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > >> Behalf Of Matt Caswell Sent: Wednesday, May 25, 2016 08:05 To: > >> > >> IIRC it is no longer possible to build for static linking but > >> dynamically load engines (there be dragons). > > > > Perhaps not. I have a hybrid engine mechanism where I build OpenSSL > > as a static library but as sharable code, link it statically into my > > own shared library (DLL on Windows, shared object on Linux/UNIX), and > > add an engine at runtime. The engine is implemented in my library, so > > it's not actually dynamically loaded, but it isn't statically linked > > into OpenSSL either. That seems to work fine, at least for 1.0.1 and > > 1.0.2. > > The problem is that OpenSSL maintains global state. If you've built > OpenSSL as a shared library then any applications or dynamically loaded > engines all load the same shared library and all have the same global state. > > If your application is linked statically to OpenSSL and then dynamically > loads engines which are also linked to OpenSSL...then you essentially > get *two* copies of the state! Ah. That's not a problem in my case, since both OpenSSL and my engine code are statically linked into a single shared library. Everyone's using the same single copy of OpenSSL. The engine is added to OpenSSL at runtime (if it's needed) as if it were dynamically loaded, but it was there all along. And while we statically link OpenSSL into our own library, it's built for sharing and our library is shared. We're just not supplying libcrypto and libssl as discrete modules. (We're very familiar with the issues around shared-library collisions, thanks to decades of dealing with things like Microsoft's broken C runtime, Oracle's inclusion of OpenLDAP in their client, and so on.) -- Michael Wojcik Technology Specialist, Micro Focus From murakami at acroquest.co.jp Thu May 26 11:15:40 2016 From: murakami at acroquest.co.jp (Akira Murakami) Date: Thu, 26 May 2016 20:15:40 +0900 Subject: [openssl-users] SSL problem related to ServerName directive Message-ID: <0aa701d1b73f$efe9bab0$cfbd3010$@acroquest.co.jp> Hi, I am trying to use Apache 2.2.21 and Subversion 1.18.11 with OpenSSL 1.0.2h on Windows Server 2008 R2 Enterprise. I have a problem which is related to ServerName directive on httpd-ssl.conf. When I type in the host name of URL such as "www.example.com" on ServerName directive, the Browser(IE) shows error message stating that "Internet Explorer cannot display the webpage". But when I type machine name of server on ServerName directive, the browser shows correct page. Even though I can access the browser with this method, I still cannot access SVN client because of SSL hand-shake error. Any help is appreciated. +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ ?GPTW???????????????? 2????1????? ?http://www.acroquest.co.jp/gptw ????25?99???? ???????????????????????? ?http://www.acroquest.co.jp/51systems ??5??????????????????????????????? http://taisetu-taisyo.jimdo.com/?5?-????/ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Acroquest Technology?????http://www.acroquest.co.jp ???????? ????? ?mailto:murakami at acroquest.co.jp ?TEL:045-476-3171 ?FAX:045-476-4171 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ From murakami at acroquest.co.jp Thu May 26 11:22:39 2016 From: murakami at acroquest.co.jp (Akira Murakami) Date: Thu, 26 May 2016 20:22:39 +0900 Subject: [openssl-users] SSL problem related to ServerName directive Message-ID: <0aaf01d1b740$e9d782a0$bd8687e0$@acroquest.co.jp> Hi, I am trying to use Apache 2.2.21 and Subversion 1.18.11 with OpenSSL 1.0.2h on Windows Server 2008 R2 Enterprise. I have a problem which is related to ServerName directive on httpd-ssl.conf. When I type in the host name of URL such as "www.example.com" on ServerName directive, the Browser(IE) shows error message stating that "Internet Explorer cannot display the webpage". But when I type machine name of server on ServerName directive, the browser shows correct page. Even though I can access the browser with this method, I still cannot access SVN client because of SSL hand-shake error. Any help is appreciated. From Suman.Patro-TRN at lntebg.com Thu May 26 16:33:27 2016 From: Suman.Patro-TRN at lntebg.com (R-D intern) Date: Thu, 26 May 2016 09:33:27 -0700 (MST) Subject: [openssl-users] regarding ssl_server test Message-ID: <1464280407874-66354.post@n7.nabble.com> Hello, I have implemented ssl for my internal server that listens over a private ip. Can anyone suggest how can I test my ssl_server? For eg. Qualys test shows the amount of ssl implementation of a server listening over public ip and even checks for vulnerabilities in ssl implementation. How can such a thing be tested for a server listening over private ip? Please help. Awaiting response. Regards, R-D Intern -- View this message in context: http://openssl.6102.n7.nabble.com/regarding-ssl-server-test-tp66354.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From martin at black-sheep-research.com Thu May 26 17:01:07 2016 From: martin at black-sheep-research.com (counterpoint) Date: Thu, 26 May 2016 10:01:07 -0700 (MST) Subject: [openssl-users] OpenSSL non-blocking epoll hanging on data receiving Message-ID: <1464282067393-66355.post@n7.nabble.com> I'm working on a proxy application that uses non-blocking socket I/O. A limited number of threads use epoll to handle events, and each thread runs process bound as much as it can. The SSL implementation uses read_SSL and write_SSL, with logic to handle "read wants write" etc. When reading, processing is triggered by an EPOLLIN event and read_SSL will read all the data available - after an initial read, a loop is controlled by SSL_pending(). The problem is that with a large volume of data the read process comes to a halt. Perhaps this means that there was unprocessed data that has been received but cannot be read. In that case, the read loop will not get all the data, but neither will there be an EPOLLIN event. If this happens when no further data is to be sent, the connection comes to a halt (if my analysis is correct). Or maybe my analysis isn't correct! I'd be grateful for any pointers to how I can get out of this problem! -- View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-non-blocking-epoll-hanging-on-data-receiving-tp66355.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From Walter.H at mathemainzel.info Thu May 26 18:52:02 2016 From: Walter.H at mathemainzel.info (Walter H.) Date: Thu, 26 May 2016 20:52:02 +0200 Subject: [openssl-users] regarding ssl_server test In-Reply-To: <1464280407874-66354.post@n7.nabble.com> References: <1464280407874-66354.post@n7.nabble.com> Message-ID: <574745D2.30808@mathemainzel.info> On 26.05.2016 18:33, R-D intern wrote: > Hello, > I have implemented ssl for my internal server that listens over a > private ip. Can anyone suggest how can I test my ssl_server? For eg. Qualys > test shows the amount of ssl implementation of a server listening over > public ip and even checks for vulnerabilities in ssl implementation. How > can such a thing be tested for a server listening over private ip? > you can't because, your site listens for e.g. https://host.domain.local/... and domain.local is the CN of your SSL-certificate, but not a real public domain name; so a port forwarding in a NAT router won't help you ... you only can do - in case you have a public webserver - implement it there and test with Qualys ... and then take the same configuration parameters to your internal server Walter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4312 bytes Desc: S/MIME Cryptographic Signature URL: From mcepl at cepl.eu Thu May 26 20:18:14 2016 From: mcepl at cepl.eu (=?UTF-8?Q?Mat=C4=9Bj?= Cepl) Date: Thu, 26 May 2016 22:18:14 +0200 Subject: [openssl-users] regarding ssl_server test References: <1464280407874-66354.post@n7.nabble.com> Message-ID: On 2016-05-26, 16:33 GMT, R-D intern wrote: > I have implemented ssl for my internal server that listens > over a private ip. Can anyone suggest how can I test my > ssl_server? For eg. Qualys test shows the amount of ssl > implementation of a server listening over public ip and even > checks for vulnerabilities in ssl implementation. How can such > a thing be tested for a server listening over private ip? Are we talking about unit testing or functional testing? For the former, just use whatever tools are appropriate for your language, and for the latter, ... I am trying to revive M2Crypto (Python bindings to OpenSSL), which has a lot of tests done via running the OpenSSL?s binary s_client against the server and checking the reaction of the server. That could work for you as well, couldn't it? Mat?j -- https://matej.ceplovi.cz/blog/, Jabber: mcepl at ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Courage is resistance of fear, mastery of fear, not absence of fear. From jb-openssl at wisemo.com Thu May 26 21:51:26 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 26 May 2016 23:51:26 +0200 Subject: [openssl-users] regarding ssl_server test In-Reply-To: <1464280407874-66354.post@n7.nabble.com> References: <1464280407874-66354.post@n7.nabble.com> Message-ID: <99310875-060e-47ce-5da7-257aeac526f4@wisemo.com> On 26/05/2016 18:33, R-D intern wrote: > Hello, > I have implemented ssl for my internal server that listens over a > private ip. Can anyone suggest how can I test my ssl_server? For eg. Qualys > test shows the amount of ssl implementation of a server listening over > public ip and even checks for vulnerabilities in ssl implementation. How > can such a thing be tested for a server listening over private ip? > Please help. Awaiting response. > Regards, > R-D Intern > Indeed, there are many servers that cannot be reached by the online configuration tests such as the one run by Qualsys. What would be really nice would be if one of the good test suites could be downloaded and run locally on internal servers, non-web servers, staging servers etc. to verify that configurations are correct, or at least as good as possible. Note (for some of the other repliers) that this is not about unit-testing or software testing, but about testing if a finished system has been correctly configured and assembled. In other words, the question isn't "is there a bug in my new/changed code?". But "Did I accidentally configure this Apache HTTPS server with RSA-EXPORT enabled or something equally dangerous?", "Does the STARTLS mail server I just installed implement OCSP stapling safely?", "Did I install the correct set of intermediary CA certs in the returned chain?", and hundreds of similar questions. QualSys does an excellent job checking this for public port 443 https servers, but nothing else, a downloadable copy of the QualSys code without the policy restrictions of the online service would be one way of filling the gap. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From martin at black-sheep-research.com Fri May 27 06:32:16 2016 From: martin at black-sheep-research.com (counterpoint) Date: Thu, 26 May 2016 23:32:16 -0700 (MST) Subject: [openssl-users] OpenSSL non-blocking epoll hanging on data receiving In-Reply-To: <1464282067393-66355.post@n7.nabble.com> References: <1464282067393-66355.post@n7.nabble.com> Message-ID: <1464330736228-66370.post@n7.nabble.com> Hmm, some progress, but still puzzled. When my code is acting as the client, it seems that the problem can be overcome by calling SSL_set_read_ahead with a zero parameter, to turn off reading ahead. This is done just before calling SSL_connect. The application now seems able to read megabytes of data from the server without hanging. However, adding a similar call just before SSL_accept does not solve the problem when the application is the server, and is reading a lot of data from the client. It looks as if the data is read (certainly hundreds of KB in packets of 16384 bytes) but the application then hangs. Presumably for lack of any trigger (such as EPOLLIN) to generate any further activity. Any suggestions please? -- View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-non-blocking-epoll-hanging-on-data-receiving-tp66355p66370.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From matt at openssl.org Fri May 27 08:53:24 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 27 May 2016 09:53:24 +0100 Subject: [openssl-users] OpenSSL non-blocking epoll hanging on data receiving In-Reply-To: <1464330736228-66370.post@n7.nabble.com> References: <1464282067393-66355.post@n7.nabble.com> <1464330736228-66370.post@n7.nabble.com> Message-ID: <57480B04.3040403@openssl.org> On 27/05/16 07:32, counterpoint wrote: > Hmm, some progress, but still puzzled. When my code is acting as the client, > it seems that the problem can be overcome by calling SSL_set_read_ahead with > a zero parameter, to turn off reading ahead. This is done just before > calling SSL_connect. The application now seems able to read megabytes of > data from the server without hanging. read_ahead and SSL_pending() do not play nicely together unfortunately. See the master (1.1.0) version of the SSL_pending() documentation which discusses this issue and introduced the new function SSL_has_pending() which addresses it: https://www.openssl.org/docs/manmaster/ssl/SSL_pending.html > > However, adding a similar call just before SSL_accept does not solve the > problem when the application is the server, and is reading a lot of data > from the client. It looks as if the data is read (certainly hundreds of KB > in packets of 16384 bytes) but the application then hangs. Presumably for > lack of any trigger (such as EPOLLIN) to generate any further activity. So it sounds like this is during reading of application data? Has SSL_accept() returned successfully, and you are now wanting to call SSL_read()? Matt From martin at black-sheep-research.com Fri May 27 12:23:04 2016 From: martin at black-sheep-research.com (counterpoint) Date: Fri, 27 May 2016 05:23:04 -0700 (MST) Subject: [openssl-users] OpenSSL non-blocking epoll hanging on data receiving In-Reply-To: <57480B04.3040403@openssl.org> References: <1464282067393-66355.post@n7.nabble.com> <1464330736228-66370.post@n7.nabble.com> <57480B04.3040403@openssl.org> Message-ID: <1464351784734-66383.post@n7.nabble.com> Thanks for the comments, Matt. > read_ahead and SSL_pending() do not play nicely together unfortunately. > See the master (1.1.0) version of the SSL_pending() documentation which > discusses this issue and introduced the new function SSL_has_pending() > which addresses it: > https://www.openssl.org/docs/manmaster/ssl/SSL_pending.html I looked at SSL_has_pending, but can't easily use it as the software needs to build on standard distributions, as far as possible, and it isn't in e.g. CentOS 6.5 > So it sounds like this is during reading of application data? Has > SSL_accept() returned successfully, and you are now wanting to call > SSL_read()? It's getting a lot further than that. The SSL_accept returns success, and a whole series of SSL_read and SSL_write calls look to be operating fine. It appears that most of the 500KB of data used in the test is transferred, but (probably near the end) the process hangs. Presumably SSL_pending is returning 0 and there are no further EPOLLIN events. Or something like that. I expected that turning off read ahead would fix both server and client, but it seems not. I've read all the configuration options I can find, but so far haven't found a solution to the server side application. -- View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-non-blocking-epoll-hanging-on-data-receiving-tp66355p66383.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From matt at openssl.org Fri May 27 13:43:41 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 27 May 2016 14:43:41 +0100 Subject: [openssl-users] OpenSSL non-blocking epoll hanging on data receiving In-Reply-To: <1464351784734-66383.post@n7.nabble.com> References: <1464282067393-66355.post@n7.nabble.com> <1464330736228-66370.post@n7.nabble.com> <57480B04.3040403@openssl.org> <1464351784734-66383.post@n7.nabble.com> Message-ID: <57484F0D.603@openssl.org> On 27/05/16 13:23, counterpoint wrote: > Thanks for the comments, Matt. > >> read_ahead and SSL_pending() do not play nicely together unfortunately. >> See the master (1.1.0) version of the SSL_pending() documentation which >> discusses this issue and introduced the new function SSL_has_pending() >> which addresses it: > >> https://www.openssl.org/docs/manmaster/ssl/SSL_pending.html > > I looked at SSL_has_pending, but can't easily use it as the software needs > to build on standard distributions, as far as possible, and it isn't in e.g. > CentOS 6.5 > >> So it sounds like this is during reading of application data? Has >> SSL_accept() returned successfully, and you are now wanting to call >> SSL_read()? > > It's getting a lot further than that. The SSL_accept returns success, and a > whole series of SSL_read and SSL_write calls look to be operating fine. It > appears that most of the 500KB of data used in the test is transferred, but > (probably near the end) the process hangs. Presumably SSL_pending is > returning 0 and there are no further EPOLLIN events. Or something like > that. > > I expected that turning off read ahead would fix both server and client, but > it seems not. I've read all the configuration options I can find, but so far > haven't found a solution to the server side application. It would be interesting to know what the value of "s->s3->rbuf.left" is (where "s" is your SSL object) when it gets to this point. SSL_pending() tells you how much buffered and processed data is left that OpenSSL can provide. The above value tells you how much buffered and raw *unprocessed* data is left. If you've turned read_ahead off it should be zero. I wouldn't recommend looking at that in a production app (you won't be able to access it in 1.1.0) but for debugging purposes it would be interesting. Matt From jens.h.jensen at intel.com Fri May 27 13:49:03 2016 From: jens.h.jensen at intel.com (Jensen, Jens H) Date: Fri, 27 May 2016 13:49:03 +0000 Subject: [openssl-users] Missing EVP_aes_128_gcm() in openssl 1.0.2g Message-ID: <556A2411F4FA364EB3CB63FFCEAC8B393426F660@irsmsx105.ger.corp.intel.com> Hi, I cannot find the implementation of EVP_aes_128_gcm() in openssl-1.0.2g (2016-Mar-01). I searched all files but it's not there. Also when compiling openssl as a lib, it's missing. I can only find the header prototype of EVP_aes_128_gcm() which doesn't help much. Any idea where I can find the implementation of EVP_aes_128_gcm() ? Thanks! Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri May 27 14:07:05 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 27 May 2016 15:07:05 +0100 Subject: [openssl-users] Missing EVP_aes_128_gcm() in openssl 1.0.2g In-Reply-To: <556A2411F4FA364EB3CB63FFCEAC8B393426F660@irsmsx105.ger.corp.intel.com> References: <556A2411F4FA364EB3CB63FFCEAC8B393426F660@irsmsx105.ger.corp.intel.com> Message-ID: <57485489.9060302@openssl.org> On 27/05/16 14:49, Jensen, Jens H wrote: > Hi, > > > > I cannot find the implementation of EVP_aes_128_gcm() in openssl-1.0.2g > (2016-Mar-01). I searched all files but it?s not there. Also when > compiling openssl as a lib, it?s missing. > > > > I can only find the header prototype of EVP_aes_128_gcm() which doesn?t > help much. > > > > Any idea where I can find the implementation of EVP_aes_128_gcm() ? It's defined via a macro. crypto/evp/e_aes.c line 1602. Matt From ostradegroup at gmail.com Fri May 27 15:34:12 2016 From: ostradegroup at gmail.com (ostradegroup ostradegroup) Date: Fri, 27 May 2016 08:34:12 -0700 Subject: [openssl-users] OpenSSL shutdown timeout - Please add timeout function Message-ID: Two or more calls to ssl_shutdown() resulted in a lock. ssl_shutdown would not return for over 60 seconds or more. The server, or host, is Microsoft IIS. Could OpenSSL add a setting function to the library which will set the timeout/waketime for ssl_shutdown() (process)? Thank you. Gary Pham ostradegroup at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at black-sheep-research.com Fri May 27 14:51:34 2016 From: martin at black-sheep-research.com (counterpoint) Date: Fri, 27 May 2016 07:51:34 -0700 (MST) Subject: [openssl-users] OpenSSL non-blocking epoll hanging on data receiving In-Reply-To: <57484F0D.603@openssl.org> References: <1464282067393-66355.post@n7.nabble.com> <1464330736228-66370.post@n7.nabble.com> <57480B04.3040403@openssl.org> <1464351784734-66383.post@n7.nabble.com> <57484F0D.603@openssl.org> Message-ID: <1464360694194-66394.post@n7.nabble.com> Seems to always be zero, Matt, as it should be. This gives some idea of what is going on: Breakpoint 4, dcb_basic_read_SSL (dcb=0x7fffdc0158d0, nsingleread=0x7fffffff86fc) at /root/MaxScale/server/core/dcb.c:12181218 switch (SSL_get_error(dcb->ssl, *nsingleread))$352 = 16384Breakpoint 5, dcb_basic_read_SSL (dcb=0x7fffdc0158d0, nsingleread=0x7fffffff86fc) at /root/MaxScale/server/core/dcb.c:12221222 MXS_DEBUG("%lu [%s] Read %d bytes from dcb %p in state %s "Fri May 27 16:47:12 BST 2016$353 = "Successful SSL read"Breakpoint 1, dcb_read_SSL (dcb=0x7fffdc0158d0, head=0x7fffffff87d0) at /root/MaxScale/server/core/dcb.c:11911191 ss_dassert(gwbuf_length(*head) == (start_length + nreadtotal));$354 = 0Breakpoint 9, dcb_write (dcb=0x678ef0, queue=0x67d300) at /root/MaxScale/server/core/dcb.c:13701370 below_water = (dcb->high_water && dcb->writeqlen < dcb->high_water);Fri May 27 16:47:12 BST 2016$355 = 16384$356 = "Writing to the client" Breakpoint 4 shows the number of bytes read.Breakpoint 5 shows the case for analysis of the return code from the read.Breakpoint 1 shows the value of s->s3->rbuf.leftBreakpoint 9 shows the number of bytes being passed to the write function. -- View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-non-blocking-epoll-hanging-on-data-receiving-tp66355p66394.html Sent from the OpenSSL - User mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri May 27 16:15:35 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 27 May 2016 17:15:35 +0100 Subject: [openssl-users] OpenSSL non-blocking epoll hanging on data receiving In-Reply-To: <1464360694194-66394.post@n7.nabble.com> References: <1464282067393-66355.post@n7.nabble.com> <1464330736228-66370.post@n7.nabble.com> <57480B04.3040403@openssl.org> <1464351784734-66383.post@n7.nabble.com> <57484F0D.603@openssl.org> <1464360694194-66394.post@n7.nabble.com> Message-ID: <574872A7.2010309@openssl.org> On 27/05/16 15:51, counterpoint wrote: > Seems to always be zero, Matt, as it should be. This gives some idea of > what is going on: > > Breakpoint 4, dcb_basic_read_SSL (dcb=0x7fffdc0158d0, > nsingleread=0x7fffffff86fc) at /root/MaxScale/server/core/dcb.c:1218 > 1218 switch (SSL_get_error(dcb->ssl, *nsingleread)) > $352 = 16384 > > Breakpoint 5, dcb_basic_read_SSL (dcb=0x7fffdc0158d0, > nsingleread=0x7fffffff86fc) at /root/MaxScale/server/core/dcb.c:1222 > 1222 MXS_DEBUG("%lu [%s] Read %d bytes from dcb %p in state %s " > Fri May 27 16:47:12 BST 2016 > $353 = "Successful SSL read" > > Breakpoint 1, dcb_read_SSL (dcb=0x7fffdc0158d0, head=0x7fffffff87d0) > at /root/MaxScale/server/core/dcb.c:1191 > 1191 ss_dassert(gwbuf_length(*head) == (start_length + nreadtotal)); > $354 = 0 > > Breakpoint 9, dcb_write (dcb=0x678ef0, queue=0x67d300) > at /root/MaxScale/server/core/dcb.c:1370 > 1370 below_water = (dcb->high_water && dcb->writeqlen < dcb->high_water); > Fri May 27 16:47:12 BST 2016 > $355 = 16384 > $356 = "Writing to the client" > > Breakpoint 4 shows the number of bytes read. Breakpoint 5 shows the case > for analysis of the return code from the read. Breakpoint 1 shows the > value of s->s3->rbuf.left Breakpoint 9 shows the number of bytes being > passed to the write function. So, if I understand you correctly, s->s3->rbuf.left is always 0 (indicating that there is no unprocessed data that OpenSSL has buffered) and SSL_pending() returns 0 (indicating that OpenSSL has no processed data bufferred). And this is the point where the hang in epoll occurs? It sounds to me like OpenSSL on the server is behaving as expected. Its processed all the data it has received and sent it on to your application. This looks like either: - the client hasn't sent the data that you're expecting to receive (perhaps because of a problem on the client side) or - your server application hasn't correctly responded to something that the client sent you. Either way it looks to me like an application protocol level issue rather than an SSL/TLS level issue. So the question is what data are you waiting for from the client at this point? Does the client think it sent it? Perhaps its sitting in some buffer somewhere. You need to work out at the application protocol level what state things are in, and why the client and server are apparently out of sync with each other. Matt From martin at black-sheep-research.com Fri May 27 15:20:48 2016 From: martin at black-sheep-research.com (counterpoint) Date: Fri, 27 May 2016 08:20:48 -0700 (MST) Subject: [openssl-users] OpenSSL non-blocking epoll hanging on data receiving In-Reply-To: <574872A7.2010309@openssl.org> References: <1464282067393-66355.post@n7.nabble.com> <1464330736228-66370.post@n7.nabble.com> <57480B04.3040403@openssl.org> <1464351784734-66383.post@n7.nabble.com> <57484F0D.603@openssl.org> <1464360694194-66394.post@n7.nabble.com> <574872A7.2010309@openssl.org> Message-ID: <1464362448049-66396.post@n7.nabble.com> Thanks Matt, good points. Not easy to implement though! In the problem case, my code is the server (it is a proxy), and the standard MariaDB command line client is the client. Yes, it does look as if everything is happening as it should, except that the process stops before all the data has been handled. The client is sending a large query (about 500 KB, using "load data local infile '/root/bigdata.txt' into table upload;"). If the client is connected directly to the database, using SSL, the query runs successfully. If the client is connected through the proxy without SSL (most of the logic exactly the same), the query runs successfully. If a shorter query is chosen, it works with SSL. Looking at the data flows with Wireshark, it looks about right, but I can't see the data in detail because of the SSL :) I thought the read ahead issue would have fixed both sides, but somehow the interface to the client still doesn't work. So it's hard to find things to diagnose, leaving me scratching round for inspiration and something to change that might fix things. And ideally, I need a quick result! Such is life. -- View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-non-blocking-epoll-hanging-on-data-receiving-tp66355p66396.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From matt at openssl.org Fri May 27 16:29:18 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 27 May 2016 17:29:18 +0100 Subject: [openssl-users] OpenSSL non-blocking epoll hanging on data receiving In-Reply-To: <1464362448049-66396.post@n7.nabble.com> References: <1464282067393-66355.post@n7.nabble.com> <1464330736228-66370.post@n7.nabble.com> <57480B04.3040403@openssl.org> <1464351784734-66383.post@n7.nabble.com> <57484F0D.603@openssl.org> <1464360694194-66394.post@n7.nabble.com> <574872A7.2010309@openssl.org> <1464362448049-66396.post@n7.nabble.com> Message-ID: <574875DE.9050509@openssl.org> On 27/05/16 16:20, counterpoint wrote: > Thanks Matt, good points. Not easy to implement though! > > In the problem case, my code is the server (it is a proxy), and the standard > MariaDB command line client is the client. Yes, it does look as if > everything is happening as it should, except that the process stops before > all the data has been handled. > > The client is sending a large query (about 500 KB, using "load data local > infile '/root/bigdata.txt' into table upload;"). > > If the client is connected directly to the database, using SSL, the query > runs successfully. > > If the client is connected through the proxy without SSL (most of the logic > exactly the same), the query runs successfully. > > If a shorter query is chosen, it works with SSL. > > Looking at the data flows with Wireshark, it looks about right, but I can't > see the data in detail because of the SSL :) Perhaps using an eNULL ciphersuite might help? Matt From martin at black-sheep-research.com Fri May 27 15:28:44 2016 From: martin at black-sheep-research.com (counterpoint) Date: Fri, 27 May 2016 08:28:44 -0700 (MST) Subject: [openssl-users] OpenSSL non-blocking epoll hanging on data receiving In-Reply-To: <574875DE.9050509@openssl.org> References: <1464282067393-66355.post@n7.nabble.com> <1464330736228-66370.post@n7.nabble.com> <57480B04.3040403@openssl.org> <1464351784734-66383.post@n7.nabble.com> <57484F0D.603@openssl.org> <1464360694194-66394.post@n7.nabble.com> <574872A7.2010309@openssl.org> <1464362448049-66396.post@n7.nabble.com> <574875DE.9050509@openssl.org> Message-ID: <1464362924190-66398.post@n7.nabble.com> > Perhaps using an eNULL ciphersuite might help? > Matt Good idea, I'll give it a try. -- View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-non-blocking-epoll-hanging-on-data-receiving-tp66355p66398.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From Suman.Patro-TRN at lntebg.com Fri May 27 18:25:58 2016 From: Suman.Patro-TRN at lntebg.com (R-D intern) Date: Fri, 27 May 2016 11:25:58 -0700 (MST) Subject: [openssl-users] regarding ssl_server test In-Reply-To: <99310875-060e-47ce-5da7-257aeac526f4@wisemo.com> References: <1464280407874-66354.post@n7.nabble.com> <99310875-060e-47ce-5da7-257aeac526f4@wisemo.com> Message-ID: <1464373558816-66400.post@n7.nabble.com> Thank you so much.I tried searching for a downloadable ssl_server test source code for internal servers but couldn't get any.how could I get one? Thanks and regards, R-D Intern -- View this message in context: http://openssl.6102.n7.nabble.com/regarding-ssl-server-test-tp66354p66400.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From satya at attivonetworks.com Fri May 27 21:20:02 2016 From: satya at attivonetworks.com (Satya Das) Date: Fri, 27 May 2016 21:20:02 +0000 Subject: [openssl-users] OpenSSL/TLS /AES-GCM IV/Key uniqueness compliance with SP800-38D Section 8 Message-ID: All, We are using OpenSSL 1.0.1e/FIPS 2.0.11 on CentOS6 x86_64 and I have a question about the TLS GCM Cipher suites - Do the TLS GCM suites satisfy the requirements of Section 8 of SP 800-38D ? If I am reading the document right, the following are the requirements therein. 1) The probability that the authenticated encryption function ever will be invoked with the same IV and same key on two (or more) distinct sets of input data shall be no greater than 2-32. 2) Any GCM key that is established among its intended users shall, with high probability, be fresh. 3) The total number of invocations of the authenticated encryption function shall not exceed 232, including all IV lengths and all instances of the authenticated encryption function with the given key. TIA. -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Sat May 28 02:05:51 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 27 May 2016 22:05:51 -0400 Subject: [openssl-users] regarding ssl_server test In-Reply-To: <99310875-060e-47ce-5da7-257aeac526f4@wisemo.com> References: <1464280407874-66354.post@n7.nabble.com> <99310875-060e-47ce-5da7-257aeac526f4@wisemo.com> Message-ID: On Thu, May 26, 2016 at 5:51 PM, Jakob Bohm wrote: > On 26/05/2016 18:33, R-D intern wrote: >> >> Hello, >> I have implemented ssl for my internal server that listens over >> a >> private ip. Can anyone suggest how can I test my ssl_server? For eg. >> Qualys >> test shows the amount of ssl implementation of a server listening over >> public ip and even checks for vulnerabilities in ssl implementation. How >> can such a thing be tested for a server listening over private ip? >> Please help. Awaiting response. >> Regards, >> R-D Intern >> > > Indeed, there are many servers that cannot be reached by the > online configuration tests such as the one run by Qualsys. > > What would be really nice would be if one of the good test > suites could be downloaded and run locally on internal servers, > non-web servers, staging servers etc. to verify that > configurations are correct, or at least as good as possible. That's sslscan (http://sourceforge.net/projects/sslscan/). You need a modern fork because the original version by Ventura-Whiting and Bowman has been abandoned. The abandoned version lacks things like TLV 1.2 support and SNI support. You can find lots of forks of the original sslscan on GitHub: http://www.google.com/search?q=sslscan+site:github.com Jeff From ssawgift at 163.com Sat May 28 04:13:52 2016 From: ssawgift at 163.com (=?UTF-8?B?5p2o5pil6Zu3?=) Date: Sat, 28 May 2016 12:13:52 +0800 (CST) Subject: [openssl-users] Unable to run Configure for msys/mingw Message-ID: <2e9d4ecf.32af.154f59179de.Coremail.ssawgift@163.com> I had been always successful with Configure for last several releases. But with 1.0.2h, I am not able to run Configure correctly. Note that I am on Windows msys. Here is what I get : $ ./configure no-symlinks shared mingw Configuring for mingw ? ? no-ec_nistp_64_gcc_128 [default] ?OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) ? ? no-gmp ? ? ? ? ?[default] ?OPENSSL_NO_GMP (skip dir) ? ? no-jpake ? ? ? ?[experimental] OPENSSL_NO_JPAKE (skip dir) ? ? no-krb5 ? ? ? ? [krb5-flavor not specified] OPENSSL_NO_KRB5 ? ? no-libunbound ? [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) ? ? no-md2 ? ? ? ? ?[default] ?OPENSSL_NO_MD2 (skip dir) ? ? no-rc5 ? ? ? ? ?[default] ?OPENSSL_NO_RC5 (skip dir) ? ? no-rfc3779 ? ? ?[default] ?OPENSSL_NO_RFC3779 (skip dir) ? ? no-sctp ? ? ? ? [default] ?OPENSSL_NO_SCTP (skip dir) ? ? no-ssl-trace ? ?[default] ?OPENSSL_NO_SSL_TRACE (skip dir) ? ? no-ssl2 ? ? ? ? [default] ?OPENSSL_NO_SSL2 (skip dir) ? ? no-store ? ? ? ?[experimental] OPENSSL_NO_STORE (skip dir) ? ? no-symlinks ? ? [option] ? ? no-unit-test ? ?[default] ?OPENSSL_NO_UNIT_TEST (skip dir) ? ? no-weak-ssl-ciphers [default] ?OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) ? ? no-zlib ? ? ? ? [default] ? ? no-zlib-dynamic [default] IsMK1MF=0 CC ? ? ? ? ? ?=gcc CFLAG ? ? ? ? =-D_WINDLL -DOPENSSL_USE_APPLINK -DOPENSSL_PIC -DOPENSSL_THREADS -D_MT -DDSO_WIN32 -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM EX_LIBS ? ? ? =-lws2_32 -lgdi32 -lcrypt32 CPUID_OBJ ? ? =x86cpuid.o uplink.o uplink-x86.o BN_ASM ? ? ? ?=bn-586.o co-586.o x86-mont.o x86-gf2m.o EC_ASM ? ? ? ?= DES_ENC ? ? ? =des-586.o crypt586.o AES_ENC ? ? ? =aes-586.o vpaes-x86.o aesni-x86.o BF_ENC ? ? ? ?=bf-586.o CAST_ENC ? ? ?=c_enc.o RC4_ENC ? ? ? =rc4-586.o RC5_ENC ? ? ? =rc5-586.o MD5_OBJ_ASM ? =md5-586.o SHA1_OBJ_ASM ?=sha1-586.o sha256-586.o sha512-586.o RMD160_OBJ_ASM=rmd-586.o CMLL_ENC ? ? ?=cmll-x86.o MODES_OBJ ? ? =ghash-x86.o ENGINES_OBJ ? = PROCESSOR ? ? = RANLIB ? ? ? ?=true ARFLAGS ? ? ? = PERL ? ? ? ? ?=perl THIRTY_TWO_BIT mode DES_PTR used DES_RISC1 used DES_UNROLL used BN_LLONG mode RC4_INDEX mode RC4_CHUNK is undefined Configured for mingw. *** Because of configuration changes, you MUST do the following before *** building: ? ? ? ? make depend The configure script abruptly stops at "RC4_CHUNK is undefined", and no other error messages are given. I'm not a familiar with Shell script so I am not able to locate the bug. Need help. From matt at openssl.org Sat May 28 08:51:15 2016 From: matt at openssl.org (Matt Caswell) Date: Sat, 28 May 2016 09:51:15 +0100 Subject: [openssl-users] Unable to run Configure for msys/mingw In-Reply-To: <2e9d4ecf.32af.154f59179de.Coremail.ssawgift@163.com> References: <2e9d4ecf.32af.154f59179de.Coremail.ssawgift@163.com> Message-ID: <57495C03.9040607@openssl.org> On 28/05/16 05:13, ??? wrote: > DES_UNROLL used > BN_LLONG mode > RC4_INDEX mode > RC4_CHUNK is undefined > > > Configured for mingw. > > > *** Because of configuration changes, you MUST do the following before > *** building: > > > make depend > > The configure script abruptly stops at "RC4_CHUNK is undefined", and no other error messages are given. > > I'm not a familiar with Shell script so I am not able to locate the bug. Need help. > This looks like normal output to me (what makes you think it isn't?). Just run "make depend" and "make" as normal. Matt From ssawgift at 163.com Sat May 28 09:45:52 2016 From: ssawgift at 163.com (=?UTF-8?B?5p2o5bKR?=) Date: Sat, 28 May 2016 17:45:52 +0800 Subject: [openssl-users] Unable to run Configure for msys/mingw In-Reply-To: <57495C03.9040607@openssl.org> References: <2e9d4ecf.32af.154f59179de.Coremail.ssawgift@163.com> <57495C03.9040607@openssl.org> Message-ID: No, it's not normal. I copied the exact output, no truncation. There should be a huge amount of lines before "Configured for mingw". ? 2016/5/28 16:51, Matt Caswell ??: > > > On 28/05/16 05:13, ??? wrote: >> DES_UNROLL used >> BN_LLONG mode >> RC4_INDEX mode >> RC4_CHUNK is undefined >> >> >> Configured for mingw. >> >> >> *** Because of configuration changes, you MUST do the following before >> *** building: >> >> >> make depend >> >> The configure script abruptly stops at "RC4_CHUNK is undefined", and no other error messages are given. >> >> I'm not a familiar with Shell script so I am not able to locate the bug. Need help. >> > > This looks like normal output to me (what makes you think it isn't?). > > Just run "make depend" and "make" as normal. > > Matt > From jeremy.farrell at oracle.com Sat May 28 16:22:50 2016 From: jeremy.farrell at oracle.com (Jeremy Farrell) Date: Sat, 28 May 2016 17:22:50 +0100 Subject: [openssl-users] Unable to run Configure for msys/mingw In-Reply-To: References: <2e9d4ecf.32af.154f59179de.Coremail.ssawgift@163.com> <57495C03.9040607@openssl.org> Message-ID: <6a6a284a-06c0-b1c8-e0ec-89f5eb6083dd@oracle.com> What do you expect that huge amount of lines to say? In what ways did the subsequent make depend, build, and test stages fail? On 28/05/2016 10:45, ?? wrote: > No, it's not normal. > > I copied the exact output, no truncation. There should be a huge amount > of lines before "Configured for mingw". > > ? 2016/5/28 16:51, Matt Caswell ??: >> >> On 28/05/16 05:13, ??? wrote: >>> DES_UNROLL used >>> BN_LLONG mode >>> RC4_INDEX mode >>> RC4_CHUNK is undefined >>> >>> >>> Configured for mingw. >>> >>> >>> *** Because of configuration changes, you MUST do the following before >>> *** building: >>> >>> >>> make depend >>> >>> The configure script abruptly stops at "RC4_CHUNK is undefined", and no other error messages are given. >>> >>> I'm not a familiar with Shell script so I am not able to locate the bug. Need help. >>> >> This looks like normal output to me (what makes you think it isn't?). >> >> Just run "make depend" and "make" as normal. >> >> Matt -- J. J. Farrell Not speaking for Oracle -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Sat May 28 18:17:18 2016 From: matt at openssl.org (Matt Caswell) Date: Sat, 28 May 2016 19:17:18 +0100 Subject: [openssl-users] Unable to run Configure for msys/mingw In-Reply-To: References: <2e9d4ecf.32af.154f59179de.Coremail.ssawgift@163.com> <57495C03.9040607@openssl.org> Message-ID: <5749E0AE.7040706@openssl.org> On 28/05/16 10:45, ?? wrote: > No, it's not normal. > > I copied the exact output, no truncation. There should be a huge amount > of lines before "Configured for mingw". Well, you explicitly suppressed the symlink creation (using no-symlinks) which does normally generate a lot of output during Configure. That option should generally not be used unless you know what it does. If the symlinks are already present that you can get away with using the option and you will get the shorter Configure output that you are seeing. Matt > > ? 2016/5/28 16:51, Matt Caswell ??: >> >> >> On 28/05/16 05:13, ??? wrote: >>> DES_UNROLL used >>> BN_LLONG mode >>> RC4_INDEX mode >>> RC4_CHUNK is undefined >>> >>> >>> Configured for mingw. >>> >>> >>> *** Because of configuration changes, you MUST do the following before >>> *** building: >>> >>> >>> make depend >>> >>> The configure script abruptly stops at "RC4_CHUNK is undefined", and no other error messages are given. >>> >>> I'm not a familiar with Shell script so I am not able to locate the bug. Need help. >>> >> >> This looks like normal output to me (what makes you think it isn't?). >> >> Just run "make depend" and "make" as normal. >> >> Matt >> > From ssawgift at 163.com Sun May 29 05:54:43 2016 From: ssawgift at 163.com (=?UTF-8?B?5p2o5bKR?=) Date: Sun, 29 May 2016 13:54:43 +0800 Subject: [openssl-users] Unable to run Configure for msys/mingw In-Reply-To: <6a6a284a-06c0-b1c8-e0ec-89f5eb6083dd@oracle.com> References: <2e9d4ecf.32af.154f59179de.Coremail.ssawgift@163.com> <57495C03.9040607@openssl.org> <6a6a284a-06c0-b1c8-e0ec-89f5eb6083dd@oracle.com> Message-ID: <266d208d-a42c-3e70-41e7-ebd01bbfa3fe@163.com> Please note I'm on msys/Windows. Under Linux, the configure script runs correctly without any problems. If you have doubt I strongly recommend you try this yourself using msys. If everything is normal, the output is too short. It should contain many many lines configure tests like what I got in Linux and msys and earlier versions of openssl. Output of make: $ make making all in crypto... make[1]: Entering directory 'C:/Build/openssl-1.0.2h/crypto' make[1]: *** No rule to make target 'all'. Stop. make[1]: Leaving directory 'C:/Build/openssl-1.0.2h/crypto' Makefile:284: recipe for target 'build_crypto' failed make: *** [build_crypto] Error 1 So I guess the generated makefile is not complete. ? 2016/5/29 0:22, Jeremy Farrell ??: > What do you expect that huge amount of lines to say? > > In what ways did the subsequent make depend, build, and test stages fail? > > On 28/05/2016 10:45, ?? wrote: >> No, it's not normal. >> >> I copied the exact output, no truncation. There should be a huge amount >> of lines before "Configured for mingw". >> >> ? 2016/5/28 16:51, Matt Caswell ??: >>> >>> On 28/05/16 05:13, ??? wrote: >>>> DES_UNROLL used >>>> BN_LLONG mode >>>> RC4_INDEX mode >>>> RC4_CHUNK is undefined >>>> >>>> >>>> Configured for mingw. >>>> >>>> >>>> *** Because of configuration changes, you MUST do the following before >>>> *** building: >>>> >>>> >>>> make depend >>>> >>>> The configure script abruptly stops at "RC4_CHUNK is undefined", and no other error messages are given. >>>> >>>> I'm not a familiar with Shell script so I am not able to locate the bug. Need help. >>>> >>> This looks like normal output to me (what makes you think it isn't?). >>> >>> Just run "make depend" and "make" as normal. >>> >>> Matt > > -- > J. J. Farrell > Not speaking for Oracle > > > From ssawgift at 163.com Sun May 29 05:56:42 2016 From: ssawgift at 163.com (=?UTF-8?B?5p2o5bKR?=) Date: Sun, 29 May 2016 13:56:42 +0800 Subject: [openssl-users] Unable to run Configure for msys/mingw In-Reply-To: <5749E0AE.7040706@openssl.org> References: <2e9d4ecf.32af.154f59179de.Coremail.ssawgift@163.com> <57495C03.9040607@openssl.org> <5749E0AE.7040706@openssl.org> Message-ID: I don't quite know what symblinks does, but it did not cause problems. With version 1.0.2h, I get: $ ./configure shared mingw Configuring for mingw no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-gmp [default] OPENSSL_NO_GMP (skip dir) no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-ssl2 [default] OPENSSL_NO_SSL2 (skip dir) no-store [experimental] OPENSSL_NO_STORE (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) no-zlib [default] no-zlib-dynamic [default] IsMK1MF=0 CC =gcc CFLAG =-D_WINDLL -DOPENSSL_USE_APPLINK -DOPENSSL_PIC -DOPENSSL_THREADS -D_MT -DDSO_WIN32 -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM EX_LIBS =-lws2_32 -lgdi32 -lcrypt32 CPUID_OBJ =x86cpuid.o uplink.o uplink-x86.o BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o EC_ASM = DES_ENC =des-586.o crypt586.o AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o BF_ENC =bf-586.o CAST_ENC =c_enc.o RC4_ENC =rc4-586.o RC5_ENC =rc5-586.o MD5_OBJ_ASM =md5-586.o SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o RMD160_OBJ_ASM=rmd-586.o CMLL_ENC =cmll-x86.o MODES_OBJ =ghash-x86.o ENGINES_OBJ = PROCESSOR = RANLIB =true ARFLAGS = PERL =perl THIRTY_TWO_BIT mode DES_PTR used DES_RISC1 used DES_UNROLL used BN_LLONG mode RC4_INDEX mode RC4_CHUNK is undefined e_os2.h => include/openssl/e_os2.h making links in crypto... make[1]: Entering directory 'C:/Build/openssl-1.0.2h/crypto' make[1]: *** No rule to make target 'links'. Stop. make[1]: Leaving directory 'C:/Build/openssl-1.0.2h/crypto' Makefile:434: recipe for target 'links' failed make: *** [links] Error 1 Note again - the output is copied exactly as is without deliberate omission or truncation. ? 2016/5/29 2:17, Matt Caswell ??: > > > On 28/05/16 10:45, ?? wrote: >> No, it's not normal. >> >> I copied the exact output, no truncation. There should be a huge amount >> of lines before "Configured for mingw". > > Well, you explicitly suppressed the symlink creation (using no-symlinks) > which does normally generate a lot of output during Configure. That > option should generally not be used unless you know what it does. If the > symlinks are already present that you can get away with using the option > and you will get the shorter Configure output that you are seeing. > > Matt > > >> >> ? 2016/5/28 16:51, Matt Caswell ??: >>> >>> >>> On 28/05/16 05:13, ??? wrote: >>>> DES_UNROLL used >>>> BN_LLONG mode >>>> RC4_INDEX mode >>>> RC4_CHUNK is undefined >>>> >>>> >>>> Configured for mingw. >>>> >>>> >>>> *** Because of configuration changes, you MUST do the following before >>>> *** building: >>>> >>>> >>>> make depend >>>> >>>> The configure script abruptly stops at "RC4_CHUNK is undefined", and no other error messages are given. >>>> >>>> I'm not a familiar with Shell script so I am not able to locate the bug. Need help. >>>> >>> >>> This looks like normal output to me (what makes you think it isn't?). >>> >>> Just run "make depend" and "make" as normal. >>> >>> Matt >>> >> From matt at openssl.org Sun May 29 09:44:47 2016 From: matt at openssl.org (Matt Caswell) Date: Sun, 29 May 2016 10:44:47 +0100 Subject: [openssl-users] Unable to run Configure for msys/mingw In-Reply-To: References: <2e9d4ecf.32af.154f59179de.Coremail.ssawgift@163.com> <57495C03.9040607@openssl.org> <5749E0AE.7040706@openssl.org> Message-ID: <574ABA0F.20102@openssl.org> On 29/05/16 06:56, ?? wrote: > I don't quite know what symblinks does, but it did not cause problems. > With version 1.0.2h, I get: > > $ ./configure shared mingw > Configuring for mingw > no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 > (skip dir) > no-gmp [default] OPENSSL_NO_GMP (skip dir) > no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) > no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 > no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) > no-md2 [default] OPENSSL_NO_MD2 (skip dir) > no-rc5 [default] OPENSSL_NO_RC5 (skip dir) > no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) > no-sctp [default] OPENSSL_NO_SCTP (skip dir) > no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) > no-ssl2 [default] OPENSSL_NO_SSL2 (skip dir) > no-store [experimental] OPENSSL_NO_STORE (skip dir) > no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) > no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) > no-zlib [default] > no-zlib-dynamic [default] > IsMK1MF=0 > CC =gcc > CFLAG =-D_WINDLL -DOPENSSL_USE_APPLINK -DOPENSSL_PIC > -DOPENSSL_THREADS -D_MT -DDSO_WIN32 -DL_ENDIAN -DWIN32_LEAN_AND_MEAN > -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS > -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM > -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM > EX_LIBS =-lws2_32 -lgdi32 -lcrypt32 > CPUID_OBJ =x86cpuid.o uplink.o uplink-x86.o > BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o > EC_ASM = > DES_ENC =des-586.o crypt586.o > AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o > BF_ENC =bf-586.o > CAST_ENC =c_enc.o > RC4_ENC =rc4-586.o > RC5_ENC =rc5-586.o > MD5_OBJ_ASM =md5-586.o > SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o > RMD160_OBJ_ASM=rmd-586.o > CMLL_ENC =cmll-x86.o > MODES_OBJ =ghash-x86.o > ENGINES_OBJ = > PROCESSOR = > RANLIB =true > ARFLAGS = > PERL =perl > THIRTY_TWO_BIT mode > DES_PTR used > DES_RISC1 used > DES_UNROLL used > BN_LLONG mode > RC4_INDEX mode > RC4_CHUNK is undefined > e_os2.h => include/openssl/e_os2.h > making links in crypto... > make[1]: Entering directory 'C:/Build/openssl-1.0.2h/crypto' > make[1]: *** No rule to make target 'links'. Stop. > make[1]: Leaving directory 'C:/Build/openssl-1.0.2h/crypto' > Makefile:434: recipe for target 'links' failed > make: *** [links] Error 1 > > Note again - the output is copied exactly as is without deliberate > omission or truncation. What does "perl --version" report? Matt From ssawgift at 163.com Sun May 29 09:51:12 2016 From: ssawgift at 163.com (=?UTF-8?B?5p2o5bKR?=) Date: Sun, 29 May 2016 17:51:12 +0800 Subject: [openssl-users] Unable to run Configure for msys/mingw In-Reply-To: <574ABA0F.20102@openssl.org> References: <2e9d4ecf.32af.154f59179de.Coremail.ssawgift@163.com> <57495C03.9040607@openssl.org> <5749E0AE.7040706@openssl.org> <574ABA0F.20102@openssl.org> Message-ID: <2f322238-6341-43c7-71a2-eb9af7a4c82d@163.com> ? 2016/5/29 17:44, Matt Caswell ??: > > > On 29/05/16 06:56, ?? wrote: >> I don't quite know what symblinks does, but it did not cause problems. >> With version 1.0.2h, I get: >> >> $ ./configure shared mingw >> Configuring for mingw >> no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 >> (skip dir) >> no-gmp [default] OPENSSL_NO_GMP (skip dir) >> no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) >> no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 >> no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) >> no-md2 [default] OPENSSL_NO_MD2 (skip dir) >> no-rc5 [default] OPENSSL_NO_RC5 (skip dir) >> no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) >> no-sctp [default] OPENSSL_NO_SCTP (skip dir) >> no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) >> no-ssl2 [default] OPENSSL_NO_SSL2 (skip dir) >> no-store [experimental] OPENSSL_NO_STORE (skip dir) >> no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) >> no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) >> no-zlib [default] >> no-zlib-dynamic [default] >> IsMK1MF=0 >> CC =gcc >> CFLAG =-D_WINDLL -DOPENSSL_USE_APPLINK -DOPENSSL_PIC >> -DOPENSSL_THREADS -D_MT -DDSO_WIN32 -DL_ENDIAN -DWIN32_LEAN_AND_MEAN >> -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS >> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m >> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM >> -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM >> EX_LIBS =-lws2_32 -lgdi32 -lcrypt32 >> CPUID_OBJ =x86cpuid.o uplink.o uplink-x86.o >> BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o >> EC_ASM = >> DES_ENC =des-586.o crypt586.o >> AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o >> BF_ENC =bf-586.o >> CAST_ENC =c_enc.o >> RC4_ENC =rc4-586.o >> RC5_ENC =rc5-586.o >> MD5_OBJ_ASM =md5-586.o >> SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o >> RMD160_OBJ_ASM=rmd-586.o >> CMLL_ENC =cmll-x86.o >> MODES_OBJ =ghash-x86.o >> ENGINES_OBJ = >> PROCESSOR = >> RANLIB =true >> ARFLAGS = >> PERL =perl >> THIRTY_TWO_BIT mode >> DES_PTR used >> DES_RISC1 used >> DES_UNROLL used >> BN_LLONG mode >> RC4_INDEX mode >> RC4_CHUNK is undefined >> e_os2.h => include/openssl/e_os2.h >> making links in crypto... >> make[1]: Entering directory 'C:/Build/openssl-1.0.2h/crypto' >> make[1]: *** No rule to make target 'links'. Stop. >> make[1]: Leaving directory 'C:/Build/openssl-1.0.2h/crypto' >> Makefile:434: recipe for target 'links' failed >> make: *** [links] Error 1 >> >> Note again - the output is copied exactly as is without deliberate >> omission or truncation. > > What does "perl --version" report? > > Matt > I use Strawberry Perl: $ perl -v This is perl 5, version 24, subversion 0 (v5.24.0) built for MSWin32-x86-multi-thread-64int Copyright 1987-2016, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. From matt at openssl.org Sun May 29 10:10:29 2016 From: matt at openssl.org (Matt Caswell) Date: Sun, 29 May 2016 11:10:29 +0100 Subject: [openssl-users] Unable to run Configure for msys/mingw In-Reply-To: <2f322238-6341-43c7-71a2-eb9af7a4c82d@163.com> References: <2e9d4ecf.32af.154f59179de.Coremail.ssawgift@163.com> <57495C03.9040607@openssl.org> <5749E0AE.7040706@openssl.org> <574ABA0F.20102@openssl.org> <2f322238-6341-43c7-71a2-eb9af7a4c82d@163.com> Message-ID: <574AC015.5000009@openssl.org> On 29/05/16 10:51, ?? wrote: > ? 2016/5/29 17:44, Matt Caswell ??: >> >> >> On 29/05/16 06:56, ?? wrote: >>> I don't quite know what symblinks does, but it did not cause problems. >>> With version 1.0.2h, I get: >>> >>> $ ./configure shared mingw >>> Configuring for mingw >>> no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 >>> (skip dir) >>> no-gmp [default] OPENSSL_NO_GMP (skip dir) >>> no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) >>> no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 >>> no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) >>> no-md2 [default] OPENSSL_NO_MD2 (skip dir) >>> no-rc5 [default] OPENSSL_NO_RC5 (skip dir) >>> no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) >>> no-sctp [default] OPENSSL_NO_SCTP (skip dir) >>> no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) >>> no-ssl2 [default] OPENSSL_NO_SSL2 (skip dir) >>> no-store [experimental] OPENSSL_NO_STORE (skip dir) >>> no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) >>> no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) >>> no-zlib [default] >>> no-zlib-dynamic [default] >>> IsMK1MF=0 >>> CC =gcc >>> CFLAG =-D_WINDLL -DOPENSSL_USE_APPLINK -DOPENSSL_PIC >>> -DOPENSSL_THREADS -D_MT -DDSO_WIN32 -DL_ENDIAN -DWIN32_LEAN_AND_MEAN >>> -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS >>> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m >>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM >>> -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM >>> EX_LIBS =-lws2_32 -lgdi32 -lcrypt32 >>> CPUID_OBJ =x86cpuid.o uplink.o uplink-x86.o >>> BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o >>> EC_ASM = >>> DES_ENC =des-586.o crypt586.o >>> AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o >>> BF_ENC =bf-586.o >>> CAST_ENC =c_enc.o >>> RC4_ENC =rc4-586.o >>> RC5_ENC =rc5-586.o >>> MD5_OBJ_ASM =md5-586.o >>> SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o >>> RMD160_OBJ_ASM=rmd-586.o >>> CMLL_ENC =cmll-x86.o >>> MODES_OBJ =ghash-x86.o >>> ENGINES_OBJ = >>> PROCESSOR = >>> RANLIB =true >>> ARFLAGS = >>> PERL =perl >>> THIRTY_TWO_BIT mode >>> DES_PTR used >>> DES_RISC1 used >>> DES_UNROLL used >>> BN_LLONG mode >>> RC4_INDEX mode >>> RC4_CHUNK is undefined >>> e_os2.h => include/openssl/e_os2.h >>> making links in crypto... >>> make[1]: Entering directory 'C:/Build/openssl-1.0.2h/crypto' >>> make[1]: *** No rule to make target 'links'. Stop. >>> make[1]: Leaving directory 'C:/Build/openssl-1.0.2h/crypto' >>> Makefile:434: recipe for target 'links' failed >>> make: *** [links] Error 1 >>> >>> Note again - the output is copied exactly as is without deliberate >>> omission or truncation. >> >> What does "perl --version" report? >> >> Matt >> > I use Strawberry Perl: Please try using msys perl instead. It is recommended to use the perl that "matches" your environment - so if you use msys to build, then use msys perl. Matt > $ perl -v > > This is perl 5, version 24, subversion 0 (v5.24.0) built for > MSWin32-x86-multi-thread-64int > > Copyright 1987-2016, Larry Wall > > Perl may be copied only under the terms of either the Artistic License > or the > GNU General Public License, which may be found in the Perl 5 source kit. > > Complete documentation for Perl, including FAQ lists, should be found on > this system using "man perl" or "perldoc perl". If you have access to the > Internet, point your browser at http://www.perl.org/, the Perl Home Page. > From ssawgift at 163.com Sun May 29 10:39:01 2016 From: ssawgift at 163.com (=?UTF-8?B?5p2o5bKR?=) Date: Sun, 29 May 2016 18:39:01 +0800 Subject: [openssl-users] Unable to run Configure for msys/mingw In-Reply-To: <574AC015.5000009@openssl.org> References: <2e9d4ecf.32af.154f59179de.Coremail.ssawgift@163.com> <57495C03.9040607@openssl.org> <5749E0AE.7040706@openssl.org> <574ABA0F.20102@openssl.org> <2f322238-6341-43c7-71a2-eb9af7a4c82d@163.com> <574AC015.5000009@openssl.org> Message-ID: ? 2016/5/29 18:10, Matt Caswell ??: > > > On 29/05/16 10:51, ?? wrote: >> ? 2016/5/29 17:44, Matt Caswell ??: >>> >>> >>> On 29/05/16 06:56, ?? wrote: >>>> I don't quite know what symblinks does, but it did not cause problems. >>>> With version 1.0.2h, I get: >>>> >>>> $ ./configure shared mingw >>>> Configuring for mingw >>>> no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 >>>> (skip dir) >>>> no-gmp [default] OPENSSL_NO_GMP (skip dir) >>>> no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) >>>> no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 >>>> no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) >>>> no-md2 [default] OPENSSL_NO_MD2 (skip dir) >>>> no-rc5 [default] OPENSSL_NO_RC5 (skip dir) >>>> no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) >>>> no-sctp [default] OPENSSL_NO_SCTP (skip dir) >>>> no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) >>>> no-ssl2 [default] OPENSSL_NO_SSL2 (skip dir) >>>> no-store [experimental] OPENSSL_NO_STORE (skip dir) >>>> no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) >>>> no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) >>>> no-zlib [default] >>>> no-zlib-dynamic [default] >>>> IsMK1MF=0 >>>> CC =gcc >>>> CFLAG =-D_WINDLL -DOPENSSL_USE_APPLINK -DOPENSSL_PIC >>>> -DOPENSSL_THREADS -D_MT -DDSO_WIN32 -DL_ENDIAN -DWIN32_LEAN_AND_MEAN >>>> -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS >>>> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m >>>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM >>>> -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM >>>> EX_LIBS =-lws2_32 -lgdi32 -lcrypt32 >>>> CPUID_OBJ =x86cpuid.o uplink.o uplink-x86.o >>>> BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o >>>> EC_ASM = >>>> DES_ENC =des-586.o crypt586.o >>>> AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o >>>> BF_ENC =bf-586.o >>>> CAST_ENC =c_enc.o >>>> RC4_ENC =rc4-586.o >>>> RC5_ENC =rc5-586.o >>>> MD5_OBJ_ASM =md5-586.o >>>> SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o >>>> RMD160_OBJ_ASM=rmd-586.o >>>> CMLL_ENC =cmll-x86.o >>>> MODES_OBJ =ghash-x86.o >>>> ENGINES_OBJ = >>>> PROCESSOR = >>>> RANLIB =true >>>> ARFLAGS = >>>> PERL =perl >>>> THIRTY_TWO_BIT mode >>>> DES_PTR used >>>> DES_RISC1 used >>>> DES_UNROLL used >>>> BN_LLONG mode >>>> RC4_INDEX mode >>>> RC4_CHUNK is undefined >>>> e_os2.h => include/openssl/e_os2.h >>>> making links in crypto... >>>> make[1]: Entering directory 'C:/Build/openssl-1.0.2h/crypto' >>>> make[1]: *** No rule to make target 'links'. Stop. >>>> make[1]: Leaving directory 'C:/Build/openssl-1.0.2h/crypto' >>>> Makefile:434: recipe for target 'links' failed >>>> make: *** [links] Error 1 >>>> >>>> Note again - the output is copied exactly as is without deliberate >>>> omission or truncation. >>> >>> What does "perl --version" report? >>> >>> Matt >>> >> I use Strawberry Perl: > > Please try using msys perl instead. It is recommended to use the perl > that "matches" your environment - so if you use msys to build, then use > msys perl. > > Matt > No, msys does not provide perl itself. I have been using Strawberry Perl for years and had been successfuly building openssl for last several releases. I think the new release changed configure script in a way that breaks in msys. I want add again that the script works under Linux. BTW, are you a developer of openssl? If yes, I think you should try this yourself. I'm basically a Windows developer, I know little about Shell script; otherwise I will locate the bug myself. From matt at openssl.org Sun May 29 10:55:17 2016 From: matt at openssl.org (Matt Caswell) Date: Sun, 29 May 2016 11:55:17 +0100 Subject: [openssl-users] Unable to run Configure for msys/mingw In-Reply-To: References: <2e9d4ecf.32af.154f59179de.Coremail.ssawgift@163.com> <57495C03.9040607@openssl.org> <5749E0AE.7040706@openssl.org> <574ABA0F.20102@openssl.org> <2f322238-6341-43c7-71a2-eb9af7a4c82d@163.com> <574AC015.5000009@openssl.org> Message-ID: <574ACA95.2030909@openssl.org> On 29/05/16 11:39, ?? wrote: > > > ? 2016/5/29 18:10, Matt Caswell ??: >> >> >> On 29/05/16 10:51, ?? wrote: >>> ? 2016/5/29 17:44, Matt Caswell ??: >>>> >>>> >>>> On 29/05/16 06:56, ?? wrote: >>>>> I don't quite know what symblinks does, but it did not cause problems. >>>>> With version 1.0.2h, I get: >>>>> >>>>> $ ./configure shared mingw >>>>> Configuring for mingw >>>>> no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 >>>>> (skip dir) >>>>> no-gmp [default] OPENSSL_NO_GMP (skip dir) >>>>> no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) >>>>> no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 >>>>> no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) >>>>> no-md2 [default] OPENSSL_NO_MD2 (skip dir) >>>>> no-rc5 [default] OPENSSL_NO_RC5 (skip dir) >>>>> no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) >>>>> no-sctp [default] OPENSSL_NO_SCTP (skip dir) >>>>> no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) >>>>> no-ssl2 [default] OPENSSL_NO_SSL2 (skip dir) >>>>> no-store [experimental] OPENSSL_NO_STORE (skip dir) >>>>> no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) >>>>> no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) >>>>> no-zlib [default] >>>>> no-zlib-dynamic [default] >>>>> IsMK1MF=0 >>>>> CC =gcc >>>>> CFLAG =-D_WINDLL -DOPENSSL_USE_APPLINK -DOPENSSL_PIC >>>>> -DOPENSSL_THREADS -D_MT -DDSO_WIN32 -DL_ENDIAN -DWIN32_LEAN_AND_MEAN >>>>> -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS >>>>> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m >>>>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM >>>>> -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM >>>>> EX_LIBS =-lws2_32 -lgdi32 -lcrypt32 >>>>> CPUID_OBJ =x86cpuid.o uplink.o uplink-x86.o >>>>> BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o >>>>> EC_ASM = >>>>> DES_ENC =des-586.o crypt586.o >>>>> AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o >>>>> BF_ENC =bf-586.o >>>>> CAST_ENC =c_enc.o >>>>> RC4_ENC =rc4-586.o >>>>> RC5_ENC =rc5-586.o >>>>> MD5_OBJ_ASM =md5-586.o >>>>> SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o >>>>> RMD160_OBJ_ASM=rmd-586.o >>>>> CMLL_ENC =cmll-x86.o >>>>> MODES_OBJ =ghash-x86.o >>>>> ENGINES_OBJ = >>>>> PROCESSOR = >>>>> RANLIB =true >>>>> ARFLAGS = >>>>> PERL =perl >>>>> THIRTY_TWO_BIT mode >>>>> DES_PTR used >>>>> DES_RISC1 used >>>>> DES_UNROLL used >>>>> BN_LLONG mode >>>>> RC4_INDEX mode >>>>> RC4_CHUNK is undefined >>>>> e_os2.h => include/openssl/e_os2.h >>>>> making links in crypto... >>>>> make[1]: Entering directory 'C:/Build/openssl-1.0.2h/crypto' >>>>> make[1]: *** No rule to make target 'links'. Stop. >>>>> make[1]: Leaving directory 'C:/Build/openssl-1.0.2h/crypto' >>>>> Makefile:434: recipe for target 'links' failed >>>>> make: *** [links] Error 1 >>>>> >>>>> Note again - the output is copied exactly as is without deliberate >>>>> omission or truncation. >>>> >>>> What does "perl --version" report? >>>> >>>> Matt >>>> >>> I use Strawberry Perl: >> >> Please try using msys perl instead. It is recommended to use the perl >> that "matches" your environment - so if you use msys to build, then use >> msys perl. >> >> Matt >> > No, msys does not provide perl itself. I have been using Strawberry Perl > for years and had been successfuly building openssl for last several > releases. I think the new release changed configure script in a way that > breaks in msys. I want add again that the script works under Linux. > Yes it does. Here is my version: $ perl --version This is perl 5, version 22, subversion 1 (v5.22.1) built for x86_64-msys-thread-multi Copyright 1987-2015, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. $ which perl /usr/bin/perl As you can see this is the msys version: "x86_64-msys-thread-multi" > BTW, are you a developer of openssl? If yes, I think you should try this > yourself. I'm basically a Windows developer, I know little about Shell > script; otherwise I will locate the bug myself. > Yes I am and I have tried it. It works perfectly for me. Please try installing msys perl (I don't use msys a lot but I think the command is "pacman -S perl") Matt From ssawgift at 163.com Sun May 29 11:13:32 2016 From: ssawgift at 163.com (=?UTF-8?B?5p2o5bKR?=) Date: Sun, 29 May 2016 19:13:32 +0800 Subject: [openssl-users] Unable to run Configure for msys/mingw In-Reply-To: <574ACA95.2030909@openssl.org> References: <2e9d4ecf.32af.154f59179de.Coremail.ssawgift@163.com> <57495C03.9040607@openssl.org> <5749E0AE.7040706@openssl.org> <574ABA0F.20102@openssl.org> <2f322238-6341-43c7-71a2-eb9af7a4c82d@163.com> <574AC015.5000009@openssl.org> <574ACA95.2030909@openssl.org> Message-ID: <699db076-001a-2f1b-0519-05ffd0e73256@163.com> ? 2016/5/29 18:55, Matt Caswell ??: > > > On 29/05/16 11:39, ?? wrote: >> >> >> ? 2016/5/29 18:10, Matt Caswell ??: >>> >>> >>> On 29/05/16 10:51, ?? wrote: >>>> ? 2016/5/29 17:44, Matt Caswell ??: >>>>> >>>>> >>>>> On 29/05/16 06:56, ?? wrote: >>>>>> I don't quite know what symblinks does, but it did not cause problems. >>>>>> With version 1.0.2h, I get: >>>>>> >>>>>> $ ./configure shared mingw >>>>>> Configuring for mingw >>>>>> no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 >>>>>> (skip dir) >>>>>> no-gmp [default] OPENSSL_NO_GMP (skip dir) >>>>>> no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) >>>>>> no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 >>>>>> no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) >>>>>> no-md2 [default] OPENSSL_NO_MD2 (skip dir) >>>>>> no-rc5 [default] OPENSSL_NO_RC5 (skip dir) >>>>>> no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) >>>>>> no-sctp [default] OPENSSL_NO_SCTP (skip dir) >>>>>> no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) >>>>>> no-ssl2 [default] OPENSSL_NO_SSL2 (skip dir) >>>>>> no-store [experimental] OPENSSL_NO_STORE (skip dir) >>>>>> no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) >>>>>> no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) >>>>>> no-zlib [default] >>>>>> no-zlib-dynamic [default] >>>>>> IsMK1MF=0 >>>>>> CC =gcc >>>>>> CFLAG =-D_WINDLL -DOPENSSL_USE_APPLINK -DOPENSSL_PIC >>>>>> -DOPENSSL_THREADS -D_MT -DDSO_WIN32 -DL_ENDIAN -DWIN32_LEAN_AND_MEAN >>>>>> -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS >>>>>> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m >>>>>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM >>>>>> -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM >>>>>> EX_LIBS =-lws2_32 -lgdi32 -lcrypt32 >>>>>> CPUID_OBJ =x86cpuid.o uplink.o uplink-x86.o >>>>>> BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o >>>>>> EC_ASM = >>>>>> DES_ENC =des-586.o crypt586.o >>>>>> AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o >>>>>> BF_ENC =bf-586.o >>>>>> CAST_ENC =c_enc.o >>>>>> RC4_ENC =rc4-586.o >>>>>> RC5_ENC =rc5-586.o >>>>>> MD5_OBJ_ASM =md5-586.o >>>>>> SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o >>>>>> RMD160_OBJ_ASM=rmd-586.o >>>>>> CMLL_ENC =cmll-x86.o >>>>>> MODES_OBJ =ghash-x86.o >>>>>> ENGINES_OBJ = >>>>>> PROCESSOR = >>>>>> RANLIB =true >>>>>> ARFLAGS = >>>>>> PERL =perl >>>>>> THIRTY_TWO_BIT mode >>>>>> DES_PTR used >>>>>> DES_RISC1 used >>>>>> DES_UNROLL used >>>>>> BN_LLONG mode >>>>>> RC4_INDEX mode >>>>>> RC4_CHUNK is undefined >>>>>> e_os2.h => include/openssl/e_os2.h >>>>>> making links in crypto... >>>>>> make[1]: Entering directory 'C:/Build/openssl-1.0.2h/crypto' >>>>>> make[1]: *** No rule to make target 'links'. Stop. >>>>>> make[1]: Leaving directory 'C:/Build/openssl-1.0.2h/crypto' >>>>>> Makefile:434: recipe for target 'links' failed >>>>>> make: *** [links] Error 1 >>>>>> >>>>>> Note again - the output is copied exactly as is without deliberate >>>>>> omission or truncation. >>>>> >>>>> What does "perl --version" report? >>>>> >>>>> Matt >>>>> >>>> I use Strawberry Perl: >>> >>> Please try using msys perl instead. It is recommended to use the perl >>> that "matches" your environment - so if you use msys to build, then use >>> msys perl. >>> >>> Matt >>> >> No, msys does not provide perl itself. I have been using Strawberry Perl >> for years and had been successfuly building openssl for last several >> releases. I think the new release changed configure script in a way that >> breaks in msys. I want add again that the script works under Linux. >> > > Yes it does. Here is my version: > > $ perl --version > > This is perl 5, version 22, subversion 1 (v5.22.1) built for > x86_64-msys-thread-multi > > Copyright 1987-2015, Larry Wall > > Perl may be copied only under the terms of either the Artistic License > or the > GNU General Public License, which may be found in the Perl 5 source kit. > > Complete documentation for Perl, including FAQ lists, should be found on > this system using "man perl" or "perldoc perl". If you have access to the > Internet, point your browser at http://www.perl.org/, the Perl Home Page. > > > $ which perl > /usr/bin/perl > > As you can see this is the msys version: "x86_64-msys-thread-multi" > >> BTW, are you a developer of openssl? If yes, I think you should try this >> yourself. I'm basically a Windows developer, I know little about Shell >> script; otherwise I will locate the bug myself. >> > > Yes I am and I have tried it. It works perfectly for me. Please try > installing msys perl (I don't use msys a lot but I think the command is > "pacman -S perl") > > Matt > > > Ah, I'm using the old classic msys: $ uname -a MINGW32_NT-6.1 VM-WIN7 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys But I also have msys2 installed, I will have a try. Thanks for your conformation. From ssawgift at 163.com Sun May 29 11:42:01 2016 From: ssawgift at 163.com (=?UTF-8?B?5p2o5bKR?=) Date: Sun, 29 May 2016 19:42:01 +0800 Subject: [openssl-users] Unable to run Configure for msys/mingw In-Reply-To: <699db076-001a-2f1b-0519-05ffd0e73256@163.com> References: <2e9d4ecf.32af.154f59179de.Coremail.ssawgift@163.com> <57495C03.9040607@openssl.org> <5749E0AE.7040706@openssl.org> <574ABA0F.20102@openssl.org> <2f322238-6341-43c7-71a2-eb9af7a4c82d@163.com> <574AC015.5000009@openssl.org> <574ACA95.2030909@openssl.org> <699db076-001a-2f1b-0519-05ffd0e73256@163.com> Message-ID: I get it compiled using msys2. It seems I should retire the old msys. ? 2016/5/29 19:13, ?? ??: > ? 2016/5/29 18:55, Matt Caswell ??: >> >> >> On 29/05/16 11:39, ?? wrote: >>> >>> >>> ? 2016/5/29 18:10, Matt Caswell ??: >>>> >>>> >>>> On 29/05/16 10:51, ?? wrote: >>>>> ? 2016/5/29 17:44, Matt Caswell ??: >>>>>> >>>>>> >>>>>> On 29/05/16 06:56, ?? wrote: >>>>>>> I don't quite know what symblinks does, but it did not cause problems. >>>>>>> With version 1.0.2h, I get: >>>>>>> >>>>>>> $ ./configure shared mingw >>>>>>> Configuring for mingw >>>>>>> no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 >>>>>>> (skip dir) >>>>>>> no-gmp [default] OPENSSL_NO_GMP (skip dir) >>>>>>> no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) >>>>>>> no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 >>>>>>> no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) >>>>>>> no-md2 [default] OPENSSL_NO_MD2 (skip dir) >>>>>>> no-rc5 [default] OPENSSL_NO_RC5 (skip dir) >>>>>>> no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) >>>>>>> no-sctp [default] OPENSSL_NO_SCTP (skip dir) >>>>>>> no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) >>>>>>> no-ssl2 [default] OPENSSL_NO_SSL2 (skip dir) >>>>>>> no-store [experimental] OPENSSL_NO_STORE (skip dir) >>>>>>> no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) >>>>>>> no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) >>>>>>> no-zlib [default] >>>>>>> no-zlib-dynamic [default] >>>>>>> IsMK1MF=0 >>>>>>> CC =gcc >>>>>>> CFLAG =-D_WINDLL -DOPENSSL_USE_APPLINK -DOPENSSL_PIC >>>>>>> -DOPENSSL_THREADS -D_MT -DDSO_WIN32 -DL_ENDIAN -DWIN32_LEAN_AND_MEAN >>>>>>> -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS >>>>>>> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m >>>>>>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM >>>>>>> -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM >>>>>>> EX_LIBS =-lws2_32 -lgdi32 -lcrypt32 >>>>>>> CPUID_OBJ =x86cpuid.o uplink.o uplink-x86.o >>>>>>> BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o >>>>>>> EC_ASM = >>>>>>> DES_ENC =des-586.o crypt586.o >>>>>>> AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o >>>>>>> BF_ENC =bf-586.o >>>>>>> CAST_ENC =c_enc.o >>>>>>> RC4_ENC =rc4-586.o >>>>>>> RC5_ENC =rc5-586.o >>>>>>> MD5_OBJ_ASM =md5-586.o >>>>>>> SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o >>>>>>> RMD160_OBJ_ASM=rmd-586.o >>>>>>> CMLL_ENC =cmll-x86.o >>>>>>> MODES_OBJ =ghash-x86.o >>>>>>> ENGINES_OBJ = >>>>>>> PROCESSOR = >>>>>>> RANLIB =true >>>>>>> ARFLAGS = >>>>>>> PERL =perl >>>>>>> THIRTY_TWO_BIT mode >>>>>>> DES_PTR used >>>>>>> DES_RISC1 used >>>>>>> DES_UNROLL used >>>>>>> BN_LLONG mode >>>>>>> RC4_INDEX mode >>>>>>> RC4_CHUNK is undefined >>>>>>> e_os2.h => include/openssl/e_os2.h >>>>>>> making links in crypto... >>>>>>> make[1]: Entering directory 'C:/Build/openssl-1.0.2h/crypto' >>>>>>> make[1]: *** No rule to make target 'links'. Stop. >>>>>>> make[1]: Leaving directory 'C:/Build/openssl-1.0.2h/crypto' >>>>>>> Makefile:434: recipe for target 'links' failed >>>>>>> make: *** [links] Error 1 >>>>>>> >>>>>>> Note again - the output is copied exactly as is without deliberate >>>>>>> omission or truncation. >>>>>> >>>>>> What does "perl --version" report? >>>>>> >>>>>> Matt >>>>>> >>>>> I use Strawberry Perl: >>>> >>>> Please try using msys perl instead. It is recommended to use the perl >>>> that "matches" your environment - so if you use msys to build, then use >>>> msys perl. >>>> >>>> Matt >>>> >>> No, msys does not provide perl itself. I have been using Strawberry Perl >>> for years and had been successfuly building openssl for last several >>> releases. I think the new release changed configure script in a way that >>> breaks in msys. I want add again that the script works under Linux. >>> >> >> Yes it does. Here is my version: >> >> $ perl --version >> >> This is perl 5, version 22, subversion 1 (v5.22.1) built for >> x86_64-msys-thread-multi >> >> Copyright 1987-2015, Larry Wall >> >> Perl may be copied only under the terms of either the Artistic License >> or the >> GNU General Public License, which may be found in the Perl 5 source kit. >> >> Complete documentation for Perl, including FAQ lists, should be found on >> this system using "man perl" or "perldoc perl". If you have access to the >> Internet, point your browser at http://www.perl.org/, the Perl Home Page. >> >> >> $ which perl >> /usr/bin/perl >> >> As you can see this is the msys version: "x86_64-msys-thread-multi" >> >>> BTW, are you a developer of openssl? If yes, I think you should try this >>> yourself. I'm basically a Windows developer, I know little about Shell >>> script; otherwise I will locate the bug myself. >>> >> >> Yes I am and I have tried it. It works perfectly for me. Please try >> installing msys perl (I don't use msys a lot but I think the command is >> "pacman -S perl") >> >> Matt >> >> >> > Ah, I'm using the old classic msys: > $ uname -a > MINGW32_NT-6.1 VM-WIN7 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys > > But I also have msys2 installed, I will have a try. > Thanks for your conformation. > From pavan.maddamsetti at gmail.com Mon May 30 00:59:06 2016 From: pavan.maddamsetti at gmail.com (Pavan Maddamsetti) Date: Sun, 29 May 2016 20:59:06 -0400 Subject: [openssl-users] Implement CBC decryption using EVP_aes_128_ecb() Message-ID: Hello all, I am attempting to solve Cryptopals Challenge 10 ( http://cryptopals.com/sets/2/challenges/10) using OpenSSL. Here's my code: ----- #include #include enum { BLKSIZ = 16 }; int main(void) { unsigned char in[BLKSIZ], out[BLKSIZ], vec[BLKSIZ], key[] = "YELLOW SUBMARINE"; int i, j; EVP_CIPHER_CTX ctx; BIO *bio, *b64, *bio_out; EVP_CIPHER_CTX_init(&ctx); EVP_CIPHER_CTX_set_padding(&ctx, BLKSIZ); EVP_DecryptInit_ex(&ctx, EVP_aes_128_ecb(), NULL, key, NULL); b64 = BIO_new(BIO_f_base64()); bio = BIO_new_fp(stdin, BIO_NOCLOSE); bio_out = BIO_new_fp(stdout, BIO_NOCLOSE); BIO_push(b64, bio); for (i = 0; i < BLKSIZ; i++) vec[i] = '\x00'; while ((i = BIO_read(b64, in, BLKSIZ)) > 0) { EVP_DecryptUpdate(&ctx, out, &j, in, i); for (i = 0; i < j; i++) { printf("\nin[%d]: %02x\nout[%d]: %02x\nvec[%d]: %02x\n", i, in[i], i, out[i], i, vec[i]); out[i] ^= vec[i]; vec[i] = in[i]; } BIO_write(bio_out, out, j); } EVP_DecryptFinal_ex(&ctx, out, &j); for (i = 0; i < j; i++) out[i] ^= vec[i]; BIO_write(bio_out, out, j); BIO_flush(bio_out); return 0; } ----- If I change the cipher type to EVP_aes_128_cbc() and remove the XOR, decryption seems to work correctly. However, as written what happens is that starting from the second block, each decrypted byte is the same as the corresponding ciphertext byte from the previous block. So when I XOR the two, I get a null byte. This means only the first 16 characters print out correctly followed by lots of '\0'. Can someone clue me in as to what is going on here? Would appreciate the help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dni.grosu at gmail.com Mon May 30 16:34:07 2016 From: dni.grosu at gmail.com (danigrosu) Date: Mon, 30 May 2016 09:34:07 -0700 (MST) Subject: [openssl-users] OpenSSL configuration file problems Message-ID: <1464626047969-66429.post@n7.nabble.com> Hi everyone. My intention is to modify the openssl.cnf file in order to add a new RSA ENGINE, dynamicaly. I have found the /etc/ssl/openssl.cnf file and after my modifications it looks like this: ######################################################## # # OpenSSL example configuration file. # This is mostly being used for generation of certificate requests. # openssl_conf = openssl_def # This definition stops the following lines choking if HOME isn't # defined. HOME = . RANDFILE = $ENV::HOME/.rnd ## other lines #----------------------------------unmodified------------------------------------- ## end of other lines ess_cert_id_chain = no # Must the ESS cert id chain be included? # (optional, default: no) [openssl_def] engines = engine_section [engine_section] foo = gpu_section [gpu_section] dynamic_path = /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/librsax_gpu.so engine_id = rsax_gpu default_algorithms = ALL init = 1 ######################################################## The problem is that if i try the command "openssl engine", it results in a "Segmentation fault (core dumped)" I am struggling with this for a while. OpenSSL 1.0.1f 6 Jan 2014, Ubuntu 14.04 Best regards, Dani Grosu -- View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-configuration-file-problems-tp66429.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From martin at black-sheep-research.com Tue May 31 07:35:20 2016 From: martin at black-sheep-research.com (counterpoint) Date: Tue, 31 May 2016 00:35:20 -0700 (MST) Subject: [openssl-users] OpenSSL non-blocking epoll hanging on data receiving In-Reply-To: <1464362924190-66398.post@n7.nabble.com> References: <1464282067393-66355.post@n7.nabble.com> <1464330736228-66370.post@n7.nabble.com> <57480B04.3040403@openssl.org> <1464351784734-66383.post@n7.nabble.com> <57484F0D.603@openssl.org> <1464360694194-66394.post@n7.nabble.com> <574872A7.2010309@openssl.org> <1464362448049-66396.post@n7.nabble.com> <574875DE.9050509@openssl.org> <1464362924190-66398.post@n7.nabble.com> Message-ID: <1464680120171-66452.post@n7.nabble.com> Fixed the problem in the end, using eNULL was useful to get the full picture. The issue my assumption that if there was data available to process (after read ahead was turned off) then SSL_pending would tell me so. But it seems that when the data extends beyond a single block (with OpenSSL imposing a 16K block size limit) it is necessary to keep reading after a successful read, as there may be more data available from the next block. I haven't seen any more positive way to know if there is data to process than simply repeatedly reading until no data is received. -- View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-non-blocking-epoll-hanging-on-data-receiving-tp66355p66452.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From jb-openssl at wisemo.com Tue May 31 15:43:26 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 31 May 2016 17:43:26 +0200 Subject: [openssl-users] OpenSSL non-blocking epoll hanging on data receiving In-Reply-To: <574875DE.9050509@openssl.org> References: <1464282067393-66355.post@n7.nabble.com> <1464330736228-66370.post@n7.nabble.com> <57480B04.3040403@openssl.org> <1464351784734-66383.post@n7.nabble.com> <57484F0D.603@openssl.org> <1464360694194-66394.post@n7.nabble.com> <574872A7.2010309@openssl.org> <1464362448049-66396.post@n7.nabble.com> <574875DE.9050509@openssl.org> Message-ID: <39adea77-e618-134c-9fb3-255dc290a64b@wisemo.com> On 27/05/2016 18:29, Matt Caswell wrote: > On 27/05/16 16:20, counterpoint wrote: >> Thanks Matt, good points. Not easy to implement though! >> >> In the problem case, my code is the server (it is a proxy), and the standard >> MariaDB command line client is the client. Yes, it does look as if >> everything is happening as it should, except that the process stops before >> all the data has been handled. >> >> The client is sending a large query (about 500 KB, using "load data local >> infile '/root/bigdata.txt' into table upload;"). >> >> If the client is connected directly to the database, using SSL, the query >> runs successfully. >> >> If the client is connected through the proxy without SSL (most of the logic >> exactly the same), the query runs successfully. >> >> If a shorter query is chosen, it works with SSL. >> >> Looking at the data flows with Wireshark, it looks about right, but I can't >> see the data in detail because of the SSL :) > Perhaps using an eNULL ciphersuite might help? > > Matt For future reference, another way is to load your private key into WireShark. This works for all but the EDH/ECDH suites that provide PFS security against enemies who steal your private key and then decrypt previously recorded TLS/SSL sessions. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at black-sheep-research.com Tue May 31 14:41:59 2016 From: martin at black-sheep-research.com (counterpoint) Date: Tue, 31 May 2016 07:41:59 -0700 (MST) Subject: [openssl-users] OpenSSL non-blocking epoll hanging on data receiving In-Reply-To: <39adea77-e618-134c-9fb3-255dc290a64b@wisemo.com> References: <1464282067393-66355.post@n7.nabble.com> <1464330736228-66370.post@n7.nabble.com> <57480B04.3040403@openssl.org> <1464351784734-66383.post@n7.nabble.com> <57484F0D.603@openssl.org> <1464360694194-66394.post@n7.nabble.com> <574872A7.2010309@openssl.org> <1464362448049-66396.post@n7.nabble.com> <574875DE.9050509@openssl.org> <39adea77-e618-134c-9fb3-255dc290a64b@wisemo.com> Message-ID: <1464705719078-66466.post@n7.nabble.com> Thanks, Jakob. I was under the impression that in my environment, Diffie Hellman key exchange would be in use, and that it would prevent the use of decryption, even with private key. Is that wrong? -- View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-non-blocking-epoll-hanging-on-data-receiving-tp66355p66466.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From udit043.ur at gmail.com Tue May 31 17:41:42 2016 From: udit043.ur at gmail.com (Udit Raikwar) Date: Tue, 31 May 2016 23:11:42 +0530 Subject: [openssl-users] ERR_error_string_n(unsigned long e, char *buf, size_t len) Message-ID: Hello, I am working on one project and i need to print the error description associated with the error number. I am using function ERR_error_string_n(unsigned long e, char *buf, size_t len); I know error code(e) is an 8 digit hexadecimal number, can i get the error description using 'strerror(int errno)' function ? Thanks -- Udit Raikwar, Jabalpur Engineering College. +91-9009875316 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue May 31 18:39:41 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 31 May 2016 20:39:41 +0200 Subject: [openssl-users] ERR_error_string_n(unsigned long e, char *buf, size_t len) In-Reply-To: References: Message-ID: On 31/05/2016 19:41, Udit Raikwar wrote: > Hello, > I am working on one project and i need to print the error description > associated with the error number. I am using function > ERR_error_string_n(unsigned long e, char *buf, size_t len); > > I know error code(e) is an 8 digit hexadecimal number, > can i get the error description using 'strerror(int errno)' function ? > Thanks No. strerror() only knows about the C runtime library errors that are reported in errno. It doesn't know the text for (or other meaning of) errors in other libraries such as OpenSSL or Zlib. That is why most such libraries (including OpenSSL) have their own error string functions that know the library specific error codes. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From chris.bare at gmail.com Tue May 31 19:46:39 2016 From: chris.bare at gmail.com (Chris Bare) Date: Tue, 31 May 2016 15:46:39 -0400 Subject: [openssl-users] Access to ECC X and Y Message-ID: Is there a public interface to access the X and Y elements of an Ecc public key? I tried: EC_KEY *ecc; BN_num_bytes (ecc->pub_key->X); but get the compiler error: error: dereferencing pointer to incomplete type ?EC_KEY {aka struct ec_key_st}? -- Chris Bare -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue May 31 19:58:43 2016 From: matt at openssl.org (Matt Caswell) Date: Tue, 31 May 2016 20:58:43 +0100 Subject: [openssl-users] Access to ECC X and Y In-Reply-To: References: Message-ID: <574DECF3.50009@openssl.org> On 31/05/16 20:46, Chris Bare wrote: > Is there a public interface to access the X and Y elements of an Ecc > public key? > I tried: > > EC_KEY *ecc; > > BN_num_bytes (ecc->pub_key->X); > > but get the compiler error: > > error: dereferencing pointer to incomplete type ?EC_KEY {aka struct > ec_key_st}? You can obtain the public key using EC_KEY_get0_public_key() and then you can access the x and y co-ords using EC_POINT_get_affine_coordinates_GFp() (or EC_POINT_get_affine_coordinates_GF2m() if using a binary curve). Matt