[NIT Request] - FCS_TLSC_EXT.1.1 test 4 (iii)

[mclearn]

Requesting Organization: Lightship Security

Status: [ ] On-going certification [*] Preparatory/Other

Certification Deadline Dates: N/A

SFR or Section of cPP/SD in question: FCS_TLSC_EXT.1.1 test 4 (iii)

Supporting Document testing in question: FCS_TLSC_EXT.1.1 test 4 (iii)

Issue: This test case can have two different behaviours depending on whether the client is TLS 1.3 aware or not. When a client is TLS 1.3 aware, it will send a supported_versions extension in its Client Hello. When a TLS 1.3 capable server receives this Client Hello, it will detect the use of the supported_versions extension and make decisions on it.

The problem occurs when you have a TLS 1.3 aware server (such as OpenSSL 3.x) which is configured to only listen for SSLv3 as in FCS_TLSC_EXT.1.1 test 4 (iii). When a TLS 1.3 capable client sends their Client Hello, the supported_versions extension is contained in the Client Hello. RFC 8446, section 4.2.1 says that this extension must be processed if it exists. OpenSSL 3.x will always process this extension if it exists, regardless of what protocol versions are enabled.

The OpenSSL 3.x behaviour can be verified using the following: In one process: openssl s_server -cert cert.pem -key key.pem -port 443 -tls1 In another process: openssl s_client -connect localhost:443 -min_protocol TLSv1.2 -max_protocol TLSv1.3

Wireshark will show that the server process will drop the connection with a "Protocol Version" error rather than responding with a Server Hello downgrade.

Proposed Resolution: There are two options: 1) Require the test server to be TLS 1.3/RFC 8446 unaware for the purposes of this test; or 2) Permit the test server to drop connections if it is TLS 1.3 aware and the test client is TLS 1.3 aware.

For option 1 (I personally do not like this option): The evaluator shall attempt to establish a TLS connection using each of the supported TLS/SSL versions (i.e. TLS 1.3, TLS 1.2, TLS 1.1, TLS 1.0, SSL 3.0, SSL 2.0). The evaluator shall verify that the versions specified in FCS_TLSC_EXT.1.1 are successfully established and all other versions are rejected by the TOE TLS client. _When configuring a test server, ensure that test server is RFC 8446 unaware when configuring for TLS 1.2 and below such that any supported_versions extension is not processed_. The evaluator must ensure the ServerHello is valid for the TLS version being negotiated. If the TOE includes the Supported Versions extension in its ClientHello, the evaluator shall also ensure the version(s) specified in the extension match the version(s) in FCS_TLSC_EXT.1.1.

For option 2 (I prefer this option): The evaluator shall attempt to establish a TLS connection using each of the supported TLS/SSL versions (i.e. TLS 1.3, TLS 1.2, TLS 1.1, TLS 1.0, SSL 3.0, SSL 2.0). The evaluator shall verify that the versions specified in FCS_TLSC_EXT.1.1 are successfully established and all other versions are not successfully negotiated by the TOE TLS client. _If a supported_versions extension is not sent by the TOE in the ClientHello, then the_ evaluator must ensure the test server responds with a ServerHello that is valid for the TLS version being negotiated. If the TOE includes the Supported Versions extension in its ClientHello, the evaluator shall also ensure the version(s) specified in the extension match the version(s) in FCS_TLSC_EXT.1.1. NOTE: For TLS 1.3 aware test servers, it is appropriate for the test server to issue a TLS Alert. The TOE client must not attempt to continue the connection.

Rationale: RFC 8446 section 4.2.1 requires processing the supported_versions extension at all times when presented which creates an ambiguity in expectations as to how the test server is to respond.

[awnissen]

""" The OpenSSL 3.x behaviour can be verified using the following: In one process: openssl s_server -cert cert.pem -key key.pem -port 443 -tls1 In another process: openssl s_client -connect localhost:443 -min_protocol TLSv1.2 -max_protocol TLSv1.3

Wireshark will show that the server process will drop the connection with a "Protocol Version" error rather than responding with a Server Hello downgrade. """

