Qual è il più vulnerabile agli attacchi MITM, SSL o SSH?

Con SSH, le cose sono fatte in questo modo:

• sul laptop, eseguire ssh -N -D 5000 proxy-machine (dove proxy-machine è il nome DNS della macchina "Proxy Web");
• configura il browser per utilizzare il protocollo SOCKS su localhost e porta 5000.

Questo è conveniente e attivato in meno di 20 minuti. Ha, tuttavia, le seguenti conseguenze:

• L'utente laptop deve eseguire il comando ssh e tenerlo attivo finché desidera navigare in Internet attraverso il proxy.
• Il comando ssh deve essere installato sul laptop (è un problema standard con MacOS X, Linux e tutti i sistemi di tipo Unix, ma non con Windows).
• Il computer del proxy Web deve eseguire un server SSH.
• L'utente laptop deve avere un account sul computer Proxy Web (è possibile limitare tale account all'impostazione di tunnel come quello sopra, ma non è facile da configurare).

Con SSL, dovresti installare alcuni software proxy sul Proxy Web (ad esempio calamari ) e configurarlo con un Certificato X.509, in modo che i client (il laptop) utilizzino https://proxy-machine:9000/ come URL proxy (il numero di porta può essere modificato a piacere, ho usato 9000 come esempio). Non c'è software da installare sul laptop; il browser deve solo essere configurato per utilizzare l'URL corretto come proxy a livello HTTP. Fai attenzione agli script di configurazione automatica del proxy, potrebbero essere modi in cui l'autore dell'attacco può forzare un'altra configurazione del proxy; è meglio configurare il proxy manualmente.

SSL e SSH utilizzano protezioni distinte contro gli attacchi Man-in-the-Middle. Il client SSH registra la chiave pubblica del computer di destinazione (nel file $HOME/.ssh/known_hosts su sistemi Unix-like) in modo che possa verificare che la chiave pubblica del server sia quella giusta; solo la prima connessione è mai vulnerabile. Le chiavi pubbliche SSH hanno impronte digitali (cioè valori hash) che possono essere usate per verificare che una chiave sia corretta (l'idea è che puoi telefonare al sysadmin e lui scriverà l'impronta digitale, questo è noioso ma deve essere fatto solo una volta per server SSH). Fino a quando il laptop o il proxy non viene compromesso, o gli algoritmi crittografici vengono completamente demoliti dai crittanalisti irati, la via SSH è sicura.

SSL si basa su certificati X.509 . La sicurezza proviene dal set di trust anchors (noti anche come "certificati radice") già incorporati nel browser (o nel sistema operativo). Le autorità di certificazione dovrebbero emettere certificati solo per le entità debitamente autenticate e le firme digitali sono gli strumenti crittografici con cui il browser può verificare che i contenuti dei certificati non siano stati manomessi e solo le autorità di certificazione accettate sono state coinvolte. Per montare un MitM, un utente malintenzionato dovrebbe corrompere una CA per emettere un certificato falso, con il nome proxy-machine , ma con una chiave pubblica di proprietà dell'attaccante.

La sicurezza X.509 si basa su molte più supposizioni della sicurezza SSH, che viene gestita localmente e dove ciò che accade è piuttosto semplice. Ma lo scenario SSH richiede che l'utente laptop sia un po 'più consapevole di ciò che sta accadendo. Per me , userei SSH (in effetti, questo è quello che faccio); per un'organizzazione con molti utenti, seguirei il percorso SSL (ma il requisito "20 minuti" sarebbe uno scherzo).

I miei due centesimi:

• Entrambi richiedono client / server aggiornati
• Entrambi si basano sulla conoscenza dell'impronta digitale pubblica della chiave / certificato del server.

Per prevenire MITM, trova un modo per avere l'impronta digitale disponibile sul tuo host client. Con SSH è facile da raggiungere poiché memorizza la chiave e rifiuterà di connettersi al server se è stata modificata, correggila una volta e sei a posto.

L'uso di questo comando ridurrà la probabilità di successo di un MITM:

ssh -o VisualHostKey=yes -2

Un altro punto per usare SSH, l'implementazione principale proviene dal server openssh, distribuito dal progetto OpenSSH . Lo hanno progettato e implementato, sono noti per controllare il loro codice e rendere ogni versione più sicura.

Ora, SSL fornirà meno controllo di SSH, il browser spesso implementa il controllo delle impronte digitali in modo intuitivo e si affida a una catena di fiducia per autenticare certificati / siti.

Se hai la possibilità, SSH è meno vulnerabile a MITM:

• non esternalizza la fiducia
• è facile verificare la presenza di modifiche alla chiave / certificato

L'unico motivo per usare SSL dal mio punto di vista è fornire un modo semplice per gli utenti di ottenere la crittografia asimmetrica per il loro flusso di dati e, naturalmente, l'autenticazione. L'usabilità sacrificherà sempre la sicurezza a un certo punto. SSH si concentra meno sull'usabilità e più sulla sicurezza. È facile capire che l'accesso alla shell su una macchina è più importante che impedire l'intercettazione del traffico web. Per Techies, dovrebbe essere facile usare SSH, ma richiede di ottenere un accesso su una macchina bouncing se si desidera utilizzarlo in uno scenario proxy, mentre con SSL, sono già molti proxy gratuiti, è più conveniente.

Personalmente userò SSH per i seguenti motivi.

1. Ho già account su alcune macchine con SSH abilitato
2. Ho già effettuato l'accesso a tali account, quindi ho già memorizzato le loro chiavi pubbliche nella cache (impedirò in modo efficace un attacco MitM)
3. È un singolo comando per impostare la connessione (vedi la risposta di Thomas) e una semplice modifica nel browser (che può anche essere eseguita tramite riga di comando con --proxy-server =: in Chrome)

Il meccanismo per un attacco MITM sarebbe esattamente lo stesso per entrambi i protocolli, come lo sono le tecniche di mitigazione. In entrambi i casi, ci si affida al controllo delle differenze nella chiave / certificato dell'host al momento della connessione.

Tuttavia, mi proverò di più su SSH in questo caso, poiché SSL si basa sulla PKI SSL globale (autorità di certificazione, ecc.) mentre SSH si aspetta semplicemente che la chiave host non cambi. Quindi, mentre SSH è molto vulnerabile agli attacchi MITM per la primissima connessione, rileverà in modo affidabile qualsiasi tentativo MITM per qualsiasi connessione successiva dal momento in cui verrà tracciata l'ultima chiave host attendibile e un confronto eseguito su ciascuna connessione provare in seguito.

E anche se è improbabile che un utente malintenzionato sia in grado di ottenere un certificato SSL valido per il nome host e di poterlo usare contro di te, non è inaudito e talvolta accade.

Oltre alle risposte precedenti. Generalmente HTTPS non viene filtrato, SSH su una porta non standard è molto più probabile che sia così, il che rende la soluzione HTTPS utilizzabile in più casi.

Inoltre, con estensioni del browser come Certificate Patrol puoi essere avvisato delle modifiche alla chiave del server come SSH e non essere alla mercé di un'autorità di certificazione corrotta o incompetente.