TLSv1: motivo per cui il client non invia il certificato client

Question

TLSv1: motivo per cui il client non invia il certificato client

#1 da (1 voti)

0

La nostra installazione di BizTalk è composta da due nodi di carico bilanciati B1 ( 10.137.10.1 ) e B2 ( 10.137.10.2 ) che elaborano e instradano i messaggi SOAP in entrata.

L'elaborazione non è altro che:

invio del messaggio di richiesta SOAP a un servizio Web esterno ( WS ) (fuori dal nostro controllo),
attendi la risposta
e indirizza la risposta al chiamante originale.

Di fronte al servizio web c'è un reverse proxy nginx ( RP , WS / RP: 145.21.186.179 ).

La connessione tra i nodi BizTalk (B1, B2) e WS (o in realtà RP) sarà HTTPS (TLSv1) con autenticazione reciproca / bidirezionale.

B1 funziona

Tutto va bene quando i messaggi vengono instradati dal nodo B1. Viene eseguito un handshake TLSv1 appropriato e infine i dati dell'applicazione (il messaggio di richiesta e di risposta) vengono scambiati. Vedi la schermata qui sotto.

Wire squalo sul nodo B1. (tutto va bene)

Il certificato di richieste RP al pacchetto 63. (Al segno di 459 secondi.)
B1 risponde al pacchetto 69. (Anche al segno di 459 secondi.)

B2tace

ImessaggielaboratidalnodoB2falliscono.Nonvediamoun'appropriatastrettadimanoTLSv1.Dopocheilserverrichiedeilcertificatodalclient,diventasilenzioso.

WiresqualosulnodoB2.(ilclientdiventasilenziosodopolarichiestadelcertificatodelserver)

IlcertificatodirichiesteRPalpacchetto27.(Alsegnodi96secondi.)
B2nonrisponde.
TimeoutRP(?)echiudelaconnessionealpaket31.(Alsecondosecondo.)

Domanda

Potresteragazzieragazzepensareadunaragionepercuiquestopotrebbeaccadere?AbbiamocontrollatolaconfigurazionesiasuB1chesuB2enonvediamoledeviazioni.

AnchetestarelaconnessioneconOpenSSLdalnodoB2funzionaperfettamente.Comandoeraquesto:

openssl.exes_client-connectRPHOSTNAMEHERE:443-state-tls1-debug-certclient_ssl.pem-keyclient_ssl.pem

QuestopotrebbeessereunproblemaconSChannel?Qualesarebbeunmotivopernoninviareilcertificatoclientsurichiestadelserver?

Ancheilogdeglieventinoncidannoalcunvantaggio.

Aggiornamenton.1checondividelaritrasmissionespuriadalloscreenshotB2

authentication openssl tls certificates

posta Martijn B 14.06.2016 - 16:07

fonte

1 risposta

Leggi altre domande sui tag authentication openssl tls certificates

Poche domande su aircrack-ng Download di un nuovo certificato pinned SSL non sicuro?

score 1 · Accepted Answer

Dalla traccia di Wireshark su B2, vediamo che il cliente semplicemente non risponde affatto; dopo un minuto, il server diventa impaziente e chiude la connessione.

Questo probabilmente non è un problema di disponibilità del certificato su B2: se SChannel ritenesse semplicemente di non avere un certificato appropriato, restituirebbe un messaggio di handshake Certificate vuoto. A quel punto, B2 sa perfettamente che è il suo turno di parlare, quindi se non lo fa, allora significa che è occupato altrove.

Potrebbe verificarsi una delle seguenti condizioni:

Ci sono diversi certificati corrispondenti su B2, e il software su B2 crede di essere "interattivo"; visualizza quindi un popup di selezione del certificato e attende che l'utente scelga il certificato. Ho visto casi in cui il software in esecuzione come account di servizio "mostra" un popup su un desktop nascosto (non quello dell'utente attualmente connesso).
La chiave privata è protetta dall'accesso. È possibile abilitare il controllo dell'accesso basato su password su chiavi private in CryptoAPI di Windows (in pratica, la chiave privata viene archiviata con crittografia basata su password). In tal caso, qualsiasi accesso attiverà un popup che richiede l'inserimento della password. Per i sistemi non interattivi, questo non andrà bene ... (vedi sopra). Nota che la chiave privata è necessaria per il messaggio CertificateVerify dal client, dopo i messaggi Certificate e ClientKeyExchange , ma poiché questi tre messaggi sono tutti "handshake", SChannel li raggrupperà in un singolo record, quindi in In questa situazione sarebbe normale non vedere i messaggi Certificate e ClientKeyExchange .
Il client è impegnato a convalidare il certificato del server. Tale convalida può comportare la comunicazione con molti altri sistemi, per raccogliere ulteriori CA intermedie e ottenere risposte CRL o OCSP. Queste sono richieste in uscita , quindi l'installazione di rete potrebbe bloccarle. Prova a creare una traccia Wireshark che includa tutto il traffico, non solo la specifica connessione TCP / SSL; in particolare, le richieste DNS che non hanno risposta dovrebbero essere esaminate.

Un test rapido sarebbe provare a connettersi da B2 al server WS di destinazione con Internet Explorer. IE utilizzerà SChannel (contrariamente a openssl.exe). Esegui IE con un account che ha accesso al certificato e alla chiave del client previsti. Questo ti mostrerà qualsiasi funzione "interattiva".