WinHTTP: impedisce l'handshake con successo se il certificato peer non è valido

Question

WinHTTP: impedisce l'handshake con successo se il certificato peer non è valido

#1 da (2 voti)

2

Sto usando WinHTTP su un progetto Delphi per effettuare chiamate al server.

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;

Domanda; Per la conformità alla sicurezza (FIA_X509_EXT1.1) , la connessione dovrebbe terminare subito dopo l'handshake SSL? Nel caso in cui il peer certificate sia ritenuto non valido. O va bene terminare in seguito?

Effettivo: Quello che sta accadendo è che il client (usando WinHTTP) effettua una chiamata e conferma con successo l'handshake TLS, anche quando il certificato non è valido. Tuttavia, subito dopo la stretta di mano e prima di completare la richiesta, termina la connessione generando un '12175' errore. Qual è l'errore per i certificati non validi? Quale è giusto?

Problema: Per quanto sopra (FIA_X509_EXT1.1) conformità per passare come strumento di verifica, WinHTTP non deve consentire l'handshake riuscito, e quindi terminare la connessione in precedenza.

Schermata di Wireshark allegata di seguito: (10.0.0.221 è il server)

Hogiàfattoquestadomandain scambio stack , ma come suggerito da un altro membro, questo è probabilmente il posto giusto.

tls x.509 common-criteria

posta Muhammad Uzair Khan 08.02.2018 - 05:00

fonte

1 risposta

Leggi altre domande sui tag tls x.509 common-criteria

Soluzione di rete wireless? Problemi di filtro WPA2 / MAC Compatibilità hardware con Hashcat in Windows 10 (64-bit)

score 2 · Accepted Answer

Question; For security compliance (FIA_X509_EXT1.1), should connection terminate right after SSL handshake? Incase peer certificate is deemed invalid. Or is this ok to terminate later?

TL; DR: Non credo che fallire nell'handshake TLS sia un requisito reale. Ma sarà molto più difficile dimostrare un comportamento sicuro se non fallisce già nell'handshake TLS.

Non riesco a vedere nulla in FIA_X509_EXT1.1 e correlati che richiedano esplicitamente che il client abbia già esito negativo nell'handshake TLS. E dal punto di vista della sicurezza non dovrebbe importare se la connessione TLS fallisce nell'handshake o dopo l'handshake se non vengono inviati dati dell'applicazione dal client sulla connessione non affidabile o i dati del server vengono elaborati . Ciò significa che fino a quando il certificato del server non è completamente convalidato:

Il client non deve inviare dati di applicazioni al server.
Il client non deve elaborare i dati delle applicazioni inviati dal server.

Se il client non supera l'handshake TLS già in caso di certificato errato, è facile da mostrare perché i dati dell'applicazione possono essere inviati ed elaborati solo dopo aver completato con successo l'handshake TLS. Tuttavia, se si consente di fallire la connessione TLS solo dopo l'handshake TLS, è necessario esaminare più da vicino il comportamento dell'applicazione specifica e anche i protocolli di livello superiore.

Esistono protocolli come FTPS, SMTPS ... dove il server invia i dati prima del client. In questi casi si potrebbero effettivamente vedere i dati dell'applicazione dal server nell'acquisizione dei pacchetti anche con certificati errati poiché l'handshake TLS è stato completato correttamente dal punto di vista del server. Pertanto, è necessario mostrare in qualche modo che il client non ha elaborato questi dati (non attendibili) che probabilmente implicherebbero un approfondimento nei client e / o nel codice sorgente degli stack TLS.

In altri protocolli come HTTP il client invia prima i dati. In questi casi, i dati dell'applicazione non dovrebbero essere visti nell'acquisizione del pacchetto se la convalida del certificato dovesse fallire. Ma, probabilmente, sarebbe ancora necessario analizzare il caso in cui un server non è conforme al protocollo e invia i dati al client. Qui è anche necessario dimostrare in qualche modo che il client non elabora questi dati non attendibili dal server.

In sintesi: non penso che sia un requisito reale che la connessione TLS debba fallire già all'interno dell'handshake se il certificato non può essere convalidato. Tuttavia, se la connessione TLS fallisce solo dopo il completamento dell'handshake TLS, sarà molto più difficile verificare che i dati non sensibili siano stati inviati tramite la connessione non sicura e che nessun client non sia stato elaborato dal client.