Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

From: Hubert Kario <[email-masked]>
Date: Fri, 04 Dec 2015 18:45:25 +0100

On Friday 16 October 2015 22:36:10 Kurt Roeckx wrote:
> On Fri, Oct 16, 2015 at 04:05:34PM +0200, Hubert Kario wrote:
> > On Friday 16 October 2015 09:16:01 Watson Ladd wrote:
> > > Unfortunately I don't know how to verify this. Can miTLS cover
> > > this
> > > case?
> > 
> > you mean, you want an implementation that can insert application
> > data in any place of the handshake?
> 
> Have you tried running any of your tests against miTLS?

Yes, I finally did

miTLS does accept Application Data when it is send between Client Hello 
and Client Key Exchange and rejects it when it is sent between Change 
Cipher Spec and Finished.

Though I will need to modify tlsfuzzer a bit more before I will be able 
to publish an automated test case for that*

 * - miTLS writes HTTP responses in a line-by-line basis, making 
handling of its responses a bit more complex
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 5 Dec 2015 23:54:25 +0000

Hubert Kario <[email-masked]> writes:

>miTLS does accept Application Data when it is send between Client Hello and
>Client Key Exchange and rejects it when it is sent between Change Cipher Spec
>and Finished.

Given that miTLS is a formally verified implementation, would this imply that
there's a problem with the verification?  "Beware of bugs in the above code; I
have only proved it correct, not tried it"?

Peter.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 5 Dec 2015 19:20:11 -0500

> have only proved it correct, not tried it"?

Are you saying there is a security flaw with the behavior described?
Because I don't believe there is after one adopts Extended Master
Secret. (Someone more familiar with the security should check this)
>
> Peter.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 6 Dec 2015 01:18:51 +0000

>Are you saying there is a security flaw with the behavior described?

I hadn't even thought it through to that point, more that you're not supposed
to accept anything between Client Hello and Client Keyex except an optional
Client Certificate.

(OK, I haven't gone through every extension RFC and draft to see what else you
could poke in there, but I'm pretty sure Application Data isn't one of them).

Peter.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 5 Dec 2015 21:10:13 -0500

> could poke in there, but I'm pretty sure Application Data isn't one of them).

miTLS did not claim to be consistent with the RFC. Rather it claimed
to be secure, and to interoperate with most other implementations in
circumstances tested. The informal nature of the RFC makes it
impossible to carry out formal verification against it.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 6 Dec 2015 02:33:39 +0000

Watson Ladd <[email-masked]> writes:

>miTLS did not claim to be consistent with the RFC. Rather it claimed to be
>secure, and to interoperate with most other implementations in circumstances
>tested. The informal nature of the RFC makes it impossible to carry out
>formal verification against it.

By that argument, you could start accepting SSH messages in the middle of the
TLS handshake.  No matter how you colour it, accepting Application Data after
a Client Hello is wrong.  Is there any random, non-formally-verified
implementation that would do that?

Peter.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 5 Dec 2015 21:44:45 -0500

> implementation that would do that?

Any implementation where the record layer state is maintained
separately from the handshake state will do this automatically. The
only security issue is when data is intermingled across authentication
boundaries, but once the record layer is told to encrypt at all that
doesn't happen. If you disagree, please cite the sentence of the TLS
RFC which prohibits accepting application data records during the
handshake.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 6 Dec 2015 02:48:33 +0000

Watson Ladd <[email-masked]> writes:

>please cite the sentence of the TLS RFC which prohibits accepting application
>data records during the handshake.

Please cite the sentence of the TLS RFC which prohibits accepting SSH messages
during the handshake.

Please cite the sentence of the TLS RFC which prohibits executing
/usr/games/hack during the handshake.

Please cite the sentence of the TLS RFC which prohibits reformatting the
user's hard drive during the handshake.

(This debate is pointless and probably annoying everyone else, so I'll bow out
now).

Peter.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 5 Dec 2015 21:58:33 -0500

