Issue when OpenSSL 0.9.8zc built with -DOPENSSL_NO_SSL2 -DOPENSSL_NO_SSL3
Hi, We are building OpenSSL 0.9.8zc with options -DOPENSSL_NO_SSL2 -DOPENSSL_NO_SSL3 on a FreeBSD based OS. This is one of the ways we are trying to mitigate CVE-2014-3566 POODLE issue in our OS. We are not able to use following commands after building the library with above mentioned flags. openssl s_client [argument list] openssl s_server [argument list] openssl ciphers [argument list] openssl s_time [argument list] Issue is mostly because of following condition in header file openssl/apps/progs.h #if !defined(OPENSSL_NO_SOCK) !(defined(OPENSSL_NO_SSL2) defined(OPENSSL_NO_SSL3)) --Allow s_client, s_server ciphers, s_time Is this the expected behavior ? If not, could you please suggest fix for the issue. Regards, Nimesh
Re: [openssl.org #3585] [PATCH] OPENSSL_NO_SSL3 doesn't remove all SSLv3 bits
On Thursday 30 October 2014 23:26:15 Alin Năstac via RT wrote: Some SSLv3 parts (e.g. SSLv3 ciphers) SSLv3 ciphers can be used with any version of TLS from TLSv1.0 to TLSv1.2 if you remove ciphers that are marked as SSLv3, you actually remove all ciphers that can be used with TLSv1.0 and TLSv1.1, as such, the only protocol version that will continue to work is TLSv1.2 I'm quite sure that's not the expected behaviour of no-ssl3 flag -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Fwd: Query Regarding defining MTU for DTLS Packet
Hi All,
I am Trying to limit the packet size for DTLS messages. By
using ssl_set_mtu() I am able to define max size for particular record.
But in the above Handshake OPENSSL combines multiple records and sends
out in a single UDP Packet.Is there a way we can configure
OPENSSL such that it splits out each record into a separate UDP Packet
in case combination of DTLS record exceeds a given MTU?
*Sample DTLS Handshake: *
Client Server
ClientHello + use_srtp
ServerHello + use_srtp
Certificate*
ServerKeyExchange*
CertificateRequest*
ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished
[ChangeCipherSpec]
Finished
SRTP packets --- SRTP packets
*Example*: Suppose my MTU is 1500 bytes
*Current **Behavior*
ServerHello +
use_srtp(100 bytes)
Certificate*(1400 bytes)
ServerKeyExchange*(50 bytes)
CertificateRequest*(50 bytes)
ServerHelloDone(50 bytes)
*Expected **Behavior*
ServerHello + use_srtp(100 bytes)
Certificate*(1400 bytes)
(Since we reached MTU
OPENSSL must split records into 2 UDP packets)
ServerKeyExchange*(50 bytes)
CertificateRequest*(50 bytes)
ServerHelloDone(50 bytes)
Thanks
Satya
RE: Query Regarding defining MTU for DTLS Packet
Which downstream BIO do you use? (SSL_set_bio)
Try to set ssl-d1-mtu directly, and override the downstream BIO's ctrl
function:
BIO_CTRL_DGRAM_QUERY_MTU - return the starting MTU
BIO_CTRL_DGRAM_GET_FALLBACK_MTU - return some value smaller than the current
MTU.
From: owner-openssl-...@openssl.org [owner-openssl-...@openssl.org] on behalf
of T@Run..! Polisetty [tarunpolise...@gmail.com]
Sent: Friday, October 31, 2014 13:01
To: openssl-dev@openssl.org
Subject: Fwd: Query Regarding defining MTU for DTLS Packet
Hi All,
I am Trying to limit the packet size for DTLS messages. By using ssl_set_mtu()
I am able to define max size for particular record.
But in the above Handshake OPENSSL combines multiple records and sends out in a
single UDP Packet.Is there a way we can configure
OPENSSL such that it splits out each record into a separate UDP Packet in case
combination of DTLS record exceeds a given MTU?
Sample DTLS Handshake:
Client Server
ClientHello + use_srtp
ServerHello + use_srtp
Certificate*
ServerKeyExchange*
CertificateRequest*
ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished
[ChangeCipherSpec]
Finished
SRTP packets --- SRTP packets
Example: Suppose my MTU is 1500 bytes
Current Behavior
ServerHello + use_srtp(100
bytes)
Certificate*(1400 bytes)
ServerKeyExchange*(50 bytes)
CertificateRequest*(50 bytes)
ServerHelloDone(50 bytes)
Expected Behavior
ServerHello + use_srtp(100 bytes)
Certificate*(1400 bytes)
(Since we reached MTU OPENSSL
must split records into 2 UDP packets)
ServerKeyExchange*(50 bytes)
CertificateRequest*(50 bytes)
ServerHelloDone(50 bytes)
Thanks
Satya
This email and any files transmitted with it are confidential material. They
are intended solely for the use of the designated individual or entity to whom
they are addressed. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, use, distribution or
copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender
and delete or destroy any copy of this message
Re: Query Regarding defining MTU for DTLS Packet
Hai All,
We are Using Memory BIO. We will Try this out and get back to you.
Regards
Satya
On Fri, Oct 31, 2014 at 4:48 PM, Yair Elharrar yair.elhar...@audiocodes.com
wrote:
Which downstream BIO do you use? (SSL_set_bio)
Try to set ssl-d1-mtu directly, and override the downstream BIO's ctrl
function:
BIO_CTRL_DGRAM_QUERY_MTU - return the starting MTU
BIO_CTRL_DGRAM_GET_FALLBACK_MTU - return some value smaller than the
current MTU.
--
*From:* owner-openssl-...@openssl.org [owner-openssl-...@openssl.org] on
behalf of T@Run..! Polisetty [tarunpolise...@gmail.com]
*Sent:* Friday, October 31, 2014 13:01
*To:* openssl-dev@openssl.org
*Subject:* Fwd: Query Regarding defining MTU for DTLS Packet
Hi All,
I am Trying to limit the packet size for DTLS messages. By
using ssl_set_mtu() I am able to define max size for particular record.
But in the above Handshake OPENSSL combines multiple records and sends out in
a single UDP Packet.Is there a way we can configure
OPENSSL such that it splits out each record into a separate UDP Packet in
case combination of DTLS record exceeds a given MTU?
*Sample DTLS Handshake: *
Client Server
ClientHello + use_srtp
ServerHello + use_srtp
Certificate*
ServerKeyExchange*
CertificateRequest*
ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished
[ChangeCipherSpec]
Finished
SRTP packets --- SRTP packets
*Example*: Suppose my MTU is 1500 bytes
*Current **Behavior*
ServerHello + use_srtp(100
bytes)
Certificate*(1400
bytes)
ServerKeyExchange*(50 bytes)
CertificateRequest*(50 bytes)
ServerHelloDone(50 bytes)
*Expected **Behavior*
ServerHello + use_srtp(100 bytes)
Certificate*(1400
bytes)
(Since we reached MTU OPENSSL
must split records into 2 UDP packets)
ServerKeyExchange*(50 bytes)
CertificateRequest*(50 bytes)
ServerHelloDone(50 bytes)
Thanks
Satya
--
This email and any files transmitted with it are confidential material.
They are intended solely for the use of the designated individual or entity
to whom they are addressed. If the reader of this message is not the
intended recipient, you are hereby notified that any dissemination, use,
distribution or copying of this communication is strictly prohibited and
may be unlawful.
If you have received this email in error please immediately notify the
sender and delete or destroy any copy of this message
Re: [openssl.org #3585] [PATCH] OPENSSL_NO_SSL3 doesn't remove all SSLv3 bits
That's odd, because I used a similar patch on an older openssl version (one that doesn't know TLSv1.1 or TLSv1.2) on which I disabled support on both SSLv2/SSLv3 and I was still able to use SSL clients and servers linked with openssl library I built. On Fri, Oct 31, 2014 at 11:45 AM, Hubert Kario via RT r...@openssl.org wrote: On Thursday 30 October 2014 23:26:15 Alin Năstac via RT wrote: Some SSLv3 parts (e.g. SSLv3 ciphers) SSLv3 ciphers can be used with any version of TLS from TLSv1.0 to TLSv1.2 if you remove ciphers that are marked as SSLv3, you actually remove all ciphers that can be used with TLSv1.0 and TLSv1.1, as such, the only protocol version that will continue to work is TLSv1.2 I'm quite sure that's not the expected behaviour of no-ssl3 flag -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [Fwd: Inconsistency in ARM support]
Personally, I think there are few cases where Thumb2 makes sense, and
I would be perfectly happy for all the ARM .asm code to assemble to
ARM code only. What I do think is that we could refine the logic
around interworking returns based on those #defines instead of on the
ARCH, i.e., when lr is on the stack, we could do sth like
#if !defined(__thumb__) || defined(__thumb2__)
/* we are not being called by thumb-1 code */
ldmia sp!, {..., pc}
#else
/* do interworking return compatible with ARMv4T */
ldmia sp!, {..., lr}
bx lr
#endif
Note that this only works if the .asm function are only called
internally, but I think that is the case.
Correct, it's possible to simplify interworking return logic. If we make
certain assumptions. And it's arguably safe to make these assumptions,
because code is distributed in source form and if integrated to another
project, it will share compiler flags with the rest of the project. I
mean current interworking approach implies most rigid circumstances up
to distributing in binary form, but it's not really interesting to
anybody. However, I'd like to handle this later as separate commit,
separate from one that will address the inconsistency in ARM support we
are talking about. As for simplified logic I plan to extent current #if
and settle for
#if __ARM_ARCH__=5 || !defined(__thumb__)
ldmia sp!,{...,pc}
#else
ldmia sp!,{...,lr}
bx lr
#endif
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [Fwd: Inconsistency in ARM support]
Anyway. As nobody seems to be objecting, it sounds like we are going for
combination of both alternatives? I.e. those who specify specific -march
lower than armv7 would be excused from capability detection and run-time
switch, and those who additionally specify better -Wa and
corresponding -D, would be able to build universal binaries of their
liking. I'll give it some extra time for others to ponder and make a
suggestion. It would be easier to discuss details then.
Attached is suggestion on how to implement this. [I thought it would
take more tweaking]. I scrapped -Wa, as -D__ARM_MAX_ARCH__=N was
sufficient. Most of what needs to be said is said in commentary in
./Configure (see beginning of patch). But this is most. There are
couple of controversial points that are likely to need clarification.
The reason for why I didn't add '.arch armv7-a' in all #if
__ARM_MAX_ARCH=7 sections is because '.fpu neon' appears to be
sufficient to compile the code, while *not* having '.arch armv7-a'
(where possible) would allow to catch attempts to use new instructions
in places where it's inappropriate when building universal. Second
controversial point is that ARMv8 crypto is compiled even with
__ARM_MAX_ARCH__=7. This is done so to say to popularize ARMv8 crypto
among those who won't read commentary section in Configure, as well as
among Android [and in future iOS] people. [Well, -D__ARM_MAX_ARCH__=8
would work there too, but there are even more likely to miss the memo].
diff --git a/Configure b/Configure
index 2eda5e6..a080616 100755
--- a/Configure
+++ b/Configure
@@ -352,8 +352,34 @@ my %table=(
# throw in -D[BL]_ENDIAN, whichever appropriate...
linux-generic32,gcc:-DTERMIO -O3 -fomit-frame-pointer -Wall::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
linux-ppc, gcc:-DB_ENDIAN -DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_RISC1 DES_UNROLL:${ppc32_asm}:linux32:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
-# It's believed that majority of ARM toolchains predefine appropriate -march.
-# If you compiler does not, do complement config command line with one!
+
+###
+# Note that -march is not among compiler options in below linux-armv4
+# target line. Not specifying one is intentional to give you choice to:
+#
+# a) rely on your compiler default by not specifying one;
+# b) specify your target platform explicitly for optimal performance,
+#e.g. -march=armv6 or -march=armv7-a;
+# c) build universal binary that targets *range* of platforms by
+#specifying minimum and maximum supported architecture;
+#
+# As for c) option. It actually makes no sense to specify maximum to be
+# less than ARMv7, because it's the least requirement for run-time
+# switch between platform-specific code paths. And without run-time
+# switch performance would be equivalent to one for minimum. Secondly,
+# there are some natural limitations that you'd have to accept and
+# respect. Most notably you can *not* build universal binary for
+# big-endian platform. This is because ARMv7 processor always picks
+# instructions in little-endian order. Another similar limitation is
+# that -mthumb can't cross -march=armv6t2 boundary, because that's
+# where it became Thumb-2. Well, this limitation is a bit artificial,
+# becuase it's not really impossible, but it's deemed too tricky to
+# support. And of course you have to be sure that your binutils are
+# actually up to the task handling maximum target platform. With all
+# this in mind here is an example of how to configure universal build:
+#
+# ./Configure linux-armv4 -march=armv6 -D__ARM_MAX_ARCH__=8
+#
linux-armv4, gcc:-DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${armv4_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
linux-aarch64,gcc:-DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${aarch64_asm}:linux64:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
# Configure script adds minimally required -march for assembly support,
diff --git a/crypto/aes/asm/aesv8-armx.pl b/crypto/aes/asm/aesv8-armx.pl
index 923c7f6..12ab307 100755
--- a/crypto/aes/asm/aesv8-armx.pl
+++ b/crypto/aes/asm/aesv8-armx.pl
@@ -35,7 +35,7 @@ $prefix=aes_v8;
$code=___;
#include arm_arch.h
-#if __ARM_ARCH__=7
+#if __ARM_MAX_ARCH__=7
.text
___
$code.=.arch armv8-a+crypto\n if ($flavour =~ /64/);
diff --git a/crypto/aes/asm/bsaes-armv7.pl b/crypto/aes/asm/bsaes-armv7.pl
index f3d96d9..6671e86 100644
--- a/crypto/aes/asm/bsaes-armv7.pl
+++ b/crypto/aes/asm/bsaes-armv7.pl
@@ -702,13 +702,14 @@ $code.=___;
# define BSAES_ASM_EXTENDED_KEY
# define XTS_CHAIN_TWEAK
# define __ARM_ARCH__ __LINUX_ARM_ARCH__
+# define __ARM_MAX_ARCH__ __LINUX_ARM_ARCH__
#endif
Re: [openssl.org #3585] [PATCH] OPENSSL_NO_SSL3 doesn't remove all SSLv3 bits
On Thu, Oct 30, 2014 at 11:26:15PM +0100, Alin Nastac via RT wrote: Some SSLv3 parts (e.g. SSLv3 ciphers) are built in even if ssl3 support is disabled. SSLv3 ciphers are not specific to SSLv3, they can also be used in TLS. no-ssl3 doesn't disable the SSL3 methods. That is, you can still call SSLv3_client_method() and set up an SSLv3 connection with that. It assumes that if you say that you want an SSLv3 connection that that is really what you want. There is work being done to have an option to also disable that, that looks very similar to your patch but then with a new configure option. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3585] [PATCH] OPENSSL_NO_SSL3 doesn't remove all SSLv3 bits
That's odd, because I used a similar patch on an older openssl version (one that doesn't know TLSv1.1 or TLSv1.2) on which I disabled support on both SSLv2/SSLv3 and I was still able to use SSL clients and servers linked with openssl library I built. On Fri, Oct 31, 2014 at 11:45 AM, Hubert Kario via RT r...@openssl.org wrote: On Thursday 30 October 2014 23:26:15 Alin Năstac via RT wrote: Some SSLv3 parts (e.g. SSLv3 ciphers) SSLv3 ciphers can be used with any version of TLS from TLSv1.0 to TLSv1.2 if you remove ciphers that are marked as SSLv3, you actually remove all ciphers that can be used with TLSv1.0 and TLSv1.1, as such, the only protocol version that will continue to work is TLSv1.2 I'm quite sure that's not the expected behaviour of no-ssl3 flag -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3588] obsolete comment for SSL_set_accept_state and SSL_set_connect_state
This post is really a minor detail, but - given code is not largely documented - i would expect comments even minor to be accurate. in ssl_lib.c line 2829 i read : /* For the next 2 functions, SSL_clear() sets shutdown and so * one of these calls will reset it */ functions are : void SSL_set_accept_state(SSL *s) and void SSL_set_connect_state(SSL *s) I think comment can be removed or should be reviewed since looking in code s-shutdown is actualy cleared correctly by SSL_clear(), so if it should be reset to 0 it is not due to SSL_clear(). neither void ssl2_clear(SSL *s) void ssl3_clear(SSL *s) void tls1_clear(SSL *s) void dtls1_clear(SSL *s) seems to modify shutdown field either. And looking in git, this is not new : commit 413c4f45 that resets it to 0 in SSL_clear() is 1999-02-16 10:22:21. So this comment is really obsolete, outdated and misleading. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3566] openssl-1.0.1j make depend failes
Hi, About make check. It seems that no-ssl3 disables ssl2 in openssl library automatically, but dose not in test. Specifying not only no-ssl3 but also no-ssl2, make check passes. Regards, --- Kiyoshi yoi_no_myou...@yahoo.co.jp - Original Message - From: Kiyoshi KANAZAWA yoi_no_myou...@yahoo.co.jp To: r...@openssl.org r...@openssl.org Cc: openssl-dev@openssl.org openssl-dev@openssl.org Date: 2014/10/17, Fri 00:32 Subject: Re: [openssl.org #3566] openssl-1.0.1j make depend failes Hello, Yes, I can make without make depend, but make check fails with Failed AES256-GCM-SHA384, if I specify no-ssl3. Without no-ssl3, make check passes. I tried 4 patterns of Configure parameters, and got the same result. - solaris-x86-cc threads shared zlib no-ssl3 - solaris64-x86_64-cc threads shared zlib no-ssl3 (cc is solarisstudio12.3/bin/cc) - solaris-x86-gcc threads shared zlib no-ssl3 - solaris64-x86_64-gcc threads shared zlib no-ssl3 (gcc version 4.8.3) Regards, --- Kiyoshi yoi_no_myou...@yahoo.co.jp - Original Message - From: Stephen Henson via RT r...@openssl.org To: yoi_no_myou...@yahoo.co.jp Cc: openssl-dev@openssl.org Date: 2014/10/16, Thu 21:50 Subject: [openssl.org #3566] openssl-1.0.1j make depend failes On Thu Oct 16 14:22:19 2014, yoi_no_myou...@yahoo.co.jp wrote: Hello, I'd like to build openssl-1.0.1j with no-ssl3, but can not. ./Configure --prefix=/opt/local/openssl solaris-x86-cc threads shared zlib no-ssl3 Got message: --- from here, message --- Since you've disabled or enabled at least one algorithm, you need to do the following before building: make depend Configured for solaris-x86-cc. --- till here, message --- Obviously this needs fixing but as a workaround: if you're building from scratch (or after make clean) it should compile fine with without doing make depend. 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
