Re: [PATCH: CVE-2011-1473]: Fight against DoS in openssl
On 1/16/2012 at 11:31 PM, in message 20120116163148.4f325...@redhat.com, Tomas Hoger tho...@redhat.com wrote: On Wed, 11 Jan 2012 21:04:33 -0700 Guan Jun He wrote: It seems you're trying to address more than just CVE-2011-1473 via this patch, which results in a fairly large patch. Why do you need to track client IP at all? This issue is about client's ability to do unlimited number of renegotiations within single connection. To limit that (either to a maximum total, or rate limiting), you should not really need to care about client's IP. If do not care about client's IP, then the rate limiting is aimless, that means all legitimate ssl requests will be blocked, and cause another 'DoS'. The issue is about renegotiations. If the fix allows all initial handshakes and only penalizes all connections that do many rehanshakes, there's no DoS as you suggest and should be sufficient to address CVE-2011-1473. Actually,the patch is based on the ssl protocol's client hello, initial handshakes and rehanshakes both use this, so the patch does not differ them, find one client hello just increase the counter. So, it can fix both 'initial handshakes DoS' and 'rehanshakes DoS'. thanks, Guanjun Please correct me if I'm wrong, but if I remember correctly, s_server only handles single SSL connection at the time. The next connection is only accepted (SSL handshake) when the existing connection is closed. I'd expect the above test to open 1 SSL connection to s_server, with bunch of other s_client connections being established, but waiting for SSL handshake. This does not sound like a valid test case. Seems like you are right! Do you have any good methord to test this? You want something that does not block rehandshakes. s_server should be sufficient if you're only after limiting renegotiations within one connection. httpd blocks client-initiated renegotiation for a while. stunnel may work as a good target. You probably want to look at something using custom BIO too. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2710] Add missing checks for load_certs_crls failure
The attached trivial patch adds missing check for load_certs_crls
failure in apps.c. It is applicable to 1.0.0 and 1.0.1 branches.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -up openssl-1.0.0a/apps/apps.c.load-certs openssl-1.0.0a/apps/apps.c
--- openssl-1.0.0a/apps/apps.c.load-certs 2010-05-27 16:09:13.0 +0200
+++ openssl-1.0.0a/apps/apps.c 2011-04-28 21:24:06.0 +0200
@@ -1208,7 +1208,8 @@ STACK_OF(X509) *load_certs(BIO *err, con
const char *pass, ENGINE *e, const char *desc)
{
STACK_OF(X509) *certs;
- load_certs_crls(err, file, format, pass, e, desc, certs, NULL);
+ if (!load_certs_crls(err, file, format, pass, e, desc, certs, NULL))
+ return NULL;
return certs;
}
@@ -1216,7 +1217,8 @@ STACK_OF(X509_CRL) *load_crls(BIO *err,
const char *pass, ENGINE *e, const char *desc)
{
STACK_OF(X509_CRL) *crls;
- load_certs_crls(err, file, format, pass, e, desc, NULL, crls);
+ if (!load_certs_crls(err, file, format, pass, e, desc, NULL, crls))
+ return NULL;
return crls;
}
[openssl.org #2711] Fix possible NULL dereference on bad MIME headers
In some cases when a S/MIME message with broken MIME headers is
processed a NULL dereference in mime_hdr_cmp can happen. The attached
patch guards against this dereference.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -up openssl-0.9.8j/crypto/asn1/asn_mime.c.bad-mime openssl-0.9.8j/crypto/asn1/asn_mime.c
--- openssl-0.9.8j/crypto/asn1/asn_mime.c.bad-mime 2008-08-05 17:56:11.0 +0200
+++ openssl-0.9.8j/crypto/asn1/asn_mime.c 2009-01-14 22:08:34.0 +0100
@@ -792,6 +792,10 @@ static int mime_hdr_addparam(MIME_HEADER
static int mime_hdr_cmp(const MIME_HEADER * const *a,
const MIME_HEADER * const *b)
{
+ if ((*a)-name == NULL || (*b)-name == NULL)
+ return (*a)-name - (*b)-name 0 ? -1 :
+ (*a)-name - (*b)-name 0 ? 1 : 0;
+
return(strcmp((*a)-name, (*b)-name));
}
[openssl.org #2712] Be more liberal when trying to recognize the XMPP starttls headers
The attached simple patch allows other possible syntaxes of XMPP
starttls headers to be recognized.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -ru openssl-1.0.0d.old/apps/s_client.c openssl-1.0.0d/apps/s_client.c
--- openssl-1.0.0d.old/apps/s_client.c 2011-07-17 21:05:19.934181169 +0200
+++ openssl-1.0.0d/apps/s_client.c 2011-07-17 21:11:42.747824990 +0200
@@ -1186,7 +1186,7 @@
xmlns='jabber:client' to='%s' version='1.0', host);
seen = BIO_read(sbio,mbuf,BUFSIZZ);
mbuf[seen] = 0;
- while (!strstr(mbuf, starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'))
+ while (!strcasestr(mbuf, starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls') !strcasestr(mbuf, starttls xmlns=\urn:ietf:params:xml:ns:xmpp-tls\))
{
if (strstr(mbuf, /stream:features))
goto shut;
[openssl.org #2713] Move libraries that are not needed for dynamic linking to Libs.private in the .pc files
The attached simple patch moves the libraries that are not needed for
dynamic linking to the Libs.private section in the OpenSSL .pc files.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -up openssl-1.0.0e/Makefile.org.private openssl-1.0.0e/Makefile.org
--- openssl-1.0.0e/Makefile.org.private 2011-11-03 10:01:53.0 +0100
+++ openssl-1.0.0e/Makefile.org 2011-11-22 11:50:27.0 +0100
@@ -326,7 +326,8 @@ libcrypto.pc: Makefile
echo 'Description: OpenSSL cryptography library'; \
echo 'Version: '$(VERSION); \
echo 'Requires: '; \
- echo 'Libs: -L$${libdir} -lcrypto $(EX_LIBS)'; \
+ echo 'Libs: -L$${libdir} -lcrypto'; \
+ echo 'Libs.private: $(EX_LIBS)'; \
echo 'Cflags: -I$${includedir} $(KRB5_INCLUDES)' ) libcrypto.pc
libssl.pc: Makefile
@@ -339,7 +340,8 @@ libssl.pc: Makefile
echo 'Description: Secure Sockets Layer and cryptography libraries'; \
echo 'Version: '$(VERSION); \
echo 'Requires: '; \
- echo 'Libs: -L$${libdir} -lssl -lcrypto $(EX_LIBS)'; \
+ echo 'Libs: -L$${libdir} -lssl -lcrypto'; \
+ echo 'Libs.private: $(EX_LIBS)'; \
echo 'Cflags: -I$${includedir} $(KRB5_INCLUDES)' ) libssl.pc
openssl.pc: Makefile
@@ -352,7 +354,8 @@ openssl.pc: Makefile
echo 'Description: Secure Sockets Layer and cryptography libraries and tools'; \
echo 'Version: '$(VERSION); \
echo 'Requires: '; \
- echo 'Libs: -L$${libdir} -lssl -lcrypto $(EX_LIBS)'; \
+ echo 'Libs: -L$${libdir} -lssl -lcrypto'; \
+ echo 'Libs.private: $(EX_LIBS)'; \
echo 'Cflags: -I$${includedir} $(KRB5_INCLUDES)' ) openssl.pc
Makefile: Makefile.org Configure config
[openssl.org #2714] Fix build with no-srp option
OpenSSL-1.0.1-beta2 build with no-srp option fails because there are
some missing #ifdef OPENSSL_NO_SRP directives in the s_server code. The
attached patch fixes this.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -up openssl-1.0.1-beta2/apps/progs.pl.no-srp openssl-1.0.1-beta2/apps/progs.pl
--- openssl-1.0.1-beta2/apps/progs.pl.no-srp 2009-06-30 17:08:38.0 +0200
+++ openssl-1.0.1-beta2/apps/progs.pl 2012-02-07 01:14:08.979758307 +0100
@@ -51,6 +51,8 @@ foreach (@ARGV)
{ print #ifndef OPENSSL_NO_CMS\n${str}#endif\n; }
elsif ( ($_ =~ /^ocsp$/))
{ print #ifndef OPENSSL_NO_OCSP\n${str}#endif\n; }
+ elsif ( ($_ =~ /^srp$/))
+ { print #ifndef OPENSSL_NO_SRP\n${str}#endif\n; }
else
{ print $str; }
}
diff -up openssl-1.0.1-beta2/apps/s_server.c.no-srp openssl-1.0.1-beta2/apps/s_server.c
--- openssl-1.0.1-beta2/apps/s_server.c.no-srp 2012-02-07 01:04:12.0 +0100
+++ openssl-1.0.1-beta2/apps/s_server.c 2012-02-07 01:13:21.573362310 +0100
@@ -2248,6 +2248,7 @@ static int sv_body(char *hostname, int s
{ static count=0; if (++count == 100) { count=0; SSL_renegotiate(con); } }
#endif
k=SSL_write(con,(buf[l]),(unsigned int)i);
+#ifndef OPENSSL_NO_SRP
while (SSL_get_error(con,k) == SSL_ERROR_WANT_X509_LOOKUP)
{
BIO_printf(bio_s_out,LOOKUP renego during write\n);
@@ -2258,6 +2259,7 @@ static int sv_body(char *hostname, int s
BIO_printf(bio_s_out,LOOKUP not successful\n);
k=SSL_write(con,(buf[l]),(unsigned int)i);
}
+#endif
switch (SSL_get_error(con,k))
{
case SSL_ERROR_NONE:
@@ -2305,6 +2307,7 @@ static int sv_body(char *hostname, int s
{
again:
i=SSL_read(con,(char *)buf,bufsize);
+#ifndef OPENSSL_NO_SRP
while (SSL_get_error(con,i) == SSL_ERROR_WANT_X509_LOOKUP)
{
BIO_printf(bio_s_out,LOOKUP renego during read\n);
@@ -2315,6 +2318,7 @@ again:
BIO_printf(bio_s_out,LOOKUP not successful\n);
i=SSL_read(con,(char *)buf,bufsize);
}
+#endif
switch (SSL_get_error(con,i))
{
case SSL_ERROR_NONE:
@@ -2392,6 +2396,7 @@ static int init_ssl_connection(SSL *con)
i=SSL_accept(con);
+#ifndef OPENSSL_NO_SRP
while (i = 0 SSL_get_error(con,i) == SSL_ERROR_WANT_X509_LOOKUP)
{
BIO_printf(bio_s_out,LOOKUP during accept %s\n,srp_callback_parm.login);
@@ -2402,6 +2407,7 @@ static int init_ssl_connection(SSL *con)
BIO_printf(bio_s_out,LOOKUP not successful\n);
i=SSL_accept(con);
}
+#endif
if (i = 0)
{
if (BIO_sock_should_retry(i))
@@ -2626,6 +2632,7 @@ static int www_body(char *hostname, int
if (hack)
{
i=SSL_accept(con);
+#ifndef OPENSSL_NO_SRP
while (i = 0 SSL_get_error(con,i) == SSL_ERROR_WANT_X509_LOOKUP)
{
BIO_printf(bio_s_out,LOOKUP during accept %s\n,srp_callback_parm.login);
@@ -2636,7 +2643,7 @@ static int www_body(char *hostname, int
BIO_printf(bio_s_out,LOOKUP not successful\n);
i=SSL_accept(con);
}
-
+#endif
switch (SSL_get_error(con,i))
{
case SSL_ERROR_NONE:
[openssl.org #2715] Interoperability of SSL communication on Windows XP between .NET and OpenSSL 1.0.0e
I'm writing an OpenSSL client program. It must interoperate with some .NET code that uses the SslStream classes. The .NET code is correct. If I create a .NET client it connects correctly. If I run the .NET server on Windows 7 it works correctly (with .NET client and with C plus OpenSSL client). If I run the .NET server code on Windows XP only the .NET client code works correctly. The OpenSSL code doesn't work. It returns 5760:error:1408F0C6:SSL routines:SSL3_GET_RECORD:packet length too long:.\ssl\s3_pkt.c:357 I've read this request http://comments.gmane.org/gmane.comp.encryption.openssl.user/28201 but the solution doesn't solve my problem (the suggestion is to use the SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER option) I've tried adding the -bugs option to the openssl command line tool (and/or adding the SSL_OP_ALL option to my C code) but I always get that error. The server requires a client certificate. I'm including a trace of the openssl command line tool: C:\OpenSslPackageopenssl s_client -debug -msg -state -nbio_test -tlsextdebug -bugs -connect 127.0.0.1:444 -certform PEM -cert client.crt -key client.key Enter pass phrase for client.key: Loading 'screen' into random state - done CONNECTED(0774) SSL_connect:before/connect initialization write to 0xa73e98 [0xa740e8] (210 bytes = 4 (0x4)) - 16 03 01 ... 0004 - SPACES/NULS write to 0xa73e98 [0xa740ec] (206 bytes = 6 (0x6)) - cd 01 00 00 c9 03 .. write to 0xa73e98 [0xa740f2] (200 bytes = 2 (0x2)) - 01 4f .O write to 0xa73e98 [0xa740f4] (198 bytes = 6 (0x6)) - 34 e0 20 4e 3b 88 4. N;. write to 0xa73e98 [0xa740fa] (192 bytes = 1 (0x1)) - 99 . write to 0xa73e98 [0xa740fb] (191 bytes = 6 (0x6)) - 8b 59 33 ae 14 6e .Y3..n write to 0xa73e98 [0xa74101] (185 bytes = 6 (0x6)) - df c0 a0 45 3f 56 ...E?V write to 0xa73e98 [0xa74107] (179 bytes = 5 (0x5)) - 94 21 57 03 9b .!W.. write to 0xa73e98 [0xa7410c] (174 bytes = 7 (0x7)) - cd e5 a7 71 91 af 2d ...q..- write to 0xa73e98 [0xa74113] (167 bytes = 4 (0x4)) - 00 00 5c c0 ..\. write to 0xa73e98 [0xa74117] (163 bytes = 7 (0x7)) - 14 c0 0a 00 39 00 38 9.8 write to 0xa73e98 [0xa7411e] (156 bytes = 7 (0x7)) - 00 88 00 87 c0 0f c0 ... write to 0xa73e98 [0xa74125] (149 bytes = 2 (0x2)) - 05 . 0002 - SPACES/NULS write to 0xa73e98 [0xa74127] (147 bytes = 1 (0x1)) - 35 5 write to 0xa73e98 [0xa74128] (146 bytes = 7 (0x7)) - 00 84 c0 12 c0 08 .. 0007 - SPACES/NULS write to 0xa73e98 [0xa7412f] (139 bytes = 1 (0x1)) - 16 . write to 0xa73e98 [0xa74130] (138 bytes = 2 (0x2)) - 00 13 .. write to 0xa73e98 [0xa74132] (136 bytes = -1 (0x)) SSL_connect:error in SSLv2/v3 write client hello B write W BLOCK write to 0xa73e98 [0xa74132] (136 bytes = 1 (0x1)) - c0 . write to 0xa73e98 [0xa74133] (135 bytes = 5 (0x5)) - 0d c0 03 00 0a . write to 0xa73e98 [0xa74138] (130 bytes = 4 (0x4)) - c0 13 c0 09 write to 0xa73e98 [0xa7413c] (126 bytes = 1 (0x1)) 0001 - SPACES/NULS write to 0xa73e98 [0xa7413d] (125 bytes = 1 (0x1)) - 33 3 write to 0xa73e98 [0xa7413e] (124 bytes = -1 (0x)) SSL_connect:error in SSLv2/v3 write client hello B write W BLOCK write to 0xa73e98 [0xa7413e] (124 bytes = 5 (0x5)) - 00 32 00 9a .2.. 0005 - SPACES/NULS write to 0xa73e98 [0xa74143] (119 bytes = 3 (0x3)) - 99 00 45 ..E write to 0xa73e98 [0xa74146] (116 bytes = 1 (0x1)) 0001 - SPACES/NULS write to 0xa73e98 [0xa74147] (115 bytes = 1 (0x1)) - 44 D write to 0xa73e98 [0xa74148] (114 bytes = -1 (0x)) SSL_connect:error in SSLv2/v3 write client hello B write W BLOCK write to 0xa73e98 [0xa74148] (114 bytes = 6 (0x6)) - c0 0e c0 04 00 2f ./ write to 0xa73e98 [0xa7414e] (108 bytes = 3 (0x3)) - 00 96 .. 0003 - SPACES/NULS write to 0xa73e98 [0xa74151] (105 bytes = -1 (0x)) SSL_connect:error in SSLv2/v3 write client hello B write W BLOCK write to 0xa73e98 [0xa74151] (105 bytes = -1 (0x))
[openssl.org #2716] Re: Exporter return value confusion
On Thu, Feb 9, 2012 at 4:33 PM, Adam Langley a...@google.com wrote: This is my bad, I didn't realise that s_client had any calls in it. I'll fix it. (By fixing s_client I think). Dear Ben, please see attached patch. Cheers AGL patch Description: Binary data
[openssl.org #2715] Interoperability of SSL communication on Windows XP between .NET and OpenSSL 1.0.0e
[xana...@geocities.com - Fri Feb 10 10:54:26 2012]: I'm writing an OpenSSL client program. It must interoperate with some .NET code that uses the SslStream classes. The .NET code is correct. If I create a .NET client it connects correctly. If I run the .NET server on Windows 7 it works correctly (with .NET client and with C plus OpenSSL client). If I run the .NET server code on Windows XP only the .NET client code works correctly. The OpenSSL code doesn't work. It returns 5760:error:1408F0C6:SSL routines:SSL3_GET_RECORD:packet length too long:.\ssl\s3_pkt.c:357 I've read this request http://comments.gmane.org/gmane.comp.encryption.openssl.user/28201 but the solution doesn't solve my problem (the suggestion is to use the SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER option) read from 0xa73e98 [0xa79648] (7 bytes = 7 (0x7)) - 16 03 01 86 f4 02 .. 0007 - SPACES/NULS Translating the above. Handshake protocol, TLS 1.0 and length of 0x86f4 whereas RFC2246 states a maximum of 2^14 == 0x4000. The big buffer workaround adds another 0x4000 but that still isn't enough. The server is fairly clearly violating the specs here. You could try upping the value of SSL3_RT_MAX_EXTRA and also using the big buffer flag to see if that helps. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
FIPS Module 2.0 -- using non-FIPS ciphers
I am experimenting with the OpenSSL FIPS Module 2.0, but am encountering some
difficulty.
I need to perform some RC4 calculations in code that does not need to be FIPS
compliant, even though I want all FIPS ciphers to be performed in FIPS mode.
I'm trying to use the EVP_CIPH_FLAG_NON_FIPS_ALLOW flag, but no matter what I
do it is ignored. If I set the flag via
EVP_CIPHER_CTX_set_flags(m_ctx, EVP_CIPH_FLAG_NON_FIPS_ALLOW);
then calling
EVP_CipherInit(m_ctx, EVP_rc4(), NULL, NULL, 1);
first wipes out my context via the following in evp_enc.c:
int EVP_CipherInit(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *cipher,
const unsigned char *key, const unsigned char *iv, int enc)
{
if (cipher)
EVP_CIPHER_CTX_init(ctx);
return EVP_CipherInit_ex(ctx,cipher,NULL,key,iv,enc);
}
Even if I use the _ex version to avoid this
EVP_CipherInit_ex(m_ctx, EVP_rc4(), NULL, NULL, NULL, 1);
then the following code in evp_enc.c / EVP_CipherInit_ex() also ends up wiping
the flags out:
if (cipher)
{
/* Ensure a context left lying around from last time is cleared
* (the previous check attempted to avoid this if the same
* ENGINE and EVP_CIPHER could be used). */
EVP_CIPHER_CTX_cleanup(ctx);
Since all paths seem to cause the code to wipe out my
EVP_CIPH_FLAG_NON_FIPS_ALLOW flags setting before the call to
FIPS_cipherinit(ctx, cipher, key, iv, enc) gets a chance to test it in order to
allow it, what is the proper mechanism for creating an EVP_CIPHER usage that
will be allowed in FIPS mode?
Thanks,
Erik
Erik Tkal
Juniper OAC/UAC/Pulse Development
Re: FIPS Module 2.0 -- using non-FIPS ciphers
On Fri, Feb 10, 2012 at 09:39:20AM -0500, Erik Tkal wrote: I am experimenting with the OpenSSL FIPS Module 2.0, but am encountering some difficulty. I need to perform some RC4 calculations in code that does not need to be FIPS compliant, even though I want all FIPS ciphers to be performed in FIPS mode. You should talk to whoever wrote the security policy for your device or application. To do this without compromising your FIPS validation, you likely need to move the code in question -- the code that uses a non-FIPS cipher -- outside the module boundary. It is probably a good rule of thumb that if symbols in the same instance of the OpenSSL library used within the boundary are visible to your code that is using a non-Approved algorithm, the code using the non-Approved algorithm is (improperly) within the module boundary. If you move the code outside the module boundary, you should be able to link it to a different copy of OpenSSL, and the problem should go away. I suppose you might be using RC4 to generate initialization vectors. I cannot remember whether that is allowed. If it is, you likely need a constrained, standalone RC4 implementation (which would only be about 10 lines of code) that you can prove to the test lab validating your device or application is actually never used (or not usable) for any purpose other than IV generation. If you are relying on OpenSSL's certificate in order to claim FIPS 140 compliance for your application or device, it is definitely improper to have other implementations of cryptographic algorithms floating around unless you can clearly establish (and advertise) that they are part of a separate application which is _not_ FIPS 140 compliant. Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: FIPS Module 2.0 -- using non-FIPS ciphers
Yes, I understand all that; we currently have our own certified FIPS module that I wired into OpenSSL via the engine APIs. Assuming that the module boundary is the code in the FIPS canister, I want that module to perform all FIPS-compliant operations, but still need the outer OpenSSL to perform other operations. For example, authentication with EAP-TTLS can use weaker inner authentication protected by the stronger outer tunnel. MS-CHAPv2, e.g. uses NT password hashing. It seems the purpose of these NON_FIPS_ALLOW flags is for exactly this reason - that a developer can decide what is allowable for a FIPS-capable OpenSSL in FIPS mode based on the context of the actual crypto operations relative to what is required to be truly FIPS compliant. It just seems in this case that the implementation is not correct in order to allow this (the FIPS_cipherinit in fipscanister checks this flag, but the FIPS-capable implementation around it happens to clear the flag before it can be analyzed). Erik Tkal Juniper OAC/UAC/Pulse Development -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Thor Lancelot Simon Sent: Friday, February 10, 2012 9:52 AM To: openssl-dev@openssl.org Subject: Re: FIPS Module 2.0 -- using non-FIPS ciphers On Fri, Feb 10, 2012 at 09:39:20AM -0500, Erik Tkal wrote: I am experimenting with the OpenSSL FIPS Module 2.0, but am encountering some difficulty. I need to perform some RC4 calculations in code that does not need to be FIPS compliant, even though I want all FIPS ciphers to be performed in FIPS mode. You should talk to whoever wrote the security policy for your device or application. To do this without compromising your FIPS validation, you likely need to move the code in question -- the code that uses a non-FIPS cipher -- outside the module boundary. It is probably a good rule of thumb that if symbols in the same instance of the OpenSSL library used within the boundary are visible to your code that is using a non-Approved algorithm, the code using the non-Approved algorithm is (improperly) within the module boundary. If you move the code outside the module boundary, you should be able to link it to a different copy of OpenSSL, and the problem should go away. I suppose you might be using RC4 to generate initialization vectors. I cannot remember whether that is allowed. If it is, you likely need a constrained, standalone RC4 implementation (which would only be about 10 lines of code) that you can prove to the test lab validating your device or application is actually never used (or not usable) for any purpose other than IV generation. If you are relying on OpenSSL's certificate in order to claim FIPS 140 compliance for your application or device, it is definitely improper to have other implementations of cryptographic algorithms floating around unless you can clearly establish (and advertise) that they are part of a separate application which is _not_ FIPS 140 compliant. Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Module 2.0 -- using non-FIPS ciphers
On Fri, Feb 10, 2012 at 10:01:43AM -0500, Erik Tkal wrote: Yes, I understand all that; we currently have our own certified FIPS module that I wired into OpenSSL via the engine APIs. Assuming that the module boundary is the code in the FIPS canister, I want that module to perform all FIPS-compliant operations, but still need the outer OpenSSL to perform other operations. Personally, I think if they're in the same address space (or, at least, namespace) this is dubious. But you probably have people advising you (or available to advise you) who know a lot better than I do! Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2715] Interoperability of SSL communication on Windows XP between .NET and OpenSSL 1.0.0e
So I would have to recompile the OpenSSL and link against my version. Would it be possible in a future version to make SSL3_RT_MAX_EXTRA a runtime-settable parameter? As it's now it's a constant, but it's used only dynamically (no static buffer is allocated through it). From: Stephen Henson via RT r...@openssl.org To: xana...@geocities.com Cc: openssl-dev@openssl.org Sent: Friday, February 10, 2012 3:10 PM Subject: [openssl.org #2715] Interoperability of SSL communication on Windows XP between .NET and OpenSSL 1.0.0e [xana...@geocities.com - Fri Feb 10 10:54:26 2012]: I'm writing an OpenSSL client program. It must interoperate with some .NET code that uses the SslStream classes. The .NET code is correct. If I create a .NET client it connects correctly. If I run the .NET server on Windows 7 it works correctly (with .NET client and with C plus OpenSSL client). If I run the .NET server code on Windows XP only the .NET client code works correctly. The OpenSSL code doesn't work. It returns 5760:error:1408F0C6:SSL routines:SSL3_GET_RECORD:packet length too long:.\ssl\s3_pkt.c:357 I've read this request http://comments.gmane.org/gmane.comp.encryption.openssl.user/28201 but the solution doesn't solve my problem (the suggestion is to use the SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER option) read from 0xa73e98 [0xa79648] (7 bytes = 7 (0x7)) - 16 03 01 86 f4 02 .. 0007 - SPACES/NULS Translating the above. Handshake protocol, TLS 1.0 and length of 0x86f4 whereas RFC2246 states a maximum of 2^14 == 0x4000. The big buffer workaround adds another 0x4000 but that still isn't enough. The server is fairly clearly violating the specs here. You could try upping the value of SSL3_RT_MAX_EXTRA and also using the big buffer flag to see if that helps. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org So I would have to recompile the OpenSSL and link against "my" version. Would it be possible in a future version to makeSSL3_RT_MAX_EXTRA a runtime-settable parameter? As it's now it's a constant, but it's used only dynamically (no static buffer is allocated through it).From: Stephen Henson via RT r...@openssl.org To: xana...@geocities.com Cc: openssl-dev@openssl.org Sent: Friday, February 10, 2012 3:10 PM Subject: [openssl.org #2715] Interoperability of SSL communication on Windows XP between .NET and OpenSSL 1.0.0e [xana...@geocities.com - Fri Feb 10 10:54:26 2012]: I'm writing an OpenSSL client program. It must interoperate with some .NET code that uses the SslStream classes. The .NET code is correct. If I create a .NET client it connects correctly. If I run the .NET server on Windows 7 it works correctly (with .NET client and with C plus OpenSSL client). If I run the .NET server code on Windows XP only the .NET client code works correctly. The OpenSSL code doesn't work. It returns 5760:error:1408F0C6:SSL routines:SSL3_GET_RECORD:packet length too long:.\ssl\s3_pkt.c:357 I've read this request http://comments.gmane.org/gmane.comp.encryption.openssl.user/28201 but the solution doesn't solve my problem (the suggestion is to use theSSL_OP_MICROSOFT_BIG_SSLV3_BUFFER option) read from 0xa73e98 [0xa79648] (7 bytes = 7 (0x7)) - 16 03 01 86 f4 02 .. 0007 - SPACES/NULSTranslating the above. Handshake protocol, TLS 1.0 and length of 0x86f4whereas RFC2246 states a maximum of 2^14 == 0x4000. The big bufferworkaround adds another 0x4000 but that still isn't enough.The server is fairly clearly violating the specs here. You could tryupping the value of SSL3_RT_MAX_EXTRA and also using the big buffer flagto see if that helps.Steve.-- Dr Stephen N. Henson. OpenSSL project core developer.Commercial tech support now available see: http://www.openssl.org
RE: [openssl.org #2702] TLS bad_mac_record with IIS 7 and client authentication
I have verified with a new build that I was able to connect WITHOUT forcing the TLS version. So the changes worked in my tests. Thanks for the quick turnaround! -Steve -Original Message- From: Stephen Henson via RT [mailto:r...@openssl.org] Sent: Thursday, February 09, 2012 10:47 AM To: Steve Kapinos (stkapino) Cc: openssl-dev@openssl.org Subject: [openssl.org #2702] TLS bad_mac_record with IIS 7 and client authentication [stkap...@cisco.com - Wed Feb 08 00:12:25 2012]: Results using prexit are attached. Openssl v1.0.1 beta 2 compiled on powerppc/linux Vs Win2008 R2 64bit IIS7 set to require client auth Command issued: openssl s_client -connect stk-tms.a51.lab:443 -cert /config/lighttpd/ssl.pem -CAfile /user/http_calist.pem -prexit -state Output attached I've developed this workaround: http://cvs.openssl.org/chngview?cn=22087 It seems OK on my test server. Let me know of any problems. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: FIPS Module 2.0 -- using non-FIPS ciphers
I'm just saying that there are options to allow this and it just doesn't seem to work. #define EVP_MD_CTX_FLAG_NON_FIPS_ALLOW 0x0008 /* Allow use of non FIPS digest * in FIPS mode */ /* Allow non FIPS cipher in FIPS mode */ #define EVP_CIPH_FLAG_NON_FIPS_ALLOW0x8000 Obviously the EVP_MD_CTX_FLAG_NON_FIPS_ALLOW flag handling works, since the SSL/TLS processing uses this to allow MD5 during the handshake. Erik -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Thor Lancelot Simon Sent: Friday, February 10, 2012 10:08 AM To: openssl-dev@openssl.org Subject: Re: FIPS Module 2.0 -- using non-FIPS ciphers On Fri, Feb 10, 2012 at 10:01:43AM -0500, Erik Tkal wrote: Yes, I understand all that; we currently have our own certified FIPS module that I wired into OpenSSL via the engine APIs. Assuming that the module boundary is the code in the FIPS canister, I want that module to perform all FIPS-compliant operations, but still need the outer OpenSSL to perform other operations. Personally, I think if they're in the same address space (or, at least, namespace) this is dubious. But you probably have people advising you (or available to advise you) who know a lot better than I do! Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Module 2.0 -- using non-FIPS ciphers
On Fri, Feb 10, 2012, Erik Tkal wrote: I'm just saying that there are options to allow this and it just doesn't seem to work. #define EVP_MD_CTX_FLAG_NON_FIPS_ALLOW0x0008 /* Allow use of non FIPS digest * in FIPS mode */ /* Allow non FIPS cipher in FIPS mode */ #define EVP_CIPH_FLAG_NON_FIPS_ALLOW0x8000 Obviously the EVP_MD_CTX_FLAG_NON_FIPS_ALLOW flag handling works, since the SSL/TLS processing uses this to allow MD5 during the handshake. That's a bug. Looking into a fix. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: FIPS Module 2.0 -- using non-FIPS ciphers
Hi Steve, thanks. This also seems to be a general issue with setting other
fields in the context, for example to override the key length (even in non-FIPS
mode) you have to initialize the cipher context with the cipher, then set the
fields in the context, then reinitialize it without specifying the cipher (I
found via googling that you had to do this):
EVP_CIPHER_CTX_init(m_ctx);
EVP_CipherInit_ex(m_ctx, EVP_rc4(), NULL, NULL, NULL, 1); // first
time don't pass key
EVP_CIPHER_CTX_set_key_length(m_ctx, (int)nKeySize); // specify
key length
EVP_CipherInit_ex(m_ctx, NULL, NULL, pKey, NULL, 1); // now set
the key
Ideally one should be able to omit the extra step, since I thought one of the
points of the _ex form was to assume the CTX is already set up?
EVP_CIPHER_CTX_init(m_ctx);
EVP_CIPHER_CTX_set_key_length(m_ctx, (int)nKeySize);
EVP_CipherInit_ex(m_ctx, EVP_rc4(), NULL, pKey, NULL, 1);
I think the following in evp_enc.c at line 123 might work to only clean up the
CTX if you were specifying a cipher and one was already present:
if (cipher)
{
/* Ensure a context left lying around from last time is cleared
* (the previous check attempted to avoid this if the same
* ENGINE and EVP_CIPHER could be used). */
+++if (ctx-cipher)
EVP_CIPHER_CTX_cleanup(ctx);
Thanks,
Erik
Erik Tkal
Juniper OAC/UAC/Pulse Development
-Original Message-
From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On
Behalf Of Dr. Stephen Henson
Sent: Friday, February 10, 2012 11:15 AM
To: openssl-dev@openssl.org
Subject: Re: FIPS Module 2.0 -- using non-FIPS ciphers
On Fri, Feb 10, 2012, Erik Tkal wrote:
I'm just saying that there are options to allow this and it just doesn't seem
to work.
#define EVP_MD_CTX_FLAG_NON_FIPS_ALLOW0x0008 /* Allow use of non
FIPS digest
* in FIPS mode */
/* Allow non FIPS cipher in FIPS mode */
#define EVP_CIPH_FLAG_NON_FIPS_ALLOW0x8000
Obviously the EVP_MD_CTX_FLAG_NON_FIPS_ALLOW flag handling works, since the
SSL/TLS processing uses this to allow MD5 during the handshake.
That's a bug. Looking into a fix.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2715] Interoperability of SSL communication on Windows XP between .NET and OpenSSL 1.0.0e
So I would have to recompile the OpenSSL and link against my version. Would it be possible in a future version to make SSL3_RT_MAX_EXTRA a runtime-settable parameter? As it's now it's a constant, but it's used only dynamically (no static buffer is allocated through it). From: Stephen Henson via RT r...@openssl.org To: xana...@geocities.com Cc: openssl-dev@openssl.org Sent: Friday, February 10, 2012 3:10 PM Subject: [openssl.org #2715] Interoperability of SSL communication on Windows XP between .NET and OpenSSL 1.0.0e [xana...@geocities.com - Fri Feb 10 10:54:26 2012]: I'm writing an OpenSSL client program. It must interoperate with some .NET code that uses the SslStream classes. The .NET code is correct. If I create a .NET client it connects correctly. If I run the .NET server on Windows 7 it works correctly (with .NET client and with C plus OpenSSL client). If I run the .NET server code on Windows XP only the .NET client code works correctly. The OpenSSL code doesn't work. It returns 5760:error:1408F0C6:SSL routines:SSL3_GET_RECORD:packet length too long:.\ssl\s3_pkt.c:357 I've read this request http://comments.gmane.org/gmane.comp.encryption.openssl.user/28201 but the solution doesn't solve my problem (the suggestion is to use the SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER option) read from 0xa73e98 [0xa79648] (7 bytes = 7 (0x7)) - 16 03 01 86 f4 02 .. 0007 - SPACES/NULS Translating the above. Handshake protocol, TLS 1.0 and length of 0x86f4 whereas RFC2246 states a maximum of 2^14 == 0x4000. The big buffer workaround adds another 0x4000 but that still isn't enough. The server is fairly clearly violating the specs here. You could try upping the value of SSL3_RT_MAX_EXTRA and also using the big buffer flag to see if that helps. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org
RE: [openssl.org #2702] TLS bad_mac_record with IIS 7 and client authentication
I have verified with a new build that I was able to connect WITHOUT forcing the TLS version. So the changes worked in my tests. Thanks for the quick turnaround! -Steve -Original Message- From: Stephen Henson via RT [mailto:r...@openssl.org] Sent: Thursday, February 09, 2012 10:47 AM To: Steve Kapinos (stkapino) Cc: openssl-dev@openssl.org Subject: [openssl.org #2702] TLS bad_mac_record with IIS 7 and client authentication [stkap...@cisco.com - Wed Feb 08 00:12:25 2012]: Results using prexit are attached. Openssl v1.0.1 beta 2 compiled on powerppc/linux Vs Win2008 R2 64bit IIS7 set to require client auth Command issued: openssl s_client -connect stk-tms.a51.lab:443 -cert /config/lighttpd/ssl.pem -CAfile /user/http_calist.pem -prexit -state Output attached I've developed this workaround: http://cvs.openssl.org/chngview?cn=22087 It seems OK on my test server. Let me know of any problems. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org
Re: FIPS Module 2.0 -- using non-FIPS ciphers
Just go get source code for RC4 and call it directly when you need RC4.
--David
On 2/10/2012 6:39 AM, Erik Tkal wrote:
I am experimenting with the OpenSSL FIPS Module 2.0, but am
encountering some difficulty.
I need to perform some RC4 calculations in code that does not need to
be FIPS compliant, even though I want all FIPS ciphers to be performed
in FIPS mode.
I'm trying to use the EVP_CIPH_FLAG_NON_FIPS_ALLOW flag, but no matter
what I do it is ignored. If I set the flag via
EVP_CIPHER_CTX_set_flags(m_ctx, EVP_CIPH_FLAG_NON_FIPS_ALLOW);
then calling
EVP_CipherInit(m_ctx, EVP_rc4(), NULL, NULL, 1);
first wipes out my context via the following in evp_enc.c:
int EVP_CipherInit(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *cipher,
const unsigned char *key, const unsigned char *iv, int enc)
{
* if (cipher)*
* EVP_CIPHER_CTX_init(ctx);*
return EVP_CipherInit_ex(ctx,cipher,NULL,key,iv,enc);
}
Even if I use the _ex version to avoid this
EVP_CipherInit_ex(m_ctx, EVP_rc4(), NULL, NULL, NULL, 1);
then the following code in evp_enc.c / EVP_CipherInit_ex() also ends
up wiping the flags out:
*if (cipher)*
{
/* Ensure a context left lying around from last time is
cleared
* (the previous check attempted to avoid this if the same
* ENGINE and EVP_CIPHER could be used). */
*EVP_CIPHER_CTX_cleanup(ctx);*
Since all paths seem to cause the code to wipe out my
EVP_CIPH_FLAG_NON_FIPS_ALLOW flags setting before the call to
FIPS_cipherinit(ctx, cipher, key, iv, enc) gets a chance to test it in
order to allow it, what is the proper mechanism for creating an
EVP_CIPHER usage that will be allowed in FIPS mode?
Thanks,
Erik
Erik Tkal
Juniper OAC/UAC/Pulse Development
No virus found in this message.
Checked by AVG - www.avg.com http://www.avg.com
Version: 2012.0.1913 / Virus Database: 2112/4800 - Release Date: 02/09/12
Re: FIPS Module 2.0 -- using non-FIPS ciphers
On Fri, Feb 10, 2012, Erik Tkal wrote: Hi Steve, thanks. This also seems to be a general issue with setting other fields in the context, for example to override the key length (even in non-FIPS mode) you have to initialize the cipher context with the cipher, then set the fields in the context, then reinitialize it without specifying the cipher (I found via googling that you had to do this): EVP_CIPHER_CTX_init(m_ctx); EVP_CipherInit_ex(m_ctx, EVP_rc4(), NULL, NULL, NULL, 1); // first time don't pass key EVP_CIPHER_CTX_set_key_length(m_ctx, (int)nKeySize); // specify key length EVP_CipherInit_ex(m_ctx, NULL, NULL, pKey, NULL, 1); // now set the key That technique has been documented for some time. See the manual pages for details and examples. Ideally one should be able to omit the extra step, since I thought one of the points of the _ex form was to assume the CTX is already set up? EVP_CIPHER_CTX_init(m_ctx); EVP_CIPHER_CTX_set_key_length(m_ctx, (int)nKeySize); EVP_CipherInit_ex(m_ctx, EVP_rc4(), NULL, pKey, NULL, 1); EVP_CIPHER_CTX_set_key_length performs sanity checks on the supplied key length (you should check the return value for an error code) so it has to know the cipher being used. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Module 2.0 -- using non-FIPS ciphers
On Fri, Feb 10, 2012, Erik Tkal wrote:
I think the following in evp_enc.c at line 123 might work to only clean up
the CTX if you were specifying a cipher and one was already present:
if (cipher)
{
/* Ensure a context left lying around from last time is cleared
* (the previous check attempted to avoid this if the same
* ENGINE and EVP_CIPHER could be used). */
+++ if (ctx-cipher)
EVP_CIPHER_CTX_cleanup(ctx);
Should be fixed now, thanks for the report.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Building OpenSSL on Win7 + VS2010
Hi. I'm not a Windows person so bear with me: I'm trying to ensure that some multi-platform code continues to build and run on Windows, so I'm having to set up a build environment there too. I went looking for MASM and found it on MSDN, but when I try to run it, it complains about the architecture (it's 32-bit and doesn't want to run on a Win7 64-bit platform apparently... probably a broken compatibility check). What do people do? What are the steps? I read: http://www.openssl.org/support/faq.html#BUILD and: INSTALL.W32 but the directions are a little antiquated... they talk about NT and Win 9x. I'm running Win7 in 64-bit mode, but I'm building 32-bit code. Any pointers are appreciated. Thanks, -Philip __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Building OpenSSL on Win7 + VS2010
On Fri, Feb 10, 2012, Philip Prindeville wrote: Hi. I'm not a Windows person so bear with me: I'm trying to ensure that some multi-platform code continues to build and run on Windows, so I'm having to set up a build environment there too. I went looking for MASM and found it on MSDN, but when I try to run it, it complains about the architecture (it's 32-bit and doesn't want to run on a Win7 64-bit platform apparently... probably a broken compatibility check). What do people do? What are the steps? I read: http://www.openssl.org/support/faq.html#BUILD and: INSTALL.W32 but the directions are a little antiquated... they talk about NT and Win 9x. I'm running Win7 in 64-bit mode, but I'm building 32-bit code. Any pointers are appreciated. The instructions are still valid despite being pretty much the same since NT and Win9x. Download and install the free NASM assembler instead, that's the preferred option. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
