Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Daniel Kahn Gillmor]

On Tue 2018-01-09 18:41:25 -0800, William Bathurst wrote:
> [ dkg wrote: ]
>> My understanding is that the algorithm designers and primary advocates
>> have not been particularly forthcoming with their design goals, and
>> their reputation is mixed, at best.
>
> Simon and Speck has been in the public domain for a number of years and 
> there are quite a few white papers and articles on the Ciphers. Allowing 
> public scrutiny and crypto-analysis is one way to put a cipher through 
> the grinder to make sure there are no back doors or weaknesses.

It sounds like we agree that adversarial cryptanalysis is a necessary
component of evaluating cryptographic algorithms today. :)

And yes, Simon and Speck have indeed been published for a while now.  My
understanding is that there has been a steady stream of cryptanalysis
against them, which has made some non-negligible progress in whittling
down their initially-claimed security levels.

Meanwhile (as i said above), the designers have not been particularly
forthcoming with producing their design goals and their own
cryptanalysis, despite requests for those documents.  Shouldn't the
designers of algorithms intended to be used by the public also be
transparent about their design goals and their own understanding of the
strengths and weaknesses of the algorithms they're proposing?  This
seems particularly relevant when the designers have been plausibly
accused of trying to pass off sub-standard cryptographic algorithms as
acceptable for public consumption (e.g. "we got punked" as one NIST
representative described the Dual EC DRBG fiasco).

I'd personally like to see documentation of the internal design goals
and cryptanalysis from the authors of Simon and Speck before considering
it for wider adoption, especially given that reasonably efficient strong
ciphers are already available.  Or do you think that knowing the
designers' goals and internal analysis should not a relevant criterion
for consideration?

Regards,

   --dkg


signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Daniel Kahn Gillmor]

Hi Bill--

On Fri 2018-01-05 10:52:01 -0800, William Bathurst wrote:

> We have open sourced our work in regards to integrating the Speck Cipher 
> with OpenSSL. Basic information about this cipher can be found here.
>
> https://en.wikipedia.org/wiki/Speck_(cipher) 
> 
>
> SPECK is a lightweight block ciphers each of which comes in a variety of 
> widths and key sizes and is targeted towards resource constrained 
> devices and environments. This implementation is currently implemented 
> using the 128 and 256 block sizes.

Thanks for your work on this, and for reporting on it here.  Out of
curiosity, who is the "We" involved here?  The changeset history
appears to be a bit ambivalent about the authorship, based on edits to
the README itself:

  
https://github.com/m2mi/openssl_speck/commit/4a67a5644ff5c56956063d858033585f57686d1e
  
https://github.com/m2mi/openssl_speck/commit/8d619beffa3bd1c221fc6a7946b9aa7a00774019

> 1) Community interest in such a lightweight cipher.

I'm not convinced that the OpenSSL project should encourage the adoption
of SPECK, given the general level of distrust around the algorithm:

  https://www.schneier.com/blog/archives/2017/09/iso_rejects_nsa.html

My understanding is that the algorithm designers and primary advocates
have not been particularly forthcoming with their design goals, and
their reputation is mixed, at best.

Regards,

  --dkg


signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] X509_cmp_time (possible) bug

[Daniel Kahn Gillmor]

On Mon 2017-09-11 14:16:11 +, Short, Todd via openssl-dev wrote:
> Yes, it’s annoying, but it’s historic. I looked into changing this at one 
> point.

I think Dimitry's point was that the documentation doesn't match the
implementation because of the flexibility of strcmp's defined return
code.

However, i think commit 80770da39ebba0101079477611b7ce2f426653c5 ("X509
time: tighten validation per RFC 5280") resolves Dmitry's concerns.

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

Re: [openssl-dev] [openssl.org #4038] SSLv2 session reuse is broken on the 1.0.2 branch

[Daniel Kahn Gillmor]

On Wed 2016-06-15 09:51:37 -0400, Salz, Rich wrote:
> I think OpenSSL needs to decide if SSLv2 bugs will be getting fixed.
> Matt and I disagree :)

Isn't the existence of SSLv2 a bug? ;)

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

Re: [openssl-dev] Out-of-tree build?

[Daniel Kahn Gillmor]

On Fri 2016-06-10 06:27:30 -0400, Richard Levitte wrote:
> 'make clean' doesn't remove everything (it doesn't remove stuff
> produced by Configure), 'git clean -dfx' removes the last vestiges.
>
> It's possible that we'd do well with a 'make distclean'

yes, please!  For systems that build from distributed tarballs, "git
clean" isn't really an option.

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

Re: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity

[Daniel Kahn Gillmor]

On Fri 2016-02-26 18:04:43 +0100, Viktor Dukhovni  
wrote:
> I'd like to propose a policy of no bug fixes to undocumented public
> interfaces.  If the interface is useful enough to fix, it has to be
> documented.

fwiw, i agree with Viktor on this proposal.  Clear, sane APIs require
documentation, and just writing up the documentation can sometimes spur
people to evaluate the functionality differently and look for bugs in
new ways.

If anyone understands a function well enough to fix bugs in it, you should
understand it well enough to write minimal documentation.

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

Re: [openssl-dev] [openssl.org #3203] Normalize PFS key exchange labels

[Daniel Kahn Gillmor via RT]

On Tue 2016-02-02 14:08:18 -0500, Rich Salz via RT wrote:
> any chance you can refresh your 1.0.2 patch? I'm interested in being able to
> accept the common names but not changing the output for compatibility..

I am too :)

it looks like it was already merged, though, as
0ec6898c67aeddc3c414f3cc1af2275d81329c20.

0 dkg@alice:~$ openssl version
OpenSSL 1.0.2f  28 Jan 2016
0 dkg@alice:~$ openssl ciphers -v DHE-DSS-DES-CBC3-SHA
EDH-DSS-DES-CBC3-SHASSLv3 Kx=DH   Au=DSS  Enc=3DES(168) Mac=SHA1
0 dkg@alice:~$ openssl ciphers -v EDH-DSS-DES-CBC3-SHA
EDH-DSS-DES-CBC3-SHASSLv3 Kx=DH   Au=DSS  Enc=3DES(168) Mac=SHA1
0 dkg@alice:~$ 

do you think there are pieces that aren't yet merged?  have you tried
using the common names with 1.0.2 and they don't work?

  --dkg


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

