[openssl-dev] [openssl.org #4174] Support the TLS Feature (aka Must Staple) X.509v3 extension (RFC7633)

2015-12-07 Thread Rob Stradling via RT
https://github.com/openssl/openssl/pull/495

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

___
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] [openssl.org #4043] monitoring software depending onopenssl not working on cloudflare ssl websites

2015-09-15 Thread Rob Stradling via RT
Hi Horatiu.  To connect to a site that uses CloudFlare Universal SSL
[1], you need to specify the SNI (Server Name Indication) header.
Modern browsers do this by default, but for s_client you need to do this...

openssl s_client -connect :443 -servername 

This isn't an OpenSSL bug, so I suggest closing this ticket.


[1] https://blog.cloudflare.com/introducing-universal-ssl/

On 15/09/15 15:33, Horatiu N via RT wrote:
> Greetings,
> 
> Using the nagios plugins (latest debian package for 8.1) to check
> availability of https websites using cloudflare gives errors
>> CRITICAL - Cannot make SSL connection.
>> 139729452828304:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 
>> alert internal error:s23_clnt.c:770:
> 
> same goes if i attempt to run
>> openssl s_client -connect :443 
> 
> This basically makes monitoring impossible at this time,
> Any idea how to remedy this situation ?
> 
> i attached a textfile with sample domains as extracted from the
> certificate's "Certificate Subject alt name"
> it's reproducible on any target as long as it's online
> 
> openssl version
>> OpenSSL 1.0.1k 8 Jan 2015
> 
> 
> dpkg -l openssl
>> ii  openssl 1.0.1k-3+deb8u1amd64  Secure 
>> Sockets Layer toolkit - cryptographic utility
> 
> tried also to compile the newest one from openssl.org and use it, same
> problem.

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


___
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 forOpenSSL 1.0.1l (and 1.0.1k)

2015-01-19 Thread Rob Stradling via RT
On 19/01/15 14:47, Stephen Henson via RT wrote:
 On Mon Jan 19 14:40:32 2015, steve wrote:

 The problem is that the two fields containing the signature algorithm
 do not match.

 The current 'x509' utility can't show this difference (I have an option I'm
 testing which will).

Steve, while you're there...

I've been caught out a few times in the past because the 'x509' utility 
displays the outer signature algorithm in the place where it should 
display the inner signature algorithm.  This is fine when they match, 
but it's rather unhelpful when they don't match!

Please consider this trivial patch.  Thanks.

