Re: WG Last Call: HTTP over TLS (draft-ietf-tls-https-02.txt)

On Fri, Aug 06, 1999 at 04:58:58AM -0400, Rene Eberhard wrote:

>> You could not receive a "Connection: close" *after* the closure alert.
>> Obviously this is about transport protocol closures -- FIN packets in
>> the case of TCP.

> Of course you are right. But why use synonyms when you can
> use "closure alert" or "close_notify"?

Does it use synonyms?  As far as I remember, the draft always says
"closure alert" when talking about the TLS facility of this name, and
says "connection close" only when discussing events at the underlying
transport protocol.

>  [ A HTTP response with a valid Content-Length header closed before
>    all data has been read. Because TLS does not provide document 
>    oriented protection, it is impossible to determine whether the 
>    server has miscomputed the Content-Length or an attacker has 
>    truncated the connection. ]
> 
> Now its getting interesting. How should a server behave when
> 1. an internal error occurred?
>    1.1 Close the TCP layer (FIN, RST) which ends up in a
>        "premature close". In this case the client
>        can detect that something unexpected had happened.
> 
>    1.2 Close the TLS layer which closes the TCP layer. This
>        ends up in a "incomplete close". In this case the client
>        can only detect an unexpected error on the server
>        side if a content length info has been sent.

If the HTTP protocol is used in a way such that the client cannot
detect the error at HTTP level, then the server should not send a TLS
closure alert.

> 2. the response completed successfully?
>    2.1 Close the TCP layer (FIN, RST) which ends up in a
>        "premature close". I see no reason why a server
>        should close the TCP layer without closing
>        the TLS layer before.
>        
>    1.2 Close the TLS layer which closes the TCP layer. This
>        ends up in a "incomplete close". This is the correct 
>        behavior.

The latter one, obviously.

> Of course we can combine the "close_notify" message with 
> any combination of (FIN | RST) but this would not be 
> very clever =)

RST would be incorrect (the client's TCP may throw away the
close_notify before the TLS implementation could glimpse at it),
but of course there'll be a FIN when the TCP connection is closed.