Qual è la differenza tra SSL e SSH? Quale è più sicuro?

SSL e SSH forniscono entrambi la crittografia elementi per costruire un tunnel per il trasporto di dati confidenziali con integrità verificata.Per quella parte, usano tecniche simili e possono subire lo stesso tipo di attacchi, quindi dovrebbero fornire una sicurezza simile (cioè una buona sicurezza) assumendo che siano entrambe correttamente implementate. Che esistano entrambi è una specie di sindrome di NIH : gli sviluppatori SSH avrebbero dovuto riutilizzare SSL per la parte del tunnel (il protocollo SSL è abbastanza flessibile da ospitare molte varianti, inclu ding non usando certificati).

Differiscono per le cose che si trovano intorno al tunnel. SSL utilizza tradizionalmente i certificati X.509 per annunciare le chiavi pubbliche del server e del client; SSH ha un proprio formato. Inoltre, SSH viene fornito con una serie di protocolli per ciò che va allinterno del tunnel (multiplexing di diversi trasferimenti, esecuzione dellautenticazione basata su password allinterno del tunnel, gestione del terminale …) mentre non esiste nulla di simile in SSL o, più precisamente, quando tali cose vengono utilizzate in SSL non sono considerate come parte di SSL (ad esempio, quando si esegue lautenticazione HTTP basata su password in un tunnel SSL, diciamo che fa parte di “HTTPS”, ma funziona davvero in un modo simile a quello che accade con SSH).

Concettualmente, potresti prendere SSH e sostituire la parte tunnel con quella da SSL. Puoi anche prendere HTTPS e sostituire la cosa SSL con SSH-with-data-transport e un hook per estrarre la chiave pubblica del server dal certificato. Non cè impossibilità scientifica e, se fatto correttamente, la sicurezza rimarrebbe la stessa. Tuttavia, non esiste un insieme diffuso di convenzioni o strumenti esistenti per questo.

Quindi non usiamo SSL e SSH per le stesse cose, ma questo è a causa di quali strumenti storicamente venivano forniti con le implementazioni di quelli protocolli, non a causa di una differenza relativa alla sicurezza. E chiunque implementi SSL o SSH farebbe bene a controllare che tipo di attacchi sono stati tentati su entrambi i protocolli.

Commenti

• Ottimo lavoro. E infatti, poiché SSH è più facile da configurare rispetto a SSL, molte persone eseguono il tunneling http (non https) allinterno di SSH, ad esempio per eseguire lamministrazione del sistema remoto con un web Strumento GUI come ebox o webmin.
• Giusto per sottolineare, ‘ non è del tutto vero che i ragazzi di SSH ” dovrebbe ” aver utilizzato SSL: SSH è stato progettato in modo molto specifico per avere una piccola superficie di attacco ed essere molto sicuro. SSHv2 non ha nessuno dei problemi e insidie in SSL / TLS, quindi andando con una cosa più piccola che u Capirono bene, con meno complessità, uscirono con qualcosa di molto più adatto alla loro situazione. Dipende da quanto sei paranoico: SSL non è ‘ t inutilizzabile, a seconda dellapplicazione, ma il design di SSH ‘ lo rende accettabile in situazioni / comunità di sicurezza in cui SSL semplicemente non è attendibile.
• Il design di @NicholasWilson ” SSH ‘ lo rende accettabile in situazioni / comunità di sicurezza in cui SSL semplicemente non è attendibile ” come …
• SSL e SSH sono stati sviluppati in parallelo (entrambi rilasciati nel 1995), quindi anche se SSH potrebbe aver utilizzato SSL non è chiaro. Anche se avrebbe dovuto usare il contemporaneo SSL 2.0 è molto dubbio 🙂
• Bene, SSH 2.0 è stata una riscrittura completa del protocollo ed è apparso intorno al 1999, quindi si potrebbe aver riutilizzato SSL 3.0 o anche TLS 1.0. Ma, ovviamente, TLS sembra essere legato a X.509, il che spaventa gli sviluppatori.

Questo non è “un confronto ragionevole da fare. SSL è un metodo generale per proteggere i dati trasportati su una rete, mentre SSH è unapplicazione di rete per laccesso e la condivisione dei dati con un computer remoto.

La protezione del livello di trasporto in SSH è simile per capacità a SSL, quindi quale sia “più sicuro” dipende da ciò che richiede il tuo modello di minaccia specifico e se le implementazioni di ciascuna risolvono i problemi che stai cercando di affrontare.

SSH ha quindi un livello di autenticazione utente che manca a SSL (perché non ne ha bisogno – SSL deve solo autenticare le due interfacce di connessione che anche SSH può fare). In UTF-8 art:

 SSL SSH +-------------+ +-----------------+ | Nothing | | RFC4254 | Connection multiplexing +-------------+ +-----------------+ | Nothing | | RFC4252 | User authentication +-------------+ +-----------------+ | RFC5246 | | RFC4253 | Encrypted data transport +-------------+ +-----------------+ 

