Re: [openssl-dev] [openssl-users] Kerberos
On 5/13/2015 10:19 AM, Matt Caswell wrote: On 08/05/15 09:40, Matt Caswell wrote: On 08/05/15 02:28, Jeffrey Altman wrote: Regardless, the inability to improve the support in this area has left the those organizations that rely upon 2712 with the choice of use insecure protocols or re-implement the applications. I do not believe that any sane OS or application vendor can with a straight face continue to ship 2712 support. As such it should be removed from OpenSSL master. I plan to start preparing the patches to remove it next week. FYI, these patches have now been applied to master. Matt Thank you. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-users] Kerberos
On 5/8/2015 5:17 PM, Nathaniel McCallum wrote: I agree that the current situation is not sustainable. I was only hoping to start a conversation about how to improve the situation. For instance, there is this: http://tls-kdh.arpa2.net/ I don't see any reason this couldn't be expanded to do GSSAPI. I think that TLS-KDH is fundamentally flawed because it is tied to the Kerberos protocol. Most operating systems today support Kerberos but they do not support a stable standard Kerberos API because such a creature does not exist in the wild. If we want a TLS implementation to make use of Kerberos authentication on a broad range of operating systems that we must access Kerberos through GSS. Only by using GSS can userland TLS implementations hope to stack on top of the OS provided Kerberos in a portable way. But maybe this mailing list isn't the right place for such a discussion. Perhaps the right question to ask is how much interest there would be in improving this situation in the TLS WG and whether or not OpenSSL would have interest in implementing such a project. The IETF TLS WG and perhaps the IETF Kitten WG are the appropriate places to hold discussions. Or perhaps hold an IETF BOF first to explore the interest. The last time I was involved the work product was https://tools.ietf.org/html/draft-santesson-tls-gssapi-03 I still believe that is a reasonable approach. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-users] Kerberos
On 5/7/2015 8:40 PM, Viktor Dukhovni wrote: On Thu, May 07, 2015 at 08:00:17PM -0400, Nathaniel McCallum wrote: There have been some conversations behind Red Hat doors about improving the state of Kerberos/TLS in both standards and implementations. Could we maybe have a broader conversation about how to fix this situation? To be blunt, if you want better Kerberos support in TLS, the fix is to expand the TLS WG charter to explore new directions in TLS Kerberos support. Given all the current efforts on 1.3, this is not going to happen for quite some time. There's nothing that can be done in just OpenSSL, and the right immediate action is to drop support for the obsolete protocol. [ FWIW, Nico concurs. ] As do I and I am one of the individuals that pushed to get RFC 2712 passed the TLS WG and added to OpenSSL back in 1999. While Viktor is correct that GSS authentication used over TLS with appropriate channel bindings is a good option, it is not an option for everyone. It isn't easy to re-architect protocols that have been deployed for more than 15 years in production. There have been several efforts over the years to better integrate GSS and Kerberos into TLS. The approach that I prefer is one in which TLS relies upon GSS authentication to produce a shared secret key that is used to feed the TLS Pre-Shared Key (PSK) functionality. However that went nowhere. TLS is complicated enough and there were significant concerns that creating a GSS hole in the protocol would risk broader security and performance issues. SSH2 + GSS Key Exchange demonstrates how easy it should be to combine GSS Kerberos with a security protocol and remove the dependency on key management. I have often wondered if the real resistance to adding GSS to TLS is the negative impact it would have on the bottom lines of companies that sell server certificates. Regardless, the inability to improve the support in this area has left the those organizations that rely upon 2712 with the choice of use insecure protocols or re-implement the applications. I do not believe that any sane OS or application vendor can with a straight face continue to ship 2712 support. As such it should be removed from OpenSSL master. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: If you use kerberos/ssl
On 8/12/2014 6:06 PM, Viktor Dukhovni wrote: On Tue, Aug 12, 2014 at 04:22:21PM -0400, Salz, Rich wrote: Can you take a look at http://rt.openssl.org/Ticket/Display.html?id=549 And let us know what you think? I contribute bits of code to MIT and Heimdal Kerberos and maintain a Kerberos infrastructure for a living. I would like to see OpenSSL remove all support for the obsolete Kerberos-V5 cipher-suites. The modern way to combine Kerberos with TLS is GSSAPI with channel binding. The old crufty Kerberos support should be deleted from master. No new features should be added to this code. Viktor, RFC 2712 is a Proposed Standard. I agree with you wholeheartedly that no one should ever use it again because of its dependence on DES and only DES. An Internet Draft should be submitted to the IETF TLS Working Group to change the status to Historic and reference RFC 6649 Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos as the justification. I also agree that OpenSSL should consider removing the functionality. That being said I know that there are entities that did rely upon it. OpenSSL does not build with this support by default and it would bad form to remove it from an existing release series. Removal on the current master branch should not be an issue. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: FIPS Module 1.2 build with Visual Studio 2010 fails self-tests
On 10/17/2010 4:36 PM, Dr. Stephen Henson wrote: On Sun, Oct 17, 2010, aerow...@gmail.com wrote: Ugh. This is worse than I thought. It's *intermittently* failing like that. After a few more minutes, I tried it again, and got the expected output. Is there some way to specify a base address during the creation of the DLL, after the fipscanister is created? Would that invalidate it? The default appears to be 0x00d6, and it works when loaded there. You can't modify the 1.2 module build process in any way but you can specify an alternate base address when you link against a newer version of OpenSSL such as 0.9.8o. One way to get more information would be to dump the fingerprinted data in the FIPS_incore_fingerprint() function along with the addresses when it works and when it fails. Then see if the addresses and/or the dumped binary data have changed. On Windows it is not possible to require that a DLL be loaded at a specific address in memory within a process. The base address is simply a recommendation and if correct will result in the library loading process being faster than if it is not. Any fingerprinting of a library needs to be performed by computing the memory offsets compared to the base address and using those. Microsoft Vista, Server 2008, Win7 and Server 2008-R2 all support enable by default Address space layout randomization (ASLR). Visual Studio 2010 is the first version of Windows development tools to turn ASLR on by default for EXEs and DLLs. To disable, use /DYNAMICBASE:NO when linking. (Or disable the Randomized Base Address property in Visual Studio.) Jeffrey Altman Secure Endpoints, Inc. signature.asc Description: OpenPGP digital signature
Re: Draft FIPS Module v1.2 User Guide
Steve Marquess wrote: Well, it's still not as finished as I'd like but since I'll be out of town and offline until next week I'm releasing the OpenSSL FIPS Object Module v1.2 User Guide document: http://www.openssl.org/docs/fips/UserGuide-1.2-RC1.pdf. It's still labeled as a draft as I anticipate revisions over the next few weeks. Feedback on errors/omissions/improvements will be greatly appreciated. -Steve M. The Windows section looks like it needs a close review. The list of changes for this revision states that nasm is no longer supported and yet the instructions still refer to configuring and building with nasm. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: valgrind and openssl
John Parker wrote: change -DPURIFY to -DNO_UNINIT_DATA or something else which has a clearer intention, so that debug packages (or even base packages that want to be valgrind-friendly) have a straightforward mechanism to apply. Well, a straightforward mechanism that doesn't kill the PRNG outright, I mean (otherwise there is already a highly-publicised patch we could apply...) What I was hoping for was a -DNO_UNINIT_DATA that wouldn't be the default, but wouldn't reduce the keyspace either. That is -DPURIFY. Can someone provide a pointer to this highly-publicized patch? I'm afraid I'm dreadfully ignorant of the blogosphere. The Debian patch is the highly publicized patch that kills the PRNG outright. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: Static global - bug? (Re: Two valgrind warnings in OpenSSL-possible bug???)
Paul Sheer wrote: Locking with no contention is not pretty expensive, it's darn near free. Oh? If this is true it changes things somewhat. But I must say that I believe that no-one has ever used OpenSSL with 10'000 concurrent SSL objects. So I'm not going to take the chance that there will be any performance degradation. I'd rather have the GUARANTEE that there is no lock contention AT ALL. In my opinion what you are doing is going to result in some subtle bug that is going to be impossible to track down if there is even a single location where two threads can step on each other's toes. Locks are placed into the code when the developer of the code believes it is not safe to perform an operation in a multi-threaded environment without the guarantee that no other thread can be accessing or manipulating the same data. If your application is designed correctly and there is in fact no contention between the threads, then the cost of obtaining and releasing locks will be inconsequential. You can do what you will but as someone who has years of experience tracking down bugs in live systems caused by races between threads that were not prevented by locks, I think you are being foolish. It is not worth the cost of a production system going down or valuable data being lost or corrupted. Jeffrey Altman Secure Endpoints Inc. smime.p7s Description: S/MIME Cryptographic Signature
Re: Two valgrind warnings in OpenSSL - possible bug???
Paul Sheer wrote: I valgrind'ed OpenSSL as follows: I compiled OpenSSL (0.9.8g) with my own random number engine - in order to generate pseudo random numbers that are not based on unitialized values (if you run openssl without doing this you get infinite warnings - of course). The results are as follows ==26139== Conditional jump or move depends on uninitialised value(s) ==26139==at 0x81095FF: BN_mod_inverse (bn_gcd.c:215) ==26139==by 0x810D29F: BN_MONT_CTX_set (bn_mont.c:406) ==26139==by 0x8103E8F: BN_mod_exp_mont (bn_exp.c:417) ==26139==by 0x81036E9: BN_mod_exp (bn_exp.c:223) ==26139==by 0x81090FD: BN_BLINDING_create_param (bn_blind.c:352) ==26139==by 0x80C9844: RSA_setup_blinding (rsa_lib.c:413) ==26139== ==26139== Conditional jump or move depends on uninitialised value(s) ==26139==at 0x8128F5A: BN_div (bn_div.c:190) ==26139==by 0x810D318: BN_MONT_CTX_set (bn_mont.c:417) ==26139==by 0x8103E8F: BN_mod_exp_mont (bn_exp.c:417) ==26139==by 0x81036E9: BN_mod_exp (bn_exp.c:223) ==26139==by 0x81090FD: BN_BLINDING_create_param (bn_blind.c:352) ==26139==by 0x80C9844: RSA_setup_blinding (rsa_lib.c:413) ...above repeated several times. The code that gives the error is the BN_get_flags() macro (see bn_div.c extract about line 190 below): Could this be highlighting a bug in OpenSSL? Kind regards -paul Reading the 0.9.8g code I see no uninitialized variables in these code paths.The BIGNUM pointers which are passed to the BN_get_flags() macro are parameters passed into the BN_mod_inverse() and BN_div() functions. In BN_MONT_CTX_set() those BIGNUM objects are initialized. I do not see why this warning is being triggered. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Loophole in Windows RNG
This paper justifies the decision not to rely on the Windows Random Number Generator. http://eprint.iacr.org/2007/419.pdf Quoting: We analyzed the security of the algorithm and found a non-trivial attack: given the internal state of the generator, the previous state can be computed in O(223) work (this is an attack on the forward-security of the generator, an O(1) attack on backward security is trivial). The attack on forward-security demonstrates that the design of the generator is flawed, since it is well known how to prevent such attacks. The generator is run in user mode rather than in kernel mode, and therefore it is easy to access its state even without administrator privileges. The implication of these findings is that a buffer overflow attack or a similar attack can be used to learn a single state of the generator, which can then be used to predict all random values, such as SSL keys, used by a process in all its past and future operation. This attack is more severe and more efficient than known attacks, in which an attacker can only learn SSL keys if it is controlling the attacked machine at the time the keys are used. smime.p7s Description: S/MIME Cryptographic Signature
Re: RAnd_Poll crashes in Vista
Shobhit Gupta wrote: Hi, We were using OpenSSL in our product, but lately after testing on Vista, our application was was crashing (only in Vista) in SSL_Connect(). (It worked fine in XP) After debugging through OpenSSL we found that within RAND_poll() it was crashing in a win32 api function snap(TH32CS_SNAPALL,0). I would like to see a minidump with heap for an instance of an application crashing in this circumstance. I will require the source code to the test application, the matching binary and symbols. With reference to the RAND_poll() issue described in http://www.mail-archive.com/openssl-dev@openssl.org/msg18900.html we came to know that RAND_poll() crash occurs especially during a multithreaded environment. The purpose of the CreateToolhelp32Snapshot function is to permit walking data structures that are constantly changing by creating a read-only copy that will not change. The returned HANDLE points to a unique snapshot. Walking the contents of the data structures in this snapshot is thread safe. Getting more info from an MSDN page http://msdn2.microsoft.com/en-us/library/ms682489.aspx we got to know that : TH32CS_SNAPALL copies process + thread information while TH32CS_SNAPPROCESS copies just the process information. That is not the crucial item. SNAPALL includes the HEAPLIST whereas SNAPPROCESS by itself does not. So we tried changing from *snap(TH32CS_SNAPALL,0)* to *snap(TH32CS_SNAPPROCESS ,0)* And then it worked and did not crash. The important question is where is the crash? Is the crash occurring within the CreateToolhelp32Snapshot function call? If so, is your application running in an environment which does not support COM (or in Vista perhaps WMI)? Can anyone confirm if these changes are good (safe)? Making the change reduces the amount of data that is obtained for use in initializing the random number generator. Has anyone else faced such RAND_poll() related crash before ? Yes. Is there anyway I can bypass that RAND_poll() call (as described in the last paragraph of http://www.mail-archive.com/openssl-dev@openssl.org/msg18900.html). Your application can all RAND_add() and provide an alternate source of random data. If there is sufficient random data available, RAND_poll() will not be called. Thanks in advance, Regards, Shobhit Gupta smime.p7s Description: S/MIME Cryptographic Signature
Re: RAnd_Poll crashes in Vista
Andy Polyakov wrote: The purpose of the CreateToolhelp32Snapshot function is to permit walking data structures that are constantly changing by creating a read-only copy that will not change. The returned HANDLE points to a unique snapshot. Walking the contents of the data structures in this snapshot is thread safe. Has anyone else faced such RAND_poll() related crash before ? Yes. Where was it then? Point is that if above (with snapshot being read-only copy) held true, then we wouldn't have this discussion, would we? Or at least switching to TH32CS_SNAPPROCESS wouldn't make difference... I see no other option then to assume that either snapshot is not really a snapshot or CreateToolhelp32Snapshot itself is not thread-safe. I don't have enough information to perform the analysis. As documented, CreateToolhelp32Snapshot is supposed to create a read-only snapshot. Hence the reason I asked for the minidump. Unless someone collects data and places in inquiry with Microsoft to find out what is really going on, everything is just going to be speculation. smime.p7s Description: S/MIME Cryptographic Signature
Re: RAnd_Poll crashes in Vista
Andy Polyakov wrote: Yes, of course. It's just that as you answered yes to question has anyone else had problem I assumed that you ran into it at some point too. I mean my where was it targeted you as potential somebody else:-) A. The 'yes' applies to the complaints that have been reported on openssl-info and openssl-dev going back more than seven years. My applications never experience this problem because they all execute in user mode on the user's desktop. The applications that have experienced the problem that I am aware of are services that either execute before other dependencies have started OR have called OpenSSL from within DllMain(). smime.p7s Description: S/MIME Cryptographic Signature
Re: RAnd_Poll crashes in Vista
Shobhit Gupta wrote: Thanks all for responses. Andy::I will try appending your piece of code in the end of md_rand.c -- I would like to see a minidump with heap for an instance of an application crashing in this circumstance. I will require the source code to the test application, the matching binary and symbols. How do we create a minidump ? The easiest way is to reproduce the problem with a debugger attached and then after the crash occurs ask the debugger to write the minidump. Using Debugging Tools for Windows, http://www.microsoft.com/whdc/devtools/debugging/default.mspx, you can use the .dump command. See the debugger's online help. smime.p7s Description: S/MIME Cryptographic Signature
Re: Emails not getting through?
Testing from [EMAIL PROTECTED] which subscribed to the list on 17 Sep 2006. smime.p7s Description: S/MIME Cryptographic Signature
TSU Notification - encryption was Re: [openssl.org #1336] OpenSSL support for Kerberos
__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Extending OpenSSL ASN.1 for Kerberos
I need to extend the OpenSSL ASN.1 support to include the PKINIT SubjectAltName extension and the Kerberized Certificate Authority extension. Is there any documentation or guidelines available to assist developers wishing to add new extensions? Thanks. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Peter Runestig has passed away
Last month, Peter Runestig [EMAIL PROTECTED] passed away from a heart attack. Peter was an active participant in the openssl community. He will be dearly missed by all that knew him. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
[openssl.org #1112] 0.9.8 beta 5 build issue on windows
The following build issue exists: cl /Fotmp32dll\c_zlib.obj -Iinc32 -Itmp32dll -DZLIB_SHARED -DZLIB -DKRB5_MIT /MD /W3 /WX /G5 /Ox /O2 /Ob2 /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -DOPENSSL_SYSNAME_WINNT -DOPENSSL_USE_APPLINK -I. /Fdout32dll -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPENSSL_NO_MDC2 -I/usr/kerberos/include -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\comp\c_zlib.c c_zlib.c crypto\comp\c_zlib.c(76) : error C2220: warning treated as error - no object file generated crypto\comp\c_zlib.c(76) : warning C4005: 'ZLIB_SHARED' : macro redefinition command-line arguments : see previous definition of 'ZLIB_SHARED' This can be corrected by wrapping the #define ZLIB_SHARED in an #ifndef ... #endif block. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Finally time for IPvn support
Richard Levitte - VMS Whacker wrote:
gianni If I think hard enough, I could probably think of ways that
gianni this would break things.
Well, let's see, we have two places where this is relevant. One is
the simple {host}:{port} combination, the other is the URL
http://{host}:{port}/... In both cases, the brackets be part of the
{host} part. Brackets can't be part of a IP address or a host name
(at least as far as I know), so I'm not really sure what would break.
gianni I think this is one of those cases where you want to stick to
gianni the standard exactly and not allow any non-standard behaviour.
That makes things tougher, because I had planned on letting
getaddrinfo() take care of all the correctness verification. With
what you ask for, we get back at having to do it ourselves, which is
duplication of functionality (and potentially getting it wrong), which
I don't see the benefits of.
Cheers,
Richard
As long as OpenSSL only accepts the extended behavior as input and
never generates the extended behavior on output I do not see there
being a problem.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
Re: possibly bug in crypto/rand/rand_win.c
Suggestion:
This is a usage error. Be sure to initialize openssl when your
application starts or
when your DLL is loaded. Do not wait for the first thread to attempt
to make
a call to OpenSSL to initialize it.
Come to think of it, maybe OpenSSL should simply perform a call to
RAND_poll()
as part of the DLL initialization. This would solve many problems.
Jeffrey Altman
Jiang Lei wrote:
Hi,
Sorry if this message is sent twice.
I got problem running RAND_poll() in multi-threaded programs. The
function sometimes crashes at heap_next(hentry):
...
if (heaplist_first(handle, hlist))
do
{
RAND_add(hlist, hlist.dwSize, 3);
hentry.dwSize = sizeof(HEAPENTRY32);
if (heap_first(hentry,
hlist.th32ProcessID,
hlist.th32HeapID))
{
int entrycnt = 80;
do
RAND_add(hentry,hentry.dwSize, 5);
while (heap_next(hentry)
^
*** this is where the problem is ***
--entrycnt 0);
}
} while (heaplist_next(handle,
hlist));
...
An article at
http://www.codeproject.com/threads/Thelp32ReadProcessMemory.asp revealed
that the function Heap32Next is not appropriate to be used in threaded
programs:
[QUOTE START]
The snapshot
The toolhelp functions make use of a snapshot to access process, thread,
module, and heap lists in the system. To quote MSDN:
The lists in system memory change when processes are started and ended,
threads are created and destroyed, executable modules are loaded and
unloaded from system memory, and heaps are created and destroyed. The
use of information from a snapshot prevents inconsistencies. Otherwise,
changes to a list could possibly cause a thread to incorrectly traverse
the list or cause an access violation (a GP fault). For example, if an
application traverses the thread list while other threads are created or
terminated, information that the application is using to traverse the
thread list might become outdated and could cause an error for the
application traversing the list.
[QUOTE END]
I guess that tells why. The most simple resolution will be to remove
the Heap32Next.(of course
this will trade off rand seed quality, too).
Any ideas?
regards
Lei
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Common Name and IDNA
What follows is simply my opinion but I believe it to be correct: The name must match the text the user entered when specifying the desired host. As such there are multiple input forms which resolve to the same name. Instead of using Common Name you should use subjectAltName and provide two entries; one for each of the UTF8 representation and the ACE representation. Jeffrey Altman Gisle Vanem wrote: How is the /CN= supposed to be encoded for a host/domain- name using international characters? In some specified charset (utf8?) or in the ASCII Compatible Encoded form? I ask since in an application here (using libidn), I get the subject with X509_get_subject_name() and check the CN (or wildcard mask) against the host I connect to. If they don't match, that's an error. E.g. if I connect to www.tromsø.no, it's registered in DNS as www.xn--troms-zua.no. Should the CN be the same also? Is it an error to match the CN against www.tromsø.no too? Guessing beeing liberal is okay... BTW. is there any function in OpenSSL that can match e.g. x*.foo.com against xxx.foo.com? IDNA = Internationalizing Domain Names in Applications, RFC-3490. --gv __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: Inclusion of FIPS
Steve: Thank you for the answer. Just fyi, I and Richard Levitte did spend time to get the code to work on Windows to the extent that was possible without an answer to the questions you have now answered. One concern with your answer is that it appears to imply that FIPS certification can only be useful to applications which statically link in all libraries. Therefore, the openssl distributions which are shipped by Linux vendors in RPMs cannot be considered FIPS certified. Correct? Jeffrey Altman Marquess, Steve Mr JMLFDC wrote: RE: Inclusion of FIPS Jeffrey Altman wrote "There are a couple of things that have been bothering me. (1) I'm not sure the use of .SHA1 files is going to work long term on Windows. First, they are unmanageable when it comes to patches. Second, Windows itself modifies the .EXE/.DLL files to include updating binding information. It seems to me that we need to compute the hash not on the entire .EXE/.DLL file but instead exclude the Run Time Binding data and the Resource data. Then we can store the hash as a resource string bound to the file. Good questions, and you probably won't like the answers. This validation effort is primarily concerned with Unix platforms, though Ben did put a call out for volunteers to work the Windows issues so we could accommodate that platform as much as possible. This validation will be unique in that the source code itself is the object of the validation testing, not a platform specific binary executable or library. As such we had to provide a mechanism for showing that the cryptographic code executing in binary form was derived from the validated source. We also wanted this mechanism to be platform neutral; hence the chain of SHA-1 HMAC signatures from the source code to the library object code to the application executable. Note this only works for static linking, or the special case of a shared library explicitly loaded with a known path. The typical validation doesn't have this problem because it is for a platform specific binary where there runtime integrity check is custom tailored to the specific runtime environment. To do what you suggest (exclude Windows DLL binding and resource data) we would need a Windows specific implementation of FIPS_check_exe(), which as non-portable code would then require testing under Windows. We did not have the funding for that additional testing, and support of Windows was not an explicit goal of the current sponsors. Any new sponsors interested in Windows specific support should contact John Weathersby of the Open Source Software Institute. He can coordinate the arrangements as he did for this current effort. Cost would probably be in the $USD15K ballpark, exclusive of the code development. The good news is that at least we were able to include the x86 specific assembler optimizations in the validation, courtesy of IBM. So Linux and *BSD on x86 are covered. (2) Why is it that the SHA1 hash of the executable linked to LIBEAY32.DLL is being checked and not the hash of LIBEAY32.DLL itself? Are we truly worried about the application being altered and not the crypto library?" The crypto library is statically linked in the application executable, hence the check of the entire application verifies that the embedded crypto code has not changed. Though as you noted if the application executable changes after the *.sha1 file is generated even that will fail. -Steve M. smime.p7s Description: S/MIME Cryptographic Signature
Re: Inclusion of FIPS
Marquess, Steve Mr JMLFDC wrote We are very close (a few days at most) from the point where the 26 special source files in the ./fips/ tree can no longer be modified (or else the FIPS validation won't apply). These files are identified by the SHA-1 HMAC signatures in the fingerprint.sha1 files; these signatures will be immortalized in the validation from NIST. So if there are any last minutes fixes needed please do them now! Steve Marquess DMLSS Technical Manager JMLFDC, 623 Porter Street, Ft. Detrick, MD 21702 DSN 343-3933, COM 301-619-3933, FAX 301-619-7831 [EMAIL PROTECTED] Steve: I asked the following of Ben but never received an answer regarding how library and application verification can be ensured on Windows (and perhaps other platforms): There are a couple of things that have been bothering me. (1) I'm not sure the use of .SHA1 files is going to work long term on Windows. First, they are unmanageable when it comes to patches. Second, Windows itself modifies the .EXE/.DLL files to include updating binding information.It seems to me that we need to compute the hash not on the entire .EXE/.DLL file but instead exclude the Run Time Binding data and the Resource data. Then we can store the hash as a resource string bound to the file. (2) Why is it that the SHA1 hash of the executable linked to LIBEAY32.DLL is being checked and not the hash of LIBEAY32.DLL itself? Are we truly worried about the application being altered and not the crypto library? Can you provide some insight? Thanks. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: Win32 compiles under cygwin
Andy Polyakov wrote: Steven, I've written a command-line utility called gcc2cl which acts like a gcc front-end while using Microsoft's compiler/linker at the backend. It translates options and does some munging of cl's stdout/stderr so as to fool autoconf into thinking it is really using gcc. This enables us (I did this at Computer Associates) to do a fairly standard OpenSSL cygwin build while using the Microsoft compiler/linker/libraries/runtime. Could you elaborate on fairly standard OpenSSL cygwin build. What's considered standard? I assume the way Cygwin is currently supported by OpenSSL... What's fair? What is the actual reason for dismissing gcc and trying to compile cygwin library with Microsoft compiler? Trouble is that Microsoft compiler generates code which is dependent on presence of Visual C run-time environment and it's a slippery way. Presense of 3rd party run-time components in a cygwin application might break some interfaces [fork is first one to come to mind]. Of course you might mean that the only cygwin component you use is make and sh [which is actually appealing!] and that resulting OpenSSL build does not contain any run-time dependencies from cygwin1.dll. But can you call it fairly standard *cygwin* build? Shouldn't it be called fairly standard *Win32* build? A. I believe the OSAF requires a build which has no dependencies on cygwin1.dll. I may very well be wrong but I believe that they are simply using the cygwin environment as a means to remote login via SSH for the purpose of automating the execution of the build process on Windows in a manner equivalent to that which is done on their supported Unix/Linux systems. Jeffrey Altman __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Win32 compiles under cygwin
The libssl.a and libcrypto.a binaries are linked to cygwin1.dll. This is not what you want. You do not want to be using the cygwin build process but the MS Visual Studio build environment. Perhaps you can use the cygwin environment to kick off a normal OpenSSL build in the background. Jeffrey Altman Mark Jaffe wrote: I have one other issue I need resolution on: when I run the make file under cygwin, the resulting libraries are exactly what I get on unix: libssl.a and libcrypto.a. What I want to know is how do I get ssleay32.dll and libeay32.dll? These are required to link m2crypto on Win32. Mark On May 10, 2004, at 5:17 PM, Steven Reddie wrote: Hi Andy, We have standards for the compilers that we use on each platform, and on Windows it is Microsoft's toolset. In our lab we use cygwin for the build framework so that we can use the same framework on Windows and Unix platforms. What I was trying to say was that rather than using the .bat files and nmake makefiles that come with OpenSSL for Windows builds, we use gcc2cl with cygwin and Microsoft's compiler to piggy-back onto the Unix-ey cygwin build target, thereby avoiding the .bat files and nmake files. We therefore pickup the ability to specify no-idea no-rc5 no-mdc2 in the same way for Unix and Windows builds, and the same goes for using the -shared option. It just makes the Windows OpenSSL build integrate into our build framework in the same way that the Unix builds do. Yes, it's a standard Win32. By fairly standard OpenSSL cygwin build I was referring to the parts of the OpenSSL build process that we are using rather than the compiler. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Polyakov Sent: Tuesday, 11 May 2004 3:13 AM To: [EMAIL PROTECTED] Subject: Re: Win32 compiles under cygwin Steven, I've written a command-line utility called gcc2cl which acts like a gcc front-end while using Microsoft's compiler/linker at the backend. It translates options and does some munging of cl's stdout/stderr so as to fool autoconf into thinking it is really using gcc. This enables us (I did this at Computer Associates) to do a fairly standard OpenSSL cygwin build while using the Microsoft compiler/linker/libraries/runtime. Could you elaborate on fairly standard OpenSSL cygwin build. What's considered standard? I assume the way Cygwin is currently supported by OpenSSL... What's fair? What is the actual reason for dismissing gcc and trying to compile cygwin library with Microsoft compiler? Trouble is that Microsoft compiler generates code which is dependent on presence of Visual C run-time environment and it's a slippery way. Presense of 3rd party run-time components in a cygwin application might break some interfaces [fork is first one to come to mind]. Of course you might mean that the only cygwin component you use is make and sh [which is actually appealing!] and that resulting OpenSSL build does not contain any run-time dependencies from cygwin1.dll. But can you call it fairly standard *cygwin* build? Shouldn't it be called fairly standard *Win32* build? A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Mark Jaffe | (415) 946-3028 (work) Release Engineer| (408) 807-2093 (cell) OSAF | (415) 946-3001 (FAX) [EMAIL PROTECTED]| http://www.osafoundation.org/ PGP Fingerprint: 3435 EB88 6424 F5DF F2CA EF16 2DBF DFEF 143C 1ADE __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: Win32 compiles under cygwin
Since the cygwin environment is different from the MS Run Time environment, I would not make the assumption that the binaries produced use exactly the same configuration options. They may but I would not count on it. I understand what you are attempting to do; I just do not know if the results will be the same. I know that with other packages such as Kerberos you absolutely do not get the same result when building under cygwin because the environment is more Unix like and therefore different assumptions are made. Jeffrey Altman Steven Reddie wrote: Jeffrey, Are you saying that using something like gcc2cl to kick off a build the way you do for cygwin, but using the Microsoft compiler, is the wrong way to go? It's working well for us in-house, though we've been using static libraries up until now and are just finishing up changes to support the DLL build. Mark, the naming issue is something that we need to handle also, although we need to use a custom name with the OpenSSL version number included. Whatever we can contribute will include support for altering the name. Steven smime.p7s Description: S/MIME Cryptographic Signature
Re: No CAs in CertificateRequest message
Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Thu, 6 May 2004 08:24:57 -0400, "Erik Tkal" [EMAIL PROTECTED] said: etssl Can anyone answer this? How do I tell if this is a known etssl problem with OpenSSL or if the RFC is incorrect, or if this is etssl just a accepted deviation? I can't really say, as that's not my forte in OpenSSL, so what I say is just a guess. There are several places in OpenSSL (some ASN.1 stuff among others, IIRC) where the standards aren't entirely followed to the letter (you could say that the standards have been expanded a little bit, to be kind), so as not to break with some other software (I think Microsoft is often mentioned at this point...) that deviates from standards a little bit. My guess is that this possibility to generate an empty list of ceritificate requests may be that kind of deviation. I would love it if those in the team that really know the SSL parts could give an accurate response... I am certainly not an expert, but I thought the bending of the rules was on the side of accepting things that were not standard; not generating things which were not standard. At least anything that would result in generating non-standard output should have a SSL_OP flag associated with it. What code is being executed that is causing the zero length CA list? smime.p7s Description: S/MIME Cryptographic Signature
Re: No CAs in CertificateRequest message
I'm looking at the TLS 1.1
Internet-Draft and it reads:
7.4.4. Certificate request
When this message will be sent:
A non-anonymous server can optionally request a certificate from
the client, if appropriate for the selected cipher suite. This
message, if sent, will immediately follow the Server Key Exchange
message (if it is sent; otherwise, the Server Certificate
message).
Structure of this message:
enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), |
fortezza_dms_RESERVED(20), |
(255)
} ClientCertificateType;
opaque DistinguishedName1..2^16-1;
struct {
ClientCertificateType certificate_types1..2^8-1;
DistinguishedName certificate_authorities0..2^16-1; |
} CertificateRequest;
certificate_types
This field is a list of the types of certificates requested, |
sorted in order of the server's preference. |
certificate_authorities
A list of the distinguished names of acceptable certificate
authorities. These distinguished names may specify a desired
distinguished name for a root CA or for a subordinate CA;
thus, this message can be used both to describe known roots |
and a desired authorization space. If the |
certificate_authorities list is empty then the client MAY |
send any certificate of the appropriate |
ClientCertificateType, unless there is some external |
arrangement to the contrary. |
Reading through the minutes and mailing lists of IETF TLS Working
Group, it is
clear that this change was made because the vast majority of
implementors
had already been allowing a certificate request to be sent without a
certificate authority name being specified. In TLS 1.0, according to
the spec
there must be at least one certificate_authority specified in the list.
To be compliant with TLS 1.0 you must call SSL_set_client_CA_list() with
at least one certificate authority. However, the general consensus as
indicated
in TLS 1.1 is that the specification of a certificate authority should
not be
required.
TLS 1.1 has passed last call and is currently being reviewed by the
IESG.
Jeffrey Altman
Erik Tkal wrote:
Jeff,
Look ins3_srvr.c -
ssl3_send_certificate_requestcalls SSL_get_client_CA_list to get the
stack of CA names(assumedly set by other code having called
SSL_set_client_CA_list). However, if the server side code has not set
this then the stack is empty, so the code ends up setting the 2-byte
length field to 0x and appending no further data to the message.
So the questions that remain are:
1) Is this ok and should clients be
required to handle this, and if so where is this documented?
2) If it is required for the server
implementation to call SSL_set_client_CA_list, shouldan error be
surfaced at some point when this is detected?
3) If a server implementation is to call
SSL_set_client_CA_list how should it specify that it does not care what
the client sends (assuming it will check against trusted roots later)?
I could contend that a server implementation may not want to give such
hints to a client and assume that clients it trusts will present proper
credentials based on proper configuration.
Erik Tkal
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of Jeffrey Altman
Subject: Re: No CAs in CertificateRequest message
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Thu, 6 May 2004 08:24:57 -0400, "Erik Tkal" said:
etssl Can anyone answer this? How do I tell if this is a known
etssl problem with OpenSSL or if the RFC is incorrect, or if this is
etssl just a accepted deviation?
I can't really say, as that's not my forte in OpenSSL, so what I say
is just a guess.
There are several places in OpenSSL (some ASN.1 stuff among others,
IIRC) where the standards aren't entirely followed to the letter (you
could say that the standards have been expanded a little bit, to be
kind), so as not to break with some other software (I think Microsoft
is often mentioned at this point...) that deviates from standards a
little bit.
My guess is that this possibility to generate an empty list of
ceritificate requests may be that kind of deviation.
I would love it if those in the team that really know the SSL parts
could give an accurate response...
I am certainly not an expert, but I
thought the bending
of the rules was on the side of accepting things that were
not standard; not generating things which were not standard.
At least anything that wo
Re: Windows DLL naming inconsistency
Andy Polyakov wrote:
Now let's imagine we pick Microsoft compiler. I'd suggest to perform an
MT build and link it dynamically with MSVCRT.DLL. Idea is to use MSVCRT
primarily for BIO and other strictly internal purposes (keep in mind
that MSCVRT.DLL can be redistributed). At the same time I'd sanitize
functions appearing in grep 'FILE \*' include/openssl/* and replace
calls to stdio with wrappers, which would treat FILE * as opaque
pointer. Idea is to link these wrappers to corresponding stdio functions
provided by compiler environment at run-time. How? We could require user
application to be linked with a module of own design, which exports a
symbol, and then we could refer to this symbol from DllMain in
libeay32.dll for the purposes of linking the wrappers with vendor stdio.
For example. Supplied code to be compiled and linked with user
application could look as following (this is just an example!):
static void *link_table[]={stdin,stout,stderr,fprintf,fread,fclose};
void ** __declspec(dllexport) get_link_table() { return link_table; }
While DllMain in libeay32.dll could:
h=GetModuleHandle(NULL);//.exe image used to create the calling process
proc=GetProcAddress(h,get_link_table);
if (proc==NULL) report_or_log_error_and_exit();
tbl=(*proc)(); // use tbl to feed the wrappers
It should be enough to simply add the supplied module to the target
project to make magic happen and work with any run-time environment or
flag combination. There is a minor problem with Borland, which insists
on different function name decoration and uses different .LIB format,
but it seems that it can be easily resolved with IMPLIB... Thoughts? A.
I like it! :-)
Three comments:
* Do we really need to have the get_link_table function? I think
we should be able to import just the link table itself
* We can define the link table in a header file and have the user
simply include the header file in only one place OR provide a
#define prior to the #include to define the link table in only one
place
* The link table should contain a table format version number so
that in case we need to grow the table in the future it will be
possible to do so and produce the appropriate compatibility errors.
- Jeff
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Windows DLL naming inconsistency
We have the following variables which we want to express in the name of the dll: 1. run-time library [compiler x threading x debugging] Compilers: cygwin versions msvc 6.0 msvs .net msvs .net 2003 others? Threading; linked to threaded run-time linked to non-threaded run-time Debugging: linked to debugging run-time linked to non-threaded run-time 2. 32-bit vs 64-bit 3. openssl version 4. with or without kerberos or some other openssl feature? and we need to do all of this in 8.3 notation. This is not going to be pretty. Assuming we allocate one character to represent compilers in a table; one character to represent threading and debugging and 32/64-ness; two characters for openssl version; this leaves four characters for a descriptive name. The primary motivation for this in my mind is that too many companies are beginning to install OpenSSL binaries into the System Path on Windows (or worse the \Windows\System32 directory). This causes other apps to break. Now, we could avoid all of this by simply requiring software vendors to follow IBM's rules for redistribution of run time dependent components. You must redistribute the components using application specific naming conventions in order to avoid conflicts with other applications which might rely on different versions of the same component. This last item is probably the easiest to implement. Jeffrey Altman Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Sun, 25 Jan 2004 11:02:06 -0500, Jeffrey Altman [EMAIL PROTECTED] said: jaltman I think there are two very different markets. One is the jaltman cygwin (unix on windows) environments which expect things to jaltman be named the way they are on Unix/Linux. The other is the jaltman native windows environment which expects naming to be as it jaltman has been on Windows. I think both need to be supported jaltman therefore there should not be a name collision. I entirely agree with the idea of following the standard set in the environment you work in. However, if we look at the file name without the extension, I'm only aware of a naming standard on Unix (libraries start with lib) and VMS (it's a little bit more complex, and includes things like a prefix for the utility or language the library is connected to, and usually includes the word SHR for shareable libraries, although I see a lot of variety still...). I'm not aware of any naming convention for Windows libraries, and haven't been able to get a straight answer when I ask (and if you look at the variants of LIBC that comes with MSVC, you see a bit of variety there as well). On Windows, there's the added complexity of using different run-time libraries depending on if you're using threads or not, if you built in debug mode or not, and other details I'm not aware of. I've heard suggestions of creating several variants of the OpenSSL libraries that would be used in parallell with the different MSVC libraries, and that's where a naming convention is becoming even more important. Added to this problem, we have the different register sizes on different CPUs (32-bit, 64-bit, and whatever will follow), which seems to be difficult to intermix in the same library, and thereby requires another bit of information that may need to be included in library file names, and as far as I understand, no-one has yet come up with a commonly accepted standard. I would love it if someone could point out a standard for each operating system family (Unix, Windows, VMS, ...) and if we could figure out a way to adhere to that in a meaningful way. Thoughts? Opinions? Wishes to strangle me for sturring this up :-)? - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. smime.p7s Description: S/MIME Cryptographic Signature
Re: Windows DLL naming inconsistency
Andy Polyakov wrote: That would be great, so how does one do that? Note that I didn't say it would be trivial, nor that I know exactly how to actually do it:-) I merely said that having observed how system components [e.g. KERNEL32] are linked there seem to be a way to achieve this [noble] goal. Step in the direction would be to understand exactly *why* it's not possible to interchange /MD and /MDd versions. The conclusion might be hard to accept. As it might turn out that the only way is to break dependency from MSVCRT, but the catch is that it's MSVCRT stands for stdio.h, malloc.h and string.h. malloc.h and string.h are relatively easy to replace (e.g. by linking with the static LIBC), but probably not stdio.h (linking it statically probably won't work as it most likely will interfere with another copy of stdio and one most likely will have to implement some ascetic replacement). A. What you do is not link to a run-time library and instead use the equivalent versions provided by the Windows kernel as defined in WinBase.h. For string functions you use: lstrcmp lstrcmpi lstrcpyn lstrcpy lstrcat lstrlen For file operations you use: _lopen _lcreat _lread _lwrite _hread _hwrite _lclose _llseek For memory allocation you use a combination of: GlobalAlloc LocalAlloc HeapAlloc TlsAlloc(thread local) depending on what is necessary. Basically, we would approach this by implementing our own run-time library which is in turn implemented in base OS functions. Then we would link the DLL without a run time library. Remember the dependency on the type of run time library is caused by passing of things like FILE pointers and Memory allocations across the application / library boundary. If you can ensure that there are no such crossings then you do not have a dependency. However, with the BIO code I am not sure this is a possibility. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: Windows DLL naming inconsistency
Dr. Stephen Henson wrote: That I believe is the main problem: all the runtime library dependencies which directly or indirectly call incompatible library functions. There was an attempt to fix this back in SSLeay where the application called one function which passed pointers to the malloc routines but it never worked. I suspect the reason is that it didn't go far enough: it would have to also pass pointers to things like stdio functions too. The passing of the memory functions was good enough to allow you to move between debug and non-debug versions of the same library (compiler version and threading model.) It is not good enough to all total portability since there a many classes of run-time functions which have internal data structure dependencies depending on the compiler version and the threading model. The stdio functions are another example of these. An easy way to figure out where the dependencies lie are to compare the data structure definitions in the CRT headers. If there are #ifdef's in the data structure definition then you know there is a guarranteed compatibility issue. smime.p7s Description: S/MIME Cryptographic Signature
Re: Windows DLL naming inconsistency
Andy Polyakov wrote: That's why I wrote that it might be hard to accept, because it's really the last thing we want to do, implement own run-time environment, isn't it? But note that there *are* system DLL which are linked with MSVCRT.DLL. E.g. CRYPT32.DLL imports string functions and malloc/free, while WS32_32.DLL imports fopen, fclose, fgets and some string functions... How does it work there? A. You can link to a C Run Time within a DLL as long as you are not sharing data structures with your caller. WS32_32.DLL can use fopen() because it does not accept FILE * from its callers. All of the use of fopen() is local to its own implementation. Threading issues if any are handled internally by ensuring that calls are not made outside of a mutex semaphore lock. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: Windows DLL naming inconsistency
Why do you believe that stunnel represents the most widely used naming? There are widely deployed applications from IBM (ships as part of the Access IBM service) Time Warner's Road Runner The Kermit Project (Kermit 95) and many others who distribute ssleay32.dll and libeay32.dll. If anything I would argue that the naming convention needs to be modified to include the version number so as to prevent conflicts between 0.9.5, 0.9.6, 0.9.7, and 0.9.8 all of which have incompatible ABIs. Jeffrey Altman Martin Germann wrote: Hi, I noticed an inconsistency in the windows library names: When compiling OpenSSL on windows with gcc (MinGW), the resulting ssl library is called 'libssl32.dll'. Using MS Visual C++ (and Borland C++, i suppose), the resulting binary will be called 'ssleay32.dll'. This may cause a lot of confusion for users compiling OpenSSL on Win32. Therefore, I suggest to modify the targets for Visual C++ and Borland C++ to also build 'libssl32.dll', as this target name seems to be most widely used (e.g. stunnel). Regards, Martin __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
[openssl.org #807] 0.9.7 snapshot patches for compilation on Windows
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #806] 0.9.8 snapshot patches for compilation on Windows
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #753] 0.9.6l does not compile on Windows
The inclusion of e_os.h in crypto\des\cfb_enc.c must be specified as either #include openssl/e_os.h or #include ../e_os.h This is not performed in a consistent manner in OpenSSL 0.9.6. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #753] 0.9.6l does not compile on Windows
Richard Levitte - VMS Whacker via RT wrote: In message [EMAIL PROTECTED] on Wed, 5 Nov 2003 08:42:39 +0100 (MET), Jeffrey Altman via RT [EMAIL PROTECTED] said: rt rt The inclusion of e_os.h in crypto\des\cfb_enc.c must be specified as rt either rt rt #include openssl/e_os.h Absolutely not! Well, the reason I say that is because of the following grep output which clearly shows that openssl/e_os.h is used more often than not. GLOBAL: C:\src\openssl\0.9.6l GLOBAL: C:\src\openssl\0.9.6l\apps GLOBAL: C:\src\openssl\0.9.6l\apps\demoCA GLOBAL: C:\src\openssl\0.9.6l\apps\demoCA\private GLOBAL: C:\src\openssl\0.9.6l\apps\set GLOBAL: C:\src\openssl\0.9.6l\bugs GLOBAL: C:\src\openssl\0.9.6l\certs GLOBAL: C:\src\openssl\0.9.6l\certs\expired GLOBAL: C:\src\openssl\0.9.6l\crypto GLOBAL: C:\src\openssl\0.9.6l\crypto\asn1 GLOBAL: C:\src\openssl\0.9.6l\crypto\bf bftest.c:#include ../e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\bf\asm GLOBAL: C:\src\openssl\0.9.6l\crypto\bio bss_bio.c:#include openssl/e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\bn bntest.c:#include openssl/e_os.h exptest.c:#include ../e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\bn\asm GLOBAL: C:\src\openssl\0.9.6l\crypto\bn\asm\alpha GLOBAL: C:\src\openssl\0.9.6l\crypto\bn\asm\alpha.works GLOBAL: C:\src\openssl\0.9.6l\crypto\bn\asm\x86 GLOBAL: C:\src\openssl\0.9.6l\crypto\buffer GLOBAL: C:\src\openssl\0.9.6l\crypto\cast casttest.c:#include ../e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\cast\asm GLOBAL: C:\src\openssl\0.9.6l\crypto\comp GLOBAL: C:\src\openssl\0.9.6l\crypto\conf conf_api.c:#include openssl/e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\des cfb_enc.c:#include openssl/e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\des\asm GLOBAL: C:\src\openssl\0.9.6l\crypto\des\t GLOBAL: C:\src\openssl\0.9.6l\crypto\des\times GLOBAL: C:\src\openssl\0.9.6l\crypto\dh dhtest.c:#include ../e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\dsa dsatest.c:#include ../e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\dso GLOBAL: C:\src\openssl\0.9.6l\crypto\err GLOBAL: C:\src\openssl\0.9.6l\crypto\evp GLOBAL: C:\src\openssl\0.9.6l\crypto\hmac hmactest.c:#include ../e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\idea ideatest.c:#include ../e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\lhash GLOBAL: C:\src\openssl\0.9.6l\crypto\md2 md2test.c:#include ../e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\md4 md4test.c:#include ../e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\md5 md5test.c:#include ../e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\md5\asm GLOBAL: C:\src\openssl\0.9.6l\crypto\mdc2 mdc2test.c:#include ../e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\objects GLOBAL: C:\src\openssl\0.9.6l\crypto\pem GLOBAL: C:\src\openssl\0.9.6l\crypto\perlasm GLOBAL: C:\src\openssl\0.9.6l\crypto\pkcs12 GLOBAL: C:\src\openssl\0.9.6l\crypto\pkcs7 GLOBAL: C:\src\openssl\0.9.6l\crypto\pkcs7\p7 GLOBAL: C:\src\openssl\0.9.6l\crypto\pkcs7\t GLOBAL: C:\src\openssl\0.9.6l\crypto\rand md_rand.c:#include openssl/e_os.h randfile.c:#include openssl/e_os.h randfile.c:/* #define RFILE .rnd - defined in ../../e_os.h */ randtest.c:#include ../e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\rc2 rc2test.c:#include ../e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\rc4 rc4test.c:#include ../e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\rc4\asm GLOBAL: C:\src\openssl\0.9.6l\crypto\rc5 rc5test.c:#include ../e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\rc5\asm GLOBAL: C:\src\openssl\0.9.6l\crypto\ripemd rmdtest.c:#include ../e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\ripemd\asm GLOBAL: C:\src\openssl\0.9.6l\crypto\rsa rsa_test.c:#include openssl/e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\sha sha1test.c:#include ../e_os.h shatest.c:#include ../e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\sha\asm GLOBAL: C:\src\openssl\0.9.6l\crypto\stack GLOBAL: C:\src\openssl\0.9.6l\crypto\threads mttest.c:#include ../../e_os.h th-lock.c:#include openssl/e_os.h GLOBAL: C:\src\openssl\0.9.6l\crypto\txt_db GLOBAL: C:\src\openssl\0.9.6l\crypto\x509 GLOBAL: C:\src\openssl\0.9.6l\crypto\x509v3 GLOBAL: C:\src\openssl\0.9.6l\demos GLOBAL: C:\src\openssl\0.9.6l\demos\bio GLOBAL: C:\src\openssl\0.9.6l\demos\eay GLOBAL: C:\src\openssl\0.9.6l\demos\maurice GLOBAL: C:\src\openssl\0.9.6l\demos\pkcs12 GLOBAL: C:\src\openssl\0.9.6l\demos\prime GLOBAL: C:\src\openssl\0.9.6l\demos\sign GLOBAL: C:\src\openssl\0.9.6l\demos\ssl GLOBAL: C:\src\openssl\0.9.6l\demos\state_machine GLOBAL: C:\src\openssl\0.9.6l\doc GLOBAL: C:\src\openssl\0.9.6l\doc\apps GLOBAL: C:\src\openssl\0.9.6l\doc\crypto GLOBAL: C:\src\openssl\0.9.6l\doc\ssl GLOBAL: C:\src\openssl\0.9.6l\inc32 GLOBAL: C:\src\openssl\0.9.6l\inc32\openssl GLOBAL: C:\src\openssl\0.9.6l\include GLOBAL: C:\src\openssl\0.9.6l\include\openssl GLOBAL: C:\src\openssl\0.9.6l\MacOS GLOBAL: C:\src\openssl\0.9.6l\MacOS\GetHTTPS.src GLOBAL: C:\src\openssl\0.9.6l\ms GLOBAL: C:\src\openssl\0.9.6l\out32dll GLOBAL: C:\src\openssl\0.9.6l\perl GLOBAL: C:\src\openssl\0.9.6l
Re: Slow heap walking in rand_win.c
If that is the case, then THAT is the bug to be fixed. - Jeffrey Altman Lee Dilkie wrote: You can always implement your own source of random data and push it into the OpenSSL engine. If you do that the rand_win code will not be executed. Jeffrey Altman As far as I can tell from reading rand_win.c and md_rand.c, this is not the case. Calling any of the useful rand functions, see ssleay_rand_status() for example, results in RAND_poll() being called because the global initialized is not set. RAND_poll() calls the heapwalking stuff in windows. Calling ssleay_rand_add() (same as RAND_add) does not set the initialized flag so there is no way to stop the lengthy heapwalk without hacking the source. Please correct me if I'm wrong. regards, -lee __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: Slow heap walking in rand_win.c
I do not actually believe that a one time 30 second delay during process initialization is inappropriate for a security application. In the discussions that are being held with regards to the use of AES in conjunction with Kerberos there is a belief that 30 seconds should be the minimum amount of time taken to perform the crypto operations for processing a password to key operation. This is to ensure that there is not the opportunity for offline dictionary attacks on passwords. The 30 second delay for random key data initialization does not have to be a blocking operation for the initialization of the application. It can be done in parallel to other operations your app requires unless the first thing that is performed are SSL/TLS operations. I also wonder what it is that your application is doing at initialization time that results in a heap size of greater than several hundred megs. You should be initializing the random number generator when your application starts; not when you have to perform your first SSL/TLS handshake. Jeffrey Altman [EMAIL PROTECTED] wrote: I know this has been brought up a few times on this list - but since I consider it a severe problem and I haven't found an acceptable solution anywhere, I bring it up again. Random number generation in crypto/rand/rand_win.c can be extremely slow! In our application (connecting to a SSL web service), it takes up to 30 (THIRTY) seconds to initialize the random number. (On a 2.4 GHz Pentium 4) The reason is the heap walking algorithm (the Heap32Next procedure in the Toolhelp32 snapshot section). What makes the problem harder is that it only occurs if the calling process' heap is large, i.e. you don't notice the problem with a small test program. I know little about SSL and very little about random number generation, so I can't provide a patch. I just lowered the number of heap entries to 2, i.e. changed int entrycnt = 80; in the RAND_poll() procedure in rand_win.c to int entrycnt = 2; which made it fast enough for me - but if it's secure enough in the general case, I can't say. I know the problem only affects the windows implementation, so maybe this problem persists in order to prove that windows is slow :-) If that isn't the case, couldn't some reliable intelligent person do one of the following: - provide info how to avoid this problem without hacking the source - check or add code to check if a lower entrycnt would be acceptable in the general case - check or add code to check if the heap walking is necessary at all - make the entrycnt configurable and add it to the INSTALL.W32 file - add this problem to the PROBLEMS file Thanks Frank Ammeter --- Versendet mit dem IPSHOST.CH E-Mail Service WEBHOSTING:500MB Speicherplatz für Fr.24.95 http://www.ipshost.ch __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: Slow heap walking in rand_win.c
Lee Dilkie wrote: well, it's a bit more complicated than that. all the heaps of all the processes are walked. They don't have to be big, just lots of them. Which is why this isn't a problem on some systems running few processes or with small heap list lengths and is a big problem on others systems (desktops of power users, for example). My Solution... I hacked the code to get rid of the heap walk and just used the entropy from the process, thread and module walk. My application didn't need that paranoid a level of security. But personally, I think these methods should be exposed openssl library calls that the application can pick and choose. -lee You can always implement your own source of random data and push it into the OpenSSL engine. If you do that the rand_win code will not be executed. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: BUG: CreateToolhelp32Snapshot
The reason that we go to all this trouble to examine alternative sources of randomness other than CryptGetRandom() is that Microsoft has refused to publish the sources of randomness which are used. Therefore, we have no ability to know whether or not the randomness reported by Windows is in fact random. The fundamental trouble with the ToolHelp32 and HKEY_PERFORMANCE_DATA when used in Services is that at the time the service is being loaded and this code may be executing we are unaware of what other services must first be loaded and initialized in order for them to work properly. We never hear of problems for client applications. Nor do I ever see problems with this code in the Internet Kermit Service when loaded on NT/2000/2003 server. The IKS installs a small Windows Service which then spawns processes which execute RAND_poll(). My assumption is that those users who are having problems do not have the proper set of dependencies set. Therefore, RAND_poll() is executed when the necessary conditions are not quite met. Of course, I have never had time to investigate this in detail. I wish I had the time. I wish we had a function that could determine if we were running as a service. If so, we might be able to tailor this code to behave differently. Jeffrey Altman Richard Levitte - VMS Whacker wrote: cardbox As for the Windows 2003 Server crash: I agree that disabling cardbox sections of code is a Bad Thing. What I've done (pending more cardbox people researching the problem) is to put cardbox BOOL bMJKGotRandomness=FALSE; cardbox at the start of RAND_poll cardbox bMJKGotRandomness=TRUE; cardbox when either of the CryptGenRandom calls succeeds. Then cardbox if (kernel) cardbox can become cardbox if (!bMJKGotRandomness kernel) cardbox cardbox ... which seems a reasonably conservative way round the cardbox problem. [The variable name isn't vanity, it's just that I cardbox want to be able to recognise my own code so I know what cardbox patches to re-apply to later releases of OpenSSL]. OK, I'll look at that later today. cardbox For those who are trying to reproduce the bug: I wonder if cardbox perhaps MS have decided that ToolHelp is too powerful to be cardbox safe and have started requiring that you have some sort of cardbox special permissions to access it. This is just a thought in cardbox case the bug turns out to be hard to reproduce. Hmm, again, I think don't say it... applies again. The gods may have a wry sense of humor today, and you may get what you wish for (regardless of whether you actually do or don't). *sacrifices a rubber ducky on a VAX altar* smime.p7s Description: S/MIME Cryptographic Signature
Re: HKEY_PERFORMANCE_DATA
If you read the knowledge base article you will see that the exceptions are caught properly on Win2000 and above. However, on NT4 third party devices which plug-in to the performance engine did not always do the right thing and let exceptions slip out. I think this is what is causing the crashes on some servers and not others. There is still an issue of dependence on the COM engine. Services employing OpenSSL must be loaded after the DCOM service has started. Jeffrey Altman Martin Kochanski wrote: If we're going to try exception handling then I suppose that CreateToolhelp32Snapshot could be wrapped in a handler as well... although I'd still be worried that some internal bit of Windows could be left in a state as a result of the exception. smime.p7s Description: S/MIME Cryptographic Signature
Re: AW: AW: AW: BUG: CreateToolhelp32Snapshot, check if running asNT service
Ingo: In other words, this test cannot work in all cases based upon the knowledge of the OpenSSL developers because the account under which the program executes is determined by the local system administrator OR the application developer. All three of these tests would fail for my use of OpenSSL in Kermit. The parent process is an INETD equivalent and the SID is recommended to be an account with restricted privileges. Kermit (being a network service for remote users) also changes the account of the process to that of the logged in end-user was authentication is complete. Now that we know how to fix the ToolHelp32 API to work on NT4 (use Unicode only) we can walk the process list and check all parents until we find either services.exe or winlogon.exe. If we find winlogon.exe we know we are not a service. If we find services.exe we know we are a service. If we are in limbo we can check for the Local System account. If we find that we can assume we are a service. If we are still in limbo we would need to not attempt to use tests which might fail if running as a service. - Jeff Ingo A. Kubbilun wrote: Hi, to make things clear, how to check if a Win32 exe is currently running as a NT service: 1.) Check if the SID (security ID) of the current process is S-1-5-18, i.e. the so called LOCALSYSTEM account. This changes if you configure your service (in the services control panel) to run on a different account. 2.) Check if the parent process of your service is services.exe, the service control manager. 3.) Check if the parent process of this parent process is winlogon.exe. I always use all three checks (a little bit paranoid) but it is sufficient to check the SID. You can bypass the 2nd and 3rd checks by passing NULL, thus: IsService(NULL,NULL,SID string) At least, the 3rd parameter must be fixed at link time or check #1 will fail at run time. Just pass the same SID that you are using in the installation procedure of your service. The default account is always LOCALSYSTEM. As an alternative, you can just check if the parent process of your process is services.exe, the Service Control Manager. All NT services run on behalf of the SCM. This is static on all Windows versions running services. Rgs, Ingo. smime.p7s Description: S/MIME Cryptographic Signature
HKEY_PERFORMANCE_DATA
In case someone has time to look at RAND_poll(). Here is a new KB article describing restrictions which can be placed on Performance Data: http://support.microsoft.com/default.aspx?scid=kb;en-us;146906 -- This KB article explains why using performance data on NT4 SP6 would hang plus a workaround (use the Unicode version instead of the ANSI version): http://support.microsoft.com/default.aspx?scid=kb;en-us;226371 Therefore the call to RegQueryValueEx() must be replaced with RegQueryValueExW() and TEXT(Global) should be replaced with LGlobal. -- This KB article explains why exceptions may be thrown or why the data returned from a performance data call would be invalid: http://support.microsoft.com/default.aspx?scid=kb;en-us;178887 We may need to wrap calls probing HKEY_PERFORMANCE_DATA in an exception handling block. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: AW: BUG: CreateToolhelp32Snapshot, check if running as NT service
Ingo:
Thanks for the function. Can you provide a complete blackbox solution
that is simply
BOOL IsService(void)
Please keep in mind that within the RAND_poll() function we have no
input from the application as to the service name, logon session or
account. All of that information would need to be extracted at runtime.
I assume this could be done by extracting information from an
OpenProcess() call. If you could provide the complete solution that
would be very much appreciated.
- Jeff
Ingo A. Kubbilun wrote:
Hi,
someone asked for a function to determine if a Win32 exe is running
as a NT service?
Use svccheck.c and svccheck.h, just call:
if (IsService(EXENAME_SERVICES,EXENAME_WINLOGON,SYSTEM_SID))
{
...
}
If you are running your service on a different account than the well
known SYSTEM_SID, which is S-1-5-18, then specify your specific
one as the 3rd param (zero-terminated string).
Rgs, Ingo.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [openssl.org #655] Kerberos: solaris 9 openssl-0.9.7b compileproblem
Remove FAR from the two locations it is specified in the KSSL_CTX data structure. MIT Kerberos 1.3 no longer provides dummy definitions for FAR as all support for 16-bit platforms (MS-DOS) has been removed. Jeffrey Altman Wayne Rasmussen via RT wrote: config -t results in: Configuring for solaris-sparcv9-gcc /bin/perl ./Configure solaris-sparcv9-gcc --with-krb5-flavor=MIT make has the following warnings: a_type.c:74: warning: dereferencing type-punned pointer will break strict-aliasing rules x_name.c:171: warning: dereferencing type-punned pointer will break strict-aliasing rules x_name.c:177: warning: dereferencing type-punned pointer will break strict-aliasing rules x_name.c:239: warning: dereferencing type-punned pointer will break strict-aliasing rules x_name.c:242: warning: dereferencing type-punned pointer will break strict-aliasing rules pem_lib.c:479: warning: dereferencing type-punned pointer will break strict-aliasing rules ../include/openssl/kssl.h:134: warning: no semicolon at end of struct or union ../include/openssl/kssl.h:135: warning: type defaults to `int' in declaration of `KSSL_CTX' ../include/openssl/kssl.h:135: warning: data definition has no type or storage class ../include/openssl/kssl.h:148: warning: type defaults to `int' in declaration of `kssl_ctx_new' ../include/openssl/kssl.h:148: warning: data definition has no type or storage class ../include/openssl/kssl.h:149: warning: type defaults to `int' in declaration of `kssl_ctx_free' ../include/openssl/kssl.h:149: warning: data definition has no type or storage class ../include/openssl/ssl.h:909: warning: no semicolon at end of struct or union smime.p7s Description: S/MIME Cryptographic Signature
Re: [openssl.org #550] bug report - library and header version mismatch
This is not a bug. You must recompile SSH if you want the header version within the executable to change. [EMAIL PROTECTED] via RT wrote: Hi Folks I have noticed that the internal version number of of opensslv.h (0x0090701fL) and the internal version number of libcrypto.so.0.9.7 and libssl.so.0.9.7 (0x0090700fL) do not match for openssl-0.9.7a. They also do not match in openssl-0.9.7-stable-SNAP-20030326. This version mismatch is causing configuration of openssh-3.5p1 to fail with the following error message: checking OpenSSL header version... 90701f (OpenSSL 0.9.7a Feb 19 2003) checking OpenSSL library version... 90700f (OpenSSL 0.9.7 31 Dec 2002) checking whether OpenSSL's headers match the library... configure: error: Your OpenSSL headers do not match your library Here is the self-test report: OpenSSL self-test report: OpenSSL version: 0.9.7a Last change: In ssl3_get_record (ssl/s3_pkt.c), minimize information... Options: --openssldir=/usr/local/OpenSSL threads shared no-krb5 OS (uname): Linux dgrunt 2.4.20 #1 Wed Mar 19 13:10:00 EST 2003 i586 unknown OS (config): i586-whatever-linux2 Target (default): linux-k6 Target: linux-k6 Compiler: gcc version 2.95.3 20010315 (release) Test passed. Test report in file testlog What can I do to fix this? Thanks -- Ken -- [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: [ADVISORY] Timing Attack on OpenSSL
This is a different vulnerability. The one you patched two weeks ago was caused by a failure to decrypt messages when the MAC comparison failed. This vulnerability is a timing attack against the RSA algorithms. The Slashdot discussion is here: http://slashdot.org/article.pl?sid=03/03/14/0012214mode=threadtid=172 The paper is here: http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html Christopher Fowler wrote: Is this a new advisory. I've patched for a previous timing attack 2 weeks ago. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #536] Bug in kssl ?
I will look into this in a few days. I am sorry but I do not have the time at the moment. - Jeff Markus Moeller wrote: On Wednesday 12 Mar 2003 16:48, [EMAIL PROTECTED] via RT wrote: A further check showed it is in kssl_TKT2tkt after the kssl_build_principal_2, because asn1ticket-encdata-kvno is NULL. I get the same error on Solaris 2.8 with MIT Kerberos 1.2.4 new5ticket-enc_part.kvno = asn1ticket-encdata-kvno-data[0]; Markus I use openssl 0.9.7a with MIT Kerberos 1.2.4 and try to use Kerberos authentication/encryption. To test the functionality I tried ssltest as shown below. I run Suse 8.1 with uname -a Linux moelma 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i686 unknown No kinit ssltest failed as expected. ./ssltest -v -d -cipher EXP-KRB5-DES-CBC-MD5 client waiting in SSL_connect - before/connect initialization ERROR in CLIENT 7703:error:140740B5:SSL routines:SSL23_CLIENT_HELLO:no ciphers available:s23_clnt.c:274: moelma:/usr/src/packages/SOURCES/openssl-0.9.7a/test # kinit moelma Password for [EMAIL PROTECTED]: After kinit ssltest starts and core dumps in kssl_build_principal_2 moelma:/usr/src/packages/SOURCES/openssl-0.9.7a/test # ./ssltest -v -d -cipher EXP-KRB5-DES-CBC-MD5 client waiting in SSL_connect - before/connect initialization server waiting in SSL_accept - before/accept initialization client waiting in SSL_connect - SSLv2/v3 read server hello A server waiting in SSL_accept - SSLv3 read client certificate A Segmentation fault Is this a bug or did I miss something ? Markus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #481] (0.9.7 on Win32) openssl ca crashes when exiting...
Richard Levitte via RT wrote: OK, does anyone know a good way to detect (in run-time!) when the program is running as a service? If there's a way, the rest should be easy. Sorry I have been out of contact on this issue but the problems here are not about OpenSSL being used within a service but how OpenSSL is used within a service. Kermit 95 uses OpenSSL and it can be installed as a service and the RAND_poll() functions work just fine. Accessing the desktop will not be a fatal error if it cannot be reached. Where the problem lies is in the calls to obtain performance data. If RAND_poll() is called from within a DLL initialization function and if the service uses OLE components there is a race condition in which the internal process data structures necessary to read the performance data and/or walk the tree are not yet stable. Attempts to process the performance data can therefore result in unexplained exceptions. What we need is not a way to determine if we are running as a service BUT a way to give developers the ability to tell OpenSSL how the library is being used so that we know whether or not it is safe to perform certain types of randomness gathering. - Jeff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #441] bug in win32 test
By any chance did you install the Visual C++ Processor Pack? It replaces the Back End compiler (C2.DLL). Apparently, this upgrade to support new processors is a bit buggy. If you need support for new instruction sets upgrade to VC++ 7.0. Michael Hunley via RT wrote: OpenSSl v0.9.7 on Windows XP Home Using MSVC 6 sp 5 with Masm I'm not sure this is a bug or an issue with network connections. I compiled the source and ran the test app (ms/test.exe) and got the following error: test sslv3 ERROR in SERVER 2212:error:1408F455:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:.\ssl\s3_pkt.c:453: SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 512 bit RSA problems. Is this a problem on my end or an old test that is out of date? thanks. Michael Hunley Senior Engineer PocketPurchase, Inc. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #425] Build error on Windows NT4?
Andy Polyakov via RT wrote:
cl ... -c .\crypto\asn1\n_pkey.c
.\crypto\asn1\n_pkey.c(96) : error C2370: 'NETSCAPE_ENCRYPTED_PKEY_it' :
redefinition; different storage class
.\crypto\asn1\n_pkey.c(93) : see declaration of
'NETSCAPE_ENCRYPTED_PKEY_it'
Strange, I checked VC++ 6.0 SP3 and had no problems. What version of
VC++ are you using?
First of all I want to make it clear that I do *not* have environment
for VC-WIN32 build. All I say here is based on experinence not related
to OpenSSL.
How does one tell VC++SP level? I couldn't find a way. It's probably
more appropriate to ask for version number returned by cl. Mine says
12.00.8804...
In either case I believe it's OPENSSL_EXTERN which is "responsible" for
this. On Windows OPENSLL_EXTERN is[?]/can be defined as "extern
_declspec(dllimport)" and the problem must be that n_pkey.c refers to
same variable as both local and OPENSSL_EXTERN. The catch is that
_decspec(dllimport) is [and has to be] treated differently. Most notably
"_declspec(dllimport) int i; int foo(){return i;}" effectively compiles
as "int *_i; int foo() {return *_i;}." As you can see generated machine
code has to be substantially different from one generated for plain "int
i; int foo(){return i;}" and this is what the compiler must be
complaining about. At the very least if I try to compile "int
i;_declspec(dllimport) int i;" I get the very same error code, C2370.
A.
I've built 0.9.7 with VC 6.0 SP3 as well as VC 7.0 without incident.
I'm wondering if there are any Environment Variables defined that
might be altering the build environment.
Also, it would be useful to know which makefile is being used.
Re: [CVS] OpenSSL: openssl/ssl kssl.c
comments inline:
Lutz Jaenicke wrote:
OpenSSL CVS Repository
http://cvs.openssl.org/
Server: cvs.openssl.org Name: Lutz Jaenicke
Root: /e/openssl/cvs Email: [EMAIL PROTECTED]
Module: openssl Date: 20-Dec-2002 13:47:16
Branch: OpenSSL_0_9_7-stable Handle: 2002122012471600
Modified files: (Branch: OpenSSL_0_9_7-stable)
openssl/ssl kssl.c
Log:
Fix Kerberos5/SSL interaction
Submitted by: Kenneth R. Robinette [EMAIL PROTECTED]
Summary:
RevisionChanges Path
1.20.2.8+17 -38 openssl/ssl/kssl.c
Index: openssl/ssl/kssl.c
$ cvs diff -u -r1.20.2.7 -r1.20.2.8 kssl.c
--- openssl/ssl/kssl.c 28 Nov 2002 08:08:59 - 1.20.2.7
+++ openssl/ssl/kssl.c 20 Dec 2002 12:47:16 - 1.20.2.8
@@ -2029,44 +2029,23 @@
*/
goto err;
}
- if (!EVP_DecryptInit_ex(ciph_ctx, enc, NULL, kssl_ctx-key, iv))
- {
- kssl_err_set(kssl_err, SSL_R_KRB5_S_INIT,
- EVP_DecryptInit_ex error decrypting authenticator.\n);
- krb5rc = KRB5KRB_AP_ERR_BAD_INTEGRITY;
- goto err;
- }
- if (!EVP_DecryptUpdate(ciph_ctx, unenc_authent, outl,
- dec_authent-cipher-data, dec_authent-cipher-length))
- {
- kssl_err_set(kssl_err, SSL_R_KRB5_S_INIT,
- EVP_DecryptUpdate error decrypting authenticator.\n);
- krb5rc = KRB5KRB_AP_ERR_BAD_INTEGRITY;
- goto err;
- }
- if (outl unencbufsize)
- {
- kssl_err_set(kssl_err, SSL_R_KRB5_S_INIT,
-Buffer overflow decrypting authenticator.\n);
- krb5rc = KRB5KRB_AP_ERR_BAD_INTEGRITY;
- goto err;
- }
- if (!EVP_DecryptFinal_ex(ciph_ctx, (unenc_authent[outl]), padl))
- {
- kssl_err_set(kssl_err, SSL_R_KRB5_S_INIT,
- EVP_DecryptFinal_ex error decrypting authenticator.\n);
- krb5rc = KRB5KRB_AP_ERR_BAD_INTEGRITY;
- goto err;
- }
- outl += padl;
- if (outl unencbufsize)
- {
- kssl_err_set(kssl_err, SSL_R_KRB5_S_INIT,
-Buffer overflow decrypting authenticator.\n);
- krb5rc = KRB5KRB_AP_ERR_BAD_INTEGRITY;
- goto err;
- }
- EVP_CIPHER_CTX_cleanup(ciph_ctx);
+
+if (!EVP_CipherInit(ciph_ctx,enc,kssl_ctx-key,iv,0))
+{
+kssl_err_set(kssl_err, SSL_R_KRB5_S_INIT,
+EVP_DecryptInit_ex error decrypting authenticator.\n);
This error message should be updated to describe the new function being
called.
+krb5rc = KRB5KRB_AP_ERR_BAD_INTEGRITY;
+goto err;
+}
+outl = dec_authent-cipher-length;
+if (!EVP_Cipher(ciph_ctx,unenc_authent,dec_authent-cipher-data,outl))
+{
+kssl_err_set(kssl_err, SSL_R_KRB5_S_INIT,
+EVP_Cipher error decrypting authenticator.\n);
+krb5rc = KRB5KRB_AP_ERR_BAD_INTEGRITY;
+goto err;
+}
+EVP_CIPHER_CTX_cleanup(ciph_ctx);
The cleanup function is only being called on successful completion.
Shouldn't we be calling it on error as well?
I suggest adding after the err: label:
if (ciph_ctx) EVP_CIPHER_CTX_cleanup(ciph_ctx);
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
TSU NOTIFICATION - encryption was Re: [CVS] OpenSSL: openssl/sslkssl.c
SUBMISSION TYPE: TSU
SUBMITTED BY: Jeffrey Altman
SUBMITTED FOR:
POINT OF CONTACT:[EMAIL PROTECTED]
PHONE and/or FAX:
MANUFACTURER: (if relevant)
PRODUCT NAME/MODEL #: openssl 0.9.7
ECCN: 5D002
NOTIFICATION: The attached patch is against the 20021220 snapshot of
openssl, version 0.9.7. The sourcecode is available at
ftp.openssl.org and its worldwide mirrors. Patch submitted to the
openssl-dev mailing list.
*** \temp\kssl.c Fri Dec 20 10:53:06 2002
--- kssl.c Fri Dec 20 10:56:22 2002
***
*** 1961,1967
const EVP_CIPHER*enc = NULL;
unsigned char iv[EVP_MAX_IV_LENGTH];
unsigned char *p, *unenc_authent;
! int padl, outl, unencbufsize;
struct tm tm_time, *tm_l, *tm_g;
time_t now, tl, tg, tr, tz_offset;
--- 1961,1967
const EVP_CIPHER*enc = NULL;
unsigned char iv[EVP_MAX_IV_LENGTH];
unsigned char *p, *unenc_authent;
! int outl, unencbufsize;
struct tm tm_time, *tm_l, *tm_g;
time_t now, tl, tg, tr, tz_offset;
***
*** 2033,2039
if (!EVP_CipherInit(ciph_ctx,enc,kssl_ctx-key,iv,0))
{
kssl_err_set(kssl_err, SSL_R_KRB5_S_INIT,
! EVP_DecryptInit_ex error decrypting authenticator.\n);
krb5rc = KRB5KRB_AP_ERR_BAD_INTEGRITY;
goto err;
}
--- 2033,2039
if ( !EVP_CipherInit(ciph_ctx, enc, kssl_ctx-key,iv,0 ))
{
kssl_err_set(kssl_err, SSL_R_KRB5_S_INIT,
! EVP_CipherInit error decrypting authenticator.\n);
krb5rc = KRB5KRB_AP_ERR_BAD_INTEGRITY;
goto err;
}
***
*** 2094,2099
--- 2094,2100
if (auth) KRB5_AUTHENT_free((KRB5_AUTHENT *) auth);
if (dec_authent)KRB5_ENCDATA_free(dec_authent);
if (unenc_authent) free(unenc_authent);
+ EVP_CIPHER_CTX_cleanup(ciph_ctx);
return krb5rc;
}
Lutz Jaenicke wrote:
Jeffrey, Kenneth, can one of you kindly provide a corresponding patch?
Lutz
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: openssl CHANGES
Not entirely true. I implemented the dynamic locks on Windows in Kermit 95. I do not have any hardware to test it with though. + *) The hw_ncipher.c engine requires dynamic locks. Unfortunately, it + seems that in spite of existing for more than a year, no application + author has done anything to provide the necessary callbacks, which + means that this particular engine will not work properly anywhere. + This is a very unfortunate situation which forces us, in the name + of usability, to give the hw_ncipher.c a static lock, which is part + of libcrypto. + NOTE: This is for the 0.9.7 series ONLY. This hack will never + appear in 0.9.8 or later. We EXPECT application authors to have + dealt properly with this when 0.9.8 is released (unless we actually + make such changes in the libcrypto locking code that changes will + have to be made anyway). + [Richard Levitte] + __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #395] Problem with OpenSSL
When running as a Service there are order of loading dependencies.
Apparently, on the one machine you have in question your service is
being loaded prior to something else that is a blocking point for
Performance Gathering routines. This is known to happen in apps that
utilize OpenSSL with COM.
Ken Mattsen via RT wrote:
We at ROXIO are looking at using STunnel in our GoBack product to provide a secure link between a server and many client PCs. We have done some testing and this looks like it will work. We plan to support WinNT, Win2000, and WinXP clients. In our testing we had one (1 of 3) computer that would not start STunnel as a service. This computer has WinNT installed, Service pack 6 build 1381. Investigation determined that the OpenSSL was failing at line 279 in the code below. The call to RegQueryValueEx() would never return when bufsz was greater than 32768. I do not know if this is the same problem reported by Jeffrey Altman.
File crypto\rand\rand_win.c - OpenSSL 0.9.6g 9 Aug 2002
Code from the RAND_poll() function.
Line:
253/* It appears like this can cause an exception deep within ADVAPI32.DLL
254 * at random times on Windows 2000. Reported by Jeffrey Altman.
255 * Only use it on NT.
256 */
257if ( osverinfo.dwPlatformId == VER_PLATFORM_WIN32_NT
258 osverinfo.dwMajorVersion 5)
259 {
260 /* Read Performance Statistics from NT/2000 registry
261 * The size of the performance data can vary from call
262 * to call so we must guess the size of the buffer to use
263 * and increase its size if we get an ERROR_MORE_DATA
264 * return instead of ERROR_SUCCESS.
265 */
266 LONG rc=ERROR_MORE_DATA;
267 char * buf=NULL;
268 DWORD bufsz=0;
269 DWORD length;
270
271 while (rc == ERROR_MORE_DATA)
272 {
273 buf = realloc(buf,bufsz+8192);
274 if (!buf)
275break;
276 bufsz += 8192;
277
278 length = bufsz;
279 rc = RegQueryValueEx(HKEY_PERFORMANCE_DATA, Global,
280NULL, NULL, buf, length);
281 }
282 if (rc == ERROR_SUCCESS)
283 {
284/* For entropy count assume only least significant
285 * byte of each DWORD is random.
286 */
287 RAND_add(length, sizeof(length), 0);
288 RAND_add(buf, length, length / 4.0);
289 }
290 if (buf)
291 free(buf);
292 }
I solved my problem 2 different ways.
One solution was to limit the bufsz to 32768 by inserting at line 273 the following:
if (bufsz = 8192*4)
{
rc = ERROR_SUCCESS;
break;
}
The other solution was to skip this section if ADVAPI32.DLL is present by changing the line at 258 to
257if ( osverinfo.dwPlatformId == VER_PLATFORM_WIN32_NT
258 osverinfo.dwMajorVersion 5 advapi == NULL)
This change would make the code behave the same way as Win2000 if ADVAPI32.DLL is installed. When ADVAPI32.DLL is not installed is the only time the RegQueryValueEx() function would be called.
I do not know the ramification of these changes. This code is run during the seeding of the PRNG and it appears to me that this extra seeding is only needed if ADVAPI32.DLL is not available. I could use advice on this.
Is it possible to get a fix into OpenSSL?
Misc Info:
Compiler: Microsoft Visual C++ 6.0
Thanks!
Ken Mattsen
Senior Software Engineer
ROXIO, IncThe Digital Media Company
6900 Wedgwood Road
Maple Grove, MN 55311 USA
763-494-7207 direct
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
www.roxio.com http://www.roxio.com
NASDAQ:ROXI
Featuring the Best-Selling CD-Recording Software in the World
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[openssl.org #392] X509_STORE_CTX_cleanup 0.9.7 beta 5
I'm tracking down the cause of an exception that did not occur with Kermit 95 with previous 0.9.7 builds. In the process I noticed that in X509_STORE_CTX_cleanup the buffer ctx-ex_data is freed with CRYPTO_free_ex_data prior to it being cleansed with OPENSSL_cleanse I'm pretty sure these two calls need to be reversed. - Jeff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #393] 0.9.7 beta 5 crypto/x509/x509_vfy.c X509_STORE_CTX_init() memset required
Please ignore my previous e-mail, the problem is located in X509_STORE_CTX_init() The memset((ctx-ex_data),0,sizeof(CRYPTO_EX_DATA)) that was commented out needs to be restored due to the use of OPENSSL_cleanse() on that data structure. In previous releases this data structure would have been zero'd out. Now it contains random data in pointer fields and therefore must be zero'd before the call to CRYPTO_new_ex_data(). Thanks. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Concerns about the use of OPENSSL_cleanse()
Rich Salz wrote:
Hmm, so OpenSSL is depending on NULL being all-bytes-zero. :)
Funny about that. :-)
Probably a safe assumption, although theoretically you shouldn't do that.
It really wouldn't matter what assumption you made. At some point there
needs to be a test:
Is this structure initialized?
And assigning random values to a structure will never allow the test to
properly succeed.
But this does make me think that perhaps a better approach is to have
a bunch of static instances:
X509_STORE_ctx nil_x509_store_ctx;
RSA nil_RSA;
...
etc.
Then OPENSSL_cleanse is
OPENSSL_cleanse2(volatile void* dest, volatile void* in, size_t s)
{
memcpy(dest, in, s);
/* play usual force used tricks here */
}
Another approach to consider is implementing special XXX_cleanse()
functions that are smart about which fields can be randomized and which
ones (ie, pointers) must be set to zero.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Concerns about the use of OPENSSL_cleanse()
I think we need to take a very close look at the situations when it is safe to replace memset(buf,0,sizeof(buf)) with OPENSSL_cleanse(buf,sizeof(buf)). It is clearly safe to make this replacement when the buffer is a stack allocation because there can be no future use of the data can take place. So there is no functional difference between a buffer filled with zeros and a buffer filled with garbage data. However, this is not true for data structures that are located on the heap. In many cases OpenSSL provides functions that allow a buffer to be reused: XXX_init(), XXX_cleanup(), XXX_free(). This is true for several data structures. By replacing memset() with OPENSSL_cleanse() in the XXX_cleanup() function we have a problem when the data structure contains pointers to additional heap allocations. One case that I found a problem with is: . application allocates X509_STORE_CTX and initializes it with X509_STORE_CTX_init(). . application calls X509_STORE_CTX_cleanup() which in turn calls OPENSSL_cleanse() . application calls X509_STORE_CTX_free() which in turn calls X509_STORE_CTX_cleanup(). This results in an exception because the ex_data field is a struct that contains pointers to memory allocations. Due to the OPENSSL_cleanse() call the pointer values are garbage non-NULL values. An attempt is made to free the memory. This causes an exception. This is going to require careful examination to find all of the places where pointers need to be set to NULL after or during a cleanse operation. - Jeff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
OpenSSL on VMS - default locations for CERTS, KEYS, ...
C-Kermit can now be built on VMS with OpenSSL/Compaq SSL support. This provides a TELNET START_TLS, TELNET AUTH SSL, HTTPS client for VMS. Assuming the FTP functionality and IKSD functionality is implemented on VMS that would also inherit this support http://www.kermit-project.org/ckermit.html http://www.kermit-project.org/ckdaily.html To build C-Kermit on VMS with SSL/TLS support use the command: make CK_SSL,CK_AUTHENTICATION The only thing I have not done yet for VMS is provide default locations for the System-wide and User-specific locations for the storing of CERTS/KEYS and CRLs. Could some post a description of what is considered standard practice? Thanks. Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #367] s3_clnt.c ssl3_get_server_hello and SSL_SESSION cipher_id 0.9.7-b4
Sometime in the last couple of weeks the following change was made to s3_clnt.c 698,699c699 if (s-hit (s-session-cipher != c)) --- if (s-hit (s-session-cipher_id != c-id)) The only problem is that at this point in time the cipher_id field of the SSL_SESSION has not been set. Therefore, this test fails. If you do not trust the pointer comparison (and I wouldn't) the following change does work if (s-hit (s-session-cipher-id != c-id)) It is interesting to note that in i2d_SSL_SESSION() the following code is used to determine the cipher id: if (in-cipher == NULL) l=in-cipher_id; else l=in-cipher-id; This leads me to believe the proper change should look like: if (s-session-cipher == NULL) id=s-session-cipher_id; else id=s-session-cipher-id; if (s-hit (id != c-id)) I do wonder why the SSL_SESSION cipher_id field is not consistently set when the cipher itself is set. Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #360] crypto/dsa/dsa_lib.c DSA_size()
What is the appropriate size for 'buf' in DSA_size()? 4 bytes is certainly not correct. My guess is that we want to support at least 256 bits and so it needs to be at least 32 bytes. Does anyone have a better recommendation? Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #361] Re: OpenSSL and compression using ZLIB
http://www.ietf.org/internet-drafts/draft-ietf-tls-compression-03.txt
defines the compression numbers to be:
enum { null(0), ZLIB(1), LZS(2), (255) } CompressionMethod;
Therefore proposed numbers have been issued. I suggest that OpenSSL
define the CompressionMethod numbers to be:
enum { null(0), ZLIB(1), LZS(2), eayZLIB(224), eayRLE(225), (255) }
CompresssionMethod
as values in the range 193 to 255 are reserved for private use.
Where does the above draft state that the dictionary must be reset?
It states that the engine must be flushed but does not indicate that
the dictionary is to be reset. Resetting the dictionary would turn
ZLIB into a stateless compression algorithm and according to the draft
ZLIB is most certainly a stateful algorithm:
the compressor maintains it's state through all compressed records
I do not believe that compatibility will be an issue. It will simply
result in the possibility that the compressed data is distributed
differently among the TLS frames that make up the stream.
If compatibility is a issue we could implement a new variant of
COMP_zlib(); COMP_tls_zlib() that would be used with ZLIB(1).
Well, I've got a couple of issues with such a change:
1. Is OpenSSL really the only implementation that has ZLIB at all? I
believe there aren't any compression numbers defined for ZLIB yet
(are have they actually been defined by now?), so I guess it might
be tricky to implement in any case...
If OpenSSL isn't alone with ZLIB compression, perhaps we should
look at interoperability?
2. How does that affect communication with programs running older
versions of OpenSSL? I assume that a change in dictionary reseting
will also change the actual data that's resulting from compression.
Will that be a problem?
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!!
The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP
http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and
[EMAIL PROTECTED] OpenSSL.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #360] crypto/dsa/dsa_lib.c DSA_size()
Thanks. That is very reassuring.
Jeffrey Altman via RT wrote:
What is the appropriate size for 'buf' in DSA_size()?
4 bytes is certainly not correct.
Hi Jeffry,
I think it's correct :-)
int DSA_size(const DSA *r)
{
int ret,i;
ASN1_INTEGER bs;
unsigned char buf[4];
i=BN_num_bits(r-q);
bs.length=(i+7)/8;
OPENSSL_assert(bs.length = sizeof buf);
I think this assertion wrong. Normally we have 2^159 q 2^160
(see FIPS 186-2) = i == 160 = bs.length == 20 4
bs.data=buf;
bs.type=V_ASN1_INTEGER;
/* If the top bit is set the asn1 encoding is 1 larger. */
buf[0]=0xff;
i=i2d_ASN1_INTEGER(bs,NULL);
i+=i; /* r and s */
ret=ASN1_object_size(1,i,V_ASN1_SEQUENCE);
return(ret);
}
i2d_ASN1_INTEGER() calls i2c_ASN1_INTEGER() (a_int.c) and
in i2c_ASN1_INTEGER() we have:
int i2c_ASN1_INTEGER(ASN1_INTEGER *a, unsigned char **pp)
// NOTE: pp == NULL
{
int pad=0,ret,i,neg;
unsigned char *p,*n,pb=0;
if ((a == NULL) || (a-data == NULL)) return(0);
neg=a-type V_ASN1_NEG;
if (a-length == 0)
ret=1;
else
{
ret=a-length;
i=a-data[0];
// NOTE: a-data[0] == 0xff == 255
if (!neg (i 127)) {
pad=1;
pb=0;
} else if(neg) {
if(i128) {
pad=1;
pb=0xFF;
} else if(i == 128) {
...
}
}
ret+=pad;
}
if (pp == NULL) return(ret);
...
hence only the first byte of 'buf' is used.
Regards,
Nils
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #360] crypto/dsa/dsa_lib.c DSA_size()
The code is the same in both 0.9.6- and 0.9.7-beta4. in 0.9.7-b4 there is an assertion added that is being triggered because the buf size is considered too small. However, tracing through the calls shows that even with a 160bit input only the first byte is ever touched. That does not mean other bytes could not be touched in the future though. In message [EMAIL PROTECTED] on Mon, 25 Nov 2002 09:32:30 +0100 (MET), Jeffrey Altman via RT [EMAIL PROTECTED] said: rt rt What is the appropriate size for 'buf' in DSA_size()? rt rt 4 bytes is certainly not correct. My guess is that we want to support at rt least 256 bits and so it needs to be at least 32 bytes. Does anyone rt have a better recommendation? Which version of OpenSSL? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #360] crypto/dsa/dsa_lib.c DSA_size()
The code is the same in both 0.9.6- and 0.9.7-beta4. in 0.9.7-b4 there is an assertion added that is being triggered because the buf size is considered too small. However, tracing through the calls shows that even with a 160bit input only the first byte is ever touched. That does not mean other bytes could not be touched in the future though. In message [EMAIL PROTECTED] on Mon, 25 Nov 2002 09:32:30 +0100 (MET), Jeffrey Altman via RT [EMAIL PROTECTED] said: rt rt What is the appropriate size for 'buf' in DSA_size()? rt rt 4 bytes is certainly not correct. My guess is that we want to support at rt least 256 bits and so it needs to be at least 32 bytes. Does anyone rt have a better recommendation? Which version of OpenSSL? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #360] crypto/dsa/dsa_lib.c DSA_size()
Then the assertion should be removed because as it is now it will always fail. Jeffrey Altman wrote: The code is the same in both 0.9.6- and 0.9.7-beta4. in 0.9.7-b4 there is an assertion added that is being triggered because the buf size is considered too small. However, tracing through the calls shows that even with a 160bit input only the first byte is ever touched. That does not mean other bytes could not be touched in the future though. That depends on the OpenSSL ASN1 code. But as far as I understand the code I don't know a possible reason to use any other value of the 'buf' array. In DSA_size() i2d_ASN1_INTEGER() is only called to get the max. possible length of the DER encoded integer (r and s) = only the first byte (with data[0] == 0xff) is needed. Regards, Nils Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #360] crypto/dsa/dsa_lib.c DSA_size()
Then the assertion should be removed because as it is now it will always fail. Jeffrey Altman wrote: The code is the same in both 0.9.6- and 0.9.7-beta4. in 0.9.7-b4 there is an assertion added that is being triggered because the buf size is considered too small. However, tracing through the calls shows that even with a 160bit input only the first byte is ever touched. That does not mean other bytes could not be touched in the future though. That depends on the OpenSSL ASN1 code. But as far as I understand the code I don't know a possible reason to use any other value of the 'buf' array. In DSA_size() i2d_ASN1_INTEGER() is only called to get the max. possible length of the DER encoded integer (r and s) = only the first byte (with data[0] == 0xff) is needed. Regards, Nils Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL and compression using ZLIB
http://www.ietf.org/internet-drafts/draft-ietf-tls-compression-03.txt
defines the compression numbers to be:
enum { null(0), ZLIB(1), LZS(2), (255) } CompressionMethod;
Therefore proposed numbers have been issued. I suggest that OpenSSL
define the CompressionMethod numbers to be:
enum { null(0), ZLIB(1), LZS(2), eayZLIB(224), eayRLE(225), (255) }
CompresssionMethod
as values in the range 193 to 255 are reserved for private use.
Where does the above draft state that the dictionary must be reset?
It states that the engine must be flushed but does not indicate that
the dictionary is to be reset. Resetting the dictionary would turn
ZLIB into a stateless compression algorithm and according to the draft
ZLIB is most certainly a stateful algorithm:
the compressor maintains it's state through all compressed records
I do not believe that compatibility will be an issue. It will simply
result in the possibility that the compressed data is distributed
differently among the TLS frames that make up the stream.
If compatibility is a issue we could implement a new variant of
COMP_zlib(); COMP_tls_zlib() that would be used with ZLIB(1).
Well, I've got a couple of issues with such a change:
1. Is OpenSSL really the only implementation that has ZLIB at all? I
believe there aren't any compression numbers defined for ZLIB yet
(are have they actually been defined by now?), so I guess it might
be tricky to implement in any case...
If OpenSSL isn't alone with ZLIB compression, perhaps we should
look at interoperability?
2. How does that affect communication with programs running older
versions of OpenSSL? I assume that a change in dictionary reseting
will also change the actual data that's resulting from compression.
Will that be a problem?
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!!
The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP
http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and
[EMAIL PROTECTED] OpenSSL.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: BIO broken
Building shared libraries with static C Run Time Libraries is a disaster waiting to happen on many platforms. It is simply something you should not do. Not just because of the problem you are describing but because the C Run Time Libraries might be from completely incompatible implementations. Perhaps from different vendors. (This is a frequent problem on OS/2 when people try to mix EMX and IBM run time libraries.) If avoiding this problem is a goal of OpenSSL, then the only way to handle it is to never call a run time library function that works on a FILE * directly. Instead, all such calls must be made via callbacks to the application space in much the same way that we do for memory allocation and deallocation. Or applications must never create FILEs themselves and instead must use versions of fopen(), fclose(), ... which are provided by OpenSSL. This is not a design flaw in the BIO. It is a requirement on Windows that the DLLs be built with the same run-time library and threading models as the application. Hard to believe it might by true. Nevertheless everything indicates there is a major design flaw in BIO: BIO sends FILE* pointer across dll boundary, causing crash of statically linked version of libeay32.dll. (At least on WINNT). To reproduce, modify the corresponding compiler switch to /MT and try enclosed tests. The crash is located inside the EnterCriticalSection API, since the dll incorrectly considers sent FILE* as FILEX structure after being unable to locate it in its own list of FILEs. This is caused by the fact, both exe and dll maintain its own copy of the run time library, hence FILE* from the exe cannot work inside the DLL. Jan Kuznik __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: IMPORTANT: Please try these specific snapshots
In message [EMAIL PROTECTED] on Fri, 15 Nov 2002 16:46:40 +0100, Corinna Vinschen [EMAIL PROTECTED] said: vinschen That's exactly how it can't work. The DLL search algorithm is inside vinschen of Windows and it doesn't work using symlinks (resp. shortcuts under vinschen Windows) unfortunately. OK, another question: does Windows DLLs have any version information inside that's used for comparison, or is it just informative? The version information stored in the DLL resources is strictly informative. It is not used during the process of resolving dynamic links to libraries. And for good reason, there is no information in the process that is linked to the DLL to indicate the version. DLLs are discovered simply by using application specific search path data stored in the registry combined with the current PATH environment variable. Hard Links allowing a file to have multiple directory entries are supported in NTFS however very few shells understand how to manipulate them. Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OOB Data with SSL
You cannot use OOB data with SSL/TLS. I have setup a very simple SSL connection over sockets, and use the SSL_read and SSL_write functions to get and send encrypted data. With the socket read/write functions in C you can send/recv OOB (out of band) data - which I use for state maintenance. Is it possible to send/recv OOB data with ssl? I dont see a way to pass such options to the SSL_read/write functions and I am very new to all this ;-) Thanks for any pointers! Nate Yocom [EMAIL PROTECTED] http://pgina.cs.plu.edu __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #189] Kerberos Ciphersuite IDs
Richard: Just tried to build this and it fails: .\ssl\s3_lib.c(609) : error C2065: 'SSL3_TXT_KRB5_DES_192_CBC3_MD5' : undeclared identifier .\ssl\s3_lib.c(609) : error C2099: initializer is not a constant .\ssl\s3_lib.c(610) : warning C4047: 'initializing' : 'const char *' differs in levels of indirection from 'const int ' .\ssl\s3_lib.c(637) : error C2065: 'SSL3_TXT_KRB5_IDEA_128_CBC_MD5' : undeclared identifier .\ssl\s3_lib.c(637) : error C2099: initializer is not a constant .\ssl\s3_lib.c(638) : warning C4047: 'initializing' : 'const char *' differs in levels of indirection from 'const int ' .\ssl\s3_lib.c(679) : error C2065: 'SSL3_TXT_KRB5_RC4_40_CBC_SHA' : undeclared identifier .\ssl\s3_lib.c(679) : error C2099: initializer is not a constant .\ssl\s3_lib.c(680) : error C2065: 'SSL3_CK_KRB5_RC4_40_CBC_SHA' : undeclared identifier .\ssl\s3_lib.c(680) : error C2099: initializer is not a constant .\ssl\s3_lib.c(681) : warning C4047: 'initializing' : 'const char *' differs in levels of indirection from 'const long ' .\ssl\s3_lib.c(707) : error C2065: 'SSL3_TXT_KRB5_RC2_40_CBC_MD5' : undeclared identifier .\ssl\s3_lib.c(707) : error C2099: initializer is not a constant .\ssl\s3_lib.c(708) : warning C4047: 'initializing' : 'const char *' differs in levels of indirection from 'const int ' .\ssl\s3_lib.c(721) : error C2065: 'SSL3_TXT_KRB5_RC4_40_CBC_MD5' : undeclared identifier .\ssl\s3_lib.c(721) : error C2099: initializer is not a constant .\ssl\s3_lib.c(722) : error C2065: 'SSL3_CK_KRB5_RC4_40_CBC_MD5' : undeclared identifier .\ssl\s3_lib.c(722) : error C2099: initializer is not a constant .\ssl\s3_lib.c(723) : warning C4047: 'initializing' : 'const char *' differs in levels of indirection from 'const long ' It looks like the identifiers in ssl.h are wrong. There, I finally got the time to put this in. Just commited. Please test the next 0.9.7 snapshot and make sure I got it all right. This ticket is now resolved. [[EMAIL PROTECTED] - Mon Sep 30 18:55:14 2002]: Any chance of making progress on this? As a reminder, the issue is that the Kerberos ciphersuites in OpenSSL do not use the IDs defined in RFC2712, which obviously has negative effects on interoperability. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #189] Kerberos Ciphersuite IDs
' : undeclared identifier .\ssl\s3_lib.c(722) : error C2099: initializer is not a constant .\ssl\s3_lib.c(723) : warning C4047: 'initializing' : 'const char *' differs in levels of indirection from 'const long ' It looks like the identifiers in ssl.h are wrong. There, I finally got the time to put this in. Just commited. Please test the next 0.9.7 snapshot and make sure I got it all right. This ticket is now resolved. [[EMAIL PROTECTED] - Mon Sep 30 18:55:14 2002]: Any chance of making progress on this? As a reminder, the issue is that the Kerberos ciphersuites in OpenSSL do not use the IDs defined in RFC2712, which obviously has negative effects on interoperability. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #189] Kerberos Ciphersuite IDs
' : undeclared identifier .\ssl\s3_lib.c(722) : error C2099: initializer is not a constant .\ssl\s3_lib.c(723) : warning C4047: 'initializing' : 'const char *' differs in levels of indirection from 'const long ' It looks like the identifiers in ssl.h are wrong. There, I finally got the time to put this in. Just commited. Please test the next 0.9.7 snapshot and make sure I got it all right. This ticket is now resolved. [[EMAIL PROTECTED] - Mon Sep 30 18:55:14 2002]: Any chance of making progress on this? As a reminder, the issue is that the Kerberos ciphersuites in OpenSSL do not use the IDs defined in RFC2712, which obviously has negative effects on interoperability. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: DES_CBC_CKSUM in SSL and Kerberos.
AQIDBAUGBwgJCgsMDQAA AA4AAAD+EBESEwAAABQVFgAAAP7///8YGQAAABob HB0eHwAAACAh/v///yMkJQAAACYnKCkAAAD+ KwAAACwtLgAAAC8wMQAAAP79NP7+/v// //9SAG8AbwB0ACAARQBuAHQAcgB5 FgAFAf//AwYJAgAAwEYAAADw bA9sdXDCATYAAACAAEQAYQB0AGEA AAAKAAIB DwAQMQBUAGEAYgBsAGUA AA4AAgEBBgAAAP8A AAAX6RUAAABXAG8AcgBkAEQA bwBjAHUAbQBlAG4AdAAAGgAC AQIF/wAiHAAA AAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4A AAAoAAIB IgAQBQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBv AHIAbQBhAHQAaQBvAG4AADgAAgEE//8A AAAqABABAEMAbwBtAHAATwBiAGoA EgACAP///wAA AABq AQAAAP7/ //8BAP7/AwoAAP8GCQIAAMBGGE1pY3Jvc29mdCBXb3JkIERvY3VtZW50 AAoAAABNU1dvcmREb2MAEFdvcmQuRG9jdW1lbnQuOAD0ObJx AA== --_=_NextPart_001_01C27085.410E8F0F-- __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: heap walk in rand_win.c is quite slow
Suggestion. Do not wait until you establish your first connection to call RAND_poll(). Initializae the PRNG as part of the startup of your app or in a background thread. Greetings. The first SSL connection in my application was taking some 10 to 16 seconds to return. Thereafter, subsequent SSL connections would complete and return immediately. I eventually traced the culprit to RAND_poll() in rand_win.c. Specifically, it was the part of RAND_poll() that walks through the list of allocated blocks on the heap(s); this heap walk was consuming almost all of those 16 seconds. I do have a large application, and there were no doubt several heaps, each with many allocated blocks. I see that there was code in place to limit the number of blocks traversed per heap to 50, but there was no limit on the number of separate heaps that may be traversed. In fact, it was visiting some 500 blocks total in my case. (The limit of 50 blocks per heap was as of version 0.9.6d. I note that by 0.9.7-beta3 someone has upped that limit to 80, worsening my problem.) Is it really necessary to visit so many blocks? I put in a quick hack to apply the 50-block limit to the total number of blocks, rather than per heap; this makes it take maybe 2 to 3 seconds instead, which is still pretty slow but at least it's tolerable. (Apparently the heap-walking routines in Win2000 are quite slow.) I am concerned that someone recently felt the need to raise the count to 80, however. What affect will capping this number have on the security of my transactions? Perhaps the limit was originally meant to apply to the total number anyway, and this was just an oversight? It doesn't make a whole lot of sense to limit the number of blocks visited per heap, without also limiting the number of heaps. Do you have any advice? Many thanks, David __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Question about the latest security patch - malicious usage
Jeffrey Altman wrote: The answer to your questions is 'yes'. As I understand it, the patches were released as they are for the time being because it is better to crash your application then allow the attacker to compromise your computer. New patches will have to be released to properly correct the problem in the very near future. Note that changing unexploitable die()s to internal errors is a mistake: it is not safe to continue after an internal error! Cheers, Ben. This is true IFF the internal error is the result of a memory overwrite condition that could have compromised the application; but if the problem is something that we were able to identify before any damage is done (such as the recent protocol error checks) then the error must be returned to the application. The library is often just one small part of an overall application. Introducing easy to trigger denial of service attacks is unacceptable. Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #189] Kerberos Ciphersuite IDs
Has anyone sent a query to Win Treese [EMAIL PROTECTED] [TLS WG chair]
and perhaps the area directors looking for guidance?
The TLS Protocol Version 1.0 is in the process of being re-issued:
http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc2246-bis-01.txt
and clearly this problem should be addressed in that document and by
the working group. If this has not already been brought to their
attention, let me know and I will do so.
- Jeff
Hmm, there's a problem that haven't been addressed at all by the
IETF. SSLv3 contains the following as part of it's ciphersuite:
The final cipher suites are for the FORTEZZA token.
CipherSuite SSL_FORTEZZA_KEA_WITH_NULL_SHA = {
0X00,0X1C };
CipherSuite SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA = {
0x00,0x1D };
CipherSuite SSL_FORTEZZA_KEA_WITH_RC4_128_SHA = {
0x00,0x1E };
Please note how the last one clashes with the first of the KRB5
suite. Also, when one looks at RFC 2246 (TLS), there's this note at
the end of section A.5:
Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
reserved to avoid collision with Fortezza-based cipher suites
in
SSL 3.
which indicates that SSL_FORTEZZA_KEA_WITH_RC4_128_SHA was not
considered or entirely dropped. Still a clash, and I honestly
wouldn't have any idea on what to do with this.
If it wasn't for this, I'd apply the needed changes immediately. As
it is now, I'd like to see this issue cleared first.
Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!!
The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP
http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and
[EMAIL PROTECTED] OpenSSL.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL patches for other versions
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 it produces nice DoS. Yes, it's better than exploitable hole but still not acceptable. Arne I agree. An exploit should return an error to the application and invalidate the connection attempt. It should not cause the application to terminate. There are other places in the code where checks for input lengths vs buffer lengths are performed. Never has OpenSSL called abort() in the past. Also, the exploit error should preferably be sent to a call back so that proper logging can be performed. Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #169] 0.9.7-b3 compile error on Win32
ssl\s3_srver.c (1591) error: pms_length is not a member of evp_cipher_st I believe the correct reference is if (enc_pms.length sizeof pms) instead of if (enc.pms_length sizeof pms) Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL patches for other versions
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. /r$ Or when the new OpenSSLDie() is called. That is why we want it removed. Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #170] OpenSSLDie not exported in Win32
OK, I don't understand why it needs to be exported - isn't it internal to the library? But assuming it does, I prefer the original suggestions (i.e. move the declaration of OpenSSLDie()). It needs to be exported because the function is defined in libeay32.dll and used in ssleay32.dll on Windows. Now the choices as I see it are: . export the function. which I have done in order to get the code to compile and link on Windows, or . remove the call entirely and instead simply have OpenSSL return an error to the application as is done with other length checks For example, in ssl_sess.c ssl_get_new_session() the error SSL_R_SSL_SESSION_ID_HAS_BAD_LENGTH is returned if tmp ss-session_id_length. I don't see why we need to call abort() (via die()) if s-sid_ctx_length sizeof ss-sid_ctx. Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #170] OpenSSLDie not exported in Win32
OK, I don't understand why it needs to be exported - isn't it internal to the library? But assuming it does, I prefer the original suggestions (i.e. move the declaration of OpenSSLDie()). It needs to be exported because the function is defined in libeay32.dll and used in ssleay32.dll on Windows. Now the choices as I see it are: . export the function. which I have done in order to get the code to compile and link on Windows, or . remove the call entirely and instead simply have OpenSSL return an error to the application as is done with other length checks For example, in ssl_sess.c ssl_get_new_session() the error SSL_R_SSL_SESSION_ID_HAS_BAD_LENGTH is returned if tmp ss-session_id_length. I don't see why we need to call abort() (via die()) if s-sid_ctx_length sizeof ss-sid_ctx. Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #170] OpenSSLDie not exported in Win32
rt Need to add it to the exports list. For anyone who has the time, the fix is to move the declaration (but not the macro die()) from cryptlib.h to crypto.h, then do a make update. And this will auto-generate the entry for util/libeay.num ? Cool. Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #170] OpenSSLDie not exported in Win32
jaltman Now the choices as I see it are: jaltman jaltman . export the function. which I have done in order to get the jaltmancode to compile and link on Windows, or jaltman jaltman . remove the call entirely and instead simply have OpenSSL return jaltmanan error to the application as is done with other length checks jaltman jaltman For example, in ssl_sess.c ssl_get_new_session() the error jaltman SSL_R_SSL_SESSION_ID_HAS_BAD_LENGTH is returned if tmp jaltman ss-session_id_length. I don't see why we need to call abort() (via jaltman die()) if s-sid_ctx_length sizeof ss-sid_ctx. I believe it was done this way because time was too short to explore what cases one should die at and what cases one should not, including the ramifications of returning an error instead of using the biggest canon available. The possible threasts are serious, and at least in a hopefully short amount of time, we will look at those die() statements and deal with them in any way that seems appropriate. At this moment, it was more important to kill the possible holes quickly and swiftly rather than spend time being kind to the applications. My 2 cents, others may have a different opinion. That is fine. So the patches are out and already need to be replaced since they do not compile on two major platforms. The primary concern was to get notification out and patches that stop the attacks. That has been done. Arne has mentioned that he is working on alternate patches. All of the functions in which die() was inserted already return errors when comparing buffer lengths except for: s2_clnt.c client_finished() s2_lib.c ssl2_generate_key_material() s2_lib.c ssl2_write_error() s2_srvr.c server_verify() s2_srvr.c server_finished() of these, client_finished() is safe to return an error value 0 ssl2_generate_key_material() is void and so needs to have its interface changed in order to return an error. It is only called from ssl2_enc_init(). ssl2_enc_init() already returns error conditions. ssl2_write_error() is void. It is called from ssl2_return_error() which is also void and from ssl2_write() which is already returning errors to the caller. ssl2_return_error() is always called from locations that are already in the process of returning errors to the caller. server_verify() is safe to return an error value 0 server_finish() is safe to return an error value 0 So it seems that we should be able to safely return errors from all of them with minor interface changes to two functions. (void - int) Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #170] OpenSSLDie not exported in Win32
jaltman Now the choices as I see it are: jaltman jaltman . export the function. which I have done in order to get the jaltmancode to compile and link on Windows, or jaltman jaltman . remove the call entirely and instead simply have OpenSSL return jaltmanan error to the application as is done with other length checks jaltman jaltman For example, in ssl_sess.c ssl_get_new_session() the error jaltman SSL_R_SSL_SESSION_ID_HAS_BAD_LENGTH is returned if tmp jaltman ss-session_id_length. I don't see why we need to call abort() (via jaltman die()) if s-sid_ctx_length sizeof ss-sid_ctx. I believe it was done this way because time was too short to explore what cases one should die at and what cases one should not, including the ramifications of returning an error instead of using the biggest canon available. The possible threasts are serious, and at least in a hopefully short amount of time, we will look at those die() statements and deal with them in any way that seems appropriate. At this moment, it was more important to kill the possible holes quickly and swiftly rather than spend time being kind to the applications. My 2 cents, others may have a different opinion. That is fine. So the patches are out and already need to be replaced since they do not compile on two major platforms. The primary concern was to get notification out and patches that stop the attacks. That has been done. Arne has mentioned that he is working on alternate patches. All of the functions in which die() was inserted already return errors when comparing buffer lengths except for: s2_clnt.c client_finished() s2_lib.c ssl2_generate_key_material() s2_lib.c ssl2_write_error() s2_srvr.c server_verify() s2_srvr.c server_finished() of these, client_finished() is safe to return an error value 0 ssl2_generate_key_material() is void and so needs to have its interface changed in order to return an error. It is only called from ssl2_enc_init(). ssl2_enc_init() already returns error conditions. ssl2_write_error() is void. It is called from ssl2_return_error() which is also void and from ssl2_write() which is already returning errors to the caller. ssl2_return_error() is always called from locations that are already in the process of returning errors to the caller. server_verify() is safe to return an error value 0 server_finish() is safe to return an error value 0 So it seems that we should be able to safely return errors from all of them with minor interface changes to two functions. (void - int) Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #170] OpenSSLDie not exported in Win32
In message [EMAIL PROTECTED] on Tue, 30 Jul 2002 11:31:17 EDT, Jeffrey Altman [EMAIL PROTECTED] said: jaltman since they do not compile on two major platforms. On VMS, creating OpenSSL shared libraries is not the norm yet, so it'll build fine :-). fine. shared libraries won't work on two major platforms. One of which where it is the norm. the other bug I submitted this morning prevents the 0.9.7 patch from compiling on any platform. --- in case you hadn't heard Kermit 95 was granted a mass market export license including OpenSSL 0.9.7 and the full MIT Kerberos for Windows distribution. Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #170] OpenSSLDie not exported in Win32
In message [EMAIL PROTECTED] on Tue, 30 Jul 2002 11:31:17 EDT, Jeffrey Altman [EMAIL PROTECTED] said: jaltman since they do not compile on two major platforms. On VMS, creating OpenSSL shared libraries is not the norm yet, so it'll build fine :-). fine. shared libraries won't work on two major platforms. One of which where it is the norm. the other bug I submitted this morning prevents the 0.9.7 patch from compiling on any platform. --- in case you hadn't heard Kermit 95 was granted a mass market export license including OpenSSL 0.9.7 and the full MIT Kerberos for Windows distribution. Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CBC vulnerability workaround
I have found nothing in the SSL 3.0 and TLS 1.0 specifications that forbids fragments of length zero. The length is given as a 'uint16' value; the specification defines upper limits, but no lower limits. draft-freier-ssl-version3-02.txt (SSL 3.0): 5.2.1 Fragmentation The record layer fragments information blocks into SSLPlaintext records of 2^14 bytes or less. [...] RFC 2246 (TLS 1.0): 6.2.1. Fragmentation The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. [...] I have come across a large commercial user of SSL services for whom the workaround fails. The transmission of the data frame with no application data generates an SSL Alert causing the application to close the connection. The developers of the SSL library being used have replied that SSLv3 does not permit data frames containing no application data. Can they cite a particular provision in the specification that forbids records with a fragment length of zero? I haven't found one, and length-zero fragments are handled well by many implementations (including Microsoft IIS). Bodo: Thanks for the reply. They are quoting: draft-netscape-ssl-v2 1.1 SSL Record Header Format In SSL, all data sent is encapsulated in a record, an object which is composed of a header and some non-zero amount of data RFC2246 6.2. Record layer The TLS Record Layer receives uninterpreted data from higher layers in non-empty blocks of arbitrary size. Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CBC vulnerability workaround
When OpenSSL inserts an empty fragment, it fragments a single message into multiple parts, the first of which happens to be empty. I concede that this might appear pointless as long as one doesn't know about the CBC security issues, but nothing in the specification speaks against it. (And, of course, security considerations speak for it.) -- Bodo Möller [EMAIL PROTECTED] Thanks Bodo. This is exactly the response I needed. Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #82] `NID_uniqueIdentifier' undeclared (first use in this function)
Gang. It is a little uncool to be having a long lengthy discussion of someone's supported code without involving them in the discussion. As it turns out all of the issues that have been addressed in this thread related to C-Kermit had already been handled in the C-Kermit Daily builds. http://www.kermit-project.org/ckdaily.html Also, markus@ created this temp patch: +@@ -102,6 +104,13 @@ + !ERROR This module requires OpenSSL 0.9.5a or higher + #endif /* OPENSSL_VERSION_NUMBER */ + #endif /* SSLDLL */ ++ ++#if OPENSSL_VERSION_NUMBER 0x00907000L ++#else ++ #ifndef NID_UniqueIdentifier ++ #define NID_uniqueIdentifier NID_x500UniqueIdentifier ++ #endif ++#endif + + static int auth_ssl_valid = 0; + static char *auth_ssl_name = 0;/* this holds the oneline name */ That looks better, but not finally good enough. I think that the correct solution would be something like: * Replace all occurences of NID_UniqueIdentifier with ID_X500UniqueIdentifier. * Then: #if OPENSSL_VERSION_NUMBER 0x00907000L #define NID_X500UniqueIdentifier NID_UniqueIdentifier #endif Of course, this will still break compatibility with application not especially prepared. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #82] `NID_uniqueIdentifier' undeclared (first use in this function)
Sorry for not including you into the discussion. I only cared about the problem itself, which also pops up in mod_ssl, so I didn't even realize that we were talking about your package. Anyway: NID_uniqueIdentifier _may_ be re-enabled at some point in the future with its original meaning # The following clashes with 2.5.4.45, so commented away #pilotAttributeType 44 : uid : uniqueIdentifier where original meaning == pilotAttributeType That is fine. I would therefore propose to not code dependant on #ifdef NID_uniqueIdentifier but by OpenSSL version number. Right, I actually already changed this to be dependent not on the item that is in conflict but based on the item we agree is stable. This discussion started 1 week ago with corresponding problems reported in the mod_ssl mailing lists. As nobody else spoke up in that regard, it is my intention to leave everything as is, make sure that the item is pointed out in CHANGES (maybe even NEWS) and declare the problem to be resolved this way. I have not yet decided about pilotAttributeType 44, but will probably leave it disabled until the 0.9.8 release of OpenSSL, so that applications not conforming to the new naming will not compile instead of silently using a wrong interpretation. I completely agree with this approach. It did not come up for me in the last week because C-Kermit has consistently been kept in sync with the 0.9.7 development builds. Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #44] OpenSSL_add_all_algorithms problems in Win32
Are you sure your problem is in OpenSSL_add_all_algorithms() and not a call to RAND_poll()? Many of the methods used in RAND_poll() to collect random data are incompatible with COM when called from within DLL initializers. Hi: I´m having ugly crashes in Win32 when I call several times OpenSSL_add_all_algoritms(), mainly when I use my C code from Visual Basic but also if I use several DLLs. The problem comes up if I call that funcion from several C DLLs to initialize library. I think that it would be useful to have an static variable inside OpenSSL_add_all_algoritms(), in such a way initialized that only one time the initialize is made.This way , no matter how many times from no matter which other DLLs I call the function it only gets initialized one time. In short way, to use a singleton. I have debugged my code a lot, used purify...etc and I think the problem is not in OpenSSL or my C code (is working under heavy pressure in other programs),but in the extrange things with COM apartments and threads, and I suppose this change in library would not break compatibility much. It would be possible such a change or similar?.If you know another solution I would like to hear... Thank you Pablo J. Royo __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Jeffrey Altman * Sr.Software Designer Kermit 95 1.1.21 available now!!! The Kermit Project @ Columbia University SSH plus Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and [EMAIL PROTECTED]OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #44] OpenSSL_add_all_algorithms problems in Win32
Take a look at the source code for OpenSSL_add_all_algorithms(). For each cipher there is a block of code to initialize it. Simply initialize the ones you want in your code. There is no requirement that OpenSSL_add_all_algorithms() be called. Although, I would be interested in where the exception is being generated. Since you are in a debugger, can you present the stack trace for libeay32.dll when built with debug info? Hi Jeffrey: Are you sure your problem is in OpenSSL_add_all_algorithms() and not a call to RAND_poll()? Many of the methods used in RAND_poll() to collect random data are incompatible with COM when called from within DLL initializers. Yes, I have seen it to happen several times in my debugger.I have the problematic code inside a try-catch and I see clearly an exception delivered when execution reaches OpenSSL_add_all_algoritms(). And it isn't the first time this happens to me.Other program I made had a very similar problem (also using COM ) but that time I fixed moving my calls to OpenSSL_add... to be called only one time. I would like to give you a piece of this code, but the calls are so nested and in so many places that it woldn't be useful. I wonder it there would be a method to select only desired ciphers and digests (OpenSLL_add_all_algoritms() would be excessive) in DLLEntryPoint(), called at loading program only one time. Thank you Pablo J. Royo __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Jeffrey Altman * Sr.Software Designer Kermit 95 1.1.21 available now!!! The Kermit Project @ Columbia University SSH plus Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and [EMAIL PROTECTED]OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
0.9.7 20020427 snapshot errors on Win32
cl /Fotmp32dll\s3_pkt.obj -Iinc32 -Itmp32dll /MD /W3 /WX /G5 /Ox /O2 /O b2 /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -DBN_ASM -DMD5_ASM -DSHA1_ASM -DRMD160_ASM /Fdout32dll -DOPENSSL_NO_IDEA -DZLIB -DOPENSSL_THREADS -DDSO_WIN32 -DKRB5_MIT -D_WINDLL -D_DLL -DOPENSSL_BUILD_SHLIBSSL -c .\ssl\s3_pkt.c s3_pkt.c .\ssl\s3_pkt.c(248) : error C2220: warning treated as error - no object file generated .\ssl\s3_pkt.c(248) : warning C4018: '!=' : signed/unsigned mismatch .\ssl\s3_pkt.c(608) : warning C4018: '' : signed/unsigned mismatch int vs unsigned int -- cl /Fotmp32dll\ssl_cert.obj -Iinc32 -Itmp32dll /MD /W3 /WX /G5 /Ox /O2 /Ob2 /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -DBN_ASM -DMD5_ASM -DSHA1_ASM -DRMD160_ASM /Fdout32dll -DOPENSSL_NO_IDEA -DZLIB -DOPENSSL_THREADS -DDSO_WIN32 -DKRB5_MIT -D_WINDLL -D_DLL -DOPENSSL_BUILD_SHLIBSSL -c .\ssl\ssl_cert.c ssl_cert.c .\ssl\ssl_cert.c(828) : error C2065: 'd' : undeclared identifier .\ssl\ssl_cert.c(828) : warning C4013: 'closedir' undefined; assuming extern returning int 'd' does not exist in the Windows implementation -- link /nologo /subsystem:console /machine:I386 /opt:ref /out:out32dll\eng inetest.exe @H:\DOCUME~1\jaltman\LOCALS~1\Temp\nmx03400. cl /Fotmp32dll\ssltest.obj -Iinc32 -Itmp32dll /MD /W3 /WX /G5 /Ox /O2 /Ob2 /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -DBN_ASM -DMD5_ASM -DSHA1_ASM -DRMD160_ASM /Fdout32dll -DOPENSSL_NO_IDEA -DZLIB -DOPENSSL_THREADS -DDSO_WIN32 -DKRB5_MIT -c .\ssl\ssltest.c ssltest.c .\ssl\ssltest.c(1058) : error C2220: warning treated as error - no object file generated .\ssl\ssltest.c(1058) : warning C4018: '' : signed/unsigned mismatch size_t != int -- There is still an issue with perl Configure VC-WIN32 no-idea --with-krb5-flavor=MIT zlib-dynamic which produces in MINFO CFLAG=-DOPENSSL_SYSNAME_WIN32 -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS \ -DDSO_WIN32 -DKRB5_MIT -DOPENSSL_NO_IDEA However, the CFLAG values are not imported into ms\nt*.mak when ms\do_*.bat is executed. The resulting .mak files need to be edited by hand to include the flags -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -DDSO_WIN32 -DKRB5_MIT Jeffrey Altman * Sr.Software Designer Kermit 95 1.1.21 available now!!! The Kermit Project @ Columbia University SSH plus Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and [EMAIL PROTECTED]OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: DES...
From: Jeffrey Altman [EMAIL PROTECTED] jaltman I prefer that des_old.h be compatible with libdes since that apps that jaltman are built using it assume that the api they were using was constant jaltman and unchanging. The way things work now, there is at least no clash with libdes on the symbol level. The whole situation is otherwise a lose-lose one. There will always be someone loseing from the changes we make. Either we lose libdes compatibility by default or we lose the openssl 0.9.6 one. Take your pick. It has been pointed out (and I think I agree) that OpenSSL should prefer to be as compatible with the previous version of itself before being compatible with anything external (like libdes). Yes, but let's remember the reason this whole situation came up in the first place. There are a large number of applications that link to both Kerberos 4 and OpenSSL in place of libdes.a. These applications are not likely to be updated nor supported and yet we don't want to see all of them break simply because they load des.h. jaltman The apps that were designed to use OpenSSL were warned many times that jaltman the API set would change with each build. There are many other things jaltman I need to change in my app to make it build with earlier versions of jaltman OpenSSL. Adding an additional #define to that list is not a big jaltman deal. That makes the decision even easier. Thanks. I'm not sure I made myself clear. The point I was trying to make is that it is very difficult to support in the general sense different OpenSSL versions such as 0.9.5, 0.9.6, and 0.9.7 with a common code base that is unaware of the OpenSSL version number. The reason is that there are too many subtle changes that have taken place over the years. Most of this is primarily due to bug fixes. Some of it is due to the increased feature set. Especially when dealing with questions of certificate verification; available cipher suites; replacement of functions with macros or vice versa; and the new ASN.1 library. Therefore, any attempt to try to maintain compatibility between OpenSSL releases at this point is fool hardy. At best it leads developers into a false sense that their code will just work without actually looking at the semantic changes that have taken place within the API. jaltman And oh, I wrote another blurb about DES_INT a while ago. jaltman No reaction at all. I'd like a reaction, very much even... jaltman jaltman I must have missed this one. Please repost or send the archive link. http://marc.theaimsgroup.com/?t=10151207931r=1w=2 In this post you wrote: After some discussion with OpenBSD folks, I've been convinced that DES_INT should be norm rather than not on most platforms, since int is 32 bits most often, at least on 32- and 64-bit architectures. The blatant exception that I know of would be DOS, where int is usually a 16-bit quantity, and where DES_LONG should be 'unsigned long' rather than 'unsigned int'. As far as I know, DES_LONG is supposed to be a 32-bit quantity. Have I gotten this wrong? If not, I'll make appropriate changes to Configure, and some problems on some 64-bit architectures may go away. I'm not sure I understand the question you are looking for an answer to. Currently there is no reference to DES_INT in any of the DES code. The only reference is to DES_LONG. As far as I can tell by looking at the code, the code assumes that DES_LONG == 32-bits. It would probably make most sense to replace DES_LONG with DES_UINT32 to indicate exactly what is meant by it. Then DES_UINT32 can be defined on a per platform basis to choose the appropriate 32-bit unsigned integer type. Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and [EMAIL PROTECTED]OpenSSL. Interfaces with OpenSSH __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
