sorry to drag this out, but i'm still confused by the results i'm getting.

i'm using non-blocking io, and everything is working fine in that respect. i would 
like my application to re-negotiate the connection after x number of bytes have been 
transmitted, and for it to close the connection if the re-negotiation fails.

my client app calls SSL_renegotiate() and gets a return value of 1 (success i presume, 
as i cann't find a man page for this function). this sets up internal flags in ssl 
ready to negotiate the connection.

i call SSL_do_handshake() and get a return value of 1 (success), however, no network 
traffic is sent, tcpdump/ethereal shows no traffic sent at this point.

according to the api, my app requested a renegotiation and it got one successfully, 
but as no traffic has passed over the interface how can this be ?

i was really expecting to get the error SSL_ERROR_WANT_READ/WRITE from the 
SSL_do_handshake() call as i would expect i'dd have to send/receive data before it 
could report a success or failure.

any help would be greatly appreciated.

cheers

nigel

> -----Original Message-----
> From: Bodo Moeller [mailto:[EMAIL PROTECTED]]
> Sent: 28 January 2003 12:19
> To: [EMAIL PROTECTED]
> Subject: Re: renegotiation in 0.9.7
> 
> 
> On Mon, Jan 27, 2003 at 03:21:45PM -0000, Nigel Spowage wrote:
> 
> > okay, so the proper way to renegotiate a connection is  :
> > 
> > 1 - call SSL_renegotiate()
> > 2 - call SSL_do_handshake()
> > 3 - wait for either 
> > 3a- SSL_renegotiate_pending() to return 0, or
> > 3b- an acceptable amount of time (which means rengotiation 
> has failed)
> > 4 - call SSL_renegotiate()
> > 5 - call SSL_do_handshake()
> > 
> > is that right ?
> 
> SSL_renegotiate() will just set internal flags that tell
> SSL_do_handshake() to renegotiate, so you will not have to call
> SSL_renegotiate multiple times; but you may have to repeat the calls
> to SSL_do_handshake(), which does the actual work.  Use
> SSL_get_error() (as described on its manpage) to find out when
> SSL_do_handshake() has finished.
> 
> You do not have to check the return value of SSL_renegotiate_pending()
> unless you want to be really sure that an actual renegotiation has
> taken place -- in some cases, if one party requests a renegotiation,
> the other party can simply ignore this request.  (If
> SSL_renegotiate_pending() returns non-zero, this does necessarily not
> mean that calling SSL_do_handshake() again will accomplish
> anything; maybe you're done and the question is just whether
> the other party will comply with the request for renegotiation.)
> 
> 
> 
> -- 
> Bodo Möller <[EMAIL PROTECTED]>
> PGP 
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]


********************************************************************************************************
This e-mail is from Energis Communications Ltd, 185 Park Street, London, SE1 9DY,
United Kingdom, No: 2630471.

This e-mail is confidential to the addressee and may be privileged. The views
expressed are personal and do not necessarily reflect those of Energis. If you are not
the intended recipient please notify the sender immediately by calling our switchboard 
on
+44 (0) 20 7206 5555 and do not disclose to another person or use, copy or forward
all or any of it in any form.

********************************************************************************************************
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to