> From: owner-openssl-us...@openssl.org On Behalf Of Brice André > Sent: Thursday, 30 May, 2013 04:08
> I tested [s_client] and it seems to work properly, which, I > suppose, means that the problem resides in my client code. I > copy-pasted the output below. > I think so; see more below. > I just find something strange on the server : to write my server code, > I followed a tuto where they initialised a diffie-helman key in the > server side. I was not sure of the utility of that and thus, I > performed several tests with the command you provided : with and > without this initialisation on the server side. In both cases, this > works properly. So, I am a little bit confused about that. I would > want to remove that part, but I am not sure if it may be useful... > I presume you mean *temporary* Diffie-Hellman *parameters* i.e. SSL_CTX_set_tmp_dh (or _callback). The actual key using those parameters is generated inside openssl. This is for ciphersuites using "ephemeral" or "anonymous" DH key-exchange, abbreviated EDH or DHE (better to avoid confusing EDH with ECDH which is different) and ADH. SSL/TLS also defines ciphersuites using static Diffie-Hellman, but openssl does not implement them; plus you can't have a selfsigned cert for a (static) DH key. Your key is RSA so s_client by default and your client as posted supports both ciphersuites with DHE (DHE-RSA) and without (RSA, or akRSA to avoid ambiguity). Other kinds of key/cert would differ. I believe (but didn't check) that both will prefer DHE-RSA; thus you might observe the difference if either endpoint displays SSL_get_cipher_name(ssl) or equivalent after handshake, or when you use s_client which displays this among other things. The advantage of DHE-RSA over akRSA is "perfect forward secrecy": assuming the endpoints (together) put sufficient entropy into their DHE keys, the session keys cannot be recovered and thus logged session data cannot be decrypted even if the (server's) privatekey is later compromised. Google for more. In a situation where you're doing both endpoints (no interop) and trust your own key management, PFS probably doesn't have any benefit. > I joined my client code. The interesting function is > "wxSSLSocketClient::InitiateSSLSession". This code uses the wxWidgets > library and thus, it uses the wxSocketClient (wxWidgets socket > implementation) with a dedicated BIO so that openssl can handle it. > This code is extracted from the wxEMail project (I am the maintaniner > of this project). But, in this project, I did not implement the server > certificate check stuff. Thus, this version is slighlty modified to > perform those additional checks. > > You will easily identify which part is original code and which one is > not because original code was designed to work in static link as well > as dynamic link (with a manual load of library). So, in original code, > all ssl calls are encapsulated in a macro. The modified version > currenlty only support static link, and thus ssl calls are not > encapsulated in the macro. > It's a bit difficult to read through the clutter, but I don't see anything here which should cause the cert lookup to fail. If some calls were going to a different version openssl library(ies) somehow that might explain it, but with OPEN_SSL_STATIC_LINK defined I don't see how that would happen. Two things I do notice: - SSL_set_connect_state is redundant when using SSL_connect. (It is needed for "transparent" or "automatic" handshake.) - SSL_set_cipher_list "ALL" includes the anonymous suites that provide no authentication, which may conflict with your goal. Do you want your client to verify the server unconditionally, or only if the server "agrees" by choosing an authenticating suite? > Note that this code allows performing ssl connection on different > servers and thus, I really think that the BIO part and so on is OK. > The only part that has never been tested is the new part performing > the server certificate check. > I think you're down to an ordinary debugging problem here. In your shoes I would: - cut down the code to the minimum that reproduces the problem; your special BIO logically shouldn't matter, but cut it out anyway to be certain and simplify the code - use a (re)build with symbols and step through it using a good debugger (preferably gdb); in particular, after _load_verify ctx->cert_store->objs->stack should have num=1 (and data should point to a pointer that's actually to an X509_OBJECT that contains a pointer to the desired cert, but that's harder to look at), and the first time you get to X509_STORE_CTX_get1_issuer from X509_verify_cert for this case ctx->ctx->objs->stack the same. (The first ctx is a store_ctx and the second actually a store, which is confusing.) If not then backtrack to see why not; if so then step forward to see why it's not matched and accepted. - if I get to a point where what the debugger says happened is not what the source code directs, look at the machine code and registers etc. as needed. This is a last resort. Good luck. <snip> > D:\home\DbSync1>C:\OpenSSL-Win32\bin\openssl s_client > -connect localhost:1212 -CAfile server.crt > Loading 'screen' into random state - done > CONNECTED(00000738) > depth=0 C = BE, ST = Hainaut, L = Charleroi, O = AMS-Solutions, > CN = Brice Andre, emailAddress = brice.an...@xxx.be > verify return:1 <snip most> > New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA > Server public key is 2048 bit > Secure Renegotiation IS supported > Compression: NONE > Expansion: NONE > SSL-Session: > Protocol : TLSv1 > Cipher : DHE-RSA-AES256-SHA <snip rest> If the server doesn't have a temp-DH key (or callback) this ciphersuite won't be the one selected. You'll get RSA-something, almost certainly RSA-AES256-SHA, instead. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
