HTTPS protegge dagli aggressori attivi?

TLS (il protocollo di rete protetto sottostante HTTPS) specifica un gran numero di "pacchetti di crittografia" (combinazioni di primitive crittografiche, come crittografie asimmetriche e simmetriche, funzioni di hash, ecc.). Tutte le suite di crittografia ampiamente utilizzate, le uniche che dovrebbero essere consentite da client come browser Web o server, forniscono quanto segue:

1. Autenticazione del server (quindi un utente malintenzionato non può presentare la propria chiave pubblica e ottenere il client per accettarlo come valido).
2. Codifica dei dati trasferiti in entrambe le direzioni (fornendo così riservatezza, come hai notato).
3. Integrità del testo del messaggio (per impedire attacchi di bit-flipping sul testo cifrato, ad esempio).
4. Protezione riproduzione (catturare il traffico crittografato da una parte della conversazione e iniettarlo in una parte successiva non funzionerà).
5. Protezione della sequenza (un utente malintenzionato non può prendere con successo più pacchetti di messaggi, riorganizzarli e trasmettere il messaggio ricomposto, verrà rifiutato)

Alcune suite di crittografia offrono una protezione aggiuntiva:

• Perfect Forward Secrecy (PFS), tale che anche se un utente malintenzionato registra una conversazione e successivamente ottiene l'accesso alla chiave privata del server, la conversazione non può mai essere decifrata (salva dalla forza bruta o interrompendo le primitive crittografiche).

TLS (incluso HTTPS) può essere configurato facoltativamente per fornire la seguente protezione:

• Autenticazione del client (normalmente, il server fornisce al client un certificato che mostra l'autenticità del server, è possibile che il client fornisca anche al server un tale certificato, che può sostituire la necessità di altre forme di autenticazione come come trasmettere una password).
• Protezione del downgrade, che impedisce il fallback a versioni precedenti del protocollo con vulnerabilità note o sospette.

TLS non fornisce le seguenti protezioni:

• Maschera di lunghezza, oltre il grado limitato fornito da alcune primitive (se l'attaccante conosce la lunghezza dei possibili messaggi in entrambe le direzioni e ogni messaggio ha una lunghezza diversa, l'attaccante può probabilmente ricostruire il traffico del messaggio guardando le lunghezze dei messaggi ).
• Mascheramento del tempo, oltre all'aggiunta di alcuni overhead (se l'attaccante sa per quanto tempo determinate operazioni eseguono, l'attaccante può indovinare quando tali operazioni sono state richieste / eseguite monitorando i tempi tra i messaggi in ciascuna direzione).
• Disponibilità (un man-in-the-middle può sempre decidere di non trasmettere il traffico di rete, con conseguente negazione del servizio).
• L'anonimato del server o del client (l'indirizzo IP del client e l'indirizzo IP del server e il nome dell'host sono esposti in testo in chiaro a chiunque controlli il traffico).

In generale, sì, HTTPS è sicuro contro la maggior parte degli attacchi attivi a parte il denial-of-service. Tuttavia, ci sono limitazioni. TLS non protegge dallo sfruttamento delle debolezze nelle primitive crittografiche che utilizza (ad esempio, questo è il motivo per cui le suite di crittografia che utilizzano il cifrario simmetrico RC4 sono ora deprecate). La crittografia perde canali secondari come la lunghezza e la temporizzazione, che in alcune applicazioni possono consentire a un utente malintenzionato di violare la riservatezza (sebbene un'applicazione attenta alla sicurezza possa normalizzare le lunghezze / i tempi del traffico di rete per chiudere questo canale laterale). p>

Inoltre, è possibile utilizzare TLS in modo insicuro se lo si configura in modo errato. Ad esempio, i controlli di convalida dell'autenticità del certificato possono essere disabilitati o sostituiti con controlli personalizzati errati, invalidando il controllo dell'autenticazione e consentendo a un utente malintenzionato attivo di utilizzare un certificato fraudolento. Se sia il client che il server consentono suite di crittografia non sicure ("NULL"), è possibile configurare TLS in modo che non utilizzi verifiche di autenticazione, crittografia o integrità. Infine, le implementazioni TLS stesse possono presentare vulnerabilità di sicurezza. La vulnerabilità "Heartbleed" del 2014 era dovuta a un bug di sicurezza estremamente grave in una libreria TLS molto comune (OpenSSL); se vengono utilizzate implementazioni non protette / non corrette, le protezioni di TLS possono essere aggirate e / o possono essere introdotte altre debolezze.

Direi che dipende dal tipo di active attack e dal intent dell'aggressore ... se questo è un attacco Denial of service, ad esempio, HTTPS non ti proteggerà veramente qui ... ma se l'intento è quello di ottenere l'accesso ai dati privati, quindi HTTPS è una buona prima linea di difesa da avere:

Ad esempio, si supponga di voler accedere a un sito Web della banca, il sito richiede il nome utente e la password. Quando si inviano questi dati, non si desidera che vengano trasferiti in chiaro, quindi un modo in cui l'app ti protegge è utilizzare la tecnologia HTTPS per "nascondere" questi dati in chiaro (crittografia) poiché vengono inviati alla banca per la verifica. E una volta che la banca lo riceve, sa come "nasconderlo" alle tue credenziali ed effettuare il login. Quindi il server bancario emetterà un identifier/session per aiutarti a tracciarti mentre ti sposti tra le pagine web nel app. La banca ha bisogno di un modo per condividere / inviarti questo session/identifier . E non vogliamo un intercettatore per ottenere questo identificatore / sessione o indovinarlo, e così la crittografia viene utilizzata per nasconderlo di nuovo in vista e inviarlo a voi. Naturalmente sto semplificando, ma questa è l'idea. E questo è un modo in cui HTTPS è in grado di proteggerti da un aggressore.

HTTPS non è affatto l'unica difesa che dovresti avere contro gli attaccanti. È necessario altro, ad esempio, è necessario proteggere il sistema da utenti autorizzati, XSS, SQL injection ecc.

Questo dipende anche da cosa stai cercando di proteggere. Questa è una buona domanda, ma può essere risolta in molti modi poiché "dipende" da una serie di cose.