need help on handshake failure

Hello All, I am getting some errors causing SSL handshake to fail. Is there any way by which i can enable logging in our OpenSSL libraries? -mithun

Re: need help on handshake failure

Also when i use s_client tool it just hangs with following output. Any input on how to get full handshake dump? *vm-soniclx13(misingh): openssl s_client -connect NC-WIN2008X64:1433 **-state -debug -msg*** *CONNECTED(0003)* *SSL_connect:before/connect initialization* *write to 09050898

crash when calling ERR_print_errors_fp()

Hello All, I am using the function ERR_print_errors_fp() to get the last error in case of any failure. I want to divert the output to file. When ever there is a handshake failure application crashes. If handshake is successful i don't see any crash. Any idea where things are going wrong.

Re: crash when calling ERR_print_errors_fp()

i could see following method failing.. uplink.c :19 static void unimplemented (void) { OPENSSL_showfatal (sizeof(TCHAR)==sizeof(char)?%s\n:%S\n,msg); ExitProcess (1);//causing crash } On Thu, Aug 30, 2012 at 3:25 PM, Mithun Kumar mithunsi...@gmail.com wrote: Hello All, I am using the

Re: crash when calling ERR_print_errors_fp()

Thanks for the quick reply. I could see that following condition compiler flag is used OPENSSL_USE_APPLINK causing the problem. Any idea why this flag is used? -mithun On Thu, Aug 30, 2012 at 3:58 PM, Saurabh Pandya er.saurabhpan...@gmail.comwrote: is as simple as below const *errString =

Re: AES set_decrypt_key optimization

Hi, On 29.08.2012 17:18, Andy Polyakov wrote: Hi, There are alternatives for x86[_64] platforms [besides AES-NI], namely SSSE3 vpaes-x86[_64] and bsaes-x86_64 modules. These are accessible through EVP and provide adequate performance (in comparison to aes_core.c that is, not AES-NI). Thanks

RE: [PATCH] Support DTLS compatibility with DTLS1_BAD_VER client

So yes, I have a *vague* interest in your patch, although I wasn't intending to work on the server side myself in the near future. Ken (in Cc) may be interested though... It seems that David Woodhouse is interested for this patch. Will it be pushed ? Thanks, Ghennadi

Re: [PATCH] Fix mips64 compilation with gcc = 4.4

typedef unsigned int uint128_t __attribute__((mode(TI))); There is builtin __uint128_t type recognized by gcc [reportedly] since 3.1, so that why does one have to clobber it with typedef? Could you generate assembler listing for following snippet? unsigned long long foo(unsigned long long

RE: [openssl.org #2863] proposed fix

Thanks!! From: Andy Polyakov via RT [r...@openssl.org] Sent: Friday, August 17, 2012 2:45 AM To: Sand, Duane Cc: openssl-dev@openssl.org Subject: Re: [openssl.org #2863] proposed fix ... This inconsistency deserves a fix, i.e. assigning a default value

RE: [openssl.org #2863] Mips build of 1.0.1 fails, no private_AES_encrypt_key

Hi Andy, The scheduling feature of the original Mips assemblers was very nice; I used it extensively in 1988. It is unfortunately not present in the gnu and llvm assemblers now commonly used by most current users of the Mips architecture. The static schedule in this existing code looks good

Re: need help on handshake failure

use err = ERR_get_error(); to get error no and use ERR_string(ec) to stringify On 8/30/12, Mithun Kumar mithunsi...@gmail.com wrote: Also when i use s_client tool it just hangs with following output. Any input on how to get full handshake dump? *vm-soniclx13(misingh): openssl

Re: crash when calling ERR_print_errors_fp()

is as simple as below const *errString = ERR_error_string(ERR_get_error(), NULL)); On 8/30/12, Mithun Kumar mithunsi...@gmail.com wrote: Hello All, I am using the function ERR_print_errors_fp() to get the last error in case of any failure. I want to divert the output to file. When ever

FW: Negotiating TLS 1.0 from 1.2

Reposting in openssl-dev. Is this a bug or an oversight or an intentional omission? Or am I just not doing something right? If I modify s3_pkt.c in ssl3_get_record() to not fail out but to just change the version in the SSL session then it seems to work ok. -Original Message-

RE: Negotiating TLS 1.0 from 1.2

After experimenting some more I think I resolved this. It seems that specifying SSLv23_client_method(), in conjunction with SSL_OP_NO_SSLv2 and SSL_OP_NO_SSLv3, actually does send a TLSv1 handshake record, with {3,3} in the ClientHello. What confused me was that the docs for