4

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?

halfer
  • 19,824
  • 17
  • 99
  • 186
Shahbaz Shueb
  • 410
  • 4
  • 9
  • I have been using `XMLHTTP` from an imported `MSXML2_TLB.pas` instead of WinHTTP for a while now, as I suspect the MSXML sub-system is getting watched closer by Microsoft than the WinHTTP sub-system is. I wonder if that would provide you with better test results. – Stijn Sanders Jan 31 '18 at 15:19

1 Answers1

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.

logicalscope
  • 183
  • 1
  • 9
  • Thanks for the help but the problem has been resolved. Apparently, the tls-cc-tools checks whether the ssl handshake fails for negative cases but in our case, the ssl handshake was not failing, instead the request was failing after handshake. Apparently, this is how winhttp works. – Shahbaz Shueb Feb 14 '18 at 06:51
  • None of the test cases you mention should permit a successful handshake to occur even if they fail after the fact. If this is what you are seeing then the winhttp library may not pass the Common Criteria test cases. – logicalscope Feb 14 '18 at 12:07
  • We have confirmed this from a CC labs that we are working in collaboration with and they said that this should not be a problem as long as the request is failing and no data is being transferred to or accepted at either side and according to that lab, NIAP has already accepted a product that has this behavior. – Shahbaz Shueb Feb 16 '18 at 06:56