Re: [openssl.org #3575] [BUG] FALLBACK_SCSV early in the cipher list breaks handshake
Sorry, my fault. I'll fix this. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3575] [BUG] FALLBACK_SCSV early in the cipher list breaks handshake
The fix will be in the next version. Note that OpenSSL servers aren't expected to see TLS_FALLBACK_SCSV in normal operation (the code is sufficiently version tolerant, etc.), and if you've enabled TLS 1.2, there isn't even a higher protocol version that the client could be falling back from, so the impact of this bug is really low. It's just bad for testing. Bodo __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3432]
__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms
For the record, I have reviewed Adam's versions of the code before these were posted here, and Adam has resolved the problems that I pointed out. As of the latest patch, I think the code is suitable for inclusion in OpenSSL. The final missing part is support that makes it easy to build with or without this NIST P-256 implementation, depending on whether the target platform supports it, similar to the enable-ec_nistp_64_gcc_128 config option for the 64-bit optimized implementations using type __uint128_t. (The current patch unconditionally links in the new files, but we may not even be able to process the new assembler files.) Also, it would be nice to have Shay review our changes to his contribution (the March 11 patch.bz2 as further changed by the April 10 patch) to make sure that while fixing the problems we found, we didn't do unwanted changes. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3113] OpenSSL’s DH implementation uses an unnecessarily long exponent, leading to significant performance loss
The -dsaparam option to dhparam converts DSA parameters to DH and sets the length parameter. Note that this isn't actually safe to do in general; it's OK for ephemeral DH with no re-use of private keys. A shortcoming of our internal format (following from a similar shortcoming of the TLS DH format) is that DH groups and DH public keys don't come with the subgroup order or cofactor: so in general we can't validate that the DH share received from the peer is in the expected subgroup (or even that the generator is for a prime-order subgroup in the first place), because we don't need what that subgroup is. For servers, we could change DH parameter generation to either create safe primes with the exponent length set to the recommended length plus one, or to create Lim-Lee primes and avoid that small-subgroup safety margin. (Or enhance the internal data format and add subgroup checks, which has some advantages and some disadvantages. With Lim-Lee primes, with this we'd have twice the necessary computational cost.) For clients, when we receive a DH key from the server in the ServerKeyExchange message, there's not much we can do about unnecessarily long exponents in general because that message lacks the information needed to decide about exponent length. We can hope that the generator is for a prime-order subgroup or otherwise that the DH prime is a safe prime, but I don't think that this is generally guaranteed by the TLS specification: so someone might get a practical attack from it. What we could do is check for well-known DH groups and set the exponent length accordingly. Has anyone ever done a survey for TLS servers supporting DH, to check how widely used well-known groups are vs. custom DH groups? It used to be the case that DH was little supported in SSL/TLS. Now it's more widely supported, but there's also ECDH support. My immediate reaction about this DH performance issue would be to recommend using ECDH instead. Given the complications, is improving the classical DH case worth the effort? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms
Here is an updated version of the patch. Addressing a) pointer to the function (to select ADCX/ADOX) and b) multiple points addition There is (only) ~1% performance deterioration in due to the pointer being passed now, instead of (originally) being static. You can choose which style is preferable. Thanks! Alternatives would be (a) using a new lock for safe static initialization, or (b) more code duplication to avoid the need for an explicit pointer (there could be two separate implementations for the higher-level routines). However, given the 1% performance penalty, that's a minor issue at this point. Do you have any comment from Intel on the concerns regarding the scattering technique (http://cryptojedi.org/peter/data/chesrump-20130822.pdf)? Bodo __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms
While if (functiona==NULL || functionb==NULL) { asssign functiona,
functionb } can be unsafe, I'd argue that if (functiona==NULL) { assign
functiona } followed by if (functionb) { assign functionb } is.
We're implicitly assuming here that (thanks to alignment, etc.) each
pointer can be accessed atomically, which so far seems reasonable given
the particular platform this code is for. However, the C11 memory model
also allows the compiler to assume there's no write race, and it thus
could, for example, use the same memory location to hold other temporary
values, which could then be misinterpreted as the function pointer by
concurrent threads. See
http://static.usenix.org/event/hotpar11/tech/final_files/Boehm.pdf for
ideas how this might break -- maybe not right now, but possibly with future
compilers, possibly after this code has evolved a bit.
(I'm not promising that it will actually break, but thread-safety analysis
tools are likely to complain loudly. And at some point the code might
actually fail spectacularly.)
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms
This initialization is used for selecting a code path that would use ADCX/ADOX instructions when the processor supports them. The outcome depends only on the appropriate CPUID bits. Therefore, there is no “thread-safe” issue (because any thread would select the same path). I understand that that's the idea, and would have considered the code to be safe a while ago (and might have written the initialization just like that), but actually compiler transformations that are legal with the C memory model could break this. See http://static.usenix.org/event/hotpar11/tech/final_files/Boehm.pdf for inspiration. Your ec_p256_points_mul implementation is much worse than necessary when then input comprises many points Indeed right. However, this patch is intended to optimize ECDSA sign/verify (and ECDH). This usage does not require adding more than a single point. Sure, but there's no compelling reason to make the other (rarer) use cases slower. Also, adapting the addition/subtraction chain used in the existing crypto/ec/ecp_nistp256.c (modified Booth encoding instead of unsigned windows) could make the new implementation even faster. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms
Thanks for the submission! It seems that the BN_MONT_CTX-related code (used in crypto/ecdsa for constant-time signing) is entirely independent of the remainder of the patch, and should be considered separately. Regarding your reference 'S.Gueron and V.Krasnov, Fast Prime Field Elliptic Curve Cryptography with 256 Bit Primes' for you NIST P-256 code, is that document available? (Web search only pointed me back to your patch.) I've noticed that for secret-independent constant-time memory access, your code relies on the scattering approach. However http://cryptojedi.org/peter/data/chesrump-20130822.pdf points out that apparently this doesn't actually work as intended. (Dan Bernstein's earlier references: Sections 14, 15 in http://cr.yp.to/papers.html#cachetiming; http://cr.yp.to/mac/athlon.html.) Note that in your code, OPENSSL_ia32cap_P-dependent initialization of global variables is not done in a thread-safe way. How about entirely avoiding this global state, and passing pointers down to the implementations? Your ec_p256_points_mul implementation is much worse than necessary when then input comprises many points (more precisely, more than one point other than the group generator), because you call ec_p256_windowed_mul multiple times separately and add the results. I'd suggest instead to implement this modeled on ec_GFp_nistp256_points_mul instead to benefit from interleaved left-to-right point multiplication. (This avoids the additional point-double operations from the separate point multiplication algorithm executions going through each additional scalar.) Your approach for precomputation also is different (using fewer point operations based on a larger precomputed table than the one we currently use in ec_GFp_nistp256_points_mul) -- that table size still seems appropriate, so keeping that probably makes sense. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2929] Patch for recursive deadlock in x_pubkey.c [1.0.1c]
This appears to be a duplicate of ticket #2813 (which is fixed, but missed the 1.0.1c release by one day). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2866] Openssl can deadlock OpenSSL version 1.0.1c
This issue has been reported in http://rt.openssl.org/Ticket/Display.html?id=2813 (and fixed). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2635] 1/n-1 record splitting technique for CVE-2011-3389
I think from the point of view of both interoperability and security, the original empty-fragment approach is best when a cipher using 8-byte blocks has been negotiated (usually 3DES), while 1 / n-1 splitting is better for interoperability and fully adequate for large block sizes (AES). Regardless of which of these splitting techniques is chosen, we'd want it to be enabled by default, but it always should be possible to entirely disable this. So I'd suggest to rename SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS to cover 1 / n-1 splitting (e.g., SSL_OP_DONT_SPLIT_FRAGMENTS) while retaining the old name as an alias (#define SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS SSL_OP_DONT_SPLIT_FRAGMENTS). To slightly simplify the code, we could stop worrying about the 8-byte block ciphers (i.e., never use empty fragments, use 1 / n-1 splitting instead), but while using 8-byte blocks comes with known security issues, there's probably no good justification to make this worse [*]. Data that Yngve Pettersen has shown actually suggests that interoperability with 3DES implementations is better with the empty-fragment approach anyway. [*] For a 8-byte block cipher, the 1 / n-1 splitting approach means you 56 MAC bits for randomization in the first block. With some luck (p = 2^-56), these bits will come out as needed by the attacker. You'd typically have other security problems too when using an 8-byte block cipher, but why add to them? I think from the point of view of both interoperability and security, the original empty-fragment approach is best when a cipher using 8-byte blocks has been negotiated (usually 3DES), while 1 / n-1 splitting is better for interoperability and fully adequate for large block sizes (AES). Regardless of which of these splitting techniques is chosen, wed want it to be enabled by default, but it always should be possible to entirely disable this.So Id suggest to rename SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS to cover 1 / n-1 splitting (e.g., SSL_OP_DONT_SPLIT_FRAGMENTS) while retaining the old name as an alias (#define SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS SSL_OP_DONT_SPLIT_FRAGMENTS). To slightly simplify the code, we could stop worrying about the 8-byte block ciphers (i.e., never use empty fragments, use 1 / n-1 splitting instead), but while using 8-byte blocks comes with known security issues, theres probably no good justification to make this worse [*]. Data that Yngve Pettersen has shown actually suggests that interoperability with 3DES implementations is better with the empty-fragment approach anyway. [*] For a 8-byte block cipher, the 1 / n-1 splitting approach means you 56 MAC bits for randomization in the first block. With some luck (p = 2^-56), these bits will come out as needed by the attacker. Youd typically have other security problems too when using an 8-byte block cipher, but why add to them?
Re: [openssl.org #1833] [PATCH] Abbreviated Renegotiations
On Sep 6, 2010, at 10:39 AM, Darryl Miles wrote: The only user of these field(s) is libssl.so itself. The exact meaning, usage and interpretation of the field(s) is a matter of implementation detail which is encapsulated and presented to the application via the document OpenSSL APIs. Ideally this would be true, but in practice various applications do access some fields directly. The big change to stop that would be to move all the struct details completely out of the externally visible header files. Of course, that change too would be rather painful for such applications. Bodo __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1831] PATCH: openssl rand -hex
What is the rationale of not having a newline at the end? It's text, after all? no rationale, just an oversight. So ... I was going to add the newline while working on the patch, but then it occurred to me as you said this comes from OpenBSD CVS I might be breaking something there. No risk then? Bodo __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1831] PATCH: openssl rand -hex
we'll cope ;)
Here's my version of the patch. Let me know if it looks OK for you.
Bodo
Index: CHANGES
===
RCS file: /e/openssl/cvs/openssl/CHANGES,v
retrieving revision 1.1468
diff -u -r1.1468 CHANGES
--- CHANGES 28 Jan 2009 12:54:51 - 1.1468
+++ CHANGES 1 Feb 2009 17:48:03 -
@@ -745,6 +745,9 @@
Changes between 0.9.8j and 0.9.8k [xx XXX ]
+ *) New -hex option for openssl rand.
+ [Matthieu Herrb]
+
*) Print out UTF8String and NumericString when parsing ASN1.
[Steve Henson]
Index: apps/rand.c
===
RCS file: /e/openssl/cvs/openssl/apps/rand.c,v
retrieving revision 1.20
diff -u -r1.20 rand.c
--- apps/rand.c 12 Aug 2007 17:44:27 - 1.20
+++ apps/rand.c 1 Feb 2009 17:48:05 -
@@ -68,7 +68,8 @@
/* -out file - write to file
* -rand file:file - PRNG seed files
- * -base64 - encode output
+ * -base64 - base64 encode output
+ * -hex - hex encode output
* num - write 'num' bytes
*/
@@ -84,6 +85,7 @@
char *outfile = NULL;
char *inrand = NULL;
int base64 = 0;
+ int hex = 0;
BIO *out = NULL;
int num = -1;
#ifndef OPENSSL_NO_ENGINE
@@ -133,6 +135,13 @@
else
badopt = 1;
}
+ else if (strcmp(argv[i], -hex) == 0)
+ {
+ if (!hex)
+ hex = 1;
+ else
+ badopt = 1;
+ }
else if (isdigit((unsigned char)argv[i][0]))
{
if (num 0)
@@ -148,6 +157,9 @@
badopt = 1;
}
+ if (hex base64)
+ badopt = 1;
+
if (num 0)
badopt = 1;
@@ -160,7 +172,8 @@
BIO_printf(bio_err, -engine e - use engine e,
possibly a hardware device.\n);
#endif
BIO_printf(bio_err, -rand file%cfile%c... - seed PRNG from
files\n, LIST_SEPARATOR_CHAR, LIST_SEPARATOR_CHAR);
- BIO_printf(bio_err, -base64 - encode output\n);
+ BIO_printf(bio_err, -base64 - base64 encode
output\n);
+ BIO_printf(bio_err, -hex - hex encode
output\n);
goto err;
}
@@ -210,7 +223,14 @@
r = RAND_bytes(buf, chunk);
if (r = 0)
goto err;
- BIO_write(out, buf, chunk);
+ if (!hex)
+ BIO_write(out, buf, chunk);
+ else
+ {
+ for (i = 0; i chunk; i++)
+ BIO_printf(out, %02x, buf[i]);
+ BIO_puts(out, \n);
+ }
num -= chunk;
}
(void)BIO_flush(out);
Index: doc/apps/rand.pod
===
RCS file: /e/openssl/cvs/openssl/doc/apps/rand.pod,v
retrieving revision 1.5
diff -u -r1.5 rand.pod
--- doc/apps/rand.pod 7 Sep 2001 06:13:26 - 1.5
+++ doc/apps/rand.pod 1 Feb 2009 17:48:15 -
@@ -10,6 +10,7 @@
[B-out Ifile]
[B-rand Ifile(s)]
[B-base64]
+[B-hex]
Inum
=head1 DESCRIPTION
@@ -41,6 +42,10 @@
Perform base64 encoding on the output.
+=item B-hex
+
+Show the output as a hex string.
+
=back
=head1 SEE ALSO
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #1831] PATCH: openssl rand -hex
[...@mindrot.org - Fr. 30. Jan. 2009, 11:52:17]: This patch adds a -hex option to the rand app. E.g. $ openssl rand -hex 8 d203552d5eb39e76 What is the rationale of not having a newline at the end? It's text, after all? Bodo __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1812] the openssl build environment is broken
On Thu, Jan 8, 2009 at 4:01 PM, Felix von Leitner via RT r...@openssl.org wrote: [...] Apart from the inherent wrongness of doing recursive make (see http://miller.emu.id.au/pmiller/books/rmch/ and note that the traditionally cited reason for doing recursive makes, namely being able to go into apps and doing make install to only get the apps content installed, does not actually work with openssl) For this particular point, note that while having all those mini-makefiles is awkward, it does serve a purpose here in that you can individually remove the source code sub-directories corresponding to various cryptographic algorithms that you might want to exclude from your builds (such as for patent reasons). If you say no-rc5 (say) when configuring OpenSSL, then cyrpto/rc5/Makefile won't be invoked at all. Also, while you can't do make install to only install the apps content, you can go to a subdirectory to only *build* the stuff in there (so you won't always have to wait for the recursive make to finish if you're just doing development work within some part of OpenSSL). The sub-Makefile will invoke the master Makefile, instructing it to invoke the appropriate sub-Makefile with appropriate settings (well ... mostly: you've pointed to CC issues). These are aspects that the Recursive Make Considered Harmful paper doesn't talk about. I'm not saying that the whole Configure/Makefile thing shouldn't be thoroughly redone -- it's just much more complex than just pasting everything into a single file. (There's some support for having this done automatically, actually: util/mk1mf.pl, which is used for Windows builds. You can try make makefile.one to see this. Currently this set-up is mostly adding to the overall complexity because many configuration options need to be handled in mk1mf.pl as special cases that are already handled outside mk1mf.pl for Unix builds. Maybe some kind of makefile.one setup should be used for Unix platforms too: we'd be keeping individual per-directory Makefiles mostly to record information on what is in the respective directory [to be used to create makefile.one], but would not actually call these when building stuff.) Bodo __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1695] RSA_padding_check_SSLv23 broken
[EMAIL PROTECTED] - Mi. 04. Jun. 2008, 08:08:00]:
We have addressed the following issue in Mac OS X:
RSA_padding_check_SSLv23 has a bug in the loop that verifies the
presence of eight consecutive 0x03 padding bytes just before the null
marker signifying the end of the padding. The problem is that at the
start of the for loop (for (k= -8; k0; k++)), p points at the byte
*after* the NULL terminator. The eight 0x03 bytes are actually from
p[-9] to p[-2] inclusive. The byte at p[-1] is the NULL. As a result,
if an SSLv2-only client is extraordinarily unlucky, an OpenSSL server
with SSLv2 enabled may erroneously detect a rollback attack. Well,
this could have happened anyway with a probability of 1 in 2^64, but
with this bug the probability was increased to 1 in 2^56.
Thank you very much for your report! I have just checked in the fix
into the OpenSSL CVS (i.e., it will be in the next snapshots, both for
the main development branch and the 0.9.8 stable branch).
Note that your proposed patch isn't quite right, though. The loop is
correct, but the error should still be raised in the case that k == -1,
meaning that p[-9] through p[-2] each had the value 0x03.
Bodo
diff -Naur /var/tmp/OpenSSL.roots/OpenSSL/openssl/crypto/rsa/
rsa_ssl.c ./crypto/rsa/rsa_ssl.c
--- /var/tmp/OpenSSL.roots/OpenSSL/openssl/crypto/rsa/rsa_ssl.c
2000-11-06 14:34:16.0 -0800
+++ ./crypto/rsa/rsa_ssl.c2006-10-11 16:40:48.0 -0700
@@ -130,11 +130,11 @@
RSAerr(RSA_F_RSA_PADDING_CHECK_SSLV23,RSA_R_NULL_BEFORE_BLOCK_MISSING);
return(-1);
}
- for (k= -8; k0; k++)
+ for (k= -9; k-1; k++)
{
if (p[k] != 0x03) break;
}
- if (k == -1)
+ if (k != -1)
{
RSAerr(RSA_F_RSA_PADDING_CHECK_SSLV23,RSA_R_SSLV3_ROLLBACK_ATTACK);
return(-1);
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
[openssl.org #1583] assertion
This transaction appears to have no content __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1346] Re: SSL_accept concurrency in 0.9.7j and 0.9.8b
Current snapshots use a more thorough locking approach that takes into account inconsistent cache views on multi-processor or multi-core systems (where consistency can be reached by obtaining locks). The application has to call CRYPTO_set_id_callback() for OpenSSL to work properly. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1070] PATCH: fix for memory leaks in smime verification
Thanks, this should be fixed in the next snapshots. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #801] Memory leak in pem_lib.c
Thanks, this will be fixed in the next snapshots. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1017] Bug in EC_GROUP_cmp
Thanks for the correction. This will be in the next snapshot. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #674] bug report - lock_dbg_cb
Thanks for the report. This has now been corrected in the CVS. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #555] RSA blinding MT patch
Tom Wu via RT [EMAIL PROTECTED]: Bodo Moeller via RT wrote: The next round of snapshots (20030402, to appear at ftp://ftp.openssl.org/snapshot;type=d in about six hours) should solve the multi-threading problems. Please test them when they are available. The good news is that the fix in the snapshot fixes the problem, but the bad news is that it seems to kill performance in my benchmarks. On a P3-750 running Linux, I get 106 RSA sign/s (1024-bit) with my patch, regardless of the number of simultaneous threads. With the snapshot fix, I get 102 RSA sign/s with one thread, but if I try with 2 or more threads it drops down to 81 sign/s. It's quite possible that I've misconfigured something on my own end, but I suspect that it is more likely that the local blinding operation is slowing things down. Yes, surely this is what is happening, local blinding is somewhat expensive. In the case where the blinding struct is owned by a different thread from the one doing an RSA op, the code has to do a modexp and a mod inverse, as opposed to the two squarings that the update normally does. These two squarings should be changed, though -- OpenSSL should use a random new blinding factor after a couple of RSA secret key operations instead of predictably updating the factor (I didn't want to change all of this at once). So the update code will be slower in the future; not every time, but sometimes. I believe that on most if not all platforms, the cost of putting critical sections around the blinding convert/update will be drastically smaller than the cost of the extra local blinding computation. This depends: on a single-processor machine, indeed additional locking should usually be faster than using local blinding; but for multi-processor systems, the cost of locking could be quite high. There are some strategies that could be used to make blinding faster without expensive locking, but these would require incompatible changes to the RSA and/or BN_BLINDING structures (the addition of thread_id is an incompatible change in theory, but it's one that does not directly affect applications). -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #555] RSA blinding MT patch
Tom Wu via RT [EMAIL PROTECTED]: (Bodo Moeller) via RT wrote: Tom Wu via RT [EMAIL PROTECTED]: Is there any established wisdom on the security implications of refreshing the blinding factor? Assuming that the initial blinding value had sufficient entropy and was unknown to an attacker, is there still some way to carry out a timing attack given the knowledge that the host is just squaring A after each RSA operation? I am not aware of descriptions of such attacks. Maybe it would even suffice to randomly square or cube the factor to avoid potential attacks, but better safe than sorry ... I also wonder if slowing down blinding would weaken the rationale for turning it on all the time when doing RSA? Well, in any case you can still turn it off if it is too slow. I believe that on most if not all platforms, the cost of putting critical sections around the blinding convert/update will be drastically smaller than the cost of the extra local blinding computation. This depends: on a single-processor machine, indeed additional locking should usually be faster than using local blinding; but for multi-processor systems, the cost of locking could be quite high. I just tried benchmarking the snapshot code against my earlier patch on an 8-way P3-700 server (Win2K AS). My patch gets ~100 RSA sign/s (1024-bit) with a single thread and peaks at ~790 RSA sign/s with 8 threads. The 0402 snapshot also starts at ~100 RSA sign/s with 1 thread and peaks at ~650 RSA sign/s with 8 threads. Thanks for the timings. One thing to take into account when interpreting these is that some additional random blinding should be added to your patch; maybe once in ten or hundred RSA operations, so the timing difference would not really change a lot. A more important aspect is that you are comparing just the case that multiple threads do share an RSA structure. A different scenario is that you have multiple threads with *individual* RSA structures -- then the snapshot version will be very fast while the version with locking will be unnecessarily slowed down because the locks are global. This is why we are trying to avoid excessive locking. There are some strategies that could be used to make blinding faster without expensive locking, but these would require incompatible changes to the RSA and/or BN_BLINDING structures (the addition of thread_id is an incompatible change in theory, but it's one that does not directly affect applications). As for what to do for the short term in 0.9.6j or 0.9.7b, is there any chance of using my original patch with the _r methods? It doesn't change either the RSA or BN_BLINDING structures at all, and seems to give the least slowdown on both single and multi-processor systems. Perhaps the always square A behavior should be the default if it is good enough to block the obvious timing attack, with future options to enable random refresh strategies if the caller wants to do a performance/security tradeoff. One idea to consider is to include a second BN_BLINDING slot with each RSA object: the first BN_BLINDING object would be single-threaded (as in the current snapshots), the second one would be shared between all the other threads (and require locking). The major problem is how to do this without harming compatibility too much. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #555] RSA blinding MT patch
[EMAIL PROTECTED] - Mon Mar 31 17:14:12 2003]: The latest snapshots have not been fixed, some more patience is required ... The next round of snapshots (20030402, to appear at ftp://ftp.openssl.org/snapshot;type=d in about six hours) should solve the multi-threading problems. Please test them when they are available. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #558] Patch Openssl 0.9.7a for AIX 5.2 to use /dev/urandom
No patch should be required, not even AIX can be that weird. An official specification for select() is available at http://www.opengroup.org/onlinepubs/007908799/xsh/select.html __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #558] Patch Openssl 0.9.7a for AIX 5.2 to use /dev/urandom
[bodo - Tue Apr 1 16:58:47 2003]: No patch should be required, not even AIX can be that weird. An official specification for select() is available at http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/commtrf1/select.htm This was the wrong link, I meant the www.opengroup.org link that appears my other message ... __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #555] RSA blinding MT patch
On Mon, Mar 31, 2003 at 03:01:10PM +0200, Richard Levitte via RT wrote: Could you please download the latest 0.9.6 snapshot and check that it works for you? As far as I understand, the MT issue has been adressed, but solved in a different manner. The latest snapshots have not been fixed, some more patience is required ... -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #541] Problem with the blinding patch
Terry Kennedy via RT [EMAIL PROTECTED]: I downloaded and configured/built/tested 0.9.7a on BSD/OS 4.3.1 with no problems, using the following commands: [...] The tests completed with no errors. I then applied the blinding patch from http://www.openssl.org//news/secadv_20030317.txt, did make clean and then the same commands as shown above. One of the certificate request tests failed with the following output: [...] 20476:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not seeded:md_rand.c:503:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html Please try again using the latest 0.9.7a snapshot, which is available from ftp://ftp.openssl.org/snapshot;type=d (don't apply the patch, the countermeasure is included with that snapshot). The problem should now be solved; please confirm if the snapshot works for you. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #514] Bug in OpenSSL????
Ralph via RT [EMAIL PROTECTED]: But so far, I can tell you that when SSL_get_error() returns SSL_ERROR_SYSCALL and you inspect errno, it tells EWOULDBLOCK or EAGAIN. By repeating the SSL_* call as long as this condition occurs, I can overcome the problem and the SSL handshake and communication works perfectly. Oh...it's in a multi-threaded application, too! Maybe this helps (OpenSSL compiled with the correct switch for MT - I hope) If OpenSSL is *not* compiler with correct switches for multithreading, that would explain -- in that case, SSL_get_error() could be reading the wrong copy of errno and thus not find the EWOULDBLOCK/EAGAIN code. Here's something to try: find the 'errno' definition for multi-threading in the system header files, which should involve some function call; then use 'nm' to see if that function is mentioned in the OpenSSL object files that you are linking with. (bss_sock.o is the object file to look at.) -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #514] Bug in OpenSSL????
On Wed, Feb 19, 2003 at 06:10:13PM +0100, Ralph via RT wrote: on AIX (64bit) I noticed a major problem with non-blocking sockets. Methods SSL_connect(), SSL_read() and SSL_write() should return SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE if they need to complete their tasks but the socket couldn't handle all the work. But instead, the methods return SSL_ERROR_SYSCALL when the underlying socket gave errno=EWOULDBLOCK or errno=EAGAIN (means: the application should retry with these functions if it has not been completed, yet) from their respective functions (read() and write()). For these specific system error numbers, the SSL functions should return SSL_ERROR_WANT_* return codes, shouldn't they? PS: However, on AIX 4.2 and earlier, this didn't seem to be a problem. Funny, isn't it? (But these versions are not supported by IBM anymore!) It's not SSL_connect() etc. that will return these error codes, it's SSL_get_error(). But probably you meant that, or you would not get SSL_ERROR_SYSCALL. Can you tell what is going on by looking at the definition of SSL_get_error (ssl/ssl_lib.c) and BIO_sock_should_retry and BIO_sock_non_fatal_error (crypto/bio/bss_bio.c)? You might want to add some debugging output in BIO_sock_non_fatal_error(). -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #511] BUG: crypto/ec/ec_key.c:EC_KEY_dup()
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #512] make OpenSSl-0.9.6a
This is not an OpenSSL bug; you should install gcc, and possibly remove /usr/ucb from the PATH. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #495] 0.9.7: tests fail on HPUX 11.00
Removing the +Olibcalls option appears to have solved this problem (apparently some compiler bug, but reportedly the option is deprecated anyway). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #162] SSL_shutdown return 0 in case of SSLv3_client_method
Note that SSL_get_error() is not meant to be used on SSL_shutdown() return values (although it would be good to have some API that behaves similarly to SSL_read, SSL_write, SSL_do_handshake etc. in this respect). If SSL_shutdown() always returns 0 when called multiple times, this is probably because the server (which, presumably, is not OpenSSL-based) does not properly close the connection and fails to send a closure alert. This is a protocol violation; however, it should be safe to tolerate it because connection closure will not have to be authenticated for most application protocols. Ticket closed because this looks like a bug in the server software, which appears to be not OpenSSL-based. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #491] [Fwd: Bug#180067: openssl: 0.9.7 causes gcc in sid to output warnings]
In OpenSSL, the 'info_callback' gets a 'const SSL *' argument; the application in question used 'SSL *', which caused the compiler warning for 0.9.7 (earlier OpenSSL versions did not declare the 'info_callback' argument list at all). The problem has been solved by changing the application accordingly (Debian Bug#180067). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #487] bug in BN_generate_prime for small n.
On Fri, Jan 31, 2003 at 08:12:41AM +0100, Cameron Gregory via RT wrote: for num 15 .. always get the same result.. and it's larger than expected... Reason: The internal OpenSSL function 'probable_prime' (in crypto/bn/bn_prime.c) uses a built-in list of small primes for sieving out candidate random numbers that cannot be prime. But the test does not correctly the handle the special case that the candidate *is* one of small primes in the list -- they will be falsely rejected. Generally the design cannot handle generation of *short* primes well, the desired bit-length is actually treated as a lower limit: if a candidate is rejected, some delta will be added to obtain a new candidate. For very short numbers, this addition is likely to increase the bit-length of the candidate. (Your code requests safe primes, so it is in general impossible to exactly meet the requested bit-length -- there is a two-bit prime, namely 3, but it is not a safe prime.) -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #328] DH_compute_key incompatable with PKCS #3
On Wed, Dec 04, 2002 at 10:16:37AM -0500, Jack Lloyd wrote: I asked Eric Rescorla, and he agreed the section of the TLS RFC was definitely unclear, but he wasn't totally sure which way it should go as far as stripping any leading 0s before using the shared secret to generate keys. It basically depends on what various implementations have decided to do. A safe way for clients to work around this problem for ephemeral DH is to try a new DH secret if the DH result has a leading zero byte. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #482] man page bug for BN_prime_check(s)
Thanks for the report. Actually by coincidence I noticed this typo (which has been in OpenSSL for quite a while) a couple of days ago and corrected it. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #330] Abuse of assert() in crypto/aes/
The AES library (0.9.7-dev, 0.9.8-dev) abuses assert() to check for invalid function parameters. For aes_cbc.c, this includes the case where 'length' is not a multiple of AES_BLOCK_SIZE. For consistency with other ciphers, the library should not require 'length' to be a multiple of the block size. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
On Wed, Sep 25, 2002 at 09:22:20PM +0200, Patrick McCormick via RT wrote: I was looking at some other code in the ssl directory, and the *_method functions in the *_meth.c files appear to use the same initialization idiom I believe they need to be thread-protected also. Fixed. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
On Tue, Sep 24, 2002 at 03:47:14PM -0700, Patrick McCormick wrote:
Many thanks for putting in a lock. However, the race condition has not been
eliminated.
[...]init must be checked after the lock is entered in order to
prevent the client_data setup from happening twice. So, add:
if (init)
{
CRYPTO_w_lock(CRYPTO_LOCK_SSL_METHOD);
if (init)
{
}
CRYPTO_w_unlock(CRYPTO_LOCK_SSL_METHOD);
}
You are absolutely right, of course. I got similar constructs right
in the past, but I guess this time I was too busy with various other
things to really think about what I was writing ...
The next snapshot should really fix the problem.
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[openssl.org #291] race condition in *get_cipher_by_char
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
On Fri, Sep 20, 2002 at 06:19:48PM -0700, Patrick McCormick wrote: Here's one step by step scenario. You are absolutely right about the bug. I somehow had not realized that the memcpy accesses the same struct as the following assignments. We need a lock to fix this. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #262] bug: init race in SSLv3_client_method
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
On Thu, Sep 19, 2002 at 06:28:16PM -0700, Patrick McCormick wrote:
No locking should be needed because the assignments are idempotent.
However, the assignments are not atomic. The following unprotected
operation:
if (init)
{
memcpy((char *)SSLv3_server_data,(char *)sslv3_base_method(),
sizeof(SSL_METHOD));
SSLv3_server_data.ssl_accept=ssl3_accept;
SSLv3_server_data.get_ssl_method=ssl3_get_server_method;
init=0;
}
can result in a thread calling .ssl_accept or .get_ssl_method after the
memcpy but before the assignment.
Can you elaborate? In such cases the other thread should execute the
'if' body too. A potential problem is not about atomicity, but about
reordering of statements (if the assignment to 'init' happens before
on of the other assignements, we have a problem), so it might be
better to make those static variables 'volatile'.
(I'm aware that the code still is bad in theory, but it should work
for all implementations. There's more stuff like that in OpenSSL, but
I can't rewrite all of it ...)
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[openssl.org #274] session ID length bug (in 0.9.6g and 0.9.7beta3)
This SSLeay/OpenSSL behaviour appears to be correct; from RFC 2246: session_id_length This field must have a value of either zero or 16. If zero, the client is creating a new session. If 16, the session_id field __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #262] bug: init race in SSLv3_client_method
All (most?) similar cases clear the 'init' flag *after* having set up the data structures appropriately, e.g. see ssl/s3_meth.c. No locking should be needed because the assignments are idempotent. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #274] session ID length bug (in 0.9.6g and 0.9.7beta3)
Sorry, the RFC 2246 quote was incorrect -- the value 16 is for SSL 2.0 session IDs only, and the SSLeay/OpenSSL interpretation indeed is buggy. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #274] session ID length bug (in 0.9.6g and 0.9.7beta3)
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #259] SHA-256, SHA-384, SHA-512
FIPS PUB 180-2, which defines SHA-256, SHA-384 and SHA-512 in addition to SHA-1, has been published on August 1: http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf These new hash algorithms should be added to the 0.9.8-dev branch. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #258] ssl3_output_cert_chain
Can you elaborate what you think is buggy? 'make test' still succeeds if you substitute 10 for SSL3_RT_MAX_PLAIN_LENGTH in ssl3_write_bytes (ssl/s3_pkt.c), which sort of simulates very long certificate chains. There is a limit to certificate chains (SSL_MAX_CERT_LIST_DEFAULT by __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #247] Openssl fix
Please obtain OpenSSL 0.9.6g. OpenSSL 0.9.6d was the last version __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #254] pem_lib.c
Thanks, the bug has been fixed now in 0.9.6-stable, 0.9.7-stable and __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #217] bug in util/pod2mantest (openssl-0.9.6g)
Ticket 207 is resolved, too (if pod2mantest finds a working pod2man, this is now called directly without explicitly invoking perl). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #199] Bugs
[EMAIL PROTECTED]: Failure! [...] Failed! bc: stack empty Can you condense the bc test file into a single-line test so that we can automatically test if bc has this bug? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #220] bug in config (openssl-0.9.6g, Solaris2.6)
[levitte - Thu Aug 15 16:04:15 2002]: [guest - Thu Aug 15 14:21:45 2002]: Since isalist displays the available native instruction sets ordered in the sense of best performance, I guess the best choice for target would be the leftmost in the list displayed. Under no circumstances should the target be set to something which is not available on the respective platform. Agree? Note that the solaris-sparcv9-cc and solaris-sparcv9-gcc configurations actually use just sparcv8plus code (32 bit); see Configure. Only the solari64-sparcv9-... configuration really needs sparcv9. This is on a sun4u machine with 32-bit OS only: $ isalist sparcv8plus+vis sparcv8plus sparcv8 sparcv8-fsmuld sparcv7 sparc solaris-sparcv9-cc or ...-gcc are the configurations that should be used on this machine. Do you have a sun4u machine on which the solaris-sparcv9-cc/gcc code actually fails? I agree. Please try the attached patch The patch should not be necessary (and should probably be reverted in the CVS). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #217] bug in util/pod2mantest (openssl-0.9.6g)
On Tue, Aug 13, 2002 at 12:28:06PM +0200, via RT wrote: Line 14 in util/pod2mantest should read: try_without_dir=true otherwise 'first iteration' in the for-loop is never executed. The code as it currently is doesn't make too much sense (try_without_dir could be totally abolished), but the change from try_without_dir=true to try_without_dir=flase was intentional: The reason was we want the complete path to pod2man, not just the string 'pod2man'. The reason for this is that the top-level Makefile calls pod2man indirectly, via perl: @pod2man=`cd util; ./pod2mantest ignore`; \ for i in doc/apps/*.pod; do \ fn=`basename $$i .pod`; \ if [ $$fn = config ]; then sec=5; else sec=1; fi; \ echo installing man$$sec/`basename $$i .pod`.$$sec; \ (cd `$(PERL) util/dirname.pl $$i`; \ sh -c $(PERL) $$pod2man \ ^ --section=$$sec --center=OpenSSL \ --release=$(VERSION) `basename $$i`) \ $(INSTALL_PREFIX)$(MANDIR)/man$$sec/`basename $$i .pod`.$$sec; \ done; \ This does not make much sense, though -- if pod2mantest manages to run .../pod2man directly, why call 'perl .../pod2man' instead? The one case where $(PERL) is really needed in the invocation of pod2man is when pod2mantest has not found a working pod2man (in this case util/pod2man.pl is used instead, and it may not be able to find the correct version of perl). I think this should be resolved as follows: - Switch back to try_without_dir=true - Don't explicitly invoke $(PERL) in the Makefile when running pod2man - but give util/pod2mantest an argument so that it can point to perl if needed. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #217] bug in util/pod2mantest (openssl-0.9.6g)
We now call pod2man directly if this works (without explicit invocation of perl). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #205] Patch to crypto/engine/vendor_defns/cswift.h, openssl-e-0.9.6-sta ble-SNAP-20020807, fix crash on Windows
Patch applied. Please send unified or context diffs in the future. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #206] error compiling dll with msvc6
This problem is fixed in 0.9.6f. (You might prefer to wait for 0.9.6g, which will be out very soon.) __ 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
On Tue, Jul 30, 2002 at 06:08:46PM +0300, Arne Ansper wrote: attached is a patch for openssl-0.9.6e that removes the usage of die. please review it carefully. all changes are localized but the action i take in some places where error reporting is not possible might be little bit wrong (i.e. in ssl2_generate_key_material(). this is void function, so i cannot indicate error). Thanks for the patch. For static functions, you can safely change void into int so that you can indicate the errors properly. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #141] Error while writing zero-length string
On Fri, Jul 19, 2002 at 10:39:21AM +0200, Martin Sjögren via RT wrote: Note that it's perfectly valid to call write(2) with an empty string [...] This is true only for regular files. According to the The Single UNIX Specification, Version 2, and related write() manual pages on systems such as Solaris: If nbyte is 0, write() will return 0 and have no other results if the file is a regular file; otherwise, the results are unspecified. A warning in the man pages for SSL_write (and probably SSL_read too) would a good start for this. I agree. Actually it should be quite easy to change OpenSSL so that this problem is avoided (I just can't do this in the the 0.9.6 branch because I have to extend the SSL structure, which will destroy binary compatibility). -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #125] [Enhancement] --certdir option for cert/key directory
Often, the cert/key directory is not used at all; otherwise it should be easy to use symbolic links to get the desired effect. Thus it should be possible to do without the '--certdir' patch. A reason for *not* introducing '--certdir' is that the '--prefix'/'--openssldir' situation is already a little bit complicated w.r.t. default values, and there have been proposals to simplify it. '--certdir' would further complicate the current situation. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #50] openssl-0.9.6d 'make test' fails (gcc, Solaris)
In similar configurations with gcc version 2.95.2, I observe none of these problems. This suggests that the problems may be due to compiler bugs in your gcc version; please try gcc 2.95.2 or a different newer release and report if the problems persist. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #118] How to implement OPENssl on AS 400
This is not a report on an actual problem in OpenSSL, and there has been no updated to the original request since June 25th; so nothing to do for us about this at the moment. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #149] [PATCH] apps/ca.c crl issuer patch
apps/ca.c has now been changed as suggested; thanks for the patch. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #141] Error while writing zero-length string
Martin Sjögren: When you write a zero-length string with SSL_write, OpenSSL signals a protocol-violating EOF even though no such thing has happened. My guess is that a zero returned is misinterpreted somewhere though I have not had time to dig through the source. SSL_write() with length 0 will return 0, and this return value is always interpreted as protocol-violating EOF according to the SSL_get_error() manpage (SSL_get_error() returns SSL_ERROR_ZERO_RETURN). This is an inconsistency, but even if we change SSL_write() to return a different value, the program will not work -- we cannot return a positive value, and negative values would be interpreted as errors too. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ 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 #127] AES draft cipher suites
Lutz Jaenicke: I have already worked in the cipher selection routines yesterday with respect to PR#130. I will add an appropriate NOTDEFAULT selection keyword that will cover cipher suites not selected by default. As this is a new feature I intend to only add it to 0.9.7 (and later). Technically spoken we have two things: * ALL: all ciphers _except_ eNULL (no encryption is left out) * DEFAULT: ALL ciphers, then ADH is removed, then some sorting We would therefore have two classes of non-selected ciphers: * NODEFAULT: meaning effectively ADH in the moment * NOALL: meaning effectively eNULL in the moment Of course, this distinction is not necessarily clear unless you look up the realization of DEFAULT and ALL. Should I realize both classes? Actually it would make sense from the logical point of view and in the documentation I would propose to use something like RSA:NODEFAULT:NOALL to unselect the unwanted ciphers. I propose NOALL instead of NONE in order to reflect its logic interaction with the ALL keyword. The NO prefix in NODEFAULT and NOALL could be misleading. (Of course, NONE isn't any better.) COMPLEMENT_OF_ALL and COMPLEMENT_OF_DEFAULT is clearer. It is also longer, but it may be worth it. I don't particularly like the RSA:NODEFAULT:NOALL example because the NO... or COMPLEMENT_OF_... group aliases are not really useful for *enabling* ciphersuites (it can be done, but this is quite pointless). Their real purpose is *disabling* ciphersuites: RSA:!COMPLEMENT_OF_ALL or RC4:!COMPLEMENT_OF_DEFAULT will enable all RSA ciphersuites with the exception of the eNULL ciphersuites, and RC4:!COMPLEMENT_OF_DEFAULT will enable all non-anonymous RC4 ciphersuites. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ 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 #127] AES draft cipher suites
RFC3268 makes the AES cipher suites official, so the AESdraft problem no longer exists. However, it would still be a good idea to create a NONE cipher suite group alias because it is useful in the other scenarios given in the problem description. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #127] AES draft cipher suites
While the AES cipher suites from draft-ietf-tls-ciphersuite-06.txt are disabled by default and not part of ALL (the AESdraft group alias can be used to enable them), they might be accidentily enabled by using cipher suite strings such as RSA. The reason for disabling them unless explicitly requested is that they are not yet official, so it may be a problem if seemingly innocuous strings such as RSA enable them. (Similarly, cipher suite strings such as DES will enable ADH cipher suites that are left out of ALL. But this is less of a problem because these cipher suites are official; they are not in ALL simply because usually anonymous connections are not desired.) A possible strategy is to define a new group alias for all those cipher suites that are not part of ALL, which could be called NONE (unless someone comes up with a more serious name for it). Then !NONE in a cihper suite string will disable all cipher suites that are not in ALL, i.e. RSA:!NONE would be RSA without AESdraft and __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #102] Problem: aes_locl.h on Windows
I have totally removed that '#ifdef' condition, now we include string.h on all systems (which is what we do in most other header files anyway, so this cannot break anything unless it is broken elsewhere too). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #85] 0.9.7 prototype constification problems
Avery Pennarun [EMAIL PROTECTED]: On Thu, Jun 13, 2002 at 01:26:42PM +0200, Bodo Moeller via RT wrote: [[EMAIL PROTECTED] - Thu Jun 6 18:39:34 2002]: It appears the openssl guys goofed in 0.97beta. The prototype for the d2i_RSAPrivateKey function in 0.9.6c, which I use, is like this: d2i_RSAPrivateKey(RSA **a, unsigned char **pp, long length); ie., without a const on the second parameter. The const should have been done like this (I think): const unsigned char * const *pp ...which would be entirely backwards-compatible with old versions of openssl. Could you explain why you think this would improve compatibility (compared with 'const unsigned char **pp', which is how 'pp' should be declared in 0.9.7-beta1, although the exact definition is hidden behind macros)? Any variable that could be passed to a function taking unsigned char ** could also be passed to a function taking const unsigned char * const *. Thus, using the above declaration would make openssl's api 100% source-compatible with previous versions, while promising an increased level of constness. Using const unsigned char **, however, is not 100% api-compatible, because you can't safely pass an unsigned char ** to it, for complicated reasons explained in the URL I sent earlier. [http://www.geocrawler.com/archives/3/362/1997/9/0/2036587/] I see, so this is an C++ speciality. As far as C is concerned, the types should be incompatible between any of these three variants, but compilers tend not to look that close (and otherwise you'd use a cast). Writing code that tries to change a 'const char' object as shown at the above URL is possible -- the actual assignment is illegal, but in general the compiler cannot catch this. In fact the second 'const' would be wrong because the pointer that 'pp' points to is updated to reflect how much of the encoded data has been processed by the d2i_... function. I.e., it is not at all constant. Now, you caught me there. The change I proposed earlier (adding an additional const) would fix API compatibility, but promises a level of constness that you're not actually providing. Unfortunately, I don't know a way around it: the problem is that the beta1 level of constness looks right, but doesn't _actually_ promise the constness that it looks like it does, due to the crazy hackery described in the URL I sent earlier. Prototypes alone don't really guarantee constness anyway. If a function is passed a 'const int *' pointer and knows somehow that the object pointed to is not 'const' (i.e. the pointer was 'int *' originally), it may cast the pointer back to 'int *' and modify the object. It also makes the API incompatible with older versions. I can't pass the address of unsigned char *p to the new function. I guess you'll have to include a cast to the new type depending on the value of OPENSSL_VERSION_NUMBER. I know this is ugly, but I don't think we should un-constify the prototype to avoid such problems. (In fact we'll have to make various other prototype changes to clean up the API, for example 'int' quite often should be 'size_t' etc.) -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #87] Ticket #87, #90 resolved (empty fragments for CBC)
The CBC vulnerability countermeasure that cannot be handled by some broken SSL/TLS implementations can now be disabled with the new SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS option, which is also part of SSL_OP_ALL and thus will be automatically enabled in many OpenSSL applications designed to be compatible with weird implementations. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #65] 0.9.6d: SSL3_GET_RECORD:wrong version number
Status was (automatically?) changed from resolved to open by additional correspondance. The actual status is resolved. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #34] SSL through Netscape Proxy server
Not a bug in OpenSSL, should have been sent to openssl-users __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #27] Legalizing OpenSSL in France
Not an OpenSSL bug, this should be discussed elsewhere (openssl-users). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #87] openssl 0.9.6b to 0.9.6d with IE5.5 and IE6 and 3DES-CBC-SHA hangs
[[EMAIL PROTECTED] - Fri Jun 7 14:22:15 2002]: even though Netscape still works, this should be considered a bug since IE is now broken when in the past it worked fine It is a bug in IE, not in OpenSSL. Note that the problem is avoided when using RC4 ciphersuites, and these are typically preferred by most clients anyway. However OpenSSL clients prefer 3DES ciphersuites by default, so interoperability problems of OpenSSL clients with broken servers must be expected. Future versions of OpenSSL will be modified so that the CBC security workaround that caused these problems with some broken SSL/TLS implementations can be disabled. We have to decide whether to give higher priority to security (enable the workaround by default and let applications that don't need it, such is Apache with mod_ssl or Apache-SSL, disable it) or to interoperability (disable the workaround by default and rely on applications to enable it when it is needed). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #85] 0.9.7 prototype constification problems
[[EMAIL PROTECTED] - Thu Jun 6 18:39:34 2002]: [...] It appears the openssl guys goofed in 0.97beta. The prototype for the d2i_RSAPrivateKey function in 0.9.6c, which I use, is like this: d2i_RSAPrivateKey(RSA **a, unsigned char **pp, long length); ie., without a const on the second parameter. The const should have been done like this (I think): const unsigned char * const *pp ...which would be entirely backwards-compatible with old versions of openssl. Could you explain why you think this would improve compatibility (compared with 'const unsigned char **pp', which is how 'pp' should be declared in 0.9.7-beta1, although the exact definition is hidden behind macros)? In fact the second 'const' would be wrong because the pointer that 'pp' points to is updated to reflect how much of the encoded data has been processed by the d2i_... function. I.e., it is not at all constant. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #65] 0.9.6d: SSL3_GET_RECORD:wrong version number
If you run 's_client' with the '-debug' option, you will see that this server (ebmx.extra.daimlerchrysler.com:443) sends a cleartext string starting with 'HTTP/' when it is supposed to send SSL 3.0 encrypted data. This is where the 'wrong version number' error message comes from -- 0x54 0x54 (ASCII 'TT') is interpreted as a version number by OpenSSL as required by the protocol. So the server is obviously very broken, OpenSSL is not to blame. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
