Re: Weird OpenSSL behaviour on connecting to W2k3-LDAPS [LONG]
Christophe Devine wrote: Christian Marg [EMAIL PROTECTED] wrote: See the log on http://pastebin.com/892617 (or if that takes to long to load: http://pastebin.ca/379610 ) - didn't want to post 30K mail ;) Looking at the logs, it appears the server drops the connection after the client has sent his Finished message -- decryption failed, probably. It may be helpful if you could provide a tcpdump trace in both cases (with and without -pause). Ok, I attached the files I created with FreeBSD# tcpdump -w with(out)-pause.tcpdump-raw host Windowsserver.fqdn and tcp port 636 bye Christian -- Christian Margmail: mailto:[EMAIL PROTECTED] Rechenzentrum TU Clausthalweb : http://www.rz.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2043 Germany ICQ : on request with-pause.tcpdump-raw Description: Binary data without-pause.tcpdump-raw Description: Binary data signature.asc Description: OpenPGP digital signature
Re: [patch] Valgrind complaining about unitialized data
Ben Laurie schrieb: Lutz Jaenicke wrote: Lutz Jaenicke wrote: Peter Waltenberg wrote: Yes, it's desirable that that data is unknown however there is a compromise possible: Complement the area. It'll mean valgrind will only complain at the correct place, or possibly not at all, and it's still random. The performance hit from doing that will be so small it won't matter. This annoyed me as well - the big advantage of valgrind is that it doesn't require recompilation to work and it's really good if you don't have to wade through all the flase alarms before you can find the real problems. Not being a valgrind user... I do not see that leaving this area uninitialized will give us some cryptographically useful amount of entropy so that we could as well memset it to 0... Ok, I have just applied the patch to 0.9.8-stable and 0.9.9-dev. Oi. Don't do that. Why not? Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Why not send initial Handshake messages wrapped in TLSCompressed and TLSCiphertext
Hi. I'm developing an TLS implementation for Common Lisp. I'm using openssl s_server and s_client for tests propose. Why initial Handshake messages are sent only in TLSPlaintext and not TLSCompressed and TLSCiphertext? Where is written on protocol RFC that the initial handshake messages are only wrapped in TLSPlaintext and sent over the network? Regards, Anil Mamede __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Why not send initial Handshake message s w Why not send initial Handshake messages wrapped� �in TLSCompressedand TLSCiphertext
Hi. I'm developing an TLS implementation for Common Lisp. I'm using openssl s_server and s_client for tests propose. Why initial Handshake messages are sent only in TLSPlaintext and not TLSCompressed and TLSCiphertext? Because all security parameters are negotiated during this phase. So you have to exchange them in clear, however, they are protected by Finished messages against modification or replay. Add to that, the ClientKeyExchange is not in clear, it is encrypted with the server public key (case RSA). Best regards, Badra Where is written on protocol RFC that the initial handshake messages are only wrapped in TLSPlaintext and sent over the network? Regards, Anil Mamede __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [patch] Valgrind complaining about unitialized data
Oi. Don't do that. Why not? Because it's a pure pessimization whose sole purpose is to suppress a bogus warnings that very, very few people even see, when there's already a way to suppress those warnings that doesn't impose costs on people who don't care about them because they'll never even see them. A lot of applications require you to compile with '-DPURIFY' in order to get reliable results from Purify-like programs. Intentional use of initialized data is just one reason. Other common ones include code to delay freeing data in case it will be be re-allocated shortly or customized memory allocators which need to be disabled in order to accurate detect access to freed memory areas. Compiling with '-DPURIFY' is the ideal tradeoff. Always disabling these improvements just to make Purify-like tools is just wrong. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [patch] Valgrind complaining about unitialized data
Yes but: If you use Purify you have to recompile anyway to instrument the code. Valgrind runs on unmodified binaries - and it's not always possible to get someone else to recompile their code so that you can find problems. OpenSSL is used in commercial products where source isn't always available. Since there's no performance impact from fixing this, and the concensus is that there's no security gain from leaving the code as is I simply don't see the point of not changing this. very few people see it is true of most bugs :), but it's still not a good reason to avoid fixing problems. Peter David Schwartz [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 05/03/2007 09:21 AM Please respond to openssl-dev To openssl-dev@openssl.org cc Subject RE: [patch] Valgrind complaining about unitialized data Oi. Don't do that. Why not? Because it's a pure pessimization whose sole purpose is to suppress a bogus warnings that very, very few people even see, when there's already a way to suppress those warnings that doesn't impose costs on people who don't care about them because they'll never even see them. A lot of applications require you to compile with '-DPURIFY' in order to get reliable results from Purify-like programs. Intentional use of initialized data is just one reason. Other common ones include code to delay freeing data in case it will be be re-allocated shortly or customized memory allocators which need to be disabled in order to accurate detect access to freed memory areas. Compiling with '-DPURIFY' is the ideal tradeoff. Always disabling these improvements just to make Purify-like tools is just wrong. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [patch] Valgrind complaining about unitialized data
Valgrind runs on unmodified binaries - and it's not always possible to get someone else to recompile their code so that you can find problems. OpenSSL is used in commercial products where source isn't always available. Valgrind *can* run on unmodified binaries, but when you do that, you get lots of false positives and false negatives. In most realistic scenarios, OpenSSL is far from the least of your problems trying to do this, and it's unlikely you'd be able to make any sense of the output if you didn't have the source code. Since there's no performance impact from fixing this, and the concensus is that there's no security gain from leaving the code as is I simply don't see the point of not changing this. There is a performance impact for this change. That's why the general philosophy is to make optimizations that confuse memory tracking programs in release builds and to disable them in debug builds or builds specifically for memory tracking. very few people see it is true of most bugs :), but it's still not a good reason to avoid fixing problems. This is neither a problem nor a bug. It's an optimization that valgrind can't cope with. To remove the optimization just for people using valgrind is a bad tradeoff. There are a long list of things you can't do in valgrind builds and avoiding all of them just in case someone is going to run valgrind on a build for which they have no source code and likely can do nothing with the results is a bad tradeoff. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
Peter Waltenberg wrote: Valgrind runs on unmodified binaries - and it's not always possible to get someone else to recompile their code so that you can find problems. OpenSSL is used in commercial products where source isn't always available. This does not mean the valgrind ready version of a library is the same version as a general purpose optimized that you might use in a production environment. If you need to use valgrind then you must accept that you need to be in the position to audit ALL of the code that makes up your application to play nice with valgrind. It is not the OpenSSL project's place to make your commercial product development work best for you in your environment. If you want to debug with OpenSSL you must compile a debugging version, if you want to profile with OpenSSL you must compile a profiling version, if you want to use valgrind with OpenSSL you must compile a valgrind version, yadda, yadda. I think you take the valgrind marketing feature Valgrind runs on unmodified binaries far too literally. You have to also account for the flaws in how valgrind is implemented, some people could argue that valgrind should have a rule to cater for this exact problem just like it already does for many quirks of popular libc implemtations and system calls. But it doesn't at this time and I accept that and I accept that -DPURFY is fine for me. I would not be against any fix which has no performance impact and given its this one little line I'd also like to hear the case for why things should be left as they are. Would I be correct in saying that OpenSSL uses the implied randomness of the data on the stack to add randomness to the result. By virute of using uninitialized data as a source of randomness it is this that is causing the problem (then it gets used by the app and one or more bytes find their way into what valgrind believes is dangerous usage and therefore a warning gets emitted) ? Darryl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
If you want to debug with OpenSSL you must compile a debugging version, if you want to profile with OpenSSL you must compile a profiling version, if you want to use valgrind with OpenSSL you must compile a valgrind version, yadda, yadda. Which is fine - IF you have access to the sources of the code that uses OpenSSL. Im my case we supply libraries that customers integrate with other code - often other 3rd party code. If this decreased security, or had any real performance impact, I'd understand the objections - but that doesn't appear to be the case. Would I be correct in saying that OpenSSL uses the implied randomness of the data on the stack to add randomness to the result. By virute of using uninitialized data as a source of randomness it is this that is causing the problem (then it gets used by the app and one or more bytes find their way into what valgrind believes is dangerous usage and therefore a warning gets emitted) ? Yes, but it isn't very random anyway. Just uninitialized. i.e. it may have the same value every time the program starts. In reality it isn't a major problem for me, since I solved this years ago, but I can still remember how annoying it was at the time. And since IBM isn't the only comemercial user of OpenSSL you may want to consider not drowning one of the better debug tools available in spam every time OpenSSL is in the process. Peter Darryl Miles darryl-mailingli [EMAIL PROTECTED] To Sent by: openssl-dev@openssl.org owner-openssl-dev cc @openssl.org Subject Re: [patch] Valgrind complaining 05/03/07 03:51 PM about unitialized data Please respond to openssl-dev Peter Waltenberg wrote: Valgrind runs on unmodified binaries - and it's not always possible to get someone else to recompile their code so that you can find problems. OpenSSL is used in commercial products where source isn't always available. This does not mean the valgrind ready version of a library is the same version as a general purpose optimized that you might use in a production environment. If you need to use valgrind then you must accept that you need to be in the position to audit ALL of the code that makes up your application to play nice with valgrind. It is not the OpenSSL project's place to make your commercial product development work best for you in your environment. If you want to debug with OpenSSL you must compile a debugging version, if you want to profile with OpenSSL you must compile a profiling version, if you want to use valgrind with OpenSSL you must compile a valgrind version, yadda, yadda. I think you take the valgrind marketing feature Valgrind runs on unmodified binaries far too literally. You have to also account for the flaws in how valgrind is implemented, some people could argue that valgrind should have a rule to cater for this exact problem just like it already does for many quirks of popular libc implemtations and system calls. But it doesn't at this time and I accept that and I accept that -DPURFY is fine for me. I would not be against any fix which has no performance impact and given its this one little line I'd also like to hear the case for why things should be left as they are. Would I be correct in saying that OpenSSL uses the implied randomness of the data on the stack to add randomness to the result. By virute of using uninitialized data as a source of randomness it is this that is causing the problem (then it gets used by the app and one or more bytes find their way into what valgrind believes is dangerous usage and therefore a warning gets emitted) ? Darryl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org
