[openssl-dev] [openssl.org #4394] OpenSSL 1.1.0 state machine can't read handshake headers async

David Benjamin via RT rt at openssl.org
Tue Mar 8 14:29:52 UTC 2016

On Mon, Mar 7, 2016 at 5:08 PM David Benjamin via RT <rt at openssl.org> wrote:

> No patch for this one since I'm not that familiar with your state machine.
> If the peer sends handshake messages fragmented across records such that
> the handshake message header is split over two records AND the two records
> are received in different steps asynchronously, OpenSSL fails to reassemble
> the message.
> This is because every iteration through the READ_STATE_HEADER step in
> read_state_machine resets s->init_num.
> https://github.com/openssl/openssl/blob/0d4fb8439092ff8253af72ac6bc193e77ebbcf2f/ssl/statem/statem.c#L550
> Instead, it should only get reset once between messages.
> The Basic-Server-Async-SplitHandshakeRecords test in BoringSSL's test suite
> can be used to repro this:
> https://mta.openssl.org/pipermail/openssl-dev/2016-March/005779.html
> (Also most other tests that say Async and SplitHandshakeRecords in them.)

Oh, I'd meant to elaborate on this test and forgot. It's part of a series
of tests that tries to stress all the async bits of the state machine.
SplitHandshakeRecords means each handshake message (I probably should have
named it SplitHandshakeMessages), gets fragmented so each record contains
only one byte. Async means we tell the shim to install a fake BIO that only
releases one byte at a time.

The combination does a good job at testing transport-related state machine
resumption points. I'm not familiar with how one writes TLSProxy tests, but
something proxy-based should also be able to simulate the handshake
fragmentation, and then async mode is implemented in the tested process.


Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4394
Please log in as guest with password guest if prompted

More information about the openssl-dev mailing list