date:20160303

Re: [openssl-dev] [PATCH] Do not offer options like -ssl2, -tls1, -dtls if they are not compiled in

2016-03-03 Thread Viktor Dukhovni


> On Mar 3, 2016, at 8:07 PM, Ángel González  wrote:
> 
> They were showed in the help, but providing them failed with an
> “unknown option” error, and showed the help which listed it
> as a valid option.

The patch is not right.  For example, when TLSv1 is disabled, it is
not the case that TLSv1.1 and TLSv1.2 are disabled.  Secondly disabled
features should report that the feature is disabled, not a bad usage
message, as would be the case with a mistyped option.

> Patch against the stable 1.0.2 branch.
> 
>  apps/s_client.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/apps/s_client.c b/apps/s_client.c
> index 0c1102b..f68c581 100644
> --- a/apps/s_client.c
> +++ b/apps/s_client.c
> @@ -376,16 +376,22 @@ static void sc_usage(void)
> " -srp_strength int - minimal length in bits for N
> (default %d).\n",
> SRP_MINIMAL_N);
>  #endif
> +#ifndef OPENSSL_NO_SSL2
>  BIO_printf(bio_err, " -ssl2 - just use SSLv2\n");
> +#endif
>  #ifndef OPENSSL_NO_SSL3_METHOD
>  BIO_printf(bio_err, " -ssl3 - just use SSLv3\n");
>  #endif
> +#ifndef OPENSSL_NO_TLS1
>  BIO_printf(bio_err, " -tls1_2   - just use TLSv1.2\n");
>  BIO_printf(bio_err, " -tls1_1   - just use TLSv1.1\n");
>  BIO_printf(bio_err, " -tls1 - just use TLSv1\n");
> +#endif
> +#ifndef OPENSSL_NO_DTLS1
>  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");
> +#endif
> +BIO_printf(bio_err, " -fallback_scsv - send TLS_FALLBACK_SCSV\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,
> -- 
> 2.7.2
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-- 
Viktor.

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [PATCH] Do not offer options like -ssl2, -tls1, -dtls if they are not compiled in

2016-03-03 Thread Ángel González

They were showed in the help, but providing them failed with an
“unknown option” error, and showed the help which listed it
as a valid option.

---

Patch against the stable 1.0.2 branch.

 apps/s_client.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/apps/s_client.c b/apps/s_client.c
index 0c1102b..f68c581 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -376,16 +376,22 @@ static void sc_usage(void)
" -srp_strength int - minimal length in bits for N
(default %d).\n",
SRP_MINIMAL_N);
 #endif
+#ifndef OPENSSL_NO_SSL2
 BIO_printf(bio_err, " -ssl2 - just use SSLv2\n");
+#endif
 #ifndef OPENSSL_NO_SSL3_METHOD
 BIO_printf(bio_err, " -ssl3 - just use SSLv3\n");
 #endif
+#ifndef OPENSSL_NO_TLS1
 BIO_printf(bio_err, " -tls1_2   - just use TLSv1.2\n");
 BIO_printf(bio_err, " -tls1_1   - just use TLSv1.1\n");
 BIO_printf(bio_err, " -tls1 - just use TLSv1\n");
+#endif
+#ifndef OPENSSL_NO_DTLS1
 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");
+#endif
+BIO_printf(bio_err, " -fallback_scsv - send TLS_FALLBACK_SCSV\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,
-- 
2.7.2
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4375] [PATCH] Missing Sanity Checks for OPENSSL_malloc() in OpenSSL-1.0.2g

2016-03-03 Thread Bill Parker via RT

Hello All,

In reviewing code in OpenSSL-1.0.2g, in directory 'ssl', file
'ssl_ciph.c', in function ''SSL_COMP_add_compression_method()'',
there is a call to OPENSSL_malloc() which is not checked for a
return value of NULL, indicating failure.

The patch file below should address/correct this issue:

--- ssl_ciph.c.orig 2016-03-02 17:39:01.677826126 -0800
+++ ssl_ciph.c  2016-03-02 17:40:51.942840242 -0800
@@ -1996,6 +1996,8 @@

 MemCheck_off();
 comp = (SSL_COMP *)OPENSSL_malloc(sizeof(SSL_COMP));
+if (comp == NULL)
+   return 1;
 comp->id = id;
 comp->method = cm;
 load_builtin_compressions();

