Issue in retriving certificates using openssl.
Hi, This is regarding one of the issues I'm facing while using openssl. We are using openssl to retrive the server certificate to store that in the truststore to do a connect to the server. The command we run is as follows and we redirect the certificate into a file. This is then imported into our truststore before making further communication with the server. cat /dev/null | openssl s_client -connect hostname:port | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' This works in most of the cases except one where the above command hangs. In this specific case it works if I remove all the applications (This is a J2EE application server which we are trying to get the certs for). For all other channels (browser, application server command line) the server presents the certificate and we are able to use it. Only with Open SSL it hangs. Following are the logs with -msg and -debug options. CommandWithmsgoption.txt CommandWithdebugoption.txt Following are logs for the same parameters on server where this is working. workingwithdebugoption.txt workingwithmsgoption.txt Any help on this would be much appreciated. Also let me know incase you need more details. Regards, Krishna This e-mail, including any attachment(s) hereto, is intended only for the individual or entity to whom it is addressed. It may contain proprietary, confidential or privileged information or attorney work product belonging to FIL India Business Services Private Limited (FIL-IBS) or its affiliates. If you are not the intended recipient of this e-mail, or if you have otherwise received this e-mail in error, please immediately notify the sender via return e-mail and permanently delete the original mail, any print outs and any copies, including any attachments. Any dissemination, distribution, alteration or copying of this e-mail is strictly prohibited. The originator of this e-mail does not guarantee the security of this message and will not be responsible for any damages arising from any dissemination, distribution, alteration or copying of this message and/or any attachments to this message by a third party or as a result of any virus being passed on. Any comments or statements made in this are not necessarily those of FIL - IBS or any other Fidelity entity. All e-mails sent from or to FIL- IBS may be subject to our monitoring and recording procedures. bash-3.2$ cat /dev/null | openssl s_client -connect dcasit1.uk.fid-intl.com:15012 -msg CONNECTED(0003) SSL 2.0 [length 0077], CLIENT-HELLO 01 03 01 00 4e 00 00 00 20 00 00 39 00 00 38 00 00 35 00 00 16 00 00 13 00 00 0a 07 00 c0 00 00 33 00 00 32 00 00 2f 03 00 80 00 00 05 00 00 04 01 00 80 00 00 15 00 00 12 00 00 09 06 00 40 00 00 14 00 00 11 00 00 08 00 00 06 04 00 80 00 00 03 02 00 80 00 00 ff 9b 1b 20 ac fa cf 07 a1 74 87 b3 c2 a5 b8 44 b1 f3 4e 98 71 3f 84 99 4a 9e 76 0a 9e 1c 79 8f 83 TLS 1.0 Handshake [length 004a], ServerHello 02 00 00 46 03 01 4d ac 1e ef 95 87 aa 7c 31 97 99 b3 99 29 67 ae dd 11 72 a3 3f 85 65 5a 4e b2 8d f3 01 7b bf 77 20 4d ac 1e ef a9 47 86 50 46 c0 6f 38 7c d2 9e 4f bf d9 27 b6 f7 05 6b 00 10 5f 6d 9a 39 b4 ad ec 00 16 00 TLS 1.0 Handshake [length 0223], Certificate 0b 00 02 1f 00 02 1c 00 02 19 30 82 02 15 30 82 01 7e a0 03 02 01 02 02 04 4d 70 bc c7 30 0d 06 09 2a 86 48 86 f7 0d 01 01 05 05 00 30 4f 31 0b 30 09 06 03 55 04 06 13 02 47 42 31 1f 30 1d 06 03 55 04 0a 13 16 46 69 64 65 6c 69 74 79 20 49 6e 74 65 72 6e 61 74 69 6f 6e 61 6c 31 1f 30 1d 06 03 55 04 03 13 16 64 63 61 73 69 74 2e 75 6b 2e 66 69 64 2d 69 6e 74 6c 2e 63 6f 6d 30 1e 17 0d 31 31 30 33 30 34 31 30 31 39 35 31 5a 17 0d 32 31 30 33 30 31 31 30 31 39 35 31 5a 30 4f 31 0b 30 09 06 03 55 04 06 13 02 47 42 31 1f 30 1d 06 03 55 04 0a 13 16 46 69 64 65 6c 69 74 79 20 49 6e 74 65 72 6e 61 74 69 6f 6e 61 6c 31 1f 30 1d 06 03 55 04 03 13 16 64 63 61 73 69 74 2e 75 6b 2e 66 69 64 2d 69 6e 74 6c 2e 63 6f 6d 30 81 9f 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03 81 8d 00 30 81 89 02 81 81 00 a2 fe 46 15 d0 bf 6c 53 35 60 40 f9 7c 6e e4 fc a3 bc c3 a7 96 2c 4f 1d d0 14 2b 50 7c fb 24 e8 93 22 20 e2 cf 8a 3d 22 cd 13 12 7a dc 58 03 d6 92 35 1b 7c 74 d6 d1 97 01 35 a2 3a c9 f5 20 29 a9 7b f3 c3 a5 80 50 8a b1 8e 8c 33 bf 86 43 0b df b8 8c 1c 7f 93 18 2a 0d 64 ae 6a 9c da f0 53 a3 d6 a0 62 ce ee fe 48 44 79 02 f6 d1 8b c1 43 96 b1 3a dd c1 76 8d 29 4e 3d 8f 78 78 99 97 45 02 03 01 00 01 30 0d 06 09 2a 86 48 86 f7 0d 01 01 05 05 00 03 81 81 00 56 8e 9a d0 f8 d5 24 3a 93 19 78 ac b3 5c 30 7e 34 9e 10 8a d7 3f cb 10 70 cd 23 df 8f 27 db 6f a5 f4 32 9a 7b 24 4e 2f ac 2a 9e 57 06 f8 7a 55 73 30 13 5a ee 83 17 2e 00 15 1d 6d d9 95 f5 c9 36 19 bf a2 21 2c 1d 06 1a a6 85 f6 7e 8c f1 4b 2f f5 00 e3 ac c8 5f 59 04 21 6a b3 5d 52 d9 81 25 7e 60 55 97 95 e9 e7 52 a8 7f 19 f3 39 5b
DH session Key length
Hello, I 'd like to know the length of DH session key generated by DH_compute_key(unsigned char *key, BIGNUM *pub_key, DH *dh) . Here : http://www.openssl.org/docs/crypto/DH_generate_key.html It is said that *key* must point to *DH_size(dh)* bytes of memory. is 128 bits the default length ? how can I adjust this length according the symetric-key algorithm I use ( AES128/ICM) Thanks for your help.
RE: DH session Key length
From: owner-openssl-us...@openssl.org On Behalf Of ikuzar Sent: Monday, 18 April, 2011 11:01 I 'd like to know the length of DH session key generated by DH_compute_key(unsigned char *key, BIGNUM *pub_key, DH *dh) . Here : http://www.openssl.org/docs/crypto/DH_generate_key.html It is said that key must point to DH_size(dh) bytes of memory. is 128 bits the default length ? how can I adjust this length according the symetric-key algorithm I use ( AES128/ICM) The size of both private (x) and public (y) values in DH is the same as the size of the prime P or very nearly. If the parameters were generated with openssl commandline 'dhparam' the default size of P was 512 bits, which is probably not secure. (I know factoring thus RSA up to 700-something is broken; I haven't heard of results for discrete-log thus DH and DSA, but on my limited knowledge of number theory I think it should be about the same.) (Good) asymmetric algorithms need more bits for comparable security than (good) symmetric ones. Experts do not agree on an exact correspondence, but in (very) rough terms elliptic-curve algs are about 2x symmetric, and traditional asymmetric (RSA, DH, DSA, etc) are in the vicinity of 20x. NIST Special Publication 800-57 available under csrc.nist.gov seems to be a good reflection of reasonably current thinking. There is or at least was a few years ago an independent site with the consensus of leading academic crypto researchers, but I can't find it now. (If you don't know it, NIST = National Institute for Science and Technology is a part of the US government Department of Commerce; it was formerly NBS National Bureau of Standards.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Issue in retriving certificates using openssl.
From: owner-openssl-us...@openssl.org On Behalf Of Jayaraman, Krishna Sent: Monday, 18 April, 2011 07:31 We are using openssl to retrive the server certificate to store that in the truststore to do a connect to the server. Assuming OpenSSL client(s) this only works if server cert is selfsigned. If not, OpenSSL needs the *root* in its truststore, plus any intermediate cert(s) IF not sent by server (but servers often do), not the entity. #include usual caveats about selfsigned snip: s_client and select to file This works in most of the cases except one where the above command hangs. In this specific case it works if I remove all the applications (This is a J2EE application server which we are trying to get the certs for). For all other channels (browser, application server command line) the server presents the certificate and we are able to use it. Only with Open SSL it hangs. snip: explain log attachments s_client apparently isn't receiving the last two messages of the handshake sequence (ChangeCipherSpec and Finished). Possibly this server doesn't flush these until it has an application response to send, which presumably happens after the client sends a request. This is somewhat odd behavior, but I believe legal because CCS and Finished are officially independent per side. It might be intended as an optimization, or it might be an accident or side-effect of something else. In my experience vanilla Java SSLServerSocket/SSLSocket does finish handshake immediately. Do you know if this server is using something else, maybe SSL engine and NIO channels? You say removing the apps on the server makes it work, so clearly the server can finish the handshake. Possibly it's any app(s) or possibly it's something about your specific app(s), maybe even something intentional. If you get the cert in IE and/or Firefox, you can export from either of those to a file and put that into OpenSSL. Or you could just get a cert file from the server people. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DH session Key length
You might take a look at RFC 3526: http://tools.ietf.org/html/rfc3526 It is my understanding that the DH exponent can be significantly shorter than the modulus without compromising security. RFC 3526 is from 2003, but I haven't found anything published since then that would make me think its assertions are invalid or outdated. The paranoid tinfoil hat crowd can probably take twice the maximum bit count from section 8 (620x2=1240) and be happy. Mike On Mon, Apr 18, 2011 at 8:01 AM, ikuzar razuk...@gmail.com wrote: Hello, I 'd like to know the length of DH session key generated by DH_compute_key(unsigned char *key, BIGNUM *pub_key, DH *dh) . Here : http://www.openssl.org/docs/crypto/DH_generate_key.html It is said that key must point to DH_size(dh) bytes of memory. is 128 bits the default length ? how can I adjust this length according the symetric-key algorithm I use ( AES128/ICM) Thanks for your help. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org