FCS_TLSC_EXT.1:
The evaluator shall check the description of the implementation of this
protocol in the
TSS to
ensure that the cipher suites supported are specified. The evaluator shall check the
TSS to ensure that the
cipher suites specified include those listed for this component.
Guidance
The evaluator shall
also check the operational guidance to ensure that it contains instructions on
configuring the product so that
TLS conforms to the description in the
TSS.
Tests
The evaluator shall also perform the following tests:
- Test 1:
The evaluator shall establish a TLS connection
using each of the cipher suites specified by the
requirement. This connection may be established as part of the establishment of a
higher-level protocol, e.g., as part of an EAP session. It is sufficient to
observe the successful negotiation of a cipher suite to satisfy the intent of the
test; it is not necessary to examine the characteristics of the encrypted traffic
in an attempt to discern the cipher suite being used (for example, that the
cryptographic algorithm is 128-bit AES and not 256-bit AES).
- Test 2:
The goal of the following test is to verify that the TOE accepts only certificates
with appropriate values in the extendedKeyUsage extension, and implicitly that the
TOE correctly parses the extendedKeyUsage extension as part of X.509v3 server
certificate validation.
The evaluator shall attempt to establish the connection using a server with a
server certificate that contains the Server Authentication purpose in the
extendedKeyUsage extension and verify that a connection is established. The
evaluator shall repeat this test using a different, but otherwise valid and
trusted, certificate that lacks the Server Authentication purpose in the
extendedKeyUsage extension and ensure that a connection is not established.
Ideally, the two certificates should be similar in structure, the types of
identifiers used, and the chain of trust.
- Test 3:
The evaluator shall send a server certificate in the TLS connection
that does not match the server-selected cipher suite (for example, send a ECDSA certificate while using the
TLS_RSA_WITH_AES_128_CBC_SHA cipher suite or send a RSA certificate while using one
of the ECDSA cipher suites.) The evaluator shall verify that the product disconnects after
receiving the server’s Certificate handshake message.
- Test 4:
The evaluator shall configure the server to select the
TLS_NULL_WITH_NULL_NULL cipher suite and verify that the client denies the
connection.
- Test 5:
The evaluator shall perform the following modifications to the traffic:
- Test 5.1:
Change the TLS version
selected by the server in the Server Hello to an undefined TLS version (for example 1.5
represented by the two bytes 03 06) and verify that the client rejects the
connection.
- Test 5.2:
Change the TLS version
selected by the server in the Server Hello to the most recent unsupported TLS version (for example 1.1
represented by the two bytes 03 02) and verify that the client rejects the
connection.
- Test 5.3:
[conditional] If DHE or ECDHE cipher suites are supported, modify at least one byte in the
server’s nonce in the Server Hello handshake message, and verify that the client does not complete
the handshake and no application data flows.
- Test 5.4:
Modify the server’s selected cipher suite in the Server Hello handshake
message to be a cipher suite not presented in the Client Hello handshake
message. The evaluator shall verify that the client does not complete the handshake
and no application data flows.
- Test 5.5:
[conditional] If DHE or ECDHE cipher suites are supported, modify the signature block in the
server’s Key Exchange handshake message, and verify that the client does not complete the handshake
and no application data flows. This test does not apply to cipher suites using RSA key exchange.
If a TOE only supports RSA key exchange in conjunction with TLS, then this test shall be omitted.
- Test 5.6:
Modify a byte in the Server Finished handshake message, and verify that the
client does not complete the handshake and no application data flows.
- Test 5.7:
Send a message consisting of random bytes from the server after the server has issued the
Change Cipher Spec message and verify that the client does not complete the handshake
and no application data flows. The message must still have a valid 5-byte record
header in order to ensure the message will be parsed as TLS.
The evaluator shall ensure that the
TSS describes the client’s method of establishing all reference
identifiers from the application-configured reference identifier, including which
types of reference identifiers are supported (e.g. Common Name,
DNS Name,
URI Name,
Service Name, or other application-specific Subject Alternative Names) and whether
IP
addresses and wildcards are supported. The evaluator shall ensure that this
description identifies whether and the manner in which certificate pinning is
supported or used by the product.
Guidance
The evaluator shall verify that the AGD guidance includes instructions for
setting the reference identifier to be used for the purposes of certificate validation
in
TLS.
Tests
The evaluator shall
configure the reference identifier according to the AGD guidance and perform the
following tests during a
TLS connection:
- Test 1:
The evaluator shall present a server certificate that contains
a CN that does not match the reference identifier and does not
contain the SAN extension. The evaluator shall verify that the
connection fails.
Note that some systems might require the presence of the SAN extension.
In this case the connection would still fail but for the
reason of the missing SAN extension instead of the mismatch of
CN and reference identifier. Both reasons are acceptable to
pass Test 1.
- Test 2:
The evaluator shall present a server certificate that contains a CN that
matches the reference identifier, contains the SAN extension, but does not contain
an identifier in the SAN that matches the reference identifier. The evaluator
shall verify that the connection fails. The evaluator shall repeat this test for
each supported SAN type.
- Test 3:
[conditional] If the TOE does not mandate the presence of the SAN extension,
the evaluator shall present a server certificate that contains
a CN that matches the reference identifier and does not
contain the SAN extension. The evaluator shall verify that the
connection succeeds. If the TOE does mandate the presence of
the SAN extension, this Test shall be omitted.
- Test 4:
The evaluator shall present a server certificate that contains a CN that does
not match the reference identifier but does contain an identifier in the SAN that
matches. The evaluator shall verify that the connection succeeds.
- Test 5:
The evaluator shall perform the following wildcard tests with each supported type of reference
identifier. The support for wildcards is intended to be optional. If wildcards are supported, the
first, second, and third tests below shall be executed. If wildcards are not supported, then the
fourth test below shall be executed.
- Test 5.1:
[conditional]: If wildcards are supported, the evaluator shall present a server certificate
containing a wildcard that is not in the left-most label of the presented identifier (e.g.
foo.*.example.com) and verify that the connection fails.
- Test 5.2:
[conditional]: If wildcards are supported, the evaluator shall present a server certificate
containing a wildcard in the left-most label but not preceding the public
suffix (e.g. *.example.com). The evaluator shall configure
the reference identifier with a single left-most label (e.g. foo.example.com) and verify that the
connection succeeds. The evaluator shall configure the reference identifier without a left-most
label as in the certificate (e.g. example.com) and verify that the connection fails. The evaluator
shall configure the reference identifier with two left-most labels (e.g. bar.foo.example.come) and
verify that the connection fails.
- Test 5.3:
[conditional]: If wildcards are supported, the evaluator shall present a server certificate
containing a wildcard in the left-most label immediately preceding the public suffix (e.g. *.com).
The evaluator shall configure the reference identifier with a single left-most label (e.g.
foo.com) and verify that the connection fails. The evaluator shall configure the reference
identifier with two left-most labels (e.g. bar.foo.com) and verify that the connection fails.
- Test 5.4:
[conditional]: If wildcards are not supported, the evaluator shall present a server certificate
containing a wildcard in the left-most label (e.g. *.example.com). The evaluator shall configure
the reference identifier with a single left-most label (e.g. foo.example.com) and verify that the
connection fails.
- Test 6:
[conditional] If URI or Service name reference identifiers are supported, the
evaluator shall configure the DNS name and
the service identifier. The evaluator shall present a server certificate
containing the correct DNS name and
service identifier in the URIName or SRVName fields of the SAN and verify that the
connection succeeds. The evaluator shall repeat this test with the wrong service
identifier (but correct DNS name) and
verify that the connection fails.
- Test 7:
[conditional] If pinned certificates are supported the evaluator shall
present a certificate that does not match the pinned certificate and verify that
the connection fails.
If the selection for authorizing override of invalid certificates is made, then
the evaluator shall ensure that the
TSS includes a description of how and when user or administrator
authorization is obtained. The evaluator shall also ensure that the
TSS describes
any mechanism for storing such authorizations, such that future presentation
of such otherwise-invalid certificates permits establishment of a trusted channel
without user or administrator action.
Tests
The evaluator shall demonstrate that using an invalid certificate (unless excepted)
results in the function failing as follows, unless excepted:
- Test 1: The evaluator shall demonstrate that a server using a certificate without a
valid certification path results in an authentication failure. Using the
administrative guidance, the evaluator shall then load the trusted CA
certificate(s) needed to validate the server's certificate, and demonstrate that the
connection succeeds. The evaluator then shall delete one of the CA certificates,
and show that the connection fails.
- Test 2: The evaluator shall demonstrate that a server using a certificate which has
been revoked results in an authentication failure.
- Test 3: The evaluator shall demonstrate that a server using a certificate which has
passed its expiration date results in an authentication failure.
- Test 4: The evaluator shall demonstrate that a server using a certificate which does
not have a valid identifier results in an authentication failure.