> (This debate is pointless and probably annoying everyone else, so I'll bow out

So what basis do you have for your assertion that you aren't supposed
to accept data between Client Hello and Client Key Exchange? I think
on the contrary that interleaved data was intended to be handled
transparently: so long as the Finished message goes after the CCS
message, with no intervening data, each record layer is associated to
one of two handshakes unambiguously.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 6 Dec 2015 08:59:31 +0200

> On 6 Dec 2015, at 4:44 AM, Watson Ladd <[email-masked]> wrote:
> 
>  If you disagree, please cite the sentence of the TLS

OK, I’ll bite. Top of page 36:

      Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

             Figure 1.  Message flow for a full handshake

See?  Application data goes *after* the Finished message. Not between ClientHello and anything else. Now this swim track diagram may not look like a formal definition, but RFCs are written to be processed by humans, not computers. If I add some application data in the middle there like this:

      Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Application Data
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

Any human can see that this is not the same as what’s in Figure 1, and thus is wrong. We don’t need the RFC to provide a regular expression or a state machine diagram to figure that out.

Yoav

---

From: Watson Ladd <[email-masked]>
Date: Sun, 6 Dec 2015 07:15:14 -0500

> See?  Application data goes *after* the Finished message. Not between ClientHello and anything else. Now this swim track diagram may not look like a formal definition, but RFCs are written to be pr…

(Ever meet a tax lawyer?)

But is it defining the flow of messages in the Handshake protocol, or
on the wire? The reason I think it's the first is that the RFC several
times explains that different layers above the record layer are
independent.

Even if that's prohibited, there is no requirement to send an alert if
that happens: allowing it is not prohibited. In fact several emails in
this thread show that other implementers agree with my reading, and
that there exist implementations that have this behavior.

I hope that whatever renegotiation replacement we have in TLS 1.3
explicitly specifies that this sort of trick is allowed.

---

From: Kurt Roeckx <[email-masked]>
Date: Sun, 6 Dec 2015 14:08:08 +0100

> to accept anything between Client Hello and Client Keyex except an optional

Please read the start of the thread, that includes relevant RFC
sections that seem to indicate you can do this.

Kurt

---

From: Hubert Kario <[email-masked]>
Date: Sun, 06 Dec 2015 16:50:28 +0100

On Saturday 05 December 2015 23:54:25 Peter Gutmann wrote:
> >miTLS does accept Application Data when it is send between Client
> >Hello and Client Key Exchange and rejects it when it is sent between
> >Change Cipher Spec and Finished.
> 
> Given that miTLS is a formally verified implementation, would this
> imply that there's a problem with the verification?  "Beware of bugs
> in the above code; I have only proved it correct, not tried it"?

This behaviour is dictated by the TLS 1.2 RFC, although partially 
indirectly:
 - the acceptance of application data during subsequent handshakes is 
   explicit
 - the no application data between CCS and Finished is implicit, as it
   is only stated that the Finished MUST be the next message directly
   following CCS. And since CCS and Finished have different content 
   types, that means that the limitation is cross-content type, unlike 
   for other handshake messages

So on the face of it, behaviour of miTLS is correct.

Now, as we've discussed on the OpenSSL bug tracker. This does cause 
problems if we have certificate based client authentication and the TLS 
library returns client authentication data from *new* handshake while it 
still has not received and processed Finished message. If that is the 
case, then the attacker may force the server to process messages under 
authority it still didn't verify.

---

From: Hubert Kario <[email-masked]>
Date: Sun, 06 Dec 2015 16:53:20 +0100

On Saturday 05 December 2015 19:20:11 Watson Ladd wrote:
> >>Hello and Client Key Exchange and rejects it when it is sent
> >>between Change Cipher Spec and Finished.
> >>
> > imply that there's a problem with the verification?  "Beware of
> > bugs in the above code; I have only proved it correct, not tried
> > it"?
> 

Extended Master Secret doesn't come into play here at all. The attack 
requires just a passive observation of a legitimate exchange for the 
attacker to have enough information to fake its identity, provided that 
TLS library returns data to application from a new handshake in 
renegotiation before the renegotiation finished.

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Sun, 6 Dec 2015 17:04:59 +0100

Our state machine design in miTLS was quite deliberate, and based on our interpretation of the TLS 1.2 spec. It is possible that we got this interpretation wrong, but maybe the protocol authors can clarify the intended behavior.

However, I think that looking at the Handshake protocol message sequence (Figure 1) for guidance is misleading, because this sequence only concerns the first handshake and does not handle renegotiation. Otherwise, all messages would be marked as optionally encrypted. A proper interpretation of this issue must take into account the two-layer Record/Handshake split that is inherent to TLS 1.2. For example, one interpretation is that the CCS message changes Record state and Application Data can then directly interact with Record without necessarily being aware of Handshake status.

In any case, a note about the miTLS security theorem. In miTLS, every application data fragment is labeled by the epoch in which it is sent and received. miTLS itself does not concatenate data from different epochs, but gives applications enough information about the two epochs so that it can choose to combine data from different epochs (say if the  certificates used in the two epochs are the same.)

So, the miTLS security theorem shows that sending and accepting data during a renegotiation handshake is fine, as long as:
(a) this data is treated as belonging to the previous epoch, not the next one, and
(b) no data is sent or accepted between CCS and Finished in either direction.
Notably, this means that if the new epoch uses new certificates for the client and/or server, any application data sent during the handshake does not get to be authorized with the new certificates, since it still belongs to the old epoch. If the current handshake completes and then new data is sent, the new data will be labeled with the new epoch. Now, the application on top of TLS gets to decide whether it wants to concatenate the data streams from the two epochs.

For other implementations, I do agree that sending or accepting data once renegotiation has begun but before the new handshake has finished can be dangerous, because it is sometimes unclear whether this data will be associated with the as-yet-unconfirmed parameters of the new handshake.

Best,
-K.

> On 06 Dec 2015, at 16:50, Hubert Kario <[email-masked]> wrote:
> 
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic_______________________________________________
> TLS mailing list
> [email-masked]

---

From: Hubert Kario <[email-masked]>
Date: Sun, 06 Dec 2015 17:05 +0100

On Sunday 06 December 2015 02:48:33 Peter Gutmann wrote:
> >please cite the sentence of the TLS RFC which prohibits accepting
> >application data records during the handshake.
>
> Please cite the sentence of the TLS RFC which prohibits accepting SSH
> messages during the handshake.
>
> Please cite the sentence of the TLS RFC which prohibits reformatting
> the user's hard drive during the handshake.
> 
> (This debate is pointless and probably annoying everyone else, so I'll
> bow out now).

Peter, I think you should go back to the beginning of the thread.
(I'm sorry for the necromancy making it a bit hard, but there was a 
direct question aimed at me that I didn't have time to answer earlier 
and I don't think we arrived at conclusion before)

To summarise:
RFC 5246 Section 6.2.1 states:
   Recipients MUST receive and process interleaved
   application layer traffic during handshakes subsequent to the first
   one on a connection.

At the same time, sections like 7.4.7 state:
   It [Client Key Exchange message] MUST immediately
   follow the client certificate message, if it is sent.
or, at section 7.4.9:
      A Finished message is always sent immediately after a change
      cipher spec message

The question is, which one takes precedence?
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Hubert Kario <[email-masked]>
Date: Sun, 06 Dec 2015 17:09:09 +0100

On Sunday 06 December 2015 02:33:39 Peter Gutmann wrote:
>
> No matter how you colour it, accepting
> Application Data after a Client Hello is wrong.  Is there any random,
> non-formally-verified implementation that would do that?

The discussion is about renegotiated handshakes, and yes there is one.
Java implementation of TLS can send Application Data during subsequent 
handshakes.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic