Il client può inviare i dati dell'applicazione in TLS 1.2 o precedente prima di ricevere il messaggio Messaggio finito?

Question

Il client può inviare i dati dell'applicazione in TLS 1.2 o precedente prima di ricevere il messaggio Messaggio finito?

#1 da (3 voti)

3

Ho letto Ivan Ristic, Bulletproof SSL e TLS. È stato detto dopo 2 RTT, il client inizia a inviare i dati dell'applicazione come per es. Richiedi GET.

Ma ho visto durante l'analisi dei pacchetti tramite wireshark che in alcuni siti i client iniziano a inviare l'applicazione insieme al messaggio ClientFinished cioè dopo 1 RTT, mentre in alcuni casi non lo fa e inizia a inviare i dati dell'applicazione dopo 2 RTT cioè dopo aver ricevuto ServerFinished Messaggio.

Penso che non sia necessario attendere fino a ServerFinished per l'invio dei dati dell'applicazione poiché il client ha già la chiave, quindi può iniziare a inviare i dati dell'applicazione.

In quali casi il client invia i dati dell'applicazione prima del messaggio ServerFinished e in quali casi dopo il messaggio ServerFinished?

Se 1 RTT era già presente in TLS 1.2, allora perché c'è così fuzz su 1 RTT in TLS 1.3? A proposito, questa non è la mia domanda principale, rispondi se vuoi.

Copiato da RFC

  Client                                               Server

  ClientHello                  -------->
                                                  ServerHello
                                                 Certificate*
                                           ServerKeyExchange*
                                          CertificateRequest*
                               <--------      ServerHelloDone
  Certificate*
  ClientKeyExchange
  CertificateVerify*
  [ChangeCipherSpec]
  Finished                     -------->
                                           [ChangeCipherSpec]
                               <--------             Finished
  Application Data             <------->     Application Data

         Figure 1.  Message flow for a full handshake

web-browser tls

posta prakharjain 06.05.2017 - 09:43

fonte

1 risposta

Leggi altre domande sui tag web-browser tls

È possibile inviare un messaggio e il 100% offuscare l'origine del mittente in una bacheca di rete p2p? Domanda su IDS e IPS

score 3 · Accepted Answer

Anche se non so che cosa abbiate visto, il TLS 1.2 afferma esplicitamente che i dati dell'applicazione devono essere inviati solo dopo che l'handshake è stato completato. Ciò significa che entrambe le parti hanno ottenuto e verificato il messaggio Finito dall'altra parte. Questo è indicato in varie parti della RFC 5246 , come

7.4.9. Finished
...
Once a side has sent its Finished message and received and validated the Finished message from its peer, it may begin to send and receive application data over the connection.

All'interno di una stretta di mano completa il messaggio Finito viene prima inviato dal client e poi dal server. Ciò significa che il client deve attendere che il server riceva e verificare il messaggio Finito dal client e quindi inviare nuovamente il proprio messaggio Fine. E solo dopo che il client ha ricevuto e verificato questo messaggio completato dal server, può inviare i dati dell'applicazione.

Ma, in una sessione di successo riprendi, il messaggio Finito viene prima inviato dal server e poi dal client. E in questo caso i dati dell'applicazione dal client possono ovviamente seguire direttamente il messaggio Finito dal client. Da RFC 5246 pagina 37:

  Client                                                Server

  ClientHello                   -------->
                                                   ServerHello
                                            [ChangeCipherSpec]
                                <--------             Finished
  [ChangeCipherSpec]
  Finished                      -------->
  Application Data              <------->     Application Data

      Figure 2.  Message flow for an abbreviated handshake

... that in some sites clients starts sending application right along with ClientFinished message i.e. after 1 RTT, while in some cases it doesn't and starts sending application data after 2 RTT

Una possibilità è che hai notato solo che i dati dell'applicazione dal client seguivano direttamente il messaggio Finito ma che non ti rendevi conto che ciò era dovuto al fatto che si verificava una sessione e quindi il Finito dal server è già stato ricevuto e verificato dal cliente.

Tuttavia, dopo aver modificato la domanda e incluso un'immagine, è ovvio che non è questo il caso e che è stata effettuata una stretta di mano completa con l'invio anticipato dei dati dell'applicazione. Si chiama TLS False Start ed è definito in RFC 7918 . In base a questo RFC TLS, il False Start può essere eseguito se il client ha una conoscenza precedente del fatto che il server è compatibile con l'avvio falso e se vengono utilizzati codici cifrati bianchi validi per l'utilizzo con false start. Per una breve introduzione in TLS False Start vedi High Performance Rete di browser .

If 1 RTT was already there in TLS 1.2, then why there is so fuzz about 1 RTT in TLS 1.3?

TLS 1.3 ha cambiato molto il protocollo. Il risultato di questo era 1-RTT invece di 2-RTT per l'intera stretta di mano e facoltativamente 0-RTT invece di 1-RTT sulle connessioni successive (ad esempio, cosa era il riassunto della sessione in TLS 1.2).