Per quanto riguarda il problema contro il quale ci sono più potenziali attacchi, sembra chiaro che SSH ha una superficie di attacco più ampia. Ma questo è solo perché SSH ha un intero applic azione incorporata: la superficie di attacco di SSL + qualunque applicazione tu abbia bisogno di fornire non può essere confrontata perché non abbiamo informazioni sufficienti.

Commenti

• -1 È un confronto ragionevole. Si presume erroneamente che OP stia confrontando SSL con il programma unix ssh (1) . SSH è in realtà un altro protocollo che fornisce sicurezza a livello di trasporto, che ha disposizioni speciali per shell remote ed esecuzione remota.
• +1 @jpillora mentre sono daccordo che ha senso confrontare i due, il termine SSH è non tipicamente utilizzato per fare riferimento al sottoinsieme del protocollo SSH che gestisce la sicurezza del livello di trasporto che sarebbe direttamente paragonabile a SSL / TLS. È utilizzato quasi esclusivamente in riferimento al protocollo del livello dellapplicazione che differisce da SSL / TLS nel modo descritto in questa risposta.
• @freb nel modo in cui ‘ il rinvio in generale non cambia la verità della questione. SSH è un protocollo utilizzato come livello di trasporto per lutilità ssh. La risposta accettata e più votata riflette questo fatto.
• @jpillora Volevo semplicemente dire che non ‘ penso che il protocollo del livello di trasporto SSH sia ciò che la maggior parte delle persone vorrebbe dire data la formulazione della domanda. Tuttavia, data la risposta che è stata accettata come corretta, deve essere stato quello che chiedeva OP.
• @freb Giusto, la maggior parte delle persone pensa che data la frase, il che rende ancora più importante correggere questo comune malinteso.

Da un punto di vista crittografico rigoroso, entrambi forniscono crittografia autenticata, ma in due diversi modi.

SSH utilizza il cosiddetto Encrypt-and-MAC, ovvero il messaggio cifrato è giustapposto a un codice di autenticazione del messaggio (MAC) del messaggio in chiaro per aggiungere integrità. Non è dimostrato che sia sempre completamente sicuro (anche se in casi pratici dovrebbe essere sufficiente).

SSL utilizza MAC-then-Encrypt: un MAC è giustapposto al testo in chiaro, quindi sono entrambi crittografati . Anche questo non è il massimo, poiché con alcune modalità di cifratura a blocchi parti del MAC possono essere indovinate e rivelare qualcosa sul codice. Ciò ha portato a vulnerabilità in TLS 1.0 (attacco BEAST).

Quindi hanno entrambi potenziali punti deboli teorici. Il metodo più efficace è Encrypt-then-MAC (aggiungi un MAC del messaggio cifrato), che è implementato, ad esempio, in IPsec ESP.

Commenti

• SSH ‘ Il protocollo dei pacchetti binari è criptato e MAC dove per ogni messaggio in chiaro (m) invia il testo cifrato E (m) ++ MAC (m) (concatena criptato messaggio con MAC), contro SSL che fa E (m ++ MAC (m)). Tuttavia, SSH è molto più del suo protocollo di pacchetto binario (gestione delle chiavi, client / server shell remoto, trasferimento di file, ecc.), Mentre SSL (ora chiamato TLS) è solo il protocollo del livello di trasporto utilizzato in altri protocolli che aggiungono nelle funzionalità necessarie (es. HTTPS, FTPS, IMAPS ecc.). Vedi anche il confronto tra EtM, E & M, MtE su: crypto.stackexchange.com / questions / 202
• Pienamente daccordo, cè molto di più di quello che ho scritto; questo ‘ è ciò che intendevo con il mio incipit ” da un punto di vista crittografico rigoroso “.
• BEAST non è correlato a MtE ed è dovuto al noto-IV con CBC (in SSL3 e TLS1.0), che anche SSH2 fa e non ha corretto, sebbene abbia ottenuto CTR come alternativa prima che sia esso che TLS ottenessero AEAD = GCM (TLS anche CCM) (ed entrambi ChaCha / Poly) come alternativa migliore. Gli attacchi basati sul padding MtE + CBC sono POODLE e Lucky13.
• Ho una soluzione che rende MAC-then-Encrypt sicuro per qualsiasi cifrario con dimensione delloutput = dimensione dellinput e nessun input di dati debole nel cifrario core.
• questa risposta è obsoleta perché non è ciò che fa TLS oggi.

