Skip to content
This repository has been archived by the owner on Jun 17, 2024. It is now read-only.

miTLS server does not enforce max_early_data of a ticket properly #185

Open
oweisse-msft opened this issue Aug 4, 2017 · 1 comment
Open
Assignees

Comments

@oweisse-msft
Copy link

oweisse-msft commented Aug 4, 2017

Using a session ticket which has max_early_data = 16384, 6 bulks of early data messages were sent, with sizes of 4095, 4096, 4096, 4096, 4096, 4096 bytes. Only then EndOfEarlyData was sent.

  1. It seems that after the 5th early message, the server will not accept any more early data, but it will accept the first 5. I.e., the first 5 calls to FFI_mitls_receive will return the first 5 early data messages. The 6th call to FFI_mitls_receive will return nothing. Overall , 20479 bytes were received as early data, which are 4095 bytes more than allowed by the ticket. I assume the desired behavior is accepting only the first 16384 bytes.

  2. According to section 4.6.1 in the RFC (draft-21), max_early_data

A server receiving more than max_early_data_size bytes of 0-RTT data SHOULD terminate the connection with an "unexpected_message" alert.
However, no alert was emitted by the server upon receiving the 5th early data message.

  1. On the client side, the early data messages were sent using FFI_mitls_send, which should have perhaps split the data into early data and regular app data.

To summarize: The client side behavior of FFI_mitls_send is probably wrong, and the server side behavior (accepting the early data) is potentially a violation of the security parameter max_early_data.

@BarryBo
Copy link

BarryBo commented Jun 1, 2018

I'm assigning to you, to confirm this is a bug, and that it'll be addressed via verification work.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants