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

Rene Eberhard <[email protected]> writes:

> Hi
> 
> > 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"?
I believe that the draft is consistent. There are two separate
kinds of events:
1. A "connection close". I.e. the underlying transport closes
the connection. In the case of TCP, a TCP FIN.
2. A "closure alert" or "close_notify" which is the receipt
of a valid TLS close_notify alert message.

> I fully support the definition of the "close_notify" used in HTTP 
> over TLS but I'm unhappy with the current state. Perhaps I misunderstood
> the topic.
> 
>  [ A HTTP response without a Content-Length header. Since data length in
>    this situation is signalled by connection close a premature close
						      ^^^^^^^^^^^^^^^^
>    generated by the server cannot be distinguished from a spurious
>    close generated by an attacker.]
>  
>  Of course it can. In this case the server can properly close the TLS 
>  layer. TLS sends the "close_notify" and closes the underlying transport
>  layer (TCP). This ends in a "incomplete close" which is okay.
You misunderstand. This text refers to a premature close, i.e. one
in which the server closes the underlying transport (a connection close)
without signalling a close_notify. (See section 2.2 for this 
definition). As I state, this cannot be distinguished from a 
forged TCP FIN. Would it be clearer if the text said "spurious connection
close" instead of "spurious close"

>  [ 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.
>          
> 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 general behavior is that you should close the TLS layer
correctly (at the very least send a close_notify) in the
same circumstances in which you would close the TCP layer
correctly. (I.e. send a FIN). The point is to provide protection
for the message traffic, not to provide additional signalling.

So, the answer for Q 2 is clearly 2.2. I believe that servers
normally simply close the connection (with a FIN) if an error
occurs, so the answer for Q 1 is 1.2 as well.


-Ekr

-- 
[Eric Rescorla                                   [email protected]]
          PureTLS - free SSLv3/TLS software for Java
                http://www.rtfm.com/puretls/