Verifica della vulnerabilità degli attacchi di barboncino.
Inoltre, potrei annusare il pacchetto da wireshark e vedere la versione TLS. Voglio scoprire se c'è un altro modo disponibile con cui posso testarlo?
Verifica della vulnerabilità degli attacchi di barboncino.
Inoltre, potrei annusare il pacchetto da wireshark e vedere la versione TLS. Voglio scoprire se c'è un altro modo disponibile con cui posso testarlo?
Annusando i pacchetti con alcune applicazioni come Wireshark si rivelano le informazioni; la versione del protocollo utilizzata in una connessione è contenuta nel messaggio ServerHello (fare attenzione a guardare il campo server_version , non la "versione" nelle intestazioni dei record, che potrebbero non corrispondere).
Se non si desidera utilizzare uno sniffer di pacchetti, è possibile provare a modificare il DNS in modo che la richiesta di connessione dall'applicazione non vada al server previsto, ma a un altro computer controllato dall'utente. Su quel computer, è quindi possibile eseguire un piccolo software server che si collega alla porta 443 e riceve il messaggio ClientHello dal client. Guardando il contenuto del messaggio, è possibile vedere la versione massima supportata dal client. Inviandoti il messaggio al server desiderato, potresti anche ottenere il corrispondente ServerHello e vedere di persona. Tuttavia, usare uno sniffer di pacchetti sarebbe più semplice.
(Alterazione del DNS dovrebbe essere fattibile sul punto di accesso WiFi, se il cellulare si connette tramite WiFi.)
Non è possibile ottenere le informazioni senza connettersi a un certo punto al vero server, né dall'applicazione mobile né da soli; il motivo è che la versione del protocollo è il risultato di una negoziazione tra client e server. Il client suggerisce, ma il server sceglie.
Un ulteriore problema è attacchi di downgrade del protocollo . È improbabile che il client e il server utilizzino SSL 3.0 per impostazione predefinita; richiederebbe che una o entrambe le implementazioni non fossero a conoscenza di TLS 1.0 (pubblicato nel gennaio 1999!). Tuttavia, è ipotizzabile che SSL 3.0 possa essere forzato su di loro. Il metodo è semplice: l'autore dell'attacco semplicemente interrompe (con pacchetti RST) qualsiasi connessione in cui il client annuncia qualcosa di più recente di SSL 3.0 nella sua ClientHello . Alcuni client tenteranno nuovamente, limitandosi volontariamente a SSL 3.0. Se l'applicazione è un client di questo tipo, l'attacco di downgrade del protocollo ha esito positivo e le connessioni utilizzeranno SSL 3.0. Il problema qui è che non puoi sapere se un attacco di downgrade del protocollo si applica senza averlo provato: dipende dal comportamento del client in circostanze anomale, quindi devi forzare le circostanze anomale. Sei tornato al piano dello sniffer, con una vendetta.
D'altra parte, potresti ottenere le informazioni che cerchi semplicemente collegandoti al server. Da un computer con OpenSSL (ad esempio qualsiasi sistema Linux o MacOS X), prova questo:
openssl s_client -ssl3 -connect theservername:443
sostituzione di "theservername" con il nome effettivo del server (ed eventualmente sostituzione della porta se la connessione non utilizza la porta standard 443). OpenSSL proverà a connettersi usando solo SSL 3.0 come protocollo supportato. Se il server rifiuta immediatamente la connessione con un messaggio di avviso "protocol_version", allora sapere che il server non accetta di usare SSL 3.0, e quindi la connessione tra app e server non utilizzerà mai SSL 3.0 , indipendentemente dagli attacchi di downgrade del protocollo.
Ma se il server accetta una connessione SSL 3.0, tutte le opzioni sono ancora aperte e si torna a provare l'attacco di downgrade.
Leggi altre domande sui tag tls