===

Hello All,

In reviewing code in OpenSSL-1.0.2g, in directory 'crypto/bio', file
'bss_rtcp.c', in function 'rtcp_new()', there is a call to
OPENSSL_malloc() which is not checked for a return value of NULL,
indicating failure.

The patch file below should address/correct this issue:

--- bss_rtcp.c.orig 2016-03-02 15:25:08.307826108 -0800
+++ bss_rtcp.c  2016-03-02 15:25:47.326785217 -0800
@@ -170,6 +170,8 @@
 bi->num = 0;
 bi->flags = 0;
 bi->ptr = OPENSSL_malloc(sizeof(struct rpc_ctx));
+if (bi->ptr == NULL)
+   return (0);
 ctx = (struct rpc_ctx *)bi->ptr;
 ctx->filled = 0;
 ctx->pos = 0;

===

Hello All,

In reviewing code in OpenSSL-1.0.2g, in directory 'apps', file
'apps.c', in function 'args_from_file()', there is a call to
OPENSSL_malloc() which is not checked for a return value of NULL,
indicating failure.

The patch file below should address/correct this issue:

--- apps.c.orig 2016-03-02 15:27:24.293109138 -0800
+++ apps.c  2016-03-02 15:27:48.108135906 -0800
@@ -215,7 +215,8 @@
 if (arg != NULL)
 OPENSSL_free(arg);
 arg = (char **)OPENSSL_malloc(sizeof(char *) * (i * 2));
-
+if (arg == NULL)
+   return (0);
 *argv = arg;
 num = 0;
 p = buf;

===

Hello All,

In reviewing code in OpenSSL-1.0.2g, in directory 'crypto/x509', file
'by_dir.c', in function 'get_cert_by_subject()', there is a call to
OPENSSL_malloc() which is not checked for a return value of NULL,
indicating failure.

The patch file below should address/correct this issue:

