On Sunday 09 August 2015 16:41:19 dott...@gmail.com wrote: > I have a question regarding the handshake message length. > > The 'decode_error' alert in TLS 1.2 is defined as: > > decode_error > A message could not be decoded because some field was out of the > specified range or the length of the message was incorrect. (...) > > It says that the message "could not be decoded". What should happen > if the specified message length is longer than needed? I.e. the message > was successfully decoded, but the length of the message was incorrect: > there is still some unknown data after the defined structure.
that is definitely error for the case of a "length of a field is longer than expected" or "there's more data in message than the length specifies" > For example, a Finished message has a length of 40 bytes, > but the 'verify_data' array has 32 bytes and there are 8 unknown bytes > remaining in the received message. The 40 bytes I talk about here > is the length specified in the Handshake message header. > > Is this also a fatal error? yes, always > Should the implementation just drop those bytes and proceed? definitely not, it should send a fatal alert, close connection and mark session as non resumable > On the other hand, there is the 'illegal_parameter' alert: > > illegal_parameter > A field in the handshake was out of range or inconsistent with > other fields. This message is always fatal. > > Is this alert suitable for the described scenario? no, it's for values that are explicitly bound to some specific range (e.g. client_random length tag always needs to be 32) verify_data has no range specified (it's opaque data), the negotiatied ciphersuite defines what length it has -- 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: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
