Subject: [TLS] Tr: Behaviour when TLS fails

From: Julien ÉLIE <[email-masked]>
Date: Thu, 25 Sep 2008 08:26:02 +0200

Hi,

Would it be possible to have some more information about how to behave when
a TLS negotiation fails?

In RFC 4642 on TLS with NNTP, it is written:

    Upon receiving a 382 response to a STARTTLS command, the client MUST
    start the TLS negotiation before giving any other NNTP commands.  The
    TLS negotiation begins for both the client and server with the first
    octet following the CRLF of the 382 response.  If, after having
    issued the STARTTLS command, the client finds out that some failure
    prevents it from actually starting a TLS handshake, then it SHOULD
    immediately close the connection.

    [...]

    If the TLS negotiation fails, both client and server SHOULD
    immediately close the connection.  Note that while continuing the
    NNTP session is theoretically possible, in practice a TLS negotiation
    failure often leaves the session in an indeterminate state;
    therefore, interoperability can not be guaranteed.

But we do not know whether the "SHOULD immediately close the connection"
is in fact a MUST.

You can see a current discussion about that here:
    http://groups.google.fr/group/news.software.nntp/browse_frm/thread/aa305c96999afbcf

Some excerpts below.

Thanks beforehand for your answer (please CC: me as I am not subscribed
to the list).

Julien

----- Message d'origine ----- 
De : "Julien ÉLIE"
Groupes de discussion : news.software.nntp
Envoyé : mercredi 24 septembre 2008 19:39
Objet : Re: Behaviour when STARTTLS fails

> After having carefully reviewed it, I think I cannot submit an errata
> report for that because of the difference between fatal and warning
> messages in RFC 5246.  Even though almost everything is fatal, I see
> that one:
>
>   user_canceled
>      This handshake is being canceled for some reason unrelated to a
>      protocol failure.  If the user cancels an operation after the
>      handshake is complete, just closing the connection by sending a
>      close_notify is more appropriate.  This alert should be followed
>      by a close_notify.  This message is generally a warning.
>
> And unfortunately, the connection MAY go on (even though it SHOULD be
> closed).

----- Message d'origine ----- 
De : "Julien ÉLIE"
Groupes de discussion : news.software.nntp
Envoyé : mercredi 24 septembre 2008 21:20
Objet : Re: Behaviour when STARTTLS fails

> Hi Russ,
>
>> I was having a hard time understanding RFC 5246, but the impression that I
>> was getting was that once you start establishing STARTTLS, either you
>> finish or you fail;
>
> I also admit it is not clear at all!
>
>
>> if you send a warning message instead of an error
>> message, that means you're going to finish successfully.
>
>   If an alert with a level of warning is sent and received, generally
>   the connection can continue normally.  If the receiving party decides
>                  ^^^^^^^^^^^^^^^^^^^^^
>   not to proceed with the connection (e.g., after having received a
>   no_renegotiation alert that it is not willing to accept), it SHOULD
>   send a fatal alert to terminate the connection.  Given this, the
>   sending party cannot, in general, know how the receiving party will
>   behave.  Therefore, warning alerts are not very useful when the
>   sending party wants to continue the connection, and thus are
>   sometimes omitted.  For example, if a peer decides to accept an
>   ^^^^^^^^^^^^^^^^^
>   expired certificate (perhaps after confirming this with the user) and
>   wants to continue the connection, it would not generally send a
>            ^^^^^^^^^^^^^^^^^^^^^^^
>   certificate_expired alert.
>
>
>
>> I couldn't find any notion of an unsuccessful finish.
>
> Fatal => close.
> But with warnings, nothing very precise is said :-/
>
>   One of the content types supported by the TLS record layer is the
>   alert type.  Alert messages convey the severity of the message
>   (warning or fatal) and a description of the alert.  Alert messages
>   with a level of fatal result in the immediate termination of the
>   connection.
>
> ...
>
> -- 
> Julien ÉLIE
>
> « Tout homme devrait un jour se marier ;
>  après tout, le bonheur n'est pas la seule chose dans la vie. »

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Rex <[email-masked]>
Date: Thu, 25 Sep 2008 18:09:36 +0200 (MEST)

> Would it be possible to have some more information about how to behave when

I have no experience with STARTTLS-style extensions for protocols
such as NNTP or HTTP, but I think I know where the "should close down"
suggestion" because of the "indeterminate state" of the connection
comes from.  I also don't see a need for a MUST close down here.

The possibility to get back in sync on a connection after a SSL/TLS
handshake error (or a fatal SSL alert after a successful handshake)
is probably not a feature that most SSL/TLS stacks
offer in their APIs because it is not really deterministic.

A SSL/TLS stack could try to  recv(,,,MSG_PEEK) from the network socket
and apply heuristics whether anything that arrived during the
timeout might be a leftover SSL record from the failed SSL/TLS handshake
(or data) which would need to be cleared from the connection.  
But it is completely unclear how much SSL/TLS handshake (or data) messages
may still be in the network pipe when one side detects a fatal handshake
(or data) error and aborts.

Even in the successful TLS session closure case, when the connection is
gracefully completed with the CloseNotify closure alerts it is common
behaviour that the closure alert of one side dies unread in the network
pipe.  TLS v1.1 (and newer) explicitly mentions this characteristic for the
successful closure and describes what would have to be done/changed to
reuse a network connection of a _successfully_ closed SSL/TLS communication:

   Unless some other fatal alert has been transmitted, each party is
   required to send a close_notify alert before closing the write side
   of the connection.  The other party MUST respond with a close_notify
   alert of its own and close down the connection immediately,
   discarding any pending writes.  It is not required for the initiator
   of the close to wait for the responding close_notify alert before
   closing the read side of the connection.

   If the application protocol using TLS provides that any data may be
   carried over the underlying transport after the TLS connection is
   closed, the TLS implementation must receive the responding
   close_notify alert before indicating to the application layer that
   the TLS connection has ended.  If the application protocol will not
   transfer any additional data, but will only close the underlying
   transport connection, then the implementation MAY choose to close the
   transport without waiting for the responding close_notify.  No part
   of this standard should be taken to dictate the manner in which a
   usage profile for TLS manages its data transport, including when
   connections are opened or closed.

I can not think of a good and robust way to clear a network
connection from SSL/TLS errors, and even if someone came up with
a workable scheme, it would take much to long to be adopted by the
installed base and probably not usable/useful for several years.
Btw. not all (network) pipes offer "PEEK" and how long do you wait?

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Sep 2008 09:27:28 -0700

At Thu, 25 Sep 2008 08:26:02 +0200,
> Thanks beforehand for your answer (please CC: me as I am not subscribed

TLS doesn't have any opinion about what you do with the underlying 
transport. So, as far as TLS is concerned, the underlying transport
(TCP) could stay open and you could try to negotiate NNTP on it.
It might even work. It's recommended not for the reasons noted
above. I wouldn't have a problem with 4462 saying MUST, but
I don't think it's required by the logic of TLS.

-Ekr