ChangeCipherSpec messages have a defined value. They also may not occur in the middle of a handshake message. The current logic will accept a ChangeCipherSpec with value 2. It also would accept up to three bytes of handshake data before the ChangeCipherSpec which it would discard (because s->init_num gets reset).
Instead, require that s->init_num is 0 when a ChangeCipherSpec comes in. The BadChangeCipherSpec-1 test in BoringSSL's test suite can be used to repro part of this: https://mta.openssl.org/pipermail/openssl-dev/2016-March/005779.html We do also have a series of FragmentAcrossChangeCipherSpec tests, but they assume the buggy behavior was to concatenate the pre- and post-CCS fragments, rather than drop the pre-CCS fragment. Instead, applying this patch will repro: diff --git a/ssl/test/runner/handshake_server.go b/ssl/test/runner/handshake_server.go index 0232772..3a93d48 100644 --- a/ssl/test/runner/handshake_server.go +++ b/ssl/test/runner/handshake_server.go @@ -907,6 +907,9 @@ func (hs *serverHandshakeState) sendFinished(out []byte) error { hs.writeServerHash(hs.finishedBytes) postCCSBytes := hs.finishedBytes + if !c.isDTLS { + c.writeRecord(recordTypeHandshake, []byte{'A'}) + } if c.config.Bugs.FragmentAcrossChangeCipherSpec { c.writeRecord(recordTypeHandshake, postCCSBytes[:5]) postCCSBytes = postCCSBytes[5:] David -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4391 Please log in as guest with password guest if prompted
0005-Tighten-up-logic-around-ChangeCipherSpec.patch
Description: Binary data
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
