Re: TLS and bad record mac
Tim Hudson a écrit : Gregory BELLIER wrote: I added a cipher in OpenSSL and NSS. I would like to send an email with SMTPs from a modified Thunderbird (because of NSS) to a postfix. The TLS negociation is between NSS and OpenSSL. [snip] Do you have any hint in what could be wrong? Use the -state -debug flags for s_client and s_server to trace each end when your modified NSS is at the other end. That will provide you with a lot more information to assist in figuring out what you've done wrong in the code. i.e. point modified thunderbird at a modified s_server with -state -debug enabled. Tim. Thanks for your comments, I'll look into that. Greg. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2194] Unwanted dependencies to user32.dll
-Original Message-
From: Andy Polyakov via RT [mailto:r...@openssl.org]
Sent: Monday, March 22, 2010 22:48
To: Kees Dekker
Cc: openssl-dev@openssl.org
Subject: Re: [openssl.org #2194] Unwanted dependencies to user32.dll
I agree that OPENSSL_isservice() cannot be changed,
??? My suggestion for *you* was to modify it to unconditionally
return 1...
Our application can both run in foreground and in service
context. So
simply changing to return 1 is not possible.
If changing to return 1 is not acceptable, how come conditional
compilation freezing to some unconditional behavior is?
Changing to 1 is acceptable, but changing code is very difficult.
In our current build process, we will use the code unchanged.
That is the reason that I like that the code is part of the standard source
base of openSSL.
May be there is another
method to check wether a windows process is a service, without using
user32.dll.
As mentioned one can do it with Native NT API, but it's quite special
and belongs rather in [your] application than in openssl.
Yes and no. As soon as there is any openSSL code, using APIs from user32.dll,
my application still have a dependency to user32.dll.
Although I cannot prove, my feeling is that the silly fact that an application
loads user32.dll also results in usage of desktop heap memory.
I would like to have no reference at all to user32.dll. I will try to get some
figures in this region.
Unfortunatelly, Microsoft dheapmon supports only 'older' platforms (and not
recent SPs, e.g. XP SP3 not). As soon as I have date I will let you know.
At least for windows 2008/vista etc, you can assume that
a process is a service, if it is running in session 0 (e.g. see
WTSGetActiveConsoleSessionId(), supported from Windows 2003 onwards)
You most likely mean ProcessIdToSessionId for current process.
True.
However, processes can run as non-service, but that will not
necessary mean that there is a visible console (e.g. another process
may call the process using OPENSSL_isservice(), but not redirect
stdout or stderr).
Which reminds me. *If* you redirect stderr to a file when you
start your
application and never call RAND_screen (once again, openssl
itself does
not call it), then /delayload-ing user32.dll and gdi32.dll
will do the
trick. This is because OPENSSL_isservice is *not* called if stderr is
redirected or attached to console window.
I would highly appreciate if a define can be used
(configurable with Configure) to tell that we want [no]
unconditional
logging to the evenviewer.
No. The maximum I'd go for is a way for application to
provide a way to
override OPENSSL_isservice. E.g. *application* can dllexport
_OPENSSL_isservice and OPENSSL_isservice can check for its
presence and
in such case invoke it.
My feeling is - but I can't prove - that if applications load
user32.dll, some init code in user32.dll will already occupy some
bytes in the windows heap.
Can't you run
main(){getchar();LoadLibrary(user32.dll);getchar();} and
*see* that with dheapmon? feeling should not be part of
programmer's
vocabulary.
Hmm :-) I did actually measure our own application, but that one is so big,
that I was not 100% sure that the usage of desktop heap memory was caused by
user32.dll.
We removed all references (except those caused by the openSSL static lib) to
user32.dll and made user32.dll delayed loaded. We saw some decrease of desktop
heap usage.
It may help too if RAND_screen() + readscreen() moved to a separate file,
preventing that user32.dll will be used if no RAND_screen was used.
The linker is not that clever if another function is being used in the same
file, to remove references to system dlls of not used functions (even if link
time optimization/LTCG is active).
I tried the code above, and saw:
Closed as many applications as possible, and then just before LoadLibrary():
Desktop Heap 3145728 (0x 30) Bytes
Committed 856064 (0x d1000) Bytes
Uncommitted 2289664 (0x 22f000) Bytes
Allocated 407472 (0x 637b0) Bytes
Total Freed 448592 (0x 6d850) Bytes
Unused 2738256 (0x 29c850) Bytes
Used Rate( 13.0) %
After LoadLibrary():
Desktop Heap 3145728 (0x 30) Bytes
Committed 856064 (0x d1000) Bytes
Uncommitted 2289664 (0x 22f000) Bytes
Allocated 410696 (0x 64448) Bytes
Total Freed 445368 (0x 6cbb8) Bytes
Unused 2735032 (0x 29bbb8) Bytes
Used Rate( 13.1) %
So simply loading user32.dll increased the amount of used memory with 3224
bytes (410696 - 407472). In our case, when 1000 users are logged on, this will
almost blow up the used heap.
Yes, we do start a new process for every user/connection. I can
of course add /delayload:user32.dll, but the risc is
RE: [openssl.org #2194] Unwanted dependencies to user32.dll
-Original Message-
From: Andy Polyakov via RT [mailto:r...@openssl.org]
Sent: Monday, March 22, 2010 22:48
To: Kees Dekker
Cc: openssl-dev@openssl.org
Subject: Re: [openssl.org #2194] Unwanted dependencies to user32.dll
I agree that OPENSSL_isservice() cannot be changed,
??? My suggestion for *you* was to modify it to unconditionally
return 1...
Our application can both run in foreground and in service
context. So
simply changing to return 1 is not possible.
If changing to return 1 is not acceptable, how come conditional
compilation freezing to some unconditional behavior is?
Changing to 1 is acceptable, but changing code is very difficult.
In our current build process, we will use the code unchanged.
That is the reason that I like that the code is part of the standard source
base of openSSL.
May be there is another
method to check wether a windows process is a service, without using
user32.dll.
As mentioned one can do it with Native NT API, but it's quite special
and belongs rather in [your] application than in openssl.
Yes and no. As soon as there is any openSSL code, using APIs from user32.dll,
my application still have a dependency to user32.dll.
Although I cannot prove, my feeling is that the silly fact that an application
loads user32.dll also results in usage of desktop heap memory.
I would like to have no reference at all to user32.dll. I will try to get some
figures in this region.
Unfortunatelly, Microsoft dheapmon supports only 'older' platforms (and not
recent SPs, e.g. XP SP3 not). As soon as I have date I will let you know.
At least for windows 2008/vista etc, you can assume that
a process is a service, if it is running in session 0 (e.g. see
WTSGetActiveConsoleSessionId(), supported from Windows 2003 onwards)
You most likely mean ProcessIdToSessionId for current process.
True.
However, processes can run as non-service, but that will not
necessary mean that there is a visible console (e.g. another process
may call the process using OPENSSL_isservice(), but not redirect
stdout or stderr).
Which reminds me. *If* you redirect stderr to a file when you
start your
application and never call RAND_screen (once again, openssl
itself does
not call it), then /delayload-ing user32.dll and gdi32.dll
will do the
trick. This is because OPENSSL_isservice is *not* called if stderr is
redirected or attached to console window.
I would highly appreciate if a define can be used
(configurable with Configure) to tell that we want [no]
unconditional
logging to the evenviewer.
No. The maximum I'd go for is a way for application to
provide a way to
override OPENSSL_isservice. E.g. *application* can dllexport
_OPENSSL_isservice and OPENSSL_isservice can check for its
presence and
in such case invoke it.
My feeling is - but I can't prove - that if applications load
user32.dll, some init code in user32.dll will already occupy some
bytes in the windows heap.
Can't you run
main(){getchar();LoadLibrary(user32.dll);getchar();} and
*see* that with dheapmon? feeling should not be part of
programmer's
vocabulary.
Hmm :-) I did actually measure our own application, but that one is so big,
that I was not 100% sure that the usage of desktop heap memory was caused by
user32.dll.
We removed all references (except those caused by the openSSL static lib) to
user32.dll and made user32.dll delayed loaded. We saw some decrease of desktop
heap usage.
It may help too if RAND_screen() + readscreen() moved to a separate file,
preventing that user32.dll will be used if no RAND_screen was used.
The linker is not that clever if another function is being used in the same
file, to remove references to system dlls of not used functions (even if link
time optimization/LTCG is active).
I tried the code above, and saw:
Closed as many applications as possible, and then just before LoadLibrary():
Desktop Heap 3145728 (0x 30) Bytes
Committed 856064 (0x d1000) Bytes
Uncommitted 2289664 (0x 22f000) Bytes
Allocated 407472 (0x 637b0) Bytes
Total Freed 448592 (0x 6d850) Bytes
Unused 2738256 (0x 29c850) Bytes
Used Rate( 13.0) %
After LoadLibrary():
Desktop Heap 3145728 (0x 30) Bytes
Committed 856064 (0x d1000) Bytes
Uncommitted 2289664 (0x 22f000) Bytes
Allocated 410696 (0x 64448) Bytes
Total Freed 445368 (0x 6cbb8) Bytes
Unused 2735032 (0x 29bbb8) Bytes
Used Rate( 13.1) %
So simply loading user32.dll increased the amount of used memory with 3224
bytes (410696 - 407472). In our case, when 1000 users are logged on, this will
almost blow up the used heap.
Yes, we do start a new process for every user/connection. I can
of course add /delayload:user32.dll, but the risc is
OpenSSL 0.9.8n released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 0.9.8n released === OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.8n of our open source toolkit for SSL/TLS. This new OpenSSL version is a security and bugfix release which addresses CVE-2010-0740. For a complete list of changes, please see http://www.openssl.org/source/exp/CHANGES. We consider OpenSSL 0.9.8n to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 0.9.8n is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file names are: o openssl-0.9.8n.tar.gz Size: 3770041 MD5 checksum: 076d8efc3ed93646bd01f04e23c07066 SHA1 checksum: 595f5ebf592568515964f0adc62239e7012ef08b The checksums were calculated using the following commands: openssl md5 openssl-0.9.*.tar.gz openssl sha1 openssl-0.9.*.tar.gz Yours, The OpenSSL Project Team... Mark J. Cox Nils Larsch Ulf Möller Ralf S. Engelschall Ben Laurie Andy Polyakov Dr. Stephen Henson Richard Levitte Geoff Thorpe Lutz JänickeBodo Möller -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEVAwUBS6odXqLSm3vylcdZAQLDhQf+MvAiA8El3jdYPkkYuZd7x0NClhqVTWqK fFsrkediEMZapz3baTAXAn5Bj21JeohEKtXES4s+JurKOa4MTZaBc2QCUmfwWava hWVsymGD01PxOEMmfagQNrvjmhnCyUy+bmeJgQGvbZbbmvHwFTtHvYsgRAh9E1bx VLgNe7fReasGqz9OlhWgeKNDb9HyKbmbEJtaiMyKuIyGnsRd8U3qg1axFLbPGNM9 aOGjgxJsFydSQthbeq4wZIvr0RMdF/HcN+2zljuBiFfsIU6IObvvJ+oXsn8w2DNg 6P3jhFqYw1Bg4IdOCrCJi9jRd0nLOM7DDTV8iyMcrhX/gFXhMqTooA== =sSYR -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2192] [PATCH] chil engine displays weird prompts to the end user
Your code successfuly fixed problems no.2 and no.3. However problem no.1 (output of strange binary characters) described in my initial email is still there. Buffer that stores prompt really needs to be zeroed. Please see my initial patch (memset) for more details. Kind Regards Jaroslav Imrich Disig, a.s. Zahradnicka 151, 821 08 Bratislava 2 jaroslav.imr...@disig.sk www.disig.sk -Original Message- From: Stephen Henson via RT [mailto:r...@openssl.org] Sent: Friday, March 12, 2010 1:50 PM To: Imrich Jaroslav Cc: openssl-dev@openssl.org Subject: [openssl.org #2192] [PATCH] chil engine displays weird prompts to the end user [jaroslav.imr...@disig.sk - Wed Mar 10 21:34:31 2010]: I've just realized that chil.patch I sent in my first e-mail can cause troubles when hwcrhk library passes null as stated in nCipher headers. I am attaching modified version chil2.patch that supports both null and an empty string. I've fixed this using an equivalent technique. Let me know of any problems. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2192] [PATCH] chil engine displays weird prompts to the end user
Your code successfuly fixed problems no.2 and no.3. However problem no.1 (output of strange binary characters) described in my initial email is still there. Buffer that stores prompt really needs to be zeroed. Please see my initial patch (memset) for more details. Kind Regards Jaroslav Imrich Disig, a.s. Zahradnicka 151, 821 08 Bratislava 2 jaroslav.imr...@disig.sk www.disig.sk -Original Message- From: Stephen Henson via RT [mailto:r...@openssl.org] Sent: Friday, March 12, 2010 1:50 PM To: Imrich Jaroslav Cc: openssl-dev@openssl.org Subject: [openssl.org #2192] [PATCH] chil engine displays weird prompts to the end user [jaroslav.imr...@disig.sk - Wed Mar 10 21:34:31 2010]: I've just realized that chil.patch I sent in my first e-mail can cause troubles when hwcrhk library passes null as stated in nCipher headers. I am attaching modified version chil2.patch that supports both null and an empty string. I've fixed this using an equivalent technique. Let me know of any problems. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org
OpenSSL 0.9.8n v. VMS
An OpenSSL 0.9.8n kit which appears to work on VMS should be available at: http://antinode.info/ftp/openssl/0_9_8n/openssl-0_9_8n_s1.zip The suggested changes are the same as for 0.9.8m: http://antinode.info/ftp/openssl/0_9_8m/ Not amazingly, old complaints/questions persist: As previously explained, I claim that some of these changes are closer to minimal than to optimal: crypto/o_init.c: Loose extern declarations, instead of a header file. makevms.com: Still overwrites a symlink, apps/md4.c, with crypto/md4/md4.c. (Who uses/needs apps/md4.c?) util/libeay.num: Excludes pqueue_print() on VAX, instead of providing working 32-bit code (crypto/pqueue/pqueue.c). Steven M. Schweda s...@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2201] 1.0 beta5, Solaris cc compile options
Hi, Any chance that old compiler options can get fixed for Solaris Studio cc compiler? For solaris-sparcv9-cc option with Sun compiler Studio 12.1 cc (cc: Sun C 5.10 SunOS_sparc Patch 141861-04 2010/02/24) on Sparc (5.10 Generic_142900-06 sun4u), I get the following compiler complaint: cc: Warning: -xarch=v8plus is deprecated, use -m32 -xarch=sparc instead For solaris64-sparcv9-cc, I get the following warning: cc: Warning: -xarch=v9 is deprecated, use -m64 to create 64-bit programs I'm not enough of a compiler guru to guess what the right settings might be, but warnings always worry me. The above applies to 0.9.8 versions too. Jeff Earickson Colby College __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2192] [PATCH] chil engine displays weird prompts to the end user
On Wed, Mar 24, 2010, Jaroslav Imrich via RT wrote: Your code successfuly fixed problems no.2 and no.3. However problem no.1 (output of strange binary characters) described in my initial email is still there. Buffer that stores prompt really needs to be zeroed. Please see my initial patch (memset) for more details. Just to be awkward I used a different technique again ;-) Just setting the buf[0] to 0 should work. Actually eliminating the call to UI_dup_info_string() might be better but I don't have a chil setup to test that. Let me know if this works now. iSteve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
