OK, I followed the advice documented for the SSL_ERROR_SYSCALL case and
since ERR_get_error() returns 0, ended up with this situation :
"If *ret == 0*, an EOF was observed that violates the protocol."
Disabling the server results in SSL_connect never returning, so I
suspect that, when the serv
Currently using 0.9.7, trying to upgrade. When configuring with
"solaris64-x86_64-cc", I get a build error, but in an unusual spot:
> ./Configure solaris64-x86_64-cc
Seems to go ok.
Build:
> test-mn$ make
...
> cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
> -DHAVE_
On Tue, Feb 19, 2013, T J wrote:
> I think it might be my client as SSL_connect() is returning 0. When
> I plug that value + the clients' ssl into SSL_get_error(), it
> returns a value of 5. strerror(5) returns "Input/output error". Not
> much help there! Can anyone point me in the right direction
On Sun, Feb 17, 2013, Jeremy Harris wrote:
> On 02/16/2013 10:51 PM, Dr. Stephen Henson wrote:
> >So you could supply an application defined callback that just calls
> >X509_verify_cert too which keeps the current behaviour. If that call is
> >successful you can then note the chain for future use
I think it might be my client as SSL_connect() is returning 0. When I
plug that value + the clients' ssl into SSL_get_error(), it returns a
value of 5. strerror(5) returns "Input/output error". Not much help
there! Can anyone point me in the right direction to track that down
further to find ex
Well passing the ret value from SSL_get_error() (which is 2) to
ERR_error_string() results in:
... error:0002:lib(0):func(0):system lib ...
which is a system error isn't it? - hence my reasoning to try using
strerror().
Removing the timeout causes the socket to block and then DTLS
On Fri, 15 Feb 2013, Joel Dice wrote:
On Fri, 15 Feb 2013, Joel Dice wrote:
On Thu, 14 Feb 2013, Dr. Stephen Henson wrote:
On Thu, Feb 14, 2013, Joel Dice wrote:
Although OpenSSL seems to allow CBC-based suites with DTLS, from
what I've read a block in a CBC stream can't be properly decode
>From: owner-openssl-us...@openssl.org On Behalf Of David Geib
>Sent: Monday, 18 February, 2013 09:45
>You can't use strerror for OpenSSL errors. Look into
>ERR_get_error() and ERR_error_string().
After *most* OpenSSL errors. Errors (only) on an underlying
I/O operation, in particular a socket
> From: owner-openssl-us...@openssl.org On Behalf Of Joel Bion
> Sent: Monday, 18 February, 2013 13:57
> The issue I have been reporting has never been on the client
> side, as the
> problem is seen when connecting into a server that is booted into a
> 1.0.1e-environment vs. a 1.0.1c based enviro
On Mon, Feb 18, 2013 at 10:57:14AM -0800, Joel Bion wrote:
> 3372:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
> failure:.\ssl\s23_lib.c:177:
I think this is the important thing to check:
error:[error code]:[library name]:[function name]:[reason string]
error:140790E5:SSL routines:SSL23_
On Mon, February 18, 2013 3:04 am, Eisenacher, Patrick wrote:
> Hi Joel,
>
>
> Looks like your client doesn't trust the server's root CA certificate.
> Try to invoke s_client with either the -CApath or the -CAfile option.
>
>
Thanks for your note.
The issue I have been reporting has never been o
hi ALL,
There were 13 upstream commits for fixing the Lucky-13 issue in
openssl 0.9.8. For this issue, modified/deleted thousand of lines of
code. Is there any method or POC code for verification? Any ideas?
Thanks!
--
GNU powered it...
GPL protect it...
God blessing it...
regards
Shawn
__
On Sun, Feb 17, 2013 at 10:02 AM, Jeremy Harris wrote:
> On 02/16/2013 10:51 PM, Dr. Stephen Henson wrote:
>>
>> So you could supply an application defined callback that just calls
>> X509_verify_cert too which keeps the current behaviour. If that call is
>> successful you can then note the chain
You can't use strerror for OpenSSL errors. Look into ERR_get_error() and
ERR_error_string().
I think what's happening with your code is that you set a recv timeout on
the listen socket, so you listen for one second and then hit the timeout
and the socket returns EWOULDBLOCK/EAGAIN to OpenSSL which
On Mon, Feb 18, 2013 at 8:31 AM, Nick wrote:
> On Mon, 2013-02-18 at 08:12 -0500, Jeffrey Walton wrote:
>> It looks like the GCC tool chain has let you down: "C/C++ Option to
>> Initialize Variables?",
>> http://gcc.gnu.org/ml/gcc/2013-02/msg00207.html.
>>
>> Visual Studio has a similar feature fo
On Mon, 2013-02-18 at 14:18 +0100, Dr. Stephen Henson wrote:
> > Can you confirm the same logic applies to d2i_X509_fp?
> >
>
> Yes, it applies to any function of the form d2i__fp.
>
I'll make the appropriate changes elsewhere then.
Thank you very much for your prompt & helpful responses.
Ni
On Mon, 2013-02-18 at 08:12 -0500, Jeffrey Walton wrote:
> It looks like the GCC tool chain has let you down: "C/C++ Option to
> Initialize Variables?",
> http://gcc.gnu.org/ml/gcc/2013-02/msg00207.html.
>
> Visual Studio has a similar feature for debug builds, and I don't ever
> recall being burn
On Mon, Feb 18, 2013, Nick wrote:
> On Mon, 2013-02-18 at 13:22 +0100, Dr. Stephen Henson wrote:
> > Here's what's happening in detail. If you pass a non-NULL pointer for
> > the
> > second parameter it will attempt to reuse the structure.
> >
> > In the case of the RSA structure the outer (RSA *
On Mon, Feb 18, 2013 at 7:58 AM, Nick wrote:
> On Mon, 2013-02-18 at 13:22 +0100, Dr. Stephen Henson wrote:
>> Here's what's happening in detail. If you pass a non-NULL pointer for
>> the
>> second parameter it will attempt to reuse the structure.
>>
>> In the case of the RSA structure the outer (
On Mon, 2013-02-18 at 13:22 +0100, Dr. Stephen Henson wrote:
> Here's what's happening in detail. If you pass a non-NULL pointer for
> the
> second parameter it will attempt to reuse the structure.
>
> In the case of the RSA structure the outer (RSA *) is allocated via
> OPENSSL_malloc and so are
On Mon, Feb 18, 2013, Nick wrote:
> On Mon, 2013-02-18 at 00:37 +0100, Dr. Stephen Henson wrote:
> > That's because it is attempting to free up parts of a pointer that
> > haven't
> > been allocated with OPENSSL_malloc. See:
> >
> > http://www.openssl.org/docs/crypto/d2i_X509.html#WARNINGS
> >
>
Hi Joel,
> -Original Message-
> From: Joel Bion
>
> Here is the output from running an 'openssl s_client -debug' command (as
> much verbosity as I could quickly find.) The key difference between the
> two seems to be in the 1.0.1e case, there is this extra text at the end.
> 1.0.1c does n
On Mon, 2013-02-18 at 04:00 -0500, Jeffrey Walton wrote:
> The signature is X509 *d2i_X509_fp(FILE *fp, X509 **x);
>
Please re-read my previous response. I'm not having a problem w/ the
code involving x509. I included it in my last response to point out
that while it works fine, calling d2i_RSA
On Mon, Feb 18, 2013 at 3:04 AM, Nick wrote:
> On Mon, 2013-02-18 at 00:37 +0100, Dr. Stephen Henson wrote:
>> That's because it is attempting to free up parts of a pointer that
>> haven't
>> been allocated with OPENSSL_malloc. See:
>>
>> http://www.openssl.org/docs/crypto/d2i_X509.html#WARNINGS
>
On Mon, 2013-02-18 at 08:23 +, b ganesh ganesh wrote:
> All:
>
> What is the major difference bw SSL and TLS?Does it possible to use
> this protocols independenlty?
>
Google seems to turn up a bunch of results for your first question:
https://www.google.com/search?q=difference+between+ssl+a
On Mon, 2013-02-18 at 00:37 +0100, Dr. Stephen Henson wrote:
> That's because it is attempting to free up parts of a pointer that
> haven't
> been allocated with OPENSSL_malloc. See:
>
> http://www.openssl.org/docs/crypto/d2i_X509.html#WARNINGS
>
Changing the code to allocate the struct via OPEN
26 matches
Mail list logo