diff --git a/crypto/asn1/t_x509.c b/crypto/asn1/t_x509.c
index 89115c7..97abd51 100644
--- a/crypto/asn1/t_x509.c
+++ b/crypto/asn1/t_x509.c
@@ -168,7 +168,7 @@ int X509_print_ex(BIO *bp, X509 *x, unsigned long 
nmflags, unsigned long cflag)

 if(!(cflag  X509_FLAG_NO_SIGNAME))
 {
-   if(X509_signature_print(bp, x-sig_alg, NULL) = 0)
+   if(X509_signature_print(bp, ci-signature, NULL) = 0)
 goto err;
  #if 0
 if (BIO_printf(bp,%8sSignature Algorithm: ,) = 0)

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


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


Re: [openssl.org #3516] OCSP Certificate Chain Response Handling

2014-09-09 Thread Rob Stradling

Duplicate of #2206 ?

On 05/09/14 08:35, Mehner, Carl via RT wrote:

OCSP response handling in /apps/ocsp.c
--
2014-06-25

The OCSP Documentation States
https://www.openssl.org/docs/apps/ocsp.html
Otherwise the OCSP responder certificate's CA is checked against the issuing CA 
certificate in the request. If there is a match and the OCSPSigning extended key usage is 
present in the OCSP responder certificate then the OCSP verify succeeds.

--Assumptions--
The flag '-issuer' in openSSL's ocsp application is what the responder's 
certificate's CA is checking against.
The 'responder's certificate's CA' means the certificate authority that is 
issuer of the ocsp signing certificate.


--What Happens--
When running the command:
openssl ocsp -no_nonce -issuer intermediary.cer -cert leaf.cer -CA root.cer 
-url http://ocsp.url

Validation of the OCSP responder certificate fails unless the issuer's cert is 
also in the file containing the root CA cert. The error messages are:
Response Verify Failure
8604:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify 
error:.\crypto\ocsp\ocsp_vfy.c:126:Verify error:unable to get local issuer 
certificate

However, if you specify a -CAfile that includes the same cert from the 
'-issuer' flag and the root CA cert that is the root of trust for the ocsp 
responder cert, you will get back a 'Response verify OK'

--What Should Happen--
If the certificate provided in the '-issuer' flag matches the CA certificate 
referenced in the OCSP responder's issuer field, the OCSP verify should succeed.

There should be no need to chain up to the root in this case as it would be a 
waste of time since that evaluation is already done on the issuer certificate 
provided with the '-issuer' flag when evaluating the chain of the certificate 
provided by the '-cert' flag outside of the OCSP validation process. If the 
leaf validation fails, there is no need to validate the OCSP chain, the 
connection will fail regardless.

However, if the anyone feels that the full chain needs to be validated, the 
validation procedure should be able to bridge the cert included on the 
'-issuer' flag with a single root specified on the '-CA' flag. (It currently 
does not.)

-cem


--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: [openssl.org #2354] [PATCH] Increase Default RSA Key Size to 2048-bits

2014-09-09 Thread Rob Stradling
This can presumably be resolved as fixed, given the commit on #2626 just 
now.


On 29/09/10 20:54, Rob Stradling via RT wrote:

NIST (SP800-57 Part 1) recommends a minimum RSA key size of 2048-bits beyond
2010.  From January 1st 2011, in order to comply with the current Microsoft[1]
and Mozilla[2] CA Policies, Commercial CAs will no longer be permitted to
issue certificates with RSA key sizes of 2048-bit.

Please accept the attached patch, which increases the default RSA key size to
2048-bits for the req, genrsa and genpkey apps.

Thanks.

[1] http://technet.microsoft.com/en-us/library/cc751157.aspx says:
we have advised Certificate Authorities...to transition their subordinate and
end-certificates to 2048-bit RSA certificates, and to complete this transition
for any root certificate distributed by the Program no later than December 31,
2010.

[2] https://wiki.mozilla.org/CA:MD5and1024 says:
December 31, 2010 – CAs should stop issuing intermediate and end-entity
certificates from roots with RSA key sizes smaller than 2048 bits. All CAs
should stop issuing intermediate and end-entity certificates with RSA key size
smaller than 2048 bits under any root.

Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.



--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

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


Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

2014-05-02 Thread Rob Stradling

See also this thread:
http://www.ietf.org/mail-archive/web/tls/current/msg12143.html

On 01/05/14 11:29, Marcus Meissner via RT wrote:

Hi,

SUSE has received a bugreport from a user, that the padding extension
change breaks IronPort SMTP appliances.

There might a RT on this already, not sure.

https://bugzilla.novell.com/show_bug.cgi?id=875639
http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html

Quoting from our openSUSE bugreport:

Last upgrade to openssl-1.0.1g-11.36.1.x86_64 broke SSL connections to some
services, e.g. Cisco Ironport SMTP appliances.

1.0.1g not only fixes the Heartbleed bug but also adds another change by
adding:
#define TLSEXT_TYPE_padding 21

This in turn breaks SSL connections to e.g. Ironports, probably others:
SSL23_GET_SERVER_HELLO:tlsv1 alert decode error

Workaround: Force protocol to SSLv3 or recompile without the define above.

For details, please refer to:
postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html


Reproducible: Always

Steps to Reproduce:
1. openssl s_client -connect some.ironport.com:25 -starttls smtp

Note: Send me an email for a hostname of an Ironport SMTP appliance to test
with. I don't want to disclose it here.
Actual Results:
CONNECTED(0003)
139718758192784:error:1407741A:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
decode error:s23_clnt.c:762:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 129 bytes and written 552 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---


Expected Results:
CONNECTED(0003)
---
Certificate chain
[...cut...]
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1
[...cut..-]
250 STARTTLS

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



--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

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


Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

2014-05-02 Thread Rob Stradling

On 01/05/14 12:26, Stephen Henson via RT wrote:

On Thu May 01 12:29:58 2014, meiss...@suse.de wrote:

Hi,

SUSE has received a bugreport from a user, that the padding
extension
change breaks IronPort SMTP appliances.

snip

Ironically it was added as a workaround for another bug. The padding extension
was believed to have no side effects... obviously that isn't true :-(

If you use a smaller cipherstring it should also work without having to force
SSLv3.


Steve, have you considered trimming the DEFAULT cipher list?

It's currently...
#define SSL_DEFAULT_CIPHER_LIST ALL:!aNULL:!eNULL:!SSLv2

I wonder how many of these ciphers are actually ever negotiated in 
real-world use.



The padding extension is only used if the ClientHello would be between 256 and
511 bytes in length so if you reduce the number of ciphersuites it wont be
used.


--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Questions on SSL_OP_SAFARI_ECDHE_ECDSA_BUG

2013-12-10 Thread Rob Stradling

On 09/12/13 23:34, Jeffrey Walton wrote:

Reference: 
http://openssl.6102.n7.nabble.com/openssl-org-3068-PATCH-Safari-broken-ECDHE-ECDSA-workaround-td45432.html
and http://openssl.6102.n7.nabble.com/Apple-are-apparently-dicks-td45512.html.

BL  ...and don't intend to fix their broken ECDSA support in Safari.
Apple really needs to fix their engineering process and broken
implementation. (And hire some QA personnel while they are at it...
This is something their lawyers can't fix with a change to their
license agreements).

Will the patch be applied to 0.9.8 and 1.0.1 branches?


It has been applied on those branches already.

http://git.openssl.org/gitweb/?p=openssl.git;a=shortlog;h=refs/heads/OpenSSL_0_9_8-stable
Committed on 2013-10-04.

http://git.openssl.org/gitweb/?p=openssl.git;a=shortlog;h=refs/heads/OpenSSL_1_0_0-stable
Committed on 2013-09-10.

http://git.openssl.org/gitweb/?p=openssl.git;a=shortlog;h=refs/heads/OpenSSL_1_0_1-stable
Committed on 2013-09-16.


If I can't wait for the patch in future stable releases (or don't want
to use SSL_OP_SAFARI_ECDHE_ECDSA_BUG), what are the other options? Can
I use a cipher_list to work around this? For example, can I prefer RSA
and DSS ciphers over ECDSA:

   const char* const PREFERRED_CIPHERS =

 /* TLS 1.2 only */
 ECDHE-RSA-AES256-GCM-SHA384:
 ECDHE-RSA-AES128-GCM-SHA256:

 /* TLS 1.2 only */
 DHE-DSS-AES256-GCM-SHA384:
 DHE-RSA-AES256-GCM-SHA384:
 DHE-DSS-AES128-GCM-SHA256:
 DHE-RSA-AES128-GCM-SHA256:

 /* TLS 1.2, see SSL_OP_SAFARI_ECDHE_ECDSA_BUG */
 ECDHE-ECDSA-AES256-GCM-SHA384:
 ECDHE-ECDSA-AES128-GCM-SHA256:


The broken versions of Safari/OSX don't support GCM (or DSS, I think), 
so enabling and even preferring ECDHE-ECDSA-AES256-GCM-SHA384 and 
ECDHE-ECDSA-AES128-GCM-SHA256 on your server shouldn't cause any problems.


If you can't wait for the patch, or don't want to use it, here are two 
workarounds that I think should work...


1. Ensure that these 4 ciphers are all disabled on your server (since 
these are the only ciphers that are affected by the Safari/OSX bug):

ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-RC4-SHA
ECDHE-ECDSA-DES-CBC3-SHA

or

2. If you want to enable 1 or more of those 4 ECDHE-ECDSA ciphers, 
ensure that your server prefers at least 1 of the following ciphers 
(that Safari/OSX also offers) ahead of them:

ECDH-RSA-AES128-SHA
ECDH-RSA-AES256-SHA
ECDH-RSA-RC4-SHA
ECDH-RSA-DES-CBC3-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA
ECDHE-RSA-RC4-SHA
ECDHE-RSA-DES-CBC3-SHA
AES128-SHA
RC4-SHA
RC4-MD5
AES256-SHA
DES-CBC3-SHA
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
EDH-RSA-DES-CBC3-SHA

(Obviously you'll need 2 server certificates, one with an RSA key and 
one with an ECC key).


--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


[openssl.org #3169] [PATCH] Additional chain_cert functions for 1.0.2-dev

2013-11-11 Thread Rob Stradling via RT
This patch, which currently applies successfully against master and 
1_0_2, adds the following functions:

SSL_[CTX_]select_current_cert() - set the current certificate without 
disturbing the existing structure.

SSL_[CTX_]get0_chain_certs() - get the current certificate's chain.

SSL_[CTX_]clear_chain_certs() - clear the current certificate's chain.

The patch also adds these functions to, and fixes some existing errors 
in, SSL_CTX_add1_chain_cert.pod.

-- 
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 associated with the current certificate of
 Bctx.
 
+SSL_CTX_get0_chain_certs() retrieves the chain associated with the current
+certificate of Bctx.
+
+SSL_CTX_clear_chain_certs() clears any existing chain associated with the
+current certificate of Bctx.  (This is implemented by calling
+SSL_CTX_set0_chain() with Bsk set to BNULL).
+
 SSL_CTX_build_cert_chain() builds the certificate chain for Bctx using the
 chain store. Any existing chain certificates are used as untrusted CAs.
 If the function is successful the built chain will replace any existing chain.
 The Bflags parameter can be set to BSSL_BUILD_CHAIN_FLAG_NO_ROOT to omit
 the root CA from the built chain.
 
-SSL_set0_chain(), SSL_set1_chain(), SSL_add0_chain_cert(), SSL_add0_chain_cert()
-and SSL_build_cert_chain() are similar except they apply to SSL structure
-Bssl.
+Each of these functions operates on the Icurrent end entity
+(i.e. server or client) certificate. This is the last certificate loaded or
+selected on the corresponding Bctx structure.
+
+SSL_CTX_select_current_cert() selects Bx509 as the current end entity
+certificate, but only if Bx509 has already been loaded into Bctx using a
+function such as SSL_CTX_use_certificate().
+
+SSL_set0_chain(), SSL_set1_chain(), SSL_add0_chain_cert(),
+SSL_add1_chain_cert(), SSL_get0_chain_certs(), SSL_clear_chain_certs(),
+SSL_build_cert_chain() and SSL_select_current_cert() are similar except they
+apply to SSL structure Bssl.
 
 All these functions are implemented as macros. Those containing a B1
 increment the reference count of the supplied certificate or chain so it must
@@ -56,10 +80,6 @@ The chains associate with an SSL_CTX structure are copied to any SSL
 structures when SSL_new() is called. SSL structures will not be affected
 by any chains subsequently changed in the parent SSL_CTX.
 
-Each of these functions operates on the Icurrent end entity
-(i.e. server or client) certificate. This is the last certificate set
-on the corresponding Bctx or Bssl structure.
-
 One chain can be set for each key type supported by a server. So, for example,
 an RSA

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

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

2013-11-06 Thread Rob Stradling

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?

Thanks.

--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


ECDHE problem with 1.0.2-dev

2013-11-01 Thread Rob Stradling
Hi.  When I build the latest development version of httpd or nginx 
against the OpenSSL_1_0_2-stable branch, the ECDHE-RSA and ECDHE-ECDSA 
ciphers don't work.  With both webservers, I can get these ciphers to 
work by either...

  1. Deleting: SSL_CTX_set_options(ctx, SSL_OP_SINGLE_ECDH_USE);
  or
  2. Adding: SSL_CTX_set_ecdh_auto(ctx, 1);

Should it still be possible to manually configure ECDH keys using 
SSL_CTX_set_tmp_ecdh() in 1_0_2?
If so, any ideas why it isn't working?  Is there a bug in 
OpenSSL_1_0_2-stable?  Or are both httpd and nginx doing something wrong?


Or, is SSL_CTX_set_ecdh_auto(ctx, 1); the only supported way of doing 
it in 1_0_2?


Thanks.

--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-18 Thread Rob Stradling

On 14/06/13 14:16, Ben Laurie wrote:

On 14 June 2013 14:08, Rob Stradling rob.stradl...@comodo.com wrote:

snip

Apparently the ECDHE-ECDSA bug is in SecureTransport, which is an integral
component of OSX.


https://developer.apple.com/library/mac/#documentation/security/Reference/secureTransportRef/Reference/reference.html
seems to suggest it is a library.


Ben, what else needs to happen before this patch is either committed or 
rejected?


Thanks.

--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-15 Thread Rob Stradling

On 14/06/13 15:25, Florian Weimer wrote:

On 06/14/2013 03:31 PM, Dr. Stephen Henson wrote:

Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared
libraries are updated to include the patch existing applications wont
set it:
they'd all need to be recompiled.


That's a valid point.


Possibly alternative is to reuse one of the existing *ancient* flags.
Does
anyone really care about compatibility with a bug in SSLeay 0.80 for
example?


Wouldn't it be better to reverse the meaning of the flag and not set it
in SSL_OP_ALL?


Just to complicate matters further, the 0x400 bit used to be set in 
SSL_OP_ALL, and has previously been used for at least 2 other purposes!


http://cvs.openssl.org/chngview?cn=18974
http://cvs.openssl.org/chngview?cn=22501

--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-14 Thread Rob Stradling

On 13/06/13 17:39, Ben Laurie wrote:

...and don't intend to fix their broken ECDSA support in Safari.


Ben, you've got your wires a bit crossed there.

The ECDHE-ECDSA ciphersuites are indeed broken in Safari on OSX 10.8 to 
10.8.3, but they are _fixed_ in OSX 10.8.4 (released last week).



It is therefore suggested that I pull this patch:

https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d

What do people think?


The unfortunate reality is that significant numbers of OSX 10.8.x users 
won't upgrade to 10.8.4 anytime soon, even though the upgrade is free 
and easy to install.


No server administrator will want to deploy ECDHE-ECDSA if it means 
breaking compatibility with even a small fraction of deployed browsers. 
 Hence why this patch is, unfortunately, necessary.


--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-14 Thread Rob Stradling

On 14/06/13 10:20, Ben Laurie wrote:

On 14 June 2013 09:39, Rob Stradling rob.stradl...@comodo.com wrote:

On 13/06/13 17:39, Ben Laurie wrote:


...and don't intend to fix their broken ECDSA support in Safari.


Ben, you've got your wires a bit crossed there.

The ECDHE-ECDSA ciphersuites are indeed broken in Safari on OSX 10.8 to
10.8.3, but they are _fixed_ in OSX 10.8.4 (released last week).


It is therefore suggested that I pull this patch:

https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d

What do people think?


The unfortunate reality is that significant numbers of OSX 10.8.x users
won't upgrade to 10.8.4 anytime soon, even though the upgrade is free and
easy to install.


Precisely my point - so how were my wires crossed?


Ah, so you're criticizing Apple for not being willing to force all OSX 
10.8.x users to update to 10.8.4.


If OSX 10.8.x has a mechanism that allows Apple to force updates to be 
installed, then I agree.  But my suspicion is that it doesn't, and if 
so, Apple's willingness isn't the key issue here.



No server administrator will want to deploy ECDHE-ECDSA if it means breaking
compatibility with even a small fraction of deployed browsers.  Hence why
this patch is, unfortunately, necessary.


What is _necessary_ is that Apple accept responsibility for their errors :-)


Agreed.

Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA bugfix.


Why are we chasing after them cleaning up their messes?


Because we want ECDHE-ECDSA to be deployable.

--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-14 Thread Rob Stradling

On 14/06/13 12:31, Ben Laurie wrote:

On 14 June 2013 12:25, Rob Stradling rob.stradl...@comodo.com wrote:

snip

Ah, so you're criticizing Apple for not being willing to force all OSX
10.8.x users to update to 10.8.4.


No.


If OSX 10.8.x has a mechanism that allows Apple to force updates to be
installed, then I agree.  But my suspicion is that it doesn't, and if so,
Apple's willingness isn't the key issue here.


It has a mechanism to nag you endlessly until you do install updates.
Which makes me wonder why you think people won't install the OS
update?


Safari's User-Agent string reveals the OSX version that it is running 
on.  A few weeks ago I analyzed some webserver logs to get an idea of 
historical OSX update rates.  Based on that analysis, I forecast that 
the majority of OSX 10.8.x users will install the 10.8.4 update, but 
that a significant minority won't.



No server administrator will want to deploy ECDHE-ECDSA if it means
breaking
compatibility with even a small fraction of deployed browsers.  Hence why
this patch is, unfortunately, necessary.



What is _necessary_ is that Apple accept responsibility for their errors
:-)



Agreed.

Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA bugfix.



Why are we chasing after them cleaning up their messes?



Because we want ECDHE-ECDSA to be deployable.


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





--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

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


Re: Apple are, apparently, dicks...

2013-06-14 Thread Rob Stradling

On 14/06/13 13:58, Ben Laurie wrote:

On 14 June 2013 13:57, Rob Stradling rob.stradl...@comodo.com wrote:

snip

Safari's User-Agent string reveals the OSX version that it is running on.  A
few weeks ago I analyzed some webserver logs to get an idea of historical
OSX update rates.  Based on that analysis, I forecast that the majority of
OSX 10.8.x users will install the 10.8.4 update, but that a significant
minority won't.


I guess then we need to know why? And would they upgrade Safari alone?


Apparently the ECDHE-ECDSA bug is in SecureTransport, which is an 
integral component of OSX.



No server administrator will want to deploy ECDHE-ECDSA if it means
breaking
compatibility with even a small fraction of deployed browsers.  Hence
why
this patch is, unfortunately, necessary.




What is _necessary_ is that Apple accept responsibility for their errors
:-)