I'd have to look at the packets, but isn't this the appropriate behavior. Server supports TLS 1.0; the client is only supporting TLS 1.3 & TLS 1.2. There's not a common version that can be negotiated.

""" If this extension is present in the ClientHello, servers MUST NOT use the ClientHello.legacy_version value for version negotiation and MUST use only the "supported_versions" extension to determine client preferences. """ (RFC 8446 section 4.2.1)

Is there more background?

[mclearn]

The test case has the following wording: "...and all other versions are rejected by the TOE TLS client. The evaluator must ensure the ServerHello is valid for the TLS version being negotiated." and there is no Server Hello response in this case and the test tool rejects the connection rather than the TOE client. What it comes down to is being "TLS 1.3 aware" which is not the same as "TLS 1.3 capable". The server is not capable of negotiating TLS 1.3 because it has been restricted from doing so. However, our test server is still TLS 1.3 aware because it is processing the supported_versions extension and reacting to it.

In the example I provided the OpenSSL server will NOT return a Server Hello response. It will simply send an Alert and tear down the connection. This is absolutely in keeping with RFC 8443, but not in keeping with the test case.

You can see the behaviour more clearly with the following: 1) TOE client capable only of TLS 1.2 with server which is TLS 1.3 aware, but protocols are restricted: server: openssl s_server -port 4343 -cert cert.pem -key key.pem -tls1 client: openssl s_client -connect localhost:4343 -min_protocol TLSv1.2 -max_protocol TLSv1.2

Server will send back Server Hello with the downgrade offering which TOE client rejects using an Alert (therefore TOE is actively rejecting).

2) TOE client capable of TLS 1.2 and 1.3, with server which is TLS 1.3 aware, but protocols are restricted: server: openssl s_server -port 4343 -cert cert.pem -key key.pem -tls1 client: openssl s_client -connect localhost:4343 -min_protocol TLSv1.2 -max_protocol TLSv1.3

Server (test tool) will send back Alert and initiates teardown (TOE client has no say in the matter).

NOTE: I made an edit to the original request since the TOE client isn't actually involved rejecting the connection for TLS 1.3 aware servers.

[jhallf5]

Running this same test case with OpenSSL v3.0.2 results in the server not sending a ServerHello and just closing the connection with fatal:protocol_version alert 70.

