Re: [PATCH] ec/ec_pmeth.c: fix unsigned char issue

2013-11-07 Thread Marcelo Cerri
Hi, any news on that?

On Tue, Oct 29, 2013 at 05:01:03PM -0200, Marcelo Cerri wrote:
 In some platforms, such as POWER, char is defined as unsigned. This
 patch fix a problem when comparing a char to -1.
 
 Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com
 ---
  crypto/ec/ec_pmeth.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/crypto/ec/ec_pmeth.c b/crypto/ec/ec_pmeth.c
 index e477418..933bf43 100644
 --- a/crypto/ec/ec_pmeth.c
 +++ b/crypto/ec/ec_pmeth.c
 @@ -319,7 +319,7 @@ static int pkey_ec_ctrl(EVP_PKEY_CTX *ctx, int type, int 
 p1, void *p2)
   case EVP_PKEY_CTRL_EC_ECDH_COFACTOR:
   if (p1 == -2)
   {
 - if (dctx-cofactor_mode != -1)
 + if (dctx-cofactor_mode != ((char) -1))
   return dctx-cofactor_mode;
   else
   {
 -- 
 1.7.12
 
 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org
 

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


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

2013-11-07 Thread 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


[openssl.org #3165] tru64-alpha-cc compatibility fixes

2013-11-07 Thread Daniel Richard G. via RT
I encountered a number of unusual (but mostly minor) errors in building
1.0.1e on Tru64 V4.0G, configuration tru64-alpha-cc. I've addressed the
majority of these in the 20131106 snapshot, and the changes are in the
attached patch. Here is a walk-through:

crypto/Makefile,
crypto/bn/Makefile,
crypto/modes/Makefile,
crypto/sha/Makefile:

* Using $ in an explicit rule is GNU Make territory; I was using the
  system-provided make(1), and the other *.s rules already don't use $

* Tru64 cc(1) can't preprocess stdin; it needs a file

* I'm not sure why tee(1) was being used here, but I removed it so that
  it doesn't mask a potential error from the preprocessor

crypto/evp/Makefile:

* Tru64 does have [, but make(1) interprets it in a bizarre way. Given
  a sample makefile like

blah:
[ -f blah ] || touch blah

  , you'll get

$ make
LOCK:  -f blah 
 || touch blah
sh: syntax error at line 1: `||' unexpected
*** Exit 2
Stop.

  (This doesn't happen if the [ is preceded by @, but I changed all
  three instances of [ for consistency)

crypto/srp/srp_grps.h:

* The Tru64 preprocessor doesn't like this magic. Here is a portion of
  srp_libs.c after preprocessing:

static  unsigned long  bn_group_1024_value[] = {
 0x9FC61D2FC0EB06E3ULL ,
 0xFD5138FE8376435BULL ,
 0x2FD4CBF4976EAA9AULL ,
 0x68E DBC3C05726CC0ULL ,
 0xC529F50E57E CULL ,
 0x82559B297BCF1885ULL ,
 0xCE8EF4AD69B15D49ULL ,
 0x5DC7D7B46154D6B6ULL ,
 0x8E495C1D6089DAD1ULL ,
 0xE0D5D8E250B98BE4ULL ,
 0x383B4813D692C6E0ULL ,
 0xD674DF7496E A81D3ULL ,
 0x9E A2314C9C256576ULL ,
 0x6072618775FF3C0BULL ,
 0x9C33F80AFA8FC5E8ULL ,
 0xEEAF0AB9ADB38DD6ULL 
};

  The pattern behind the random spaces becomes a little clearer if you
  remove the token-joins from the definition of bn_pack4():

#  define bn_pack4(a1,a2,a3,a4) 0x a1 a2 a3 a4 ULL

  yields

static  unsigned long  bn_group_1024_value[] = {
 0x 9FC6 1D2F C0EB 06E3 ULL ,
 0x FD51 38FE 8376 435B ULL ,
 0x 2FD4 CBF4 976E AA9A ULL ,
 0x 68E D BC3C 0572 6CC0 ULL ,
 0x C529 F566 660E 57E C ULL ,
 0x 8255 9B29 7BCF 1885 ULL ,
 0x CE8E F4AD 69B1 5D49 ULL ,
 0x 5DC7 D7B4 6154 D6B6 ULL ,
 0x 8E49 5C1D 6089 DAD1 ULL ,
 0x E0D5 D8E2 50B9 8BE4 ULL ,
 0x 383B 4813 D692 C6E0 ULL ,
 0x D674 DF74 96E A 81D3 ULL ,
 0x 9E A2 314C 9C25 6576 ULL ,
 0x 6072 6187 75FF 3C0B ULL ,
 0x 9C33 F80A FA8F C5E8 ULL ,
 0x EEAF 0AB9 ADB3 8DD6 ULL 
};

  Notice how the spaces are always preceded by /[0-9]+E/, and followed
  by a letter or space. The preprocessor is recognizing e.g. 68E as an
  integer-literal-with-exponent, and when this is followed by an
  (invalid) letter for the exponent, it adds a space.

  My workaround is to make bn_pack4() use bit shifts and ORs instead of
  preprocessor operations, and prepend 0x to all the hex constants in
  bn_group_*_value[]. A better solution might be to have the different
  forms of the tables generated by a Perl script.

e_os.h:

* Tru64 has AF_INET6 and PF_INET6, but no sockaddr_in6; checking for an
  additional IPv6 symbol here is enough to get the correct result

util/shlib_wrap.sh:

* /bin/sh on this system expands an empty $@ to  instead of nothing


After all this, there are still a couple of problems:

making all in crypto/modes...
cc -c -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  
-DOPENSSL_THREADS -pthread -DDSO_DLFCN -DHAVE_DLFCN_H -std1 -tune host -fast 
-readonly_strings -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DGHASH_ASM -c -o 
ghash-alpha.o ghash-alpha.s
as1: Error: pre-ghash-alpha.s, line 557: Redefinition of symbol: 
rem_4bit
as1: Error: pre-ghash-alpha.s, line 566: Redefinition of symbol: 
rem_4bit
*** Exit 1

I've no idea where this assembly error is coming from. It's not obvious
from the code.

../util/shlib_wrap.sh ./gost2814789t
Testing GOST 28147-89 Engine test t=3 derive key error.
*** Exit 12

Don't know what to do with this one. But according to make -i, it's
the only test that fails.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

diff -ru openssl-SNAP-20131106/crypto/Makefile openssl-SNAP-20131106-new/crypto/Makefile
--- openssl-SNAP-20131106/crypto/Makefile	2013-03-04 10:00:03.0 -0500
+++ openssl-SNAP-20131106-new/crypto/Makefile	2013-11-06 14:31:12.0 -0500
@@ -86,7 +86,8 @@
 ppccpuid.s:	ppccpuid.pl;	$(PERL) 

[openssl.org #3166] RE: Possible bug/leak in OpenSSL ssl/bio_ssl.c:ssl_ctrl(BIO_CTRL_POP)

2013-11-07 Thread Tom Maher via RT
Part of the problem reported here was resolved, namely the reference
count increment/decrement.

However, there is still a problem but I have a simple patch that fixes
it.

The problem is that the SSL may have the bbio in place when the pop
happens. If that is the case, then rbio != wbio and the
BIO_free_all(ssl-wbio) leads to two double frees later (the bbio and
the rbio). The fix is to remove the bbio is it in place. It doesn't need
to be freed, SSL_free will do that.

From openssl-1.0.1e/ssl/bio_ssl.c:

case BIO_CTRL_POP:
/* Only detach if we are the BIO explicitly being popped
*/
if (b == ptr)
{
   if (ssl-bbio  ssl_p-bbio == ssl_p-wbio)
  ssl_p-wbio = BIO_POP(ssl_p-wbio);

/* Shouldn't happen in practice because the
 * rbio and wbio are the same when pushed.
 */
if (ssl-rbio != ssl-wbio)
BIO_free_all(ssl-wbio);
if (b-next_bio != NULL)
 
CRYPTO_add(b-next_bio-references,-1,CRYPTO_LOCK_BIO);
ssl-wbio=NULL;
ssl-rbio=NULL;
}
break;

Regards,
Tom Maher

-Original Message-
From: Tom Maher 
Sent: 19 May 2006 15:15
To: r...@openssl.org
Subject: Possible bug/leak in OpenSSL
ssl/bio_ssl.c:ssl_ctrl(BIO_CTRL_POP)


I suspect that there may be a bug in ssl/bio_ssl.c (OpenSSL 0.9.7j - and
earlier versions).

In a BIO_CTRL_PUSH, the next_bio-references is incremented.
In a BIO_CTRL_POP, the next_bio-references is also incremented.
Shouldn't it be decremented.

To worked around it I am using a BIO_free_all() instead of a BIO_pop(),
which is probably the recommened way, but I thought I should report the
possibility of a bug that could lead to memory leaks (in my case I was
leaking the BIO's under my SSL's).


static long ssl_ctrl(BIO *b, int cmd, long num, void *ptr)
{
...

case BIO_CTRL_PUSH:
if ((b-next_bio != NULL)  (b-next_bio != ssl-rbio))
{
SSL_set_bio(ssl,b-next_bio,b-next_bio);
 
CRYPTO_add(b-next_bio-references,1,CRYPTO_LOCK_BIO);
}
break;
case BIO_CTRL_POP:
/* ugly bit of a hack */
if (ssl-rbio != ssl-wbio) /* we are in trouble :-( */
{
BIO_free_all(ssl-wbio);
}
if (b-next_bio != NULL)
{

CRYPTO_add(b-next_bio-references,1,CRYPTO_LOCK_BIO);

CRYPTO_add(b-next_bio-references,-1,CRYPTO_LOCK_BIO);
}
ssl-wbio=NULL;
ssl-rbio=NULL;
break;

...
}


Regards,
Tom Maher

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


Re: [PATCH] ec/ec_pmeth.c: fix unsigned char issue

2013-11-07 Thread Dr. Stephen Henson
On Thu, Nov 07, 2013, Marcelo Cerri wrote:

 Hi, any news on that?
 
 On Tue, Oct 29, 2013 at 05:01:03PM -0200, Marcelo Cerri wrote:
  In some platforms, such as POWER, char is defined as unsigned. This
  patch fix a problem when comparing a char to -1.
  
  Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com
  ---
   crypto/ec/ec_pmeth.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  diff --git a/crypto/ec/ec_pmeth.c b/crypto/ec/ec_pmeth.c
  index e477418..933bf43 100644
  --- a/crypto/ec/ec_pmeth.c
  +++ b/crypto/ec/ec_pmeth.c
  @@ -319,7 +319,7 @@ static int pkey_ec_ctrl(EVP_PKEY_CTX *ctx, int type, 
  int p1, void *p2)
  case EVP_PKEY_CTRL_EC_ECDH_COFACTOR:
  if (p1 == -2)
  {
  -   if (dctx-cofactor_mode != -1)
  +   if (dctx-cofactor_mode != ((char) -1))
  return dctx-cofactor_mode;
  else
  {
  -- 
  1.7.12
  

Does making cofactor mode signed char also fix this for you?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL client DH group limits

2013-11-07 Thread Kurt Roeckx
On Tue, Nov 05, 2013 at 11:43:54PM -0500, Daniel Kahn Gillmor wrote:
 I noticed recently that OpenSSL as a client is happy to connect to a
 server that offers a trivially-crackable DH group.
 
 You can try it out at https://demo.cmrg.net/
 
 Other modern TLS implementations will refuse to connect to this server
 because the DHE group is only 16 bits.  OpenSSL happily connects and
 does not inform the user that their expected message authenticity and
 confidentiality and integrity guarantees are not being met.  I consider
 this a security failure in the key exchange, just as i would consider it
 a failure for OpenSSL to silently accept a known-broken cipher or MAC
 from its peer.
 
 I'd like to propose that the OpenSSL client implementation reject
 connections to peers that offer DH groups  1024 bits, rather than
 failing open.  The attached patch should have this effect.

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

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


Kurt

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


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

2013-11-07 Thread Salz, Rich
I think a better way to do this would be to have a config param that set the 
minimum acceptable size. I.e., a #define

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA



-Original Message-
From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On 
Behalf Of Daniel Kahn Gillmor via RT
Sent: Thursday, November 07, 2013 6:55 AM
Cc: openssl-dev@openssl.org
Subject: [openssl.org #3164] [PATCH] require DH group of 1024 bits 

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.org #3164] [PATCH] require DH group of 1024 bits

2013-11-07 Thread Dr. Stephen Henson
On Thu, Nov 07, 2013, Salz, Rich wrote:

 I think a better way to do this would be to have a config param that set the
 minimum acceptable size. I.e., a #define
 

I think the best option is to have a compile time default with a runtime
override for this and other related issues. The idea being that an
application wont by accident use weak parameters but if (for whatever reason) 
it really wants to it can override this.

I hope to look at adding a more comprehensive set of checks for other issues
with an appropriate API to support it.

In general we could exclude anything with less than (say) 80 bits security
strength by default with the overrides mentioned above.

That would cover both attempts to configure such parameters (e.g. server gets
an error when an attempt is made to configure weak parameters) and attempts to
use them (client receives weak parameters from a server).

I'd be interested in suggestions for other related issues, for example:

1. Keys in certificate chains. For example 512 bit RSA keys. Again best a
client can do is to reject them.

2. Use of weak ciphersuites. Does anyone still want/need export ciphersuites?
For this we could not include weak ciphersuites in ClientHello on the client
side and the server not pick them if a client indicates support.

3. Use of algorithms with known security weaknesses: for example MD5 in
certificates. We already exclude MD2.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Need get() and clear() functions for chain_certs in 1.0.2-dev

2013-11-07 Thread Rob Stradling

On 06/11/13 17:27, Dr. Stephen Henson wrote:

On Wed, Nov 06, 2013, Rob Stradling wrote:


These 2 #defines exist for SSL_CTX-extra_certs:
   SSL_CTX_add_extra_chain_cert
   SSL_CTX_get_extra_chain_certs
   SSL_CTX_clear_extra_chain_certs

In 1.0.2-dev, the #defines such as SSL_CTX_add0_chain_cert allow me
to specify different chains for different certificate types, but
AFAICT there are no associated get() or clear() functions.

I can't see a way to squeeze a standalone SSL_CTX_get_chain_certs
function into SSL_CTX_ctrl().  There's only 1 pointer argument
available, so I can't pass in an X509* (to indicate which cert I
want the chain for) and get back a STACK_OF(X509)* (the chain).

One option would be to have another SSL_CTX_ctrl #define called
SSL_CTX_get_cert_type, which would accept an X509* and return the
index of that cert (i.e. SSL_CTX-CERT-pkeys[index]-x509), or -1
if not found.  That index could then be passed to
SSL_CTX_get_chain_certs in the larg argument.
However, since the SSL_PKEY_* #defines are private (in ssl_locl.h),
I'm unsure whether exposing these values in the public APIs would be
acceptable.

The other option would be to write SSL_CTX_get_chain_certs() as a
proper function (instead of a SSL_CTX_ctrl #define), but I'm unsure
whether or not that would be better than the first option.

Any preference?


The index for certificates could change in future so I'd rather not expose it
in a public API.


Agreed.  I can imagine some future version of OpenSSL being able to 
accommodate several ECC certs, each with a key on a different named 
curve, for example.



OpenSSL has the concept of a current certificate which could be used here.
This refers to the last certificate set. So you'd have (for example) a way to
retrieve extra chain certificates for the current certificate.

For that to work properly you'd also have to have a way to set the current
certtificate, without the risk of disturbing the existing structure.

So perhaps something like:

int SSL_set_current_cert(SSL *ssl, X509 *x);


Works for me.  :-)

I think the word select instead of set in that function name might 
help to make its purpose slightly clearer.  (I can imagine someone who 
doesn't like reading man pages thinking this function will do the same 
thing as SSL_use_certificate() ).



Which returns 1 and sets the current certificate to one containing 'x' if a
match is found and returns 0 and does nothing if no match is found. Also with
an SSL_CTX version.


Does the attached patch (against the master branch) look acceptable?

Thanks.

--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online

diff --git a/doc/ssl/SSL_CTX_add1_chain_cert.pod b/doc/ssl/SSL_CTX_add1_chain_cert.pod
index 04f7526..2d2161a 100644
--- a/doc/ssl/SSL_CTX_add1_chain_cert.pod
+++ b/doc/ssl/SSL_CTX_add1_chain_cert.pod
@@ -3,9 +3,11 @@
 =head1 NAME
 
 SSL_CTX_set0_chain, SSL_CTX_set1_chain, SSL_CTX_add0_chain_cert,
-SSL_CTX_add1_chain_cert, SSL_set0_chain, SSL_set1_chain,
-SSL_add0_chain_cert, SSL_add1_chain_cert, SSL_CTX_build_cert_chain,
-SSL_build_cert_chain - extra chain certificate processing
+SSL_CTX_add1_chain_cert, SSL_CTX_get0_chain_certs, SSL_CTX_clear_chain_certs,
+SSL_set0_chain, SSL_set1_chain, SSL_add0_chain_cert, SSL_add1_chain_cert,
+SSL_get0_chain_certs, SSL_clear_chain_certs, SSL_CTX_build_cert_chain,
+SSL_build_cert_chain, SSL_CTX_select_current_cert,
+SSL_select_current_cert - extra chain certificate processing
 
 =head1 SYNOPSIS
 
@@ -13,36 +15,58 @@ SSL_build_cert_chain - extra chain certificate processing
 
  int SSL_CTX_set0_chain(SSL_CTX *ctx, STACK_OF(X509) *sk);
  int SSL_CTX_set1_chain(SSL_CTX *ctx, STACK_OF(X509) *sk);
- int SSL_CTX_add0_chain_cert(SSL_CTX *ctx, STACK_OF(X509) *x509);
+ int SSL_CTX_add0_chain_cert(SSL_CTX *ctx, X509 *x509);
  int SSL_CTX_add1_chain_cert(SSL_CTX *ctx, X509 *x509);
+ int SSL_CTX_get0_chain_certs(SSL_CTX *ctx, STACK_OF(X509) **sk);
+ int SSL_CTX_clear_chain_certs(SSL_CTX *ctx);
 
  int SSL_set0_chain(SSL *ssl, STACK_OF(X509) *sk);
  int SSL_set1_chain(SSL *ssl, STACK_OF(X509) *sk);
- int SSL_add0_chain_cert(SSL *ssl, STACK_OF(X509) *x509);
+ int SSL_add0_chain_cert(SSL *ssl, X509 *x509);
  int SSL_add1_chain_cert(SSL *ssl, X509 *x509);
+ int SSL_get0_chain_certs(SSL *ssl, STACK_OF(X509) **sk);
+ int SSL_clear_chain_certs(SSL *ssl);
 
  int SSL_CTX_build_cert_chain(SSL_CTX *ctx, flags);
- int SSL_build_cert_chain(SSL_CTX *ctx, flags);
+ int SSL_build_cert_chain(SSL *ssl, flags);
+
+ int SSL_CTX_select_current_cert(SSL_CTX *ctx, X509 *x509);
+ int SSL_select_current_cert(SSL *ssl, X509 *x509);
 
 =head1 DESCRIPTION
 
 SSL_CTX_set0_chain() and SSL_CTX_set1_chain() set the certificate chain
-associated with the current certificate of Bctx to Bsk. If Bsk is set
-to BNULL any existing chain is cleared.
+associated with the current certificate of Bctx to Bsk.
 
 SSL_CTX_add0_chain_cert() and SSL_CTX_add1_chain_cert() append the single
 certificate Bx509 to the chain 

[openssl.org #3167] openssl pkcs8 does not convert from PKCS8 to traditional format private key

2013-11-07 Thread Michael Slass via RT
[slass@jenkins01 ~]$ openssl version
OpenSSL 1.0.0-fips 29 Mar 2010
[slass@jenkins01 ~]$ uname -a
Linux jenkins01 2.6.32-358.18.1.el6.x86_64 #1 SMP Wed Aug 28 17:19:38
UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[slass@jenkins01 ~]$

According to the docs:
http://www.openssl.org/docs/apps/pkcs8.html

=
DESCRIPTION

The pkcs8 command processes private keys in PKCS#8 format. It can
handle both unencrypted PKCS#8 PrivateKeyInfo format and
EncryptedPrivateKeyInfo format with a variety of PKCS#5 (v1.5 and
v2.0) and PKCS#12 algorithms.



COMMAND OPTIONS

-topk8

Normally a PKCS#8 private key is expected on input and a traditional
format private key will be written. With the -topk8 option the
situation is reversed: it reads a traditional format private key and
writes a PKCS#8 format key.



*
BUG: The Normally behavior, that is PKCS8 in, traditional format
private key out does not work.
The actual behavior is PKCS8 in, PKCS8 out.
**

Transcript showing unexpected behavior:

# generate a 2048 bit RSA key
[slass@jenkins01 ~]$ openssl genrsa -out bogus.key 2048
Generating RSA private key, 2048 bit long modulus
.+++
.+++
e is 65537 (0x10001)
[slass@jenkins01 ~]$ cat bogus.key
-BEGIN RSA PRIVATE KEY-
MIIEowIBAAKCAQEAq6cIq+H9v08l0660A8zi5wr4rVevIMZaazw7mdOcHwwuRECH
3u77bMULhwdXlbL9OhDmq1NcUlM183ymCnAldv1xoSmdvx1greHOpIOgJ7wJOWkh
F86EFNJaDgl59U6KZqJ4/4rShrrYtvyREzEzBGtwhB5vzLFzuCEAF6akWPSIPv51
l46DW+110BVbDKf9iHW3TudaqWQA6wrH+4t7ry+sqXPSt3vtDMK+mMwNLOf7DC6R
ynbSDXk2IbEsE5TFy0uvAQyi1jENuU4l69l/CvPabjCMEOah5mKeAgat1fulLvsK
XmeivUZpZYSH22tHWqfylPVwoHspb3MMfclOTQIDAQABAoIBAGKPMB1xT3+PdIrN
HzOnawl6dTsiw72v5q74EMjMhjIVjmNGIj3RPrA/m9TWVGXyNhAnMCtjW/kxKiM6
iSQpLHncIGiHOrpHpgFxTHON2GG4SBucz5GZ1KEX/vlcW5iMlk9ELvGbxjHyCwlW
j/5TG5YIErzptQv1QBqTaDgsSOWB4Tcy/m9v+6c8P47ZOKBlALBsHJG0ktLreacB
prRI8/rRPALxe6vw7dcjs6h9GzQqRKcJrj4bcYqIwD9qjDV9MOjFk8Yr7aLPNWX5
tbwOrUPyleAveOeUR56FI0LVR9Dgq6QrATGFNBlACGxFs5zr23dNkzH4oEMfISGB
EAt0SIECgYEA5D7wvUyMsJzot6lUe9dAoFnPWpN1i6cRA0RDUzFC2EP359Vz6shj
CfPUf5J7HN5yZyjQdV0GrAuZY36EVCjuLvf0FIqT11Fg6cbYZrdYUkmMidhjVzhp
9qLtdur0vqt89EuTciDkuwe7FSYSu8zxoDUeoAlja/DMi8J8G0oa430CgYEAwIZm
QfiJjQiS+epyEY3VL4KfJOvEEWImfqlv447zGDc4bg92RoOsJeqzNB/1ZgS0MA0D
iimkBH7YTo+sEEllATZgz5+v3EbN03HqOzMdLJMI5x5YCUx8L0PcVGmWd6zyjrsq
tiEjyXkhyc2S3GE0TLZQAofKAY79mRYHtUNhbxECgYAAjqbHz4gIZlmrGR67rqrZ
uV5oOjPvQ1knSONhMJ2ZKZFRX5QI3rRfMdky9oiWaXSeC9t2beO2R9D4DTcFfZQX
SUOvSSdTPz+dUn70wT3V9ZgCPiT/8YNQttUdlTVDwedsMUMK5Emqqzopsw4Yp0dv
vLF2co9rlArrzG3BI00tgQKBgCNoVGQrpniGrClEYegykpOjTUuIBM5Bo9zFoqtS
PgklFr6/HzyGuOFcUcrzWbmCgfUYX59IWz7saTHBoJ56MRZQ/usQblJvvyj1GWP7
2ZC6FfgTj5NeOrSioWHw7VhjOVTgvVEztRY3rewkX68iPXEiUoK0oIU63A8Miyxe
EQxRAoGBAL590zYRB8UZmj6KwNrHKoKgmqDa8N7YbmQnyTPvtjbNd/O3ZDKOj7Fw
8R8H51oIjDiyprQvVSICggJpdq59V8mA/oHISxL/ZGC9CH2XTQPDH9+Lne9ZJeTz
BzGfQmNQ/2VkeAOhPdALPonypencNTMY8+4VY6ygME/sAVpg8EQS
-END RSA PRIVATE KEY-

# create an (unencrypted) PKCS8 object from the private key
[slass@jenkins01 ~]$ openssl pkcs8 -nocrypt -topk8 -in bogus.key -out
bogus.key.pkcs8
[slass@jenkins01 ~]$ cat bogus.key.pkcs8
-BEGIN PRIVATE KEY-
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCrpwir4f2/TyXT
rrQDzOLnCvitV68gxlprPDuZ05wfDC5EQIfe7vtsxQuHB1eVsv06EOarU1xSUzXz
fKYKcCV2/XGhKZ2/HWCt4c6kg6AnvAk5aSEXzoQU0loOCXn1Topmonj/itKGuti2
/JETMTMEa3CEHm/MsXO4IQAXpqRY9Ig+/nWXjoNb7XXQFVsMp/2IdbdO51qpZADr
Csf7i3uvL6ypc9K3e+0Mwr6YzA0s5/sMLpHKdtINeTYhsSwTlMXLS68BDKLWMQ25
TiXr2X8K89puMIwQ5qHmYp4CBq3V+6Uu+wpeZ6K9RmllhIfba0dap/KU9XCgeylv
cwx9yU5NAgMBAAECggEAYo8wHXFPf490is0fM6drCXp1OyLDva/mrvgQyMyGMhWO
Y0YiPdE+sD+b1NZUZfI2ECcwK2Nb+TEqIzqJJCksedwgaIc6ukemAXFMc43YYbhI
G5zPkZnUoRf++VxbmIyWT0Qu8ZvGMfILCVaP/lMblggSvOm1C/VAGpNoOCxI5YHh
NzL+b2/7pzw/jtk4oGUAsGwckbSS0ut5pwGmtEjz+tE8AvF7q/Dt1yOzqH0bNCpE
pwmuPhtxiojAP2qMNX0w6MWTxivtos81Zfm1vA6tQ/KV4C9455RHnoUjQtVH0OCr
pCsBMYU0GUAIbEWznOvbd02TMfigQx8hIYEQC3RIgQKBgQDkPvC9TIywnOi3qVR7
10CgWc9ak3WLpxEDRENTMULYQ/fn1XPqyGMJ89R/knsc3nJnKNB1XQasC5ljfoRU
KO4u9/QUipPXUWDpxthmt1hSSYyJ2GNXOGn2ou126vS+q3z0S5NyIOS7B7sVJhK7
zPGgNR6gCWNr8MyLwnwbShrjfQKBgQDAhmZB+ImNCJL56nIRjdUvgp8k68QRYiZ+
qW/jjvMYNzhuD3ZGg6wl6rM0H/VmBLQwDQOKKaQEfthOj6wQSWUBNmDPn6/cRs3T
ceo7Mx0skwjnHlgJTHwvQ9xUaZZ3rPKOuyq2ISPJeSHJzZLcYTRMtlACh8oBjv2Z
Fge1Q2FvEQKBgACOpsfPiAhmWasZHruuqtm5Xmg6M+9DWSdI42EwnZkpkVFflAje
tF8x2TL2iJZpdJ4L23Zt47ZH0PgNNwV9lBdJQ69JJ1M/P51SfvTBPdX1mAI+JP/x
g1C21R2VNUPB52wxQwrkSaqrOimzDhinR2+8sXZyj2uUCuvMbcEjTS2BAoGAI2hU
ZCumeIasKURh6DKSk6NNS4gEzkGj3MWiq1I+CSUWvr8fPIa44VxRyvNZuYKB9Rhf

Re: OpenSSL client DH group limits

2013-11-07 Thread 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