Open nmav opened 7 years ago
Given that this test script is passed by tlslite-ng, which can't verify correctness of certificates (it has a very rudimentary ASN.1 parser), I'm quite sure that you can deduce that the Certificate message is corrupt without inspecting the certificates within. So the decode_error
applies, not bad_certificate
.
In general, testing ASN.1 is something that tlsfuzzer explicitly tries not to do.
Also, that test script runs few hundred test cases, I will need more specific failure to tell for certain that it creates a valid Certificate message with invalid certificates in it or not.
@nmav ping?
The cases that I ignore due to alert code currently are:
"-e", "fuzz empty certificate - overall 7, certs 4, cert 1",
"-e", "fuzz empty certificate - overall 8, certs 5, cert 2"
What are they supposed to do? Do they have a malformed TLS handshake packet or an incorrect certificate, (or both)?
it's fuzzing an empty Certificate message, the overall
, certs
and cert
are values for the length of handshake message payload (the Certificate message), certificate_list and ASN.1Cert respectively. The message was padded with zeros to the overall
length before the changes.
given that the length of certificate_list specifies 5, and that the "2nd" and "3rd" certificate are 0-length, that's incorrect encoding of message as ASN.1Cert is defined as follows:
opaque ASN.1Cert<1..2^24-1>;
same for the case of certs
equal 4
decode_error
is thus correct
no, that actually is correct encoding of a certificate that is a single zero byte or a double zero byte:
'\x00'
and '\x00\x00'
yeah, that should cause a bad_certificate
Several of the tests in test-certificate-malformed.py fail if anything else than decode_error is returned.
That however is a bit arbitrary. The decode_error refers mostly to messages according to its description, and there is a specific alert for corrupt certificates, that is the bad_certificate alert.