Penso che un aspetto di questo confronto sia stato trascurato. user185 si è avvicinato ma non ci è riuscito. Sono daccordo che si tratta di mele e arance e ritengo un confronto migliore tra mele e mele per essere HTTPS e SSH. HTTPS e SSH utilizzano diversi livelli del modello OSI e quindi crittografano i dati a diversi volte nella trasmissione. Quindi le vere domande da porre sarebbero sulla falsariga di quando questi dati vengono crittografati e non crittografati durante la trasmissione. Questo rivelerà le potenziali superfici di attacco. Con HTTPS, una volta che il pacchetto viene ricevuto da un dispositivo in la rete di destinazione (Web Server, Border Router, load balancer, ecc …) non è crittografata e trascorre il resto del suo viaggio in testo normale. Molti sostengono che questo non è un grosso problema poiché il traffico è interno a questa volta, ma se il payload contiene dati sensibili, viene archiviato non crittografato nei file di registro di ogni dispositivo di rete attraverso cui passa fino a quando non raggiunge la destinazione finale. Con SSH, in genere, viene specificato il dispositivo di destinazione e il la trasmissione è crittografata finché non raggiunge questo dispositivo. Esistono modi per crittografare nuovamente i dati HTTPS, ma si tratta di passaggi aggiuntivi che la maggior parte dimentica di eseguire quando implementa una soluzione HTTPS nel proprio ambiente.

ssh è come una chiave (privata) e la serratura (pubblica)

ssl è come la porta e i mattoni.

ssl fornisce un collegamento sicuro tra due server di computer. ad esempio, il tuo e quello a cui ti connetti.

ssh è il modo in cui il computer che si connette può verificare se stesso e ottenere laccesso.

Commenti

• Non spieghi affatto il commento su ” porta e mattoni “. SSL ha anche chiavi pubbliche e private. SSL può essere utilizzato anche per lautenticazione del client. SSH fornisce anche un collegamento sicuro tra il client e il server.

SSL è un livello di protocollo che è astratto dal contenuto sottoposto a tunneling. SSH è una versione sicura della shell (SH), non è stata progettata per contenere uno strato astratto sottostante, è stata progettata specificamente per trasportare il traffico della shell. Quindi, sebbene le operazioni crittografiche siano utilizzate in entrambe, e queste operazioni crittografiche potrebbero anche essere le stesse, lo scopo e quindi il design complessivo sono abbastanza diversi.

Tieni presente che ci sono differenze specifiche (come è stato citato sopra ), ma la maggior parte se non tutte queste differenze sono radicate nello scopo dei diversi protocolli.

Commenti

• -1 Assumi erroneamente quellOP sta confrontando SSL con il programma unix ssh (1) . SSH è in realtà un altro protocollo che fornisce sicurezza a livello di trasporto, che ha disposizioni speciali per shell remote ed esecuzione remota.

Se stai davvero cercando SSH vs SSL (TLS), la risposta è SSH.

Per una ragione per cui SSH vince su SSL è il modo in cui esegue lautenticazione. Per questo motivo, quando si utilizza FTP, utilizzare il protocollo SSH (SFTP) anziché FTPS (FTP su SSL).

SSH viene utilizzato nelle reti aziendali per:

• fornire accesso sicuro per utenti e processi automatizzati
• trasferimenti di file interattivi e automatici
• invio di comandi remoti

fonte: https://www.ssh.com/ssh/protocol/#sec-Typical-uses-of-the-SSH-protocol

Commenti

• ” Per una ragione SSH vince su SSL è il modo in cui esegue lautenticazione ” Hai una fonte o una spiegazione per questa affermazione?
• In SSH si hanno due opzioni per connettere il server. Con lopzione di autenticazione basata su chiave, sarà prima necessario generare in anticipo una chiave privata SSH e una chiave pubblica. Che non è molto lavoro aggiuntivo. Questo è anche considerato le migliori pratiche di sicurezza. SSL ha così tante versioni lultima è TLS1.2.Il che significa che ‘ non è ancora così sicuro, ma sta per migliorare.
• TLS ha anche certificati lato client. Non spieghi perché SSH ” vince “.
• Se intendi copiare / incollare da qualche parte, assicurati di citare la tua fonte.
• ” SSL ha così tante versioni ” Quindi, 6 versioni è ” così tanti “? OpenSSH è nella versione 7.7. ” Il che significa che ‘ non è ancora così sicuro, ma sta per migliorare. ” La tua logica non ha senso qui.

Il problema è duplice, ” Non è solo la forza e la debolezza della crittografia, ma è anche la facilità e la comodità della consegna. Quindi, dal punto di vista aziendale, SSL / TLS è più conveniente e più semplice perché richiede solo un browser e un certificato pubblico o privato.

E SSH richiede lapplicazione o il thin client installato per utilizzarlo. Questo è più un problema dal punto di vista e dal supporto del client Internet dellutente.