`hall@pier:~$ openssl s_client -debug -msg -state -connect localhost:44443 -min_protocol TLSv1.2 -max_protocol TLSv1.2 CONNECTED(00000003) SSL_connect:before SSL initialization

TLS 1.0, RecordHeader [length 0005] 16 03 01 00 b7 TLS 1.2, Handshake [length 00b7], ClientHello 01 00 00 b3 03 03 a6 49 94 61 3c b0 57 08 f2 a3 75 1c 25 54 28 d7 c9 85 4d 46 6e ec d7 09 12 00 5a d5 51 f8 84 a0 00 00 38 c0 2c c0 30 00 9f cc a9 cc a8 cc aa c0 2b c0 2f 00 9e c0 24 c0 28 00 6b c0 23 c0 27 00 67 c0 0a c0 14 00 39 c0 09 c0 13 00 33 00 9d 00 9c 00 3d 00 3c 00 35 00 2f 00 ff 01 00 00 52 00 0b 00 04 03 00 01 02 00 0a 00 0c 00 0a 00 1d 00 17 00 1e 00 19 00 18 00 23 00 00 00 16 00 00 00 17 00 00 00 0d 00 2a 00 28 04 03 05 03 06 03 08 07 08 08 08 09 08 0a 08 0b 08 04 08 05 08 06 04 01 05 01 06 01 03 03 03 01 03 02 04 02 05 02 06 02 write to 0x55f69301a0b0 [0x55f69302b2d0] (188 bytes => 188 (0xBC)) 0000 - 16 03 01 00 b7 01 00 00-b3 03 03 a6 49 94 61 3c ............I.a< 0010 - b0 57 08 f2 a3 75 1c 25-54 28 d7 c9 85 4d 46 6e .W...u.%T(...MFn 0020 - ec d7 09 12 00 5a d5 51-f8 84 a0 00 00 38 c0 2c .....Z.Q.....8., 0030 - c0 30 00 9f cc a9 cc a8-cc aa c0 2b c0 2f 00 9e .0.........+./.. 0040 - c0 24 c0 28 00 6b c0 23-c0 27 00 67 c0 0a c0 14 .$.(.k.#.'.g.... 0050 - 00 39 c0 09 c0 13 00 33-00 9d 00 9c 00 3d 00 3c .9.....3.....=.< 0060 - 00 35 00 2f 00 ff 01 00-00 52 00 0b 00 04 03 00 .5./.....R...... 0070 - 01 02 00 0a 00 0c 00 0a-00 1d 00 17 00 1e 00 19 ................ 0080 - 00 18 00 23 00 00 00 16-00 00 00 17 00 00 00 0d ...#............ 0090 - 00 2a 00 28 04 03 05 03-06 03 08 07 08 08 08 09 .*.(............ 00a0 - 08 0a 08 0b 08 04 08 05-08 06 04 01 05 01 06 01 ................ 00b0 - 03 03 03 01 03 02 04 02-05 02 06 02 ............ SSL_connect:SSLv3/TLS write client hello read from 0x55f69301a0b0 [0x55f6930220b3] (5 bytes => 5 (0x5)) 0000 - 15 03 03 00 02 ..... <<< TLS 1.2, RecordHeader [length 0005] 15 03 03 00 02 read from 0x55f69301a0b0 [0x55f6930220b8] (2 bytes => 2 (0x2)) 0000 - 02 46 .F <<< TLS 1.2, Alert [length 0002], fatal protocol_version 02 46 SSL3 alert read:fatal:protocol version SSL_connect:error in error 807B983E8B7F0000:error:0A00042E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:../ssl/record/rec_layer_s3.c:1584:SSL alert number 70 `

I think we will need to write the test to tell the evaluator to be aware of these inconsistencies. Unfortunately, getting consistent behavior from the server in this scenario may require a custom server.

[kr15tyk]

@mclearn , @awnissen , @jhallf5 Do you have any recommended wording after the last comment?

[mclearn]

My option 1 above considers using a custom test server. I prefer option 2 which doesn't need a custom server. It comes down to whether we are trying to consider RFC conformance to an older RFC (5246 - TLS 1.2) or a newer RFC (8446 - TLS 1.3) and whether such conformance constitutes a security concern or not.

[kr15tyk]

@jhallf5 with Greg's explanation above, are you okay with going with option 2?

[KSinitski]

While I support Option 2, I see Option 1 to be more likely to produce consistent testing. Please consider expanding Option 2 by introducing a note with additional explanation.

[kr15tyk]

@KSinitski Thank you for the feedback. Would you be willing to provide the additional explanation for option 2?

[jhallf5]

I support option 2 also.

[KSinitski]

How about the following:

Note: Depending on whether the server is TLS 1.3 aware or not, it may respond differently to attempts to protocol downgrade. To ensure the test results are repeatable, please document relevant server configuration details.

[plughy2]

The NIAP FP for TLS and the draft package I proposed this week both have similar wording in its test requirement for TLS Client: For each of SSL version 2, SSL version 3, TLS version 1.0, TLS version 1.1, and [conditional] TLS version 1.2, the evaluator shall initiate a connection from the TOE to a test TLS server that is configured to negotiate the obsolete version and observe that the TSF terminates the connection.

That said, I have not run into this specific issue myself. I'm using the TLS 'layer' within Scapy that I've modified for this and most of the other TLS testing requirements - https://github.com/secdev/scapy. Scapy supports SSL and TLS versions 1.0 through TLS 1.3. When the Scapy TLS server is configured for TLS 1.0 and a test client is configured to support TLS 1.2 and TLS 1.3, the tool won't abort the handshake but will send a server hello message to the Client.

Client Hello Supported Version Extension:

Server Hello:

I do believe though that the test should be 'tool independent' and would support option 2.

[kr15tyk]

The TLSWG will revisit this issue once all NIAP TLS comments for NDcPPv3.0 have been addressed.