On Thu, 21 Apr 2005, Ka Fai Lau wrote:
If it is absolutely necssary, a quick pointer to the libssl source code will
be very appreciated. Any exceptional case?
Hmm. I do not know about SSL_read but in case of SSL_write there is
unnecessary check in the code that checks that the write must be
Hi!
It seems that compress_meth variable from SSL_SESSION is not stored inside
SSL_SESSION_ASN1 and therefore the external caching of sessions that use
compression disables the compression.
I would like to add the compress_meth to SSL_SESSION_ASN1 structure but I
wonder if there are any
I need the crypto portion.
I have found the SSLEay 0.8.1 port to PalmOS. Is this the port you are
talking about?
Yes, probably.
What are the problems you faced? What are limitations of
PalmOS you faced?
IIRC we had two problems. Each program was limited to 64kB and JMP was
limited to +-
I need OpenSSL on Palm OS. I have searched the archives and have found some
references to people attempting to port to Palm OS.
Has anyone ported it? What state is it in? And what problems did anyone face
porting it to Palm?
What parts do you need? Porting the complete OpenSSL is quite
Hi!
This patch fixes the multithreading issues I was having when an RSA
struct was being used by multiple threads simultaneously with blinding
enabled.
It adds _r versions of the convert/invert functions to save the
unblinding value, and does the update in the convert step. rsa_eay.c
Hi!
There have been two problem reports concerning the blinding patch:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg15565.html
and
http://www.mail-archive.com/[EMAIL PROTECTED]/msg15576.html
Perhaps same thing. Is somebody working with this issue?
Arne
Methods SSL_connect(), SSL_read() and SSL_write() should return
SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE if they need to complete
their tasks but the socket couldn't handle all the work.
But instead, the methods return SSL_ERROR_SYSCALL when the underlying
socket gave errno=EWOULDBLOCK
Like I say, they should only do this if there was an error reported, surely?
No. Take a look at the SSL_CTX_use_certificate_chain_file:
ret=SSL_CTX_use_certificate(ctx,x);
if (ERR_peek_error() != 0)
ret = 0; /* Key/certificate mismatch doesn't imply ret==0 ... */
I guess
I just checked. Seems that SSL_CTX_use_certificate_chain_file has a same
problem. Other uses of ERR_peek_error seem to be immune to the old entries
in error stack.
One theory is that applications should not call arbitrary OpenSSL
functions while there is stuff in the error queue.
Adding ERR_clear_errors() into SSL_read() etc seems to be the correct
approach. It is already handled this way in _accept(), _connect(), but
not that obvious, because it is found e.g. in ssl3_accept() which is
called depending on the method selected.
You will often find ERR_clear_errors()
Adding ERR_clear_errors() into SSL_read() etc seems to be the correct
approach. It is already handled this way in _accept(), _connect(), but
not that obvious, because it is found e.g. in ssl3_accept() which is
called depending on the method selected.
You will often find ERR_clear_errors()
Hi!
I have a small problem with SSL_get_error. This function starts like this:
int SSL_get_error(SSL *s,int i)
{
int reason;
unsigned long l;
BIO *bio;
if (i 0) return(SSL_ERROR_NONE);
/* Make things return SSL_ERROR_SYSCALL when doing SSL_do_handshake
* etc,
Example: when working through the internal session cache we learn, that
the linked list is corrupted, we have dangling pointers and don't know
what is going on. This would touch all threads using the same SSL_CTX.
Thus: we don't know how to repair it - abort().
to make it more extreme: why
On Wed, 14 Aug 2002, Ben Laurie wrote:
The point is that the application is now in an inconsistent state and
cannot reliably know anything. Even returning from a function could
cause an exploit. The only safe thing to do is abort (now I think about
it, probably die() shouldn't even print
These patches are known to apply correctly but have not been
thoroughly tested.
As I understand it, OpenSSL will call abort() when it detects attack
against any hole in SSL. It might be acceptable for process-per-connection
situations like Apache, but when one process serves many connections
As I understand it, OpenSSL will call abort() when it detects attack
against any hole in SSL.
Unh, no. The only time it calls abort is with -DREF_CHECK, and if a
reference count is less than zero, which is a can't happen condition.
the new patches that fix various buffer overflows in
I have added Ben to the CCs of this ticket, as it might affect all other
patches, too!
btw, i'm in process of rewriting the patches to not use die at all.
openssl-0.9.5a is almost ready.
arne
__
OpenSSL Project
btw, i'm in process of rewriting the patches to not use die at all.
openssl-0.9.5a is almost ready.
i started with openssl-0.9.6e instead.
attached is a patch for openssl-0.9.6e that removes the usage of die.
please review it carefully. all changes are localized but the action i
take in
ukik:/home/arne/b2l-infra/rootbin/openssl ciphers -v HIGH+RSA
AESdraft256-SHA SSLv3 Kx=RSA Au=RSA Enc=AESdraft(256)
Mac=SHA1
DES-CBC3-SHASSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
NULL-SHASSLv3 Kx=RSA Au=RSA Enc=None Mac=SHA1
NULL-MD5
Thanks for the detailed report. Please try this patch:
it works.
arne
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated
You do not point out in which version the problem occurs.
Does it still occur with recent snapshots?
sorry. my mistake. i'm still using 0.9.6b, but i checked cvs and all the
bad bits are still there.
arne
__
OpenSSL
hi!
i found a really nasty bug in the ssl code. i can describe it, but i
cannot offer a solution, because the code is so complex and full of
special conditions.
okey, the bug:
ssl3_read_internal function has special treatment for situations when
renegotiation is going on and the handshake and
hi!
we have a client program that uses external session database for session
caching. we have found a bug in client side session caching. or actually a
missing functionality.
after decoding stored session using d2i function the cipher parameter of
SSL_SESSION structure is zero. on server side
What I'd like to know is if the following structures are basically
just a memory blob with some bits that are fiddled with, or if it's a
handle to some bulkier resource. It's probably OK to create, say,
1 of the former without ay problem, the latter would create
problems in those
Yes it reminded me of Eric's old signature about a tristate boolean in
Windoze.
fyi: we are using term "trit" for such tri-state bits (0,1,dontcare).
arne
__
OpenSSL Project
I'd say that has very little to do with BIOs and more to do with the
fact that the public key API has no concept of "non blocking operations"
and this has filtered down to the SSL API.
It may be possible to actually do what you want through some of the SSL
state callbacks but I haven't
So the question: how many people would want non blocking I/O support? If
no one or hardly anyone wants or needs it then there isn't a lot of
point. However if there's considerably demand it would be worth looking
into.
if it doesn't affect the API then i suppose, then the blocking I/O is
The idea behind this is that a simple engine aware application could
then just call ENGINE_load_config("filename.cnf") and forget about any
other details.
or you can encode the parameters into string and pass this string around.
file-based configuration is not always the best.
every engine
The problem is the socket should be blocking, but for some reason, it has
become non-blocking. Using Observer and stepping through the code, I
verified
Are you using WSAEventSelect or WSAAsyncSelect functions? They put socket
into non-blocking mode.
Arne
stuff and do all the I/O yourself. The only feature you lose when you do
this is client connection reuse.
is it really so? i allways thought that session caching is implemented
completely in ssl statemachine.
server while the read completes? If your server is 100% CPU and no blocking
I/O,
Hmm, I was able to create 354406 unnamed mutexes, before
CreateMutex() failed with ERROR_NOT_ENOUGH_QUOTA. Tested under
NT4 SP6.
btw, why use mutexes at all? openssl uses only unnamed mutexes and always
waits indefinitly long on mutex. so we could use critical sections
instead. they are
As far as I've been able to see, that's only an issue in crypto/bio/bss_log.c.
One of my colleagues, Mr. Toomas Kiisk [EMAIL PROTECTED] made changed
BIO_s_log so that required functions from advapi32.dll are looked up at
runtime, so you don't have to create NT and 9x versions of OpenSSL
DLLs.
Thanks for answering!
Why's that? DH *parameter* generation is that slow, but only the
server has to do it. All the client does for generating its DH *key*
is an exponentiation with a random exponent. (Then another
exponentation is done to compute the shared DH secret.)
Yes, I know
Hi!
I made a small modification to s3_clnt.c to support reusing the ephemeral
Diffie-Hellman key on client side.
I have a centrally managed system with many servers and single client
which communicate using SSL. I use EDH ciphers to ensure PFS and all
servers use the same set of
decded to go ahead and start redoing the entire ASN1 infrastructure
for OpenSSL. I expect to have a preliminary snapshot in 2-3 weeks as
I'm only able to spend about 20 hrs/week on this.
good news. what are the properties of your asn.1 routines? are they still
memory based?
as a temporary
So any preferences or alternative suggestions?
peek for iget and copy for rget
arne
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Yes changing the structures to pointers to structures was one idea I
thought of. As you say there is a possiblity for memory leaks. Currently
you can call EVP_DigestInit() for example when a digest operation is
abandoned without ever calling EVP_DigestFinal() with no ill effects.
You'd get
hi!
one of my colleagues, Meelis Roos, found a bug in ASN1 routines.
ASN1_STRING_set allocates one extra byte for terminating '\0', so that one
can use str* functions directly. however it (correctly) doesn't reflect
this extra byte in length field. there are two other routines which create
On Wed, 23 Jun 1999, Bodo Moeller wrote:
This depends on how you define "properly written", obviously. If you
yes. but in order to make the OpenSSLifying of existing applications
simpler, it would be nice to follow the semantics of normal socket calls.
then you can start using OpenSSL just
I can't see the problem here. The check is:
if ((s-s2-wpend_tot (int)len) || (s-s2-wpend_buf != buf))
sorry, once again i did not check the latest source carefully enough. i
still use 0.8.1 and there the check readed:
if ((s-s2-wpend_tot != (int)len) || (s-s2-wpend_buf !=
hi!
i would like to report some bugs in ssleay. unfortunately i don't have
diffs against latest openssl source, but the fixes are really small, so i
hope it's not too much trouble to incorporate them.
1) crypto/bio/b_printf.c uses static buffer for vsprintf which might
overflow. we should use
41 matches
Mail list logo
