Re: [openssl-users] help with timestamping
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
Re: [openssl-users] Storing session in file and reusing at client side
> 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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Storing session in file and reusing at client side
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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Changing IV in EVP API?
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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Changing IV in EVP API?
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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Storing session in file and reusing at client side
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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Storing session in file and reusing at client side
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. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Are you using "TLS proxy certificates"?
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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Storing session in file and reusing at client side
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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
