TLS Handshake viene abbattuto

9

Sto provando a eseguire il debug di un handshake TLS tra due endpoint del trunk SIP: .75 e .82. È in uso l'autenticazione reciproca.

.75 invia:

  • Client Hello
  • Certificate, Client Key Exchange
  • Certificate Verify, Change Cipher Spec, Encrypted Handshake Message
  • Encrypted Alert

.82 invia:

  • Server Hello, Certificate, Certificate Request, Server Hello Done
  • Change Cipher Spec, Encrypted Handshake Message
  • [FIN, ACK]

Dalla traccia wireshark su .75, i dettagli di Encrypted Alert sono: Content Type: Alert (21)

Come faccio a sapere che cosa causa l'errore da 82?

    
posta Yusuf 16.07.2013 - 12:04
fonte

1 risposta

8

La tua macchina .75 (il client) invia un messaggio di "avviso crittografato". Se lo fa, allora questa macchina, a quel punto, crede che la connessione sia ancora attiva e in esecuzione, e il server sarà in grado di ricevere il messaggio di avviso, e in particolare di decrittografarlo. Altrimenti, quale sarebbe il punto di inviare quel messaggio? Pertanto, è probabile che il messaggio FIN dal server è stato inviato dopo per ricevere questo avviso. Molto probabilmente, il client invia un avviso che attiva la chiusura della connessione e il server reagisce chiudendo il mezzo di trasporto (il pacchetto FIN).

Si noti che in un normale handshake, il server attenderà la ricezione del messaggio Finished dal client (il "messaggio di handshake crittografato" dopo Change Cipher Spec ) prima di inviare il proprio Change Cipher Spec e Finished . Qui vediamo che il server è stato in grado di elaborare il messaggio Finished dal client, compresa la decrittografia, la verifica MAC e il contenuto del messaggio.

Supponendo che entrambe le implementazioni siano conformi allo standard , il messaggio "avviso crittografato" è non un avviso close_notify . Un close_notify è un messaggio di avviso che avverte il destinatario dell'intenzione del mittente di terminare con garbo la connessione. Il destinatario deve quindi rispondere con un close_notify del proprio, contrassegnandone l'accettazione. Qui, il client invia un messaggio di avviso ma nessun messaggio di avviso viene inviato in risposta dal server, quindi potremmo supporre che non stiamo assistendo ad una chiusura graduale con una coppia di close_notify . Più plausibilmente, l'avviso del cliente è un avviso fatale , che indica al server che qualcosa non funziona e che la connessione è condannata. Il server può quindi solo chiudere il mezzo di trasporto perché non c'è nient'altro che possa fare a quel punto.

Non vi è alcuna indicazione su cosa abbia infastidito il cliente abbastanza da farlo inviare un avviso; tuttavia, ci sono indicazioni piuttosto decisive che tutte le operazioni di crittografia siano andate bene.

Potresti voler eseguire due acquisizioni di rete su entrambi i sistemi, in modo da ottenere tempi precisi per tutti i pacchetti; aiuta a ricostruire la sequenza effettiva degli eventi.

    
risposta data 16.07.2013 - 14:31
fonte

Leggi altre domande sui tag