[openssl.org #1067] OpenSSL symmetric crypto padding check incompatible with XMLENC
Please find below a patch, with spec reference, against OpenSSL 0.9.7g.
It could be argued that XMLENC spec is wrong in insisting on unpredictable
values for the padding because this allows padding to be used as a
covert channel. However, to deploy interoperable implementations it seems
patching OpenSSL is the right thing to do. It has been observed that
other crypto libraries, such as bouncing castle (a pure Java
implementation) do not set all padding bytes to OpenSSL's satisfaction.
--Sampo
--- evp_enc.c~ 2005-01-28 14:03:53.0 +
+++ evp_enc.c 2005-05-12 03:26:44.0 +
@@ -509,6 +509,21 @@
EVPerr(EVP_F_EVP_DECRYPTFINAL,EVP_R_BAD_DECRYPT);
return(0);
}
+#ifdef PADDING_CHECK
+ /* Following loop checks that all padding has known value,
+* presumably to prevent covert channel or some form of
+* chosen text attack. However this check is in violation
+* of [XMLENC] specification section 5.2 subsection
+* Padding, which states that only last octet of the
+* block matters and values of other octets are not
+* predictable. Thus to implement XMLENC decryption with
+* openssl it is necessary to disable this code.
+* -- 11.5.2005, Sampo Kellomaki ([EMAIL PROTECTED])
+*
+* [XMLENC] D. Eastlake, ed., XML Encryption Syntax and
+* Processing, W3C Recommendation 10. Dec. 2002,
+* http://www.w3.org/TR/2002/REC-xmlenc-core-20021210 */
+
for (i=0; in; i++)
{
if (ctx-final[--b] != n)
@@ -517,6 +532,7 @@
return(0);
}
}
+#endif
n=ctx-cipher-block_size-n;
for (i=0; in; i++)
out[i]=ctx-final[i];
Sampo Kellomaki --- Chief Architect --- DirectoryScript
M: +351-918.731.007 F: +351-213.422.185 W: www.symlabs.com
Customize directories - LDAP SOAP Liberty SIP - Directory Extender
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
[openssl.org #1068] X509_NAME_add_entry: inserting with loc == 0 and set == 0 creates wrong set
__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1068] X509_NAME_add_entry: inserting with loc == 0 and set == 0 creates wrong set
Hi, I've created the RT entry above before noticing that I cannot further edit it, sorry! Here are the relevant details to add: The function X509_NAME_add_entry has the following bug: When called with loc == 0 and set == 0, the local variable inc is set using inc = (set == 0) ? 1 : 0; after (!) the parameter set is already overwritten. I noticed this behaviour when writing a function to convert a Distinguished Name from the RFC2253 ASCII representation to the ASN.1 encoding. I created a X509_NAME structure and called the function X509_NAME_add_entry for each RDN with loc == 0 to change the order of RDNs as demanded by RFC2253. When using 3 RDNs, two of them are put in the same set because of the bug. This bug exists at least since version 0.9.5a up to the current CVS version I checked. Regards, Frank __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: version 2 is used for Client Hello when version 3 was requested in client code
On Thu, May 12, 2005 at 09:40:38AM +0200, Thomas wrote: Am Freitag, 13. Mai 2005 20:32 schrieb Bodo Moeller: On Wed, May 11, 2005 at 02:14:23PM +0200, Thomas Biege wrote: You see I use SSLv23_method() and later SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2); to disable SSLv2 support. Is it normal that the Client Hello message is SSLv2 and later TLS is used? Yes. In the past this used to be necessary because some SSL 3.0 implementations were confused by seeing TLS 1.0 records in the Client Hello. But now these issues should be history. Why wasn't SSLv3(.0) be used? Or will only headers of SSLv3(.1) be identified as real SSLv3? I am confused a bit b/c everyone tells you that SSLv2 isn't secure and so usage of it should be avoided... and then it was used silently. Maybe its insecurity doesn't matter in this early stage. With SSL_OP_NO_SSLv2, SSL 2.0 was never used, so its security problems did not apply. The SSL 2.0 compatible client hello message that was generated by SSLv23_client_method() is just a different way of arranging essentially the same information that occurs in an SSL 3.0 or TLS 1.0 client hello message. (You just can't list compression techniques in the SSL 2.0 format, and you can't include TLS extensions. TLS extensions are not yet supported by OpenSSL, though.) When the SSL 2.0 compatible client hello is *not* used, the data sent by the client contains two version numbers: One is the version number in the record headers (the SSL 2.0 format does not have anything like this); the second is the version number given in the actual client hello message (the maximum protocol version supported by the client). In the past when many servers supported only SSL 2.0 and 3.0 but not TLS 1.0, setting the version number in the record header to 3.1 (for TLS 1.0) could lead to some servers rejecting such packets because, not recognizing the record header format, they did not even look at the actual client hello message -- clients had to use the SSL 2.0 format to avoid this server bug. By now, this is no longer a problem, and even when clients use a nonsense version number such as 3.42, servers will simply reply with the maximum protocol version that they support (i.e., either TLS 1.0 or SSL 3.0). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: version 2 is used for Client Hello when version 3 was requested in client code
Why wasn't SSLv3(.0) be used? Or will only headers of SSLv3(.1) be identified as real SSLv3? I am confused a bit b/c everyone tells you that SSLv2 isn't secure and so usage of it should be avoided... and then it was used silently. Maybe its insecurity doesn't matter in this early stage. With SSL_OP_NO_SSLv2, SSL 2.0 was never used, so its security problems did not apply. The SSL 2.0 compatible client hello message that was generated by SSLv23_client_method() is just a different way of arranging essentially the same information that occurs in an SSL 3.0 or TLS 1.0 client hello message. (You just can't list compression techniques in the SSL 2.0 format, and you can't include TLS extensions. TLS extensions are not yet supported by OpenSSL, though.) [...] Thanks for the answer! :) Thomas -- Tom [EMAIL PROTECTED] fingerprint = F055 43E5 1F3C 4F4F 9182 CD59 DBC6 111A 8516 8DBF __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1068] AutoReply: X509_NAME_add_entry: inserting with loc == 0 and set == 0 creates wrong set
Hi, an additional bug in the same function, triggered with the same setup: The loop for incrementing the set value (near the end of the function) has to increment at index i and not at index i-1. Regards, Frank __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1060] [Bug Report] can't build user/issuer certificate chain with different asn1 types in issuer/subject
[EMAIL PROTECTED] - Fri May 6 19:20:48 2005]: Hello, I have noticed a problem while using TC Trustcenter certificates with OpenSSL. The encoding of the 'Subject' in the issuer cert contrains 'T61String' elements while the user cert issued by that sub-CA contains only 'Printablestring' in the 'Issuer' field. Based on that difference in types, OpenSSL is unable to a) find the issuer cert in the certstore because the hashes are different and b) locate the certificate in the stack using sk_find after I placed the issuer cert in the store twice, with both names/hashes. Neither 0.9.7e nord 0.9.8 are able to build the cert chain. I did some debugging with 0.9.7e, which lead me to the conclusions stated above. I rate this behaviour as a bug because the connection between two certs shouldn't be based on the way a string is encoded but on it's value. I'm working on a temp workaround for our specific case but it's by no means a fix for the problem. Almost all certificates not only keeps the same string type but also the same encoding. Doing otherwise would break quite a lot of software. This also violates various standards. For example in RFC3280. The DN comparision algorithm states: (a) attribute values encoded in different types (e.g., PrintableString and BMPString) MAY be assumed to represent different strings; Later on it also states: CAs MUST encode the distinguished name in the subject field of a CA certificate identically to the distinguished name in the issuer field in certificates issued by that CA. Nevertheless newer versions of OpenSSL should handle this situation but not for the directory (CApath) based lookup. If the certificate is added in a file based manner (CAfile) or directly it should be OK. Directory based lookup will be supported at some point but it would break existing hashes. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1040] ctrls of type NO_INPUT don't work
[guest - Wed Apr 6 21:34:12 2005]: Please see proposed patch for crypto/engine/eng_cnf.c. Fix applied, thanks for the report. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1069] How to change default port 443 to 8443?
I am using Oracle HTTP Server Powered by Apache/1.3.19 (Unix) mod_ssl/2.8.1 OpenSSL/0.9.5a mod_fastcgi/2.2.10 mod_perl/1.25 mod_oprocmgr/1.0 configured __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1069] How to change default port 443 to 8443?
This is a question that is well-answered in the relevant documentation (go to http://httpd.apache.org/docs/), and has nothing to do with OpenSSL. Please read it before asking off-topic questions on a developer mailing list. On Thursday 12 May 2005 14:03, via RT wrote: I am using Oracle HTTP Server Powered by Apache/1.3.19 (Unix) mod_ssl/2.8.1 OpenSSL/0.9.5a mod_fastcgi/2.2.10 mod_perl/1.25 mod_oprocmgr/1.0 configured __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
