Re: [TLS] SSL Renegotiation DOS

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> 
> Presumably, somewhere there is a TCP-based load-balancing DoS prevention 
> system protecting a TLS server that allows client-initiated 
> renegotiation. This system may do a good job of resisting DoSes on the 
> initial handshake but not DoSes on renegotiation handshakes.

The issue might be more about the classification of what counts as
a DoS attack.  Recognizing TLS renegotiations is technically possible for
Intrusion dectection systems, since the ChangeCipherSpec handshake
message remains visible on on the wire, even for TLS renegotiations.
(also, the fact that handshake messages rather than application data
is exchanged, remains visible on the wire).

The workload impact of full TLS handshakes on the TLS server is
far from marginal.  Therefore, even non-hostile clients can consume
most of a servers resources.

Distinguishing DoS from clients with a flaw in their TLS session caching
and defective server-side TLS session caching or inappropriate configuration
might be tricky for an IDS.  Server resources may get drained without any
errors showing up on the communication protocol level, simply by
performing the cryptographic operations of the protocol over and over again.

A TLS server can easily DoS _itself_ with an inadequate,
too small or disabled server side TLS session cache (or due to
bugs in the session cache management of the implementation).

Personally, I consider it a bad idea to run a TLS server on the
internet with TLS session caching entirely disabled.  Limiting
session cache lifetime and session cache size on the TLS server
seems sensible, but running entirely without session cache
does not look sensible to me (for public Web-Servers on the internet).

TLS clients without session caching capabilities also seem to
be unnecessarily common.  Apache mod_proxy used to be incapable
of client side TLS session caching--which causes a serious
performance impact on the communication link between reverse
proxy and backend if that link is TLS-reencrypted.

> 
> My suggestion to Jorge would be to find such a product configuration and 
> demonstrate the attack against it (and file a bug with the vendor of 
> course).
> 
> I don't see this as a real weakness in TLS itself either. Nevertheless, 
> I think might be something in scope here. Are there improvements to DoS 
> resistance which could be made in the scope of the IETF's TLS activity?

When the topic of "client identity protection" came up on the TLS
mailing list, the suggestion was made to solve this by performing
a TLS renegotiation.

Today (after the TLS renegotiation vulnerability), many servers may
have unsolicited renegotiations disabled (and may continue to have
it disabled after adopting the rfc5746 solution).  Microsoft IIS
seems to have never supported unsolicited renegotiations so far --
it was primarily "added value" for TLS implementations that could
perform TLS renegotiation "transparently", i.e. without requiring
support from the (TLS) application caller to do renegotiation.

The results that TLS renegotiation might have on the client identity,
as seen by the server application, is sufficiently non-trivial that some
discussion on this was added to the security considerations of rfc5746

   http://tools.ietf.org/html/rfc5746#section-5


-Martin