[PATCH] Fix XMM register clobbering in crypto/aes/asm/aesni-x86_64:aesni_ecb_encrypt() under Win64
This patch fixes clobbering of XMM6-XMM9 registers by the assembler implementation of aesni_ecb_encrypt(). Windows x86_64 ABI requires XMM6-XMM15 registers to be preserved by callee, unlike System V x86_64 ABI. --- a/crypto/aes/asm/aesni-x86_64.pl2014-09-25 22:02:56.0 +0300 +++ b/crypto/aes/asm/aesni-x86_64.pl2014-10-14 13:00:42.085931400 +0300 @@ -584,6 +584,15 @@ .typeaesni_ecb_encrypt,\@function,5 .align16 aesni_ecb_encrypt: +___ +$code.=___ if ($win64); +lea-0x48(%rsp),%rsp# 4*16 bytes for XMM regs + 8 bytes for stack alignment +movdqa%xmm6,(%rsp) +movdqa%xmm7,0x10(%rsp) +movdqa%xmm8,0x20(%rsp) +movdqa%xmm9,0x30(%rsp) +___ +$code.=___; and\$-16,$len jz.Lecb_ret @@ -862,6 +871,15 @@ movups$inout5,0x50($out) .Lecb_ret: +___ +$code.=___ if ($win64); +movdqa(%rsp),%xmm6 +movdqa0x10(%rsp),%xmm7 +movdqa0x20(%rsp),%xmm8 +movdqa0x30(%rsp),%xmm9 +lea0x48(%rsp),%rsp +___ +$code.=___; ret .sizeaesni_ecb_encrypt,.-aesni_ecb_encrypt ___ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: CIPHER STRINGS
- Original Message - From: dE de.tec...@gmail.com To: openssl-dev@openssl.org Sent: Tuesday, 14 October, 2014 6:39:11 AM Subject: Re: CIPHER STRINGS On 10/13/14 17:09, Hubert Kario wrote: - Original Message - From: dE de.tec...@gmail.com To: openssl-dev@openssl.org Sent: Monday, 13 October, 2014 5:38:28 AM Subject: Re: CIPHER STRINGS On 10/13/14 01:13, Viktor Dukhovni wrote: On Sun, Oct 12, 2014 at 11:36:01PM +0530, dE wrote: A command line tool. Like openssl list-ciphersuits My own preference in this case is complete and accurate documentation. This'll also avoid updating the man page with long descriptive text. Even if a command-line tool is created, complete and accurate documentation is not optional. Problem with the documentation is that it's not complete. Many of these don't specify what does the algo do (auth, digest etc...). They're basically just writing the obvious with some notices about openSSL specific implementation. So if you dont know about the algo, you've to google it anyway. backporting documentation fixes is much easier that code fixes (some distributions even have mechanisms to update just the man pages without need of issuing a new binary package) speaking of which, I did recently update ciphers man page on 1.0.1 branch with the intended goal to make it aligned with code actually shipping and more explicit with what different options do. If you think that it still has some unclear parts I'll gladly hear about them. See here for the current version: https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/doc/apps/ciphers.pod If the man page in your distro doesn't include those changes, open a bug report against the distro, we can't help much with this though. Thanks for the contribution. For suggest the kind of algorithm the cipher string targets to be placed somewhere. e.g. kRSA, RSA, ADH, AECDH should have -- Category:Kx Many of these dont specify that these are Kx algorithms. Similarly, AES128, AES256, AES should have Category:Enc It is sorted more or less this way, first key exchanges, then authentication algorithms, encryption algorithms and finally HMACs/PRFs. The exception being FORTEZZA, which is unsupported and you shouldn't use it and GOST algorithms which have very specific and limited use. Problem is that some of those aliases don't have one specific meaning. For example 'ECDH' will match the regular ECDHE key exchange, but it will also match aECDH ciphers, similarly with 'DH'. So you can't assign them to single category. -- Regards, Hubert Kario __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Vuln in SSL 3.0
Hi, Any idea what this is about? Is it a threat for OpenSSL users: http://www.theregister.co.uk/2014/10/14/nasty_ssl_30_vulnerability_to_drop_tomorrow/ Regards, Kris __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: CIPHER STRINGS
On 10/14/14 16:47, Hubert Kario wrote: - Original Message - From: dE de.tec...@gmail.com To: openssl-dev@openssl.org Sent: Tuesday, 14 October, 2014 6:39:11 AM Subject: Re: CIPHER STRINGS On 10/13/14 17:09, Hubert Kario wrote: - Original Message - From: dE de.tec...@gmail.com To: openssl-dev@openssl.org Sent: Monday, 13 October, 2014 5:38:28 AM Subject: Re: CIPHER STRINGS On 10/13/14 01:13, Viktor Dukhovni wrote: On Sun, Oct 12, 2014 at 11:36:01PM +0530, dE wrote: A command line tool. Like openssl list-ciphersuits My own preference in this case is complete and accurate documentation. This'll also avoid updating the man page with long descriptive text. Even if a command-line tool is created, complete and accurate documentation is not optional. Problem with the documentation is that it's not complete. Many of these don't specify what does the algo do (auth, digest etc...). They're basically just writing the obvious with some notices about openSSL specific implementation. So if you dont know about the algo, you've to google it anyway. backporting documentation fixes is much easier that code fixes (some distributions even have mechanisms to update just the man pages without need of issuing a new binary package) speaking of which, I did recently update ciphers man page on 1.0.1 branch with the intended goal to make it aligned with code actually shipping and more explicit with what different options do. If you think that it still has some unclear parts I'll gladly hear about them. See here for the current version: https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/doc/apps/ciphers.pod If the man page in your distro doesn't include those changes, open a bug report against the distro, we can't help much with this though. Thanks for the contribution. For suggest the kind of algorithm the cipher string targets to be placed somewhere. e.g. kRSA, RSA, ADH, AECDH should have -- Category:Kx Many of these dont specify that these are Kx algorithms. Similarly, AES128, AES256, AES should have Category:Enc It is sorted more or less this way, first key exchanges, then authentication algorithms, encryption algorithms and finally HMACs/PRFs. The exception being FORTEZZA, which is unsupported and you shouldn't use it and GOST algorithms which have very specific and limited use. Problem is that some of those aliases don't have one specific meaning. For example 'ECDH' will match the regular ECDHE key exchange, but it will also match aECDH ciphers, similarly with 'DH'. So you can't assign them to single category. You can make an 'others' category that way, or make duplicate entries. I would suggest a table so you can map duplicate entries too. Hope the man page allows tables. You know these strings are used in programs like Apache so they must be clear. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Vuln in SSL 3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 If there is a threat in SSLv3 it seems almost certain to affect OpenSSL. The upstream dev team not commenting on this is probably fairly standard protocol; I believe they don't comment on anything critical that could be exploited before patches are imminent or available. I guess the situation is Watch this space. Sent from Thunderbird for OS X. My PGP public key is automatically attached to this email. On 14/10/2014 15:19, Krzysztof Kwiatkowski wrote: Hi, Any idea what this is about? Is it a threat for OpenSSL users: http://www.theregister.co.uk/2014/10/14/nasty_ssl_30_vulnerability_to_drop_tomorrow/ Regards, Kris __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUPU0UAAoJEIclJNuddDJsNYUP/A00vuZ/PUsoIG/rORgw9yvj Gg9IIfybSodxdVpeQeI98z1wxEh4+6p99MYmZTvJ3RnRATrMn2ymjrYbJz4Jj43q 0d3kg3QQCPnPimFkgCo2IwdT/K2TCZl2pAwIOJn5Mo25nGnVL7WpH62PXjtBLpvz Im7WME5W8qzhZ+cHQJA3A+P5ow9q+aS++/bNk/dq80EON4/gyxRvu/BNl+/DmCfw 2SKP57k8huHj5F0voziNPKLPd2RBtgxS9iAEVZ9bmWLLTxdfTfTs19+VZRm2yyXw KFM2DbeWJORrWkxO0yDPS5FNVv54brkmvu8Iu7Ge3fbYNXSAe5SKJMhmwiXone7S XZFLY9KceZjj1jrX9JLDE8Ivp/gp+9W2LrafguZhYnSeZ2SRtx/vDloPDKrv1V/N ny2EudnX+vN6KRMqfpcGc/NR3/ODfkHkXfKVuZ056oPxsSBCFJSzlVl2gDfMTCDV fH+emZEN2lN9okRIbZadNlGy8Ef34ZvX52CzBonA1u30YI/PiSjiC+8l8HxjEDJv VhZSJb2dwMJX/7AtXGcEL9C9avRmfzjFullbaCM5HDnKlwvUC/04HkYuydft66XW VrILhscdrGiBOIiQTaJuiJPBavSQEt8LCYpZOS74icvlB5RzI8Mk8I6V976XzBoS QAGulIxAp/+CYisBYr6j =3vi3 -END PGP SIGNATURE- 0x9D74326C.asc Description: application/pgp-keys 0x9D74326C.asc.sig Description: Binary data
RE: [openssl.org #3564]
Have attempted another build using Win 32 option perl Configure VC-WIN32 no-asm no-hw ms\do_ms completes without error or warnings. Running nmake -f ms\ntdll.mak compiles all C code but generates the following error on linking rc /fotmp32dll\libeay32.res /d CRYPTO ms\version32.rc Microsoft (R) Windows (R) Resource Compiler Version 6.2.9200.16384 Copyright (C) Microsoft Corporation. All rights reserved. link /nologo /subsystem:console /opt:ref /debug /dll /out:out32dll\libeay32.dll /def:ms/LIBEAY32.def @C:\Users\nmangino\AppData\Local\Temp\nm9D07.tmp Creating library out32dll\libeay32.lib and object out32dll\libeay32.exp bss_fd.obj : error LNK2001: unresolved external symbol _OPENSSL_UplinkTable bss_file.obj : error LNK2019: unresolved external symbol _OPENSSL_UplinkTable referenced in function _BIO_new_file b_dump.obj : error LNK2001: unresolved external symbol _OPENSSL_UplinkTable out32dll\libeay32.dll : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN\link.EXE' : return code '0x460' Stop. Better now but can't get away from this uplink error. Again, I appreciate any help you can give. -Original Message- From: The default queue via RT [mailto:r...@openssl.org] Sent: Tuesday, October 14, 2014 1:49 AM To: Mangino, Nicholas @ CSG - CSE Subject: [openssl.org #3564] AutoReply: Build error OpenSSL 1.0.1i Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: Build error OpenSSL 1.0.1i, a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [openssl.org #3564]. Please include the string: [openssl.org #3564] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, r...@openssl.org - I am attempting to build Open SSL 1.0.1.i on Intel 64, Windows 7, using Visual Studio Professional 2012. I configured the build with perl Configure debug-VC-WIN64I no-asm no-hw ms\do_win64i complains about not finding ias but continues. Running nmake -f ms\ntdll.mak generates the following errors ml /c ms\uptable.asm Microsoft (R) Macro Assembler Version 11.00.50727.1 Copyright (C) Microsoft Corporation. All rights reserved. Assembling: ms\uptable.asm ms\uptable.asm(1) : error A2008:syntax error : . ms\uptable.asm(2) : error A2044:invalid character in file ms\uptable.asm(3) : error A2044:invalid character in file ms\uptable.asm(5) : error A2044:invalid character in file ms\uptable.asm(6) : error A2034:must be in segment block ms\uptable.asm(7) : error A2008:syntax error : . ms\uptable.asm(8) : error A2045:missing angle bracket or brace in literal ms\uptable.asm(9) : error A2008:syntax error : loc0 ms\uptable.asm(10) : error A2008:syntax error : . ms\uptable.asm(11) : error A2008:syntax error ms\uptable.asm(12) : error A2044:invalid character in file ms\uptable.asm(13) : error A2008:syntax error : . ms\uptable.asm(14) : error A2045:missing angle bracket or brace in literal ms\uptable.asm(15) : error A2045:missing angle bracket or brace in literal ms\uptable.asm(16) : error A2045:missing angle bracket or brace in literal ms\uptable.asm(17) : error A2044:invalid character in file ms\uptable.asm(18) : error A2045:missing angle bracket or brace in literal ms\uptable.asm(19) : error A2045:missing angle bracket or brace in literal ... ms\uptable.asm(104) : error A2045:missing angle bracket or brace in literal ms\uptable.asm(105) : error A2044:invalid character in file ms\uptable.asm(106) : fatal error A1012:error count exceeds 100; stopping assembly NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN\ml.EXE' : r eturn code '0x1' Stop. I configured for no assembler code but nmake is attempting to assemble this code. How can I gert around this error and complete the build? Appreciate any help you can give. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Patch to mitigate CVE-2014-3566 (POODLE)
Here's a patch for the OpenSSL 1.0.1 branch that adds support for
TLS_FALLBACK_SCSV, which can be used to counter the POODLE attack
(CVE-2014-3566; https://www.openssl.org/~bodo/ssl-poodle.pdf).
Note well that this is not about a bug in OpenSSL -- it's a protocol issue.
If SSL 3.0 is disabled in either the client or in the server, that is
completely sufficient to avoid the POODLE attack. (Also, there's only a
vulnerability if the client actively falls back to SSL 3.0 in case that TLS
connections don't work -- but many browsers still do that to ensure
interoperability with broken legacy servers.) If you can't yet disable SSL
3.0 entirely, TLS_FALLBACK_SCSV can help avoid the attack, if both the
client and the server support it.
Server-side TLS_FALLBACK_SCSV support is automatically provided if you use
the patch. Clients that do fallback connections downgrading the protocol
version should use SSL_set_mode(ssl, SSL_MODE_SEND_FALLBACK_SCSV) for such
downgraded connections.
The OpenSSL team will follow up with official releases that will include
TLS_FALLBACK_SCSV support. Meanwhile, if you can't simply disable SSL 3.0,
you may want to use this patch.
Bodo
diff --git a/apps/s_client.c b/apps/s_client.c
index 4625467..c2e160c 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -337,6 +337,7 @@ static void sc_usage(void)
BIO_printf(bio_err, -tls1_1 - just use TLSv1.1\n);
BIO_printf(bio_err, -tls1 - just use TLSv1\n);
BIO_printf(bio_err, -dtls1- just use DTLSv1\n);
+ BIO_printf(bio_err, -fallback_scsv - send TLS_FALLBACK_SCSV\n);
BIO_printf(bio_err, -mtu - set the link layer MTU\n);
BIO_printf(bio_err, -no_tls1_2/-no_tls1_1/-no_tls1/-no_ssl3/-no_ssl2 -
turn off that protocol\n);
BIO_printf(bio_err, -bugs - Switch on all SSL implementation
bug workarounds\n);
@@ -617,6 +618,7 @@ int MAIN(int argc, char **argv)
char *sess_out = NULL;
struct sockaddr peer;
int peerlen = sizeof(peer);
+ int fallback_scsv = 0;
int enable_timeouts = 0 ;
long socket_mtu = 0;
#ifndef OPENSSL_NO_JPAKE
@@ -823,6 +825,10 @@ int MAIN(int argc, char **argv)
meth=DTLSv1_client_method();
socket_type=SOCK_DGRAM;
}
+ else if (strcmp(*argv,-fallback_scsv) == 0)
+ {
+ fallback_scsv = 1;
+ }
else if (strcmp(*argv,-timeout) == 0)
enable_timeouts=1;
else if (strcmp(*argv,-mtu) == 0)
@@ -1235,6 +1241,10 @@ bad:
SSL_set_session(con, sess);
SSL_SESSION_free(sess);
}
+
+ if (fallback_scsv)
+ SSL_set_mode(con, SSL_MODE_SEND_FALLBACK_SCSV);
+
#ifndef OPENSSL_NO_TLSEXT
if (servername != NULL)
{
diff --git a/crypto/err/openssl.ec b/crypto/err/openssl.ec
index e0554b4..34754e5 100644
--- a/crypto/err/openssl.ec
+++ b/crypto/err/openssl.ec
@@ -71,6 +71,7 @@ R SSL_R_TLSV1_ALERT_EXPORT_RESTRICTION1060
R SSL_R_TLSV1_ALERT_PROTOCOL_VERSION 1070
R SSL_R_TLSV1_ALERT_INSUFFICIENT_SECURITY 1071
R SSL_R_TLSV1_ALERT_INTERNAL_ERROR 1080
+R SSL_R_SSLV3_ALERT_INAPPROPRIATE_FALLBACK 1086
R SSL_R_TLSV1_ALERT_USER_CANCELLED 1090
R SSL_R_TLSV1_ALERT_NO_RENEGOTIATION 1100
R SSL_R_TLSV1_UNSUPPORTED_EXTENSION1110
diff --git a/ssl/d1_lib.c b/ssl/d1_lib.c
index 6bde16f..82ca653 100644
--- a/ssl/d1_lib.c
+++ b/ssl/d1_lib.c
@@ -266,6 +266,16 @@ long dtls1_ctrl(SSL *s, int cmd, long larg, void *parg)
case DTLS_CTRL_LISTEN:
ret = dtls1_listen(s, parg);
break;
+ case SSL_CTRL_CHECK_PROTO_VERSION:
+ /* For library-internal use; checks that the current protocol
+* is the highest enabled version (according to s-ctx-method,
+* as version negotiation may have changed s-method). */
+#if DTLS_MAX_VERSION != DTLS1_VERSION
+# error Code needs update for DTLS_method() support beyond DTLS1_VERSION.
+#endif
+ /* Just one protocol version is supported so far;
+* fail closed if the version is not as expected. */
+ return s-version == DTLS_MAX_VERSION;
default:
ret = ssl3_ctrl(s, cmd, larg, parg);
diff --git a/ssl/dtls1.h b/ssl/dtls1.h
index e65d501..192c5de 100644
--- a/ssl/dtls1.h
+++ b/ssl/dtls1.h
@@ -84,6 +84,8 @@ extern C {
#endif
#define DTLS1_VERSION 0xFEFF
+#define DTLS_MAX_VERSION DTLS1_VERSION
+
#define DTLS1_BAD_VER 0x0100
#if 0
@@ -284,4 +286,3 @@ typedef struct dtls1_record_data_st
}
#endif
#endif
-
diff --git a/ssl/s23_clnt.c b/ssl/s23_clnt.c
index 2b93c63..d4e43c3 100644
--- a/ssl/s23_clnt.c
+++ b/ssl/s23_clnt.c
@@ -736,6 +736,9 @@ static
Re: Patch to mitigate CVE-2014-3566 (POODLE)
On Wed, Oct 15, 2014 at 01:46:40AM +0200, Bodo Moeller wrote: Here's a patch for the OpenSSL 1.0.1 branch that adds support for TLS_FALLBACK_SCSV, which can be used to counter the POODLE attack (CVE-2014-3566; https://www.openssl.org/~bodo/ssl-poodle.pdf). Hi Bodo. Many thanks for the OOB patch that I just saw commited to git. Any reason for the s_client -fallback_scsv option check to be within an #ifndef OPENSSL_NO_DTLS1 block? Thanks. --mancha pgpQP0dloJSeZ.pgp Description: PGP signature
