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

[Marsh Ray <[e-mail]>]

Martin Rex wrote:
> Marsh Ray wrote:
>>> I got confused.  It is about early adopter clients that send
>>> TLS extension RI (not knowning about SCSV) and might run into
>>> updated servers that look only for SCSV.
>> Such servers are not permitted by the current proposal.
>>
>> From http://www.ietf.org/id/draft-ietf-tls-renegotiation-02.txt
>>>    Upon receipt of the "renegotiation_info" extension, both client and
>>>    server implementations which support the extension MUST verify that
>>>    it contains the correct contents as specified above (the previous
>>>    client Finished.verify_data in the ClientHello and the concatenation
>>>    of both Finished.verify_data values in the ServerHello).  If the
>>>    contents are incorrect, then it MUST generate a fatal
>>>    "handshake_failure" alert and terminate the connection.
>> [...]
>>>    TLS servers MUST support both the "renegotiation_info" extension and
>>>    the TLS_RENEGO_PROTECTION_REQUEST SCSV.  TLS servers which support
> 
> 
> You're quoting section 3 of the document.

You mean the section "3.  Extension Definition"?

> That part only applies to TLS peers implementing secure _renegotiation_.

Whatever gave you that idea?

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.

> Section 4 seems to be incomplete, the last paragraph describes
> the situation only for non-renegotiating clients, the paragraph
> for non-renegotiating appears to be missing from section 4,

For non-renegotiating what? There appears to be a word missing so your
paragraph seems to be incomplete.

> 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. If its absence is conspicuous
and distracting to you, perhaps we should strike that whole last
paragraph. It is redundant anyway.

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.

>> TLS does not define such a thing as a "server that does not
>> renegotiate". There may be in fact some application protocols or servers
>> which do not, but TLS provide no way to indicate this in the handshake.
>>
>> In practice, it requires deep code inspection to prove and many
>> application authors have been surprised to find out that their TLS
>> implementation will renegotiate for them automatically.
> 
> An SSLv3 or TLS implementation will definitely not perform
> TLS renegotiation by accident or coincidence.  It will require
> a few lines of code to enable that.

Many applications have gotten renegotiation for free from their helpful
TLS implementations with zero lines of added code.

> What may happen, is that developers or maintainers who inherited
> code are not (or no longer) aware of the functionality being present.

Or even more likely, the application writers.

>> 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 there even is _no_ security problem involved.
>> An unpatched TLS connection can only be believed secure with code
>> inspection done on _both_ endpoints to prove that renegotiation can
>> never happen and/or application protocol analysis. Since a primary
>> feature of TLS is to support interoperability between diverse client and
>> server implementations, this is just not a common enough case to be
>> worth considering.
> 
> Code inspection?  That seems to be a fairly inefficient way.
> 
> If you want to know whether it is there, try it.

And you will conclude wrongly and it will result in a security
vulnerability.

Try doing a client-initiated renegotiation against MS IIS for example.
It will hang up on you. Yet it's clear that a properly constructed HTTP
request and the right server configuration will cause it to perform
server-initiated renegotiation.

Similarly, an https client may refuse requests for renegotiation unless
he has a client certificate he's willing to offer to that specific
server. There is absolutely no way for a server to determine whether
this is the case or not with the client that's attempting to connect
insecurely.

It is very difficult to prove a negative.

Security analyses based on "the remote endpoint does not renegotiate
therefore our connection is not vulnerable" are betting they can prove
that negative correctly every single time. My money is on the attacker
who only needs to disprove it once.

Again, the TLS protocol does not define such a thing as "TLS without
renegotiation" and consequently there is no way for an endpoint to know
that his remote peer can never be enticed into renegotiating.

> 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.

> 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.

- Marsh