--- by_dir.c.orig   2016-03-02 15:29:32.361385958 -0800
+++ by_dir.c2016-03-02 15:30:04.762503973 -0800
@@ -401,6 +401,10 @@
 }
 if (!hent) {
 hent = OPENSSL_malloc(sizeof(BY_DIR_HASH));
+   if (hent == NULL) {
+   X509err(X509_F_GET_CERT_BY_SUBJECT,
ERR_R_MALLOC_FAILURE);
+   goto finish;
+   }
 hent->hash = h;
 hent->suffix = k;
 if (!sk_BY_DIR_HASH_push(ent->hashes, hent)) {

===

Hello All,

In reviewing code in OpenSSL-1.0.2g, in directory 'engines', file
'e_capi.c', in function 'capi_get_provname()', there is a call to
OPENSSL_malloc() or alloca() which is not checked for a return value
of NULL, indicating failure.

In function 'capi_cert_get_fname()', there is a call to OPENSSL_malloc()
which is not checked for a return value of NULL, indicating failure.

In function '*capi_get_key()', there is a call to OPENSSL_malloc()
which is not checked for a return value of NULL, indicating failure.

The patch file below should address/correct this issue:

--- e_capi.c.orig   2016-03-02 15:31:15.011432251 -0800
+++ e_capi.c2016-03-02 15:35:24.264110984 -0800
@@ -1106,6 +1106,10 @@
 name = alloca(len);
 else
 name = OPENSSL_malloc(len);
+if (name == NULL) {
+   CAPIerr(CAPI_F_CAPI_GET_PROVNAME, ERR_R_MALLOC_FAILURE);
+   return 0;
+}
 if (!CryptEnumProviders(idx, NULL, 0, ptype, name, )) {
 err = GetLastError();
 if (err == ERROR_NO_MORE_ITEMS)
@@ -1286,6 +1290,10 @@
 (cert, CERT_FRIENDLY_NAME_PROP_ID, NULL, ))
 return NULL;
 wfname = OPENSSL_malloc(dlen);
+if (wfname == NULL) {
+   CAPIerr(CAPI_F_CAPI_CERT_GET_FNAME, ERR_R_MALLOC_FAILURE);
+   return NULL;
+}
 if (CertGetCertificateContextProperty
 (cert, CERT_FRIENDLY_NAME_PROP_ID, wfname, )) {
 char *fname = wide_to_asc(wfname);
@@ -1436,6 +1444,11 @@
 CAPI_KEY *key;
 DWORD dwFlags = 0;
 key = OPENSSL_malloc(sizeof(CAPI_KEY));
+if (key == NULL) {
+   CAPIerr(CAPI_F_CAPI_GET_KEY, ERR_R_MALLOC_FAILURE);
+   capi_addlasterror();
+   goto err;
+}
 if (sizeof(TCHAR) == sizeof(char))
 CAPI_trace(ctx, "capi_get_key, contname=%s, provname=%s,
type=%d\n",
contname, provname, ptype);
===

Hello All,

In reviewing code in OpenSSL-1.0.2g, in directory

[openssl-dev] [openssl.org #4374] [PATCH] Potential for NULL pointer dereferences in OpenSSL-1.0.2g (CWE-476)

2016-03-03 Thread Bill Parker via RT

Hello All,

In reviewing source code in directory 'openssl-1.0.2g/crypto/evp',
in file 'openbsd_hw.c', there are a few instances where OPENSSL_malloc()
is called, but immediately afterwards a call to memcpy() is made with
the return value from the call to OPENSSL_malloc(), but no check for
a return value of NULL is made after OPENSSL_malloc() returns.

However, if the 1st argument to memcpy() is NULL, a segmentation fault/
violation will occur.  The patch file below should address/correct this
issue:

--- openbsd_hw.c.orig   2016-03-02 15:36:57.236927351 -0800
+++ openbsd_hw.c2016-03-02 15:40:29.525908189 -0800
@@ -133,6 +133,10 @@
 return 0;

 CDATA(ctx)->key = OPENSSL_malloc(MAX_HW_KEY);
+if (CDATA(ctx)->key == NULL {
+   err("CDATA(ctx)->key memory allocation failed");
+   return 0;
+}

 assert(ctx->cipher->iv_len <= MAX_HW_IV);

@@ -186,6 +190,11 @@

 if (((unsigned long)in & 3) || cinl != inl) {
 cin = OPENSSL_malloc(cinl);
+   if (cin == NULL) {
+   err("cin - memory allocation failed");
+   abort();
+   return 0;
+   }
 memcpy(cin, in, inl);
 cryp.src = cin;
 }
@@ -334,6 +343,11 @@
 char *dcopy;

 dcopy = OPENSSL_malloc(len);
+   if (dcopy == NULL) {
+   err("dcopy - memory allocation failed");
+   abort();
+   return 0;
+   }
 memcpy(dcopy, data, len);
 cryp.src = dcopy;
 cryp.dst = cryp.src; // FIXME!!!
@@ -397,6 +411,10 @@
 assert(from->digest->flags & EVP_MD_FLAG_ONESHOT);

 to_md->data = OPENSSL_malloc(from_md->len);
+if (to_md->data == NULL) {
+   err("DEV_CRYPTO_MD5_COPY: unable to allocate memory");
+   return 0;
+}
 memcpy(to_md->data, from_md->data, from_md->len);

 return 1;

===

Hello All,

In reviewing source code in directory 'engines/ccgost', in file
'gost_ameth.c', there are a few instances where OPENSSL_malloc()
is called, but no check for a return value of NULL is made.  However,
immediately afterwards statments which access the allocated memory
are used (array access/memset(), etc) which will result in a segmentation
fault/violation occuring if NULL is returned from the OPENSSL_malloc()
call.

The patch file below should address/correct this issue:

--- gost_ameth.c.orig   2016-03-02 16:43:36.014151374 -0800
+++ gost_ameth.c2016-03-02 16:45:59.978448496 -0800
@@ -617,6 +617,10 @@
 return 0;
 }
 databuf = OPENSSL_malloc(octet->length);
+if (!databuf) {
+   GOSTerr(GOST_F_PUB_DECODE_GOST94, ERR_R_MALLOC_FAILURE);
+   return 0;
+}
 for (i = 0, j = octet->length - 1; i < octet->length; i++, j--) {
 databuf[j] = octet->data[i];
 }
@@ -646,6 +650,8 @@
 }
 data_len = BN_num_bytes(dsa->pub_key);
 databuf = OPENSSL_malloc(data_len);
+if (!databuf)
+   return 0;
 BN_bn2bin(dsa->pub_key, databuf);
 octet = ASN1_OCTET_STRING_new();
 ASN1_STRING_set(octet, NULL, data_len);
@@ -686,6 +692,10 @@
 return 0;
 }
 databuf = OPENSSL_malloc(octet->length);
+if (!databuf) {
+   GOSTerr(GOST_F_PUB_DECODE_GOST01, ERR_R_MALLOC_FAILURE);
+   return 0;
+}
 for (i = 0, j = octet->length - 1; i < octet->length; i++, j--) {
 databuf[j] = octet->data[i];
 }
@@ -760,6 +770,10 @@
 data_len = 2 * BN_num_bytes(order);
 BN_free(order);
 databuf = OPENSSL_malloc(data_len);
+if (!databuf) {
+   GOSTerr(GOST_F_PUB_DECODE_GOST01, ERR_R_MALLOC_FAILURE);
+   return 0;
+}
 memset(databuf, 0, data_len);

 store_bignum(X, databuf + data_len / 2, data_len / 2);

===

Hello All,

In reviewing source code in directory 'engines/ccgost', in file
'gost_pmeth.c', there are a few instances where OPENSSL_malloc()
is called, but no check for a return value of NULL is made.  However,
immediately afterwards statments which access the allocated memory
are used (memcpy()/memset(), etc) which will result in a segmentation
fault/violation occuring if NULL is returned from the OPENSSL_malloc()
call.

The patch file below should address/correct this issue:

--- gost_pmeth.c.orig   2016-03-02 17:24:49.503519153 -0800
+++ gost_pmeth.c2016-03-02 17:27:27.179558967 -0800
@@ -107,6 +107,8 @@
 return 1;
 case EVP_PKEY_CTRL_SET_IV:
 pctx->shared_ukm = OPENSSL_malloc((int)p1);
+   if (!pctx->shared_ukm)
+   return 0;
 memcpy(pctx->shared_ukm, p2, (int)p1);
 return 1;
 case EVP_PKEY_CTRL_PEER_KEY:
@@ -533,6 +535,8 @@
 return 0;
 }
 keydata = OPENSSL_malloc(32);
+if (!keydata)
+   return 0;
 memcpy(keydata, data->key, 32);

[openssl-dev] ALPN and SNI callbacks in 1.0.2

2016-03-03 Thread Short, Todd

We’ve run into an issue with the ALPN and SNI TLS extension callbacks in 1.0.2. 
The same behavior may be in master, but I have yet to check.

In summary, the ALPN selection callback is invoked before the SNI/servername 
callback, yet the ALPN value returned may be dependent on the server being 
connected to. In other words, ALPN may be broken for virtual servers.

There’s a comment in ssl_parse_clienthello_tlsext() that clearly states:

/*
 * Internally supported extensions are parsed first so SNI can be handled
 * before custom extensions. An application processing SNI will typically
 * switch the parent context using SSL_set_SSL_CTX and custom extensions
 * need to be handled by the new SSL_CTX structure.
 */

There are 4 functions that handle TLS extensions, and are invoked in the 
following order

ssl_scan_clienthello_tlsext()
* saves servername
* saves ec_point_formats
* saves elliptic_curve list
* saves opaque PRF input
* calls session ticket callback
* saves status request
* saves heartbeat
* notes NPN seen
* calls ALPN callback

ssl_check_clienthello_tlsext_early()
* calls servername callback
* calls PRF callback

ssl_scan_clienthello_custom_tlsext()
* parses custom extensions

ssl_check_clienthello_tlsext_late()
* calls status callback

I would argue that ALPN data should be saved in ssl_scan_clienthello_tlsext() 
and processed in ssl_check_clienthello_tlsext_early() - after the servername 
callback

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Issue #616 on Github | ec_mult.c | ec_wNAF_mul()

2016-03-03 Thread Nicholas Prowse

Requesting input from people that have worked on the ec_mult.c file in the past.
Issue on Github:https://github.com/openssl/openssl/issues/616
We would like to know the purpose of the dead code in question in the 
ec_wNAF_mul() function below (starts around line 323 of the file):
if (tmp_len <= max_len) {
/*
 * One of the other wNAFs is at least as long as the wNAF
 * belonging to the generator, so wNAF splitting will not buy
 * us anything.
 */

numblocks = 1;
totalnum = num + 1; /* don't use wNAF splitting */
wNAF[num] = tmp_wNAF;
wNAF[num + 1] = NULL;
wNAF_len[num] = tmp_len;
if (tmp_len > max_len)  max_len = tmp_len;
Sent from Yahoo Mail on Android
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Solaris 10 80-test_ca failure

2016-03-03 Thread Erik Forsberg


I have been having 32-bit only test failures from test_ca
for quite a while now on Solaris 10 (1.1.pre), Finally figured
out what is wrong.

I build both 32-bit and 64-bit libraries.
My /usr/local/bin/perl is always 64-bit,
used to be required for assembler support.

LD_PRELOAD is used to force newly built libs into the test process
using util/shlib_wrap.sh

So, when building 32-bit libs, shlib_wrap tries to preload a 32-bit
libcrypto/libssl into the 64-bit perl process when CA.pl is invoked.
This causes failure on Solaris 10, but seems to be ignored on Solaris 11.

There was specific support to handle 64-bit builds in shlib_wrap, this
method also needs to be used for 32-bit builds.

This patch makes it work in all cases for me.
Someone using SPARC should review what /usr/bin/file
reports for an old 32-bit SPARC library (if such still exists)
I have no access to SPARC hardware.


*** shlib_wrap.sh   Tue Feb 16 23:55:51 2016
--- /usr/local/src/openssl-1.1//shlib_wrap.sh   Tue Mar  1 23:21:23 2016
***
*** 27,32 
--- 27,37 
LD_PRELOAD_64="$LIBCRYPTOSO $LIBSSLSO"; export LD_PRELOAD_64
preload_var=LD_PRELOAD_64
;;
+   *ELF\ 32*SPARC*|*ELF\ 32*80386*)
+   [ -n "$LD_LIBRARY_PATH_32" ] && rld_var=LD_LIBRARY_PATH_32
+   LD_PRELOAD_32="$LIBCRYPTOSO $LIBSSLSO"; export LD_PRELOAD_32
+   preload_var=LD_PRELOAD_32
+   ;;
# Why are newly built .so's preloaded anyway? Because run-time
# .so lookup path embedded into application takes precedence
# over LD_LIBRARY_PATH and as result application ends up linking
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] cipher order