Re: [openssl-dev] [openssl.org #2768] Bug: internal_verify() hides errors from callbacks after X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE

[Daniel Kahn Gillmor via RT]

On Mon 2016-02-01 18:46:20 -0500, Viktor Dukhovni wrote:
> On Mon, Feb 01, 2016 at 11:38:49PM +, Alex Rousskov via RT wrote:
>
>> On 02/01/2016 02:32 PM, openssl-dev@openssl.org via RT wrote:
>> 
>> > Please be more explicit about what errors you feel were not reported.
>> 
>> One specific error mentioned during the previous discussion was "expired
>> certificate". This was ~four years ago, so my recollection may be
>> faulty, but I believe that was _not_ the only hidden error.
>
> Expiration makes no sense for a certificate at the top of the chain,
> it has no issuer, so the date is unsigned and meaningless.

if the cert at the top of the chain is self-signed, it's entirely
reasonable to say that the expiration date is meaningful.  For example,
I could distribute a certificate for a root authority which i intend to
only be useful for 2 years.

How else should i indicate to the end user that the cert should be be
considered unusable after that time?

the fact that a root cert is *not* expired is maybe not too meaningful.
But if it *is* limited in time, then we should take it at its word and
not rely on it after that point, in the same way that if the root cert
is limited via nameConstraints, we should take it at its word and not
rely on it for names outside the bounds of what it declares itself valid
for.

 --dkg


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

Re: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open

[Daniel Kahn Gillmor]

On Tue 2016-01-26 16:37:58 -0500, Salz, Rich wrote:
> TFO is interesting because it lets UDP-style attacks happen at the TCP
> level.  Normally you can't do a TCP attack unless you have a valid
> client IP address.
>
> Imagine connecting once and then sending the syncookie to the botnet.

This suggests that you have on-path capabilities between each of the
reflectors and the victim, right?

If you have on-path capabilities, couldn't you do a similar attack
against a live TCP session?  learn (or create) the sequence number of a
TCP session between each of the reflectors and the target, and
distribute them to the botnet?  Then each member of the botnet sends out
a TCP packet (sequence numbers augmented in some coordinated fashion) to
the reflector that triggers an ACK (and even worse, a data flow) from
the reflector to the victim.

I've never done this, so maybe i've missed some mitigating detail, but
it seems like the same risk with or without TFO.

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

Re: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open

[Daniel Kahn Gillmor via RT]

On Tue 2016-01-26 16:37:58 -0500, Salz, Rich wrote:
> TFO is interesting because it lets UDP-style attacks happen at the TCP
> level.  Normally you can't do a TCP attack unless you have a valid
> client IP address.
>
> Imagine connecting once and then sending the syncookie to the botnet.

This suggests that you have on-path capabilities between each of the
reflectors and the victim, right?

If you have on-path capabilities, couldn't you do a similar attack
against a live TCP session?  learn (or create) the sequence number of a
TCP session between each of the reflectors and the target, and
distribute them to the botnet?  Then each member of the botnet sends out
a TCP packet (sequence numbers augmented in some coordinated fashion) to
the reflector that triggers an ACK (and even worse, a data flow) from
the reflector to the victim.

I've never done this, so maybe i've missed some mitigating detail, but
it seems like the same risk with or without TFO.

   --dkg


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

Re: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open

[Daniel Kahn Gillmor]

On Mon 2016-01-25 13:51:11 -0500, Viktor Dukhovni wrote:
> On Mon, Jan 25, 2016 at 06:42:02PM +, Kurt Roeckx via RT wrote:
>
>> On Mon, Jan 25, 2016 at 06:24:55PM +, Sara Dickinson via RT wrote:
>> > I would like to request that support be added to OpenSSL to enable
>> > client applications to make use use of TCP Fast Open
>> > (https://tools.ietf.org/html/rfc7413
>> > ) when initiating the TLS
>> > handshake on Linux (TCP Fast Open is available in Linux kernel >
>> > 4.1).

I think it was added even earlier to the Linux kernel:

  
http://kernelnewbies.org/Linux_3.13#head-159ff61ea3acfd67b88855e75dbbb140f8825c4a

>> I've seen that request, and I have tought about it.  I'm just
>> wondering if that comes with security consequences, like replay
>> attacks.  Specially in combination with what they're doing with
>> TLS 1.3.
>> 
>> The API clearly doesn't support anything like that currently.
>
> No security impact.  Just a saving of 1-RTT on "warm" TCP reconnects.
>
> If the client's first flight payload also carries 0-RTT TLS 1.3
> data, the exposure is the same whether TCP fast open is used or
> not.

I agree with this cryptographic analysis, fwiw.

if 0-RTT support is added to OpenSSL, then we definitely need a clear
API adjustment so that applications can know whether their data is going
out in the non-PFS/non-replay-protected preflights, or in the
regularly-protected session.  But i don't think this has any bearing on
TFO.

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

Re: [openssl-dev] [openssl.org #4261] BUG unable to connect to Mysql via ssl connection.

[Daniel Kahn Gillmor via RT]

On Thu 2016-01-21 10:50:28 -0500, Alan Bocutt via RT wrote:
> I am currently running Ubuntu with Mysql and am unable to connect via an ssl
> connection to the database getting following error.
>
> error 2026 (hy000): ssl connection error: protocol version mismatch
>
> My installation details are as follows
>
> Ubuntu version 
>
> Linux ubuntu-365sussex 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24
> 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>
> Installed Version info for OpenSSL
>
> OpenSSL 1.0.1f 6 Jan 2014

iirc, mysql doesn't use openssl at all, due to licensing
incompatibilities.  It uses a separate TLS implementation entirely, but
i don't recall whether it's an embedded copy of CYAssl these days or
something else.  I think this question belongs in a MySQL forum, not an
OpenSSL forum.

--dkg


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

Re: [openssl-dev] [openssl.org #4261] BUG unable to connect to Mysql via ssl connection.

[Daniel Kahn Gillmor]

On Thu 2016-01-21 10:50:28 -0500, Alan Bocutt via RT wrote:
> I am currently running Ubuntu with Mysql and am unable to connect via an ssl
> connection to the database getting following error.
>
> error 2026 (hy000): ssl connection error: protocol version mismatch
>
> My installation details are as follows
>
> Ubuntu version 
>
> Linux ubuntu-365sussex 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24
> 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>
> Installed Version info for OpenSSL
>
> OpenSSL 1.0.1f 6 Jan 2014

iirc, mysql doesn't use openssl at all, due to licensing
incompatibilities.  It uses a separate TLS implementation entirely, but
i don't recall whether it's an embedded copy of CYAssl these days or
something else.  I think this question belongs in a MySQL forum, not an
OpenSSL forum.

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

[openssl-dev] [openssl.org #4192] [PATCH] differentiate SSL_* from from SSL_CTX_* in documentation

[Daniel Kahn Gillmor via RT]

A couple places in the OpenSSL documentation claims that SSL_foo()
takes an SSL_CTX* instead of an SSL*.  i've corrected those here.
---
 doc/ssl/SSL_CTX_set1_verify_cert_store.pod | 8 
 doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod   | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/ssl/SSL_CTX_set1_verify_cert_store.pod 
b/doc/ssl/SSL_CTX_set1_verify_cert_store.pod
index af09f88..fbdd314 100644
--- a/doc/ssl/SSL_CTX_set1_verify_cert_store.pod
+++ b/doc/ssl/SSL_CTX_set1_verify_cert_store.pod
@@ -17,10 +17,10 @@ verification or chain store
  int SSL_CTX_set0_chain_cert_store(SSL_CTX *ctx, X509_STORE *st);
  int SSL_CTX_set1_chain_cert_store(SSL_CTX *ctx, X509_STORE *st);
 
- int SSL_set0_verify_cert_store(SSL_CTX *ctx, X509_STORE *st);
- int SSL_set1_verify_cert_store(SSL_CTX *ctx, X509_STORE *st);
- int SSL_set0_chain_cert_store(SSL_CTX *ctx, X509_STORE *st);
- int SSL_set1_chain_cert_store(SSL_CTX *ctx, X509_STORE *st);
+ int SSL_set0_verify_cert_store(SSL *ssl, X509_STORE *st);
+ int SSL_set1_verify_cert_store(SSL *ssl, X509_STORE *st);
+ int SSL_set0_chain_cert_store(SSL *ssl, X509_STORE *st);
+ int SSL_set1_chain_cert_store(SSL *ssl, X509_STORE *st);
 
 =head1 DESCRIPTION
 
diff --git a/doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod 
b/doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod
index 296699d..ea2ce5f 100644
--- a/doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod
+++ b/doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod
@@ -13,7 +13,7 @@ SSL_CTX_set_tmp_rsa_callback, SSL_CTX_set_tmp_rsa, 
SSL_CTX_need_tmp_rsa, SSL_set
  long SSL_CTX_set_tmp_rsa(SSL_CTX *ctx, RSA *rsa);
  long SSL_CTX_need_tmp_rsa(SSL_CTX *ctx);
 
- void SSL_set_tmp_rsa_callback(SSL_CTX *ctx,
+ void SSL_set_tmp_rsa_callback(SSL *ssl,
 RSA *(*tmp_rsa_callback)(SSL *ssl, int is_export, int keylength));
  long SSL_set_tmp_rsa(SSL *ssl, RSA *rsa)
  long SSL_need_tmp_rsa(SSL *ssl)
-- 
2.6.4

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

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

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Daniel Kahn Gillmor]

On Fri 2015-11-13 14:48:41 -0500, Viktor Dukhovni wrote:
> The simplest approach is to remove ciphersuites from the SSL/TLS
> code (effectively making them unavailable even via ALL:COMPLEMENTOFALL),
> but leave the underlying crypto in the library.
>
> Similarly, one might remove algorithms from S/MIME, CMS, ...  while
> leaving them in the base crypto library.

FWIW, this is one of the consequences of OpenSSL providing both
libcrypto and libssl.  It would be nice from a maintenance perspective
to be able to decouple the two more cleanly.

I definitely like Viktor's suggestion of removing known-bad mechanisms
from libssl.  It's harder to know what to do with libcrypto.

Perhaps it would be useful to gather data on this by looking at large
codebases (e.g. large linux distros like fedora or debian) to see
whether these particular functions of libcrypto are being used or linked
to.

I haven't had the time to do a full review here, but i've found
https://codesearch.debian.net/ useful for this kind of API
deprecation/removal in the past.

e.g.:  https://codesearch.debian.net/perpackage-results/MDC2/2/page_0

Unfortunately, OpenSSL has lots of bindings to other languages, so the
binding authors themselves might say "we use these functions and offer
them to our users", which means there's a chained set of dependencies
to consider for proper deprecation.  Will removal of these primitives
mean that the language bindings won't build against newer versions of
OpenSSL?

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

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Daniel Kahn Gillmor]

On Fri 2015-11-13 16:16:56 -0500, Viktor Dukhovni wrote:
> This is very difficult, because most applications use libcrypto
> algorithms indirectly, via EVP_get_cipherbyname(), EVP_get_digestbyname()
> and so on.  So the code will link, but there'll be runtime errors
> due to missing ciphers or digests.

I'm less sympathetic in this case, since these functions have
well-defined semantics when a cipher has been removed (or simply isn't
present in the first place): they return NULL on error, and if code X
doesn't handle errors properly, it's up to code X to fix that problem.

Of course, no one will catch this at compile time, or even at dynamic
link time -- it'll get "caught" at runtime, which probably means
codepaths that haven't been tickled maybe ever.

At any rate, it's not hard to search for uses of EVP_get_*byname [0] --
places where those are used with hard-coded strings without error
checking can be ferreted out and fixed, and places where they're invoked
indirectly should probably just pass the error message upward in the
stack, no?

   --dkg

[0] 
https://codesearch.debian.net/perpackage-results/EVP_get_%5Ba-z%5D*byname/2/page_0
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4129] [PATCH] Can BIO_new_mem_buf take a const void* instead of a void* ?

[Daniel Kahn Gillmor via RT]

The documentation asserts that BIO_new_mem_buf is forced to a
read-only state ("The BIO is set to a read only state and as a result
cannot be written to"), but it requires passing in a void*.  This
makes it hard to use from a function that has a const buffer.

Presumably most code that tries to use a const buffer with
BIO_new_mem_buf either casts away the constness (bad practice, since
OpenSSL's API itself isn't guaranteeing it will actually remain const)
or copies the memory to a non-const buffer before passing it in (an
unnecessary memcpy).

The changeset proposed here makes OpenSSL's API offer the guarantee
that its documentation appears to make by casting away the constness
internally to BIO_new_mem_buf, but i haven't analyzed all the possible
ways that an arbitrary BIO can be (mis)used internally code to be sure
this is safe.

If this is not a safe thing to do, we should instead modify the
documentation to avoid the implication that such a buffer will remain
read-only.
---
 crypto/bio/bss_mem.c | 6 --
 doc/crypto/BIO_s_mem.pod | 2 +-
 include/openssl/bio.h| 2 +-
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/crypto/bio/bss_mem.c b/crypto/bio/bss_mem.c
index 485a8bf..e50db43 100644
--- a/crypto/bio/bss_mem.c
+++ b/crypto/bio/bss_mem.c
@@ -109,7 +109,7 @@ BIO_METHOD *BIO_s_secmem(void)
 return(_method);
 }
 
-BIO *BIO_new_mem_buf(void *buf, int len)
+BIO *BIO_new_mem_buf(const void *buf, int len)
 {
 BIO *ret;
 BUF_MEM *b;
@@ -123,7 +123,9 @@ BIO *BIO_new_mem_buf(void *buf, int len)
 if ((ret = BIO_new(BIO_s_mem())) == NULL)
 return NULL;
 b = (BUF_MEM *)ret->ptr;
-b->data = buf;
+b->data = (void*) buf; /* is it safe to cast away constness here
+  and rely on the MEM_RDONLY flags set
+  below? */
 b->length = sz;
 b->max = sz;
 ret->flags |= BIO_FLAGS_MEM_RDONLY;
diff --git a/doc/crypto/BIO_s_mem.pod b/doc/crypto/BIO_s_mem.pod
index 1aa7e6e..1fa62b5 100644
--- a/doc/crypto/BIO_s_mem.pod
+++ b/doc/crypto/BIO_s_mem.pod
@@ -17,7 +17,7 @@ BIO_get_mem_ptr, BIO_new_mem_buf - memory BIO
  BIO_set_mem_buf(BIO *b,BUF_MEM *bm,int c)
  BIO_get_mem_ptr(BIO *b,BUF_MEM **pp)
 
- BIO *BIO_new_mem_buf(void *buf, int len);
+ BIO *BIO_new_mem_buf(const void *buf, int len);
 
 =head1 DESCRIPTION
 
diff --git a/include/openssl/bio.h b/include/openssl/bio.h
index f0fbc5b..c2be049 100644
--- a/include/openssl/bio.h
+++ b/include/openssl/bio.h
@@ -672,7 +672,7 @@ long BIO_debug_callback(BIO *bio, int cmd, const char 
*argp, int argi,
 
 BIO_METHOD *BIO_s_mem(void);
 BIO_METHOD *BIO_s_secmem(void);
-BIO *BIO_new_mem_buf(void *buf, int len);
+BIO *BIO_new_mem_buf(const void *buf, int len);
 BIO_METHOD *BIO_s_socket(void);
 BIO_METHOD *BIO_s_connect(void);
 BIO_METHOD *BIO_s_accept(void);
-- 
2.6.2

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

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

Re: [openssl-dev] State machine rewrite

[Daniel Kahn Gillmor]

On Fri 2015-09-11 11:07:27 -0400, John Foley wrote:

> It's great to see improvements in the state machine along with
> consolidated handlers for TLS/DTLS.

Agreed.  Thanks for the work on this, Matt!

> Having said that, have you considered using a state transition table
> instead of long switch statements to enforce the state transition
> rules?  This would improve the maintainability of the code.  Here's a
> trivial example:
>
> http://www.gedan.net/2008/09/08/finite-state-machine-matrix-style-c-implementation/

I'm getting a 404 from this.  do you have another link?

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

Re: [openssl-dev] Mailman version used by OpenSSL is misconfigured and/or broken in relation to DKIM

[Daniel Kahn Gillmor]

On Wed 2015-08-05 17:04:30 -0400, Jonas Maebe wrote:
 On 05/08/15 23:00, mancha wrote:
 OpenSSL is certainly not alone in its practice of mangling headers
 and adding body footers so I'd be curious to hear how other lists
 handle domains such as yahoo.com.

 We warn people that DKIM-using domains may experience bounces, and
 that they should subscribe using a different email address to our
 lists. Yahoo/AOL switching it on before the probably most used mailing
 list manager could handle it certainly did not help in creating
 goodwill. Even now the mailman version included in our distribution
 still can't handle it, and manually installing and maintaining a
 different one is not something we care to do.

fwiw, the intersection between dkim/dmarc and mailman policy affects
even people who don't have dkim/dmarc enabled for their domains.

mailman effectively puts subscribers on hold if some threshold number of
mails sent to them bounce.

if a subscriber's mail exchanger respects dkim/dmarc reject policy, even
if they do not set it for their own domain, then all messages sent
through mailman from a dmarc reject domain will bounce for that
subscriber.

So if Alice from yahoo.com (which has dmarc reject) sends mail through
mailman, which sends it to Bob from example.com (which doesn't have
dmarc reject set, but respects it from other domains), Bob's mail
exchanger will bounce the message.  If Alice sends enough mail through
mailman, mailman will rack up one bounce from Bob per message, and
mailman will eventually unsubscribe Bob as a result.

afaict, mailman 2.1.9 or rejecting all mail from domains with dmarc
reject are the only sane paths through this thicket.

bleah.

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

Re: [openssl-dev] ssl_sess.c : compilation error

[Daniel Kahn Gillmor]

On Sun 2015-06-07 16:16:24 -0400, Kurt Roeckx wrote:
 You can set a callback on the creation of a new session.  See the
 SSL_CTX_sess_set_new_cb() manpage.  The SSL_CTX_sess_get_new_cb()
 get function returns that callback function back.

 There are no internal users in OpenSSL as far as I can see.  There
 might be code using OpenSSL that uses it, but I don't think that's
 very likely.

The only mentions of SSL_CTX_sess_get_new_cb are packages that bundle or
replicate OpenSSL code:

  https://codesearch.debian.net/results/SSL_CTX_sess_get_new_cb

SSL_CTX_sess_set_new_cb, otoh, is widely used (ruby, apache, courier, etc):

  https://codesearch.debian.net/results/SSL_CTX_sess_set_new_cb

Debian's archive, of course, is not all free software.  But it's a
pretty wide sampling of a lot of useful free software.

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

Re: [openssl-dev] F5 termination of TCP connection

[Daniel Kahn Gillmor]

On Mon 2015-06-01 07:36:01 -0400, Krzysztof Kwiatkowski wrote:

 Yes, that's exactly what we do in our configuration. We have 24 servers 
 with rather high workload. SSL is offloaded on F5 load balancer and 
 servers behind load balancers receive decrypted traffic.

 I'm not aware of any performance issues. And in fact it's quite good 
 idea as server itself doesn't need to know anything about TLS/SSL 
 protocol.

...  And the network connecting the load balancers to the backend
servers is completely physically secured, has no untrusted devices
connected to it anywhere, and all the backend servers completely trust
each other to avoid snooping or interfering with each others' traffic
... right?

When describing deployment configurations, please don't omit the
infrastructure and threat-model requirements for doing this kind of
deployment securely and responsibly.  You might think it goes without
saying, but a couple sentences of reminder don't hurt.

Or, as the powerpoint slide said: SSL added and removed here ;) [0]

  --dkg

[0] https://www.agwa.name/blog/post/cloudflare_ssl_added_and_removed_here
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found

[Daniel Kahn Gillmor]

On Wed 2015-05-27 16:32:45 -0400, Short, Todd via RT wrote:

 This is a change that Akamai has made to its implementation of OpenSSL.

 Version: master branch
 Description: Do not complain if config file not found

 Remove warning when OpenSSL config file can't be found

 Github link:
 https://github.com/akamai/openssl/commit/48ad3880d3247063098d1d2b0aa4e362c4b9d996

Why?  Is this warning no longer relevant?

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

Re: [openssl-dev] [openssl.org #3865] [Patch] Add DISALLOW_RENEGOTIATION option

[Daniel Kahn Gillmor via RT]

On Tue 2015-05-26 14:56:10 -0400, Short, Todd via RT wrote:
 This is a change that Akamai has made to its implementation of OpenSSL.

 Version: master branch
 Description: Add DISALLOW_RENEGOTIATION option

 Add support to disallow renegotiation in openssl
 The bit definition may need to change when pulled.

Thanks for these patches, Todd!

It would be great if patches which add new configuration options also
were to update the documentation.  It looks like this changeset would
want to also provide patches for:

 doc/ssl/SSL_CTX_set_options.pod
 doc/apps/s_server.pod

  --dkg



signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Using TLSv1.2

[Daniel Kahn Gillmor]

On Tue 2015-03-24 10:47:57 -0400, Андрей Даровских wrote:
 I use the openssl library in the project and use client certificate
 verification. When using protocol TLSv1.2 I have a problem with data
 encryption, using the private key of the client certificate. This is due to
 the fact that the certificate validation server selected encryption
 algorithm that is not supported by the crypt used to encrypt the signature
 on the client certificate (failure in method capi_rsa_sign of e_capi.c
 file).
 Now I have corrected the behavior as follows:
 - the method ssl3_send_client_certificate after selecting a client
 certificate makes cleaning pkeys [i].digest
 - the method ssl_set_cert if pkeys [i] .digest not specified, specify it.

 After that I worked with an application protocol TLSv1.2

 Is this correct or am I wrong to fix the library using openssl?

I don't think what you're proposing here is the right thing to do.
Also, your report above seems to talk about encryption algorithms but
your code change talks about digest algorithms, so i think something is
mixed up in terms of figuring out what the problem is and how to solve
it.  Maybe more details would help?

Can you give an example of the client certificate you were trying to
use, and/or a concrete example of a program that triggers the failure?

If the certificate you're using is sensitive and you don't want to share
it, can you describe a set of steps to recreate the error that you were
running into (perhaps including generating the certificate itself)?

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

Re: [openssl-dev] removing compression?

[Daniel Kahn Gillmor]

On Fri 2015-04-03 15:53:59 -0400, Salz, Rich wrote:
 I am thinking about removing compression and would like to know what
 the community thinks.

 At a minimum, I am going to remove the ability to add compression at
 run-time.  This was never really documented. Moving forward, if
 someone wants to add a new compression scheme they will need to modify
 the OpenSSL source.  This means COMP_METHOD becomes an internal
 datatype.

 But on a larger scale, does anyone use TLS compression?  It has
 certainly caused problems with HTTP (see
 http://en.wikipedia.org/wiki/CRIME). And the best practice these days
 is to do it at the application layer, and feed the compressed bytes
 down to TLS.

I think this change is a good idea, Rich.  Thanks for proposing it.

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

[openssl-dev] .txt files on https://openssl.org/ need Content-Type: text/plain; charset=utf-8

[Daniel Kahn Gillmor]

Thanks for the release today!  This is a trivial bug report, but i figure

I noticed that the advisory uses UTF-8, but it is being served with an
unadorned Content-Type: text/plain header:

$ (wget -O- -q -S https://openssl.org/news/secadv_20150319.txt | file -) 21 | 
egrep 'stdin|Content-Type'
  Content-Type: text/plain
/dev/stdin: UTF-8 Unicode text
$  

since most folks consider text/plain to default to iso-8859-1, that
means that Emilia Käsper's name is rendered as Emilia Käsper.

You can fix this by configuring the openssl.org webserver to serve
text/plain files (or at least this text/plain file) with charset=utf-8.

If you know that all the content is UTF-8 encoded, you can just add the
following line to your apache config:

  AddDefaultCharset utf-8

https://httpd.apache.org/docs/2.4/mod/core.html#adddefaultcharset

Regards,

--dkg

PS if there's a better place to report issues with the web site, please
   let me know.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3728] Question: does sslv3 in log mean we're using SSLv3?

[Daniel Kahn Gillmor]

On Thu 2015-03-05 08:58:10 -0800, Matt Caswell via RT wrote:
 On Thu Mar 05 17:42:49 2015, richard.c.pater...@sas.com wrote:
 Apologies if this is the incorrect forum for this question.

 We’re
 seeing error messages like SSL3_READ_BYTES and
 SSL3_GET_SERVER_CERTIFICATE for some reason;

 -
 SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

 -
 SSL£_GET_BYTES:sslv3 alert handshake failure

 However, we believe
 that we have disabled the use of SSLv3. Does the presence of
 “SSL3_” in the logs indicate that we are still using SSLv3 and not
 TLS like we think?

 No. These are just the names of internal functions. Originally written when it
 was just a choice of ssl2 or ssl3 they were subsequently reused for TLS - but
 the names have remained the same.

Is there a plan to change this in any subsequent release?  This kind of
misleading debugging information seems likely to confuse people.  I
understand that knowledgable users and developers might be used to
seeing these exact strings, but fixing them to provide correct
information is probably better for the entire community in the
long-term.

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

Re: [openssl-dev] [openssl.org #3728] Question: does sslv3 in log mean we're using SSLv3?

[Daniel Kahn Gillmor via RT]

On Thu 2015-03-05 08:58:10 -0800, Matt Caswell via RT wrote:
 On Thu Mar 05 17:42:49 2015, richard.c.pater...@sas.com wrote:
 Apologies if this is the incorrect forum for this question.

 We’re
 seeing error messages like SSL3_READ_BYTES and
 SSL3_GET_SERVER_CERTIFICATE for some reason;

 -
 SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

 -
 SSL£_GET_BYTES:sslv3 alert handshake failure

 However, we believe
 that we have disabled the use of SSLv3. Does the presence of
 “SSL3_” in the logs indicate that we are still using SSLv3 and not
 TLS like we think?

 No. These are just the names of internal functions. Originally written when it
 was just a choice of ssl2 or ssl3 they were subsequently reused for TLS - but
 the names have remained the same.

Is there a plan to change this in any subsequent release?  This kind of
misleading debugging information seems likely to confuse people.  I
understand that knowledgable users and developers might be used to
seeing these exact strings, but fixing them to provide correct
information is probably better for the entire community in the
long-term.

   --dkg


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

Re: [openssl-dev] Proposed cipher changes for post-1.0.2

[Daniel Kahn Gillmor]

On Wed 2015-02-11 10:15:11 -0500, Salz, Rich wrote:
 Note that for most applications the correct approach to configuring
 ciphersuites should be to start with DEFAULT and subtract what they don't
 want.  The library is then responsible for a generally sensible default order
 and default exclusions.

 I strongly disagree.  Most applications should explicitly list the
 ciphers they DO want.  That is the only way an application can be sure
 of what it is getting, without consulting external parties or
 configuration.  Otherwise, when the next Crime or Poodle or
 NameOfTheWeek comes out, you have no idea if you are vulnerable or not
 unless you look at something like the OpenSSL source code.

 For what it's worth, I believe that security levels make this
 problem much worse.

I disagree with you here, Rich.  There is ongoing evolution of our
understanding of TLS best practices, including standards, cryptanalysis,
and interoperability.  This dynamic situation seems unlikely to be come
static at any point in the future (changes in standards, cryptanalysis,
and the state of the network will continue to occur).  Even those of us
who spend a lot of time thinking about these matters have a hard time
keeping up.

As a larger ecosystem, we have maybe three main options to manage this
dynamism:

  0) every adminstrator of every TLS-using network service and every
 user of every TLS-using client needs to fiddle with TLS parameter
 selection as changes happen.

  1) every developer of every TLS-using tool (client or server) needs to
 fiddle with TLS parameter selection as changes happen.

  2) every library that implements TLS needs to fiddle with TLS
 parameter selection as changes happen.

Situation (0) is clearly untenable (it's also what we are valiantly
attempting today, e.g. https://bettercrypto.org/, because the other
things haven't happened effectively).

And situation (1) is just plain unlikely to happen.  Most software
developers *want* TLS to be magic sauce that they can sprinkle on and
have it Just Work.  They do not want to keep track of which parameters
are considered a bad idea this month, and they certainly don't want to
release new versions of their software just because someone says hey,
you need to update your cipherstring.

On the other hand, the people who are experts in this situation and who
understand the dynamics best are going to be the folks tapped for the
work in (2).  This is why these kinds of things should be done by
default in the TLS implementations.

That doesn't mean that integer-based security levels is the right
approach (is there documentation on what the OpenSSL semantics should be
for these other than doc/ssl/SSL_CTX_set_security_level.pod?) -- it's
possible that common use cases would be better.  Then there could be
an opportunistic use case that meets Viktor's goals, and a standard
use case that hews closer to TLS BCP.

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

Re: [openssl-dev] Proposed cipher changes for post-1.0.2

[Daniel Kahn Gillmor]

On Tue 2015-02-10 19:22:44 -0500, Salz, Rich wrote:
 currently, this is an error:
 
 0 dkg@alice:~$ openssl ciphers -v ALL:!NO-SUCH-CIPHER
 bash: !NO-SUCH-CIPHER: event not found
 0 dkg@alice:~$

 Yeah, but that's coming from bash, not openssl :)
 ; openssl ciphers -v ALL | wc
 111 6758403
 ; openssl ciphers -v ALL:!FOOBAR | wc
 111 6758403

d'oh!  of course, thanks. headdesks

 RC4 in LOW has a bit of pushback so far.  My cover for it is that the IETF 
 says don't use it.  So I think saying if you want it, say so is the way 
 to go.

I think that's the correct position.  People who want to be able to
negotiate a deprecated cipher should need to explicitly state that
that's their intent.

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

Re: [openssl-dev] Proposed cipher changes for post-1.0.2

[Daniel Kahn Gillmor]

On Tue 2015-02-10 16:15:36 -0500, Salz, Rich wrote:
 I would like to make the following changes in the cipher specs, in the master 
 branch, which is planned for the next release after 1.0.2

 Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW

yes, please!

 Anything that was 40-bit encryption is removed:
 /* Cipher 03 EXP-RC4-MD5 removed */
 /* Cipher 06 EXP-RC2-CBC-MD5 removed */
 /* Cipher 08 EXP-DES-CBC-SHA removed */
 /* Cipher 0B EXP-DH-DSS-DES-CBC-SHA removed */
 /* Cipher 0E EXP-DH-RSA-DES-CBC-SHA removed */
 /* Cipher 11 EXP-DHE-DSS-DES-CBC-SHA removed */
 /* Cipher 14 EXP-DHE-RSA-DES-CBC-SHA removed */
 /* Cipher 17 EXP-ADH-RC4-MD5 removed */
 /* Cipher 19 EXP-ADH-DES-CBC-SHA removed */
 /* Cipher 26 EXP-KRB5-DES-CBC-SHA removed */
 /* Cipher 27 EXP-KRB5-RC2-CBC-SHA removed */
 /* Cipher 28 EXP-KRB5-RC4-SHA removed */
 /* Cipher 29 EXP-KRB5-DES-CBC-MD5 removed */
 /* Cipher 2A EXP-KRB5-RC2-CBC-MD5 removed */
 /* Cipher 2B EXP-KRB5-RC4-MD5 removed */

when these are removed, what will that do to a cipherstring that
specifies them by negation?

currently, this is an error:

0 dkg@alice:~$ openssl ciphers -v ALL:!NO-SUCH-CIPHER
bash: !NO-SUCH-CIPHER: event not found
0 dkg@alice:~$ 

i wouldn't want ALL:!EXP-DHE-DSS-DES-CBC-SHA to be an error, though.

 The value of DEFAULT changes to this:
 ALL:!LOW:!EXPORT:!aNULL:!eNULL

 The combination of the first and last changes means that anyone who wants or 
 needs to use, say RC4 must explicitly say so.

This looks good to me.

Hanno wrote:

   I'd further suggest to move everything that's not PFSAEAD from HIGH
   to MEDIUM.

I agree with this as well.  It sets the stage for TLS 1.3.

Thanks for pushing on this, Rich.

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

Re: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups

[Daniel Kahn Gillmor]

On Wed 2015-01-28 03:44:10 -0500, Dr. Matthias St. Pierre wrote:
 On 01/28/2015 06:02 AM, Daniel Kahn Gillmor wrote:
 On Tue 2015-01-27 11:15:37 -0500, Dr. Matthias St. Pierre wrote:
 Add missing forward declarations and export declarations for DHparams
 and EC[PK]PARAMETERS.

 Add public functions to convert between EC_GROUP objects and 
 EC[PK]PARAMETERS
 objects: EC_GROUP_new_from_ec[pk]parameters(), 
 EC_GROUP_get_ec[pk]parameters().
 
 fwiw, the IETF TLS WG is moving away from the possibility of arbitrary
 EC groups, and toward the requirement of specified and vetted EC
 groups.  I'm not sure how much extra work should be done to maintain
 that as a public-facing interface.

 As for TLS, you maybe right. However, the use of Diffie-Hellman is not limited
 to TLS (in my case, it's IKEv2). The proposed changes are not for libssl, but 
 for
 the 'low level' libcrypto library, which is in my opinion a general purpose 
 crypto
 library. As such, it should not make assumptions on or impose restrictions to 
 possible
 use cases of the library. Neither should it enforce standards, but provide 
 algorithms.

 My patch does not introduce new features or change existing ones. It just 
 makes
 functionality available for reuse. I needed this particular functionality and 
 I 
 had the choice between 1) copy  paste the code 2) patch OpenSSL privately, or
 3) submit a patch. So I chose the latter.

Your choice of action makes sense to me, thanks!

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

Re: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups

[Daniel Kahn Gillmor]

On Wed 2015-01-28 03:44:10 -0500, Dr. Matthias St. Pierre wrote:
 On 01/28/2015 06:02 AM, Daniel Kahn Gillmor wrote:
 On Tue 2015-01-27 11:15:37 -0500, Dr. Matthias St. Pierre wrote:
 Add missing forward declarations and export declarations for DHparams
 and EC[PK]PARAMETERS.

 Add public functions to convert between EC_GROUP objects and 
 EC[PK]PARAMETERS
 objects: EC_GROUP_new_from_ec[pk]parameters(), 
 EC_GROUP_get_ec[pk]parameters().
 
 fwiw, the IETF TLS WG is moving away from the possibility of arbitrary
 EC groups, and toward the requirement of specified and vetted EC
 groups.  I'm not sure how much extra work should be done to maintain
 that as a public-facing interface.

 As for TLS, you maybe right. However, the use of Diffie-Hellman is not limited
 to TLS (in my case, it's IKEv2). The proposed changes are not for libssl, but 
 for
 the 'low level' libcrypto library, which is in my opinion a general purpose 
 crypto
 library. As such, it should not make assumptions on or impose restrictions to 
 possible
 use cases of the library. Neither should it enforce standards, but provide 
 algorithms.

 My patch does not introduce new features or change existing ones. It just 
 makes
 functionality available for reuse. I needed this particular functionality and 
 I 
 had the choice between 1) copy  paste the code 2) patch OpenSSL privately, or
 3) submit a patch. So I chose the latter.

Your choice of action makes sense to me, thanks!

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

Re: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups

[Daniel Kahn Gillmor]

