Re: SSL renegotiation in openssl using blocked sockets

2012-06-16 Thread Pradeep A

Can anybody help in this


Pradeep A wrote:
 
 
 
 
 This is regarding openssl renegotiation issue in client server
 communication.The openssl version is 1.0.1c.
 
 The client and server are establishing the SSL connection using blocking
 sockets and communication is fine.The client sends the data and server
 receives and send back to client.
 
 When server want to do renegotiation it is done using SSL_renogotiate,
 SSL_do_handshake after that setting SSL state as SSL_ST_ACCEPT.
 
Server Code for renegotiation:
 
 ssl_session_id_context = 1;
 SSL_set_session_id_context(ssl, (unsigned char
 *)ssl_session_id_context, sizeof(ssl_session_id_context));
 if(SSL_renegotiate(ssl) = 0){
 printf(SSL_renegotiate() failed\n);
 }   if( (err = SSL_do_handshake(ssl)) = 0){
 printf(SSL_do_handshake() 1 failed %d\n,
 SSL_get_error(ssl, err));
 ERR_print_errors_fp(stderr);
 }   ssl-state = SSL_ST_ACCEPT;
 printf(Accepted state %d\n, ssl-state);
 if( (err = SSL_do_handshake(ssl)) = 0){
 printf(SSL_do_handshake() failed %d %d\n, err,
 SSL_get_error(ssl, err));
 ERR_print_errors_fp(stderr);
 }
 
 
 
 The client side general behaviour is waiting on console to read data using
 SSL_write to send it to server.During this time if server renegotiates and
 client side sends any data from console by calling SSL_write the
 rehandshake is failed.
 
 Client side code writing data:
 
 ret = SSL_write(ssl, send_data, strlen(send_data));
 
 
 The following lines are printed at server side returning -1 from second
 SSL_do_handshake 
 
 3086063264:error:140940F5:SSL routines:SSL3_READ_BYTES:unexpected
 record:s3_pkt.c:1404:
 
 The following lines are printed at client side when it is reading using
 SSL_read which is returning -1 after it sends data to server
 
 3086079648:error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert
 unexpected message:s3_pkt.c:1251:SSL alert number 10
 3086079648:error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake
 failure:s3_pkt.c:1151:
 
 In openssl.org for blocking sockets following is given
 
 If the underlying BIO is blocking, SSL_write() will only return, once the
 write operation has been finished or an error occurred, except when a
 renegotiation take place, in which case a SSL_ERROR_WANT_READ may occur.
 
 How exactly SSL_write behaves at the clint side when it receives SSL
 renogotiation from server. How can the rehandshake be successful in this
 case.
  
 

-- 
View this message in context: 
http://old.nabble.com/SSL-renegotiation-in-openssl-using-blocked-sockets-tp34005802p34017782.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.
__
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