2016-03-03 Thread Emilia Käsper

Hm, I think that I actually agree. But David's done enough, so I'll have a
look myself.

On Thu, Mar 3, 2016 at 5:33 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> On 3/3/16, 11:30 , "openssl-dev on behalf of Hanno Böck"
>  wrote:
>
> >On Thu, 03 Mar 2016 16:18:57 + Emilia Käsper 
> >wrote:
> >>https://github.com/openssl/openssl/pull/783
> >
> >This is different from what I had in mind.
> >...
> >I would argue that cbc/hmac is so fragile that it's always preferrable
> >to have aead before cbc/hmac. The security difference between 128 and
> >256 bit aes is imho mostly irrelevant in practice.
>
> Again, +1
>
> Perhaps David can do his magic again? :-)
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] 1.1-pre: test 80 fails

2016-03-03 Thread Blumenthal, Uri - 0553 - MITLL

$ ./Configure darwin64-x86_64-cc enable-rfc3779 threads zlib
enable-ec_nistp_64_gcc_128 shared --prefix=/Users/ur20980/src/openssl-1.1
--openssldir=/Users/ur20980/src/openssl-1.1/etc —unified

. . . . . .

$ make depend && make clean && make all && make test && make install

. . . . . . 

../test/recipes/70-test_verify_extra.t  ok

