TLS Module report empty even though multiple versions of TLS supported

[duncangreene]

Describe the bug
Testrun reports TLS 1.2 and TLS 1.3 are available on the below device (albeit with a "certificate is invalid" description).

The Services Module shows at least 3 services that support TLS (443, 4911 and 5011), although I understand that you don't intend to support TLS tests for non-HTTP services at present.

However the TLS Module section of the report states "no TLS certificates found".

For the avoidance of doubt, the device does present a certificate on 443.

To Reproduce
Steps to reproduce the behaviour:

1. Run test against device offering TLS 1.2 and TLS 1.3.

Expected behaviour
The TLS Module would contain details against TLS 1.2 and/or against TLS 1.3 and/or just the certificate details irrespective of which version of TLS the cert was presented using (assuming exact same cert is presented via both 1.2 and 1.3).

Error logs

jace8000.zip

Environment (please provide the following information about your setup):

• Version: 2.1

Additional context
Only modifications from official 2.1 release are as below.

• resources/test_packs/qualification.json (Set tests to excluded/recommended/informational as appropriate)
• resources/devices/device_profile.json (Add custom questions)

[jhughesoti]

I tested on a JACE8000 on multiple runs and I was not able to recreate this issue. The only thing I could find that was different was that the server certificate exchange is not captured in the tls module in the provided files that I do see in my attempts.

Can you confirm the station and web service for your JACE are fully booted up in the 5 minute monitor window? It might be possible the web service isn't fully ready when being connected to and not reporting certificates correctly but later when nmap runs, things are more stable.

[duncangreene]

Can you confirm the station and web service for your JACE are fully booted up in the 5 minute monitor window? It might be possible the web service isn't fully ready when being connected to and not reporting certificates correctly but later when nmap runs, things are more stable.

@jhughesoti I can confirm the station and web service for this JACE are fully up and running within the monitor period. Furthermore, I have now seen this behaviour on a completely separate make and model of device on 2.1.1. I'll post this up in a sec.

I tested on a JACE8000 on multiple runs and I was not able to recreate this issue. The only thing I could find that was different was that the server certificate exchange is not captured in the tls module in the provided files that I do see in my attempts.

@jhughesoti I notice that the cert is included within the jace8000.zip file above, so Testrun does have visibility of it. What's causing analysis/detail of it not to appear within the TLS section of the report?

[duncangreene]

As promised, issue now observed on a completely separate device on 2.1.1 below.

report (33).zip

Same as above in that the device cert is clearly present within the /tls directory below.

For info, below is a Wireshark capture taken whilst accessing the device web interface later in the day using HTTPS, if it's of interest.

loadwebpage.zip

Yet TLS section in report states "No TLS certificates found on the device".

[jboddey]

We are looking into this.

[jhughesoti]

@duncangreene
I have yet to recreate this failure on a JACE8000 running in TLS 1.3 or 1.2. Are you able to recreate this scenario reliably on the current dev branch? If so, can you provide further details to your devices configuration and testing setup for further review?

It would be helpful if you also use the additional logging configuration in the tls module and set it to debug to help identifying the issue:
https://github.com/google/testrun/blob/dev/docs/additional_config.md#override-test-module-log-level-at-the-system-level

[duncangreene]

@jhughesoti I'll seek to get hold of a JACE 8000 again and see.

Unfortunately we no longer have access to the Delmatic device referenced in the comment above, nor the device referenced in the similar issue #1144, but will additionally keep an eye out next time we spot this occurring on another device too.

Was the loadwebpage.zip Wireshark trace in the comment above useful? Just wondering whether we should seek to capture these when we encounter another device doing it, or whether we don't need to?

[jhughesoti]

There was nothing that indicated an issue with any of the files provided. If you come across it again and are able to update the module logging to debug, that will help in pinpointing the cause of this.

[jboddey]

Closing this issue for now. Let us know if this occurs again.

[duncangreene]

Please reopen. Issue observed on a third device, with extra logging enabled as requested by @jhughesoti above. This is on version 2.2.

report (60).zip