Configurazione sicura di Ciphers / MAC / Kex disponibile in SSH

In questo momento , non vi è alcun punto debole noto con la crittografia MD5 o CBC o MAC a 96 bit come vengono utilizzati in SSH . Quindi non vi è, stricto sensu, nessun vantaggio di sicurezza nell'attuare le modifiche di configurazione che state proponendo. Si potrebbe sostenere che la rimozione del supporto per alcuni algoritmi potrebbe portare a problemi di sicurezza perché potrebbe impedire a alcuni client di connettersi, costringendo l'utente a trovare soluzioni alternative che potrebbero essere meno sicure (ad esempio, se scp non è più possibile, invia il file via email ...).

Il meno irrazionale dei tuoi obiettivi di progettazione è il divieto contro CBC. La sicurezza CBC richiede una corretta gestione dei vettori di inizializzazione; nel caso di SSH, l'IV viene estratto dall'ultimo blocco del pacchetto precedente (vedi lo standard ), che va bene fintanto che l'attaccante non si trova in una situazione di "attacco con testo in chiaro scelto". In pratica, i dati che entrano nel tunnel SSH non sono ostili, contrariamente a quanto avviene nei contesti HTTPS in cui il codice client malevolo (in Javascript) è una possibilità definita. Allo stesso modo, gli attacchi oracle di padding su SSH sono difficili da sfruttare (supponendo che il codice client o server non sia adeguatamente protetto), perché SSH è orientato alla connessione e non aprirà automaticamente la connessione non riuscita (lì di nuovo, contrariamente a quanto accade con HTTPS).

Allo stesso modo, HMAC / MD5 è, per quanto ne sappiamo, più solido che mai. Gli attacchi di collisione noti su MD5 non hanno alcun impatto sulla sicurezza dell'HMAC, tranne che nei più delicati dei sensi (che possono essere riassunti come: "MD5 puzza"). Per quanto riguarda il troncamento dei valori HMAC a 96 bit, non vi è ancora alcuna ragione per discriminare ciò: un utente malintenzionato ignorerà con successo un valore MAC a 96 bit con probabilità 2 ^-96 , che è estremamente basso e impossibile sfruttare in pratica perché qualsiasi errore MAC su una singola connessione SSH viene segnalato con un messaggio di errore abbastanza visibile. Questo è ancora il modo in cui viene utilizzato SSH che lo protegge dal livello di automazione degli attacchi che può essere applicato a HTTPS.

Quindi si potrebbe dire che dal momento che la potatura degli algoritmi dalla lista è a beneficio dei tuoi sentimenti di sicurezza, la lista giusta è quella che ti farà sentire più sicuro. Questo è soggettivo, per definizione, quindi sei l'unico che può definire questa lista "migliore". Per quanto mi riguarda, sono abbastanza soddisfatto delle impostazioni predefinite.

Per quanto riguarda order , prendi in considerazione questo estratto dalla sezione 7.1 di RFC 4253 :

  encryption_algorithms
     A name-list of acceptable symmetric encryption algorithms (also
     known as ciphers) in order of preference.  The chosen
     encryption algorithm to each direction MUST be the first
     algorithm on the client's name-list that is also on the
     server's name-list.

Quindi l'algoritmo scelto sarà l'algoritmo preferito del cliente . L'ordine di preferenza del server è solo un commento glorificato; non avrà alcun impatto su quale algoritmo è effettivamente scelto. Pertanto, l'ordine in /etc/sshd_config non è importante.

Chiunque sia veramente preoccupato per la sicurezza di SSH probabilmente vuole leggere questa pagina:

link

Passa attraverso tutti gli scambi di chiavi, autenticazioni server, cifrari e MAC supportati da OpenSSH e poi getta via qualsiasi cosa non possa più essere considerata sicura, dando una valida giustificazione per tutto ciò che elimina. Con questa configurazione, sei solido!

TL; DR? I vincitori per la massima sicurezza sono:

