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

SSL e SSH forniscono entrambi gli elementi crittografici per costruire un tunnel per il trasporto di dati riservati con integrità controllata. Per quella parte, usano tecniche simili e potrebbero soffrire dello stesso tipo di attacchi, quindi dovrebbero fornire una sicurezza simile (cioè una buona sicurezza) assumendo che siano entrambi correttamente implementati. Che entrambi esistano è una specie di NIH sindrome: gli sviluppatori SSH dovrebbero aver riutilizzato SSL per la parte del tunnel (il protocollo SSL è abbastanza flessibile da adattarsi a molte varianti, incluso non usare i certificati).

Si differenziano per le cose che circondano il tunnel. SSL utilizza tradizionalmente i certificati X.509 per annunciare chiavi pubbliche server e client; SSH ha il proprio formato. Inoltre, SSH viene fornito con un set di protocolli per ciò che va all'interno del tunnel (multiplexing di diversi trasferimenti, esecuzione dell'autenticazione basata su password all'interno del tunnel, gestione dei terminali ...) mentre non c'è nulla di simile in SSL , o, più esattamente, quando tali cose vengono utilizzate in SSL non sono considerate parte di SSL (ad esempio, quando si esegue l'autenticazione HTTP basata su password in un tunnel SSL, si dice che fa parte di "HTTPS", ma funziona davvero in un modo simile a quello che succede con SSH).

Concettualmente, potresti prendere SSH e sostituire la parte del 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 suo certificato. Non c'è alcuna 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 è dovuto agli strumenti storicamente forniti con le implementazioni di quei protocolli, non a causa di una differenza relativa alla sicurezza. E chiunque utilizzi SSL o SSH sarebbe bene informarsi su quale tipo di attacchi sono stati tentati su entrambi i protocolli.

Questo non è un paragone ragionevole da fare. SSL è un metodo generale per proteggere i dati trasportati su una rete, mentre SSH è un'applicazione di rete per l'accesso e la condivisione dei dati con un computer remoto.

La protezione del livello di trasporto in SSH ha una capacità simile a SSL, quindi "più sicuro" dipende da ciò che richiede il modello di minaccia specifico e se le implementazioni di ciascun indirizzo sono i problemi che stai cercando di affrontare.

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

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

Riguardo al problema di cui ci sono più potenziali attacchi contro, sembra chiaro che SSH abbia una superficie di attacco più grande. Ma questo è solo perché SSH ha un'intera applicazione incorporata: la superficie di attacco di SSL + qualsiasi altra applicazione tu debba fornire non può essere confrontata perché non abbiamo abbastanza informazioni.

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

SSH utilizza il cosiddetto Encrypt-and-MAC, ovvero il messaggio cifrato viene giustapposto a un codice di autenticazione del messaggio (MAC) del messaggio chiaro per aggiungere integrità. Non è dimostrato che questo sia sempre completamente sicuro (anche se nei 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é alcune modalità di cifratura a blocchi possono essere indovinate in parti del MAC e rivelare qualcosa sul codice. Ciò ha portato a vulnerabilità in TLS 1.0 (attacco BEAST).

Quindi hanno sia potenziali debolezze teoriche. Il metodo più efficace è Encrypt-then-MAC (aggiungi un MAC del messaggio cifrato), che è implementato, ad es., In ESP IPsec.

ssh è come una chiave (privata) e il lucchetto (pubblico)

ssl è come la porta e i mattoni.

ssl fornisce un collegamento sicuro tra i due server. Ad esempio, il tuo e quello a cui ti stai connettendo.

ssh è come il computer di connessione può verificare se stesso e ottenere l'accesso.

Il problema è duplice, non è solo la forza e la debolezza della crittografia. Ma è la facilità e la comodità della consegna. Quindi dal punto di vista aziendale SSL / TLS è più comodo e più semplice perché richiede solo un browser e un Cert pubblico o privato.

E SSH richiede l'applicazione o il thin client installato per usarlo. Questo è più un problema dal punto di vista e supporto del client Internet dell'utente.

Non tutti gli utenti sono brillanti, specialmente quelli con problemi tecnologici.

I miei 2 centesimi.

Penso che ci sia un aspetto di questo confronto che è stato trascurato. user185 si è avvicinato ma non ci è arrivato. Sono d'accordo che si tratta di mele e arance e ritengo che un confronto tra mele e mele sia HTTPS e SSH. HTTPS e SSH utilizzano diversi livelli del modello OSI e quindi crittografano i dati in momenti diversi della trasmissione. Quindi le domande reali che si dovrebbero porre sarebbero sulla falsariga di quando questi dati vengono crittografati e non criptati durante la trasmissione. Questo rivelerà le tue potenziali superfici d'attacco. Con HTTPS, una volta che il pacchetto viene ricevuto da un dispositivo nella rete di destinazione (Web Server, Border Router, bilanciamento del carico, ecc.) Non è crittografato e trascorre il resto del viaggio in testo normale. Molti sostengono che questo non è un grosso problema dal momento che il traffico è interno in questo momento, ma se il carico contiene dati sensibili, viene memorizzato non crittografato nei file di registro di ogni dispositivo di rete che attraversa fino a quando non arriva al suo destinazione finale. Con SSH, in genere, viene specificato il dispositivo di destinazione e la trasmissione viene crittografata fino a quando raggiunge questo dispositivo. Esistono modi per ricodificare i dati HTTPS, ma questi sono passaggi aggiuntivi che la maggior parte dimentica di eseguire quando si implementa una soluzione HTTPS nel proprio ambiente.

SSL è un livello di protocollo che viene estratto dal contenuto sottoposto a tunnel. SSH è una versione sicura di shell (SH), non è stata progettata per contenere un livello astratto al di sotto di esso, è stata progettata specificamente per trasportare il traffico della shell. Quindi, anche se le operazioni di crittografia sono utilizzate in entrambi e quelle operazioni di crittografia potrebbero essere uguali, lo scopo, e quindi la progettazione generale è molto diversa.

Tieni presente che esistono differenze specifiche (come già detto), ma la maggior parte se non tutte queste differenze sono radicate nello scopo dei diversi protocolli.

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

Per una ragione per cui SSH vince su SSL è il modo in cui esegue l'autenticazione. Per questo motivo, quando si utilizza FTP, utilizzare il protocollo SSH (SFTP) piuttosto che FTPS (FTP su SSL).

SSH is used in corporate networks for:

• providing secure access for users and automated processes
• interactive and automated file transfers
• issuing remote commands

source: link