it-swarm.dev

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

Qual è la differenza tra SSH e SSL? Quale è più sicuro, se puoi confrontarli insieme?
Quali sono le vulnerabilità più potenziali?

212
Am1rr3zA

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 possono soffrire dello stesso tipo di attacchi, quindi dovrebbero fornire una sicurezza simile (cioè una buona sicurezza) supponendo che siano entrambi correttamente implementati. Che entrambi esistano è una specie di NIH sindrome: gli sviluppatori SSH avrebbero dovuto riutilizzare SSL per la parte del tunnel (il protocollo SSL è abbastanza flessibile da accogliere molte varianti, incluso il non utilizzo dei certificati).

Differiscono sulle 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 il suo 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 dei terminali. ..) mentre non esiste nulla di simile in SSL o, più precisamente, quando tali elementi vengono utilizzati in SSL non vengono considerati parte di SSL (ad esempio, quando si esegue l'autenticazione HTTP basata su password in un tunnel SSL, noi dire 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 di SSL. Potresti anche prendere HTTPS e sostituire la cosa SSL con SSH con trasporto dati e un hook per estrarre la chiave pubblica del server dal suo certificato. Non vi è alcuna impossibilità scientifica e, se eseguita 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 a quali strumenti sono stati storicamente forniti con le implementazioni di quei protocolli, non a causa di un differenza relativa alla sicurezza. E chiunque implementi SSL o SSH sarebbe ben consigliato di esaminare che tipo di attacchi sono stati provati su entrambi i protocolli.

199
Thomas Pornin

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 ha una capacità simile a quella SSL, quindi "più sicura" dipende da ciò che richiede il tuo specifico modello di minaccia e se le implementazioni di ciascun indirizzo affrontano 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 deve solo autenticare le due interfacce di connessione che SSH può anche fare). Nell'arte UTF-8:

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

Per quanto riguarda la questione di cui vi sono più potenziali attacchi, sembra chiaro che SSH abbia 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.

87
user185

Da un punto di vista crittografico rigoroso, entrambi forniscono una 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 chiaro per aggiungere integrità. Questo non è dimostrato di essere 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 migliore, poiché con alcune modalità di cifratura a blocchi parti del MAC possono essere indovinabili e rivelare qualcosa sulla cifra. Ciò ha comportato vulnerabilità in TLS 1.0 (attacco BEAST).

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

12
Halberdier

Penso che ci sia un aspetto di questo confronto che è stato trascurato. user185 si è avvicinato ma non ci è riuscito. Concordo sul fatto che si tratta di mele e arance e sento un confronto migliore tra mele e mele rispetto a 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, router di frontiera, bilanciamento del carico, ecc ...) non è crittografato e trascorre il resto del viaggio in testo semplice. 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 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 non raggiunge questo dispositivo. Esistono modi per ricrittografare i dati HTTPS, ma si tratta di passaggi aggiuntivi che la maggior parte dimentica di adottare durante l'implementazione di una soluzione HTTPS nel proprio ambiente.

3
Sam Moore

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 è il modo in cui il computer connesso può verificare se stesso e ottenere l'accesso.

2
datsusarachris

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

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

Non tutti gli utenti sono brillanti, specialmente quelli tecnologici.

i miei 2 centesimi.

0

SSL è un livello di protocollo che viene sottratto dal contenuto sottoposto a tunnel. SSH è una versione sicura di Shell (SH), non è stata progettata per contenere un livello astratto al di sotto di essa, è stata progettata specificamente per trasportare il traffico Shell. Quindi, sebbene le operazioni di crittografia siano utilizzate in entrambi, e tali operazioni di crittografia potrebbero anche essere le stesse, lo scopo e quindi il design complessivo è piuttosto diverso.

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

0
Gobbly