Scambio di chiavi: curve25519-sha256
(fallback: diffie-hellman-group-exchange-sha256 )

Autenticazione server: Ed25519 with SHA512
(fallback: RSA with SHA1 4096 Bits )

Cipher: chacha20-poly1305
(fallback: aes256-ctr )

MAC: hmac-sha2-512-etm
(fallback: hmac-sha2-512 )

Il fallback è ciò che troverai nella maggior parte dei server SSH, non abbastanza sicuro, ma comunque abbastanza sicuro secondo gli standard odierni.

Solo un commento da parte mia: se si utilizza SSH anche per copiare i dati ( scp o rsync ) o per il port forwarding X11 o VNC, le prestazioni e la latenza non sono irrilevanti. In tal caso, aes128-ctr offrirà le migliori prestazioni (fuori dai cifrari noti per essere sicuri fino ad oggi) e potresti considerare l'utilizzo di [email protected] , poiché anche MD5 è stato interrotto, HMAC-MD5 non ha oggi e MD5 batte SHA-1 in velocità e SHA-2 anche di gran lunga. Per avere un'idea della velocità dell'algoritmo, vedi quella pagina:

link

IMHO è un compromesso accettabile: scambiare un po 'di sicurezza per molta più velocità.

Che dire di chacha20-poly1305 ? Non ho ancora benchmark per chacha20-poly1305 finora, né posso affermare che sia sicuro. Dovrebbe essere un rimpiazzo per RC4 (alias arcfour), quindi probabilmente è anche più veloce di aes128-ctr nel software, ma le moderne CPU Intel possono calcolare AES128 nell'hardware, quindi se l'implementazione SSH fa uso di questo, è possibile aspettarsi AES128 per essere molto veloce Ancora ChaCha potrebbe essere più veloce ma è la sicurezza non ancora provata che mi preoccupa un po '; sono stati provati attacchi troppo piccoli e anche se esiste dal 2008, solo recentemente ChaCha è diventato popolare quando è stato rivelato che l'NSA può interrompere le connessioni RC4 SSL / TLS in tempo reale. ChaCha lo aggiusterà e sostituirà RC4 in TLS, ma questa non è una prova per la sua sicurezza.

Non preoccuparti mai dello scambio di chiavi o dell'autenticazione del server, la loro velocità gioca solo un ruolo alla connessione iniziale e ogni volta che la chiave deve essere rinnovata (quando ciò accade dipende dalla cifra scelta e dalla quantità di dati che trasferisci .. ogni cifrario ha un limite di dati e una volta raggiunto, una nuova chiave viene scambiata come stare con quella esistente indebolirebbe la crittografia da quel punto in poi, ma i rinnovi non avvengono così frequentemente, quindi per questi due dovrei cerca sempre la massima sicurezza e ignora del tutto la velocità.

E non usare mai gli hash troncati (-96) per MD5 o SHA-1. Non ti danno alcun vantaggio se non quello di salvare un paio di byte per pacchetto (4 per MD5, 8 per SHA-1). L'hash impiegherà parecchio tempo a calcolare / verificare (nessun vantaggio di velocità) e il troncamento indebolirà solo la sicurezza (nessun beneficio per la sicurezza). Il troncamento verrebbe a buon fine per SHA-2 in quanto sono molto più grandi (32, 48, 64 byte per pacchetto) e tali hash di grandi dimensioni non hanno senso considerando la dimensione massima di un pacchetto di trasmissione, ma per questi troncamenti non è un'opzione. p>     

Per rimuovere i cifrari cbc, aggiungi o modifica la riga "Cipher" in / etc / ssh / sshd_config come di seguito: Cipher aes128-ctr, aes192-ctr, aes256-ctr, arcfour256, arcfour128, arcfour

Per rimuovere HMAC MD5 Aggiungere o modificare la riga MAC in / etc / ssh / sshd_config come di seguito: MAC hmac-sha1, hmac-ripemd160

Riavvia SSHD per applicare le modifiche: servizio sshd restart