SSL Handshake difference between 0.9.8g v/s 1.0.0e
Hi, I am migrating my application from 0.9.8g to 1.0.1e and using an external session cache for ssl session renegotiation. I notice slight performance degradation when running 1.0.1e When i debug using ssldumo here is what i observe: *0.9.8g* New TCP connection #6: localhost.localdomain(59162) - localhost.localdomain(12346) 6 1 0. (0.) CSV3.1(81) Handshake ClientHello Version 3.1 random[32]= 52 d8 8a 50 53 9a 04 32 dc 38 89 93 b1 ea b2 bb 50 71 08 a4 02 44 6f 8e 12 fc cb 75 0a 64 cc b0 resume [32]= cf b7 4b 45 69 a1 72 7d cc 0f 0d 84 9d e7 c2 3d c0 e3 d8 70 06 80 02 71 71 16 9a bf da 99 2a 2d cipher suites TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA compression methods NULL 6 2 0.0011 (0.0010) SCV3.1(74) Handshake ServerHello Version 3.1 random[32]= 52 d8 8a 50 22 5b 5c db 99 15 8f 57 3a 9c 3b 9d c3 bd 9b 9b a8 3f 7d 66 a3 fd a1 4e 2f 2e 3c a6 session_id[32]= cf b7 4b 45 69 a1 72 7d cc 0f 0d 84 9d e7 c2 3d c0 e3 d8 70 06 80 02 71 71 16 9a bf da 99 2a 2d cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA compressionMethod NULL 6 3 0.0011 (0.) SCV3.1(1) ChangeCipherSpec 6 4 0.0011 (0.) SCV3.1(40) Handshake 6 5 0.0013 (0.0001) CSV3.1(1) ChangeCipherSpec 6 6 0.0013 (0.) CSV3.1(40) Handshake 6 7 0.0014 (0.0001) CSV3.1(24) application_data 6 8 0.0014 (0.) CSV3.1(960) application_data 6 9 0.0045 (0.0031) SCV3.1(24) application_data 6 10 0.0045 (0.) SCV3.1(640) application_data 6 11 0.0062 (0.0016) CSV3.1(24) Alert 6 12 0.0063 (0.) SCV3.1(24) Alert 60.0064 (0.0001) CS TCP RST *1.0.1e* New TCP connection #7: localhost.localdomain(59171) - localhost.localdomain(12346) 7 1 0. (0.) CSV3.1(94) Handshake ClientHello Version 3.1 random[32]= 52 d8 8a a9 cf 2d eb 75 51 44 f8 3e 6a 55 03 4f 5d a8 99 3e 4e ca 14 da a8 ea a0 8e 3c f0 45 48 resume [32]= cf b7 4b 45 69 a1 72 7d cc 0f 0d 84 9d e7 c2 3d c0 e3 d8 70 06 80 02 71 71 16 9a bf da 99 2a 2d cipher suites TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA Unknown value 0xff compression methods NULL 7 2 0.0017 (0.0016) SCV3.1(90) Handshake ServerHello Version 3.1 random[32]= 52 d8 8a a9 b1 12 c9 db cc 61 cf fb e5 34 b5 4b c3 54 2a f7 19 9b b9 03 e8 65 36 70 c0 a0 fc 66 session_id[32]= cf b7 4b 45 69 a1 72 7d cc 0f 0d 84 9d e7 c2 3d c0 e3 d8 70 06 80 02 71 71 16 9a bf da 99 2a 2d cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA compressionMethod NULL *7 3 0.0017 (0.) SCV3.1(1178) Handshake* * TLS_RSA_WITH_RC4_128_MD5* 7 4 0.0017 (0.) SCV3.1(1) ChangeCipherSpec 7 5 0.0017 (0.) SCV3.1(40) Handshake 7 6 0.0019 (0.0002) CSV3.1(1) ChangeCipherSpec 7 7 0.0019 (0.) CSV3.1(40) Handshake 7 8 0.0021 (0.0001) CSV3.1(24) application_data 7 9 0.0021 (0.) CSV3.1(960) application_data 7 10 0.0052 (0.0030) SCV3.1(24) application_data 7 11 0.0052 (0.) SCV3.1(640) application_data 7 12 0.0069 (0.0017) CSV3.1(24) Alert 7 13 0.0070 (0.) SCV3.1(24) Alert 70.0071 (0.) CS TCP RST I am wondering why ssldump is printing an extra handshake message with the cipher which i have not enabled in my code. Any pointers on what could be going on here? -- Rohit Bansal
Re: AES-256 using CTR mode.
Thanks Matt. On that note, do we have support for OCB mode in openssl. Where can i find the documentation for all the modes supported by openssl?? Regards, Rohit Bansal On Mon, Jan 14, 2013 at 1:16 PM, Matt Caswell fr...@baggins.org wrote: The EVP API is documented here: https://www.openssl.org/docs/crypto/EVP_EncryptInit.html# There is some example code there too. It doesn't use AES or CTR, but the principle is the same. Just replace EVP_bf_cbc() with EVP_aes_256_ctr(), and ensure you use an appropriately sized key and IV. Matt On 14 January 2013 20:44, Rohit Bansal banr...@gmail.com wrote: Thanks Matt. Is there a sample code i can look into? In my case the key is unique across different messages, so having same IV across messages should not lead me into problem Thanks, Rohit Bansal On Mon, Jan 14, 2013 at 12:22 PM, Matt Caswell fr...@baggins.org wrote: Yes, you can use CTR mode for AES-256: use the EVP interface with the EVP_CIPHER of EVP_aes_256_ctr(). However it is a fundamental requirement of CTR mode that the IV must be unique across messages. If you reuse the IV then your messages can be broken quite trivially. Therefore, if by a fixed IV, you mean that it is fixed across multiple messages then CTR mode is not suitable for you. Matt On 14 January 2013 19:25, Rohit Bansal banr...@gmail.com wrote: Hi, Can somebody help me if CTR mode is supported in openssl for AES-256 encryption? I dont want to use CBC and i have a fixed IV. Thanks, Rohit -- Rohit Bansal -- Rohit Bansal
Re: AES-256 using CTR mode.
Thanks Matt. Is there a sample code i can look into? In my case the key is unique across different messages, so having same IV across messages should not lead me into problem Thanks, Rohit Bansal On Mon, Jan 14, 2013 at 12:22 PM, Matt Caswell fr...@baggins.org wrote: Yes, you can use CTR mode for AES-256: use the EVP interface with the EVP_CIPHER of EVP_aes_256_ctr(). However it is a fundamental requirement of CTR mode that the IV must be unique across messages. If you reuse the IV then your messages can be broken quite trivially. Therefore, if by a fixed IV, you mean that it is fixed across multiple messages then CTR mode is not suitable for you. Matt On 14 January 2013 19:25, Rohit Bansal banr...@gmail.com wrote: Hi, Can somebody help me if CTR mode is supported in openssl for AES-256 encryption? I dont want to use CBC and i have a fixed IV. Thanks, Rohit -- Rohit Bansal
Re: renegotiation during a handshake failure
Thanks Jakob, Callback is a possibility but the limitation is that this callback does not have access to the filename (which can change for every client) to load all pem files. Also I do not want to read the file every time in call back. I was ablt to prototype my idea by recreating the SSL object from context and use it for SSL_Connect and SSL_accept. But unfortunately client is sending a fatal unexpected_message alert to server immediately after client hello. here is the ssl dump: New TCP connection #1: localhost.localdomain(10289) - localhost.localdomain(23037) 1 1 0.0001 (0.0001) CSV3.1(67) Handshake ClientHello Version 3.1 random[32]= 4e d8 a4 ee fd 9e be ec 58 1b 3e 16 fd a6 b2 e9 a5 fe 65 34 79 e4 65 03 81 d4 f2 b7 7a a8 ac 55 cipher suites TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_IDEA_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 compression methods NULL 1 2 0.0005 (0.0003) SCV3.1(74) Handshake ServerHello Version 3.1 random[32]= 4e d8 a4 ee a5 b1 69 b8 9a a1 e4 01 07 96 e4 a1 31 dc 7d b7 e3 01 48 4e d1 f1 21 c6 58 4e 74 ff session_id[32]= 81 98 54 07 4c 14 b2 37 d6 13 05 26 05 5f bc dd 46 5c d6 aa 9e ee 20 22 3e 13 7b 98 13 d0 30 ee cipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA compressionMethod NULL 1 3 0.0005 (0.) SCV3.1(1278) Handshake Certificate 1 4 0.0005 (0.) SCV3.1(160) Handshake CertificateRequest certificate_types rsa_sign certificate_types dss_sign certificate_types unknown value certificate_authority 30 81 8d 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 0b 30 09 06 03 55 04 08 13 02 43 61 31 11 30 0f 06 03 55 04 07 13 08 53 61 6e 20 4a 6f 73 65 31 1b 30 19 06 03 55 04 0a 13 12 50 61 79 50 61 30 1e 06 09 2a 86 48 86 f7 0d 01 09 01 16 11 70 76 6f 69 63 75 40 70 61 79 70 61 6c 2e 63 6f 6d ServerHelloDone 1 5 0.0008 (0.0003) CSV3.1(2) Alert level fatal value unknown_ca 1 6 0.0130 (0.0121) CSV3.1(67) Handshake ClientHello Version 3.1 random[32]= 4e d8 a4 ee 61 a7 5b 6c 64 89 61 fb cf 0a a2 85 65 04 40 47 23 0d 62 35 b4 59 b5 bb 2e b7 a8 22 cipher suites TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_IDEA_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 compression methods NULL *1 7 0.0130 (0.) CSV3.1(2) Alert* *level fatal* *value unexpected_message* 10.0130 (0.) CS TCP FIN 1 8 0.0131 (0.0001) SCV3.1(74) Handshake ServerHello Version 3.1 random[32]= 4e d8 a4 ee 42 58 23 7f 51 e4 c1 10 b6 9d f0 7e 25 bd 8a 95 3c e2 dd 0e 4d 3e 61 38 33 2b a9 58 session_id[32]= 5b ca 68 de 2f 18 cb 03 df 8b 23 b9 b0 19 87 7e 02 72 f7 bb e2 a5 21 6a 7e c8 a8 38 12 83 d8 fe cipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA compressionMethod NULL 1 9 0.0131 (0.) SCV3.1(1278) Handshake Certificate 1 10 0.0131 (0.) SCV3.1(160) Handshake CertificateRequest certificate_types rsa_sign certificate_types dss_sign certificate_types unknown value certificate_authority 30 81 8d 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 0b 30 09 06 03 55 04 08 13 02 43 61 31 11 30 0f 06 03 55 04 07 13 08 53 61 6e 20 4a 6f 73 65 0c 06 03 55 04 0b 13 05 49 6e 66 72 61 31 0f 30 0d 06 03 55 04 03 13 06 70 76 6f 69 63 75 31 20 30 1e 06 09 2a 86 48 86 f7 0d 01 09 01 16 11 70 76 6f 69 63 75 40 70 61 79 70 61 6c 2e 63 6f 6d ServerHelloDone Any help whatsoever to solve this will be highly appreciated. Thanks, handshak3 On Fri, Dec 2, 2011 at 3:42 AM, Jakob Bohm jb-open...@wisemo.com wrote: On 12/1/2011 6:33 PM, Rohit Bansal wrote: Hi, Let me start with a disclaimer that i am not very experienced with openssl. I have
renegotiation during a handshake failure
Hi, Let me start with a disclaimer that i am not very experienced with openssl. I have a requirement. In an enterprise all clients and servers communicate over ssl. the certs in client and server are self signed. There is one client application which talks to 100+ different services. Currently the peer verification is done using a single file containing all those self signed certs on client side. if (!SSL_CTX_load_verify_locations(context, trusted_certs_filename, NULL)) fprintf(stderr,SSL_CTX_load_verify_locations failed (file:%s), _trusted_ca_certs_filename.chars()); // client always receives a certificate from the server, and if that // certificate fails to verify, the handshake will be terminated SSL_CTX_set_verify(context, SSL_VERIFY_PEER, NULL); As the pem file in question contains 100+ certs, ssl context initialization takes a while. My task is to migrate that to using CA Path.I have a solution but also want to build a fall back mechanism I want to fallback on initializing the context with the pem file in case the cert verification fails with CA Path. At high level i see following to be done - on client handle the reason code SSL_R_CERTIFICATE_VERIFY_FAILED from SSL_connect - on server handle the reason code SSL_R_TLSV1_ALERT_UNKNOWN_CA from SSL_accept - change the ssl context to have pem file as verified certs on client side. - renegotiate ssl handshake over the same socket Does anybody of the users know of such implementation or its feasibility? Please help me to give some ways to solve this issue Regards, banro21
