Current git checkout of 1.0.1, 1.0.2 and master accept malformed Client Hello messages.
If the client sends a Client Hello message with extensions.length field equal to 0, but padded with bytes FF01 0001 00 then the Server Hello will contain the renegotiation_info extension. This is in violation of RFC 3546 and RFC 4366 MUST: A server that supports the extensions mechanism MUST accept only client hello messages in either the original or extended ClientHello format, and (as for all other messages) MUST check that the amount of data in the message precisely matches one of these formats; if not then it MUST send a fatal "decode_error" alert. This overrides the "Forward compatibility note" in [TLS]. as well as the RFC 5246 MUST clause: A server MUST accept ClientHello messages both with and without the extensions field, and (as for all other messages) it MUST check that the amount of data in the message precisely matches one of these formats; if not, then it MUST send a fatal "decode_error" alert. Reproducer: openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -nodes -batch openssl s_server -key localhost.key -cert localhost.crt -www in other console: pip install --pre tlslite-ng git clone https://github.com/tomato42/tlsfuzzer.git cd tlsfuzzer PYTHONPATH=. python scripts/test-truncating-of-client-hello.py -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: PGP signature
_______________________________________________ openssl-bugs-mod mailing list [email protected] https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