On Tue 2015-01-27 11:15:37 -0500, Dr. Matthias St. Pierre wrote:
 Add missing forward declarations and export declarations for DHparams
 and EC[PK]PARAMETERS.

 Add public functions to convert between EC_GROUP objects and EC[PK]PARAMETERS
 objects: EC_GROUP_new_from_ec[pk]parameters(), 
 EC_GROUP_get_ec[pk]parameters().

fwiw, the IETF TLS WG is moving away from the possibility of arbitrary
EC groups, and toward the requirement of specified and vetted EC
groups.  I'm not sure how much extra work should be done to maintain
that as a public-facing interface.

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

Re: [openssl-dev] [openssl-announce] OpenSSL version 1.0.2 released

[Daniel Kahn Gillmor]

On Fri 2015-01-23 16:04:15 -0500, Steffen Nurpmeso wrote:
 Daniel Kahn Gillmor d...@fifthhorseman.net wrote:
  |On Fri 2015-01-23 06:19:14 -0500, Steffen Nurpmeso wrote:

  | brings.  (Myself even starves for documentation [coverage]
  | improvements.)
  |
  |fwiw, OpenSSL documentation is pretty easy to read and to edit.  If you
  |notice that things are missing, you can edit the docs, and submit
  |patches either on this mailing list, on the rt bugtracker at
  |https://rt.openssl.org/, or as a pull request via github:
  |
  | https://github.com/openssl/openssl

 And fwiw :) i don't have a github account -- i had one but wanted
 to pay (also because they paid a developer for git(1)
 development), yet they didn't accept cash.  And i *completely*
 decline using credit cards.

Sure, you don't need a github account at all, and no credit cards are
required :)

I'm assuming you've got the git client installed on your computer
(apt-get install git or yum install git or if you're on some
platform without a package management system get it from
http://git-scm.com/).

Then, to get a copy of the development tree and see what documentation
files are present, you'd do:

  git clone https://github.com/openssl/openssl
  cd openssl/doc
  ls crypto/ ssl/

edit the documentation you want to fix, generate a patch using git
diff and send it to this list attached to an explanatory e-mail.

Regards,

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

Re: [openssl-dev] [openssl-announce] OpenSSL version 1.0.2 released

[Daniel Kahn Gillmor]

On Fri 2015-01-23 06:19:14 -0500, Steffen Nurpmeso wrote:

 And i think we are all looking forward to see what the future
 brings.  (Myself even starves for documentation [coverage]
 improvements.)

fwiw, OpenSSL documentation is pretty easy to read and to edit.  If you
notice that things are missing, you can edit the docs, and submit
patches either on this mailing list, on the rt bugtracker at
https://rt.openssl.org/, or as a pull request via github:

 https://github.com/openssl/openssl

the main documentation is in the doc/ directory, either under
doc/crypto/ (for libcrypto documentation) or doc/ssl/ (for libssl
documentation).  It is in pod format, which is pretty easy to read and
get the hang of if you've used other markup languages.

If you have a proposed change but you aren't sure that you've got the
syntax right, go ahead and post the change anyway (in any of the three
forums i mentioned above) and indicate that you'd like an extra
double-check on the syntax.

Contributions to improve documentation are important contributions, and
it's a great way to give back to the project.

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

Re: [openssl-dev] [openssl-announce] OpenSSL version 1.0.2 released

[Daniel Kahn Gillmor]

On Fri 2015-01-23 16:04:15 -0500, Steffen Nurpmeso wrote:
 Daniel Kahn Gillmor d...@fifthhorseman.net wrote:
  |On Fri 2015-01-23 06:19:14 -0500, Steffen Nurpmeso wrote:

  | brings.  (Myself even starves for documentation [coverage]
  | improvements.)
  |
  |fwiw, OpenSSL documentation is pretty easy to read and to edit.  If you
  |notice that things are missing, you can edit the docs, and submit
  |patches either on this mailing list, on the rt bugtracker at
  |https://rt.openssl.org/, or as a pull request via github:
  |
  | https://github.com/openssl/openssl

 And fwiw :) i don't have a github account -- i had one but wanted
 to pay (also because they paid a developer for git(1)
 development), yet they didn't accept cash.  And i *completely*
 decline using credit cards.

Sure, you don't need a github account at all, and no credit cards are
required :)

I'm assuming you've got the git client installed on your computer
(apt-get install git or yum install git or if you're on some
platform without a package management system get it from
http://git-scm.com/).

Then, to get a copy of the development tree and see what documentation
files are present, you'd do:

  git clone https://github.com/openssl/openssl
  cd openssl/doc
  ls crypto/ ssl/

edit the documentation you want to fix, generate a patch using git
diff and send it to this list attached to an explanatory e-mail.

Regards,

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

Re: [openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k)

[Daniel Kahn Gillmor]

On Sun 2015-01-18 06:58:27 -0500, Uri Blumenthal via RT wrote:
 OpenSSL 1.0.1k and 1.0.1l. Problem: good certificates fail verification (test 
 certificate and its CA cert that illustrate the problem are attached, as well 
 as the patch/workaround).

 Here’s how the problem manifests itself:
 $ openssl version -f
 compiler: -I. -I.. -I../include  -fPIC -fno-common -DOPENSSL_PIC -DZLIB 
 -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 
 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
 -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
 -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM 
 -DGHASH_ASM
 $ openssl verify -CAfile RabbitMQ_Test_CA.pem RabbitMQ_Test.pem
 RabbitMQ_Test.pem: CN = RabbitMQ_Test, C = US
 error 7 at 0 depth lookup:certificate signature failure
 $ /usr/bin/openssl version -f
 compiler: -arch x86_64 -fmessage-length=0 -pipe -Wno-trigraphs 
 -fpascal-strings -fasm-blocks -O3 -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H 
 -DL_ENDIAN -DMD32_REG_T=int -DOPENSSL_NO_IDEA -DOPENSSL_PIC -DOPENSSL_THREADS 
 -DZLIB -mmacosx-version-min=10.6
 $ /usr/bin/openssl verify -CAfile RabbitMQ_Test_CA.pem RabbitMQ_Test.pem
 RabbitMQ_Test.pem: OK
 $ 

the version commands above don't indicate what version was tried in
each case.  I tested the verify command on 1.0.1j on debian unstable,
and found that it returns:

 RabbitMQ_Test.pem: OK

this suggests that Uri is reporting a regression in 1.0.1k and 1.0.1l.
I haven't tested those version yet.

I also tested the certificate chain with gnutls and NSS, and both seemed
to think the chain was OK.

GnuTLS 3.3.8:

1 dkg@alice:~/tmp$ cat RabbitMQ_Test.pem RabbitMQ_Test_CA.pem | certtool 
--verify-chain
Loaded 2 certificates, 1 CAs and 0 CRLs

Subject: CN=RabbitMQ_Test,C=US
Issuer: CN=RabbitMQ_Test_CA,C=US,EMAIL=mouse...@gmail.com
Checked against: CN=RabbitMQ_Test_CA,C=US,EMAIL=mouse...@gmail.com
Output: Verified. The certificate is trusted. 

Chain verification output: Verified. The certificate is trusted. 

0 dkg@alice:~/tmp$ 


NSS 3.17.2 (from an empty directory, where we're going to create an NSS
certificate db):

0 dkg@alice:/tmp/cdtemp.hknE0D$ certutil -d $(pwd) -A -n rabbitmq -t cT,,  
~/tmp/RabbitMQ_Test_CA.pem 
0 dkg@alice:/tmp/cdtemp.hknE0D$ vfychain -a -d $(pwd) -u 0 
~/tmp/RabbitMQ_Test.pem 
Chain is good!
0 dkg@alice:/tmp/cdtemp.hknE0D$ 


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

Re: [openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k)

[Daniel Kahn Gillmor via RT]

On Sun 2015-01-18 06:58:27 -0500, Uri Blumenthal via RT wrote:
 OpenSSL 1.0.1k and 1.0.1l. Problem: good certificates fail verification (test 
 certificate and its CA cert that illustrate the problem are attached, as well 
 as the patch/workaround).

 Here’s how the problem manifests itself:
 $ openssl version -f
 compiler: -I. -I.. -I../include  -fPIC -fno-common -DOPENSSL_PIC -DZLIB 
 -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 
 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
 -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
 -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM 
 -DGHASH_ASM
 $ openssl verify -CAfile RabbitMQ_Test_CA.pem RabbitMQ_Test.pem
 RabbitMQ_Test.pem: CN = RabbitMQ_Test, C = US
 error 7 at 0 depth lookup:certificate signature failure
 $ /usr/bin/openssl version -f
 compiler: -arch x86_64 -fmessage-length=0 -pipe -Wno-trigraphs 
 -fpascal-strings -fasm-blocks -O3 -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H 
 -DL_ENDIAN -DMD32_REG_T=int -DOPENSSL_NO_IDEA -DOPENSSL_PIC -DOPENSSL_THREADS 
 -DZLIB -mmacosx-version-min=10.6
 $ /usr/bin/openssl verify -CAfile RabbitMQ_Test_CA.pem RabbitMQ_Test.pem
 RabbitMQ_Test.pem: OK
 $ 

the version commands above don't indicate what version was tried in
each case.  I tested the verify command on 1.0.1j on debian unstable,
and found that it returns:

 RabbitMQ_Test.pem: OK

this suggests that Uri is reporting a regression in 1.0.1k and 1.0.1l.
I haven't tested those version yet.

I also tested the certificate chain with gnutls and NSS, and both seemed
to think the chain was OK.

GnuTLS 3.3.8:

1 dkg@alice:~/tmp$ cat RabbitMQ_Test.pem RabbitMQ_Test_CA.pem | certtool 
--verify-chain
Loaded 2 certificates, 1 CAs and 0 CRLs

Subject: CN=RabbitMQ_Test,C=US
Issuer: CN=RabbitMQ_Test_CA,C=US,EMAIL=mouse...@gmail.com
Checked against: CN=RabbitMQ_Test_CA,C=US,EMAIL=mouse...@gmail.com
Output: Verified. The certificate is trusted. 

Chain verification output: Verified. The certificate is trusted. 

0 dkg@alice:~/tmp$ 


NSS 3.17.2 (from an empty directory, where we're going to create an NSS
certificate db):

0 dkg@alice:/tmp/cdtemp.hknE0D$ certutil -d $(pwd) -A -n rabbitmq -t cT,,  
~/tmp/RabbitMQ_Test_CA.pem 
0 dkg@alice:/tmp/cdtemp.hknE0D$ vfychain -a -d $(pwd) -u 0 
~/tmp/RabbitMQ_Test.pem 
Chain is good!
0 dkg@alice:/tmp/cdtemp.hknE0D$ 


  --dkg


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

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Daniel Kahn Gillmor]

On 12/10/2014 12:59 PM, Salz, Rich via RT wrote:
 Personally i am willing to put enough trust in the OpenSSL team *even
 insofar* as i now do 'set ssl-protocol=ALL,-VULNERABLE'
 and leave the task of deciding what is VULNERABLE up to you.
 
 That is not a responsibility we want.  No how, no way.  It is enough to be 
 responsible for the code.

this is disappointing.  The OpenSSL team is in the best position to
provide sane and simple defaults/profiles, and to have those mechanisms
be upgraded smoothly without applications or admins needing to know
about them.  Requiring administrators to tweak every application that
uses TLS is a losing battle, and pretty much guarantees that we'll be
keeping users with less-secure or outdated configurations.

Programs which use the OpenSSL library generally just want to flip a
switch and know that they've turned on security, instead of trying to
expose dozens of complex controls to the user or administrator.  The
closer OpenSSL can come to that ideal, the more likely its users will
have reasonably strong crypto without having to learn the dirty dirty
details and history of TLS and its predecessors.

 There are better alternatives, including bettercrypto.org and another 
 proposal from RedHat to have site/distro-specific 'profiles' 

I am happy that both of these things exist, but they don't preclude
OpenSSL providing something and they shouldn't need to be as complex as
they are.

The configuration recommendations in bettercrypto.org are *at best* an
ugly workaround to the lack of sane and simple mechanisms in the
projects it supports.

I'd love to see a version of bettercrypto.org that only has to say to
configure OpenSSL version 1.0.3 and higher, you should use the string
BEST_PRACTICE

--dkg



signature.asc
Description: OpenPGP digital signature
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Daniel Kahn Gillmor via RT]

On 12/10/2014 12:59 PM, Salz, Rich via RT wrote:
 Personally i am willing to put enough trust in the OpenSSL team *even
 insofar* as i now do 'set ssl-protocol=ALL,-VULNERABLE'
 and leave the task of deciding what is VULNERABLE up to you.
 
 That is not a responsibility we want.  No how, no way.  It is enough to be 
 responsible for the code.

this is disappointing.  The OpenSSL team is in the best position to
provide sane and simple defaults/profiles, and to have those mechanisms
be upgraded smoothly without applications or admins needing to know
about them.  Requiring administrators to tweak every application that
uses TLS is a losing battle, and pretty much guarantees that we'll be
keeping users with less-secure or outdated configurations.

Programs which use the OpenSSL library generally just want to flip a
switch and know that they've turned on security, instead of trying to
expose dozens of complex controls to the user or administrator.  The
closer OpenSSL can come to that ideal, the more likely its users will
have reasonably strong crypto without having to learn the dirty dirty
details and history of TLS and its predecessors.

 There are better alternatives, including bettercrypto.org and another 
 proposal from RedHat to have site/distro-specific 'profiles' 

I am happy that both of these things exist, but they don't preclude
OpenSSL providing something and they shouldn't need to be as complex as
they are.

The configuration recommendations in bettercrypto.org are *at best* an
ugly workaround to the lack of sane and simple mechanisms in the
projects it supports.

I'd love to see a version of bettercrypto.org that only has to say to
configure OpenSSL version 1.0.3 and higher, you should use the string
BEST_PRACTICE

--dkg




signature.asc
Description: PGP signature
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: [PATCH] User can choose the public exponent in genrsa

[Daniel Kahn Gillmor]

On 11/14/2014 07:47 AM, Quentin Gouchet wrote:
 The user can call RSA key generation and specify the public
 exponent exp in a hexadecimal format.
 
 Example: openssl genrsa -choose 72bdf -out key.pem 4096
 Signed-off-by: Quentin quentin.gouc...@gmail.com quentin.gouc...@gmail.com


This is an interesting proposal, but i don't think it's a good idea.

 + /* Not checking whether exp = 2**16+1 since there is
 +  * no proof that small
 +  *  public exponent is a threat.
 +  *  Choosing e = 1 or e = 3 is thus possible
 +  */

This strikes me as dangerously misguided.

See section 4 of Twenty years of attacks on the RSA cryptosystem by
Dan Boneh for a description of several attacks on low public exponents:
https://crypto.stanford.edu/~dabo/pubs/papers/RSA-survey.pdf

And afaict, e = 1 is a complete disaster.

There are also more mundane problems with this patch (note that
resolving these easy problems doesn't fix the serious concerns described
above).

 * if it's going to be done, the argument should be better than -choose
-- something like -exponent would be clearer.

 * there is no patch to the genrsa manpage included

 * the value is interpreted as hexadecimal, even though other values
passed by the user to genrsa (like the number of bits) is interpreted as
decimal

--dkg



signature.asc
Description: OpenPGP digital signature