../test/recipes/80-test_ca.t .. ok

../test/recipes/80-test_cms.t . 3/4

#   Failed test 'compressed content test streaming PEM format'

#   at ../test/recipes/80-test_cms.t line 452.

# Looks like you failed 1 test of 11.

../test/recipes/80-test_cms.t . 4/4

#   Failed test 'CMS <=> CMS consistency tests, modified key parameters

# '

#   at ../test/recipes/80-test_cms.t line 458.

# Looks like you failed 1 test of 4.

../test/recipes/80-test_cms.t . Dubious, test returned 1 (wstat
256, 0x100)

Failed 1/4 subtests

../test/recipes/80-test_ct.t .. ok

../test/recipes/80-test_dane.t  ok

. . . . . .



Test Summary Report

---

../test/recipes/80-test_cms.t   (Wstat: 256 Tests: 4 Failed: 1)

  Failed test:  4

  Non-zero exit status: 1

Files=70, Tests=389, 56 wallclock secs ( 0.55 usr  0.16 sys + 35.30 cusr
15.09 csys = 51.10 CPU)

Result: FAIL

Failed 1/70 test programs. 1/389 subtests failed.

make: *** [test] Error 255

-- 
Regards,
Uri Blumenthal




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] cipher order

2016-03-03 Thread Blumenthal, Uri - 0553 - MITLL

