Re: RedHat 8.6 libk5crypto.so.3 misses symbol EVP_KDF with openssl 1.1.1l
El día martes, noviembre 08, 2022 a las 08:26:54a. m. +0100, Tomas Mraz escribió: > Hi, > > Red Hat patches its OpenSSL implementation with some additional API > calls. That means you cannot use builds from an unpatched upstream > OpenSSL tarball in place of the system libcrypto and libssl libraries. > > The proper way is to always obtain updated system packages from your > vendor, i.e., Red Hat. Otherwise you would have to try to update the > source rpm package from RHEL with new openssl version keeping the > patches that Red Hat adds to it. That is definitely not a trivial > endeavour. > > If, for some reason, you need newer OpenSSL package for some particular > application that you install to the system, it should be possible to > keep the system openssl package untouched, install the upstream OpenSSL > package somewhere into /opt or /usr/local, and link that application > against this installation of OpenSSL. > > The primary question to ask is - why do you need to install > openssl 1.1.1l on RHEL-8.6? > > Tomas Mraz, OpenSSL Thanks for your answer and explanation. We updated all our server on SuSE Linux SLES and RedHat to openssl 1.1.1l due to an announced security problem (do not remember the CVE, perhaps you will know better). The RH 8.6 server has: # /usr/bin/openssl version OpenSSL 1.1.1k FIPS 25 Mar 2021 we use: # /usr/local/sisis-pap/bin/openssl version OpenSSL 1.1.1l 24 Aug 2021 and have linked all our application servers agains this version. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub signature.asc Description: PGP signature
RedHat 8.6 libk5crypto.so.3 misses symbol EVP_KDF with openssl 1.1.1l
Hello, We compile openssl 1.1.1l from the sources and run on RedHat 8.6 into the problem that the system shared lib /usr/lib64/libk5crypto.so.3 misses a symbol from openssl: # objdump -TC /usr/lib64/libk5crypto.so.3 | grep EVP_KDF DF *UND* OPENSSL_1_1_1b EVP_KDF_ctrl DF *UND* OPENSSL_1_1_1b EVP_KDF_CTX_new_id DF *UND* OPENSSL_1_1_1b EVP_KDF_CTX_free DF *UND* OPENSSL_1_1_1b EVP_KDF_derive # objdump -TC libssl.so.1.1 | grep EVP_KDF (nix) I checked also the sources 1.1.1l and 1.1.1s, there are a lot of 'EVP_*' symbols, but not EVP_KDF_ctrl. What is the correct way to fix this. Thanks in advance. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub signature.asc Description: PGP signature
client/server communication with OpenSSL && with passwords or passphrase
Hello, we develop a business application as client/server with TCP/IP communication and a human readable protocol, which is encrypted by OpenSSL. The servers are C-written on top of PostgreSQL on Linux, while the clients are mostly Java-written and running on Win10 PCs of the staff, talking over the network to the servers. This runs well for many years already. The clients have no key material and "trust" the server servers. How the keys are made is explained below in some older post from me. The connection establishment is from the client to the server. This only as background for the actual situation. What we now want to have is strengthen the communication in some directions: 1) Each client should have its own key for the OpenSSL. They must be built central, copied to the Win PC and installed there. 2) The usage of the key and OpenSSL communication should be protected by some passphrase (like for a SSH connection the usage of the private RSA key). Is there some usecase example or some tutorial for this, or any other hints? Thanks in advance matthias - Forwarded message from Matthias Apitz - Date: Tue, 19 Feb 2019 09:57:11 +0100 From: Matthias Apitz To: openssl-users@openssl.org Subject: understand 'openssl dhparms ' Hello, Some years ago (in 2012) I wrote an OpenSSL server, loosely based on the example sources 'openssl-examples-20020110' which nowadays still exist in https://github.com/smbutton/DataCommProject/tree/master/openssl-examples-20020110/openssl-examples-20020110 There was also some guiding available about how to create the necessary key material, which goes more or less like this: $ mkdir newca $ cd newca $ cp /usr/local/openssl/misc/CA.sh . $ ./CA.sh -newca will create a new CA. Remember the passphrase as you will need it to sign certificates. $ cp demoCA/cacert.pem ../root.pem Second step $ ./CA.sh -newreq will create a certificate and a certification request. Set the passphrase to 'password' as this is hard-coded in the examples' source code. It is important to set the [Common Name] to 'localhost'. Third step $ ./CA.sh -sign will sign your newly created certificate. Enter the password for your CA which you have defined in step 1. Fourth step $ cat newreq.pem newkey.pem newcert.pem > ../localhost.pem $ cd .. $ ln -s localhost.pem server.pem $ ln -s localhost.pem client.pem Maybe you also want to issue $ openssl dhparam 1024 -2 -out dh1024.pem -outform PEM in order to update the DH parameters. ... ---- - End forwarded message - -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub signature.asc Description: PGP signature
Re: Remove from mailing list
El día sábado, mayo 29, 2021 a las 01:02:52a. m. -0400, Amber Shepherd escribió: > Hi, > Can you please let me know what I need to do in order to unsubscribe > from this list? Look into the header lines of the mails from the list for List-Unsubscribe: matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ¡Con Cuba no te metas! «» Don't mess with Cuba! «» Leg Dich nicht mit Kuba an! http://www.cubadebate.cu/noticias/2020/12/25/en-video-con-cuba-no-te-metas/
Re: understand 'openssl dhparms ....'
El día Tuesday, February 19, 2019 a las 10:47:44AM +, Matt Caswell escribió: > > > On 19/02/2019 08:57, Matthias Apitz wrote: > > > > Two questions: > > > > 1. Why this has no input file? Shouldn't it have on, and which? The man > > page says, it would read stdin, but it doesn't do so. > > The man page in question is here: > > https://www.openssl.org/docs/man1.1.1/man1/dhparam.html > > I draw your attention to the description of the "numbits" value (i.e. 1024 in > your command line): > > ... Matt, thanks for the detailed explanation. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba instead of Nazis, to live instead of to survive.
understand 'openssl dhparms ....'
Hello, Some years ago (in 2012) I wrote an OpenSSL server, loosely based on the example sources 'openssl-examples-20020110' which nowadays still exist in https://github.com/smbutton/DataCommProject/tree/master/openssl-examples-20020110/openssl-examples-20020110 There was also some guiding available about how to create the necessary key material, which goes more or less like this: $ mkdir newca $ cd newca $ cp /usr/local/openssl/misc/CA.sh . $ ./CA.sh -newca will create a new CA. Remember the passphrase as you will need it to sign certificates. $ cp demoCA/cacert.pem ../root.pem Second step $ ./CA.sh -newreq will create a certificate and a certification request. Set the passphrase to 'password' as this is hard-coded in the examples' source code. It is important to set the [Common Name] to 'localhost'. Third step $ ./CA.sh -sign will sign your newly created certificate. Enter the password for your CA which you have defined in step 1. Fourth step $ cat newreq.pem newkey.pem newcert.pem > ../localhost.pem $ cd .. $ ln -s localhost.pem server.pem $ ln -s localhost.pem client.pem Maybe you also want to issue $ openssl dhparam 1024 -2 -out dh1024.pem -outform PEM in order to update the DH parameters. What I (today) do not understand is the last step about creating the file 'dh1024.pem' :-( Two questions: 1. Why this has no input file? Shouldn't it have on, and which? The man page says, it would read stdin, but it doesn't do so. 2. When I re-run the examples today the above command does not even produces a file 'dh1024.pem', but writes the result to stdout: openssl dhparam 1024 -2 -outform PEM -out dh1024.pem (lot of random output) ... -BEGIN DH PARAMETERS- MIGHAoGBAIc6JqvNBSGwdBBzIJQAuq+TG+ttNNYZcUv/p3/nloWGwxeCKqWt2M4x z6WsA3tVbykRw80A0Rja2y7IHZ9dGJc/guxrxUpNketeSddFzGicz6mrEafSdurd ephztXEmQ63XP4ULPlcaOXzYk6GLUXFYKVYuIHnpdcJLLRMFWZ0bAgEC -END DH PARAMETERS- How this is supposed to work? Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
[openssl-users] compiling cups-1.4.3 w/ OpenSSL 1.10 && BIO_METHOD
Hello,
Compiling cups-1.4.3 against OpenSSL 1.10 gives the following error:
...
Compiling http.c...
http.c:216: error: variable `http_bio_methods' has initializer but
incomplete type
the code in question is:
#if defined(HAVE_SSL) && defined(HAVE_LIBSSL)
/*
* BIO methods for OpenSSL...
*/
static int http_bio_write(BIO *h, const char *buf, int num);
static int http_bio_read(BIO *h, char *buf, int size);
static int http_bio_puts(BIO *h, const char *str);
static long http_bio_ctrl(BIO *h, int cmd, long arg1, void *arg2);
static int http_bio_new(BIO *h);
static int http_bio_free(BIO *data);
static BIO_METHOD http_bio_methods =
{
BIO_TYPE_SOCKET,
"http",
http_bio_write,
http_bio_read,
http_bio_puts,
NULL, /* http_bio_gets, */
http_bio_ctrl,
http_bio_new,
http_bio_free,
NULL,
};
Can I fix this somehow within the cups' code?
Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ 📱
+49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Rückruf: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
El día lunes, enero 22, 2018 a las 06:40:22a. m. +, Gladewitz, Robert via openssl-users escribió: > Gladewitz, Robert möchte die Nachricht "[openssl-users] TLS Error in > FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): > error:1417C086:SSL routines:tls_process_client_certificate:certificate verify > failed" zurückrufen. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users Nice idea recall an email which was sent to a mailing-list :-) -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ 📱 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl client v1.1.0 can not connect: handshake failure:ssl/record/rec_layer_s3.c:1385:SSL alert number 40
El día Friday, February 17, 2017 a las 09:57:39AM +, Matt Caswell escribió: > > > On 17/02/17 07:46, Matthias Apitz wrote: > > New, TLSv1/SSLv3, Cipher is DHE-DSS-AES128-GCM-SHA256 > > Your server appears to be configured with a DSA certificate. > > OpenSSL 1.1.0 made changes to the default ciphersuites that get sent. > See this CHANGES entry: > > *) Changes to the DEFAULT cipherlist: >- Prefer (EC)DHE handshakes over plain RSA. >- Prefer AEAD ciphers over legacy ciphers. >- Prefer ECDSA over RSA when both certificates are available. >- Prefer TLSv1.2 ciphers/PRF. >- Remove DSS, SEED, IDEA, CAMELLIA, and AES-CCM from the > default cipherlist. > [Emilia Käsper] > > So OpenSSL 1.1.0 does not offer any DSS based ciphersuites by default > any more. If your server only has a DSA certificate then this is going > to fail. Thanks. I have aadded more ciphers using SSL_set_cipher_list(3) and all is fine now. matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openssl client v1.1.0 can not connect: handshake failure:ssl/record/rec_layer_s3.c:1385:SSL alert number 40
Hello, We run a SSL client/server application, where the server is written in Java using jdk1.8.0_31 and the client is written in C. We prepare the update to OpenSSL 1.1.0 for the C client and are facing the problem, that not even the OpenSSL s_client can now connect to our server. It says: 4146546432:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1385:SSL alert number 40 More details below. server: written in Java, using jdk1.8.0_31 client: $ openssl version OpenSSL 1.0.2e-freebsd 3 Dec 2015 $ nohup openssl s_client -tls1_2 -connect 10.23.33.55:58076 quit $ cat nohup.out depth=0 C = de, ST = Germany, L = Munich, O = unixarea.de, OU = gTech, CN = Matthias Apitz verify error:num=18:self signed certificate verify return:1 depth=0 C = de, ST = Germany, L = Munich, O = unixarea.de, OU = gTech, CN = Matthias Apitz verify return:1 CONNECTED(0004) --- Certificate chain 0 s:/C=de/ST=Germany/L=Munich/O=unixarea.de/OU=gTech/CN=Matthias Apitz i:/C=de/ST=Germany/L=Munich/O=unixarea.de/OU=gTech/CN=Matthias Apitz --- Server certificate -BEGIN CERTIFICATE- MIIDPDCCAvmgAwIBAgIEcrMKAzALBgcqhkjOOAQDBQAwbzELMAkGA1UEBhMCZGUx ... -END CERTIFICATE- subject=/C=de/ST=Germany/L=Munich/O=unixarea.de/OU=gTech/CN=Matthias Apitz issuer=/C=de/ST=Germany/L=Munich/O=unixarea.de/OU=gTech/CN=Matthias Apitz --- No client certificate CA names sent Peer signing digest: SHA1 Server Temp Key: DH, 1024 bits --- SSL handshake has read 1427 bytes and written 507 bytes --- New, TLSv1/SSLv3, Cipher is DHE-DSS-AES128-GCM-SHA256 Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher: DHE-DSS-AES128-GCM-SHA256 Session-ID: 58A69B4328BCDD246B3C2B1D7B600273AF8ACC16DE91EBB94980B1909D1D17C8 Session-ID-ctx: Master-Key: 78F0BA616EE9DBFF8BDF4A294DA70494979CBE9761185228A056C07DEC9EEBC8D126D14A27F1FDA55D4AA42DFB29E684 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1487313732 Timeout : 7200 (sec) Verify return code: 18 (self signed certificate) --- OK - message received closed client: $ /usr/local/sisis-pap/bin/openssl version OpenSSL 1.1.0d 26 Jan 2017 $ /usr/local/sisis-pap/bin/openssl s_client -connect 10.23.33.55:58076 CONNECTED(0003) 4146546432:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1385:SSL alert number 40 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 176 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher: Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1487313886 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] CVE-2016-2180
El d�a Friday, September 16, 2016 a las 08:57:30AM +0100, Matt Caswell escribi�: > >> int OBJ_obj2txt(char *buf, int buf_len, const ASN1_OBJECT *a, int no_name); > >> > >> OBJ_obj2txt() converts the ASN1_OBJECT a into a textual representation. The > >> representation is written as a null terminated string to buf at most > >> buf_len > >> bytes are written, truncating the result if necessary.* The total amount of > >> space required is returned*. If no_name is 0 then if the object has a long > >> or short name then that will be used, otherwise the numerical form will be > >> used. If no_name is 1 then the numerical form will always be used. > >> > >> Above statement statement saying that *amount of space required is > >> returned*. > > > > I saw this, but 'amount of space required' is IMHO vague, I'd expect > > 'the length of the resulting string is returned' > > That is the heart of the problem. OBJ_obj2txt() does not return what you > might expect. The author of TS_OBJ_print_bio() expected it to return the > length of the resulting string (as you do). However OBJ_obj2txt() might > truncate what it would otherwise produce if the supplied buffer isn't > big enough - but it still returns the length of the untruncated string. > > ... I would even suggest to change the wording in the man page to: "... representation is written as a null terminated string to buf at most buf_len bytes are written, INCLUDING THE NULL BYTE, truncating the result ..." -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-176-38902045 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] CVE-2016-2180
El día Thursday, September 15, 2016 a las 10:35:34PM -0700, sivagopiraju escribió: > int OBJ_obj2txt(char *buf, int buf_len, const ASN1_OBJECT *a, int no_name); > > OBJ_obj2txt() converts the ASN1_OBJECT a into a textual representation. The > representation is written as a null terminated string to buf at most buf_len > bytes are written, truncating the result if necessary.* The total amount of > space required is returned*. If no_name is 0 then if the object has a long > or short name then that will be used, otherwise the numerical form will be > used. If no_name is 1 then the numerical form will always be used. > > Above statement statement saying that *amount of space required is > returned*. I saw this, but 'amount of space required' is IMHO vague, I'd expect 'the length of the resulting string is returned' matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 "Ohne die Mauer hätte es Krieg gegeben" Fritz Streletz u.a. "Sin el Muro hubiese habido guerra." -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] CVE-2016-2180
El día Thursday, September 15, 2016 a las 09:00:07PM -0700, sivagopiraju escribió: > - int len = OBJ_obj2txt(obj_txt, sizeof(obj_txt), obj, 0); > -BIO_write(bio, obj_txt, len); > -BIO_write(bio, "\n", 1); > +OBJ_obj2txt(obj_txt, sizeof(obj_txt), obj, 0); > +BIO_printf(bio, "%s\n", obj_txt); > > Here, used BIO_printf instead of BIO_write, is it solve the issue? > > Can you please elaborate it, did't understand the solution. The man page for OBJ_obj2txt() says what the function is doing and what the parms are used for or must be, but does not specify what its return value is, only that it is 'int'. Maybe it does not return the length of the resulting string. matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 "Ohne die Mauer hätte es Krieg gegeben" Fritz Streletz u.a. "Sin el Muro hubiese habido guerra." -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] libssl.so.1.0.0 -> Java1.6 net.ssl gives: dh key too small:s3_clnt.c:3617:
Hello, We have a C written OpenSSL application which talks to a server written in Java1.6. The client side (i.e. OpenSSL) rejects connecting with the error: 25.08.2016-10:58:06 Error - SSL_connect() returned:<-1> - connection failed 25.08.2016-10:58:06 SSL_get_error() returned SSL_ERROR_SSL, ERR_print_errors_fp(): 4087322300:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3617: I read in Don Google that is due to a stronger check in OpenSSL since somewhere in September 2015. The problem is of course with the old Java 1.6 server and does not show up when we talk to a newer version of our server runninng on Java1.8. It works also with 1.6 when I use on the C side some older shared lib libssl.so.1.0.0 from Januar 2015, i.e. it seems exactly the bug as described in https://groups.google.com/forum/#!topic/ganeti/ds0TwfroS8A : The used keystore is generated with the Java keytool. It does not help generate the keystore with Java1.8 keytool and use this in the Java1.6 server. Is there some workaround? Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: Openssl IPv6 Support
El día Wednesday, November 05, 2014 a las 10:10:26AM +0100, Marcus Meissner escribió: > On Wed, Nov 05, 2014 at 08:28:40AM +, Mody, Darshan (Darshan) wrote: > > Hi, > > > > Does Openssl support IPv6 officially?. > > AFAIK the libssl and libcrypto libraries do not use sockets at all, > these are left to the applications/libraries using them. > > So openssl does neither support ipv4 nor ipv6. Marcus, I do not fully understand your reply. Ofc, openssl is using sockets to talk over. The question is only if openssl is capable to create an IPv6 socket behind its scene or not. And it can not do this, one has to pass a created IPv6 socket to the SSL layer routines. This should be fixed. matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Openssl IPv6 Support
El día Wednesday, November 05, 2014 a las 08:28:40AM +, Mody, Darshan (Darshan) escribió: > Hi, > > Does Openssl support IPv6 officially?. > > Thanks & Regards > Darshan Hi, We are using openssl for our application servers with IPv6. It turned out that the function BIO_set_conn_hostname() (and others may be) are not capable to deal with an IPv6 IP addr (which contains colon signs). We changed our code to create the socket the normal way: /* connect to an IPv6 server */ getaddrinfo(serverIP, connport, &req, &ans); sockFd = socket(ans->ai_family, ans->ai_socktype, ans->ai_protocol); connect(sockFd, ans->ai_addr, ans->ai_addrlen); and are using the created socket to bring up SSL on it with: /* build SSL context on this socket */ ctx = SSL_CTX_new(SSLv23_client_method()); bio = BIO_new_socket(sockFd, BIO_NOCLOSE); BIO_ctrl(bio, BIO_C_SSL_MODE, 1, 0); ssl = SSL_new(ctx); SSL_set_bio(ssl, bio, bio); res = SSL_connect(ssl); This works fine with IPv4 and IPv6. HIH matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
freeing SSL related memory
Hello,
We use the below attached C-code (I stripped away any error handlings
etc.) to establish a connection to an IPv6 server, send/read some data
and shutdown the connection again. My question is if the *_free() calls
at the end are enough or if we have some memory leak not freeing enough
allocated resources? The cycle
establishSSLconnection()
sendReceiveData()
sslEnd()
is not called only once due to the nature of the remote server, without
going into these details.
Thanks in adavance for reading the code and any hints.
matthias
static int sockFd = -1;
static BIO *bio = NULL;
static SSL_CTX *ctx = NULL;
static SSL *ssl = NULL;
static BIO *buffered_bio = NULL;
static BIO *ssl_bio = NULL;
establishSSLconnection()
{
ERR_load_BIO_strings();
SSL_load_error_strings();
OpenSSL_add_ssl_algorithms();
ERR_load_crypto_strings();
ERR_load_SSL_strings();
/* connect to an IPv6 server */
getaddrinfo(serverIP, connport, &req, &ans);
sockFd = socket(ans->ai_family, ans->ai_socktype, ans->ai_protocol);
connect(sockFd, ans->ai_addr, ans->ai_addrlen);
/* build SSL context on this socket */
ctx = SSL_CTX_new(SSLv23_client_method());
bio = BIO_new_socket(sockFd, BIO_NOCLOSE);
BIO_ctrl(bio, BIO_C_SSL_MODE, 1, 0);
ssl = SSL_new(ctx);
SSL_set_bio(ssl, bio, bio);
res = SSL_connect(ssl);
buffered_bio = BIO_new(BIO_f_buffer());
ssl_bio = BIO_new(BIO_f_ssl());
BIO_set_ssl(ssl_bio, ssl, BIO_CLOSE);
BIO_push(buffered_bio, ssl_bio);
}
sendReceiveData(buf)
{
i = BIO_puts(buffered_bio, buf);
rc = BIO_flush(buffered_bio);
memset(&buf, 0, sizeof(buf));
rc = BIO_gets(buffered_bio, buf, 1024 * 10);
sslError = SSL_get_error(ssl, rc);
switch (sslError) {
...
}
}
sslEnd()
{
shutdown(sockFd, SHUT_RDWR);
close(sockFd);
sockFd = -1;
ssl_bio = NULL;
buffered_bio = NULL;
bio = NULL;
if (ctx != NULL) {
SSL_CTX_free(ctx);
ctx = NULL;
}
if (ssl != NULL) {
SSL_free(ssl);
ssl = NULL;
}
}
--
Matthias Apitz | /"\ ASCII Ribbon Campaign:
E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | X- No proprietary attachments
phone: +49-170-4527211 | / \ - Respect for open standards
| en.wikipedia.org/wiki/ASCII_Ribbon_Campaign
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
s_client to contact servers in clear and switch to SSL
Hello,
We are producing a client-server-application which makes use of SSL.
The (UNIX hosted) servers answer on connect to its port with some kind
of GoodMorning message, always in clear text, like for example
200 SLNP CATserver@version:4.3@user:sisis@ssl:true
i.e. the server says with 'ssl:true' (or ssl:false) if it now switches
for the rest of the communication to SSL (or stays in clear text). This
is for historical reasons to support also clients, which are not SSL
aware.
We can not test such server anymore with
openssl s_client -connect server:port
because the s_client does not await the clear text GM message. I would
like to do as well tests with s_client and produced a special version of
our servers (controlled by an env var on start) which do not spill out the GM
message and just start awaiting a client talking SSL. This works fine
with s_client, but I'd like to have some way to not start special servers to
test with s_client...
Any idea how to let accept s_client the clear text before using SSL?
Thanks
matthias
--
Matthias Apitz | /"\ ASCII Ribbon Campaign:
E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | X- No proprietary attachments
phone: +49-170-4527211 | / \ - Respect for open standards
| en.wikipedia.org/wiki/ASCII_Ribbon_Campaign
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
some nice pictures how the bug works: http://www.xkcd.com/1354/ HIH matthias -- Sent from my FreeBSD netbook Matthias Apitz, , http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
El día Saturday, April 12, 2014 a las 03:43:29PM -0400, Michael Smith escribió: > > On Apr 12, 2014, at 3:08 PM, Michael Tuexen > wrote: > >> > > I have read the rumor. It is wrong. > > "Introduced with intent" vs. "known to the NSA" -- two > different things, right? > > I don't have any direct knowledge of what goes on in the > NSA, but if they don't have a whole cubicle farm full > of people looking for vulnerabilities, I'd be surprised. > OpenSSL would be an obvious high-value target for scrutiny > just because of its ubiquity. and one comment more: the bug works in both directions; when a client with an openssl lib/DLL with this bug connects to a well prepared SSL server, the server can fetch up to 64 kbyte of memory from the client, for example the stored saved passwords in your browser... matthias -- Sent from my FreeBSD netbook Matthias Apitz, , http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
El día Saturday, April 12, 2014 a las 03:43:29PM -0400, Michael Smith escribió: > > On Apr 12, 2014, at 3:08 PM, Michael Tuexen > wrote: > >> > > I have read the rumor. It is wrong. > > "Introduced with intent" vs. "known to the NSA" -- two > different things, right? > > I don't have any direct knowledge of what goes on in the > NSA, but if they don't have a whole cubicle farm full > of people looking for vulnerabilities, I'd be surprised. > OpenSSL would be an obvious high-value target for scrutiny > just because of its ubiquity. agreed; and this bug wasn't hard to see (even for me, sitting in a restaurant with a netbook); in my company we do code review face to face, i.e. two persons (the coder and the reviewer) wade through the new code; one target of always questioning are copies in memory: do the amount of data fit into target location and is the source amount a valid space... matthias -- Sent from my FreeBSD netbook Matthias Apitz, , http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
El día Saturday, April 12, 2014 a las 09:30:22PM +0200, Matthias Apitz escribió:
> El día Saturday, April 12, 2014 a las 09:08:15PM +0200, Michael Tuexen
> escribió:
>
> > > What is the exact bug, can someone show a svn/git diff of the first
> > > source version having the bug?
> > http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1
> > >
>
> Hi,
>
> Thanks for the git diff (and the other statements). Could you please be
> so kind and point to the exact place of the offending statement (or
> missing boundary check) in the 19 *.[ch] files? I only want (as a C
> programmer) to get my own impression of the nature of the issue. Thanks
ah, I see it in ssl/d1_both.c, the memcpy for the payload is done
regardless if payload length and payload fit; forget my request.
Thx
matthias
--
Sent from my FreeBSD netbook
Matthias Apitz, , http://www.unixarea.de/ f: +49-170-4527211
UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370)
UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
El día Saturday, April 12, 2014 a las 09:08:15PM +0200, Michael Tuexen escribió: > > What is the exact bug, can someone show a svn/git diff of the first > > source version having the bug? > http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1 > > Hi, Thanks for the git diff (and the other statements). Could you please be so kind and point to the exact place of the offending statement (or missing boundary check) in the 19 *.[ch] files? I only want (as a C programmer) to get my own impression of the nature of the issue. Thanks matthias -- Sent from my FreeBSD netbook Matthias Apitz, , http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
El dÃa Wednesday, April 09, 2014 a las 01:05:22AM -0700, monloi perez escribió: > True. Thanks for the quick reply. > > > On Wednesday, April 9, 2014 3:33 PM, Alan Buxey > wrote: > > https://www.openssl.org/news/changelog.html > > 1.0.1 introduced the heartbeat support. > > 1.0.0 and earlier are fortunate in that they didnt have it.but then they > didnt have things to stop you from being BEASTed so some you win, some you > lose. ;) > > alan Hello, As you can read in the above change log, heartbeat support was introduced in version 1.0.1 of openssl. Does this mean that also the bug was introduced with this version in March 2012, or was it later? What is the exact bug, can someone show a svn/git diff of the first source version having the bug? Is it possible that the bug was introduced with intention (to make use of it later)? Here in Germany in the news we have rumor, that the bug was used by NSA, of course the American Goverment says no. Thanks matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
> > -Original Message- > > From: Matthias Apitz [mailto:g...@unixarea.de] > > Sent: Thursday, April 10, 2014 6:41 AM > > To: Apitz,Matthias > > Subject: Fwd: RE: OpenSSL Security Advisory > > > > - Forwarded message from "Salz, Rich" - > > > > Date: Wed, 9 Apr 2014 15:43:28 -0400 > > From: "Salz, Rich" > > To: "openssl-users@openssl.org" > > Subject: RE: OpenSSL Security Advisory > > > > > Can you please post a "good" and a "bad" server example. I have > > tested a lot of servers, including 'akamai.com', and they all show > > HEARTBEATING at the end: > > > > Look at Victor's recent post about how to patch openssl/s_client to > > make your own test. That's the simplest. My example tests only > > for those who have disabled TLs heartbeats, which is the safest > > thing, but not necessarily the only thing, to do. > > Hello, I have instrumented an openssl 1.0.1f as posted by Victor: guru@hein:~/openssl-1.0.1f> diff ssl/t1_lib.c.unpatched ssl/t1_lib.c 2671c2671 < s2n(payload, p); --- > s2n(0x4000, p); but I still see HEARTBEATING, for example even from www.openssl.org: guru@hein:~/openssl-1.0.1f/apps> (sleep 3 ; echo B ; sleep 3) | ./openssl s_client -connect www.openssl.org:443 ... HEARTBEATING DONE Do I something wrong? Thx matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
> - Forwarded message from "Salz, Rich" - > > Date: Wed, 9 Apr 2014 09:54:25 -0400 > From: "Salz, Rich" > To: "openssl-users@openssl.org" > Subject: RE: OpenSSL Security Advisory > > Ø How do I determine whether or not the web servers I run are affected? > > Here's a simple way: > echo B | openssl s_client -connect $HOST:$PORT > if you see "heartbeating" at the end, then $HOST is vulnerable. > > How can you tell if private keys have been taken? You can't, really. You can > estimate the likelihood by looking closely at how OpenSSL_Malloc() return > values are used and layed out. The risk is that an allocated ssl-record > buffer is right up against a private key being stored. > > /r$ Hello Rich, Can you please post a "good" and a "bad" server example. I have tested a lot of servers, including 'akamai.com', and they all show HEARTBEATING at the end: $ echo B | openssl s_client -connect akamai.com:https ... Verify return code: 20 (unable to get local issuer certificate) --- HEARTBEATING 675358796:error:1413B16D:SSL routines:SSL_F_TLS1_HEARTBEAT:peer does not accept heartbearts:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/t1_lib.c:2562: Thanks for clarification. matthias -- Sent from my FreeBSD netbook Matthias Apitz, , http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl && interrupted read(2) call on socket
Hello,
We use openssl im our application servers and encounter the following
problem on SunOS Solaris 5.9 on SPARC:
the used call
r = BIO_gets(slnpSSL[i].io, buf, maxlen);
sslError = SSL_get_error(slnpSSL[i].ssl, r);
switch (sslError) {
case SSL_ERROR_NONE:
len = r;
break;
default:
fprintf(stderr, "SSL_get_error: %d\n", sslError);
berr_exit("SSL read problem");
}
will fail with SSL_ERROR_WANT_READ if the read(2) call on the socket is
interrupted by SIGALRM; a truss show this like this:
read(8, 0x0032842B, 5) (sleeping...)
Received signal #14, SIGALRM, in read() [caught]
siginfo: SIG#0
read(8, 0x0032842B, 5) Err#4 EINTR
lwp_sigmask(SIG_SETMASK, 0x, 0x) = 0xFFBFFEFF
[0x]
time() = 1396594526
sigaction(SIGALRM, 0xFFBF5AE0, 0xFFBF5B80) = 0
alarm(60) = 0
setcontext(0xFFBF5F68)
fstat64(2, 0xFFBF5CF8) = 0
write(2, " S S L r e a d p r o".., 17) = 17
_exit(0)
i.e. the read(2) is not setup again by the system;
on a Linux system it is; the same code and situation look like this:
19595 10:58:24.757535 alarm(60) = 0
19595 10:58:24.757588 sigreturn() = 3
19595 10:58:24.757638 read(7, 0x810469b, 5) = ? ERESTARTSYS (To be restarted)
19595 10:59:24.757784 --- SIGALRM (Alarm clock) @ 0 (0) ---
19595 10:59:24.757966 time(NULL)= 1396601964
19595 10:59:24.758040 rt_sigaction(SIGALRM, {0x180582b4, [], 0},
{0x180582b4, [], 0}, 8) = 0
19595 10:59:24.758117 alarm(60) = 0
19595 10:59:24.758172 sigreturn() = 3
19595 10:59:24.758224 read(7, 0x810469b, 5) ...
Why is this different on Solaris and Linux?
matthias
--
Matthias Apitz | /"\ ASCII Ribbon Campaign: www.asciiribbon.org
E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | X - No proprietary attachments
phone: +49-170-4527211 | / \ - Respect for open standards
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: connecting to (openssl-) server in SSL or clear text
El día Saturday, November 16, 2013 a las 08:36:33PM -0500, Dave Thompson escribió: > > I was thinking more in a solution where the client reads the first 8 > > bytes from the socket and checks if the beginning of the GoodMorning > > message is there in clear text (like "220 SLNP") and if not > > it should handover this buffer and the socket fd for further SSL > > handshake... Is this possible? > > > Note that the server cannot actually start SSL/TLS; the client does so, > normally on its own initiative but possibly in response to a clear request. > Once in SSL/TLS data phase the server can issue HelloRequest to request > the client *re*negotiate, but 5246 explicitly says it SHOULD NOT do this for > > ... Hi Dave, Thanks for that hint; this solves what I'm aiming for and I tested it already with a small C-written client: it just connects to the socket and waits some seconds with read(2) if there is the clear text goodmorning message coming in, if not it stops reading and initiates the SSL/TLS. If it can read the "220 ready" in clear text, it will asume clear text and will talk the first command to the server. Vy 73 matthias -- Sent from my FreeBSD netbook Matthias Apitz, , http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: connecting to (openssl-) server in SSL or clear text
El día Friday, November 15, 2013 a las 12:58:40PM -0500, Watson, Patrick escribió: > Traditionally, there are 2 methods that immediately come to mind. One way is > to have the SSL version of the server listen on a different port than the > plain text version. Alternatively, your protocol could include a "STARTTLS" > like command that indicates that the system wants to communicate securely. > (See http://en.wikipedia.org/wiki/STARTTLS) I was thinking more in a solution where the client reads the first 8 bytes from the socket and checks if the beginning of the GoodMorning message is there in clear text (like "220 SLNP") and if not it should handover this buffer and the socket fd for further SSL handshake... Is this possible? matthias -- Sent from my FreeBSD netbook Matthias Apitz, , http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
connecting to (openssl-) server in SSL or clear text
Hello, We have application servers, written in C, which can be configured to do SSL or not. In any case they send out a goodmorning message, ciphered with SSL or in clear text if they run configured in clear text. What would be the best method for a C-written client to figure out if the server does or not does SSL after connecting the socket? Ofc the client could try any method and if it does not fit, drop the connection and do an new one. But I hope that there are better options. Thanks matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: how to STORE encrypted string in database
El día Thursday, March 28, 2013 a las 01:14:35PM -0500, Salz, Rich escribió: > Encrypted data is not a text string, it is an array of binary octets. You > will have to do something like base64 encode/decode when treating it as a > text string. Or the OP should use a data type of the database which allows storing binary actets, like BLOB (Sybase) or IMAGE (Oracle) or ... depends on your DBS. matthias -- Sent from my FreeBSD netbook Matthias Apitz | - No system with backdoors like Apple/Android E-mail: g...@unixarea.de | - Never being an iSlave WWW: http://www.unixarea.de/ | - No proprietary attachments, no HTML/RTF in E-mail phone: +49-170-4527211 | - Respect for open standards __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: simple server with using openssl
El día Saturday, October 06, 2012 a las 01:37:06PM -0400, Indtiny s escribió: > Hi, > Thanks for the information .. I get the server part from the this link > http://www.rtfm.com/openssl-examples/ > I started the server but I am getting the following error when I am trying You did not say exactly which 'server' you started, perhaps the 'wserver' from the openssl-examples-20020110 > run the client by $curl http://127.0.0.1:8080 you should use an SSL client, for example 'wclient' from the examples or the openssl' s_client; > > AT the server side : > > 3078153864:error:140EC0AF:SSL routines:SSL2_READ_INTERNAL:non sslv2 initial > packet:s2_pkt.c:187: I think this is normal, because you did not contacted the server with some SSL client; > > At the client side : > > curl: (56) Recv failure: Connection reset by peer normal too; HIH matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl client/server connection
Hello, I'm on the way to change some TCP/IP client server application to use Openssl to cipher the traffic. To get understanding of Openssl I started with the openssl-examples-20020110 some weeks ago. After struggling some time with the way of creating the CA and certificate (because the ones included in the tar archive have been expired), I found the way as described below to re-generate them. The resulting *.pem files are: $ ls -l *.pem lrwxr-xr-x 1 guru wheel13 1 ago 10:59 client.pem -> localhost.pem -rw-r--r-- 1 guru wheel 245 1 ago 11:00 dh1024.pem -rw-r--r-- 1 guru wheel 4834 1 ago 10:58 localhost.pem -rw-r--r-- 1 guru wheel 2963 1 ago 10:53 root.pem lrwxr-xr-x 1 guru wheel13 1 ago 10:59 server.pem -> localhost.pem The openssl-examples-20020110 software builds fine on my system and I can start the "wserver" as: $ cd openssl-examples-20020110 $ ./wserver and con connect with the "wclient" while standing in the same dir: $ ./wclient -h localhost -p 4433 This connects to the "wserver" which sends over the SSL socket the dummy message: HTTP/1.0 200 OK Server: EKRServer Server test page and all works as it should. I watched with truss(1) what the "./wclient" is using of the above *.pem files to make the connection to the "wserver", it uses (i.e. reads): client.pem root.pem which makes sense when I look into the source of wclient.c, because the name of the keyfile "client.pem" is passed as an argument to SSL_CTX_use_PrivateKey_file() I tested now the running "wserver" with the standard openssl client from another host by running: $ openssl s_client -connect hein.sisis.de:4433 and was a bit surprised that the connection went fine and the "wserver" accepts the SSL connection and responds fine with its dummy message. The openssl client does not need any key files to connect... The output of the openssl client about the connection is attached below as "nohup.out". Why is this? Could some kind soul bring a bit light into this? Thanks in advance. matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards $Id: openssl-examples-20020110.txt,v 1.1 2012/07/22 15:36:56 guru Exp $ configure and compile the source using openssl from the ports: $ tar xzf openssl-examples-20020110.tar.gz $ cd openssl-examples-20020110 $ ./configure --with-openssl=/usr/local/openssl \ --with-openssl-inc=/usr/local/include \ --with-openssl-lib=/usr/local/lib $ make generate new certs and keys as described here: http://www.gentoo-wiki.info/OpenSSL i.e. do: First step Inside the example code directory openssl-examples-20020110 do PATH=/usr/local/bin:$PATH (to use 'openssl' from the ports in /usr/local/bin) $ mkdir newca $ cd newca ( orig: $ cp /etc/ssl/misc/CA.sh . ) for FreeBSD port of openssl use: $ cp /usr/local/openssl/misc/CA.sh . $ ./CA.sh -newca will create a new CA. Remember the passphrase as you will need it to sign certificates. $ cp demoCA/cacert.pem ../root.pem Second step $ ./CA.sh -newreq will create a certificate and a certification request. Set the passphrase to 'password' as this is hard-coded in the examples' source code. It is important to set the [Common Name] to 'localhost'. Third step $ ./CA.sh -sign will sign your newly created certificate. Enter the password for your CA which you have defined in step 1. Fourth step $ cat newreq.pem newkey.pem newcert.pem > ../localhost.pem $ cd .. $ ln -s localhost.pem server.pem $ ln -s localhost.pem client.pem Maybe you also want to issue $ openssl dhparam 1024 -2 -out dh1024.pem -outform PEM in order to update the DH parameters. The above setup will only work for local testing. If you want to use OpenSSL to connect between different hosts, you either have to disable the common name and host name comparison in client.c in order to be able to use the same certificate on all hosts which may pose a security problem, or repeat steps two and three above with the correct host names (FQDN - fully qualified domain name, ie. host name plus domain name) instead of 'localhost'. Final note: if the SSL_get_verify_result() method in client.c returns the error code 10 (outdated certificate), also check the CA's certificate (root.pem) expiration date! In my case, I tried to set the expiration time 100 years in the future -- which resulted in a point of time in the past possibly due to a number overflow. $ openssl s_client -connect hein.sisis.de:4433 depth=1 /C=DE/ST=Germany/O=xxx GmbH/OU=SolarTech/CN=Matth
setting up an openssl client/server connection
Hello, I'm trying to build openssl keys to be used in a client/server connection and neeed some step by step guide for this, as I'm doing it for the first time. I found and started with the following procedure: http://acs.lbl.gov/~boverhof/openssl_certs.html Generating Client/Server certificates with a local CA Generate a CA 1)openssl req -out ca.pem -new -x509 -generates CA file "ca.pem" and CA key "privkey.pem" Generate server certificate/key pair - no password required. 2) openssl genrsa -out server.key 1024 3) openssl req -key server.key -new -out server.req 4) openssl x509 -req -in server.req -CA ca.pem -CAkey privkey.pem -CAserial file.srl -out server.pem (contents of "file.srl" is a two digit number. eg. "00") Generate client certificate/key pair 5) Either choose to encrypt the key(a) or not(b) a. Encrypt the client key with a passphrase openssl genrsa -des3 -out client.key 1024 b. Don't encrypt the client key (I used this) openssl genrsa -out client.key 1024 6) openssl req -key client.key -new -out client.req 7) openssl x509 -req -in client.req -CA ca.pem -CAkey privkey.pem -CAserial file.srl -out client.pem Then I copy over the files client.pem and server.pem to the example software (openssl-examples-20020110): $ cp server.pem client.pem openssl-examples-20020110 $ cd openssl-examples-20020110 but the server can't understand the file server.pem: $ ./wserver Can't read key file 4783:error:0906D06C:PEM routines:PEM_read_bio:no start line:/usr/home/guru/myThings/FreeBSD/9-CURRENT/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/pem/pem_lib.c:650:Expecting: ANY PRIVATE KEY 4783:error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib:/usr/home/guru/myThings/FreeBSD/9-CURRENT/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_rsa.c:669: $ cat server.pem -BEGIN CERTIFICATE- MIIB+TCCAWICAQMwDQYJKoZIhvcNAQEFBQAwRTELMAkGA1UEBhMCQVUxEzARBgNV BAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0IFdpZGdpdHMgUHR5IEx0 ZDAeFw0xMjA3MjExNTM0MTZaFw0xMjA4MjAxNTM0MTZaMEUxCzAJBgNVBAYTAkFV MRMwEQYDVQQIEwpTb21lLVN0YXRlMSEwHwYDVQQKExhJbnRlcm5ldCBXaWRnaXRz IFB0eSBMdGQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSYH6rEOJHR86gi IvkPlWIFTSjAdxw/M/RWiRVSF7nPyDrdjfZ6T6uCGu+gax72SOt3uGCGKKtWa58z 1R9EVvU5OhJNUDXU72yFAKpcAH04ysdf2eNyInMbj+s+DYNukrVofTnrkqjAq2YS 0fOQmH2LbmjKTn4Ia9d9iEFXvR4/AgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAT3Vm EonQgYTwnktQMeRi7Uo40IYVXd3rNHeJFobVszP7ladNtBdjRAhD+03rbXBahxDA IGo68N8LdS5wxdUjQizmyTCsBJI2oTpQeSkZ0BrDExs8NCz8OzhskdMdgRw3JUXD tM6F1CUQbvpelHg9Yg3ILA5a4LE+nH774SyL+cE= -END CERTIFICATE- Perhaps something is wrong with the way used to generate the keys, but what? I checked the few *.txt files in http://www.openssl.org/docs/HOWTO/ and they seems to be usefull, but the file certificates.txt makes in the critical point a refernce to "...another HOWTO " which is not there :-( Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