Agreed.

Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA
bugfix.



Why are we chasing after them cleaning up their messes?




Because we want ECDHE-ECDSA to be deployable.


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





--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by
replying to the e-mail containing this attachment. Replies to this email may
be monitored by COMODO for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no
liability can be accepted and the recipient is requested to use their own
virus checking software.




--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

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


Re: Apple are, apparently, dicks...

2013-06-14 Thread Rob Stradling

On 14/06/13 13:54, The Doctor wrote:

On Thu, Jun 13, 2013 at 05:39:36PM +0100, Ben Laurie wrote:

...and don't intend to fix their broken ECDSA support in Safari.

It is therefore suggested that I pull this patch:

https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d

What do people think?


No keep the patch.


I think you misunderstood what Ben meant by pull.

See man git-pull

--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-14 Thread Rob Stradling

On 14/06/13 14:31, Dr. Stephen Henson wrote:
snip

The behavior change applies only if new option
SSL_OP_SAFARI_ECDHE_ECDSA_BUG is used (part of SSL_OP_ALL), as is standard
for interoperability bug workarounds, so while it is very unfortunate that
we'd need to do this, I'm in favor of accepting this patch.


Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared
libraries are updated to include the patch existing applications wont set it:
they'd all need to be recompiled.


Yep, but 0x400 is the only currently unallocated bit.


Possibly alternative is to reuse one of the existing *ancient* flags. Does
anyone really care about compatibility with a bug in SSLeay 0.80 for example?


I'd wondered about that.  If you're happy to reallocate one of the 
ancient flags, please do!


--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


[openssl.org #3068] [PATCH] Safari broken ECDHE-ECDSA workaround

2013-06-04 Thread Rob Stradling via RT
The Safari browser on OSX versions 10.8 to 10.8.3 advertises support for 
several ECDHE-ECDSA ciphers but fails to negotiate them.

When a Safari client connects to an OpenSSL-based server that has the 
attached patch (against the master branch) applied, the server will 
prefer other mutually supported ciphers above ECDHE-ECDSA ciphers.
This patch enables a webserver to have an ECC certificate together with 
an RSA and/or DSA certificate, and to offer ECDHE-ECDSA ciphers without 
fear of breaking compatibility with Safari clients.

The ssl_check_for_safari() function, which fingerprints Safari clients 
based on the TLS Extensions used, was written by Adam Langley.

A representative from Apple has told me that the Safari bug will be 
fixed in OSX 10.8.4.  However, since OSX users won't be forced to 
upgrade, I believe that a significant number of users will still be 
using affected Safari versions a few years from now.

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


diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
index 7ad8a54..fff73eb 100644
--- a/ssl/s3_lib.c
+++ b/ssl/s3_lib.c
@@ -3076,7 +3076,10 @@ void ssl3_clear(SSL *s)
 		OPENSSL_free(s-s3-tlsext_authz_client_types);
 		s-s3-tlsext_authz_client_types = NULL;
 		}
-#endif
+#ifndef OPENSSL_NO_EC
+	s-s3-is_probably_safari = 0;
+#endif /* OPENSSL_NO_EC */
+#endif /* OPENSSL_NO_TLSEXT */
 
 	rp = s-s3-rbuf.buf;
 	wp = s-s3-wbuf.buf;
@@ -4145,8 +4148,15 @@ SSL_CIPHER *ssl3_choose_cipher(SSL *s, STACK_OF(SSL_CIPHER) *clnt,
 		ii=sk_SSL_CIPHER_find(allow,c);
 		if (ii = 0)
 			{
-			ret=sk_SSL_CIPHER_value(allow,ii);
-			break;
+			if ((alg_k  SSL_kEECDH)  (alg_a  SSL_aECDSA)  s-s3-is_probably_safari)
+{
+if (!ret) ret=sk_SSL_CIPHER_value(allow,ii);
+}
+			else
+{
+ret=sk_SSL_CIPHER_value(allow,ii);
+break;
+}
 			}
 		}
 	return(ret);
diff --git a/ssl/ssl.h b/ssl/ssl.h
index e14a8d4..dd62578 100644
--- a/ssl/ssl.h
+++ b/ssl/ssl.h
@@ -568,6 +568,7 @@ struct ssl_session_st
 #define SSL_OP_SSLEAY_080_CLIENT_DH_BUG			0x0080L
 #define SSL_OP_TLS_D5_BUG0x0100L
 #define SSL_OP_TLS_BLOCK_PADDING_BUG			0x0200L
+#define SSL_OP_SAFARI_ECDHE_ECDSA_BUG			0x0400L
 
 /* Disable SSL 3.0/TLS 1.0 CBC vulnerability workaround that was added
  * in OpenSSL 0.9.6d.  Usually (depending on the application protocol)
@@ -578,7 +579,7 @@ struct ssl_session_st
 
 /* SSL_OP_ALL: various bug workarounds that should be rather harmless.
  * This used to be 0x000FL before 0.9.7. */
-#define SSL_OP_ALL	0x8BFFL
+#define SSL_OP_ALL	0x8FFFL
 
 /* DTLS options */
 #define SSL_OP_NO_QUERY_MTU 0x1000L
diff --git a/ssl/ssl3.h b/ssl/ssl3.h
index d8ed725..0b900b5 100644
--- a/ssl/ssl3.h
+++ b/ssl/ssl3.h
@@ -577,7 +577,14 @@ typedef struct ssl3_state_st
 	 * server echoed our server_authz extension and therefore must send us
 	 * a supplemental data handshake message. */
 	char tlsext_authz_server_promised;
-#endif
+
+#ifndef OPENSSL_NO_EC
+	/* This is set to true if we believe that this is a version of Safari
+	 * running on OS X 10.6 .. 10.8. We wish to know this because Safari
+	 * on 10.8 has broken ECDHE-ECDSA support. */
+	char is_probably_safari;
+#endif	/* OPENSSL_NO_EC */
+#endif	/* OPENSSL_NO_TLSEXT */
 	} SSL3_STATE;
 
 #endif
diff --git a/ssl/t1_lib.c b/ssl/t1_lib.c
index 31daa50..c5e2b85 100644
--- a/ssl/t1_lib.c
+++ b/ssl/t1_lib.c
@@ -1716,6 +1716,89 @@ unsigned char *ssl_add_serverhello_tlsext(SSL *s, unsigned char *p, unsigned cha
 	return ret;
 	}
 