Re: [openssl.org #3203] Normalize PFS key exchange labels

[Daniel Kahn Gillmor via RT]

On Mon 2014-05-12 15:18:35 -0400, Daniel Kahn Gillmor via RT wrote:
 I'm happy that the PFS key exchange normalization changesets have been
 merged into master.

 I've submitted https://github.com/openssl/openssl/pull/106 for the 1.0.2
 stable branch to add similar aliasing for the library input strings.  This
 provides forward compatibility with any documentation produced using the
 standardized labels (DHE and ECDHE).

 Since this is on a stable branch, it doesn't change the output.

I've done the same thing now for the 1.0.1 branch, which is published
here:

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

I've also updated PR 106 to be up-to-date wth the current stable 1.0.2
branch.

I can do this for the other supported stable branches if that would be
useful.

If there's no interest in applying these changes to stable branches,
please say so.

--dkg



pgp8i7yD4qwJO.pgp
Description: PGP signature

Re: [openssl.org #3203] Normalize PFS key exchange labels

[Daniel Kahn Gillmor]

On 09/02/2014 03:34 PM, Salz, Rich wrote:
 I think there's interest for 1.0.1 and beyond.
 
 But I thought we already had a similar alias mechanism?

With the version of openssl 1.0.1i that i have in front of me, openssl
ciphers EDH succeeds, but openssl ciphers DHE fails.  So i don't
think the alias is in place.  or are you talking about some other alias
mechanism?

thanks for looking into this, Rich.

--dkg




signature.asc
Description: OpenPGP digital signature

Re: openssl 1.0.1i ignores ciphers in cipherlist

[Daniel Kahn Gillmor]

On 08/29/2014 08:16 AM, Tomas Mraz wrote:
 On Pá, 2014-08-29 at 16:19 +0200, Frank Meier wrote:
 While testing different ciphersuites I found a quite drastic change in 
 the behavior between openssl version 1.0.1h to 1.0.1i. While using a 
 cipherlist like ECDHE-RSA-AES128-SHA256:RC4 with 1.0.1h the 
 ECDHE-RSA-AES128-SHA256 cipher is used. With 1.0.1i uses RC4-SHA.

 This happens because you use specification of cipherlist that does not
 make sense - that is with the RC4 you add also SSLv2 ciphers to the
 cipher list and simultaneously you add only EC based cipher in addition.
 With SSLv2 client hello the supported curves extension cannot be sent
 and thus the EC based ciphers must not be sent as well. If there was for
 example DHE-RSA-AES128-GCM-SHA256 in the cipher list, it would be
 correctly sent in the hello and chosen for the connection. I can't see
 anyone using such specification in real world.
 
 Basically what you specify is what you get.

the CipherSuite list that Frank posted clearly indicated his preference
for ECDHE-RSA-AES128-SHA256 ahead of RC4.

By respecting the inclusion of RC4's SSLv2 ciphersuites and sending a
v2 handshake, OpenSSL is effectively disabling a higher-priority
selection.  I acknowledge that the tradeoff is a tricky one -- if
OpenSSL makes the opposite choice, it will break interop with SSLv2
servers that choke on the handshake.  But SSLv2 is known-broken,
arguably even worse than RC4.

At any rate, I'm not sure this scenario counts as what you specify is
what you get, since the OP specified that they preferred
ECDHE-RSA-AES128-SHA256 to RC4 and they didn't get it.  I'd rather that
OpenSSL respected the user's stated preference here than enable interop
with SSLv2 servers.

--dkg



signature.asc
Description: OpenPGP digital signature

Re: [openssl.org #3451] patch for x509.c

[Daniel Kahn Gillmor via RT]

On 07/16/2014 03:39 AM, Tomas Mraz via RT wrote:
 What about just supporting float number argument for -days (0.5 for 12
 hours certificate validity)? That should be fairly simple. In the first
 step. And add something like -notafter argument that would specify the
 exact end datetime in the ISO format (not duration) as a second step.

This also seems like a reasonable proposal to me.

--dkg






signature.asc
Description: PGP signature

Re: [openssl.org #3451] patch for x509.c

[Daniel Kahn Gillmor via RT]

On 07/16/2014 09:40 AM, Salz, Rich wrote:
 But then it has to be supported for, like ever. :)

do you realistically think we'll ever drop support for the -days
argument though?  Dropping -days would break a million scripts.
Extending it to support a non-integer number of days seems like a
straightforward win.

While we're at it, we could extend the -days argument to accept the
ISO-8601 duration format, distinguishing it by whether the first
character is a 'P' or not -- i don't know whether that itself is too
many variants to handle.

 If the right thing to do is the ISO format, and I strongly believe it is, 
 then we should just work toward that and not add variants to solve a 
 short-term need that will require long-term care and confusion.

Tomas' proposal was to use the ISO-8601 date format (which is much
better known than ISO-8601 duration) for a new -notafter argument that
would allow people to specify concrete end times in a standard and
well-understood fashion.

I think this is in line with the goals you describe here, no?

--dkg




signature.asc
Description: PGP signature

Re: [openssl.org #3451] patch for x509.c

[Daniel Kahn Gillmor via RT]

On 07/16/2014 11:24 AM, Salz, Rich wrote:
 do you realistically think we'll ever drop support for the -days argument
 though?  Dropping -days would break a million scripts.
 
 No, we'll never drop support for -days.  But whether the code is atoi() or 
 atof() is a big difference and might cause important silent failures for new 
 scripts running on anything other than the most recent openssl.  On most 
 systems atoi(0.5) returns 0 and no error indicator so -days 0.5 would 
 silently do the wrong thing on anything other than openssl 1.0.whatever  
 Which seems much worse.

ugh, you're quite right.  Sorry, i wasn't thinking about the support
hassle in that direction.

And to make matters worse, openssl req -x509 currently interprets
-days 0 or -days 0.5 or -days PT1800S as use the default number
of days, which is 30. :/  From experimentation, i just discovered that
-days is also happy to accept and interpret negative integer arguments
as well, resulting in a key with ValidNotBefore later than ValidNotAfter
:(  not even an error message to let you know that you've just created a
certificate that no validation stack in its right mind should ever accept.

I withdraw my support for making -days take a fractional argument, given
the behavior of the existing deployed base.

--dkg




signature.asc
Description: PGP signature

Re: openssl apps; flags, parsing dates, etc.

[Daniel Kahn Gillmor]

On 07/17/2014 12:03 AM, Viktor Dukhovni wrote:
 You've declared -days to take only positive numbers, it should
 allow negative numbers.

why?  Or at least: why accept these generally unacceptable options by
default?  I can understand wanting to be able to create perverse
certificates to test validation stacks, but i don't think that the
command line tool used by many people to create certs should be willing
to create known bad certs without explicitly overriding a warning or
something.

--dkg



signature.asc
Description: OpenPGP digital signature

Re: [openssl.org #3451] patch for x509.c

[Daniel Kahn Gillmor via RT]

On 07/15/2014 07:58 AM, Salz, Rich via RT wrote:
 The Globus syntax is strange. :)
 
 We should support the ISO date/time standard, and use that throughout and not 
 invent yet another syntax, or yet another flag.  It's fairly simple to parse, 
 and handles timezones, relative times, date/time mixing, and so on.  The XML 
 XSD spec, for example, has a reasonable explanation.

Agreed here.  also, the presence of a hyphen in a time marker is too
easily misunderstood as a minus sign.

If we're talking about the duration of a certificate, we could use
something like the ISO-8601 duration syntax:

  https://en.wikipedia.org/wiki/ISO-8601#Durations

e.g. PT1800S is 1800 seconds

--dkg




signature.asc
Description: PGP signature

Re: [openssl.org #3442] [patch] AES XTS: supporting custom iv from openssl enc command

[Daniel Kahn Gillmor via RT]

On 07/13/2014 06:33 PM, Matt Caswell via RT wrote:
 I propose the following patch to deal with this ticket (for master, 1.0.2 and
 1.0.1), i.e. disable XTS for the enc utility.
 
 Any objections?
 
 Matt
 
 diff --git a/apps/enc.c b/apps/enc.c
 index 928d16b..48f1f8b 100644
 --- a/apps/enc.c
 +++ b/apps/enc.c
 @@ -339,6 +339,12 @@ bad:
 goto end;
 }
 
 + if (cipher  (EVP_CIPHER_mode(cipher) == EVP_CIPH_XTS_MODE))
 + {
 + BIO_printf(bio_err, XTS ciphers are not supported by the enc utility\n);
 + goto end;
 + }
 +
 if (md  (dgst=EVP_get_digestbyname(md)) == NULL)
 {
 BIO_printf(bio_err,%s is an unsupported message digest type\n,md);

shouldn't the error text be ciphers in XTS mode are not supported by
the enc utility?

--dkg





signature.asc
Description: PGP signature

Re: Return codes of EC_POINT_is_at_infinity, EC_POINT_is_on_curve

[Daniel Kahn Gillmor]

On 07/11/2014 09:22 AM, balaji marisetti wrote:
 @Kyle Hamilton
 So should all the new programs stick to the idiom or check for -1 return code?

If you care about the functionality of your program, you should always
check return codes (this is not an OpenSSL specific answer).

for functions that return -1, 0, 1, the idiom cited is a bad idea.

--dkg



signature.asc
Description: OpenPGP digital signature

Re: [openssl.org #1210] Bug: CRL and Certificates

[Daniel Kahn Gillmor via RT]

On 06/30/2014 05:14 PM, Rich Salz via RT wrote:
 It's not immediately obvious, but enforcement of the keyUsage and other
 attributes is something the relying party has to do. Anything else means just
 trusting the signer, and that is not secure; how do you konw the signer is not
 cheating?

I agree with Rich that the primary requirement is on the relying party.

But OpenSSL's user-facing tools for operating a CA can also be made to
be more user-friendly, to avoid creating a CRL (or other data structure)
by default that reasonable relying parties will automatically reject.

The ability to override this default restriction would be nice too (for
those signers who actually *want* to cheat, or for the creation of
test suite material, etc, though that could be done with modified source
code for the folks who have these special needs.

I think #1210 should be reopened.

--dkg





signature.asc
Description: PGP signature

Re: Using same SSL certificat​e for Apache and socketio web server for same applicatio​n

[Daniel Kahn Gillmor]

On 05/28/2014 01:08 AM, Deepak wrote:

 I am writing an in house application where my main web server is apache 
 web server hosting the main web portal which is being accessed by HTTPS.
 
 On one of the webpage I am establishing the connection to the socketio based
 server using HTTPS again but on different port. Hostnames are same for main
 URL and socketio's URL. 
 
 If I use two different SSL certificates all goes fine. However if I try to
 use the same certificate , application is unable to connect to socket io
 server.

The two services will need to share not only the certificate but also
the secret key material that corresponds to the public key in the
certificate, right?

Is it possible that the socketio server doesn't have permission to read
the secret key that apache can read?  Or that the socketio server is
pointing to a the wrong secret key (which would be a key/certificate
mismatch)?

Is the socketio server actually running after this change?  does it have
the given port held open?  are there error log messages you can inspect
and share here?

 I want to use the same certificate for both the URLs (same host , different
 ports ). Isn't it possible ?

What you're trying to do should be possible, but i don't think you've
given enough information to figure out what the specific problem is.

hth,

--dkg



signature.asc
Description: OpenPGP digital signature

Re: Using same SSL certificat​e for Apache and socketio web server for same applicatio​n

[Daniel Kahn Gillmor]

On 05/28/2014 11:47 AM, Deepak wrote:
 Thanks for looking in.
 There are no issues with permission  or path.

This is starting to look like it might be an issue for socketio or
python stdlib folks (which provides the python ssl module), not OpenSSL.
 but looking a bit deeper:

 /nobackup/drokade/Installations/c_276/3rdparty/python2.6.1/lib/python2.6/site-packages/gevent-1.0-py2.6-linux-x86_64.egg/gevent/ssl.py,
 line 87, in __init__
 cert_reqs, ssl_version, ca_certs)
 SSLError: [Errno 336265225] _ssl.c:337: error:140B0009:SSL
 routines:SSL_CTX_use_PrivateKey_file:PEM lib
 Greenlet at 0x3585910: bound method SocketIOServer.wrap_socket_and_handle
 of SocketIOServer at 0x298e850 fileno=12 
 address=72.163.134.157:8081(socket
 at 0x35f7bd0 fileno=13 sock=72.163.134.157, ('10.65.39.87', 49851)) failed
 with SSLError

This looks like the error is happening when socketio tries to invoke
SSL_CTX_use_PrivateKey_file() (via initialization of a gevent.SSLSocket
object, which uses ssl._ssl.sslwrap() internally).

So either there actually are permission or path issues with the secret
key, or perhaps the key file is itself formatted in some odd way.

Can you try simplifying the test case by writing a simple python test
script that creates a _socket.socket, and calls ssl._ssl.sslwrap on it,
passing it the key an cert file, and running it as the user that runs
the socketio server?

--dkg




signature.asc
Description: OpenPGP digital signature

[openssl.org #3357] Fwd: PKCS12_create() default to RC2 even if compiled with -no-rc2

[Daniel Kahn Gillmor via RT]

i'm just forwarding this followup message to the relevant bug report so
that it stays tracked with it.

--dkg

Reading at previous post of Mr. Seth Schoen about using 40 bits RC2 for 
the smime utility, it comes to my mind that PKCS12_create() also default 
to RC2, even when OpenSSl is compile with -no-rc2 command line option.

I do not know what is the best solution, but I am guessing it is not as 
simple as enclosing line 99 of p12_crt.c within  #ifndef OPENSSL_NO_RC2 
or similar.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3203] Normalize PFS key exchange labels

[Daniel Kahn Gillmor]

On 05/12/2014 03:18 PM, Daniel Kahn Gillmor via RT wrote:
 I'm happy that the PFS key exchange normalization changesets haveb been
 merged into master.
 
 I've submitted https://github.com/openssl/openssl/pull/106 for the 1.0.2
 stable branch to add similar aliasing for the library input strings.  This
 provides forward compatibility with any documentation produced using the
 standardized labels (DHE and ECDHE).
 
 Since this is on a stable branch, it doesn't change the output.
 
 I considered replacing all the internal #defines to use the standardized
 labels by default within the code as well (e.g. using SSL_kDHE instead
 of SSL_kEDH everywhere internally) -- the aliases exist so the two terms
 are equivalent, and both will remain #define'd.  But i decided to leave
 the internal code as untouched as possible for the stable branch.  I'm
 happy to go through and clean up the internal uses as well if folks
 think that'd be a good idea for 1.0.2.
 
 If this patch is considered acceptable for 1.0.2, i can go back and
 create similar pull requests for the other stable branches.

Any thoughts on this?  I'd be happy to see this fixed in 1.0.1 and 1.0.0
and 0.9.8 as well, so that we can use the standard terminology on every
stable branch.

--dkg



signature.asc
Description: OpenPGP digital signature

naming inconsistency between 3DES-EDE-CBC and DES-CBC3 [Fwd: Re: [TLS] The risk of misconfiguration]

[Daniel Kahn Gillmor]

Hi OpenSSL folks--

In the message below, James Cloos points out that the OpenSSL
ciphersuite string labels are not consistent with the grouping shorthand
for DES and 3DES.

This seems similar to the situation for DHE (EDH) and ECDHE (EECDH),
which were known with incompatible/inconsistent terms across the project
UI, and were addressed in #3203 [0].

The changes would be in both input (specifying the ciphersuite
explicitly via e.g. ECDHE-ECDSA-3DES-EDE-CBC-SHA, which currently does
not work) and output (producing more well-normalized ciphersuite strings).

Changes to add aliases to the input should be backportable to all stable
versions, though i can see the argument for not backporting the changes
to the output on stable releases.

What do people think about cleaning this up?  I can try to provide
patches if folks think this is worth fixing.

--dkg

[0] https://rt.openssl.org/Ticket/Display.html?id=3203
[1]
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
---BeginMessage---
 WL == Watson Ladd watsonbl...@gmail.com writes:

WL Do you know what your TLS configurations mean? If you use OpenSSL,
WL probably not: apparently HIGH enables ADH ciphersuites. It does so
WL before permitting AES128 with an authenticated ECDHE exchange. Sorting
WL by strength puts DES ahead of AES128: I've got no idea how that
WL happened. (Yes, DES: 3DES is indicated differently. Maybe it is really
WL 3DES, but even so...).

With openssl-1.1g, I see no DES from HIGH, only 3DES.

But you have to look carefully to realise that.  The SRP and PSK suites
which match the regex /DES/ use CBC3 to specify triple des; all other
openssl suites which match /DES/ use 3DES to specify triple des.

Gnutls, OTOH, always uses 3DES_EDE_CBC for the suites, and 3DES-CBC for
the cipher.

NSS’s tstclnt uses single-letter flags rather than names, but documents
the triple des options with EDE3 for the ssl2 suite and 3DES for the ssl3
suites it supports.

-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6

___
TLS mailing list
t...@ietf.org
https://www.ietf.org/mailman/listinfo/tls
---End Message---


signature.asc
Description: OpenPGP digital signature

Re: [openssl.org #3203] Normalize PFS key exchange labels

[Daniel Kahn Gillmor via RT]

I'm happy that the PFS key exchange normalization changesets haveb been
merged into master.

I've submitted https://github.com/openssl/openssl/pull/106 for the 1.0.2
stable branch to add similar aliasing for the library input strings.  This
provides forward compatibility with any documentation produced using the
standardized labels (DHE and ECDHE).

Since this is on a stable branch, it doesn't change the output.

I considered replacing all the internal #defines to use the standardized
labels by default within the code as well (e.g. using SSL_kDHE instead
of SSL_kEDH everywhere internally) -- the aliases exist so the two terms
are equivalent, and both will remain #define'd.  But i decided to leave
the internal code as untouched as possible for the stable branch.  I'm
happy to go through and clean up the internal uses as well if folks
think that'd be a good idea for 1.0.2.

If this patch is considered acceptable for 1.0.2, i can go back and
create similar pull requests for the other stable branches.

   --dkg



pgptsjDwMy7Sz.pgp
Description: PGP signature

Re: [RFC PATCH] s_client/s_server: support unix domain sockets

[Daniel Kahn Gillmor]

On 05/06/2014 10:34 PM, Geoff Thorpe wrote:
 The -unix path argument allows s_server and s_client to use a unix
 domain socket in the filesystem instead of IPv4 (-connect, -port,
 -accept, etc). If s_server exits gracefully, such as when -naccept
 is used and the requested number of SSL/TLS connections have occurred,
 then the domain socket file is removed. On ctrl-C, it is likely that
 the stale socket file will be left over, such that s_server would
 normally fail to restart with the same arguments. For this reason,
 s_server also supports an -unlink option, which will clean up any
 stale socket file before starting.
 
 If you have any reason to want encrypted IPC within an O/S instance,
 this concept might come in handy. Otherwise it just demonstrates that
 there is nothing about SSL/TLS that limits it to TCP/IP in any way.
 
 (There might also be benchmarking and profiling use in this path, as
 unix domain sockets are much lower overhead than connecting over local
 IP addresses).
 
 Signed-off-by: Geoff Thorpe ge...@openssl.org
 ---
 
  This is just a request for comments. Anyone think this is worth
  putting in? Eg.

I think having unix-domain sockets available in s_client/s_server is a
great idea.

Heading in this direction of generic abstractions, it could also be nice
to enable s_client and s_server just use an arbitrary file descriptor.

This would enable, for example, a privileged process to open a
restricted port, drop privileges, and then exec s_server with the
appropriate argument for what file descriptor to use.

--dkg



signature.asc
Description: OpenPGP digital signature

Re: Start Contributing

[Daniel Kahn Gillmor]

On 04/23/2014 04:52 PM, Matt Caswell wrote:
 I am actively seeking people to help out on the OpenSSL Wiki.
 Documentation is an area where OpenSSL has frequently been criticized
 in the past and is an area where we can do something about it NOW.

fwiw, i actually don't think that a wiki is going to improve the places
where OpenSSL  documentation is legitimately criticized.

historically, OpenSSL documentation (e.g. manual pages, etc) has
seriously lagged its implementation, and has in some cases been simply
wrong.  Updates to the wiki won't improve the quality of documentation
shipped with the library, which will always seem more authoritative
(because it ships with the specific version of the software that is
installed; advice found on the web may be either older or newer than the
local version)

A serious way to fix this is to have the documentation produced *from*
the code, so that it gets upgraded in sync.  For example, neither
x509(1ssl) nor openssl x509 -help ever mention the -sha256 option,
but that option has been supported for years.

--dkg



signature.asc
Description: OpenPGP digital signature

Re: Improving OpenSSL documentation

[Daniel Kahn Gillmor]

On 04/23/2014 09:50 PM, Viktor Dukhovni wrote:
 On Wed, Apr 23, 2014 at 07:21:23PM -0400, Daniel Kahn Gillmor wrote:
 
 A serious way to fix this is to have the documentation produced *from*
 the code, so that it gets upgraded in sync.  For example, neither
 x509(1ssl) nor openssl x509 -help ever mention the -sha256 option,
 but that option has been supported for years.
 
 No, that won't work well.

out of curiosity, why not?  At the very least the output of openssl
x509 -help should be derived from the same code that actually parses
the openssl x509 command-line options.  shouldn't these be able to be
kept in sync within the code?

 A more serious way to fix this is to
 reject features or patches (no matter how appealing) that extend
 or modify functionality without corresponding documentation changes.

It's easy to know reject a patch because it has no documentation
changes.  I agree that would be a good policy, worth implementing and
abiding by.

But it's much harder to know that *all relevant documentation* has been
properly updated, especially with a project that covers as much ground
as OpenSSL does.

If the bulk of the relevant documentation was all very close to the code
(e.g. like doxygen or other structured formats automatically
extractable), i think it would make it easier to find most of it and
make sure that changes also include changes to the relevant documentation.

 Plus a parallel effort to backfill the documentation gaps and errors.

Looking at the size of the documentation overall, this is a *lot* of
work.  Is anyone interested in organizing a documentation sprint to do
this kind of backfill labor in an organized and complete way?

 A tiny contribution below:
 
 diff --git a/doc/apps/req.pod b/doc/apps/req.pod
 index 51d3083..151fe8f 100644
 --- a/doc/apps/req.pod
 +++ b/doc/apps/req.pod
 @@ -490,7 +490,7 @@ be input by calling it 1.organizationName.
  The actual permitted field names are any object identifier short or
  long names. These are compiled into OpenSSL and include the usual
  values such as commonName, countryName, localityName, organizationName,
 -organizationUnitName, stateOrProvinceName. Additionally emailAddress
 +organizationalUnitName, stateOrProvinceName. Additionally emailAddress
  is include as well as name, surname, givenName initials and dnQualifier.
  
  Additional object identifiers can be defined with the Boid_file or

thanks for this fix!  I've just submitted it via github as:

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

--dkg



signature.asc
Description: OpenPGP digital signature

Re: SSL vs. SSH in the context of CVE 2014-0160

[Daniel Kahn Gillmor]

On 04/08/2014 11:08 PM, Chris Hill wrote:
 SSH and SSL/TLS are simply different protocols (doh). They may share some
 similar underlying crypto implementations, but as of their respective RFCs,
 they are just different protocols. The TLS Heartbeat TLS extension would
 not apply to SSH. 

The above is correct.

 SSH may have its own way to keep alive, but that would
 be a different implementation altogether.

SSH does indeed have its own keepalive.  Search for ServerAlive in
ssh_config(5) and ClientAlive in sshd_config(5) if you want details.  It
is an entirely different mechanism from (D)TLS heartbeat.

hope this helps,

--dkg



signature.asc
Description: OpenPGP digital signature

Re: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient

[Daniel Kahn Gillmor]

On 03/30/2014 03:39 PM, Viktor Dukhovni wrote:
 On Sun, Mar 30, 2014 at 11:20:51AM +0200, Steffen Ullrich via RT wrote:

 - probably useful: while no RFC currently forbids something like *.com you
   have a check to disallow wildcards in the two rightmost suffixes. I think
   it makes sense to have that, although it is not sufficient (e.g. *.co.uk
   should also not be allowed). But doing this 100% correct will be tricky,
   because there is currently no definition of correct behavior in this area:
   While chrome disallows *.co.uk firefox allows it.
 
 Such a policy would be too complex for OpenSSL, and will be even
 more complex to get right once all the new TLDs ICANN is blessing
 us with come online.

I think the current best approach to this is the public suffix list,
http://publicsuffix.org/ it's a horrible kludge (a fully-enumerated list
of all zones that are known to allow registration of sub-zones to the
public), but it's better than just counting labels.

there are a few C libraries that could be used to make this abstraction
available to OpenSSL (if building against external libraries is OK)
without requiring much extra work in OpenSSL itself.

--dkg



signature.asc
Description: OpenPGP digital signature

[openssl.org #3280] [PATCH] avoid perl deprecation warnings when updating error codes

[Daniel Kahn Gillmor via RT]

defined(@array) is deprecated at ./util/mkerr.pl line 792.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at ./util/mkerr.pl line 800.
(Maybe you should just omit the defined()?)
---
 util/mkerr.pl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/util/mkerr.pl b/util/mkerr.pl
index 49a52a7..b726282 100644
--- a/util/mkerr.pl
+++ b/util/mkerr.pl
@@ -789,7 +789,7 @@ foreach (keys %rcodes) {
push (@runref, $_) unless exists $urcodes{$_};
 }
 
-if($debug  defined(@funref) ) {
+if($debug  @funref ) {
print STDERR The following function codes were not referenced:\n;
foreach(sort @funref)
{
@@ -797,7 +797,7 @@ if($debug  defined(@funref) ) {
}
 }
 
-if($debug  defined(@runref) ) {
+if($debug  @runref ) {
print STDERR The following reason codes were not referenced:\n;
foreach(sort @runref)
{
-- 
1.9.0

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[PATCH] [openssl.org #3120] Reject DHE groups with 1024-bits

[Daniel Kahn Gillmor via RT]

This is a hard-coded patch to make OpenSSL clients reject connections
which use DHE handshakes with  1024 bits.

This patch has no compile-time or runtime configurability.  If the
project wants something more nuanced, we need discussion about what
the right form(s) of configurability should be.

Note that ssltest has also been changed to default to a 1024-bit
(instead of 512-bit) safe-prime DHE so that tests all pass
---
 ssl/s3_clnt.c |  5 +
 ssl/ssl.h |  1 +
 ssl/ssl_err.c |  3 ++-
 ssl/ssltest.c | 13 +++--
 4 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/ssl/s3_clnt.c b/ssl/s3_clnt.c
index 9755a0f..7f0d14a 100644
--- a/ssl/s3_clnt.c
+++ b/ssl/s3_clnt.c
@@ -2635,6 +2635,11 @@ int ssl3_send_client_key_exchange(SSL *s)
else
{
/* generate a new random key */
+   if (DH_size(dh_srvr)  1024/8)
+   {
+   
SSLerr(SSL_F_SSL3_SEND_CLIENT_KEY_EXCHANGE,SSL_R_BAD_DH_WEAK_GROUP);
+   goto err;
+   }
if ((dh_clnt=DHparams_dup(dh_srvr)) == NULL)
{

SSLerr(SSL_F_SSL3_SEND_CLIENT_KEY_EXCHANGE,ERR_R_DH_LIB);
diff --git a/ssl/ssl.h b/ssl/ssl.h
index c6cd6a9..8bcd7ca 100644
--- a/ssl/ssl.h
+++ b/ssl/ssl.h
@@ -2826,6 +2826,7 @@ void ERR_load_SSL_strings(void);
 #define SSL_R_BAD_DH_G_LENGTH   108
 #define SSL_R_BAD_DH_PUB_KEY_LENGTH 109
 #define SSL_R_BAD_DH_P_LENGTH   110
+#define SSL_R_BAD_DH_WEAK_GROUP 394
 #define SSL_R_BAD_DIGEST_LENGTH 111
 #define SSL_R_BAD_DSA_SIGNATURE 112
 #define SSL_R_BAD_ECC_CERT  304
diff --git a/ssl/ssl_err.c b/ssl/ssl_err.c
index e663483..24bc75c 100644
--- a/ssl/ssl_err.c
+++ b/ssl/ssl_err.c
@@ -1,6 +1,6 @@
 /* ssl/ssl_err.c */
 /* 
- * Copyright (c) 1999-2013 The OpenSSL Project.  All rights reserved.
+ * Copyright (c) 1999-2014 The OpenSSL Project.  All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -327,6 +327,7 @@ static ERR_STRING_DATA SSL_str_reasons[]=
 {ERR_REASON(SSL_R_BAD_DH_G_LENGTH)   ,bad dh g length},
 {ERR_REASON(SSL_R_BAD_DH_PUB_KEY_LENGTH) ,bad dh pub key length},
 {ERR_REASON(SSL_R_BAD_DH_P_LENGTH)   ,bad dh p length},
+{ERR_REASON(SSL_R_BAD_DH_WEAK_GROUP) ,bad dh weak group},
 {ERR_REASON(SSL_R_BAD_DIGEST_LENGTH) ,bad digest length},
 {ERR_REASON(SSL_R_BAD_DSA_SIGNATURE) ,bad dsa signature},
 {ERR_REASON(SSL_R_BAD_ECC_CERT)  ,bad ecc cert},
diff --git a/ssl/ssltest.c b/ssl/ssltest.c
index 64c6743..809abf3 100644
--- a/ssl/ssltest.c
+++ b/ssl/ssltest.c
@@ -870,7 +870,8 @@ static void sv_usage(void)
fprintf(stderr, -num val- number of connections to perform\n);
fprintf(stderr, -bytes val  - number of bytes to swap between 
client/server\n);
 #ifndef OPENSSL_NO_DH
-   fprintf(stderr, -dhe1024  - use 1024 bit key (safe prime) for 
DHE\n);
+   fprintf(stderr, -dhe512   - use 512 bit key (safe prime) for 
DHE\n);
+   fprintf(stderr, -dhe1024  - use 1024 bit key (safe prime) for DHE 
(default)\n);
fprintf(stderr, -dhe1024dsa   - use 1024 bit key (with 160-bit 
subprime) for DHE\n);
fprintf(stderr, -no_dhe   - disable DHE\n);
 #endif
@@ -1079,7 +1080,7 @@ int main(int argc, char *argv[])
long bytes=256L;
 #ifndef OPENSSL_NO_DH
DH *dh;
-   int dhe1024 = 0, dhe1024dsa = 0;
+   int dhe1024 = 1, dhe1024dsa = 0;
 #endif
 #ifndef OPENSSL_NO_ECDH
EC_KEY *ecdh = NULL;
@@ -1164,6 +1165,14 @@ int main(int argc, char *argv[])
debug=1;
else if (strcmp(*argv,-reuse) == 0)
reuse=1;
+   else if (strcmp(*argv,-dhe512) == 0)
+   {
+#ifndef OPENSSL_NO_DH
+   dhe1024=0;
+#else
+   fprintf(stderr,ignoring -dhe512, since I'm compiled 
without DH\n);
+#endif
+   }
else if (strcmp(*argv,-dhe1024) == 0)
{
 #ifndef OPENSSL_NO_DH
-- 
1.9.0


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Filter short DH key sizes?

[Daniel Kahn Gillmor]

On 03/13/2014 06:33 AM, Hanno Böck wrote:

 I recently had a look at how browsers react to DH key exchanges with
 bogus modulus values. here's what I found:
 http://blog.hboeck.de/archives/841-Diffie-Hellman-and-TLS-with-nonsense-parameters.html
 
 And here is a test (warning: crashes some chrome/chromium versions)
 https://dh.tlsfun.de/
 
 I wanted to bring this up here, because some openssl-based browser
 accept just about anything for the DH prime setting (including
 completely bogus values like 15).

thanks for raising this again, Hanno.  I agree that this is a concern.

 NSS seems to filter very small values (below 512). I wonder if I should
 report this to the browsers or if this is something openssl should fix.
 
 My suggestion would be that openssl as a client just rejects all DH
 parameters below 1024 bit. (I'd like to say reject below 2048, but I
 know that's not feasible - at least not today)

https://rt.openssl.org/Ticket/Display.html?id=3120  (from August 31st of
last year) has the same suggestion.  Speaking with folks at the Real
World Crypto conference in January 2014, the consensus was that a limit
of 512-bits was far too low.

I agree that a minimum of 1024 bits for the client is a good idea
(though still rather weak and also overdue).  The question is whether
there should be any additional API or compile-time option to set or
adjust or remove these limits.

In theory, users of OpenSSL as a TLS client are already able to query
the size of the DH key exchange for any given connection, and can choose
to terminate it if they object to the size of the group (or any other
properties of the group).

But in practice most clients don't, and expecting every client to know
enough and be prudent enough to manage this is unrealistic, so having a
safe default in openssl is a good idea.

I've sent a patch to #3120 without any compile-time or run-time
configurability, just a hard-coded limit.  I'm open to discussion about
ways to add configurability or better ways to dynamically select a
plausible limit.

--dkg
commit 04b8b7fbc84d1a28a43a86288d5216d794110a5e
Author: Daniel Kahn Gillmor d...@fifthhorseman.net
Date:   Thu Mar 13 13:23:50 2014 -0400

Reject DHE groups with  1024-bits

This is a hard-coded patch without any compile-time or runtime
configurability.  If the project wants something more nuanced, we need
discussion about what the right form(s) of configurability should be.

note that ssltest has also been changed to default to a 1024-bit
(instead of 512-bit) safe-prime DHE.

diff --git a/ssl/s3_clnt.c b/ssl/s3_clnt.c
index 9755a0f..7f0d14a 100644
--- a/ssl/s3_clnt.c
+++ b/ssl/s3_clnt.c
@@ -2635,6 +2635,11 @@ int ssl3_send_client_key_exchange(SSL *s)
 			else
 {
 /* generate a new random key */
+if (DH_size(dh_srvr)  1024/8)
+	{
+	SSLerr(SSL_F_SSL3_SEND_CLIENT_KEY_EXCHANGE,SSL_R_BAD_DH_WEAK_GROUP);
+	goto err;
+	}
 if ((dh_clnt=DHparams_dup(dh_srvr)) == NULL)
 	{
 	SSLerr(SSL_F_SSL3_SEND_CLIENT_KEY_EXCHANGE,ERR_R_DH_LIB);
diff --git a/ssl/ssl.h b/ssl/ssl.h
index c6cd6a9..8bcd7ca 100644
--- a/ssl/ssl.h
+++ b/ssl/ssl.h
@@ -2826,6 +2826,7 @@ void ERR_load_SSL_strings(void);
 #define SSL_R_BAD_DH_G_LENGTH 108
 #define SSL_R_BAD_DH_PUB_KEY_LENGTH			 109
 #define SSL_R_BAD_DH_P_LENGTH 110
+#define SSL_R_BAD_DH_WEAK_GROUP 394
 #define SSL_R_BAD_DIGEST_LENGTH 111
 #define SSL_R_BAD_DSA_SIGNATURE 112
 #define SSL_R_BAD_ECC_CERT 304
diff --git a/ssl/ssl_err.c b/ssl/ssl_err.c
index e663483..24bc75c 100644
--- a/ssl/ssl_err.c
+++ b/ssl/ssl_err.c
@@ -1,6 +1,6 @@
 /* ssl/ssl_err.c */
 /* 
- * Copyright (c) 1999-2013 The OpenSSL Project.  All rights reserved.
+ * Copyright (c) 1999-2014 The OpenSSL Project.  All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -327,6 +327,7 @@ static ERR_STRING_DATA SSL_str_reasons[]=
 {ERR_REASON(SSL_R_BAD_DH_G_LENGTH)   ,bad dh g length},
 {ERR_REASON(SSL_R_BAD_DH_PUB_KEY_LENGTH) ,bad dh pub key length},
 {ERR_REASON(SSL_R_BAD_DH_P_LENGTH)   ,bad dh p length},
+{ERR_REASON(SSL_R_BAD_DH_WEAK_GROUP) ,bad dh weak group},
 {ERR_REASON(SSL_R_BAD_DIGEST_LENGTH) ,bad digest length},
 {ERR_REASON(SSL_R_BAD_DSA_SIGNATURE) ,bad dsa signature},
 {ERR_REASON(SSL_R_BAD_ECC_CERT)  ,bad ecc cert},
diff --git a/ssl/ssltest.c b/ssl/ssltest.c
index 64c6743..809abf3 100644
--- a/ssl/ssltest.c
+++ b/ssl/ssltest.c
@@ -870,7 +870,8 @@ static void sv_usage(void)
 	fprintf(stderr, -num val- number of connections to perform\n);
 	fprintf(stderr, -bytes val  - number of bytes to swap between client/server\n);
 #ifndef OPENSSL_NO_DH
-	fprintf(stderr, -dhe1024  - use 1024 bit key (safe prime) for DHE\n);
+	fprintf(stderr, -dhe512   - use 512 bit key (safe prime) for DHE\n

Re: Filter short DH key sizes?

[Daniel Kahn Gillmor]

On 03/13/2014 04:05 PM, Kurt Roeckx wrote:
 On Thu, Mar 13, 2014 at 03:13:01PM -0400, Daniel Kahn Gillmor wrote:
 In theory, users of OpenSSL as a TLS client are already able to query
 the size of the DH key exchange for any given connection, and can choose
 to terminate it if they object to the size of the group (or any other
 properties of the group).
 
 Last time I looked this information is in an internal structure
 not exposed to the client.

hm, i also never figured out how a client is could possibly do it, which
suggests even more strongly that OpenSSL is failing to keep its users
secure.

But even if it turns out that there is some way that the client can get
to this information (as there is in other libraries, e.g.
gnutls_dh_get_prime_bits()), i don't think we can or should expect each
application to do this for each connection.  OpenSSL needs to default to
a mode where the connection is secure, and only move out of that if the
user or application explicitly loosens the security along some specific
axis (e.g. an SMTP daemon explicitly enabling anonymous ciphersuites as
discussed in the TLS WG right now).

--dkg





signature.asc
Description: OpenPGP digital signature

Re: [openssl.org #3120] Minimum size of DH

[Daniel Kahn Gillmor via RT]

On 03/13/2014 05:52 PM, Stephen Henson via RT wrote:
 I should've commented on this before, sorry. I'm currently working on a
 framework where several security parameters can be configured at both compile
 time and runtime, including DH parameter sizes. It's still under development 
 at
 present though. I'll commit it to the master branch when it's more stable.

Are those changes published on a git branch anywhere?  if not, is there
a reason to avoid publishing them?  you might get more feedback (and
review, and patches) if the work is more visible.

--dkg





signature.asc
Description: PGP signature

Re: Diffie Hellman question

[Daniel Kahn Gillmor]

On 02/11/2014 09:19 AM, Leon Brits wrote:

 In a test I have three DH key pairs generated from the IKE groups 14,15 and 
 16 paramters.
 [...]
 It seems the private key must be the same or larger to succeed.
 Is this correct: Can the public key not be larger than the private key?

There shouldn't be any such requirement.  If anything, i'd expect the
requirement to work the other way around, since there are some popular
DH key agreement schemes that encourage the use of short secret keys
(short exponents), e.g. SSH [0]

Can you provide the source for the problem that you're running into?
maybe there are other problems with it that someone on the list could
identify.

--dkg

[0] https://tools.ietf.org/html/rfc4419#section-6.2




signature.asc
Description: OpenPGP digital signature

Re: Requirements/Steps to add serpent to openssl

[Daniel Kahn Gillmor]

On 02/10/2014 08:35 AM, Dmitry Belyavsky wrote:

 Could you explain what is serpent and what do you want from addition
 serpent to openssl?

I suspect that Shady is asking for the Serpent block cipher, which was
one of the AES finalists:

  https://en.wikipedia.org/wiki/Serpent_%28cipher%29

You can find an implementation of it in the linux kernel, among other
places.

--dkg



signature.asc
Description: OpenPGP digital signature

Re: [openssl.org #3203] Normalize PFS key exchange labels

[Daniel Kahn Gillmor via RT]

Hi Stephen--

On Thu 2014-01-02 16:36:39 -0500, Stephen Henson via RT wrote:
 On Mon Dec 30 22:47:32 2013, d...@fifthhorseman.net wrote:

 I don't mean to be impatient -- if it's just a matter of playing catchup
 over the close of the winter holiday, i can wait :)

 Yes that's pretty much it. I'll be looking reviewing the patches in the next
 few days.

This is a ping to see if there is anything holding up the patchsets for
normalizing PFS key exchange labels on the master branch.  If there's
anything that seems wrong with the series, or additional work needed to
make it acceptable or more attractive for inclusion, please let me know.

Regards,

--dkg


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3203] Normalize PFS key exchange labels

[Daniel Kahn Gillmor]

On 01/19/2014 11:40 AM, Dr. Stephen Henson wrote:
 On Sun, Jan 19, 2014, Daniel Kahn Gillmor via RT wrote:
 This is a ping to see if there is anything holding up the patchsets for
 normalizing PFS key exchange labels on the master branch.  If there's
 anything that seems wrong with the series, or additional work needed to
 make it acceptable or more attractive for inclusion, please let me know.
 
 They've been committed to the master branch.

thanks, i see them now.  Should I expect this label normalization to be
merged into 1.0.2 before it is released, or is this scheduled for some
future future release (e.g. 1.1.0)?

aside from 1.0.2, i'd like to offer this label normalization on the
stable branches as well, if possible, so that any updated documentation,
code, and recommendations can make use of them even on systems that
track a stable branch of OpenSSL.

Presumably, this would mean that the patchsets for already-released
stable branches would add the input aliases, but would *not* modify the
output in the two relevant places (full ciphersuite names with EDH in
them, and packet tracing output).  So that both openssl's input and
output would change for new full releases, but the input aliases would
be available on any new stable revision.

Does this sound reasonable?  If so, i'm happy to propose a modified
series that applies to OpenSSL_1_0_1-stable, for starters.

If you think i'm misunderstanding the OpenSSL release process, i'd be
very happy to get constructive feedback or pointers to documentation
that would help me understand it better.

Regards,

--dkg



signature.asc
Description: OpenPGP digital signature

Re: [openssl.org #3203] Normalize PFS key exchange labels

[Daniel Kahn Gillmor]

On 01/19/2014 01:34 PM, Dr. Stephen Henson wrote:
 A brief description of the versioning scheme is at:
 
 http://www.openssl.org/support/faq.html#MISC8

thanks, this is useful.  However, the changes i'm proposing don't seem
to fall neatly into the categories of new feature or API change or
ABI change or bug fix.

I'd argue that the closest they come is security fix because they
provide coherent mechanisms to identify specific security parameters to
the library.  If people write security configuration guides, those
guides will make more sense if they can apply to all current releases,
stable or bleeding-edge.  Is that plausible?

I'm attaching a single collapsed patch for the 1.0.1 stable branch that
just adds a minimal aliases without changing internal code or modifying
output.

That patch is also now at:

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

If this makes sense to you, i'm happy to craft and test and submit
similar patches for whatever other stable branches you would like to see
covered.

I'm still unclear on whether you think the full range of changes
(including output changes) should make it into 1.0.2, or whether we
should stick to just the aliases in that case.

Let me know what next steps would be most helpful.

Regards,

--dkg
From 3bb46e4bd4fa718131ad994bfad001626a5f79f2 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor d...@fifthhorseman.net
Date: Thu, 19 Dec 2013 13:18:30 -0500
Subject: [PATCH] Allow ECDHE and DHE as forward-compatible aliases for EECDH
 and EDH

see PR #3203

Future versions of OpenSSL use the canonical terms ECDHE and DHE
as configuration strings and compilation constants.  This patch
introduces aliases so that the stable 1.0.1 branch can be
forward-compatible with code and configuration scripts that use the
normalized terms, while avoiding changing any library output for
stable users.
---
 doc/apps/ciphers.pod | 26 +-
 doc/ssl/SSL_CTX_set_cipher_list.pod  |  2 +-
 doc/ssl/SSL_CTX_set_options.pod  |  2 +-
 doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod |  2 +-
 doc/ssleay.txt   |  2 +-
 ssl/ssl.h|  4 
 ssl/ssl3.h   | 17 +
 ssl/ssl_ciph.c   | 17 +
 ssl/ssl_locl.h   |  2 ++
 ssl/tls1.h   | 12 ++--
 10 files changed, 63 insertions(+), 23 deletions(-)

diff --git a/doc/apps/ciphers.pod b/doc/apps/ciphers.pod
index f44aa00..07058fb 100644
--- a/doc/apps/ciphers.pod
+++ b/doc/apps/ciphers.pod
@@ -172,7 +172,7 @@ attack and so their use is normally discouraged.
 
 cipher suites using RSA key exchange.
 
-=item BkEDH
+=item BkDHE
 
 cipher suites using ephemeral DH key agreement.
 
@@ -306,12 +306,12 @@ e.g. DES-CBC3-SHA. In these cases, RSA authentication is used.
  SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHANot implemented.
  SSL_DH_RSA_WITH_DES_CBC_SHA Not implemented.
  SSL_DH_RSA_WITH_3DES_EDE_CBC_SHANot implemented.
- SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA   EXP-EDH-DSS-DES-CBC-SHA
- SSL_DHE_DSS_WITH_DES_CBC_SHAEDH-DSS-CBC-SHA
- SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA   EDH-DSS-DES-CBC3-SHA
- SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA   EXP-EDH-RSA-DES-CBC-SHA
- SSL_DHE_RSA_WITH_DES_CBC_SHAEDH-RSA-DES-CBC-SHA
- SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA   EDH-RSA-DES-CBC3-SHA
+ SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA   EXP-DHE-DSS-DES-CBC-SHA
+ SSL_DHE_DSS_WITH_DES_CBC_SHADHE-DSS-CBC-SHA
+ SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA   DHE-DSS-DES-CBC3-SHA
+ SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA   EXP-DHE-RSA-DES-CBC-SHA
+ SSL_DHE_RSA_WITH_DES_CBC_SHADHE-RSA-DES-CBC-SHA
+ SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA   DHE-RSA-DES-CBC3-SHA
 
  SSL_DH_anon_EXPORT_WITH_RC4_40_MD5  EXP-ADH-RC4-MD5
  SSL_DH_anon_WITH_RC4_128_MD5ADH-RC4-MD5
@@ -342,12 +342,12 @@ e.g. DES-CBC3-SHA. In these cases, RSA authentication is used.
  TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHANot implemented.
  TLS_DH_RSA_WITH_DES_CBC_SHA Not implemented.
  TLS_DH_RSA_WITH_3DES_EDE_CBC_SHANot implemented.
- TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA   EXP-EDH-DSS-DES-CBC-SHA
- TLS_DHE_DSS_WITH_DES_CBC_SHAEDH-DSS-CBC-SHA
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA   EDH-DSS-DES-CBC3-SHA
- TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA   EXP-EDH-RSA-DES-CBC-SHA
- TLS_DHE_RSA_WITH_DES_CBC_SHAEDH-RSA-DES-CBC-SHA
- TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA   EDH-RSA-DES-CBC3-SHA
+ TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA   EXP-DHE-DSS-DES-CBC-SHA
+ TLS_DHE_DSS_WITH_DES_CBC_SHADHE-DSS-CBC-SHA
+ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA   DHE-DSS-DES-CBC3-SHA
+ TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA   EXP-DHE-RSA-DES-CBC-SHA
+ TLS_DHE_RSA_WITH_DES_CBC_SHADHE-RSA-DES-CBC-SHA
+ TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA   DHE-RSA-DES-CBC3-SHA

Re: [openssl.org #3236] support for DNSSEC in openssl

[Daniel Kahn Gillmor]

On 01/13/2014 11:26 AM, Elmar Stellnberger via RT wrote:
 Webkit browsers and many other openssl based programs like ssh  would already 
 like to make use of DNSSEC. AFAIK DNSSEC has already been standardized and 
 would therefore be free to be implemented by openssl. DNSSEC could overcome 
 many of the weaknesses in the current certificate management workflow.

DNSSEC on its own seems unlikely to fix any problems in certificate
management.

DNSSEC coupled with some of the DANE proposals seems more likely to be
able to provide augmented verification mechanisms for X.509 certificates
encountered by OpenSSL.  However, please don't think that DANE will
solve the problem of certificate validation entirely; it just moves the
problem into the DNS, which powerful attackers have already shown
willingness to compromise directly.

I'm not saying DANE is a bad idea, but it is not a silver bullet.

--dkg



signature.asc
Description: OpenPGP digital signature

Re: OpenSSL version 1.0.1f released

[Daniel Kahn Gillmor]

On 01/06/2014 09:49 AM, OpenSSL wrote:

OpenSSL version 1.0.1f released
===
 [...]
The OpenSSL project team is pleased to announce the release of
version 1.0.1f of our open source toolkit for SSL/TLS. For details
of changes and known issues see the release notes at:
 
 http://www.openssl.org/news/openssl-1.0.1-notes.html

Looking at the source on github, i see that Nick Mathewson's
no_gmt_unix_time branch was also merged between 1.0.1e and 1.0.1f, but
it is not mentioned in the release notes.

I fully support the draft that recommends this change:

 https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime-00

but i also think it's a potentially significant change that is worth
acknowledging publicly (it breaks at least tlsdate -- i don't know about
other systems that rely on this).

as an aside, the commit message of
2583270191a8b27eed303c03ece1da97b9b69fd3 appears to be misleading.  it says:

Control sending time with SSL_SEND_{CLIENT,SERVER}RANDOM_MODE

but the code change indicates that the config flag is named
SSL_MODE_SEND_{CLIENT,SERVER}HELLO_TIME, which has the opposite sense
from the commit message's implication.

Thanks for taking this step to minimize data leakage from TLS clients
and servers!

Regards,

--dkg



signature.asc
Description: OpenPGP digital signature

Re: Safe ECC curves

[Daniel Kahn Gillmor]

On 01/02/2014 12:35 PM, Dr. Stephen Henson wrote:
 That's just TLS. To add more complete support to OpenSSL including storing
 private keys in PEM files and public keys in case we ever use it in ECDH
 certificates it needs an OID and some details on how the keys are encoded.

But ECDHE doesn't need any of these trappings, as nice as they would be
to have.  The curves are known; implementations of them are known;
secret keys can be held in memory in any standard way, and public keys
can be transmitted on the wire for the key exchange as simply as
possible, without specifying PKCS encodings or SPKI or whatever.

Getting Curve25519 (and Curve3617?) functional for ECDHE would be a
demonstrably good thing on its own, and it would be a shame for that
functionality to wait until people could finally agree on how to use
PKCS encodings and EdDSA for X.509 certificates.

--dkg



signature.asc
Description: OpenPGP digital signature

Re: [openssl.org #3203] Normalize PFS key exchange labels

[Daniel Kahn Gillmor]

On 01/02/2014 03:32 PM, Ben Laurie wrote:
 On 1 January 2014 21:39, Daniel Kahn Gillmor d...@fifthhorseman.net wrote:
 On 01/01/2014 12:48 PM, Ben Laurie wrote:
 Pull requests on Github are quite useful - that way they also get
 tracked (so long as we remember to close them when applied, that is!).

 OK, i've rebased the series against the current master, and submitted a
 github-specific pull request:

  https://github.com/openssl/openssl/pull/37
 
 Cool, tho didn't I read that Steve already pulled it?

I read that as well, but I assumed that just meant that he now has
access to the changesets in his local copy.  I don't think he's applied
them to his master branch, or if he has, he hasn't pushed that master
branch to the canonical repository.  or maybe i'm not looking at the
correct repository?

i don't see them applied to the master branch at
https://github.com/openssl/openssl, and i don't see them at
http://git.openssl.org/gitweb/?p=openssl.git;a=summary should i be
looking somewhere else?

--dkg



signature.asc
Description: OpenPGP digital signature

Re: [openssl.org #3203] Normalize PFS key exchange labels

[Daniel Kahn Gillmor via RT]

On 01/02/2014 03:32 PM, Ben Laurie wrote:
 On 1 January 2014 21:39, Daniel Kahn Gillmor d...@fifthhorseman.net wrote:
 On 01/01/2014 12:48 PM, Ben Laurie wrote:
 Pull requests on Github are quite useful - that way they also get
 tracked (so long as we remember to close them when applied, that is!).

 OK, i've rebased the series against the current master, and submitted a
 github-specific pull request:

  https://github.com/openssl/openssl/pull/37
 
 Cool, tho didn't I read that Steve already pulled it?

I read that as well, but I assumed that just meant that he now has
access to the changesets in his local copy.  I don't think he's applied
them to his master branch, or if he has, he hasn't pushed that master
branch to the canonical repository.  or maybe i'm not looking at the
correct repository?

i don't see them applied to the master branch at
https://github.com/openssl/openssl, and i don't see them at
http://git.openssl.org/gitweb/?p=openssl.git;a=summary should i be
looking somewhere else?

--dkg




signature.asc
Description: PGP signature

Re: Safe ECC curves

[Daniel Kahn Gillmor]

On 01/01/2014 03:45 PM, Kurt Roeckx wrote:
 Hi,
 
 I recently ran into this:
 http://safecurves.cr.yp.to/
 
 It seems that openssl doesn't support any of the curves that are
 listed there as safe.
 
 At least the curve 25519 is popular and has a draft for using it
 in TLS.  Would it be possible to add at least support for that
 curve?

I think you're referring to Simon Josefsson's draft:

  https://tools.ietf.org/html/draft-josefsson-tls-curve25519-01

IIRC, the discussion about that draft over on t...@ietf.org got a bit
bogged down in the details of how to represent the points for this curve
and other similar curves (e.g. curve3617):

See, for example:

 https://www.ietf.org/mail-archive/web/tls/current/msg10284.html

If we could hash out those details (maybe restarting that conversation
over on t...@ietf.org with a concrete proposal), i'd agree that
implementing these curves for OpenSSL (at least for ECDHE, if not for
PKIX) would be a Good Thing.

Perhaps a patchset that implements it in one specific way, along with an
update to josefsson's draft clarifying the approach would be the most
useful next step, just so people have something concrete to consider.

Regards,

--dkg



signature.asc
Description: OpenPGP digital signature

Re: [openssl.org #3203] Normalize PFS key exchange labels

[Daniel Kahn Gillmor]

On 01/01/2014 12:48 PM, Ben Laurie wrote:
 Pull requests on Github are quite useful - that way they also get
 tracked (so long as we remember to close them when applied, that is!).

OK, i've rebased the series against the current master, and submitted a
github-specific pull request:

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

hth,

--dkg



signature.asc
Description: OpenPGP digital signature

Re: [openssl.org #3203] Normalize PFS key exchange labels

[Daniel Kahn Gillmor via RT]

On 01/01/2014 12:48 PM, Ben Laurie wrote:
 Pull requests on Github are quite useful - that way they also get
 tracked (so long as we remember to close them when applied, that is!).

OK, i've rebased the series against the current master, and submitted a
github-specific pull request:

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

hth,

--dkg




signature.asc
Description: PGP signature

Re: [openssl.org #3203] Normalize PFS key exchange labels

[Daniel Kahn Gillmor]

Hi Stephen--

On Fri 2013-12-20 13:51:06 -0500, Stephen Henson via RT wrote:
 I've pulled the update now, thanks.

Any update on this change?  I don't see the patches as having been
included in the master branch of https://github.com/openssl/openssl yet.
Is there any other information, review, or modification i could provide
to help get you to adopt them (either via git merge dkg or some other
mechanism)?

Is this a question about whether such a change belongs on master or on
any of the stable branches?  I figure it should go into master first,
before we would even start to discuss whether these terminology changes
made sense for any of the stable branches.

I don't mean to be impatient -- if it's just a matter of playing catchup
over the close of the winter holiday, i can wait :)

Regards,

--dkg
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3203] Normalize PFS key exchange labels

[Daniel Kahn Gillmor via RT]

Hi Stephen--

On Fri 2013-12-20 13:51:06 -0500, Stephen Henson via RT wrote:
 I've pulled the update now, thanks.

Any update on this change?  I don't see the patches as having been
included in the master branch of https://github.com/openssl/openssl yet.
Is there any other information, review, or modification i could provide
to help get you to adopt them (either via git merge dkg or some other
mechanism)?

Is this a question about whether such a change belongs on master or on
any of the stable branches?  I figure it should go into master first,
before we would even start to discuss whether these terminology changes
made sense for any of the stable branches.

I don't mean to be impatient -- if it's just a matter of playing catchup
over the close of the winter holiday, i can wait :)

Regards,

--dkg


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Normalize PFS key exchange labels

[Daniel Kahn Gillmor]

This set of patches normalizes the terminology for Perfect Forward
Secrecy key exchange within OpenSSL to the terms used by standards
bodies and other implementations, while keeping backward compatibility
for existing configurations and other inputs.

The relevant RFCs and other implementations refer to Diffie-Hellman
ephemeral key exchange as DHE (and its elliptic curve variant as
ECDHE).  OpenSSL uses this terminology in some places, but it also
uses EDH and EECDH in others.  This confusion makes selecting
these key exchange mechanisms harder for administrators to understand.

For example, there is a ciphersuite that openssl calls
EDH-RSA-DES-CBC3-SHA, and another one called DHE-RSA-AES128-SHA, whose
only difference is the choice of the cipher.

Another example is that openssl ciphers -v EECDH emits no
ciphersuites named with EECDH in them, but rather produces all
ECDHE strings.  And openssl ciphers -v ECDHE fails with Error in
cipher list.

This series of changesets standardizes OpenSSL's input, API, and
output on the standard names (DHE and ECDHE) while retaining backward
compatibility for string input and API for the older EDH and EECDH
terminology.

OpenSSL's textual output is changed only in two places:

 * packet traces will emit ECDHE for key exchange where it used to
   emit EECDH, and DHE where it used to emit EDH.

 * the six full ciphersuite strings that used to print EDH- in their
   titles now print DHE- instead.

All test suites should pass, and there should be no ABI changes.  The
only API addition is the introduction of new DHE #defines that match
exactly the existing EDH #defines (the EDH #defines remain, of
course, aliased to the same values as the DHE #defines), and the
introduction of new text strings to match.

With this series applied, openssl cipher -v DHE:ECDHE should produce
the same output as openssl -v EDH:EECDH, and all DHE ciphersuites
should have the string DHE in their name.


 doc/apps/ciphers.pod |  26 ++---
 doc/ssl/SSL_CIPHER_get_name.pod  |   4 +-
 doc/ssl/SSL_CTX_set_cipher_list.pod  |   2 +-
 doc/ssl/SSL_CTX_set_options.pod  |   2 +-
 doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod |   2 +-
 doc/ssleay.txt   |  14 +--
 ssl/d1_srvr.c|   4 +-
 ssl/s3_clnt.c|  12 +--
 ssl/s3_lib.c | 162 +++
 ssl/s3_srvr.c|  18 ++--
 ssl/ssl.h|  12 ++-
 ssl/ssl3.h   |  29 --
 ssl/ssl_ciph.c   |  55 +++
 ssl/ssl_lib.c|  14 +--
 ssl/ssl_locl.h   |   8 +-
 ssl/t1_lib.c |   6 +-
 ssl/t1_trce.c|  20 ++--
 ssl/tls1.h   |  12 +--
 18 files changed, 222 insertions(+), 180 deletions(-)


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[PATCH 08/10] change SSL3_CK_EDH_* to SSL_CK_DHE_* (with backward-compatibility)

[Daniel Kahn Gillmor]

This change normalizes the SSL_CK_DHE_ #defines to use the common term
DHE, while permitting older code that uses the more uncommon EDH
constants to compile properly.
---
 ssl/s3_lib.c | 12 ++--
 ssl/ssl3.h   | 18 --
 2 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
index ef7a5d7..2f822bd 100644
--- a/ssl/s3_lib.c
+++ b/ssl/s3_lib.c
@@ -429,7 +429,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
{
1,
SSL3_TXT_EDH_DSS_DES_40_CBC_SHA,
-   SSL3_CK_EDH_DSS_DES_40_CBC_SHA,
+   SSL3_CK_DHE_DSS_DES_40_CBC_SHA,
SSL_kDHE,
SSL_aDSS,
SSL_DES,
@@ -445,7 +445,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
{
1,
SSL3_TXT_EDH_DSS_DES_64_CBC_SHA,
-   SSL3_CK_EDH_DSS_DES_64_CBC_SHA,
+   SSL3_CK_DHE_DSS_DES_64_CBC_SHA,
SSL_kDHE,
SSL_aDSS,
SSL_DES,
@@ -461,7 +461,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
{
1,
SSL3_TXT_EDH_DSS_DES_192_CBC3_SHA,
-   SSL3_CK_EDH_DSS_DES_192_CBC3_SHA,
+   SSL3_CK_DHE_DSS_DES_192_CBC3_SHA,
SSL_kDHE,
SSL_aDSS,
SSL_3DES,
@@ -477,7 +477,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
{
1,
SSL3_TXT_EDH_RSA_DES_40_CBC_SHA,
-   SSL3_CK_EDH_RSA_DES_40_CBC_SHA,
+   SSL3_CK_DHE_RSA_DES_40_CBC_SHA,
SSL_kDHE,
SSL_aRSA,
SSL_DES,
@@ -493,7 +493,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
{
1,
SSL3_TXT_EDH_RSA_DES_64_CBC_SHA,
-   SSL3_CK_EDH_RSA_DES_64_CBC_SHA,
+   SSL3_CK_DHE_RSA_DES_64_CBC_SHA,
SSL_kDHE,
SSL_aRSA,
SSL_DES,
@@ -509,7 +509,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
{
1,
SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA,
-   SSL3_CK_EDH_RSA_DES_192_CBC3_SHA,
+   SSL3_CK_DHE_RSA_DES_192_CBC3_SHA,
SSL_kDHE,
SSL_aRSA,
SSL_3DES,
diff --git a/ssl/ssl3.h b/ssl/ssl3.h
index 5c5a5e8..17dd50c 100644
--- a/ssl/ssl3.h
+++ b/ssl/ssl3.h
@@ -149,12 +149,18 @@ extern C {
 #define SSL3_CK_DH_RSA_DES_64_CBC_SHA  0x030F
 #define SSL3_CK_DH_RSA_DES_192_CBC3_SHA0x0310
 
-#define SSL3_CK_EDH_DSS_DES_40_CBC_SHA 0x0311
-#define SSL3_CK_EDH_DSS_DES_64_CBC_SHA 0x0312
-#define SSL3_CK_EDH_DSS_DES_192_CBC3_SHA   0x0313
-#define SSL3_CK_EDH_RSA_DES_40_CBC_SHA 0x0314
-#define SSL3_CK_EDH_RSA_DES_64_CBC_SHA 0x0315
-#define SSL3_CK_EDH_RSA_DES_192_CBC3_SHA   0x0316
+#define SSL3_CK_DHE_DSS_DES_40_CBC_SHA 0x0311
+#define SSL3_CK_EDH_DSS_DES_40_CBC_SHA  SSL3_CK_DHE_DSS_DES_40_CBC_SHA
+#define SSL3_CK_DHE_DSS_DES_64_CBC_SHA 0x0312
+#define SSL3_CK_EDH_DSS_DES_64_CBC_SHA SSL3_CK_DHE_DSS_DES_64_CBC_SHA
+#define SSL3_CK_DHE_DSS_DES_192_CBC3_SHA   0x0313
+#define SSL3_CK_EDH_DSS_DES_192_CBC3_SHA   SSL3_CK_DHE_DSS_DES_192_CBC3_SHA
+#define SSL3_CK_DHE_RSA_DES_40_CBC_SHA 0x0314
+#define SSL3_CK_EDH_RSA_DES_40_CBC_SHA SSL3_CK_DHE_RSA_DES_40_CBC_SHA
+#define SSL3_CK_DHE_RSA_DES_64_CBC_SHA 0x0315
+#define SSL3_CK_EDH_RSA_DES_64_CBC_SHA SSL3_CK_DHE_RSA_DES_64_CBC_SHA
+#define SSL3_CK_DHE_RSA_DES_192_CBC3_SHA   0x0316
+#define SSL3_CK_EDH_RSA_DES_192_CBC3_SHA   SSL3_CK_DHE_RSA_DES_192_CBC3_SHA
 
 #define SSL3_CK_ADH_RC4_40_MD5 0x0317
 #define SSL3_CK_ADH_RC4_128_MD50x0318
-- 
1.8.5.1

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[PATCH 01/10] Allow ECDHE as a synonym of EECDH when specifiying ciphers

[Daniel Kahn Gillmor]

The standard terminology in https://tools.ietf.org/html/rfc4492 is
ECDHE.  openssl ciphers outputs ECDHE.  But users of the library
currently cannot specify ECDHE, they must specify EECDH.

This change allows users to specify the common term in cipher suite
strings without breaking backward compatibility.
---
 ssl/ssl.h  | 6 --
 ssl/ssl_ciph.c | 2 ++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/ssl/ssl.h b/ssl/ssl.h
index 2eccca2..1c8309e 100644
--- a/ssl/ssl.h
+++ b/ssl/ssl.h
@@ -249,7 +249,8 @@ extern C {
 #define SSL_TXT_kECDHr kECDHr
 #define SSL_TXT_kECDHe kECDHe
 #define SSL_TXT_kECDH  kECDH
-#define SSL_TXT_kEECDH kEECDH
+#define SSL_TXT_kEECDH kEECDH /* alias for kECDHE */
+#define SSL_TXT_kECDHE kECDHE
 #define SSL_TXT_kPSKkPSK
 #define SSL_TXT_kGOST  kGOST
 #define SSL_TXT_kSRP   kSRP
@@ -271,7 +272,8 @@ extern C {
 #define SSL_TXT_ADHADH
 #define SSL_TXT_RSARSA
 #define SSL_TXT_ECDH   ECDH
-#define SSL_TXT_EECDH  EECDH /* same as kEECDH:-AECDH */
+#define SSL_TXT_EECDH  EECDH /* alias for ECDHE */
+#define SSL_TXT_ECDHE  ECDHE /* same as kECDHE:-AECDH */
 #define SSL_TXT_AECDH  AECDH
 #define SSL_TXT_ECDSA  ECDSA
 #define SSL_TXT_KRB5   KRB5
diff --git a/ssl/ssl_ciph.c b/ssl/ssl_ciph.c
index a5c417a..b285a61 100644
--- a/ssl/ssl_ciph.c
+++ b/ssl/ssl_ciph.c
@@ -250,6 +250,7 @@ static const SSL_CIPHER cipher_aliases[]={
{0,SSL_TXT_kECDHe,0,  SSL_kECDHe,0,0,0,0,0,0,0,0},
{0,SSL_TXT_kECDH,0,   SSL_kECDHr|SSL_kECDHe,0,0,0,0,0,0,0,0},
{0,SSL_TXT_kEECDH,0,  SSL_kEECDH,0,0,0,0,0,0,0,0},
+   {0,SSL_TXT_kECDHE,0,  SSL_kEECDH,0,0,0,0,0,0,0,0},
{0,SSL_TXT_ECDH,0,SSL_kECDHr|SSL_kECDHe|SSL_kEECDH,0,0,0,0,0,0,0,0},
 
 {0,SSL_TXT_kPSK,0,SSL_kPSK,  0,0,0,0,0,0,0,0},
@@ -274,6 +275,7 @@ static const SSL_CIPHER cipher_aliases[]={
/* aliases combining key exchange and server authentication */
{0,SSL_TXT_EDH,0, SSL_kEDH,~SSL_aNULL,0,0,0,0,0,0,0},
{0,SSL_TXT_EECDH,0,   SSL_kEECDH,~SSL_aNULL,0,0,0,0,0,0,0},
+   {0,SSL_TXT_ECDHE,0,   SSL_kEECDH,~SSL_aNULL,0,0,0,0,0,0,0},
{0,SSL_TXT_NULL,0,0,0,SSL_eNULL, 0,0,0,0,0,0},
{0,SSL_TXT_KRB5,0,SSL_kKRB5,SSL_aKRB5,0,0,0,0,0,0,0},
{0,SSL_TXT_RSA,0, SSL_kRSA,SSL_aRSA,0,0,0,0,0,0,0},
-- 
1.8.5.1

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[PATCH 10/10] update remaining documentation to move from EDH to DHE

[Daniel Kahn Gillmor]

change documentation and comments to indicate that we prefer the
standard DHE naming scheme everywhere over the older EDH
---
 doc/apps/ciphers.pod| 24 
 doc/ssl/SSL_CIPHER_get_name.pod |  4 ++--
 doc/ssleay.txt  | 12 ++--
 ssl/tls1.h  | 12 ++--
 4 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/doc/apps/ciphers.pod b/doc/apps/ciphers.pod
index 03056eb..900f495 100644
--- a/doc/apps/ciphers.pod
+++ b/doc/apps/ciphers.pod
@@ -335,12 +335,12 @@ e.g. DES-CBC3-SHA. In these cases, RSA authentication is 
used.
  SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHAEXP-DH-RSA-DES-CBC-SHA
  SSL_DH_RSA_WITH_DES_CBC_SHA DH-RSA-DES-CBC-SHA
  SSL_DH_RSA_WITH_3DES_EDE_CBC_SHADH-RSA-DES-CBC3-SHA
- SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA   EXP-EDH-DSS-DES-CBC-SHA
- SSL_DHE_DSS_WITH_DES_CBC_SHAEDH-DSS-CBC-SHA
- SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA   EDH-DSS-DES-CBC3-SHA
- SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA   EXP-EDH-RSA-DES-CBC-SHA
- SSL_DHE_RSA_WITH_DES_CBC_SHAEDH-RSA-DES-CBC-SHA
- SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA   EDH-RSA-DES-CBC3-SHA
+ SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA   EXP-DHE-DSS-DES-CBC-SHA
+ SSL_DHE_DSS_WITH_DES_CBC_SHADHE-DSS-CBC-SHA
+ SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA   DHE-DSS-DES-CBC3-SHA
+ SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA   EXP-DHE-RSA-DES-CBC-SHA
+ SSL_DHE_RSA_WITH_DES_CBC_SHADHE-RSA-DES-CBC-SHA
+ SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA   DHE-RSA-DES-CBC3-SHA
 
  SSL_DH_anon_EXPORT_WITH_RC4_40_MD5  EXP-ADH-RC4-MD5
  SSL_DH_anon_WITH_RC4_128_MD5ADH-RC4-MD5
@@ -371,12 +371,12 @@ e.g. DES-CBC3-SHA. In these cases, RSA authentication is 
used.
  TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHANot implemented.
  TLS_DH_RSA_WITH_DES_CBC_SHA Not implemented.
  TLS_DH_RSA_WITH_3DES_EDE_CBC_SHANot implemented.
- TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA   EXP-EDH-DSS-DES-CBC-SHA
- TLS_DHE_DSS_WITH_DES_CBC_SHAEDH-DSS-CBC-SHA
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA   EDH-DSS-DES-CBC3-SHA
- TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA   EXP-EDH-RSA-DES-CBC-SHA
- TLS_DHE_RSA_WITH_DES_CBC_SHAEDH-RSA-DES-CBC-SHA
- TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA   EDH-RSA-DES-CBC3-SHA
+ TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA   EXP-DHE-DSS-DES-CBC-SHA
+ TLS_DHE_DSS_WITH_DES_CBC_SHADHE-DSS-CBC-SHA
+ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA   DHE-DSS-DES-CBC3-SHA
+ TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA   EXP-DHE-RSA-DES-CBC-SHA
+ TLS_DHE_RSA_WITH_DES_CBC_SHADHE-RSA-DES-CBC-SHA
+ TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA   DHE-RSA-DES-CBC3-SHA
 
  TLS_DH_anon_EXPORT_WITH_RC4_40_MD5  EXP-ADH-RC4-MD5
  TLS_DH_anon_WITH_RC4_128_MD5ADH-RC4-MD5
diff --git a/doc/ssl/SSL_CIPHER_get_name.pod b/doc/ssl/SSL_CIPHER_get_name.pod
index eb772b5..908fbd1 100644
--- a/doc/ssl/SSL_CIPHER_get_name.pod
+++ b/doc/ssl/SSL_CIPHER_get_name.pod
@@ -86,8 +86,8 @@ regulations, the word Bexport is printed.
 
 Some examples for the output of SSL_CIPHER_description():
 
- EDH-RSA-DES-CBC3-SHASSLv3 Kx=DH   Au=RSA  Enc=3DES(168) Mac=SHA1
- EDH-DSS-DES-CBC3-SHASSLv3 Kx=DH   Au=DSS  Enc=3DES(168) Mac=SHA1
+ DHE-RSA-DES-CBC3-SHASSLv3 Kx=DH   Au=RSA  Enc=3DES(168) Mac=SHA1
+ DHE-DSS-DES-CBC3-SHASSLv3 Kx=DH   Au=DSS  Enc=3DES(168) Mac=SHA1
  RC4-MD5 SSLv3 Kx=RSA  Au=RSA  Enc=RC4(128)  Mac=MD5
  EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  
export
 
diff --git a/doc/ssleay.txt b/doc/ssleay.txt
index 8c0f3ac..29ea0ee 100644
--- a/doc/ssleay.txt
+++ b/doc/ssleay.txt
@@ -6061,20 +6061,20 @@ $ ssleay ciphers -v 
'!ADH:RC4+RSA:HIGH:MEDIUM:LOW:EXP:+SSLv2:+EXP'
 
 RC4-SHA SSLv3 Kx=RSA  Au=RSA  Enc=RC4(128)  Mac=SHA1
 RC4-MD5 SSLv3 Kx=RSA  Au=RSA  Enc=RC4(128)  Mac=MD5 
-EDH-RSA-DES-CBC3-SHASSLv3 Kx=DH   Au=RSA  Enc=3DES(168) Mac=SHA1
-EDH-DSS-DES-CBC3-SHASSLv3 Kx=DH   Au=DSS  Enc=3DES(168) Mac=SHA1
+DHE-RSA-DES-CBC3-SHASSLv3 Kx=DH   Au=RSA  Enc=3DES(168) Mac=SHA1
+DHE-DSS-DES-CBC3-SHASSLv3 Kx=DH   Au=DSS  Enc=3DES(168) Mac=SHA1
 DES-CBC3-SHASSLv3 Kx=RSA  Au=RSA  Enc=3DES(168) Mac=SHA1
 IDEA-CBC-MD5SSLv3 Kx=RSA  Au=RSA  Enc=IDEA(128) Mac=SHA1
-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH   Au=RSA  Enc=DES(56)   Mac=SHA1
-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH   Au=DSS  Enc=DES(56)   Mac=SHA1
+DHE-RSA-DES-CBC-SHA SSLv3 Kx=DH   Au=RSA  Enc=DES(56)   Mac=SHA1
+DHE-DSS-DES-CBC-SHA SSLv3 Kx=DH   Au=DSS  Enc=DES(56)   Mac=SHA1
 DES-CBC-SHA SSLv3 Kx=RSA  Au=RSA  Enc=DES(56)   Mac=SHA1
 DES-CBC3-MD5SSLv2 Kx=RSA  Au=RSA  Enc=3DES(168) Mac=MD5 
 DES-CBC-MD5 SSLv2 Kx=RSA  Au=RSA  Enc=DES(56)   Mac=MD5 
 IDEA-CBC-MD5SSLv2 Kx=RSA  Au=RSA  Enc=IDEA(128) Mac=MD5 
 RC2-CBC-MD5 SSLv2 

[PATCH 06/10] use SSL_kDHE throughout instead of SSL_kEDH

[Daniel Kahn Gillmor]

DHE is the standard term used by the RFCs and by other TLS
implementations.  It's useful to have the internal variables use the
standard terminology.

This patch leaves a synonym SSL_kEDH in place, though, so that older
code can still be built against it, since that has been the
traditional API.  SSL_kEDH should probably be deprecated at some
point, though.
---
 doc/apps/ciphers.pod |  2 +-
 doc/ssleay.txt   |  2 +-
 ssl/d1_srvr.c|  2 +-
 ssl/s3_clnt.c|  8 ++---
 ssl/s3_lib.c | 86 ++--
 ssl/s3_srvr.c|  8 ++---
 ssl/ssl_ciph.c   | 20 ++--
 ssl/ssl_lib.c| 10 +++---
 ssl/ssl_locl.h   |  5 +--
 ssl/t1_trce.c|  8 ++---
 10 files changed, 76 insertions(+), 75 deletions(-)

diff --git a/doc/apps/ciphers.pod b/doc/apps/ciphers.pod
index c571830..03056eb 100644
--- a/doc/apps/ciphers.pod
+++ b/doc/apps/ciphers.pod
@@ -179,7 +179,7 @@ attack and so their use is normally discouraged.
 
 cipher suites using RSA key exchange, authentication or either respectively.
 
-=item BkEDH
+=item BkDHE
 
 cipher suites using ephemeral DH key agreement.
 
diff --git a/doc/ssleay.txt b/doc/ssleay.txt
index 868a4a6..8c0f3ac 100644
--- a/doc/ssleay.txt
+++ b/doc/ssleay.txt
@@ -6026,7 +6026,7 @@ one at a time, or use 'aliases' to specify the preference 
and order for
 the ciphers.
 
 There are a large number of aliases, but the most importaint are
-kRSA, kDHr, kDHd and kEDH for key exchange types.
+kRSA, kDHr, kDHd and kDHE for key exchange types.
 
 aRSA, aDSS, aNULL and aDH for authentication
 DES, 3DES, RC4, RC2, IDEA and eNULL for ciphers
diff --git a/ssl/d1_srvr.c b/ssl/d1_srvr.c
index 267b8ca..7816bbb 100644
--- a/ssl/d1_srvr.c
+++ b/ssl/d1_srvr.c
@@ -491,7 +491,7 @@ int dtls1_accept(SSL *s)
 #ifndef OPENSSL_NO_PSK
|| ((alg_k  SSL_kPSK)  s-ctx-psk_identity_hint)
 #endif
-   || (alg_k  (SSL_kEDH|SSL_kDHr|SSL_kDHd))
+   || (alg_k  (SSL_kDHE|SSL_kDHr|SSL_kDHd))
|| (alg_k  SSL_kECDHE)
|| ((alg_k  SSL_kRSA)
 (s-cert-pkeys[SSL_PKEY_RSA_ENC].privatekey 
== NULL
diff --git a/ssl/s3_clnt.c b/ssl/s3_clnt.c
index 0054e7f..5f547bb 100644
--- a/ssl/s3_clnt.c
+++ b/ssl/s3_clnt.c
@@ -1656,7 +1656,7 @@ int ssl3_get_key_exchange(SSL *s)
;
 #endif
 #ifndef OPENSSL_NO_DH
-   else if (alg_k  SSL_kEDH)
+   else if (alg_k  SSL_kDHE)
{
if ((dh=DH_new()) == NULL)
{
@@ -2581,7 +2581,7 @@ int ssl3_send_client_key_exchange(SSL *s)
}
 #endif
 #ifndef OPENSSL_NO_DH
-   else if (alg_k  (SSL_kEDH|SSL_kDHr|SSL_kDHd))
+   else if (alg_k  (SSL_kDHE|SSL_kDHr|SSL_kDHd))
{
DH *dh_srvr,*dh_clnt;
SESS_CERT *scert = s-session-sess_cert;
@@ -3469,7 +3469,7 @@ int ssl3_check_cert_and_algorithm(SSL *s)
}
 #endif
 #ifndef OPENSSL_NO_DH
-   if ((alg_k  SSL_kEDH)  
+   if ((alg_k  SSL_kDHE)  
!(has_bits(i,EVP_PK_DH|EVP_PKT_EXCH) || (dh != NULL)))
{

SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM,SSL_R_MISSING_DH_KEY);
@@ -3506,7 +3506,7 @@ int ssl3_check_cert_and_algorithm(SSL *s)
else
 #endif
 #ifndef OPENSSL_NO_DH
-   if (alg_k  (SSL_kEDH|SSL_kDHr|SSL_kDHd))
+   if (alg_k  (SSL_kDHE|SSL_kDHr|SSL_kDHd))
{
if (dh == NULL
|| DH_size(dh)*8  
SSL_C_EXPORT_PKEYLENGTH(s-s3-tmp.new_cipher))
diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
index f68aeba..ef7a5d7 100644
--- a/ssl/s3_lib.c
+++ b/ssl/s3_lib.c
@@ -430,7 +430,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
1,
SSL3_TXT_EDH_DSS_DES_40_CBC_SHA,
SSL3_CK_EDH_DSS_DES_40_CBC_SHA,
-   SSL_kEDH,
+   SSL_kDHE,
SSL_aDSS,
SSL_DES,
SSL_SHA1,
@@ -446,7 +446,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
1,
SSL3_TXT_EDH_DSS_DES_64_CBC_SHA,
SSL3_CK_EDH_DSS_DES_64_CBC_SHA,
-   SSL_kEDH,
+   SSL_kDHE,
SSL_aDSS,
SSL_DES,
SSL_SHA1,
@@ -462,7 +462,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
1,
SSL3_TXT_EDH_DSS_DES_192_CBC3_SHA,
SSL3_CK_EDH_DSS_DES_192_CBC3_SHA,
-   SSL_kEDH,
+   SSL_kDHE,
SSL_aDSS,
SSL_3DES,
SSL_SHA1,
@@ -478,7 +478,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
1,
SSL3_TXT_EDH_RSA_DES_40_CBC_SHA,
SSL3_CK_EDH_RSA_DES_40_CBC_SHA,
-   SSL_kEDH,
+   SSL_kDHE,
SSL_aRSA,
SSL_DES,
SSL_SHA1,
@@ -494,7 +494,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
1,
SSL3_TXT_EDH_RSA_DES_64_CBC_SHA,

[PATCH 09/10] Replace EDH-RSA-DES-CBC-SHA, etc. with DHE-RSA-DES-CBC-SHA

[Daniel Kahn Gillmor]

Replace the full ciphersuites with EDH- in their labels with DHE-
so that all DHE ciphersuites are referred to in the same way.

Leave backward-compatible aliases for the ciphersuites in question so
that configurations which specify these explicitly will continue
working.
---
 ssl/s3_lib.c   | 12 ++--
 ssl/ssl3.h | 11 +++
 ssl/ssl_ciph.c | 15 +++
 3 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
index 2f822bd..5c8aa13 100644
--- a/ssl/s3_lib.c
+++ b/ssl/s3_lib.c
@@ -428,7 +428,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
 /* Cipher 11 */
{
1,
-   SSL3_TXT_EDH_DSS_DES_40_CBC_SHA,
+   SSL3_TXT_DHE_DSS_DES_40_CBC_SHA,
SSL3_CK_DHE_DSS_DES_40_CBC_SHA,
SSL_kDHE,
SSL_aDSS,
@@ -444,7 +444,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
 /* Cipher 12 */
{
1,
-   SSL3_TXT_EDH_DSS_DES_64_CBC_SHA,
+   SSL3_TXT_DHE_DSS_DES_64_CBC_SHA,
SSL3_CK_DHE_DSS_DES_64_CBC_SHA,
SSL_kDHE,
SSL_aDSS,
@@ -460,7 +460,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
 /* Cipher 13 */
{
1,
-   SSL3_TXT_EDH_DSS_DES_192_CBC3_SHA,
+   SSL3_TXT_DHE_DSS_DES_192_CBC3_SHA,
SSL3_CK_DHE_DSS_DES_192_CBC3_SHA,
SSL_kDHE,
SSL_aDSS,
@@ -476,7 +476,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
 /* Cipher 14 */
{
1,
-   SSL3_TXT_EDH_RSA_DES_40_CBC_SHA,
+   SSL3_TXT_DHE_RSA_DES_40_CBC_SHA,
SSL3_CK_DHE_RSA_DES_40_CBC_SHA,
SSL_kDHE,
SSL_aRSA,
@@ -492,7 +492,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
 /* Cipher 15 */
{
1,
-   SSL3_TXT_EDH_RSA_DES_64_CBC_SHA,
+   SSL3_TXT_DHE_RSA_DES_64_CBC_SHA,
SSL3_CK_DHE_RSA_DES_64_CBC_SHA,
SSL_kDHE,
SSL_aRSA,
@@ -508,7 +508,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
 /* Cipher 16 */
{
1,
-   SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA,
+   SSL3_TXT_DHE_RSA_DES_192_CBC3_SHA,
SSL3_CK_DHE_RSA_DES_192_CBC3_SHA,
SSL_kDHE,
SSL_aRSA,
diff --git a/ssl/ssl3.h b/ssl/ssl3.h
index 17dd50c..c94b3a4 100644
--- a/ssl/ssl3.h
+++ b/ssl/ssl3.h
@@ -214,6 +214,17 @@ extern C {
 #define SSL3_TXT_DH_RSA_DES_64_CBC_SHA DH-RSA-DES-CBC-SHA
 #define SSL3_TXT_DH_RSA_DES_192_CBC3_SHA   DH-RSA-DES-CBC3-SHA
 
+#define SSL3_TXT_DHE_DSS_DES_40_CBC_SHA
EXP-DHE-DSS-DES-CBC-SHA
+#define SSL3_TXT_DHE_DSS_DES_64_CBC_SHADHE-DSS-DES-CBC-SHA
+#define SSL3_TXT_DHE_DSS_DES_192_CBC3_SHA  DHE-DSS-DES-CBC3-SHA
+#define SSL3_TXT_DHE_RSA_DES_40_CBC_SHA
EXP-DHE-RSA-DES-CBC-SHA
+#define SSL3_TXT_DHE_RSA_DES_64_CBC_SHADHE-RSA-DES-CBC-SHA
+#define SSL3_TXT_DHE_RSA_DES_192_CBC3_SHA  DHE-RSA-DES-CBC3-SHA
+
+/* This next block of six EDH labels is for backward compatibility
+   with older versions of OpenSSL.  New code should use the six DHE
+   labels above instead:
+ */
 #define SSL3_TXT_EDH_DSS_DES_40_CBC_SHA
EXP-EDH-DSS-DES-CBC-SHA
 #define SSL3_TXT_EDH_DSS_DES_64_CBC_SHAEDH-DSS-DES-CBC-SHA
 #define SSL3_TXT_EDH_DSS_DES_192_CBC3_SHA  EDH-DSS-DES-CBC3-SHA
diff --git a/ssl/ssl_ciph.c b/ssl/ssl_ciph.c
index 6476434..1a2849a 100644
--- a/ssl/ssl_ciph.c
+++ b/ssl/ssl_ciph.c
@@ -330,6 +330,21 @@ static const SSL_CIPHER cipher_aliases[]={
{0,SSL_TXT_HIGH,0,0,0,0,0,0,SSL_HIGH,  0,0,0},
/* FIPS 140-2 approved ciphersuite */
{0,SSL_TXT_FIPS,0,0,0,~SSL_eNULL,0,0,SSL_FIPS,  0,0,0},
+
+/* EDH- aliases to DHE- labels (for backward compatibility) */
+   {0,SSL3_TXT_EDH_DSS_DES_40_CBC_SHA,0,
+ 
SSL_kDHE,SSL_aDSS,SSL_DES,SSL_SHA1,SSL_SSLV3,SSL_EXPORT|SSL_EXP40,0,0,0,},
+   {0,SSL3_TXT_EDH_DSS_DES_64_CBC_SHA,0,
+ 
SSL_kDHE,SSL_aDSS,SSL_DES,SSL_SHA1,SSL_SSLV3,SSL_NOT_EXP|SSL_LOW,0,0,0,},
+   {0,SSL3_TXT_EDH_DSS_DES_192_CBC3_SHA,0,
+ 
SSL_kDHE,SSL_aDSS,SSL_3DES,SSL_SHA1,SSL_SSLV3,SSL_NOT_EXP|SSL_HIGH|SSL_FIPS,0,0,0,},
+   {0,SSL3_TXT_EDH_RSA_DES_40_CBC_SHA,0,
+ 
SSL_kDHE,SSL_aRSA,SSL_DES,SSL_SHA1,SSL_SSLV3,SSL_EXPORT|SSL_EXP40,0,0,0,},
+   {0,SSL3_TXT_EDH_RSA_DES_64_CBC_SHA,0,
+ 
SSL_kDHE,SSL_aRSA,SSL_DES,SSL_SHA1,SSL_SSLV3,SSL_NOT_EXP|SSL_LOW,0,0,0,},
+   {0,SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA,0,
+ 
SSL_kDHE,SSL_aRSA,SSL_3DES,SSL_SHA1,SSL_SSLV3,SSL_NOT_EXP|SSL_HIGH|SSL_FIPS,0,0,0,},
+
};
 /* Search for public key algorithm with given name and 
  * return its pkey_id if it is available. Otherwise return 0
-- 
1.8.5.1

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[PATCH 02/10] emit ECDHE instead of EECDH for kX packet trace output

[Daniel Kahn Gillmor]

other parts of packet tracing emit the standard ECDHE label instead
of EECDH.  This change brings the output of ssl_print_client_keyex()
and ssl_print_server_keyex() into accordance with the standard term.
---
 ssl/t1_trce.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ssl/t1_trce.c b/ssl/t1_trce.c
index 6856898..751e0ff 100644
--- a/ssl/t1_trce.c
+++ b/ssl/t1_trce.c
@@ -817,7 +817,7 @@ static int ssl_get_keyex(const char **pname, SSL *ssl)
}
if (alg_k  SSL_kEECDH)
{
-   *pname = EECDH;
+   *pname = ECDHE;
return SSL_kEECDH;
}
if (alg_k  SSL_kECDHr)
-- 
1.8.5.1

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[PATCH 04/10] Allow DHE and kDHE as synonyms of EDH and kEDH when specifiying ciphers

[Daniel Kahn Gillmor]

The standard terminology in https://tools.ietf.org/html/rfc5426 is
DHE.  openssl ciphers outputs DHE (for the most part).  But
users of the library currently cannot specify DHE, they must
currently specify EDH.

This change allows users to specify the common term in cipher suite
strings without breaking backward compatibility.
---
 ssl/ssl.h  | 6 --
 ssl/ssl_ciph.c | 2 ++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/ssl/ssl.h b/ssl/ssl.h
index 1c8309e..3c49a38 100644
--- a/ssl/ssl.h
+++ b/ssl/ssl.h
@@ -244,7 +244,8 @@ extern C {
 #define SSL_TXT_kDHr   kDHr 
 #define SSL_TXT_kDHd   kDHd
 #define SSL_TXT_kDHkDH
-#define SSL_TXT_kEDH   kEDH
+#define SSL_TXT_kEDH   kEDH /* alias for kDHE */
+#define SSL_TXT_kDHE   kDHE
 #define SSL_TXT_kKRB5  kKRB5
 #define SSL_TXT_kECDHr kECDHr
 #define SSL_TXT_kECDHe kECDHe
@@ -268,7 +269,8 @@ extern C {
 
 #defineSSL_TXT_DSS DSS
 #define SSL_TXT_DH DH
-#define SSL_TXT_EDHEDH /* same as kEDH:-ADH */
+#define SSL_TXT_DHEDHE /* same as kDHE:-ADH */
+#define SSL_TXT_EDHEDH /* alias for DHE */
 #define SSL_TXT_ADHADH
 #define SSL_TXT_RSARSA
 #define SSL_TXT_ECDH   ECDH
diff --git a/ssl/ssl_ciph.c b/ssl/ssl_ciph.c
index 60b1456..8464784 100644
--- a/ssl/ssl_ciph.c
+++ b/ssl/ssl_ciph.c
@@ -242,6 +242,7 @@ static const SSL_CIPHER cipher_aliases[]={
{0,SSL_TXT_kDHd,0,SSL_kDHd,  0,0,0,0,0,0,0,0},
{0,SSL_TXT_kDH,0, SSL_kDHr|SSL_kDHd,0,0,0,0,0,0,0,0},
{0,SSL_TXT_kEDH,0,SSL_kEDH,  0,0,0,0,0,0,0,0},
+   {0,SSL_TXT_kDHE,0,SSL_kEDH,  0,0,0,0,0,0,0,0},
{0,SSL_TXT_DH,0,  SSL_kDHr|SSL_kDHd|SSL_kEDH,0,0,0,0,0,0,0,0},
 
{0,SSL_TXT_kKRB5,0,   SSL_kKRB5, 0,0,0,0,0,0,0,0},
@@ -274,6 +275,7 @@ static const SSL_CIPHER cipher_aliases[]={
 
/* aliases combining key exchange and server authentication */
{0,SSL_TXT_EDH,0, SSL_kEDH,~SSL_aNULL,0,0,0,0,0,0,0},
+   {0,SSL_TXT_DHE,0, SSL_kEDH,~SSL_aNULL,0,0,0,0,0,0,0},
{0,SSL_TXT_EECDH,0,   SSL_kECDHE,~SSL_aNULL,0,0,0,0,0,0,0},
{0,SSL_TXT_ECDHE,0,   SSL_kECDHE,~SSL_aNULL,0,0,0,0,0,0,0},
{0,SSL_TXT_NULL,0,0,0,SSL_eNULL, 0,0,0,0,0,0},
-- 
1.8.5.1

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3203] Normalize PFS key exchange labels

[Daniel Kahn Gillmor via RT]

The relevant RFCs and other implementations refer to Diffie-Hellman
ephemeral key exchange as DHE (and its elliptic curve variant as
ECDHE).  OpenSSL uses this terminology in some places, but it also
uses EDH and EECDH in others.  This confusion makes selecting
these key exchange mechanisms harder for administrators to understand.

For example, there is a ciphersuite that openssl calls
EDH-RSA-DES-CBC3-SHA, and another one called DHE-RSA-AES128-SHA, whose
only difference is the choice of the cipher.

Another example is that openssl ciphers -v EECDH emits no
ciphersuites named with EECDH in them, but rather produces all
ECDHE strings.  And openssl ciphers -v ECDHE fails with Error in
cipher list.

I posted a series of 10 changesets to openssl-dev which standardizes
OpenSSL's input, API, and output on the standard names (DHE and ECDHE)
while retaining backward compatibility for string input and API for the
older EDH and EECDH terminology.

See: Message-ID:
1387528669-26823-1-git-send-email-...@fifthhorseman.net, e.g. at
http://thread.gmane.org/gmane.comp.encryption.openssl.devel/23577/focus=23579
and following messages in that thread.

--dkg

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3203] Normalize PFS key exchange labels

[Daniel Kahn Gillmor]

On 12/20/2013 12:52 PM, Stephen Henson via RT wrote:
 On Fri Dec 20 18:37:18 2013, d...@fifthhorseman.net wrote:

 I posted a series of 10 changesets to openssl-dev which standardizes
 OpenSSL's input, API, and output on the standard names (DHE and ECDHE)
 while retaining backward compatibility for string input and API for
 the
 older EDH and EECDH terminology.

 
 Could you include the lot in a single attachment using git format-patch or 
 as
 a pull request? It's easier to review and apply that way.

Thanks for the quick followup, Stephen.

I can do whatever you think is most useful, but i need a bit more
guidance to be sure i'm giving you what will be most useful for you.

I used git send-email to send these patches earlier, which is how it
is usually done on the linux-nfs and notmuch mailing lists (two places i
follow that use git heavily).

I've also made these patches available as the standardize-on-dhe
branch at git://lair.fifthhorseman.net/~dkg/openssl -- you can add that
to your local repo with:

  git remote add dkg git://lair.fifthhorseman.net/~dkg/openssl
  git remote update dkg

and then review it with your local repository browser of choice.

If you want them via format-patch: my understanding is that git
format-patch produces a directory of patches, one per commit.  i'm not
sure how you want that as a single attachment.  is a tarball of the
directory produced by git format-patch OK, or do you want them squashed
down to a single aggregated patch?  I think having the separate patches
makes them easier to review.

let me know what else you'd like me to do.

Regards,

--dkg



signature.asc
Description: OpenPGP digital signature

Re: [openssl.org #3203] Normalize PFS key exchange labels

[Daniel Kahn Gillmor]

On 12/20/2013 01:51 PM, Stephen Henson via RT wrote:
 I've pulled the update now, thanks.

great!

 Well I have to admit to being far from a git expert. For me it's best if it's
 easy to get the patches with commit messages and authorship somewhere I can
 review them. If I manually have to apply multiple patches and add appropriate
 credit it's a pain.

sure, understood.  If you can get the patches all into one maildir or
mbox locally (i'm not sure what MUA you use, or what it is capable of),
then you should also be able to just run git am /path/to/maildir-or-mbox.

For example, in the notmuch MUA's emacs interface, you can just ensure
that the patches you want to apply are open in a notmuch-show buffer,
and then do:

  C-u | cd ~/src/openssl  git am

 As regards the patches themselves (and indeed any patch) an important question
 is what (if anything) it will break. As I understand it cipher strings will
 still be compatible which is great.

yep, i figured something like this wouldn't be acceptable to the
community if we actually broke existing cipher specifications.  A
nice-to-have additional feature might be to have some way to emit
warnings when the older EDH and EECDH strings are used (either in cipher
strings or at compile time), so that we could ultimately deprecate them
-- but i leave that for Future Work :)

 What about the actual cipher suite names as returned by the various APIs? If 
 an
 application compares that string to an expected value which is changed it will
 fail. Anyone know of anything that does that?

I searched the entire source of the debian archive for places where
those strings might be used:

 http://codesearch.debian.net/search?q=EDH-RSA

There is a lot of non-code that appears to just be translation lists
between a library's own idiosyncratic strings and OpenSSL's
idiosyncratic strings.

Then there are just embedded copies of OpenSSL (e.g. in chromium(!)).
Neither of these categories are an issue, i think.

Then there is code like erlang's implementation that appears to map
controls to strings for OpenSSL itself to use:

 
http://sources.debian.net/src/erlang/1:16.b.3-dfsg-1/lib/ssl/src/ssl_cipher.erl?hl=887#L887

PolarSSL appears to have the same sort of framework:

 
http://codesearch.debian.net/show?file=pdns_3.3-1%2Fpdns%2Fext%2Fpolarssl-1.1.2%2Flibrary%2Fssl_tls.cline=1998numfiles=107#L1998

I don't think this code will break, because i think it's being used to
pass strings *to* OpenSSL rather than the other way around.

There might be some issues raised in the yaSSL and tcltls and polarssl
test suites:

 
http://sources.debian.net/src/mysql-5.5/5.5.33+dfsg-1/mysql-test/r/openssl_1.result?hl=199#L199

 http://sources.debian.net/src/tcltls/1.6+dfsg-3/tests/ciphers.test?hl=44#L44

 
http://codesearch.debian.net/show?file=pdns_3.3-1%2Fpdns%2Fext%2Fpolarssl-1.1.2%2Flibrary%2Fssl_tls.cline=1998numfiles=107#L1998

but those alerts look like they'd be useful to help downstream to be
aware that OpenSSL cares about the standard vocabulary too, which is one
of the goals of this change (so we can all know that we're talking about
the same thing).

Those are the only concerns that i see, and while i can imagine some
downstream folks getting peeved because they need to adjust their test
suites, i think that's an acceptable price to pay for having a sane and
normalized vocabulary to be able to talk about this stuff.

I didn't see any other significant types of use of these strings in the
debian archive.  I know debian isn't exhaustive, but it covers a lot of
the free software world, at least.

btw, since you only raise concerns about the string value returned for
the ciphersuites, It sounds like you're OK with the change to the packet
tracing output -- i didn't think that the packet tracing would be
contentious, but just want to make sure that change is on your radar
too.  Should be fine :)

Regards,

--dkg



signature.asc
Description: OpenPGP digital signature

Re: [openssl.org #3203] Normalize PFS key exchange labels

[Daniel Kahn Gillmor via RT]

On 12/20/2013 01:51 PM, Stephen Henson via RT wrote:
 I've pulled the update now, thanks.

great!

 Well I have to admit to being far from a git expert. For me it's best if it's
 easy to get the patches with commit messages and authorship somewhere I can
 review them. If I manually have to apply multiple patches and add appropriate
 credit it's a pain.

sure, understood.  If you can get the patches all into one maildir or
mbox locally (i'm not sure what MUA you use, or what it is capable of),
then you should also be able to just run git am /path/to/maildir-or-mbox.

For example, in the notmuch MUA's emacs interface, you can just ensure
that the patches you want to apply are open in a notmuch-show buffer,
and then do:

  C-u | cd ~/src/openssl  git am

 As regards the patches themselves (and indeed any patch) an important question
 is what (if anything) it will break. As I understand it cipher strings will
 still be compatible which is great.

yep, i figured something like this wouldn't be acceptable to the
community if we actually broke existing cipher specifications.  A
nice-to-have additional feature might be to have some way to emit
warnings when the older EDH and EECDH strings are used (either in cipher
strings or at compile time), so that we could ultimately deprecate them
-- but i leave that for Future Work :)

 What about the actual cipher suite names as returned by the various APIs? If 
 an
 application compares that string to an expected value which is changed it will
 fail. Anyone know of anything that does that?

I searched the entire source of the debian archive for places where
those strings might be used:

 http://codesearch.debian.net/search?q=EDH-RSA

There is a lot of non-code that appears to just be translation lists
between a library's own idiosyncratic strings and OpenSSL's
idiosyncratic strings.

Then there are just embedded copies of OpenSSL (e.g. in chromium(!)).
Neither of these categories are an issue, i think.

Then there is code like erlang's implementation that appears to map
controls to strings for OpenSSL itself to use:

 
http://sources.debian.net/src/erlang/1:16.b.3-dfsg-1/lib/ssl/src/ssl_cipher.erl?hl=887#L887

PolarSSL appears to have the same sort of framework:

 
http://codesearch.debian.net/show?file=pdns_3.3-1%2Fpdns%2Fext%2Fpolarssl-1.1.2%2Flibrary%2Fssl_tls.cline=1998numfiles=107#L1998

I don't think this code will break, because i think it's being used to
pass strings *to* OpenSSL rather than the other way around.

There might be some issues raised in the yaSSL and tcltls and polarssl
test suites:

 
http://sources.debian.net/src/mysql-5.5/5.5.33+dfsg-1/mysql-test/r/openssl_1.result?hl=199#L199

 http://sources.debian.net/src/tcltls/1.6+dfsg-3/tests/ciphers.test?hl=44#L44

 
http://codesearch.debian.net/show?file=pdns_3.3-1%2Fpdns%2Fext%2Fpolarssl-1.1.2%2Flibrary%2Fssl_tls.cline=1998numfiles=107#L1998

but those alerts look like they'd be useful to help downstream to be
aware that OpenSSL cares about the standard vocabulary too, which is one
of the goals of this change (so we can all know that we're talking about
the same thing).

Those are the only concerns that i see, and while i can imagine some
downstream folks getting peeved because they need to adjust their test
suites, i think that's an acceptable price to pay for having a sane and
normalized vocabulary to be able to talk about this stuff.

I didn't see any other significant types of use of these strings in the
debian archive.  I know debian isn't exhaustive, but it covers a lot of
the free software world, at least.

btw, since you only raise concerns about the string value returned for
the ciphersuites, It sounds like you're OK with the change to the packet
tracing output -- i didn't think that the packet tracing would be
contentious, but just want to make sure that change is on your radar
too.  Should be fine :)

Regards,

--dkg




signature.asc
Description: PGP signature

Re: [openssl.org #3203] Normalize PFS key exchange labels

[Daniel Kahn Gillmor]

On 12/20/2013 03:30 PM, Matt Caswell wrote:
 I had this problem with my ocb patch recently. For future reference, I
 solved it by creating a temporary branch and using git merge --squash.
 So if your commits are on my-branch, and you want to create a patch
 against master:

fwiw, i think squashing all the patches would make this change
significantly more difficult to review.

I deliberately broke the changes into logical units that are reviewable
and understandable; merging all 10 of them down to one squashed patch
would render that one patch much more difficult for me to make sense of
(if i was on the reviewing side of the patch submission process), even
though the effect on the code would be the same.

Regards,

--dkg



signature.asc
Description: OpenPGP digital signature

EDH vs DHE: which specifications use the term EDH ?

[Daniel Kahn Gillmor]

hey folks--

I'm working on a set of patches that will hopefully normalize the
terminology for PFS key exchange within OpenSSL to the terms that the
rest of the world uses.  (Keeping backward compatibility is one of my
goals too, of course).

In particular, i'm concerned that when the rest of the world (including
the TLS RFCs) talk about DHE and ECDHE, OpenSSL sometimes (but not
always!) talks about EDH and EECDH.  PFS is confusing enough without
this.

i note that ssl/tls1.h says:

   561  /* XXX
   562   * Inconsistency alert:
   563   * The OpenSSL names of ciphers with ephemeral DH here include the 
string
   564   * DHE, while elsewhere it has always been EDH.
   565   * (The alias for the list of all such ciphers also is EDH.)
   566   * The specifications speak of EDH; maybe we should allow both forms
   567   * for everything. */


I'm unclear particularly about line 566.  Which specifications speak of EDH?

RFC 2246 (TLS 1.0), RFC 4346 (TLS 1.1), and RFC 5246 (TLS 1.2) all say
only DHE, and never mention EDH.

The retrospective RFC 6101 (SSL 3.0) also mentions DHE but not EDH.

So which specifications does line 566 refer to?

   --dkg


pgpQr_SOLJxRf.pgp
Description: PGP signature

[openssl.org #3164] [PATCH] require DH group of 1024 bits

[Daniel Kahn Gillmor via RT]

Reject connections to TLS servers that select DH key exchange but
offer a weak DH group.
---
 ssl/s3_clnt.c | 6 ++
 ssl/ssl.h | 1 +
 ssl/ssl_err.c | 1 +
 3 files changed, 8 insertions(+)

diff --git a/ssl/s3_clnt.c b/ssl/s3_clnt.c
index bf1ef47..ef638c4 100644
--- a/ssl/s3_clnt.c
+++ b/ssl/s3_clnt.c
@@ -3481,6 +3481,12 @@ int ssl3_check_cert_and_algorithm(SSL *s)

SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM,SSL_R_MISSING_DH_RSA_CERT);
goto f_err;
}
+else if ((alg_k  (SSL_kEDH|SSL_kDHr|SSL_kDHd)) 
+   (dh == NULL || DH_size(dh)*8  1024))
+   {
+   SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM,SSL_R_WEAK_DH_GROUP);
+   goto f_err;
+   }
 #ifndef OPENSSL_NO_DSA
else if ((alg_k  SSL_kDHd)  !SSL_USE_SIGALGS(s) 
!has_bits(i,EVP_PK_DH|EVP_PKS_DSA))
diff --git a/ssl/ssl.h b/ssl/ssl.h
index 013345e..36ffa6e 100644
--- a/ssl/ssl.h
+++ b/ssl/ssl.h
@@ -3073,6 +3073,7 @@ void ERR_load_SSL_strings(void);
 #define SSL_R_UNSUPPORTED_SSL_VERSION   259
 #define SSL_R_UNSUPPORTED_STATUS_TYPE   329
 #define SSL_R_USE_SRTP_NOT_NEGOTIATED   369
+#define SSL_R_WEAK_DH_GROUP 394
 #define SSL_R_WRITE_BIO_NOT_SET 260
 #define SSL_R_WRONG_CERTIFICATE_TYPE383
 #define SSL_R_WRONG_CIPHER_RETURNED 261
diff --git a/ssl/ssl_err.c b/ssl/ssl_err.c
index e663483..844c600 100644
--- a/ssl/ssl_err.c
+++ b/ssl/ssl_err.c
@@ -623,6 +623,7 @@ static ERR_STRING_DATA SSL_str_reasons[]=
 {ERR_REASON(SSL_R_UNSUPPORTED_SSL_VERSION),unsupported ssl version},
 {ERR_REASON(SSL_R_UNSUPPORTED_STATUS_TYPE),unsupported status type},
 {ERR_REASON(SSL_R_USE_SRTP_NOT_NEGOTIATED),use srtp not negotiated},
+{ERR_REASON(SSL_R_WEAK_DH_GROUP) ,weak dh group},
 {ERR_REASON(SSL_R_WRITE_BIO_NOT_SET) ,write bio not set},
 {ERR_REASON(SSL_R_WRONG_CERTIFICATE_TYPE),wrong certificate type},
 {ERR_REASON(SSL_R_WRONG_CIPHER_RETURNED) ,wrong cipher returned},
-- 
1.8.4.rc3

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL client DH group limits

[Daniel Kahn Gillmor]

On 11/07/2013 09:15 AM, Kurt Roeckx wrote:

I filed a ticket about this ealier (#3120)

You can see the discussion about that here:
http://openssl.6102.n7.nabble.com/openssl-org-3120-Minimum-size-of-DH-td46401.html


ah, thanks.  It's too bad that discussion isn't mirrored on

  https://rt.openssl.org/Ticket/Display.html?id=3120


Which basicly says that clients can reject it if they want, but I
rather see some sane default.


Given that i've never seen a client actually verify that this value 
meets their security expectations, having a sane default baked in would 
be a good idea.


Either that, or the OpenSSL project needs to give much stronger explicit 
guidance to its users about how to verify the security parameters of its 
sessions.


--dkg
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org