WinHTTP - Impedir un intercambio exitoso si el certificado de igual no es válido

Question

WinHTTP - Impedir un intercambio exitoso si el certificado de igual no es válido

#1 de Steffen Ullrich (2 votos)

2

Estoy usando WinHTTP en un proyecto de Delphi para realizar llamadas al servidor.

Script:

userAgent := 'TestClient.exe';
  hsession := WinHttpOpen(pwidechar(userAgent), WINHTTP_ACCESS_TYPE_DEFAULT_PROXY, nil, nil, 0);
  if(hsession = nil) then ShowMessage('Failed WinhttpOpen');
  p := 'https';
  port := 443;
  requestflags := WINHTTP_FLAG_SECURE;
  server := '10.0.0.221';

  hconnection := WinHttpConnect(hsession, PWideChar(server), port, 0);
  if(hconnection = nil) then
  begin
    le := GetLastError;
    ShowMessage('Failed to connect: ' + IntToStr(le));
  end;

  Action := 'GET';
  hInetRequest := WinHttpOpenRequest(hconnection, pwidechar(Action), nil, nil, nil, nil, WINHTTP_FLAG_SECURE);
  if(hInetRequest = nil) then
  begin
    le := GetLastError;
    ShowMessage('Failed to connect: ' + IntToStr(le));
  end;

  WinResult:=WinHttpSendRequest(hInetRequest, nil,0, 0, 0,0,0);

  if(not WinResult) then
  begin
    le := GetLastError;
    WinHttpCloseHandle(hInetRequest);
    ShowMessage('No result obtained : ' + IntToStr(le));
  end;

Pregunta; Para el cumplimiento de la seguridad (FIA_X509_EXT1.1) , ¿debería terminar la conexión justo después del protocolo de enlace SSL? En caso de que el certificado de pares se considere inválido. ¿O está bien para terminar más tarde?

Actual: Lo que está sucediendo es que el cliente (mediante WinHTTP) realiza una llamada y confirma con éxito el protocolo de enlace TLS, incluso cuando el certificado no es válido. Sin embargo, justo después del protocolo de enlace y antes de completar la solicitud, finaliza la conexión lanzando un '12175' error. ¿Cuál es el error para certificados inválidos? ¿Cuál es el correcto?

Problema: Para que el cumplimiento anterior (FIA_X509_EXT1.1) se apruebe según la herramienta de verificación, WinHTTP no debe permitir un intercambio exitoso y, por lo tanto, terminar la conexión antes.

Pantalla de Wireshark adjunta a continuación: (10.0.0.221 es el servidor)

Yahiceestapreguntaen intercambio de pila , pero como sugiere otro miembro, este es probablemente el lugar correcto.

tls x.509 common-criteria

pregunta Muhammad Uzair Khan 08.02.2018 - 06:00

fuente

1 respuesta

Lea otras preguntas en las etiquetas tls x.509 common-criteria

conjuntos de cifrado TLS / SSL ¿Solución de red inalámbrica? Problemas de filtrado WPA2 / MAC

score 2 · Accepted Answer

Pregunta; Para el cumplimiento de la seguridad (FIA_X509_EXT1.1), ¿debería la conexión terminar justo después del protocolo de enlace SSL? El certificado de pares en el caso se considera inválido. ¿O está bien para terminar más tarde?

TL; DR: No creo que fallar en el protocolo de enlace de TLS sea un requisito real. Pero será mucho más difícil demostrar un comportamiento seguro si aún no falla en el protocolo de enlace TLS.

No puedo ver nada en FIA_X509_EXT1.1 y relacionado, lo que explícitamente requiere que el cliente ya falle dentro del protocolo de enlace TLS. Y desde una perspectiva de seguridad, no debería importar si la conexión TLS falla dentro del protocolo de enlace o después del protocolo siempre que el cliente no envíe los datos de la aplicación a través de la conexión no confiable o que se procesen los datos del servidor . Esto significa que mientras el certificado del servidor no esté completamente validado:

El cliente no debe enviar ningún dato de la aplicación al servidor.
El cliente no debe procesar ningún dato de aplicación enviado por el servidor.

Si el cliente falla el protocolo de enlace TLS ya en caso de un certificado incorrecto, es fácil de mostrar porque los datos de la aplicación solo pueden enviarse y procesarse después de completar con éxito el protocolo de enlace TLS. Pero, si uno permite fallar la conexión TLS solo después del protocolo de enlace TLS, entonces es necesario tener una mirada más cercana al comportamiento de la aplicación específica y también a los protocolos de la capa superior.

Hay protocolos como FTPS, SMTPS ... donde el servidor envía datos antes que el cliente. En estos casos, uno realmente puede ver los datos de la aplicación del servidor en la captura de paquetes, incluso con certificados incorrectos, ya que el protocolo de enlace TLS se completó con éxito desde la perspectiva del servidor. Por lo tanto, es necesario demostrar de alguna manera que el cliente no procesó estos datos (no confiables) que probablemente implicarían profundizar en el código fuente de las pilas de clientes y / o TLS.

En otros protocolos como HTTP, el cliente envía primero los datos. En estos casos, no se deben ver los datos de la aplicación en la captura de paquetes, en caso de que la validación del certificado falle. Sin embargo, es probable que uno aún necesite analizar el caso en el que un servidor no cumple con el protocolo y envía datos al cliente. Aquí también se debe demostrar de alguna manera que el cliente no procesa estos datos no confiables del servidor.

En resumen: no creo que sea un requisito real que la conexión TLS deba fallar ya dentro del protocolo de enlace si no se puede validar el certificado. Pero, si la conexión TLS solo falla después de completar el protocolo de enlace TLS, será mucho más difícil verificar que los datos no confidenciales se hayan enviado a través de la conexión no confiable y que el cliente no haya procesado los datos no confiables.