Subject: [TLS] TLS Next Proto negotiation

From: [email-masked]
Date: 18 Jul 2011 12:22:59 -0000

Hi,
I have gone the TLS NPN draft, it talks about the new handshake message Next Protocol handshake message which is sent from Client to server after Change cipher spec and before Finish. But when I capture the packet with NPN enable(using google chrome to browse google web services), I find NULL NPN extnesion is sent from client to server and server is responding back with NPN extension with the protocol. But there is no next protocol handshake message sent by client after change cipher spec, instead I see a strange encrypted packet from Server side even before server is sending change cipher spec, this is on new session.
&nbsp;
Can some one help me on understanding the next protocol handshake message, the format and other details, of whether it is encrypted/decrypted. or provide me a packet cpature with has these details.
&nbsp;
Thanks and Regards,
Swarupa

---

From: Adam Langley <[email-masked]>
Date: Mon, 18 Jul 2011 08:43:30 -0400

> I have gone the TLS NPN draft, it talks about the new handshake message Next Protocol handshake message which is sent from Client to server after Change cipher spec and before Finish. But when I ca…

Make sure that you're looking at the draft which reflects the current
implementation:
http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-02

The strange, encrypted message from the server is probably a session
ticket. Wireshark, at least in some versions, doesn't understand it
and incorrectly describes it as encrypted.

If the NPN extension exchange happened then the NextProtocol message
will be sent. Again, Wireshark doesn't dissect it very well and may
believe that it was merged into the Finished message; you'll have to
look at the bytes yourself. In the particular Chrome implementation,
the NextProtocol message is sent in its own record, so you can see the
framing without having to decrypt anything.

Cheers

AGL

---

From: Marsh Ray <[email-masked]>
Date: Thu, 21 Jul 2011 17:06:13 -0500

> http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-02

The server needs to see the client's NextProtocol message to know what 
protocol will be in use. But when a session is resumed, the server sends 
the Finished message before the client. Some app protocols have the 
server send the first application data, e.g., "username: ". If such an 
app protocol is a possibility, doesn't the use of NPN introduce an extra 
round-trip delay in case of session resumption?

Also, since the semantics of NPN apply explicitly to the connection 
(rather than the session or connection state), perhaps the use of NPN 
ought to be contingent on the successful negotiation of RFC 5746 
Renegotiation Indication. Multiplexing multiple protocols from same 
server port are likely to provide additional opportunities for an 
attacker to put the server in a state where it is willing to accept a 
renegotiating ClientHello. It will also provide more ways for an 
attacker to have the server echo back chosen plaintext to be interpreted 
as HTTP response headers (or other protocols could be attacked).

- Marsh

---

From: Adam Langley <[email-masked]>
Date: Thu, 21 Jul 2011 18:11:08 -0400

On Thu, Jul 21, 2011 at 6:06 PM, Marsh Ray <[email-masked]> wrote:
> protocol will be in use. But when a session is resumed, the server sends the
> Finished message before the client. Some app protocols have the server send
> the first application data, e.g., "username: ". If such an app protocol is a
> possibility, doesn't the use of NPN introduce an extra round-trip delay in
> case of session resumption?

Yes, NPN precludes the possibility of a server-side False Start.

> Also, since the semantics of NPN apply explicitly to the connection (rather
> than the session or connection state), perhaps the use of NPN ought to be
> contingent on the successful negotiation of RFC 5746 Renegotiation
> Indication. Multiplexing multiple protocols from same server port are likely
> to provide additional opportunities for an attacker to put the server in a
> state where it is willing to accept a renegotiating ClientHello. It will
> also provide more ways for an attacker to have the server echo back chosen
> plaintext to be interpreted as HTTP response headers (or other protocols
> could be attacked).

That sounds quite sensible to me. I'm happy to include such a requirement.

Cheers

AGL