> 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 connection
> > 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 overfl
> 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 so
> 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:
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 prin
> 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_erro
> >>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 e
> 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 t
> >>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
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
_
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
> 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
> 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
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 limitat
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
> > 3) crypto/bio/bf_buff.c buffer_gets does not insert final '\n' into
> > buffer. so it is not semanticaly equivalent with fgets. this is my version
> > of buffer_gets:
>
> My reading of the current OpenSSL source says this is fixed. It'd be
> nice if you could confirm that.
sorry i did not
> Since it is a static, they will already be clear.
you are right.
arne
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated Lis
> 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->wpe
> By "properly" I mean that the "save" operation doesn't expand and
> reformat the data. That is if you have lines like this:
>
> config=$ENV::HOME
> other=oneline \
> anotherline
>
> It gets saved verbatim, NOT in the expanded form:
>
> config=/home/steve
> other=oneline anotherline
too bad
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
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
stri
> 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
> 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]
> What it seems to me is that what should be done is
>
> TYPE * API_blah(..., int app_will_free_object)
> #ifdef OLDAPP_COMPATIBILITY
> #define API_blah() API_blah(, X)
> #endif
this will make the library itself more complex: you must handle
app_will_free_object inside API_bla
> 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 tempora
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 Diffie-Hellma
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
> 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
DLL
> 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 m
> >why uses mutexes at all?
>
> programing model portability?
but they are completely hidden inside win32_locking_callback. if you use
them you will just get better performance under windows.
> write an emulation using pthreads; that will help.
sorry, didn't understand this on :( emulation o
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 rep
> 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
> 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
___
> 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 engi
> 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
> 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 i
> 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 http://www.ope
> 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 q
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
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
> 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 Pro
> Thanks for the detailed report. Please try this patch:
it works.
arne
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated Lis
ukik:/home/arne/b2l-infra/root>bin/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
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, w
> 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_err
46 matches
Mail list logo