Re: SSL and TLS questions

[Bodo Moeller <moeller@cdc.informatik.tu-darmstadt.de>]

On Mon, Jul 29, 2002 at 05:54:41AM -0400, Nick Mathewson wrote:
> On Mon, 2002-07-29 at 04:55, Bodo Moeller wrote:
>> On Sun, Jul 28, 2002 at 07:32:57PM -0400, Nick Mathewson wrote:

>>> 1) Could somebody point me at some OpenSSL example code for
>>> client-initiated key renegotiation on an *asynchronous* (nonblocking)
>>> socket? [...]

>> http://www.rtfm.com/openssl-examples/ (article part 2)

> I've seen this, but it only seems to describe how initiate a new
> handshake from the server.  Suppose I want to initiate a new handshake
> from the client instead -- can it be done?  Is it similar?  Will the
> SSL_set_session_id_context/SSL_renegotiate/SSL_do_handshake/
> SSL->state=SSL_ST_ACCEPT trick/SSL_do_handshake sequence still work?

It is similar, but there are some differences; actually it is simpler
to do in a client than in a server.  While for servers
SSL_renegotiate() requests only a 'HelloRequest', SSL_renegotiate() in
a client forces the start of a new handshake ('ClientHello' message).

When a server sends a 'HelloRequest', it asks the client to start a
renegotiation.  But this request may be ignored by the client; so the
server normally forgets about even having sent it.  If the client
does perform a handshake in response to the 'HelloRequest', this is
just like a client-initiated handshake as far as the server is
concerned.  The 'SSL->state=SSL_ST_ACCEPT' hack forces the server to
insist on a renegotiation (in violiation of the proper OpenSSL API;
there are nicer ways to achieve this goal).

But after you have called SSL_renegotiate() in a client, the
SSL_do_handshake() will actually perform a handshake.  Thus there
is no need for the 'SSL->state' hack.

Also SSL_set_session_id_context() is needed only for servers (it
determines how the server-side session cache will be used).
So the sequence is simply SSL_renegotiate(), SSL_do_handshake().



> Also, the code in question seems to assume that renegotiate and
> do_handshake never need to be retried.  Does that mean that they never
> do any network communication, or that the example uses a blocking
> connection?  If the latter (most likely), are there any issues with
> using them with a nonblocking connection, or do they return
> WANT_READ/WANT_WRITE as normal?

SSL_renegotiate() itself does not do any I/O, it just sets the
internal state.  SSL_do_handshake() is like SSL_read() and
SSL_write(), i.e. you use SSL_get_error() and call SSL_do_handshake()
again if SSL_get_error() tells you so.



-- 
Bodo Möller <moeller@cdc.informatik.tu-darmstadt.de>
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