Add an API that returns whether a client used TLS False Start

[zz85]

Problem:

TLS False Start is an optional behavior of TLS client that reduces latencies of requests by 1-RTT in TLS 1.2. Modern browsers and s2n on the server side support this behavior. Add an API that can help determine whether a client has connected with False Start.

Solution:

A description of the possible solution in terms of S2N architecture. Highlight and explain any potentially controversial design decisions taken.

Add

bool s2n_connection_has_false_started(conn)

When the server is handing Client Finished / Server CCS, peak into the receive buffer to see if there's application data. If so, a client has probably used False Start.

• Does this change what S2N sends over the wire? No
• Does this change any public APIs? Yes
• Which versions of TLS will this impact? Any

Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?

• RFC links: https://tools.ietf.org/html/rfc7918
• Related Issues: -
• Will the Usage Guide or other documentation need to be updated? Yes
• Testing: Test with popular browser (eg. Chrome/Firefox)
  • Will this change trigger SAW changes? No
  • Should this change be fuzz tested? Will it handle untrusted input? No

Out of scope:

Is there anything the solution will intentionally NOT address? No

[zz85]

onn->in is not hydrated by s2n_connection_recv_stuffer() even though there may be data after CLIENT FINISHED. this is because the state machine switches to write until SERVER_FINISHED is sent. since source buffers is not exposed, some options may be to have a peek api or attempt s2n_recv() prematurely, but this does not seem so straight forward or simple now.