search

tlsfuzzer / tlsfuzzer

SSL and TLS protocol test suite and fuzzer
GNU General Public License v2.0
556 stars 115 forks source link

test-certificate-malformed.py: expecting decode_error alert instead of bad_certificate alert #117

Open nmav opened 7 years ago

nmav commented 7 years ago

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.

   bad_certificate
      A certificate was corrupt, contained signatures that did not
      verify correctly, etc.
tomato42 commented 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.

tomato42 commented 6 years ago

@nmav ping?

nmav commented 6 years ago

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)?

tomato42 commented 6 years ago

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

tomato42 commented 6 years ago

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