On 3/3/16, 11:30 , "openssl-dev on behalf of Hanno Böck"
 wrote:

>On Thu, 03 Mar 2016 16:18:57 + Emilia Käsper 
>wrote:
>>https://github.com/openssl/openssl/pull/783
>
>This is different from what I had in mind.
>...
>I would argue that cbc/hmac is so fragile that it's always preferrable
>to have aead before cbc/hmac. The security difference between 128 and
>256 bit aes is imho mostly irrelevant in practice.

Again, +1

Perhaps David can do his magic again? :-)


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] cipher order

2016-03-03 Thread Hanno Böck

On Thu, 03 Mar 2016 16:18:57 +
Emilia Käsper  wrote:

> https://github.com/openssl/openssl/pull/783

This is different from what I had in mind.

What this patch does is sort e.g. chacha/poly and aes256-gcm before
aes256-cbc. It does however not sort aes128-gcm before aes256-cbc.
(David Benjamin answered to me on the chrome security list that he
wanted to avoid arguing about this and chose the lesser controversial
variant.)

I would argue that cbc/hmac is so fragile that it's always preferrable
to have aead before cbc/hmac. The security difference between 128 and
256 bit aes is imho mostly irrelevant in practice.

The difference between the two approaches may become mostly irrelevant
once all major browsers support at least one aead mode with 256 bit,
but I'm not sure if that's going to happen any time soon.



-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpmJ5ws0YpN1.pgp
Description: OpenPGP digital signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] cipher order

2016-03-03 Thread Emilia Käsper

https://github.com/openssl/openssl/pull/783

Courtesy of David Benjamin.

On Thu, Mar 3, 2016 at 4:34 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> +1
>
> Sent from my BlackBerry 10 smartphone on the
> Verizon Wireless 4G LTE network.
>   Original Message
> From: Hanno Böck
> Sent: Thursday, March 3, 2016 07:28
> To: openssl-dev@openssl.org
> Reply To: openssl-dev@openssl.org
> Subject: [openssl-dev] cipher order
>
> Hi,
>
> Last year I proposed to change the ciphering order in OpenSSL to always
> prefer AEAD cipher suites before CBC/HMAC-based ones:
> https://mta.openssl.org/pipermail/openssl-dev/2015-January/000421.html
>
> I just checked openssl 1.1.0 alpha and it still orders ciphers in an
> imho problematic way.
>
> Browsers have largely decided to implement GCM-modes only with AES128.
> Chrome is now about to change that. Not sure if other browsers will
> follow.
>
> Right now if you configure a server with openssl's cipher suite
> ordering it is likely that a connection will happen with AES256 in CBC
> mode instead of the (most likely more secure) AES128 in GCM mode.
>
> Can this be changed before 1.1.0 gets out?
>
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: ha...@hboeck.de
> GPG: BBB51E42
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] cipher order

2016-03-03 Thread Blumenthal, Uri - 0553 - MITLL

+1

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Hanno Böck
Sent: Thursday, March 3, 2016 07:28
To: openssl-dev@openssl.org
Reply To: openssl-dev@openssl.org
Subject: [openssl-dev] cipher order

Hi,

Last year I proposed to change the ciphering order in OpenSSL to always
prefer AEAD cipher suites before CBC/HMAC-based ones:
https://mta.openssl.org/pipermail/openssl-dev/2015-January/000421.html

I just checked openssl 1.1.0 alpha and it still orders ciphers in an
imho problematic way.

Browsers have largely decided to implement GCM-modes only with AES128.
Chrome is now about to change that. Not sure if other browsers will
follow.

Right now if you configure a server with openssl's cipher suite
ordering it is likely that a connection will happen with AES256 in CBC
mode instead of the (most likely more secure) AES128 in GCM mode.

