SSL e SSH forniscono entrambi gli elementi crittografici per costruire un tunnel per il trasporto di dati riservati 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 entrambi esistano è una sorta di sindrome di NIH: gli sviluppatori SSH avrebbero dovuto riutilizzare SSL per la parte tunnel (il protocollo SSL è abbastanza flessibile da adattarsi a molte varianti, incluso il non utilizzo di certificati).

Differiscono nelle 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 all'interno del tunnel (multiplexing di diversi trasferimenti, esecuzione dell'autenticazione basata su password all'interno 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 l'autenticazione 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 suo 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 è a causa di quali strumenti storicamente venivano forniti con le implementazioni di quei protocolli, no a causa di una differenza relativa alla sicurezza. E chiunque implementa SSL o SSH farebbe bene a controllare che tipo di attacchi sono stati tentati su entrambi i protocolli.

Questo non è un confronto 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 di 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 ciascun indirizzo 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 ha solo bisogno di autenticare le due interfacce di connessione che anche SSH può fare). Nella grafica UTF-8:

  SSL SSH + ------------- + + ----------------- + | Niente | | RFC4254 | Collegamento multiplexing + ------------- + + ----------------- + | Niente | | RFC4252 | Autenticazione utente + ------------- + + ----------------- + | RFC5246 | | RFC4253 | Trasporto dati crittografato + ------------- + + ----------------- +  

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

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

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.

Penso che un aspetto di questo confronto sia stato trascurato. user185 si è avvicinato ma non ci è riuscito. Sono d'accordo che queste sono mele e arance e sento 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 in momenti diversi della trasmissione. Quindi le vere domande che ci si dovrebbe porre sarebbero sulla falsariga di quando questi dati vengono crittografati e non crittografati durante la trasmissione. Questo rivelerà le tue potenziali superfici di attacco. Con HTTPS, una volta che il pacchetto viene ricevuto da un dispositivo nella rete di destinazione (Web Server, Border Router, load balancer, ecc ...) non viene crittografato e trascorre il resto del suo viaggio in testo normale. Molti sostengono che questo non è un grosso problema poiché il traffico è interno in questo momento, 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 arriva al suo destinazione finale. Con SSH, in genere, viene specificato il dispositivo di destinazione e la trasmissione viene 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 durante l'implementazione di 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 i due server del 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 l'accesso.

SSL è un livello di protocollo 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 tali 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.

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ù conveniente e più semplice perché richiede solo un browser e un certificato pubblico o privato.

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

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 l'autenticazione. 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 agli utenti e processi automatizzati
• trasferimenti di file interattivi e automatizzati
• emissione di comandi remoti

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