In WinHTTP, what settings should be used to pass Common Criteria TLS_EXT1.1 tests - delphi

Question

My team is working on common criteria validation of one of the clients' products written in Delphi for Windows. The application uses winhttp api for making HTTP requests. We are using tls-cc-tools for checking whether the application passes all the TLSC EXT1.1 assurance tests. We have been able to restrict the cipher suites and enable TLS 1.2 application wide and right now test 1, test 4, test 5.1, test 5.2 and 5.3 are passing but the remaining tests are not passing. The tests can be found over here.
We have set the following options in winhttp:
df:={WINHTTP_DISABLE_AUTHENTICATION or }WINHTTP_DISABLE_COOKIES or WINHTTP_DISABLE_KEEP_ALIVE or WINHTTP_DISABLE_REDIRECTS;
WinHTTPSetOption(iconnection, WINHTTP_OPTION_DISABLE_FEATURE,#df,sizeof(df));
protocols := $00000800; //WINHTTP_FLAG_SECURETLS1_2;
WinHttpSetOption(iconnection, WINHTTP_OPTION_SECURE_PROTOCOLS, #protocols, sizeof(protocols));
WinHTTPSetOption(iconnection, WINHTTP_OPTION_SECURITY_FLAGS,
#flags, sizeof(flags));
Tests that are failing:
Test 3: The evaluator shall send a server certificate in the TLS connection that the does not match the server-selected ciphersuite (for example, send a ECDSA certificate while using the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite or send a RSA certificate while using one of the ECDSA ciphersuites.) The evaluator shall verify that the TOE 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 ciphersuite and verify that the client denies the connection.
Test 5.5: Modify a byte in the Server Finished handshake message, and verify that the client sends a fatal alert upon receipt and does not send any application data.
Tests 5.6: Send a garbled message from the Server after the Server has issued the ChangeCipherSpec message and verify that the client denies the connection.
What should be done to ensure that the remaining tests pass?

Answer 1

Preface: I’m a certified Common Criteria Evaluator and a software developer. I’ve been dealing with the TLS and X.509 test cases for years.
Some of these tests are incredibly non-trivial to do correctly under all circumstances, such as FCS_TLSC_EXT.1 Test 3 above. It would be impossible to diagnose why you aren’t seeing the effect without knowing much more about your implementation and (most importantly) test setup.
However, test 4 is quite straightforward: set up your TLS server to respond only with the NULL cipher regardless of what the client asks. That can be done by a man-in-the-middle or by hacking the server. Either should force the client to disconnect well before it gets along much further.
Tests 5.5 and 5.6 are pure man-in-the-middle tests. If you are already using the TLS-cc-tools, then the basis for the test is already there.
Check my profile for ways to reach out to me directly to get more help with CC and TLS and X.509 conformance. These test cases aren’t industry standard implementations and are only for those who are seeking CC certification. It’s a niche market.