+#ifndef OPENSSL_NO_EC
+/* ssl_check_for_safari attempts to fingerprint Safari using OS X
+ * SecureTransport using the TLS extension block in |d|, of length |n|.
+ * Safari, since 10.6, sends exactly these extensions, in this order:
+ *   SNI,
+ *   elliptic_curves
+ *   ec_point_formats
+ *
+ * We wish to fingerprint Safari because they broke ECDHE-ECDSA support in 10.8,
+ * but they advertise support. So enabling ECDHE-ECDSA ciphers breaks them.
+ * Sadly we cannot differentiate 10.6 and 10.7 (which work), from 10.8 (which
+ * doesn't).
+ */
+static void ssl_check_for_safari(SSL *s, const unsigned char *data, const unsigned char *d, int n) {
+	unsigned short type, size;
+	static const unsigned char kSafariExtensionsBlock[] = {
+		0x00, 0x0a,  /* elliptic_curves extension */
+		0x00, 0x08,  /* 8 bytes */
+		0x00, 0x06,  /* 6 bytes of curve ids */
+		0x00, 0x17,  /* P-256 */
+		0x00, 0x18,  /* P-384 */
+		0x00, 0x19,  /* P-521 */
+
+		0x00, 0x0b,  /* ec_point_formats */
+		0x00, 0x02,  /* 2 bytes */
+		0x01,/* 1 point format */
+		0x00,/* uncompressed */
+	};
+
+	/* The following is only present in TLS 1.2 */
+	static const unsigned char kSafariTLS12ExtensionsBlock[] = {
+		0x00, 0x0d,  /* signature_algorithms */
+		0x00, 0x0c,  /* 12 bytes */
+		0x00, 0x0a,  /* 10 bytes */
+		0x05, 0x01,  /* SHA-384/RSA */
+		0x04, 0x01,  /* SHA-256/RSA */
+		0x02, 0x01,  /* SHA-1/RSA */
+		0x04, 0x03

Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured

2012-10-05 Thread Rob Stradling via RT
On 21/09/12 15:38, Rob Stradling via RT wrote:
 On 21/09/12 15:12, Rob Stradling via RT wrote:
 On 21/09/12 15:04, Stephen Henson via RT wrote:
 snip
 Easiest solution is to also backport ssl_get_server_send_pkey see:

 http://cvs.openssl.org/chngview?cn=22840

 I didn't think of that.  Thanks!

 I'll prepare patches to backport 22840 to 1.0.0 and 0.9.8 (unless you or
 Ben get there first).

 http://cvs.openssl.org/patchset?cn=22840 applies cleanly (i.e. no failed
 hunks) on top of my patches for 1.0.0 and 0.9.8.

Steve,

Ben committed my patch to the 1.0.0 branch yesterday:
http://cvs.openssl.org/chngview?cn=22875

So, please would you now apply http://cvs.openssl.org/patchset?cn=22840 
to the 1.0.0 branch?

Thanks.

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


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


Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured

2012-09-24 Thread Rob Stradling

Hi Steve.

I saw your update (to 1.0.2 and HEAD), and I did start looking at 
backporting it into my 1.0.1/1.0.0/0.9.8 patches.


ssl_get_server_send_pkey() is not available in 1.0.1 and earlier, so the 
t1_lib.c patch would have to be something like...


+   X509 *x;
+   x = ssl_get_server_send_cert)s);
+   /* If no certificate can't return certificate status */
+   if (x == NULL)
+   {
+   s-tlsext_status_expected = 0;
+   return 1;
+   }
+   /* Set current certificate to one we will use so
+* SSL_get_certificate et al can pick it up.
+*/
+   s-cert-key-x509 = x;

Is it OK to update s-cert-key-x509 like this?


On 21/09/12 14:34, Stephen Henson via RT wrote:

[rob.stradl...@comodo.com - Fri Sep 21 15:02:54 2012]:

Attached are patches for 1.0.0 and 0.9.8.




Note, I updated the original change to retain compatibility with
existing behaviour as far as possible. See:

http://cvs.openssl.org/chngview?cn=22808

Steve.



--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured

2012-09-24 Thread Rob Stradling

On 21/09/12 15:04, Stephen Henson via RT wrote:

[rob.stradl...@comodo.com - Fri Sep 21 15:55:39 2012]:

Hi Steve.

I saw your update (to 1.0.2 and HEAD), and I did start looking at
backporting it into my 1.0.1/1.0.0/0.9.8 patches.

ssl_get_server_send_pkey() is not available in 1.0.1 and earlier, so the
t1_lib.c patch would have to be something like...

+   X509 *x;
+   x = ssl_get_server_send_cert)s);
+   /* If no certificate can't return certificate status */
+   if (x == NULL)
+   {
+   s-tlsext_status_expected = 0;
+   return 1;
+   }
+   /* Set current certificate to one we will use so
+* SSL_get_certificate et al can pick it up.
+*/
+   s-cert-key-x509 = x;

Is it OK to update s-cert-key-x509 like this?



No because you could end up with all sorts of bad things happening (keys
and certificates not matching, certificate types not matching and memory
leaks).


That's what I thought.


Easiest solution is to also backport ssl_get_server_send_pkey see:

http://cvs.openssl.org/chngview?cn=22840


I didn't think of that.  Thanks!

I'll prepare patches to backport 22840 to 1.0.0 and 0.9.8 (unless you or 
Ben get there first).


--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured

2012-09-24 Thread Rob Stradling

On 21/09/12 15:12, Rob Stradling via RT wrote:

On 21/09/12 15:04, Stephen Henson via RT wrote:

snip

Easiest solution is to also backport ssl_get_server_send_pkey see:

http://cvs.openssl.org/chngview?cn=22840


I didn't think of that.  Thanks!

I'll prepare patches to backport 22840 to 1.0.0 and 0.9.8 (unless you or
Ben get there first).


http://cvs.openssl.org/patchset?cn=22840 applies cleanly (i.e. no failed 
hunks) on top of my patches for 1.0.0 and 0.9.8.


--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured

2012-09-21 Thread Rob Stradling via RT
Attached are patches for 1.0.0 and 0.9.8.

-- 
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

Index: ssl/s3_srvr.c
===
RCS file: /v/openssl/cvs/openssl/ssl/s3_srvr.c,v
retrieving revision 1.126.2.42
diff -u -r1.126.2.42 s3_srvr.c
--- ssl/s3_srvr.c   16 Feb 2012 15:21:17 -  1.126.2.42
+++ ssl/s3_srvr.c   20 Sep 2012 14:40:41 -
@@ -1005,7 +1005,7 @@
goto f_err;
}
}
-   if (ssl_check_clienthello_tlsext(s) = 0) {
+   if (ssl_check_clienthello_tlsext_early(s) = 0) {

SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_CLIENTHELLO_TLSEXT);
goto err;
}
@@ -1131,6 +1131,16 @@
 * s-tmp.new_cipher- the new cipher to use.
 */
 
+   /* Handles TLS extensions that we couldn't check earlier */
+   if (s-version = SSL3_VERSION)
+   {
+   if (ssl_check_clienthello_tlsext_late(s) = 0)
+   {
+   
SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_CLIENTHELLO_TLSEXT);
+   goto err;
+   }
+   }
+
if (ret  0) ret=1;
if (0)
{
Index: ssl/ssl_lib.c
===
RCS file: /v/openssl/cvs/openssl/ssl/ssl_lib.c,v
retrieving revision 1.133.2.31
diff -u -r1.133.2.31 ssl_lib.c
--- ssl/ssl_lib.c   5 Jan 2012 10:21:49 -   1.133.2.31
+++ ssl/ssl_lib.c   20 Sep 2012 14:40:41 -
@@ -1943,7 +1943,7 @@
}
 
 /* THIS NEEDS CLEANING UP */
