Re: [TLS] permitted client behaviour when rejecting renegotiation

[Martin Rex <[e-mail]>]

Nikos Mavrogiannopoulos wrote:
> 
> Martin Rex wrote:
> > Considering the guidance in draft-ietf-tls-renegotiation-03.txt
> > and the specification of HelloRequest starting with rfc-2246 (TLSv1.0)
> > http://tools.ietf.org/html/rfc2246#section-7.4.1.1
> [...]
> > Question to implementors: what will your TLS servers do when a client
> > simply ignores HelloRequest--a behaviour that has been allowed by all
> > existing TLS specs for 10 years?
> 
> I always wondered how this behavior was supposed to work. For gnutls an
> error is returned if the request is ignored.  I think the use cases of
> these packets for renegotiation should be clearly defined (i.e. why send
> this packets and what should be expected from peer). I don't know how
> easy it is to implement the semantics precisely, but so far I didn't see
> any compelling reason to do so.


To me, this sounds like the server's gnuTLS switches to half-duplex
communication when it _sends_ a HelloRequest and expects the next
_received_ TLS record to carry a ClientHello handshake message
(or a warning-level no_renegotiation alert).

Can you describe/confirm the exact behaviour for gnuTLS?


>From its design, the TLS protocol is full-duplex, so such behaviour
would not be compliant to any existing SSL/TLS protocol spec.

The full-duplex requirement, which is implied by the definition
of the HelloRequest message in SSLv3 already is probably the reason
why the "may ignore" was written out for TLS:

   The hello request message may be sent by the server at any time,
   but will be ignored by the client if the handshake protocol is
   already underway.  It is a simple notification that the client
   should begin the negotiation process anew by sending a client hello
   message when convenient.

That "when convenient" accounts to the fact that the (app) client
may be writing and the TLS implementation therefore not even
looking (read) whether there might be a HelloRequest handshake
message waiting -- and continue sending application data.


-Martin