Principio dell'operazione HTTPS

Il protocollo HTTP è costruito su TCP. TCP garantisce che i dati saranno consegnati, o è impossibile da consegnare (obiettivo non raggiungibile, ecc.). Apri una connessione TCP e invii messaggi HTTP attraverso di essa.

Ma TCP non garantisce alcun livello di sicurezza. Pertanto un livello intermedio denominato SSL viene posto tra TCP e HTTP e si ottiene il cosiddetto HTTPS. Questo modo di lavorare si chiama tunneling: si riversano i dati in un unico tunnel (SSL) e lo si raccoglie nell'altro. SSL riceve i messaggi HTTP, li crittografa, li invia su TCP e li decrittografa nuovamente dall'altra parte. La crittografia ti protegge da attacchi MITM intercettazioni e trasparenti (modifica dei messaggi).

Ma SSL non fornisce solo la crittografia, ma fornisce anche l'autenticazione. Il server deve avere un certificato firmato da un'autorità di certificazione (CA) ben nota che ne dimostra l'identità. Senza autenticazione, la crittografia è inutile in quanto l'attacco MITM è ancora possibile. L'aggressore potrebbe indurti a pensare che sia il server a cui desideri connetterti. La chat privata con il diavolo non è quello che vuoi, vuoi verificare che il server a cui ti stai connettendo sia davvero quello a cui vuoi connetterti. L'autenticazione ti protegge dal MITM.

Punti deboli

Quindi dove sono i punti deboli?

• Endpoint di connessione sicura. Il trasferimento potrebbe essere sicuro, ma per quanto riguarda il server stesso? O il cliente? Non possono.
• Non si utilizza HTTPS. Gli utenti possono essere indotti a non utilizzare lo schema in vari modi.
• CA non affidabili. Interrompono la parte di autenticazione, consentendo l'attacco MITM.
• Meccanismo di crittografia debole. Le tecnologie di crittografia invecchiano in due modi: si possono riscontrare seri difetti nella loro progettazione, che portano ad attacchi molto più efficienti della forza bruta, oi loro parametri e l'aumento della potenza di elaborazione a causa della legge di Moore potrebbe consentire un possibile attacco di forza bruta. >
• Implementazione dello schema. Bene, se si specifica A e si implementa B, le proprietà di A potrebbero non essere valide per B.

Risposta diretta

• Sembra che tu abbia assicurato il trasferimento (usando SSL). Questo non è abbastanza, la sicurezza del tuo server può essere compromessa - non dovresti memorizzare le password lì in testo normale, usa il loro modulo con hash, con sale aggiunto, ...

• SSL crittografa i dati sia durante l'invio che la ricezione. Gli attacchi MITM sono possibili virtualmente solo quando l'attaccante ha il certificato firmato da un'autorità fidata dal cliente. A meno che il client non sia indotto a non utilizzare HTTPS, nessuno può leggere né modificare i messaggi inviati.

• GET e POST sono solo due metodi per effettuare una richiesta HTTP. Ce ne sono anche molti altri. Il metodo è solo una proprietà della richiesta HTTP. Tutti i messaggi sono protetti, sia le richieste che le risposte, indipendentemente dal metodo HTTP utilizzato.

SSL protegge i dati in transito crittografandoli. Assicura solo, ad un cliente, che i dati lo faranno dal proprio computer al server senza essere intercettati o alterati (i dati crittografati potrebbero essere intercettati ma non hanno significato senza decrittografia). Detto questo, è responsabilità del cliente assicurarsi che SSL funzioni correttamente prima di inviare dati o dati attendibili dal server. Ci sono attacchi che rimuoveranno SSL dalla connessione, ma non che intercetteranno o altereranno i dati inviati tramite una connessione SSL protetta.

SSL non fornisce alcuna sicurezza una volta che i dati sono sul server. È ancora necessario utilizzare l'hashing e la crittografia lato server se si desidera proteggere i dati a riposo dalle violazioni al server stesso.

HTTPS è HTTP inviato tramite una connessione crittografata SSL. Copre sia GET che POST e qualsiasi altra azione HTTP mentre l'intero flusso HTTP si verifica inalterato ma viene passato attraverso un tunnel SSL al browser client.

SSL protegge solo la connessione tra client e server. In teoria lo fa abbastanza bene (ok, ci sono alcuni problemi - ma questi sono minori rispetto a tutti gli altri problemi :) purché nessuno dei circa 150 CA di cui ti fidi all'interno del tuo browser venga compromesso o lavori insieme ad alcune agenzie e dà loro CA intermedio per fare attacchi man-in-the-middle.

E, come ho detto, protegge solo la connessione tra client e server. Quindi, qualsiasi problema nella tua applicazione web come Cross-Site-Scripting, Cross-Site-Request-Forgery, SQL-Injection, ID di sessione non sicuri ecc. Funzionerà ancora per lo più, anche se la connessione è crittografata. Inoltre, il server può essere compromesso ecc.

In sintesi, SSL è necessario per proteggere i dati, ma non è l'unica cosa che devi fare per proteggere i dati.

Da chi stai cercando di proteggere la comunicazione? Se si tratta dell'NSA o di qualsiasi altra agenzia di sicurezza a livello statale, la risposta è no: hanno le risorse e la tecnologia per implementare con successo attacchi man-in-the-middle contro SSL. Se si tratta di reti criminali su larga scala, la risposta è ancora negativa: non possono compromettere le autorità di certificazione nel modo in cui la NSA e altri. può, ma possono facilmente compromettere le macchine stesse, e dare un'occhiata ai dati in uscita prima e ai dati in arrivo dopo la crittografia. Se stai solo ospitando un server, è meno preoccupante per te, dal momento che è molto più probabile che il compromesso si verifichi sulla macchina dell'utente finale e quindi è il loro problema. Se si tratta di pacchetti casuali che cercano di rubare e sfruttare i dati, allora sì - e nonostante quanto detto sopra, è ancora abbastanza una minaccia che dovresti usare SSL quando possibile.

Un dettaglio importante che le altre risposte non hanno menzionato è che SSL non crittografa l'URL della richiesta. Si noti che sotto lo schema GET, i dati sono solitamente codificati come parametri nell'URL. Ciò significa che se invii un modulo con un campo password su GET, la password NON verrà crittografata.