-X509 *ssl_get_server_send_cert(SSL *s)
+X509 *ssl_get_server_send_cert(const SSL *s)
{
unsigned long alg,kalg;
CERT *c;
@@ -2420,7 +2420,9 @@
 /* Fix this function so that it takes an optional type parameter */
 X509 *SSL_get_certificate(const SSL *s)
{
-   if (s-cert != NULL)
+   if (s-server)
+   return(ssl_get_server_send_cert(s));
+   else if (s-cert != NULL)
return(s-cert-key-x509);
else
return(NULL);
Index: ssl/ssl_locl.h
===
RCS file: /v/openssl/cvs/openssl/ssl/ssl_locl.h,v
retrieving revision 1.63.2.22
diff -u -r1.63.2.22 ssl_locl.h
--- ssl/ssl_locl.h  9 Mar 2012 15:51:56 -   1.63.2.22
+++ ssl/ssl_locl.h  20 Sep 2012 14:40:41 -
@@ -740,7 +740,7 @@
 int ssl_undefined_function(SSL *s);
 int ssl_undefined_void_function(void);
 int ssl_undefined_const_function(const SSL *s);
-X509 *ssl_get_server_send_cert(SSL *);
+X509 *ssl_get_server_send_cert(const SSL *);
 EVP_PKEY *ssl_get_sign_pkey(SSL *,SSL_CIPHER *);
 int ssl_cert_type(X509 *x,EVP_PKEY *pkey);
 void ssl_set_cert_masks(CERT *c, SSL_CIPHER *cipher);
@@ -979,7 +979,8 @@
 int ssl_parse_serverhello_tlsext(SSL *s, unsigned char **data, unsigned char 
*d, int n, int *al);
 int ssl_prepare_clienthello_tlsext(SSL *s);
 int ssl_prepare_serverhello_tlsext(SSL *s);
-int ssl_check_clienthello_tlsext(SSL *s);
+int ssl_check_clienthello_tlsext_early(SSL *s);
+int ssl_check_clienthello_tlsext_late(SSL *s);
 int ssl_check_serverhello_tlsext(SSL *s);
 
 #ifdef OPENSSL_NO_SHA256
Index: ssl/t1_lib.c
===
RCS file: /v/openssl/cvs/openssl/ssl/t1_lib.c,v
retrieving revision 1.13.2.30
diff -u -r1.13.2.30 t1_lib.c
--- ssl/t1_lib.c4 Jan 2012 14:25:10 -   1.13.2.30
+++ ssl/t1_lib.c20 Sep 2012 14:40:41 -
@@ -745,7 +745,7 @@
return 1;
}
 
-int ssl_check_clienthello_tlsext(SSL *s)
+int ssl_check_clienthello_tlsext_early(SSL *s)
{
int ret=SSL_TLSEXT_ERR_NOACK;
int al = SSL_AD_UNRECOGNIZED_NAME;
@@ -755,11 +755,34 @@
else if (s-initial_ctx != NULL  
s-initial_ctx-tlsext_servername_callback != 0) 
ret = s-initial_ctx-tlsext_servername_callback(s, al, 
s-initial_ctx-tlsext_servername_arg);
 
+   switch (ret)
+   {
+   case

Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured

2012-09-21 Thread Rob Stradling via RT
Hi Steve.

I saw your update (to 1.0.2 and HEAD), and I did start looking at 
backporting it into my 1.0.1/1.0.0/0.9.8 patches.

ssl_get_server_send_pkey() is not available in 1.0.1 and earlier, so the 
t1_lib.c patch would have to be something like...

+   X509 *x;
+   x = ssl_get_server_send_cert)s);
+   /* If no certificate can't return certificate status */
+   if (x == NULL)
+   {
+   s-tlsext_status_expected = 0;
+   return 1;
+   }
+   /* Set current certificate to one we will use so
+* SSL_get_certificate et al can pick it up.
+*/
+   s-cert-key-x509 = x;

Is it OK to update s-cert-key-x509 like this?


On 21/09/12 14:34, Stephen Henson via RT wrote:
 [rob.stradl...@comodo.com - Fri Sep 21 15:02:54 2012]:

 Attached are patches for 1.0.0 and 0.9.8.



 Note, I updated the original change to retain compatibility with
 existing behaviour as far as possible. See:

 http://cvs.openssl.org/chngview?cn=22808

 Steve.


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


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


Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured

2012-09-21 Thread Rob Stradling via RT
On 21/09/12 15:04, Stephen Henson via RT wrote:
 [rob.stradl...@comodo.com - Fri Sep 21 15:55:39 2012]:

 Hi Steve.

 I saw your update (to 1.0.2 and HEAD), and I did start looking at
 backporting it into my 1.0.1/1.0.0/0.9.8 patches.

 ssl_get_server_send_pkey() is not available in 1.0.1 and earlier, so the
 t1_lib.c patch would have to be something like...

 +X509 *x;
 +x = ssl_get_server_send_cert)s);
 +/* If no certificate can't return certificate status */
 +if (x == NULL)
 +{
 +s-tlsext_status_expected = 0;
 +return 1;
 +}
 +/* Set current certificate to one we will use so
 + * SSL_get_certificate et al can pick it up.
 + */
 +s-cert-key-x509 = x;

 Is it OK to update s-cert-key-x509 like this?


 No because you could end up with all sorts of bad things happening (keys
 and certificates not matching, certificate types not matching and memory
 leaks).

That's what I thought.

 Easiest solution is to also backport ssl_get_server_send_pkey see:

 http://cvs.openssl.org/chngview?cn=22840

I didn't think of that.  Thanks!

I'll prepare patches to backport 22840 to 1.0.0 and 0.9.8 (unless you or 
Ben get there first).

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


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


Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured

2012-09-21 Thread Rob Stradling via RT
On 21/09/12 15:12, Rob Stradling via RT wrote:
 On 21/09/12 15:04, Stephen Henson via RT wrote:
snip
 Easiest solution is to also backport ssl_get_server_send_pkey see:

 http://cvs.openssl.org/chngview?cn=22840

 I didn't think of that.  Thanks!

 I'll prepare patches to backport 22840 to 1.0.0 and 0.9.8 (unless you or
 Ben get there first).

http://cvs.openssl.org/patchset?cn=22840 applies cleanly (i.e. no failed 
hunks) on top of my patches for 1.0.0 and 0.9.8.

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


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


Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured

2012-09-12 Thread Rob Stradling via RT
On 07/09/12 11:51, Rob Stradling wrote:
 Attached is an updated patch for CVS HEAD, plus a patch for the 1.0.2
 branch.

 Are you still accepting patches for 1.0.1?

Attached is a patch for 1.0.1.

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


Index: ssl/s3_srvr.c
===
RCS file: /v/openssl/cvs/openssl/ssl/s3_srvr.c,v
retrieving revision 1.171.2.21.2.26
diff -u -r1.171.2.21.2.26 s3_srvr.c
--- ssl/s3_srvr.c   8 Jun 2012 09:18:46 -   1.171.2.21.2.26
+++ ssl/s3_srvr.c   12 Sep 2012 15:45:12 -
@@ -1183,7 +1183,7 @@
goto f_err;
}
}
-   if (ssl_check_clienthello_tlsext(s) = 0) {
+   if (ssl_check_clienthello_tlsext_early(s) = 0) {

SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_CLIENTHELLO_TLSEXT);
goto err;
}
@@ -1405,6 +1405,16 @@
 * s-tmp.new_cipher- the new cipher to use.
 */
 