Can this be changed before 1.1.0 gets out?

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3716] Patch for setting preferred cipher list

2016-03-03 Thread Short, Todd via RT

Yes, not absolutely necessary.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3716
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] cipher order

2016-03-03 Thread Hanno Böck

Hi,

Last year I proposed to change the ciphering order in OpenSSL to always
prefer AEAD cipher suites before CBC/HMAC-based ones:
https://mta.openssl.org/pipermail/openssl-dev/2015-January/000421.html

I just checked openssl 1.1.0 alpha and it still orders ciphers in an
imho problematic way.

Browsers have largely decided to implement GCM-modes only with AES128.
Chrome is now about to change that. Not sure if other browsers will
follow.

Right now if you configure a server with openssl's cipher suite
ordering it is likely that a connection will happen with AES256 in CBC
mode instead of the (most likely more secure) AES128 in GCM mode.

Can this be changed before 1.1.0 gets out?

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgp9aiNaxHyXU.pgp
Description: OpenPGP digital signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] overflow issue in b2i_PVK_bio

2016-03-03 Thread Marcus Meissner

Hi,

https://guidovranken.wordpress.com/2016/03/01/public-disclosure-malformed-private-keys-lead-to-heap-corruption-in-b2i_pvk_bio/

Integer overflow in b2i_PVK_bio

Have you assigned a CVE internally for that already?

Ciao, Marcus
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Configure zlib broken in latest 1.1 git

2016-03-03 Thread Richard Levitte

In message  on Wed, 2 Mar 2016 23:24:41 -0800, 
"Erik Forsberg"  said:

erik> 
erik> 
https://github.com/openssl/openssl/commit/98fdbce09144a8addc6682a0ffd8ac92b2ce70b1
erik> 
erik> broke Configure zlib
erik> the required -lz never makes it into the produced Makefile
erik> 
erik> I used Configure solaris64-x86_64-cc but I think this is more generic

I'm surprised it wasn't already broken here: 
bcb1977b7f4186b5551d83839286bc02991c2ad3

I seem to have broken down the logic behind zlib / zlib-dynamic right
about there.

Anyhow, the attached patch whould fix the problem, would you verify
that it works for you too?

Cheers,
Richard

diff --git a/Configure b/Configure
index 28339f1..5e2e8d3 100755
--- a/Configure
+++ b/Configure
@@ -339,6 +339,7 @@ our %disabled = ( # "what" => "comment"
 		  "static-engine"  => "default",
 		  "unit-test"  => "default",
 		  "zlib"   => "default",
+		  "zlib-dynamic"   => "default",
 		  "crypto-mdebug"  => "default",
 		  "heartbeats" => "default",
 		);
@@ -582,6 +583,10 @@ foreach (@argvcopy)
 {
 delete $disabled{"dynamic-engine"};
 }
+elsif ($1 eq "zlib-dynamic")
+{
+delete $disabled{"zlib"};
+}
 		my $algo = $1;
 		delete $disabled{$algo};
 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Do not offer options like -ssl2, -tls1, -dtls if they are not compiled in

[openssl-dev] [PATCH] Do not offer options like -ssl2, -tls1, -dtls if they are not compiled in

[openssl-dev] [openssl.org #4375] [PATCH] Missing Sanity Checks for OPENSSL_malloc() in OpenSSL-1.0.2g

[openssl-dev] [openssl.org #4374] [PATCH] Potential for NULL pointer dereferences in OpenSSL-1.0.2g (CWE-476)

[openssl-dev] ALPN and SNI callbacks in 1.0.2

[openssl-dev] Issue #616 on Github | ec_mult.c | ec_wNAF_mul()

[openssl-dev] Solaris 10 80-test_ca failure

Re: [openssl-dev] cipher order

[openssl-dev] 1.1-pre: test 80 fails

Re: [openssl-dev] cipher order

Re: [openssl-dev] cipher order

Re: [openssl-dev] cipher order

Re: [openssl-dev] cipher order

Re: [openssl-dev] [openssl.org #3716] Patch for setting preferred cipher list

[openssl-dev] cipher order

[openssl-dev] overflow issue in b2i_PVK_bio

Re: [openssl-dev] Configure zlib broken in latest 1.1 git

17 matches

Site Navigation

Mail list logo

Footer information