Re: TLS extension servername & ssl session caching
Hi Stephen, > > Is that a bug or is OpenSSL using stateless session resumption? FF also > supports that. In that case the session cache is not used. > It is somehow related to FF 3.5.x! I tried different 3.0.x builds on windows and debian, as well as an old seamonkey 1.1.14 and it works all time as expected. On a reconnect the session could be reused and the SNI was present. With FF 3.5.1 (I tried only windows) there are problems during the handshake and it aborts (FF sents FIN). For what ever reason FF does not sent the SNI for the next handshake, which is successful. Also the session cache will be used, but the SNI info is missing. I guess this is out of the scope of openssl but maybe you have heard about problems with the newest FF and can give me a hint. Thanks Jan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
TLS extension servername & ssl session caching
Hi, I am using 098h with the non default configure option 'enable-tlsext' and have a problem with the TLS extension servername in conjunction with ssl session caching. It seems that sessions that contain the SNI extension will not be cached by openssl. (I tried with FF 351) During the handshake openssl calls the function ssl_get_prev_session (ssl/ssl_sess.c) which calls tls1_process_ticket (ssl/t1_libc). Latter sets the member tlsext_ticket_expected of the openssl object to 1. For the first handshake no session will be found and a new one will be created in ssl_get_new_session (ssl/ssl_sess.c). Here the session id will not(!) be set in case that tlsext_ticket_expected is 1. At the end of the handshake the session will not be saved in ssl_update_cache (ssl/ssl_lib.c) because the session->session_id_length is 0! Tweaking the ssl context by setting SSL_OP_NO_TICKET enables openssl to write the session in the session cache, but when searching for an existing session tls1_process_ticket returns 0, which means cache miss. The comment in the source is /* If tickets disabled indicate cache miss which will * trigger a full handshake */ Any idea how I can make openssl to cache the initial handshake and let it find the session for further requests or an explanation why theses extensions are handled this way? Thanks Jan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: PKCS7 (time.certum.pl)
Thanks! > No it means that the service is an RFC3161 time stamp which OpenSSL doesn't > currently support. You can perform limited verification of these using the > smime command line utility for example... > > openssl smime -verify -inform DER -out ts.der -in timstamp -noverify > > will verify the integrity of the timestamp though you could avoid -noverify > and include the correct CA. > > The "ts.der" file will contain details of the object being timestamped. > Bye Jan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: PKCS7 (time.certum.pl)
Hi Stephen, What exactly does it mean? Does it mean that the wrong digest was signed? If so what is with the correct digest that is also present in the pkcs7 file? Dr. Stephen Henson wrote: > > That particular failure is caused by the digest contained explicitly in the > PKCS #7 structure not matching the calculated value. > > If you do: > > openssl sha1 content > > then > > openssl asn1parse -inform DER -in sig > > You should see something like: > > 730:d=7 hl=2 l= 9 prim: OBJECT:messageDigest > 741:d=7 hl=2 l= 22 cons: SET > 743:d=8 hl=2 l= 20 prim: OCTET STRING [HEX > DUMP]:7AA2461C5ED26B8A3B7CADF3435D8A068A2C2758 > > The actual offsets at the start don't matter it's the OCTET STRING after > messageDigest which is of interest. That is the explicit message digest of the > content. > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: PKCS7 (time.certum.pl)
Hi, Dr. Stephen Henson wrote: >> $ openssl.exe smime -verify -inform DER -in sig -content >> openssl-0.9.8h.tar.gz >> -noverify -out c.tar.gz >> Verification failure >> 3776:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest >> failure:pk7_doit >> .c:948: >> 3776:error:21075069:PKCS7 routines:PKCS7_verify:signature >> failure:pk7_smime.c:31 >> 2: >> > > Try including the -binary switch. > Even with the binary switch I get the same verification failure. Is there a debug switch that shows the calculated hash? Thanks Jan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
PKCS7 (time.certum.pl)
Hi, I try to verify a signature made by time.certum.pl. This is what I did: I obtain a pkcs7 signature using wget. When I look into the binary data that will be returned I can find the given sha1 checksum, but the verification fails. 1) What did I miss? 2) How can I extract the signed attributes from the pkcs7 data? $ openssl sha1 openssl-0.9.8h.tar.gz SHA1(openssl-0.9.8h.tar.gz)= ced4f2da24a202e01ea22bef30ebc8aee274de86 $ wget http://time.certum.pl/?sha1=ced4f2da24a202e01ea22bef30ebc8aee274de86 => `index.h...@sha1=ced4f2da24a202e01ea22bef30ebc8aee274de86' $ mv index.ht...@sha1\=ced4f2da24a202e01ea22bef30ebc8aee274de86 sig $ openssl.exe smime -verify -inform DER -in sig -content openssl-0.9.8h.tar.gz -noverify -out c.tar.gz Verification failure 3776:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest failure:pk7_doit .c:948: 3776:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:pk7_smime.c:31 2: Thanks Jan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS 1.2
Hi Stephen, thank you very much! The snapshot build compiles without these warnings. Bye Jan Dr. Stephen Henson wrote: The cause is OpenSSL doing some things which gcc 4.2 doesn't like. These have been corrected in newer versions of OpenSSL but not when the source was submitted for testing. Subsequent validations will address this issue. However... the validated source is only needed to build fipscanister.o and none of those warnings affect that. So you can use a new FIPS capable OpenSSL and link it against the test 1.2 module. For example download: ftp://ftp.openssl.org/snapshot/openssl-0.9.8-stable-SNAP-20080709.tar.gz and build shared libraries using that. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: FIPS 1.2
Hi Stephen, thank you very much! The snapshot build compiles without these warnings. Bye Jan Dr. Stephen Henson wrote: The cause is OpenSSL doing some things which gcc 4.2 doesn't like. These have been corrected in newer versions of OpenSSL but not when the source was submitted for testing. Subsequent validations will address this issue. However... the validated source is only needed to build fipscanister.o and none of those warnings affect that. So you can use a new FIPS capable OpenSSL and link it against the test 1.2 module. For example download: ftp://ftp.openssl.org/snapshot/openssl-0.9.8-stable-SNAP-20080709.tar.gz and build shared libraries using that. signature.asc Description: OpenPGP digital signature
Re: FIPS 1.2
Hi Stephen, I have downloaded ftp://ftp.openssl.org/snapshot/openssl-fips-test-1.2.0.tar.gz, extracted it and: ./config fipscanisterbuild make make install and then make clean ./config fips shared no-idea no-mdc2 --with-fipslibdir=/usr/local/ssl/fips-1.0/lib make depend make The libraries have been build and it was possible to load the libcrypto.so dynamically, to load the FIPS_mode_set function and to call it successfully (return code 1). But there are many warnings that sound dangerous. I have pasted some below. Any idea what causes this and how I can avoid it? Thanks Jan evp_pkey.c: In function ‘EVP_PKEY2PKCS8_broken’: evp_pkey.c:382: warning: function called through a non-compatible type evp_pkey.c:382: note: if this code is reached, the program will abort evp_pkey.c: In function ‘dsa_pkey2pkcs8’: evp_pkey.c:478: warning: function called through a non-compatible type evp_pkey.c:478: note: if this code is reached, the program will abort pem_all.c: In function ‘PEM_write_RSAPublicKey’: pem_all.c:240: warning: function called through a non-compatible type pem_all.c:240: note: if this code is reached, the program will abort p5_pbev2.c: In function ‘PKCS5_pbe2_set’: p5_pbev2.c:167: warning: function called through a non-compatible type p5_pbev2.c:167: note: if this code is reached, the program will abort ocsp.c:761: warning: function called through a non-compatible type ocsp.c:761: note: if this code is reached, the program will abort rmdtest.c: In function ‘main’: rmdtest.c:110: warning: dereferencing type-punned pointer will break strict-aliasing rules Dr. Stephen Henson wrote: In the case of a shared library the "application" is the shared library itself and the fipsld linking has been performed by the build process. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: FIPS 1.2
Hello Stephen, thanks for your very quick reply. 1) Can it be linked dynamically? Yes it can. 2) If I would like to link it dynamically when/where do I link the fipscanister.o? You build and install fipscanister.o from the FIPS 1.2 test source. Then obtain the 0.9.8-fips source with shared build options. This will create libcrypto with fipscanister.o included and linked in the correct manner. At an application level you just need to link against the OpenSSL shared libraries. Let's see if I understood it correctly: 1) If I want to link it dynamically the fipscanister.o is already linked into the shared object and for static linking the fipscanister.o must be linked additionally with the fipsld script, because it is not included into the libcrypto.a. 2) If I would link it static there is no difference between linking to an application, a *.so or a *.lib. Are my assumptions correct? Do you also know about the special handling of the DH-Key-Exchange algorithm? Bye Jan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
FIPS 1.2
Hello list, I am unsure how OpenSSL FIPS 1.2 can be deployed. I read that it can be linked static but also loaded dynamically, but I also read that it can only be linked static (as FIPS 1.1.2) 1) Can it be linked dynamically? 2) If I would like to link it dynamically when/where do I link the fipscanister.o? 3) Can it only be linked to binaries or is it possible to link it (static/dynamic) to a static lib (*.a) or to an shared object (*.so)? How/Where to incorporate the fips_premain.c? 4) DH-Key-Exchange: I read that it is not certified but not disabled. Is it compliant to use it or not? Why is it handled in this special way? 5) I have the UserGuide1.2 from February 2008 but it is only a draft. Is there a newer one? Thanks Jan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Questions about EC
Hi, I have problems to establish a SSL connection where the server certificate is based on an EC key. I first tried via the c-api, but I can't make it working even with the command line tool. This is what I did: xxx:~./openssl ecparam -name secp256r1 -genkey -out ecc1.pem using curve name prime256v1 instead of secp256r1 xxx:~./openssl ec -in ecc1.pem -des3 -out ecc1.key read EC key writing EC key Enter PEM pass phrase: Verifying - Enter PEM pass phrase: xxx:~./openssl req -config ./openssl.cnf -new -x509 -days 365 -key ecc1.key -out ecc1.crt Enter pass phrase for ecc1.key: You are about to be asked to enter information that will be incorporated ... xxx:~./openssl s_server -accept 1000 -cert ecc1.crt -key ecc1.key Enter pass phrase for ecc1.key: Using default temp DH parameters Using default temp ECDH parameters ACCEPT ERROR 8664:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1037: shutting down SSL CONNECTION CLOSED ACCEPT ERROR 8664:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1037: shutting down SSL CONNECTION CLOSED I can't connect via Firefox2 and also not with openssl using the s_client option. Also the pages reachable from http://ecc.fedora.redhat.com/ will not work with openssl but will work with my Firefox. xxx:~./openssl s_client -host ecc.fedora.redhat.com -port8443 CONNECTED(0003) 8682:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:580: xxx:~./openssl version OpenSSL 0.9.8h 28 May 2008 Any ideas what goes wrong? Thanks Jan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PKCS12_create returns NULL for 0.9.8.h
Hi, After applying the patch http://cvs.openssl.org/chngview?cn=17196 the problem is gone! Any ideas, what has been changed and how I can work around it? Thanks __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
PKCS12_create returns NULL for 0.9.8.h
Hello,
since the upgrade from 0.9.8g to 0.9.8h the code below to generate a PKCS12
object failed! I have observed this on linux64 (debian 3.1) and WinXP. The
parameter have not been changed and 'key' is an RSA key.
The code:
ERR_clear_error();
PKCS12 *pkcs12cont = PKCS12_create ((char*) pwd.c_str(), "id", key, cert, NULL,
0,0,0,0,0);
printf (ERR_error_string (ERR_peek_error(), NULL));
printf ("\n%s\n", ERR_error_string (ERR_peek_last_error(), NULL));
gives the output:
pkcs12cont is NULL
error:0D0BA041:asn1 encoding routines:ASN1_STRING_set:malloc failure
error:0B08A041:x509 certificate routines:X509_ATTRIBUTE_set1_data:malloc failure
Any ideas, what has been changed and how I can work around it?
Thanks
Jan
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Client Certificate requested! Or not?
Hi Stephen, Dr. Stephen Henson wrote: > > Servers can renegotate an SSL connection and request a client certificate > later. This might be due to a script or clcking on a "login" link for example. > Oh, I didn't remember this! Thanks for your quick help. Jan signature.asc Description: OpenPGP digital signature
Client Certificate requested! Or not?
Hello, When I use my browser to go to https://creditportal.bankofamerica.com/ I am redirected to a page telling me that there is something wrong with my client certificate (the fact is that I don't have one). But when I am looking at a tcp dump I cannot find that the server asks for a client certificate. When using "openssl s_client -connect creditportal.bankofamerica.com:443" I get --- No client certificate CA names sent --- What exactly does this mean? Is it: 1) The server does no ask for a client certificate 2) The server ask but did not sent a list of accepted client certificate issuers? 3) Something different My main concern is: Does the sever ask for a client certificate or is the html error message misleading? Thanks Jan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Reading server name extension
Victor Duchovni wrote: > > Download a 0.9.9 dev snapshot and see the CHANGES file: > > New functions (subject to change): > > SSL_get_servername() > SSL_get_servername_type() > SSL_set_SSL_CTX() > Thanks Victor. This seem to be what I was looking for. Do you know when 0.9.9 will be released officially? Bye Jan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Reading server name extension
Hello, can anybody explain how I can use the server name extension from the first TLS handshake message (Client Hello)? I would like to use it to return an appropriate certificate to avoid a CN mismatch. Which version of open ssl is required for this? Thanks Jan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA_padding_check_PKCS1_type_1
Hello Marek, thanks for the hint. > One workaround of this problem is to disable EDH ciphers, for example: > > $ openssl s_client -connect bshop.esprit.com:443 -cipher 'ALL:!EDH' I tried this, but got exact the same error messages! Then I looked up the cipher specs on http://www.openssl.org/docs/apps/ciphers.html and used -cipher 'ALL:!kEDH' and then I was able to connect. Where is the difference between 'ALL:!EDH' and 'ALL:!kEDH' (beside that one works and the other not) ? Bye Jan Marek Marcola wrote: > Hello, >> it seems that there are some incompatibilities out there. For some hosts >> establishing a SSL connection fails, when using openssl, but it succeeds when >> using a browser. This in one example: >> >> F:\openssl>openssl.exe s_client -connect bshop.esprit.com:443 >> Loading 'screen' into random state - done >> CONNECTED(0778) >> depth=1 /C=GB/O=Comodo Limited/OU=Comodo Trust Network/OU=Terms and >> Conditions of >> use: http://www.comodo.net/repository/OU=(c)2002 Comodo Limited/CN=Comodo >> Class 3 >> Security Services CA >> verify error:num=20:unable to get local issuer certificate >> verify return:0 >> 3056:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type >> is not >> 01:.\crypto\rsa\rsa_pk1.c:100: >> 3056:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check >> failed:.\c >> rypto\rsa\rsa_eay.c:580: >> 3056:error:1408D07B:SSL routines:SSL3_GET_KEY_EXCHANGE:bad >> signature:.\ssl\s3_cl >> nt.c:1189: >> >> >> Can anybody explain it and give me a hint how I can connect with openssl to >> that >> host? Maybe there is a compatibility switch? > After looking at packet exchange I think that in ServerKeyExchange > packet (which comes from bshop.esprit.com) there is bad signature > of DHE parameters (Ys,p,g). > In DHE server key exchange DH parameters are signed with server private > key and client should check this signature to prevent man-in-the-middle > attack. This looks like this parameters are signed with private key > that is not compatible with certificate sent to client with Certificate > packet. > One workaround of this problem is to disable EDH ciphers, for example: > > $ openssl s_client -connect bshop.esprit.com:443 -cipher 'ALL:!EDH' > > Best regards, -- Bye Jan [EMAIL PROTECTED] [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA_padding_check_PKCS1_type_1
Hello, it seems that there are some incompatibilities out there. For some hosts establishing a SSL connection fails, when using openssl, but it succeeds when using a browser. This in one example: F:\openssl>openssl.exe s_client -connect bshop.esprit.com:443 Loading 'screen' into random state - done CONNECTED(0778) depth=1 /C=GB/O=Comodo Limited/OU=Comodo Trust Network/OU=Terms and Conditions of use: http://www.comodo.net/repository/OU=(c)2002 Comodo Limited/CN=Comodo Class 3 Security Services CA verify error:num=20:unable to get local issuer certificate verify return:0 3056:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:.\crypto\rsa\rsa_pk1.c:100: 3056:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:.\c rypto\rsa\rsa_eay.c:580: 3056:error:1408D07B:SSL routines:SSL3_GET_KEY_EXCHANGE:bad signature:.\ssl\s3_cl nt.c:1189: I have seen the "RSA_padding_check_PKCS1_type_1" when verifying a CRL, too. Can anybody explain it and give me a hint how I can connect with openssl to that host? Maybe there is a compatibility switch? Thanks Jan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
