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


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: OCSP Stapling bug with multiple certs (e.g. an RSA cert and an ECC cert)

2012-06-16 Thread Dr. Stephen Henson
On Fri, Jun 15, 2012, Rob Stradling wrote:

 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?
 

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().

See if adding:

c-key = c-pkeys + i;

to ssl_get_server_send_cert fixes this.

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: OCSP Stapling bug with multiple certs (e.g. an RSA cert and an ECC cert)

2012-06-16 Thread Dr. Stephen Henson
On Sat, Jun 16, 2012, Dr. Stephen Henson wrote:

 On Fri, Jun 15, 2012, Rob Stradling wrote:
 
  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?
  
 
 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().
 
 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. 

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