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
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+and
On Mon, Feb 18, 2013 at 3:04 AM, Nick nos...@codesniffer.com 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:
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
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 not
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
Changing
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 many
On Mon, Feb 18, 2013 at 7:58 AM, Nick nos...@codesniffer.com 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
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 *) is
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 burned by
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_something_fp.
I'll make the appropriate changes elsewhere then.
Thank you very much for your prompt helpful responses.
On Mon, Feb 18, 2013 at 8:31 AM, Nick nos...@codesniffer.com 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
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
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 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 on the
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
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
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 I/O
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
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
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
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 using
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
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
24 matches
Mail list logo
