Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-renegotation: next

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> Obviously the part that says
> > If this is the initial handshake for a connection, then the
> >       "renegotiated_connection" field is of zero length in both the
> >       ClientHello and the ServerHello.
> is not limiting itself to renegotiations.
> 
> I don't know how the IETF rules work, if a future implementaion can say
> it implements proper TLS without implementing this extension. In
> practice, every TLS implementation (except perhaps yours) is going to
> want to implement the security fix properly lest they be shunned by
> other implementations.

I'm not an IETF process wizard. but I have not knowingly come
across such a situation with IETF protocols so far.

There will likely not be TLSv1.0-2010, TLSv1.1-2010 and TLSv1.2-2010.

There will be implementations of particular RFCs, but if an
implementation says TLSv1.0, that will not _by_itself_ imply
that this includes any updates.  You will probably need to look
for the update-RFC number to be explicitly mentioned.

The point in time when a product is developed or shipped or sold
does not impact this at all.


> 
> > Section 4 seems to be incomplete, the last paragraph describes
> > the situation only for non-renegotiating clients, the paragraph
> > for non-renegotiating servers appears to be missing from section 4,
> > but belongs there as well and with comparable characteristics
> > than for non-renegotiating clients.
> 
> You appear to be questioning why there isn't an equivalent statement
> about servers which do not renegotiate.

Correct.  The absence of that makes that update unnecessary complex.

Myself, I don't have any of the gadgets like these:
http://www.networkwebcams.co.uk/product_info.php?products_id=855

which implement SSL.  I don't know whether they desperately need
renegotiation, but I woul not discount the possibility that they
do not need it.  I don't know how many years manufacturers provide
firmware updates for such gadgets, and how difficult it is to
update them.  But if such a thing doesn't need renegotiation,
then it might make a difference for the decision for a manufacturer
whether to develop a firmware update for a 3+ year old product,
whether there's a simple "I'm updated" signaling available.


I guess we will get accustomed to using several browsers in a year
in order to not have to unnecessarily dump a lot of equiment that
isn't really defective, but no longer interoperable with browsers
from some suppliers.  Those weenies in the IETF that ask for
interoperability in communication protocols do not have a clue
about communication _and_ security, and do not understand how
important it is that you Javascript- and ActiveContent-enabled
Browser no longer talks to this dangerous WebCam and all those
other boxes and gadgets that you bought more than two years ago.
 


> 
> It's not an equivalent situation because the server must respond to the
> client hello as it was sent and can not "simply use the SCSV in all
> initial handshakes" like the client can. The logic for a
> non-renegotiating server does not reduce as much as it does for a
> non-renegotiating client.

Well, it _could_ be like that, as demonstrated by my specification.


> 
> >> TLS does not define such a thing as a "server that does not
> >> renegotiate".

There are a number of things that TLS fails to define -- which is
exactly the reason why the TLS renegotiation vulnerability went
unnoticed for so long.

My copy of rfc-5246 clearly describes that there are non-renegotiating
clients and servers:

rfc5246,  Appendix D

   D.4.  Implementation Pitfalls

   Implementation experience has shown that certain parts of earlier TLS
   specifications are not easy to understand, and have been a source of
   interoperability and security problems. 

   TLS protocol issues:

    -  Do you support renegotiation, both client and server initiated?
       While renegotiation is an optional feature, supporting it is
       highly recommended.



> 
> >> Therefore, it is impossible for a general-purpose client to know this
> >> about any specific server.
> >>
> >> Therefore, it is a useless consideration for the protocol design.
> > 
> > Huh?
> 
> Yes. It is impossible for a TLS clients to know that they are talking to
> a server which can not be triggered to renegotiate in the general case,
> or even in most specific cases.

So what?

Do you think that dropping from HTTPS as it is today to HTTP
will be an improvement to the overall security of the internet,
because you _are_, in fact, suggesting this?


> 
> > If you want to reliably disable it, it's <10 LoC.
> 
> http://cvs.openssl.org/timeline?d=5&e=2009-Nov-10&c=2&px=&s=1&dt=1&x=1&m=1&w=0
> 
> It was a little more than 10 LoC, but not a huge amount either.

As I previously mentioned, the "official" patch that is currently
in openssl-0.9.8l seems a little rough, because it will freeze
the handshake when the client sends a ClientHello on an established
TLS session.

The patch that I would use to reliably abort a renegotiation handshake
would be something like

s3_srvr.c:

    case SSL3_ST_SR_CLNT_HELLO_C:
+        if (NULL != s->enc_read_ctx)
+            {
+            SSLerr( /* some adequate error code */ );
+            s3_send_alert(s,SSL_AL_FATAL,SSL_AD_HANDSHAKE_FAILURE);
+            return(-1);
+	     }
	 ...
	 ssl3_get_client_hello(s,...)
		

> 
> > I'm sure the OpenSSL code maintainers didn't need a code inspection
> > in order to find out which statements would be necessary to
> > make sure the renegotiation will _not_ work.
> 
> I guess you've never looked at the OpenSSL codebase then. But I don't
> actually know of any codebase in which you can usefully change it
> without a little code inspection first.

No, I didn't.  That diff I posted which implements my specification
is only a wild guess an works by pure chance,  just like a lot of
those TLS protocol implementations that you know perform renegotiation
without their original _implementors_ being aware of it.


-Martin