help for odtt ADVANCED_SECURITY-3-3-1-v23.06 TLS client authentication – self-signed TLS server certificate with on-device RSA key pair

[kaoriakana]

Security Configuration/TLS server/TLS Client Authentication in Onvif device test toll version 23.12 .

In “ADVANCED_SECURITY-3-3-1-v23.06 TLS client authentication – self-signed TLS server certificate with on-device RSA key pair”, I get an error.

Let me describe the error with some contents.

1. This is step detail snapshot and let’s focus on step 39 and step 42.

After some TLS settings, odtt sent “Get_Services” and got the reply from the DUT(step 39). From the step 40, 41 and 44, it seems that reply content is good by odtt’s checking. The fatal wound is step 39 with the reason of an unexpected packet format.

1. I captured the packets and only show the packets of step 39.

(Odtt was installed in PC with ip 192.168.0.241 and DUT’s ip is 192.168.0.225 .)

But some packets were just shown application data and encrypted the key content. I try to decrypt them and I can get more information.

We focus on packet number 1234, 1350 and 1352 and compare the 2 packet pictures.

Find something interesting….

Packet number 1234 is onvif GetService from ODTT.

Packet number 1350 is DUT’s GetService reply.

Packet number 1352 is TLS Alert.

The detail content of packet 1352 is following

In RFC 5246 7.2.1

7.2.1. Closure Alerts

The client and the server must share knowledge that the connection is ending in order to avoid a truncation attack. Either party may initiate the exchange of closing messages.

close_notify

This message notifies the recipient that the sender will not send any more messages on this connection. The session becomes unresumable if any connection is terminated without proper close_notify messages with level equal to warning.

The close_notify signal is TLS layer connection close, isn’t it?

I am not sure the close_notify or another reason caused step 42 error ?

If there are other reasons , could you kindly give me more clues?

Please give me some information for the test and how to pass step 42.

If need more information, for example TLS server settings or Certificates or private key, I will add them.

[madhurao68]

Our test tool vendor is investigating, and we shall respond as soon as we get a response. Thanks for your patience!

[madhurao68]

Hi,

Please find the response below:

At step 39 ONVIF DTT supposed to invoke GetServices using https connection. And it is expected that Device will return https addresses with proper port at the response. According provided screenshots Device returns http addresses, so ONVIF DTT will try to connect to wrong port.

Valid addresses:

The device addresses:

Unfortunately, we could not say for sure since there is lack of information, but most probably seems to be the case. If not, then
the following logs will be helpful for investigation:

[kaoriakana]

Hi!

Thank you to drop me the workable hint, but another problem is derived.
In my case, the web server will work on http and https at the same time.
There are some tls and non-tls clients in my real environment.
"onvif GetService" may reply https://192.168.0.225/onvif/device_service for tls clients at this time,
but may need to reply http://192.168.0.225/onvif/device_service for non-tls clients at next time.

My questions are
1.how to distinguish the requests between the tls and non-tls of GetService from soap level.
I have already checked the tls and nontls request of GetService.
I try to print out the ssl information and get almost the same result.
Please check them.

ssl information in soap layer of tls GetService request
fsslauth = 0x6c7c9 <ssl_auth_init>,
fsslverify = 0x0, bio = 0x0, ssl = 0x0, ctx = 0x0, session = 0x0, dhfile = 0x0, randfile = 0x0, ssl_flags = 1, keyfile = 0x0, keyid = 0x0, password = 0x0, cafile = 0x0, capath = 0x0, crlfile = 0x0,
session_host = '\000' <repeats 1023 times>, session_port = 443, bufidx = 347, buflen = 347, ahead = 0, cdata = 0, body = 1, level = 0, start = 1709172705, count = 347, length = 0,
labbuf = 0x5552f0 "http://www.onvif.org/ver10/device/wsdl", lablen = 256, labidx = 0,

ssl information in soap layer of non-tls GetService request
fsslauth = 0x6c7c9 <ssl_auth_init>,
fsslverify = 0x0, bio = 0x0, ssl = 0x0, ctx = 0x0, session = 0x0, dhfile = 0x0, randfile = 0x0, ssl_flags = 1, keyfile = 0x0, keyid = 0x0, password = 0x0, cafile = 0x0, capath = 0x0, crlfile = 0x0,
session_host = '\000' <repeats 1023 times>, session_port = 443, bufidx = 347, buflen = 347, ahead = 0, cdata = 0, body = 1, level = 0, start = 1709173424, count = 347, length = 0,
labbuf = 0x5552f0 "http://www.onvif.org/ver10/device/wsdl", lablen = 256, labidx = 0,

I can not find the differences or I lose something useful I didn't find.

2. If my web server works on http/https at the same time,
   is it possible to reply
   "https://192.168.0.225/onvif/device_service"
   "http://192.168.0.225/onvif/device_service"
   the 2 items at the same response.
   If it is allowed, what the format I have to follow ?

Sincerely
Akana

[kaoriakana]

Hi!
I get another problem in the test.
In ADVANCED_SECURITY-3-3-1-v23.06 TLS client authentication – self-signed TLS server certificate with on-device RSA key pair,
the test will be sometimes passed but sometimes fail.
I am not sure what the reason is , but I snap some pictures and save the test log.
Could you kindly help me this problem and previous one?

Sincerely
Akana

But just click again the test right away and may get the failed result.

Please focus on the 2 pictures from step 36.
They are different since here.

The attached test log files are from "save / save current".
tmp.zip

[kaoriakana]

After I compared the 2 test logs, I found the difference is in STEP 17 - Get Client Authentication Required.
If the reply is false, step 36 will set client authentication required as true.
If the reply is already true, it will not set again.

But the key reason may be still the GetServices like my previous question
"how to distinguish the requests between the tls and non-tls of GetService from soap level.".

Please kindly give me a hint.

BR
Akana

[madhurao68]

Hello!

We reproduced exact scenario on our side, and it looks like camera issue.

At step 52 of failed scenario, there is GetServices request to HTTP entry point (not HTTPS), but device returns HTTPS service endpoints. As a result, at step 55 Device Test Tool invokes plain HTTP request to HTTPS endpoint.