+   /* Handles TLS extensions that we couldn't check earlier */
+   if (s-version = SSL3_VERSION)
+   {
+   if (ssl_check_clienthello_tlsext_late(s) = 0)
+   {
+   
SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_CLIENTHELLO_TLSEXT);
+   goto err;
+   }
+   }
+
if (ret  0) ret=1;
if (0)
{
Index: ssl/ssl_lib.c
===
RCS file: /v/openssl/cvs/openssl/ssl/ssl_lib.c,v
retrieving revision 1.176.2.19.2.25
diff -u -r1.176.2.19.2.25 ssl_lib.c
--- ssl/ssl_lib.c   8 Jun 2012 09:18:46 -   1.176.2.19.2.25
+++ ssl/ssl_lib.c   12 Sep 2012 15:45:12 -
@@ -2287,7 +2287,7 @@
 #endif
 
 /* THIS NEEDS CLEANING UP */
-X509 *ssl_get_server_send_cert(SSL *s)
+X509 *ssl_get_server_send_cert(const SSL *s)
{
unsigned long alg_k,alg_a;
CERT *c;
@@ -2780,7 +2780,9 @@
 /* Fix this function so that it takes an optional type parameter */
 X509 *SSL_get_certificate(const SSL *s)
{
-   if (s-cert != NULL)
+   if (s-server)
+   return(ssl_get_server_send_cert(s));
+   else if (s-cert != NULL)
return(s-cert-key-x509);
else
return(NULL);
Index: ssl/ssl_locl.h
===
RCS file: /v/openssl/cvs/openssl/ssl/ssl_locl.h,v
retrieving revision 1.100.2.10.2.17
diff -u -r1.100.2.10.2.17 ssl_locl.h
--- ssl/ssl_locl.h  9 Mar 2012 15:52:20 -   1.100.2.10.2.17
+++ ssl/ssl_locl.h  12 Sep 2012 15:45:12 -
@@ -830,7 +830,7 @@
 int ssl_undefined_function(SSL *s);
 int ssl_undefined_void_function(void);
 int ssl_undefined_const_function(const SSL *s);
-X509 *ssl_get_server_send_cert(SSL *);
+X509 *ssl_get_server_send_cert(const SSL *);
 EVP_PKEY *ssl_get_sign_pkey(SSL *s,const SSL_CIPHER *c, const EVP_MD **pmd);
 int ssl_cert_type(X509 *x,EVP_PKEY *pkey);
 void ssl_set_cert_masks(CERT *c, const SSL_CIPHER *cipher);
@@ -1088,7 +1088,8 @@
 int ssl_parse_serverhello_tlsext(SSL *s, unsigned char **data, unsigned char 
*d, int n, int *al);
 int ssl_prepare_clienthello_tlsext(SSL *s);
 int ssl_prepare_serverhello_tlsext(SSL *s);
-int ssl_check_clienthello_tlsext(SSL *s);
+int ssl_check_clienthello_tlsext_early(SSL *s);
+int ssl_check_clienthello_tlsext_late(SSL *s);
 int ssl_check_serverhello_tlsext(SSL *s);
 
 #ifndef OPENSSL_NO_HEARTBEATS
Index: ssl/t1_lib.c
===
RCS file: /v/openssl/cvs/openssl/ssl/t1_lib.c,v
retrieving revision 1.64.2.14.2.33
diff -u -r1.64.2.14.2.33 t1_lib.c
--- ssl/t1_lib.c27 Jun 2012 14:11:40 -  1.64.2.14.2.33
+++ ssl/t1_lib.c12 Sep 2012 15:45:12 -
@@ -1763,7 +1763,7 @@
return 1;
}
 
-int ssl_check_clienthello_tlsext(SSL *s)
+int ssl_check_clienthello_tlsext_early(SSL *s)
{
int ret=SSL_TLSEXT_ERR_NOACK;
int al = SSL_AD_UNRECOGNIZED_NAME;
@@ -1782,42 +1782,12 @@
else if (s-initial_ctx != NULL  
s-initial_ctx-tlsext_servername_callback != 0) 
ret = s-initial_ctx-tlsext_servername_callback(s, al, 
s-initial_ctx-tlsext_servername_arg);
 
-   /* If status request then ask callback what to do.
-* Note: this must be called after servername callbacks in case 
-* the certificate has changed.
-*/
-   if ((s-tlsext_status_type != -1)  s-ctx  s-ctx-tlsext_status_cb)
-   {
-   int r;
-   r = s-ctx-tlsext_status_cb(s, s-ctx-tlsext_status_arg);
-   switch (r)
-   {
-   /* We don't want to send a status request response */
-   case SSL_TLSEXT_ERR_NOACK:
-   s

Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured

2012-09-07 Thread Rob Stradling via RT
Attached is an updated patch for CVS HEAD, plus a patch for the 1.0.2 
branch.

Are you still accepting patches for 1.0.1?

Any chance of reviewing these patches soon?

Thanks.

On 19/06/12 21:15, Rob Stradling via RT wrote:
 The OCSP Stapling Callback function (s-ctx-tlsext_status_cb) is called
 during the parsing of the ClientHello message, before the server has
 decided which cipher to use.  However, since the choice of cipher can
 influence which server certificate is sent, this means that the wrong
 OCSP Response may be sent in cases where multiple server certificates
 are configured.

 The attached patch against CVS HEAD makes the following changes:
 - Moves the s-ctx-tlsext_status_cb() call to just after the cipher
 has been chosen.  This involves splitting ssl_check_clienthello_tlsext()
 into two functions: early and late.
 - Updates SSL_get_certificate() so that it returns the server
 certificate that actually gets sent.  (This is the function that Apache
 httpd's OCSP Stapling code calls in order to determine which OCSP
 Response to send).

 I've tested this patch successfully with an installation of httpd 2.4.2
 that has both an RSA cert and an ECC cert configured.

 If this patch is OK, I'd like to backport it to the OpenSSL 1.0.x branch
 as well.


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


Index: ssl/s3_srvr.c
===
RCS file: /v/openssl/cvs/openssl/ssl/s3_srvr.c,v
retrieving revision 1.239
diff -u -r1.239 s3_srvr.c
--- ssl/s3_srvr.c   15 Aug 2012 15:15:05 -  1.239
+++ ssl/s3_srvr.c   7 Sep 2012 10:00:12 -
@@ -1432,6 +1432,16 @@
 * s-tmp.new_cipher- the new cipher to use.
 */
 
+   /* Handles TLS extensions that we couldn't check earlier */
+   if (s-version = SSL3_VERSION)
+   {
+   if (ssl_check_clienthello_tlsext_late(s) = 0)
+   {
+   
SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_CLIENTHELLO_TLSEXT);
+   goto err;
+   }
+   }
+
if (ret  0) ret=1;
if (0)
{
Index: ssl/ssl_lib.c
===
RCS file: /v/openssl/cvs/openssl/ssl/ssl_lib.c,v
retrieving revision 1.242
diff -u -r1.242 ssl_lib.c
--- ssl/ssl_lib.c   31 Aug 2012 11:18:54 -  1.242
+++ ssl/ssl_lib.c   7 Sep 2012 10:00:12 -
@@ -2336,7 +2336,7 @@
 
 #endif
 
-static int ssl_get_server_cert_index(SSL *s)
+static int ssl_get_server_cert_index(const SSL *s)
{
int idx;
idx = ssl_cipher_get_cert_index(s-s3-tmp.new_cipher);
@@ -2347,7 +2347,7 @@
return idx;
}
 
-CERT_PKEY *ssl_get_server_send_pkey(SSL *s)
+CERT_PKEY *ssl_get_server_send_pkey(const SSL *s)
{
CERT *c;
int i;
@@ -2833,6 +2833,14 @@
 /* Fix this function so that it takes an optional type parameter */
 X509 *SSL_get_certificate(const SSL *s)
{
+   if (s-server)
+   {
+   CERT_PKEY *certpkey;
+   certpkey = ssl_get_server_send_pkey(s);
+   if (certpkey  certpkey-x509)
+   return certpkey-x509;
+   }
+
if (s-cert != NULL)
return(s-cert-key-x509);
else
Index: ssl/ssl_locl.h
===
RCS file: /v/openssl/cvs/openssl/ssl/ssl_locl.h,v
retrieving revision 1.155
diff -u -r1.155 ssl_locl.h
--- ssl/ssl_locl.h  31 Aug 2012 11:18:54 -  1.155
+++ ssl/ssl_locl.h  7 Sep 2012 10:00:12 -
@@ -934,7 +934,7 @@
 int ssl_undefined_function(SSL *s);
 int ssl_undefined_void_function(void);
 int ssl_undefined_const_function(const SSL *s);
-CERT_PKEY *ssl_get_server_send_pkey(SSL *);
+CERT_PKEY *ssl_get_server_send_pkey(const SSL *s);
 unsigned char *ssl_get_authz_data(SSL *s, size_t *authz_length);
 EVP_PKEY *ssl_get_sign_pkey(SSL *s,const SSL_CIPHER *c, const EVP_MD **pmd);
 int ssl_cert_type(X509 *x,EVP_PKEY *pkey);
@@ -1201,6 +1201,7 @@
 unsigned char *ssl_add_clienthello_tlsext(SSL *s, unsigned char *p, unsigned 
char *limit); 
 unsigned char *ssl_add_serverhello_tlsext(SSL *s, unsigned char *p, unsigned 
char *limit); 
 int ssl_parse_clienthello_tlsext(SSL *s, unsigned char **data, unsigned char 
*d, int n);
+int ssl_check_clienthello_tlsext_late(SSL *s);
 int ssl_parse_serverhello_tlsext(SSL *s, unsigned char **data, unsigned char 
*d, int n);
 int ssl_prepare_clienthello_tlsext(SSL *s);
 int ssl_prepare_serverhello_tlsext(SSL *s);
Index: ssl/t1_lib.c
===
RCS file: /v/openssl/cvs/openssl/ssl/t1_lib.c,v
retrieving revision 1.139
diff -u -r1.139 t1_lib.c
--- ssl/t1_lib.c29 Aug 2012 13:18:34 -  1.139
+++ ssl/t1_lib.c7 Sep 2012 10:00:12 -
@@ -123,7 +123,7 @@
 static int

warning: ‘hash_nid’ may be used uninitialized in this function

2012-07-19 Thread Rob Stradling

Steve,

I just noticed this warning whilst compiling CVS HEAD:

t1_lib.c: In function ‘tls1_lookup_sigalg’:
t1_lib.c::16: warning: ‘hash_nid’ may be used uninitialized in this 
function

(Line number scrubbed 'cos I have local edits)

The uninitialized use of hash_nid seems to be in the function's last if 
statement:  if (sign_nid  hash_nid)


I suggest:
- int sign_nid, hash_nid;
+ int sign_nid, hash_nid = 0;

--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OCSP Stapling bug with multiple certs (e.g. an RSA cert and an ECC cert)

2012-06-19 Thread Rob Stradling

On 18/06/12 11:40, Rob Stradling wrote:

On 16/06/12 23:31, Dr. Stephen Henson wrote:
snip

Is there a way to patch httpd so that it can work around the
limitations in the OpenSSL API and always send the correct OCSP
Response?

Possible changes to OpenSSL:
Should the Stapling Callback function be called later in the
handshake (perhaps in ssl_add_serverhello_tlsext()), after the
cipher has been selected?
Should ssl_get_server_send_cert() be made available for applications
to call? Or should SSL_get_certificate() be updated so that it
always returns the cert that the server will actually send?


I can't immediately think of a clean solution to this problem. I
think it
makes sense for OpenSSL to return the server certificate actually
used via
SSL_get_certificate().


Agreed. This would avoid the need to implement a fix/workaround in the
httpd code, and would presumably also mean that the OpenSSL 1.0.x branch
can be fixed without breaking binary compatibility.


See if adding:

c-key = c-pkeys + i;

to ssl_get_server_send_cert fixes this.



Which it wont because the status callback is called too soon as you
noted.


Would moving the status callback to a sufficiently later point in the
handshake work?


Since it's now clear that the fix for this problem requires changing 
OpenSSL, I've just sent a request to the Request Tracker.


I've also proposed a patch.

--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


[openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured

2012-06-19 Thread Rob Stradling via RT
The OCSP Stapling Callback function (s-ctx-tlsext_status_cb) is called 
during the parsing of the ClientHello message, before the server has 
decided which cipher to use.  However, since the choice of cipher can 
influence which server certificate is sent, this means that the wrong 
OCSP Response may be sent in cases where multiple server certificates 
are configured.

The attached patch against CVS HEAD makes the following changes:
   - Moves the s-ctx-tlsext_status_cb() call to just after the cipher 
has been chosen.  This involves splitting ssl_check_clienthello_tlsext() 
into two functions: early and late.
   - Updates SSL_get_certificate() so that it returns the server 
certificate that actually gets sent.  (This is the function that Apache 
httpd's OCSP Stapling code calls in order to determine which OCSP 
Response to send).

I've tested this patch successfully with an installation of httpd 2.4.2 
that has both an RSA cert and an ECC cert configured.

If this patch is OK, I'd like to backport it to the OpenSSL 1.0.x branch 
as well.

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

Index: ssl/s3_srvr.c
===
RCS file: /v/openssl/cvs/openssl/ssl/s3_srvr.c,v
retrieving revision 1.233
diff -u -r1.233 s3_srvr.c
--- ssl/s3_srvr.c   6 Jun 2012 12:52:19 -   1.233
+++ ssl/s3_srvr.c   19 Jun 2012 10:59:34 -
@@ -1424,6 +1424,16 @@
 * s-tmp.new_cipher- the new cipher to use.
 */
 
+   /* Handles TLS extensions that we couldn't check earlier */
+   if (s-version = SSL3_VERSION)
+   {
+   if (!ssl_check_clienthello_tlsext_late(s))
+   {
+   SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_PARSE_TLSEXT);
+   goto err;
+   }
+   }
+
if (ret  0) ret=1;
if (0)
{
Index: ssl/ssl_lib.c
===
RCS file: /v/openssl/cvs/openssl/ssl/ssl_lib.c,v
retrieving revision 1.234
diff -u -r1.234 ssl_lib.c
--- ssl/ssl_lib.c   18 Jun 2012 12:56:59 -  1.234
+++ ssl/ssl_lib.c   19 Jun 2012 10:59:34 -
@@ -2846,6 +2846,14 @@
 /* Fix this function so that it takes an optional type parameter */
 X509 *SSL_get_certificate(const SSL *s)
{
+   if (s-server)
+   {
+   CERT_PKEY *certpkey;
+   certpkey = ssl_get_server_send_pkey((SSL *)s);
+   if (certpkey  certpkey-x509)
+   return certpkey-x509;
+   }
+
if (s-cert != NULL)
return(s-cert-key-x509);
else
Index: ssl/ssl_locl.h
===
RCS file: /v/openssl/cvs/openssl/ssl/ssl_locl.h,v
retrieving revision 1.141
diff -u -r1.141 ssl_locl.h
--- ssl/ssl_locl.h  18 Jun 2012 12:56:59 -  1.141
+++ ssl/ssl_locl.h  19 Jun 2012 10:59:34 -
@@ -1132,6 +1132,7 @@
 unsigned char *ssl_add_clienthello_tlsext(SSL *s, unsigned char *p, unsigned 
char *limit); 
 unsigned char *ssl_add_serverhello_tlsext(SSL *s, unsigned char *p, unsigned 
char *limit); 
 int ssl_parse_clienthello_tlsext(SSL *s, unsigned char **data, unsigned char 
*d, int n);
+int ssl_check_clienthello_tlsext_late(SSL *s);
 int ssl_parse_serverhello_tlsext(SSL *s, unsigned char **data, unsigned char 
*d, int n);
 int ssl_prepare_clienthello_tlsext(SSL *s);
 int ssl_prepare_serverhello_tlsext(SSL *s);
Index: ssl/t1_lib.c
===
RCS file: /v/openssl/cvs/openssl/ssl/t1_lib.c,v
retrieving revision 1.123
diff -u -r1.123 t1_lib.c
--- ssl/t1_lib.c11 Jun 2012 09:23:55 -  1.123
+++ ssl/t1_lib.c19 Jun 2012 10:59:34 -
@@ -123,7 +123,7 @@
 static int tls_decrypt_ticket(SSL *s, const unsigned char *tick, int ticklen,
const unsigned char *sess_id, int sesslen,
SSL_SESSION **psess);
-static int ssl_check_clienthello_tlsext(SSL *s);
+static int ssl_check_clienthello_tlsext_early(SSL *s);
 int ssl_check_serverhello_tlsext(SSL *s);
 #endif
 
@@ -1846,7 +1846,7 @@
return 0;
}
 
-   if (ssl_check_clienthello_tlsext(s) = 0) 
+   if (ssl_check_clienthello_tlsext_early(s) = 0) 
{

SSLerr(SSL_F_SSL_PARSE_CLIENTHELLO_TLSEXT,SSL_R_CLIENTHELLO_TLSEXT);
return 0;
@@ -2247,7 +2247,7 @@
return 1;
}
 
-static int ssl_check_clienthello_tlsext(SSL *s)
+static int ssl_check_clienthello_tlsext_early(SSL *s)
{
int ret=SSL_TLSEXT_ERR_NOACK;
int al = SSL_AD_UNRECOGNIZED_NAME;
@@ -2266,42 +2266,11 @@
else if (s-initial_ctx != NULL  
s-initial_ctx-tlsext_servername_callback != 0) 
ret = s-initial_ctx

Re: OCSP Stapling bug with multiple certs (e.g. an RSA cert and an ECC cert)

2012-06-18 Thread Rob Stradling

On 16/06/12 23:31, Dr. Stephen Henson wrote:
snip

Is there a way to patch httpd so that it can work around the
limitations in the OpenSSL API and always send the correct OCSP
Response?

Possible changes to OpenSSL:
Should the Stapling Callback function be called later in the
handshake (perhaps in ssl_add_serverhello_tlsext()), after the
cipher has been selected?
Should ssl_get_server_send_cert() be made available for applications
to call?  Or should SSL_get_certificate() be updated so that it
always returns the cert that the server will actually send?


I can't immediately think of a clean solution to this problem. I think it
makes sense for OpenSSL to return the server certificate actually used via
SSL_get_certificate().


Agreed.  This would avoid the need to implement a fix/workaround in the 
httpd code, and would presumably also mean that the OpenSSL 1.0.x branch 
can be fixed without breaking binary compatibility.



See if adding:

c-key = c-pkeys + i;

to ssl_get_server_send_cert fixes this.



Which it wont because the status callback is called too soon as you noted.


Would moving the status callback to a sufficiently later point in the 
handshake work?


--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


OCSP Stapling bug with multiple certs (e.g. an RSA cert and an ECC cert)

2012-06-16 Thread Rob Stradling
Using OpenSSL 1.x and Apache httpd 2.4.x, I've been trying to get OCSP 
Stapling to work with both an RSA cert and an ECC cert configured.  The 
desired behaviour is (obviously) that httpd should staple the correct 
OCSP Response for whichever cert (RSA or ECC) it chooses to send to the 
client.  However, I've found that it always staples the OCSP Response 
for the ECC cert, even when it sends the RSA cert.


ssl_util_stapling.c in httpd 2.4.x calls SSL_get_certificate(), but this 
function appears to have no knowledge of which server cert will actually 
be sent to the client.  I've been trying to work out how to fix the 
httpd code, but it doesn't look like the OpenSSL API provides a clean 
solution.


The ssl_get_server_send_cert() function defined in ssl_lib.c would be 
ideal here, but since it's declared in ssl_locl.h it's not intended to 
be available to applications.


But even if ssl_get_server_send_cert() was publicly accessible, I don't 
think it would actually work properly.  The Stapling Callback function 
(s-ctx-tlsext_status_cb) is called when parsing the ClientHello 
message, which I believe takes place before the server has decided which 
cipher to use.  And ssl_get_server_send_cert() needs to know which 
cipher has been selected.


Is there a way to patch httpd so that it can work around the limitations 
in the OpenSSL API and always send the correct OCSP Response?


Possible changes to OpenSSL:
Should the Stapling Callback function be called later in the handshake 
(perhaps in ssl_add_serverhello_tlsext()), after the cipher has been 
selected?
Should ssl_get_server_send_cert() be made available for applications to 
call?  Or should SSL_get_certificate() be updated so that it always 
returns the cert that the server will actually send?


Thanks.

--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: [openssl.org #2626] ENHANCEMENT: please update default_bits to 2048 in default openssl.cnf

2011-10-20 Thread Rob Stradling
Duplicate of ticket #2354.

On Wednesday 19 Oct 2011 16:58:28 Daniel Kahn Gillmor via RT wrote:
 The current default openssl.cnf appears to have default_bits = 1024:
 
 http://cvs.openssl.org/fileview?f=openssl/apps/openssl.cnfv=1.23.4.6
 
 however, NIST has recommended avoiding reliance on 1024-bit RSA keys
 after 2010.
 
 See pages 63-66 of:
 
 http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_M
 ar08-2007.pdf
 
 Please change default_bits in the stock openssl.cnf to 2048, or include
 some clear justification for why the tool defaults to creating a
 deprecated keysize.
 
 Thanks,
 
   --dkg
 
 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL Security Advisory: OCSP stapling vulnerability

2011-02-09 Thread Rob Stradling
Bodo, some comments inline...

On Tuesday 08 Feb 2011 18:09:46 Bodo Moeller wrote:
 OpenSSL Security Advisory [8 February 2011]
 
 OCSP stapling vulnerability in OpenSSL
snip
 Which applications are affected
 ---
 
 Applications are only affected if they act as a server and call
 SSL_CTX_set_tlsext_status_cb on the server's SSL_CTX. This includes
 Apache httpd = 2.3.3.

In httpd = 2.3.3, OCSP Stapling is currently disabled by default.  To enable 
it, the SSLUseStapling On directive must be added to the config.  Since 
SSL_CTX_set_tlsext_status_cb() is only called when OCSP Stapling has been 
enabled, I conclude that the default configuration is not vulnerable.

A couple of months ago I proposed to httpd-dev that OCSP Stapling should be 
enabled by default.  Steve Henson was cautiously sympathetic to the idea...
My personal opinion would be to, at least initially, require an explicit 
directive to enable it and leave the option in future to have it enabled by 
default.
...but Igor Galić replied with...
If we want to see more extensive testing in the field, then this is the right 
time to make 'On' the default.

Maybe httpd should:
1. Check the version number of the OpenSSL runtime library.
2. Log a warning if a vulnerable OpenSSL version is detected.
3. Definitely avoid enabling Stapling by default if a vulnerable OpenSSL 
version is detected.

(Sorry, I guess I've drifted a bit off-topic for this list).

snip
 OCSP stapling is defined in RFC 2560.

RFC 2560 defines OCSP, but not OCSP Stapling.

OCSP Stapling is the popular term for the Certificate Status Request TLS 
Extension defined most recently by RFC 6066 (previous versions: RFC 4366, RFC 
3546).

Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


[openssl.org #2354] [PATCH] Increase Default RSA Key Size to 2048-bits

2010-09-29 Thread Rob Stradling via RT
NIST (SP800-57 Part 1) recommends a minimum RSA key size of 2048-bits beyond 
2010.  From January 1st 2011, in order to comply with the current Microsoft[1] 
and Mozilla[2] CA Policies, Commercial CAs will no longer be permitted to 
issue certificates with RSA key sizes of 2048-bit.

Please accept the attached patch, which increases the default RSA key size to 
2048-bits for the req, genrsa and genpkey apps.

Thanks.

[1] http://technet.microsoft.com/en-us/library/cc751157.aspx says:
we have advised Certificate Authorities...to transition their subordinate and 
end-certificates to 2048-bit RSA certificates, and to complete this transition 
for any root certificate distributed by the Program no later than December 31, 
2010.

[2] https://wiki.mozilla.org/CA:MD5and1024 says:
December 31, 2010 – CAs should stop issuing intermediate and end-entity 
certificates from roots with RSA key sizes smaller than 2048 bits. All CAs 
should stop issuing intermediate and end-entity certificates with RSA key size 
smaller than 2048 bits under any root.

Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.

Index: apps/genrsa.c
===
RCS file: /v/openssl/cvs/openssl/apps/genrsa.c,v
retrieving revision 1.40
diff -U 5 -r1.40 genrsa.c
--- apps/genrsa.c	1 Mar 2010 14:22:21 -	1.40
+++ apps/genrsa.c	28 Sep 2010 14:44:44 -
@@ -76,11 +76,11 @@
 #include openssl/evp.h
 #include openssl/x509.h
 #include openssl/pem.h
 #include openssl/rand.h
 
-#define DEFBITS	512
+#define DEFBITS	2048
 #undef PROG
 #define PROG genrsa_main
 
 static int MS_CALLBACK genrsa_cb(int p, int n, BN_GENCB *cb);
 
Index: apps/openssl-vms.cnf
===
RCS file: /v/openssl/cvs/openssl/apps/openssl-vms.cnf,v
retrieving revision 1.11
diff -U 5 -r1.11 openssl-vms.cnf
--- apps/openssl-vms.cnf	23 Apr 2009 16:32:37 -	1.11
+++ apps/openssl-vms.cnf	28 Sep 2010 14:44:44 -
@@ -101,11 +101,11 @@
 commonName		= supplied
 emailAddress		= optional
 
 
 [ req ]
-default_bits		= 1024
+default_bits		= 2048
 default_keyfile 	= privkey.pem
 distinguished_name	= req_distinguished_name
 attributes		= req_attributes
 x509_extensions	= v3_ca	# The extentions to add to the self signed cert
 
Index: apps/openssl.cnf
===
RCS file: /v/openssl/cvs/openssl/apps/openssl.cnf,v
retrieving revision 1.32
diff -U 5 -r1.32 openssl.cnf
--- apps/openssl.cnf	4 Apr 2009 19:54:02 -	1.32
+++ apps/openssl.cnf	28 Sep 2010 14:44:44 -
@@ -101,11 +101,11 @@
 commonName		= supplied
 emailAddress		= optional
 
 
 [ req ]
-default_bits		= 1024
+default_bits		= 2048
 default_keyfile 	= privkey.pem
 distinguished_name	= req_distinguished_name
 attributes		= req_attributes
 x509_extensions	= v3_ca	# The extentions to add to the self signed cert
 
Index: apps/req.c
===
RCS file: /v/openssl/cvs/openssl/apps/req.c,v
retrieving revision 1.146
diff -U 5 -r1.146 req.c
--- apps/req.c	14 Mar 2010 12:54:45 -	1.146
+++ apps/req.c	28 Sep 2010 14:44:44 -
@@ -97,11 +97,11 @@
 #define V3_EXTENSIONS	x509_extensions
 #define REQ_EXTENSIONS	req_extensions
 #define STRING_MASK	string_mask
 #define UTF8_IN		utf8
 
-#define DEFAULT_KEY_LENGTH	512
+#define DEFAULT_KEY_LENGTH	2048
 #define MIN_KEY_LENGTH		384
 
 #undef PROG
 #define PROG	req_main
 
Index: crypto/rsa/rsa_pmeth.c
===
RCS file: /v/openssl/cvs/openssl/crypto/rsa/rsa_pmeth.c,v
retrieving revision 1.39
diff -U 5 -r1.39 rsa_pmeth.c
--- crypto/rsa/rsa_pmeth.c	1 Jun 2010 14:39:01 -	1.39
+++ crypto/rsa/rsa_pmeth.c	28 Sep 2010 14:44:44 -
@@ -91,11 +91,11 @@
 	{
 	RSA_PKEY_CTX *rctx;
 	rctx = OPENSSL_malloc(sizeof(RSA_PKEY_CTX));
 	if (!rctx)
 		return 0;
-	rctx-nbits = 1024;
+	rctx-nbits = 2048;
 	rctx-pub_exp = NULL;
 	rctx-pad_mode = RSA_PKCS1_PADDING;
 	rctx-md = NULL;
 	rctx-mgf1md = NULL;
 	rctx

[openssl.org #2206] [PATCH] Implicitly support non-delegated OCSP response signing

2010-03-26 Thread Rob Stradling via RT
 the risk of compromise especially if the private
key itself is placed on the server.
  
   Steve, I think it's entirely unfair to label the non-delegated model as
   not recommended for security reasons just because *some
   implementations* might give a public responder access to a CA key.
 
 snip
 
  Yes sorry I should've qualified that statement. I was attempting to keep
   this simple and that always includes the risk of oversimplification.
 
 Steve, thanks for explaining.
 
 snip
 
  Though of course the delegated trust model can also support pre-produced
   OCSP responses.
 
 That's true.
 
 By the way Steve, I'd like to propose a small change to openssl ocsp to
 support the non-delegated model more seamlessly.  I've always been
  surprised and slightly confused that you have to specify both -issuer
  ca.pem and - VAfile ca.pem to verify the signature on a non-delegated
  OCSP Response. Why doesn't -issuer ca.pem cause ca.pem to be treated as
  a candidate OCSP Response signer certificate?
 
 When, a couple of weeks ago, a colleague independently made the same
 observation and asked me that same question, it spurred me to write a
  patch.
 
 Would you be happy with this change in behaviour?  If so, I'll submit my
  patch to the Request Tracker.
 
  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
  User Support Mailing Listopenssl-us...@openssl.org
  Automated List Manager   majord...@openssl.org
 
 Rob Stradling
 Senior Research  Development Scientist
 C·O·M·O·D·O - Creating Trust Online
 Office Tel: +44.(0)1274.730505
 Office Fax: +44.(0)1274.730909
 www.comodo.com
 
 Comodo CA Limited, Registered in England No. 04058690
 Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ
 
 This e-mail and any files transmitted with it are confidential and intended
 solely for the use of the individual or entity to whom they are addressed.
 If you have received this email in error please notify the sender by
  replying to the e-mail containing this attachment. Replies to this email
  may be monitored by Comodo for operational or business reasons. Whilst
  every endeavour is taken to ensure that e-mails are free from viruses, no
  liability can be accepted and the recipient is requested to use their own
  virus checking software.
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-us...@openssl.org
 Automated List Manager   majord...@openssl.org

Rob Stradling
Senior Research  Development Scientist
C·O·M·O·D·O - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

Comodo CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.

--- openssl-0.9.8n/apps/ocsp.c	2008-11-05 18:36:35.0 +
+++ openssl-0.9.8n-modified/apps/ocsp.c	2010-03-26 09:22:30.0 +
@@ -118,7 +118,7 @@
 	long nsec = MAX_VALIDITY_PERIOD, maxage = -1;
 	char *CAfile = NULL, *CApath = NULL;
 	X509_STORE *store = NULL;
-	STACK_OF(X509) *sign_other = NULL, *verify_other = NULL, *rother = NULL;
+	STACK_OF(X509) *sign_other = NULL, *verify_other = NULL, *rother = NULL, *issuer_st = NULL;
 	char *sign_certfile = NULL, *verify_certfile = NULL, *rcertfile = NULL;
 	unsigned long sign_flags = 0, verify_flags = 0, rflags = 0;
 	int ret = 1;
@@ -389,6 +389,8 @@
 issuer = load_cert(bio_err, *args, FORMAT_PEM,
 	NULL, e, issuer certificate);
 if(!issuer) goto end;
+issuer_st = sk_X509_new_null();
+sk_X509_push(issuer_st, issuer);
 }
 			else badarg = 1;
 			}
@@ -832,6 +834,12 @@
 			}
 
 		i = OCSP_basic_verify(bs, verify_other, store, verify_flags);
+
+		if (i = 0  issuer_st) {
+			i = OCSP_basic_verify(bs, issuer_st, store, OCSP_TRUSTOTHER);
+			if (i  0) ERR_clear_error();
+		}
+
 if (i  0) i = OCSP_basic_verify(bs, NULL, store, 0);
 
 		if(i = 0)
@@ -855,7 +863,7 @@
 	X509_STORE_free(store);
 	EVP_PKEY_free(key