Riepilogo:

In questo articolo, esploreremo le differenze tra i protocolli SSL e SSH. Discuteremo di punti chiave su come funzionano, il concetto di crittografia, crittografia simmetrica e asimmetrica, scambio chiave, firme digitali e autorità di certificazione. Spiegheremo anche l’uso di hash crittografici nei protocolli sicuri.

Punti chiave:

1. SSL utilizza l’autenticazione basata sul certificato, mentre SSH si basa su un processo di autenticazione nome utente/password.
2. La crittografia è il processo di codifica per mantenerle sicure dall’accesso non autorizzato.
3. La crittografia a chiave simmetrica utilizza la stessa chiave sia per la crittografia che per la decrittografia.
4. La crittografia delle chiavi asimmetriche, nota anche come crittografia della chiave pubblica, utilizza una coppia di chiave composta da una chiave privata e una chiave pubblica.
5. La crittografia della chiave pubblica consente uno scambio chiave sicuro e messaggi sicuri tra le parti.
6. La crittografia simmetrica è più veloce della crittografia delle chiavi pubbliche, quindi viene spesso utilizzata per la crittografia dei dati sfusi.
7. Le firme digitali utilizzano la crittografia delle chiavi pubbliche per verificare l’autenticità e l’integrità di un messaggio.
8. Le autorità del certificato assicurano l’associazione delle chiavi pubbliche con i loro legittimi proprietari.
9. Gli algoritmi di hash crittografici vengono utilizzati per i controlli di integrità dei dati in protocolli sicuri.
10. SSL/TLS e SSH sono protocolli di rete sicuri ampiamente utilizzati per proteggere i dati durante la trasmissione.

Domande:

1. In che modo SSL differisce da SSH in termini di autenticazione?

SSL utilizza l’autenticazione basata sul certificato, mentre SSH si basa su un processo di autenticazione nome utente/password.

2. Cos’è la crittografia e qual è il suo obiettivo?

La crittografia è il processo di codifica per mantenerle sicure dall’accesso non autorizzato. Il suo obiettivo è garantire la riservatezza e l’integrità dei dati.

3. Cos’è la crittografia a chiave simmetrica?

La crittografia a chiave simmetrica utilizza la stessa chiave sia per la crittografia che per la decrittografia dei dati.

4. Come funziona la crittografia delle chiavi pubbliche?

La crittografia della chiave pubblica, nota anche come crittografia asimmetrica, utilizza una coppia di chiave costituita da una chiave privata e una chiave pubblica. La chiave pubblica viene utilizzata per la crittografia, mentre la chiave privata viene utilizzata per la decryption.

5. Qual è il vantaggio della crittografia delle chiavi pubbliche?

La crittografia della chiave pubblica consente una messaggistica sicura e lo scambio chiave tra le parti senza la necessità di condividere una chiave segreta.

6. Perché la crittografia simmetrica è utilizzata per la crittografia dei dati sfusi?

La crittografia simmetrica è più veloce della crittografia delle chiavi pubbliche, rendendola più efficiente per la crittografia di grandi quantità di dati.

7. Quali sono le firme digitali?

Le firme digitali utilizzano la crittografia delle chiavi pubbliche per verificare l’autenticità e l’integrità di un messaggio. Forniscono garanzia che un messaggio non è stato manomesso ed è stato effettivamente firmato dal mittente rivendicato.

8. Qual è il ruolo delle autorità di certificazione?

Le autorità del certificato assicurano l’associazione delle chiavi pubbliche con i loro legittimi proprietari. Emettono certificati digitali che contengono informazioni chiave pubbliche e verificano l’identità del titolare del certificato.

9. A cosa sono usati gli algoritmi hash crittografici?

Gli algoritmi di hash crittografici vengono utilizzati per i controlli di integrità dei dati in protocolli sicuri. Generano un valore di hash unico per un determinato input, consentendo al destinatario di verificare se i dati sono stati manomessi.

10. Per cosa sono usati SSL/TLS e SSH?

SSL/TLS e SSH sono protocolli di rete sicuri ampiamente utilizzati per proteggere i dati durante la trasmissione. SSL/TLS è comunemente utilizzato per le comunicazioni Web sicure, mentre SSH viene utilizzato per l’accesso remoto sicuro e i trasferimenti di file.

SSL vs SSH-Un confronto non così tecnologico

4. SSH utilizza un processo di autenticazione nome utente/password per stabilire una connessione sicura, mentre SSL non lo considera.

Come funzionano SSL, TLS, SSH

Questo articolo esplora come funzionano i protocolli di rete sicuri. Spiegherà concetti chiave come crittografia, hash crittografici e crittografia delle chiavi pubbliche. Verranno esaminati i due protocolli di rete sicuri più popolari, SSL/TLS e SSH.

Cos’è la crittografia?

La crittografia è il processo di codifica delle informazioni in modo tale che solo le parti autorizzate a leggere le informazioni crittografate siano in grado di leggerle. Il suo obiettivo è quello di mantenere le informazioni sicure dagli intercedroper o segreti.

Le informazioni non crittografate sono note come testo semplice, mentre le informazioni crittografate sono chiamate cifro-text. Per ottenere il testo semplice dal testo cifrario, è richiesta una chiave di crittografia e solo le parti autorizzate hanno una copia della chiave di crittografia. Il processo di codifica è noto come algoritmo di crittografia. L’algoritmo è progettato in modo tale che decritting il testo semplice senza la chiave non sia praticamente possibile.

Esistono due tipi principali di crittografia: crittografia a chiave simmetrica e asimmetrica o crittografia a chiave pubblica.

Crittografia a chiave simmetrica

Nella crittografia simmetrica, la chiave utilizzata per crittografare il testo semplice e la chiave utilizzata per decrittografare il testo cifrato è la stessa. Ciò significa che le due parti (il mittente e il ricevitore) devono condividere la chiave (che a sua volta deve essere mantenuta segreta). Naturalmente, capire come condividere la chiave in modo sicuro è un’altra istanza di ciò per cui la crittografia è progettata: condividere in modo sicuro le informazioni. Allora come le due parti condividono la loro chiave segreta? Fortunatamente, questo può essere ottenuto mediante crittografia asimmetrica (o chiave pubblica), spiegata di seguito. I popolari algoritmi a chiave simmetrica includono eventi avversi, pompini, rc4 e 3des.

Crittografia delle chiavi pubbliche

La crittografia della chiave pubblica si basa su un set speciale di algoritmi che richiedono due chiavi separate. Una chiave, nota come chiave privata, è mantenuta segreta e l’altra chiave, la chiave pubblica, è ampiamente disponibile. Insieme sono conosciuti come la coppia chiave. In generale, chiunque può utilizzare la chiave pubblica per la crittografia, ma solo il proprietario della chiave privata può decrittarla.

Il vantaggio di un sistema di crittografia a chiave pubblica è questo: segreto (i.e. crittografato) i messaggi possono essere inviati a chiunque abbia pubblicato la propria chiave pubblica e solo il destinatario sarà in grado di decrittografare il messaggio. Quindi fintanto che la loro chiave pubblica ci si può fidare di essere la loro (un avvertimento importante!), un sistema sicuro per lo scambio di messaggi segreti può essere facilmente impostato. Ciascuna parte può pubblicare la propria chiave pubblica e inviare messaggi segreti all’altra usando l’altra’S Chiave pubblica. Usano la loro chiave privata per decrittografare i messaggi che ricevono.

Ma non lo fa’T Pubblicare la chiave pubblica rende i messaggi crittografati più vulnerabili alla decrittografia non autorizzata? No, non è praticamente possibile derivare la chiave privata di una coppia di chiave dalla chiave pubblica e, senza la chiave privata, il testo cifrato non può essere decrittografato. Quindi la pubblicazione della chiave pubblica non rende più semplice la decrittografia dei messaggi crittografati dalla chiave pubblica.

RSA e Diffie -Hellman erano i primi algoritmi chiave pubblici. Per molto tempo si pensava che fossero stati inventati nel 1976/1977, ma quando la ricerca segreta GCHQ fu declassificata nel 1997, si scoprì che erano stati concepiti in modo indipendente alcuni anni prima. Elgamal e DSS sono altri noti algoritmi chiave pubblici.
Esistono numerosi usi importanti della crittografia delle chiavi pubbliche descritte di seguito.

Distribuzione chiave

La crittografia simmetrica utilizza una singola chiave segreta che entrambe le parti richiedono e garantire che questa chiave segreta sia comunicata in modo sicuro all’altra parte è difficile. Questo è noto come problema di distribuzione chiave.

La crittografia delle chiavi pubbliche è ideale per risolvere questo problema. La parte ricevente, che richiede il mittente’S Secret Simmetric Key, genera una coppia chiave e pubblica la chiave pubblica. Il mittente utilizza il ricevitore’S Chiave pubblica per crittografare la loro chiave simmetrica e la invia al ricevitore. Ora, sia il mittente che il ricevitore hanno la stessa chiave simmetrica segreta e nessun altro lo fa in quanto non è mai stato trasmesso come un testo chiaro. Questo è spesso noto come lo scambio chiave.

Una domanda ovvia è chiedere perché non utilizzare la crittografia delle chiavi pubbliche per tutto ed evitare di dover inviare del tutto una chiave segreta? Si scopre che la crittografia simmetrica è ordini di grandezza più velocemente alla crittografia e alla decrittografia. Quindi è molto più efficiente utilizzare la crittografia delle chiavi pubbliche per distribuire la chiave simmetrica, quindi utilizzare la crittografia simmetrica.

Firme digitali

La crittografia della chiave pubblica è un componente importante delle firme digitali. Un messaggio può essere firmato (crittografato) con un utente’s Private Key e chiunque può usare la propria chiave pubblica per verificare che l’utente abbia firmato il messaggio e che il messaggio non sia stato manomesso. Questa applicazione della crittografia delle chiavi pubbliche è spiegata in modo più dettagliato nella sezione successiva, hash crittografici.

Autorità di certificazione

Un requisito fondamentale per un sistema che utilizza la crittografia a chiave pubblica è fornire un modo per associare in modo affidabile le chiavi pubbliche ai loro proprietari. C’è un valore limitato nel poter usare qualcuno’s chiave pubblica per crittografare un messaggio destinato a loro se può’si danno determinato che è davvero la loro chiave pubblica. Questo è ciò a cui sono le autorità di certificazione, ed sia loro che i certificati sono spiegati di seguito.

Hash crittografici

Gli algoritmi di hash crittografici sono importanti funzioni matematiche utilizzate ampiamente nel software, in particolare in protocolli sicuri come SSL/TLS e SSH.

Un blocco di dati viene passato attraverso un algoritmo di hash per produrre un valore di hash molto più piccolo, noto come Message Digest, o semplicemente il digest. Lo stesso messaggio si tradurrà sempre nello stesso digest. Messaggi diversi producono digest diversi.

Una caratteristica importante degli algoritmi hash è che, dato un particolare digest, è estremamente difficile generare un messaggio che lo produrrà. Sono “Senso Unico” Algoritmi: il digest di un messaggio è facile da calcolare, ma un messaggio può’essere dedotto dal digest. È matematicamente possibile avere due messaggi diversi producono lo stesso digest – noto come collisione – ma per gli algoritmi di buon hash questo è estremamente improbabile.

Gli algoritmi di hash popolari includono MD5 e SHA-1, sebbene questi siano ora gradualmente eliminati a favore di algoritmi più forti come SHA-2.

Gli algoritmi hash vengono utilizzati per molti scopi, come verificare l’integrità di dati o file, verifica della password e costruzione di altre funzioni crittografiche come i codici di autenticazione dei messaggi (Mac) e le firme digitali.

Firme digitali

Una firma scritta dimostra che un documento è stato creato da un autore noto e li rappresenta accuratamente. Una firma digitale è simile: garantisce che il messaggio sia stato creato da un mittente noto (autenticazione) e che il messaggio non sia stato manomesso in transito (integrità).

Per firmare un messaggio richiede due fasi. In primo luogo, viene calcolato il Digest del messaggio, producendo un hash unico che è in genere molto più piccolo del messaggio. Successivamente, il digest viene crittografato usando il messaggio firmatario’S Chiave privata. Questa è la firma digitale del messaggio.

Per verificare il firmatario di un messaggio richiede anche due fasi. In primo luogo, il firmatario’S Key Public (che è ampiamente disponibile) viene utilizzata per decrittografare la firma digitale, producendo il Digest del messaggio. Quindi il digest del messaggio del messaggio viene calcolato e confrontato con il digest decrittografato. Se il messaggio non è stato manomesso, i digest dovrebbero essere identici. E perché il firmatario’La chiave pubblica è stata utilizzata per decrittografare la firma, il firmatario’la chiave privata deve essere stata usata per crittografarla.

Perché utilizzare il messaggio’d digest affatto? Perché non crittografare il messaggio con il firmatario’s Private Key e usa il messaggio crittografato come firma? Mentre questo funzionerebbe sicuramente, è poco pratico: raddoppierebbe le dimensioni del messaggio quando la firma è inclusa. Il digest è molto piccolo e di dimensioni fisse, quindi la crittografia del digest produce una firma molto più piccola.

Codici di autenticazione dei messaggi (Mac)

Un codice di autenticazione del messaggio, o Mac, è una piccola informazione allegata a un messaggio che può verificare che il messaggio non sia stato manomesso e autentica chi lo ha creato.

Un tipo speciale di Mac è l’HMAC, che è costruito usando un hash crittografico e una chiave segreta. La chiave segreta è imbottita e concatenata con il messaggio e il digest, o hash, viene calcolato. Questo digest viene quindi nuovamente concatenato con la chiave segreta imbottita per produrre il valore HMAC. È impossibile per un aggressore produrre lo stesso HMAC senza avere la chiave segreta.

Il mittente e il ricevitore condividono entrambi la chiave segreta. Quando il ricevitore riceve un messaggio, calcolano l’HMAC e lo confrontano con l’HMAC fornito con il messaggio. Se gli HMAC si abbinano, solo qualcuno che possiede la chiave segreta avrebbe potuto produrre il messaggio. La chiave segreta stessa non viene mai trasmessa.

Password, hash password e sali

Gli hash crittografici sono estremamente utili per i sistemi che richiedono una verifica della password. È un rischio per la sicurezza ingiustificabile per archiviare l’utente’S password, anche se sono crittografate. Invece, viene archiviato il digest di ogni password. Quando l’utente fornisce la password, viene hash e confrontato con il digest che viene archiviato. Ciò è preferibile perché la password non può essere recuperata dal suo hash.

Uno svantaggio con questo metodo è che se gli utenti hanno la stessa password, avranno lo stesso valore hash. Le tabelle di digest pre-calcolate per password comuni possono essere utilizzate per attaccare un sistema se è possibile ottenere il file contenente i digest. Questi tavoli sono noti come tavoli arcobaleno.

Per questo motivo un sale-un valore casuale e non segreto-è concatenato con la password prima che venga calcolato il digest. Poiché ogni utente ha un sale diverso, non è possibile utilizzare tabelle pre-calcolate: dovrebbe esserci una tabella per ogni possibile valore di sale. Perché i sali siano efficaci, devono essere il più casuali possibile e di dimensioni adeguate – preferibilmente almeno 32 bit.

Quali sono i certificati?

Durante la discussione della crittografia delle chiavi pubbliche, è stato spiegato che deve esserci un modo per associare in modo affidabile le chiavi pubbliche ai loro proprietari. Usando qualcuno’S Chiave pubblica per crittografare un messaggio destinato a loro richiede di sapere che è davvero la loro chiave pubblica.

Le autorità del certificato sono la soluzione a questo problema. Un’autorità di certificazione (a “circa”) è un’organizzazione che emette certificati digitali. Un certificato digitale è un documento elettronico che certifica la proprietà di una chiave pubblica.

Un certificato digitale contiene un numero di campi: la chiave pubblica di cui sta certificando la proprietà, il nome del proprietario (l’oggetto), il nome dell’emittente (i.e. la ca), le date di inizio e fine e l’emittente’S Digital Firma. La firma digitale verifica che la CA abbia effettivamente emesso il certificato. Le firme digitali sono spiegate in modo più dettagliato qui.

Affinché il sistema funzioni, l’autorità del certificato deve essere una terza parte di fiducia. Ci sono solo un piccolo numero di CA, tra cui Comodo, Symantec e GoDaddy. CAS emette i propri certificati contenenti le loro chiavi pubbliche, che sono noti come certificati di root di fiducia.

Per ottenere un certificato da una CA, un’organizzazione deve fornire alla CA la sua chiave pubblica e una documentazione sufficiente per stabilire che si tratta di un’organizzazione genuina. La CA verifica questi dettagli prima di emettere il certificato.

Convalida del sito Web

L’uso più comune dei certificati è di convalidare i siti Web HTTPS (i.e. Siti Web che hanno un URL che iniziano con https: //). Quando un browser Web si collega a un sito come Amazon, l’utente deve sapere che il sito può essere attendibile, io.e. che l’URL www.Amazon.com effettivamente si riferisce a un sito controllato dalla società chiamata Amazon. Questo viene fatto incorporando il nome di dominio del sito Web nel certificato’s campo soggetto quando si applica a una CA per il certificato. La CA assicura che il nome di dominio sia controllato dall’organizzazione prima di emettere il certificato. Il browser Web ha il proprio elenco di certificati root e quando si collega al sito, il sito’Il certificato S viene inviato dal server Web. Utilizzando il certificato CA, verifica che il certificato inviato dal server Web sia stato emesso da uno degli IT di CA riconosce e che il nome di dominio corrisponda al nome di dominio nel certificato.

Perché questo assegno è importante? Finché Amazon possiede il suo nome di dominio (cosa che sappiamo che fa), perché abbiamo bisogno del browser per controllare il certificato?

Sfortunatamente, è possibile che il software dannoso impersonasse un’altra macchina. Quando un URL viene inserito in un browser Web, come https: // www.Amazon.com, deve essere tradotto in un indirizzo IP, E.G. 192.168.1.64. Queste cifre sono ciò che il browser utilizza per connettersi al server web. Il processo di traduzione è chiamato una ricerca DNS e implica il controllo del registro pubblico dei nomi di dominio per ottenere l’indirizzo IP che Amazon ha deciso di utilizzare. Il software dannoso può compromettere le ricerche DNS, restituendo l’indirizzo IP sbagliato, che potrebbe essere per un sito Web falso che sembra simile ad Amazon ed è progettato per ottenere i dettagli della carta di credito.

È qui che il controllo del certificato dimostra il suo valore: il sito Web falso può’t Restituire il certificato autentico e il browser Web segnalerà che il certificato restituito non è registrato nel nome di dominio utilizzato nell’URL. Nella maggior parte dei browser il sito autentico visualizzerà un simbolo del lucchetto e facendo clic su di esso con un mouse mostrerà il sito’S verificata identità, come con Chrome, sotto.

Questo è il motivo per cui è importante utilizzare gli URL che iniziano con HTTPS anziché HTTP – tramite il certificato, il browser può fornire la certezza che il sito è connesso è un proprietario verificato del dominio.

Come funziona SSL/TLS?

Storia

Secure Sockets Layer (SSL) è un protocollo crittografico progettato per garantire le comunicazioni su reti TCP/IP. SSL è stato sviluppato da Netscape all’inizio del 1990’s, ma vari difetti di sicurezza significavano che non lo era’t fino a SSL 3.0 è stato rilasciato nel 1996 che SSL è diventato popolare.

Fu anche durante questo periodo che un’implementazione open source di SSL chiamata SSLEAY fu resa disponibile da Eric Young, il che ha contribuito a garantire la sua diffusa adozione su Internet. Anche il server Web Apache stava guadagnando popolarità e Ben Laurie di Apache Fame ha usato SLeay per produrre Apache-SSL, uno dei primi server Web sicuri disponibili gratuitamente.

SSL è diventato la sicurezza del livello di trasporto (TLS) con la pubblicazione del TLS 1.0 standard nel 1999, seguito da TLS 1.1 e TLS 1.2, la versione più recente. Tutte le versioni di TLS sono in uso diffuso ed è solo di recente quel supporto per SSL 3.0 è stato sospeso in risposta alla vulnerabilità del barboncino. Per semplicità, noi’LL Fare riferimento a SSL/TLS come TLS per il resto di questo articolo.

Panoramica

TLS ha lo scopo di fornire connessioni sicure tra un client (E.G. un browser Web) e un server (E.G. un server Web) crittografando tutti i dati che vengono passati tra loro.

Le connessioni di rete ordinarie non sono crittografate, quindi chiunque abbia accesso alla rete può annusare pacchetti, leggere nomi utente, password, dettagli della carta di credito e altri dati riservati inviati in rete-una situazione ovviamente inaccettabile per qualsiasi tipo di e-commerce basato su Internet.

All’inizio di questo libro bianco abbiamo discusso di come funziona la crittografia, tra cui la crittografia e i certificati delle chiavi pubbliche. TLS utilizza la crittografia delle chiavi pubbliche per verificare le parti nella sessione crittografata e per fornire un modo per il client e il server di concordare una chiave di crittografia simmetrica condivisa.

La stretta di mano SSL

IL “stretta di mano” è la parte più critica di SSL/TLS, poiché è qui che vengono stabiliti i parametri importanti per la connessione. I vari passaggi nella stretta di mano sono descritti di seguito.
Protocolli di rete sicuri 12

Passaggio 1 – Cliente ciao

Dopo aver stabilito una connessione TCP/IP, il client invia un messaggio ClientHello al server. Questo afferma la versione massima TLS che il client è disposto a supportare, un numero casuale, l’elenco delle suite di cifri supportate in ordine di preferenza e gli algoritmi di compressione. Le suite di cifra sono identificatori per un gruppo di algoritmi crittografici che vengono utilizzati insieme. Ad esempio, TLS_RSA_WITH_AES_128_CBC_SHA significa che il server’La chiave pubblica S RSA deve essere utilizzata e l’algoritmo di crittografia è a 128 bit eventi avversi. L’algoritmo dei codici di autenticazione del messaggio (MAC) è HMAC/SHA-1.

Il ClientHello viene inviato in ClearText, quindi chiunque sia in grado di intercettare i pacchetti di rete può leggerlo.

Passaggio 2 – server ciao

Il server risponde al ClientHello con un messaggio ServerHello. Dice al client la versione TLS da utilizzare, insieme all’algoritmo della suite e di compressione cifera. Il serverhello fornisce anche un numero casuale generato dal server e un identificatore di sessione. Il ServerHello viene anche inviato in ClearText.

Immediatamente dopo aver inviato il suo serverhello, il server invia il suo certificato, contenente la sua chiave pubblica, al client. Questo è seguito da un messaggio Opzionale ServerKeyExchange che contiene eventuali valori richiesti aggiuntivi per lo scambio chiave.

Se il server è configurato per richiedere al client di identificarsi con un certificato client, il server lo chiede a questo punto nella handshake tramite il messaggio di certificazione opzionale.

Infine, il server invia al client un messaggio ServerHelloDone, ancora in ClearText.

Passaggio 3: verifica i certificati del server

In genere, il client ha una cache di certificati o certificati di root CA con cui può verificare che il server’Il certificato S è autentico (e registrato sul server’S Indirizzo IP). Se il server’Il certificato S non è noto, il cliente può dare comunque la possibilità di accettare il certificato (che è potenzialmente pericoloso) o può interrompere la connessione. Questo messaggio viene inviato in ClearText.

Passaggio 4 – Risposta del cliente

Se il server ha richiesto un certificato dal client, il client invia il suo certificato, seguito dal messaggio ClientKeyExchange.

Per il messaggio ClientKeyExchange, il client genera quello che viene chiamato Premaster Secret, composto da 48 byte. Questo segreto viene inviato al server come parte di questo messaggio, ma è crittografato con il server’S Chiave pubblica (ottenuta dal server’certificato S) in modo che solo il server possa decrittarlo con la sua chiave privata (poiché i messaggi vengono ancora inviati come testo normale).

Una volta che il client e il server condividono il segreto Premaster, ciascuno lo usano in combinazione con entrambi i valori casuali che sono stati scambiati in precedenza per produrre il segreto master e successivamente le chiavi di sessione – le chiavi simmetriche utilizzate per crittografare e decrittografare i dati nella successiva sessione TLS.

Il messaggio ChangeCipherspec viene inviato dopo il messaggio ClientKeyExchange. Questo messaggio indica al server che tutti i messaggi successivi verranno crittografati utilizzando le chiavi di sessione appena create. È seguito dal messaggio finito, il primo ad essere crittografato. Il messaggio finito è un hash dell’intera stretta di mano finora che consente al server di verificare che questo fosse il client che ha comunicato con il server durante la stretta di mano.

Passaggio 5: verifica il certificato client

Se il server ha richiesto il certificato del client, viene verificato per assicurarsi che sia corretto.

Passaggio 6 – Server finito

Il server risponde al messaggio finito dal client con un messaggio ChangeCipherspec, seguito da un messaggio finito crittografato, che è di nuovo un hash della stretta di mano fino a questo punto. Ciò consente al client di verificare che questo sia lo stesso server che ha comunicato con esso durante la stretta di mano.

Passaggio 7 – Comunicazione sicura stabilita

A questo punto, tutti i messaggi sono crittografati e quindi è stato istituito un canale di comunicazione sicuro attraverso la rete tra client e server.

Record e avvisi

Come vengono confezionati i dati e inviati attraverso la rete dopo il completamento della mano di mano? Ciò coinvolge il protocollo record e il protocollo di allerta.

Protocollo record

Il protocollo record è responsabile della compressione, della crittografia e della verifica dei dati. Tutti i dati da trasmettere sono divisi in record. Ogni record è costituito da un byte di intestazione, seguito dalla versione del protocollo, dalla durata dei dati da inviare (noto come payload) e dal carico utile stesso. In primo luogo, i dati vengono compressi se la compressione è stata concordata. Quindi un Mac viene calcolato e aggiunto ai dati. Il Mac consente al ricevitore di verificare che il record non sia stato manomesso. Il suo calcolo include un numero di sequenza di cui il mittente e il ricevitore tengono entrambi traccia. Infine, i dati e il Mac aggiunto vengono crittografati utilizzando la sessione’chiavi di crittografia s e il risultato è il payload per il record. Alla fine ricevente, il record viene decrittografato e il Mac viene calcolato per verificare che il record’I dati S non sono stati manomessi. Se è stata utilizzata la compressione, è decompressa.

Avvisi

Se si verificano errori, SSL/TLS definisce un protocollo di avviso in modo che i messaggi di errore possano essere passati tra client e server. Ci sono due livelli: avvertimento e fatale. Se si verifica un errore fatale, dopo aver inviato l’avviso, la connessione è chiusa. Se l’avviso è un avvertimento, spetta alla parte che riceve l’avviso se la sessione dovrebbe essere continuata. Un avviso importante è Close Notify. Inviato quando una delle parti decide di chiudere la sessione, è richiesto Closedyfy per la normale risoluzione di una sessione. Vale la pena notare che alcune implementazioni SSL/TLS non inviano questo messaggio: limitano semplicemente la connessione.

Versioni

I numeri di versione interna di SSL/TLS non corrispondono come ci si potrebbe aspettare da ciò che viene definito pubblicamente come numero di versione. Ad esempio, 3.1 corrisponde a TLS 1.0. Le versioni principali attualmente in uso sono mostrate qui.
Questi sono utili per avere familiarità, poiché i numeri di versione interna sono spesso preferiti.

Vulnerabilità SSL/TLS

TLS è un protocollo di rete sicuro maturo e ampiamente utilizzato che proteggerà le transazioni su Internet per molti anni a venire. Come ogni protocollo sicuro, tuttavia, nel corso degli anni sono state scoperte una serie di importanti vulnerabilità. Le vulnerabilità continueranno a essere scoperte ed è importante mantenere il software che utilizza TLS aggiornato in modo che vengano applicate le ultime patch di sicurezza.

Alcune delle vulnerabilità più note e di come sono state affrontate sono discusse di seguito.

Heartbleed

Heartbleed è una delle vulnerabilità più gravi mai trovate nel software TLS, consentendo il furto di chiavi del server, ID sessione utente e password utente da sistemi compromessi. Non era, tuttavia, un difetto del protocollo SSL, ma piuttosto un bug di implementazione (noto come lettura over del buffer) in OpenSSL‘S Biblioteca gratuita, ampiamente utilizzata su Internet. Milioni di macchine sono state colpite e numerosi attacchi di successo hanno riportato.

I sistemi software che non utilizzano le versioni pertinenti di OpenSSL non sono state interessate. OpenSSL è stato rapidamente patchato, ma il patching di milioni di macchine richiede tempo. Non solo le macchine dovevano essere patchate, ma le chiavi private del server devono essere aggiornate, le password dell’utente sono state modificate e i certificati riesmetti. Un anno dopo, è probabile che ci siano ancora macchine compromesse su Internet che non sono state adeguatamente modificate.

È stato stimato che il costo totale di cuore straordinario sia nella gamma di centinaia di milioni di dollari.

BARBONCINO

Il barboncino è una vulnerabilità in un protocollo SSL più vecchio, SSL 3.0. Mentre la maggior parte dei sistemi utilizza TLS 1.0, 1.1 o 1.2, il protocollo TLS ha una disposizione di back-back per consentire l’interoperabilità con il software più vecchio utilizzando SSL 3.0. Quindi gli attacchi di barboncino usano questa disposizione di back-back per ingannare i server nel downgrade a SSL 3.0.
La soluzione più semplice è disabilitare SSL 3.0 in client e server. SSL 3.0 è stato pubblicato nel 1996, è stato a lungo sostituito e non dovrebbe essere necessario sostenerlo dopo quasi 20 anni. Il barboncino è una vulnerabilità molto meno seria rispetto al cuore cuore.

RC4

RC4 è una cifra TLS ampiamente utilizzata che non è più considerata sicura. RC4 è anche noto come arc4 o arcfour (perché RC4 è marchio). La sua velocità e semplicità hanno reso popolare RC4, ma recentemente (febbraio 2015) RFC7465 ha raccomandato di non essere più utilizzato.

Protocollo di trasferimento di file SSL/TLS: FTPS

Uno degli usi più comuni di SSL/TLS è una forma sicura di trasferimento di file noto come FTPS.

L’FTP tradizionale come definito in RFC 959 non fa menzione di sicurezza. Questo è comprensibile come è stato scritto nel 1985 e sulla base delle specifiche degli anni ’70. Questo era quando le università e i militari erano gli utenti primari di Internet e la sicurezza non era la preoccupazione che lo sia oggi.

Di conseguenza, nei nomi utente e le password FTP vengono (ancora) inviati sulla rete in testo chiaro, il che significa che chiunque sia in grado di annusare i pacchetti TCP/IP è in grado di acquisirli. Se il server FTP è su Internet, i pacchetti passano tramite reti pubbliche e dovrebbero essere considerati pubblicamente disponibili.

Fu solo negli anni ’90 quando Netscape sviluppò il loro livello sicuro (SSL) che una soluzione divenne pratica. Una bozza di RFC nel 1996 ha descritto un’estensione a FTP chiamata FTPS che ha permesso di utilizzare i comandi FTP su una connessione SSL e nel 2005 questo è stato sviluppato in una RFC formale.

Implementato da client come filezilla e server come ProfTPD, FTPS è diventato rapidamente popolare.

FTP impliciti

Esistono due forme di FTPS: modalità implicita e modalità esplicita. La modalità implicita FTPS è obsoleta e non ampiamente utilizzata, ma si incontra ancora occasionalmente.

FTPS implicito non ha un comando esplicito per proteggere la connessione di rete, invece lo fa implicitamente. In questa modalità, il server FTPS prevede che il client FTPS avvierà immediatamente una stretta di mano SSL/TLS al momento della connessione. In caso contrario, la connessione viene eliminata. La porta server standard per le connessioni in modalità implicita è 990 (non la porta standard 21 utilizzata per FTP).

Una volta stabilita la connessione SSL/TLS, i comandi FTP standard vengono utilizzati per navigare nel server’s file system e per trasferire file. Poiché la connessione è sicura, è possibile inviare le password e i dati non possono essere ispezionati da EavesDroppers.

FTP espliciti

Nella modalità FTPS esplicita, il client deve richiedere esplicitamente la connessione per essere protetta inviando il comando TLS AUTH al server. Una volta che questo comando viene inviato la sua handshake SSL/TLS inizia come con TLS implicito e la connessione del comando è protetta.

Il vantaggio di utilizzare la modalità esplicita FTP sulla modalità implicita è che è possibile utilizzare lo stesso numero di porta di FTP standard – Porta 21. Gli utenti FTP ordinari semplicemente non inviano il comando di autenticazione e quindi non proteggono mai la connessione. L’amministratore del server può facoltativamente richiedere l’utilizzo del comando auth se non desiderano effettuare trasferimenti di file non garantiti.

La modalità esplicita gli FTP dovrebbero sempre essere utilizzati in preferenza alla modalità implicita, principalmente perché la modalità implicita è stata deprecata per molti anni.

Svantaggio degli FTP

FTPS ha uno svantaggio significativo, che è l’uso di una connessione di rete separata per i dati, inclusi contenuti di file e elenchi di directory. Questo fa effettivamente parte del protocollo FTP: i comandi vengono inviati tramite iniziale “controllo” Connessione sulla porta 21 e ogni volta che vengono trasferiti i dati, è necessario stabilire una nuova connessione di rete per il trasferimento. Il client e il server devono concordare un numero di porta e una connessione deve essere aperta.

Con FTP non crittografato, questo non è’T troppo problematico. Ci possono essere problemi con un’esaurimento delle connessioni di rete se vengono effettuati troppi trasferimenti in un breve periodo di tempo. Poiché ogni trasferimento richiede una nuova connessione e i sistemi operativi di solito richiedono alcuni minuti per liberare connessioni chiuse, molti trasferimenti di piccoli file possono comportare errori eventuali.

Il problema più significativo è passare attraverso i firewall. I firewall sono normalmente configurati per consentire l’accesso tramite la porta 21. I moderni firewall sono anche abbastanza intelligenti da essere in grado di ispezionare i comandi inviati tra client e server (porta o PASV) per essere in grado di determinare quali porte devono essere aperte dinamicamente per consentire i trasferimenti di dati.
Con FTPS, tuttavia, i comandi sono su un canale crittografato e i firewall non possono ispezionarli. Ciò significa che non possono aprire automaticamente le porte di dati, quindi i trasferimenti e gli elenchi delle directory falliscono. Invece, un intervallo fisso di porte deve essere concordato in anticipo e configurato in client, server e firewall.

Futuro di FTPS

Al giorno d’oggi, FTPS ha un forte concorrente in SFTP o protocollo di trasferimento di file SSH. Sono protocolli completamente diversi e i loro meriti relativi saranno esaminati nella prossima sezione. Tuttavia, FTP e FTP hanno un’enorme base di installazione e senza dubbio continueranno ad essere ampiamente utilizzati per molti anni a venire.

Come funziona SSH?

Storia SSH

Alla fine del 1980’s e 1990’S, strumenti di rete come rlogin e telnet sono stati comunemente utilizzati per gli accessi in macchine remote, in genere su piattaforme UNIX. Questi strumenti hanno consentito agli utenti di aprire shell di comandi che hanno permesso loro di eseguire comandi sulle macchine remote come se fossero effettivamente sulla macchina ed erano estremamente utili per l’amministrazione dei sistemi.

C’era uno svantaggio critico: nessuno di questi strumenti era sicuro. Le password sono state inviate tramite reti in testo semplice, il che significa che chiunque sia in grado di annusare la rete potrebbe ottenere credenziali per la macchina remota. Questo problema è il motivo per cui Tatu Ylönen, ricercatore finlandese presso l’Università di Tecnologia di Helsinki, ha deciso che era richiesto un protocollo di rete sicuro. Nel 1995 ha scritto la prima versione di SSH, conosciuta come SSH-1, e la ha rilasciato come freeware. Consisteva in un server e un client sicuri.

Man mano che la sua popolarità cresceva rapidamente, Ylönen fondò la sicurezza delle comunicazioni SSH sul mercato e sviluppò SSH come prodotto proprietario. Nel 1999 Björn Grönvall iniziò a lavorare su una precedente versione freeware e il team OpenBSD finanziava il suo lavoro per produrre liberamente OpenSsh disponibile. Le porte furono presto fatte su molte altre piattaforme e OpenSSH rimane la versione più conosciuta e usata di SSH.

Nel 2006 SSH 2.0 è stato definito in RFC 4253. SSH-2 è incompatibile con SSH-1 e ha migliorato la sicurezza e le funzionalità, rendendo obsoleto SSH-1.

Panoramica SSH

SSH è un protocollo di rete sicuro che può essere utilizzato su qualsiasi piattaforma per qualsiasi scopo che richieda una comunicazione di rete sicura. Gli usi tipici includono:

• Strumenti di accesso remoto sicuri, come il client SSH;
• trasferimento di file sicuro, come gli strumenti SCP e SFTP; E
• Fanti di trasmissione per porte protetti o tunneling sicuro.

SSH-2 utilizza un’architettura a strati ed è costituito da un livello di trasporto, un livello di autenticazione utente e un livello di connessione.
Il livello di trasporto funziona su TCP/IP e fornisce crittografia, autenticazione del server, protezione dell’integrità dei dati e compressione opzionale. Il livello di autenticazione utente gestisce l’autenticazione client, mentre il livello di connessione fornisce servizi come accessi interattivi, comandi remoti e connessioni di rete inoltrate.

Lo strato di trasporto

Il livello di trasporto è basato su messaggi e fornisce un controllo di crittografia, autenticazione e integrità dell’host. I messaggi vengono inviati tra client e server tramite TCP/IP tramite il protocollo di pacchetti binari – “pacchetti” dei dati vengono scambiati nel formato definito di seguito e il carico utile di ciascun pacchetto è il messaggio:
UINT32 packet_length byte padding_length byte [n1] carico utile; N1 = packet_length – padding_length – 1 byte [n2] imbottitura casuale; n2 = padding_length byte [m] mac (codice di autenticazione del messaggio – mac); m = mac_length

Il Mac è un campo importante, perché è il Mac che consente ai destinatari di essere sicuri che i messaggi non siano stati manomessi: il controllo di integrità di cui sopra. Il Mac viene calcolato sul resto dei dati nel pacchetto e utilizza un segreto condiviso stabilito tra client e server e un numero di sequenza che entrambe le parti tengono traccia. I Mac sono descritti in questo post.

Stabilire una sessione

Come inizia una sessione tra un client e un server? Ogni lato invia una stringa di identificazione una volta stabilita la connessione TCP/IP. Questa stringa è nel seguente formato:
SSH-2.0-softwareversion SP Commenti CR LF

Qui “Sp” significa uno spazio, “Cr” è un personaggio di ritorno a carro e “Lf” è un carattere di alimentazione di linea. La versione software è la versione fornitore e i commenti e lo spazio sono opzionali. Quindi, nel caso di CompleteftP, quando un client si collega al server riceve la seguente stringa:
SSH-2.0-Completeftp_9.0.0

L’estremità della stringa con il ritorno del trasporto obbligatorio e l’alimentazione della linea – non vengono utilizzati commenti.

Una volta scambiate le stringhe di identificazione, devono essere concordate diverse opzioni: i cifre utilizzati per la crittografia, gli algoritmi MAC utilizzati per l’integrità dei dati, i metodi di scambio chiave utilizzati per impostare chiavi di sessione una tantum per la crittografia, gli algoritmi chiave pubblici che vengono utilizzati per l’autenticazione e infine gli algoritmi di compressione per essere utilizzati. Sia il client che il server si inviano a vicenda un messaggio SSH_MSG_KEXINIT che elenca le proprie preferenze per queste opzioni:
byte SSH_MSG_KEXINIT byte[16] cookie (random bytes) name-list kex_algorithms name-list server_host_key_algorithms name-list encryption_algorithms_client_to_server name-list encryption_algorithms_server_to_client name-list mac_algorithms_client_to_server name-list mac_algorithms_server_to_client name-list compression_algorithms_client_to_server name-list compression_algorithms_server_to_client name-list languages_client_to_server name-list languages_server_to_client boolean first_kex_packet_follows uint32 0 (reserved for future extension)

Questo messaggio è il carico utile di un pacchetto di protocolli binari il cui formato è descritto sopra. Gli elenchi di nomi di algoritmi sono separati da virgola. Il client invia elenchi di algoritmi in ordine di preferenza, mentre il server invia un elenco di algoritmi che supporta. Il primo algoritmo supportato in ordine del cliente’la preferenza è l’algoritmo che viene scelto. Dati entrambi i messaggi, ogni lato può capire quali algoritmi devono essere utilizzati.

Dopo SSH_MSG_KEXINIT, l’algoritmo di scambio chiave selezionato, che può comportare scambiare una serie di messaggi. Il risultato finale è due valori: un segreto condiviso, K e un hash di scambio, h. Questi sono usati per derivare le chiavi di crittografia e autenticazione. Un ssh_msg_newkeys viene inviato per indicare la fine di questi negoziati e ogni messaggio successivo utilizza le nuove chiavi e algoritmi di crittografia.

Con la connessione SSH-2 stabilita, il client richiede a “servizio” (di solito SSH-USERAUTH per iniziare il processo di autenticazione) con il messaggio SSH_MSG_SERVICE_REQUEST.

Livello di autenticazione

Il prossimo passo è che il client si identifichi sul server ed sia autenticato. Questo è gestito tramite il livello di autenticazione utente, che funziona in cima al livello di trasporto. Ciò significa che i messaggi di autenticazione utente vengono crittografati e scambiati utilizzando il livello di trasporto.

L’autenticazione dell’utente è avviata dal client con a “servizio” Richiesta per il servizio SSH-USERAUTH. Se il server risponde consentendo la richiesta, il client invia una richiesta di autenticazione, che include il proprio nome utente e il metodo di autenticazione.

Esistono una serie di possibili metodi di autenticazione e quale viene utilizzato dipenderà dal client e dal server’S supporto per questo. Il metodo più popolare è l’autenticazione della password, che è autoesplicativa. Un altro è l’autenticazione di publickey. In genere, il client propone un metodo e il server accetta o rifiuta quel metodo.

Un esempio di richiesta di autenticazione password da parte di un utente chiamato “Enterprismedt” è mostrato di seguito:
byte ssh_msg_userauth_request stringa “enterpisedt” [nome utente] stringa “ssh-userauth” [nome del servizio] stringa “password” [metodo di autenticazione] falsa stringa booleana “mypassword” [password dell’utente]

Il server convaliderà la password inviata per questo utente rispetto ai dettagli che ha memorizzato per l’utente. Il server non archiverà l’utente’S password effettiva per la convalida, ma un hash criptograpico della password, che non può essere ingegnerizzato per ottenere la password.

Se la richiesta di autenticazione dell’utente viene respinta (ad esempio, è stata fornita una password errata), un messaggio di errore viene inviato dal server e fornisce un elenco di autenticazioni alternative che è possibile provare.

È comune da inviare “nessuno” Come metodo di autenticazione iniziale e il server di solito risponderà con un messaggio di errore contenente un elenco di tutti i metodi di autenticazione disponibili. Una risposta di esempio a “nessuno” è mostrato di seguito:

BYTE SSH_MSG_USERAUTH_FAILURE LASSWORD NOME-LIST, PUBLICKEY BOOLEAN FALSE (FLAG DI SUCCESSIONE PARZIALE)

Qui il server sta informando il client che è possibile utilizzare l’autenticazione della password o del publickey.
Se la richiesta di autenticazione password ha successo, il server restituisce un messaggio di successo come mostrato di seguito:
byte ssh_msg_userauth_success

A questo punto l’autenticazione è completa e altri servizi possono essere richiesti. Questi possono includere richieste di inoltro TCP/IP e canali per l’accesso terminale, esecuzione del processo e sottosistemi come SFTP.

Livello di connessione

Il pezzo finale di SSH-2’L’architettura a strati è il livello di connessione, che fornisce servizi di rete come sessioni interattive e port forwarding in cima al livello di trasporto, che fornisce la sicurezza necessaria.

Una volta stabilita, una connessione SSH può ospitare uno o più canali SSH, che sono tubi di dati logici multiplexi sulla connessione. Il client può aprire più canali su una connessione allo stesso server ed eseguire diverse attività di rete su canali diversi. In pratica, le implementazioni SSH usano raramente più canali su una connessione, preferendo aprire una nuova connessione per ciascun canale.

Una caratteristica importante dei canali SSH è il controllo del flusso. I dati possono essere inviati su un canale solo quando il destinatario ha indicato che sono pronti a riceverli-una forma di controllo del flusso di finestre scorrevoli. La dimensione della finestra è stabilita dal destinatario quando il canale viene aperto e la dimensione della finestra viene decretata man mano che i dati vengono inviati. Periodicamente, il destinatario invia un messaggio per aumentare le dimensioni della finestra.

Di seguito è mostrato il messaggio SSH_MSG_Channel_OPen utilizzato per aprire una sessione interattiva. Questa sessione potrebbe essere successivamente utilizzata per una sessione terminale, per eseguire un comando remoto o per avviare un sottosistema come SFTP.

byte ssh_msg_channel_open string “sessione” canale mittente uint32 uint32 dimensione della finestra iniziale uint32 dimensione massima del pacchetto

La dimensione della finestra iniziale imposta il numero di byte che il destinatario di questo messaggio può inviare al mittente, mentre la dimensione massima del pacchetto è la più grande quantità di dati che accetterà in un singolo messaggio.

Il destinatario di questo messaggio risponde con un messaggio SSH_MSG_CHANNEL_OPEN_CONFIRMAZIONE Se è pronto ad aprire il canale richiesto:
byte ssh_msg_channel_open_confirmation uint32 canale destinatario uint32 canale mittente uint32 dimensione della finestra iniziale uint32 dimensione massima del pacchetto

Una volta che un canale è stato aperto con successo, i dati possono essere scambiati e le richieste specifiche per il canale possono essere inviate. Quando la dimensione della finestra scorrevole per il client o il server diventa troppo piccola, il proprietario della finestra invia un messaggio SSH_MSG_CHANNEL_WINDOW_ADJUST per aumentarlo:
byte ssh_msg_channel_window_adjust uint32 canale destinatario uint32 byte da aggiungere

I dati vengono inviati attraverso il canale tramite il messaggio SSH_MSG_CHANNEL_DATA. Il modo in cui vengono utilizzati i dati dipenderà dal tipo di canale che è stato stabilito:
Byte SSH_MSG_CHANNEL_DATA UINT32 DATI DEL CANALE DELLA STRADITÀ

Le richieste del canale vengono utilizzate per eseguire azioni particolari su un canale. Le richieste comuni includono l’avvio di una shell o l’esecuzione di un comando remoto. Ad esempio, una shell remota viene avviata dalla richiesta mostrata di seguito:

byte ssh_msg_channel_request uint32 canale ricevente stringa “shell” boolean boolean

Un comando remoto viene eseguito dalla seguente richiesta:
byte ssh_msg_channel_request uint32 canale destinatario stringa “exec” boolean comando stringa di risposta

Infine, un sottosistema SFTP può essere aperto con questa richiesta:
byte ssh_msg_channel_request uint32 canale ricevente stringa “sottosistema” booleano vogliono stringa di risposta “SFTP-Server”

I sottosistemi sono set di comandi remoti predefiniti sulla macchina del server. Il più comune è SFTP, che fornisce comandi per trasferire e manipolare i file. I comandi del sottosistema (incluso il protocollo SFTP) vengono eseguiti su ssh, i.e. I dati per i comandi del sottosistema vengono inviati nei messaggi SSH_MSG_CHANNEL_DATA.

Quando uno di questi messaggi arriva al client o al server, viene passato al sottosistema per l’elaborazione.
Una volta che il client o il server hanno terminato l’utilizzo del canale, deve essere chiuso. Il messaggio SSH_MSG_CHANNEL_EOF viene inviato per indicare che non verranno inviati più dati nella direzione di questo messaggio. Il messaggio SSH_MSG_CHANNEL_CLOSE indica che il canale è ora chiuso. Il destinatario deve rispondere con un ssh_msg_channel_close se non ne ha già inviato uno. Una volta chiuso, il canale non può essere riaperto.

Protocollo di trasferimento di file ssh: SFTP

Il sottosistema più comune utilizzato con SSH è SFTP, che fornisce comandi per trasferire e manipolare i file. SFTP è anche noto come protocollo SSH File Transfer ed è un concorrente di FTPS – FTP tradizionale su una connessione SSL/TLS.

Il sottosistema SFTP viene eseguito sul livello di trasporto SSH, ma è un sofisticato protocollo basato su messaggi a sé stante. I messaggi SFTP vengono trasmessi come il campo di dati del livello di trasporto’SSH_MSG_CHANNEL_DATA Messaggio
I messaggi SFTP sono in un formato standard, come mostrato di seguito:
Tipo di byte di lunghezza Uint32 UINT32 RICHIEST-ID . Digita campi specifici ..

Il primo campo è la lunghezza del messaggio, escluso il campo di lunghezza, e successivo è il tipo di messaggio. Il terzo campo è l’ID richiesta: ogni richiesta inviata dal client ha un ID richiesta e il server’La risposta S deve includere l’ID richiesta corrispondente.

Alcuni dei messaggi SFTP più importanti insieme ai loro ID di tipo sono mostrati e descritti di seguito:
Ssh_fxp_init 1 ssh_fxp_version 2 ssh_fxp_open 3 ssh_fxp_close 4 ssh_fxp_read 5 ssh_fxp_write 6 ssh_fxp_status 101 ssh_fxp_data 103

Ssh_fxp_init è il primo messaggio inviato dal client per avviare la sessione SFTP e il server risponde con SSH_FXP_VERSION, indicando le versioni che supporta.
Ssh_fxp_open richiede al server aprire un file (o facoltativamente crearlo se non esiste), mentre

Ssh_fxp_close chiude un file. Ssh_fxp_read chiede di leggere un certo intervallo di byte da un file e il server risponde con ssh_fxp_data, che contiene i byte richiesti. Ssh_fxp_write viene utilizzato per scrivere dati su un file e uno dei suoi campi è i dati da scrivere (così come l’offset nel file).

Se uno dei comandi sopra indicati fallisce, SSH_FXP_STATUS viene restituito con un codice di errore che indica il tipo di errore che si è verificato. Viene anche usato per segnalare una scrittura riuscita in risposta a ssh_fxp_write.

Esistono anche comandi per altre operazioni di file e directory standard, come la rimozione di file (ssh_fxp_remove), il rinominato file (ssh_fxp_rename) e la creazione e la rimozione delle directory (ssh_fxp_mkdir, ssh_fxp_rmdir). Le directory vengono lette aprendoli (ssh_fxp_opendir) e inviando richieste ssh_fxp_readdir. Ancora una volta, SSH_FXP_STATUS viene utilizzato per indicare il successo o il fallimento di queste richieste.

Non esiste un messaggio SFTP specifico per terminare una sessione SFTP, invece, il client chiude il canale SSH utilizzato.

È importante notare che SFTP è un protocollo completamente diverso per l’FTP tradizionale, i.e. Non sono comandi FTP inviati su una connessione SSH. Al contrario, FTPS è comandi FTP inviati su una connessione SSL/TLS. I due protocolli sono facilmente confusi, in quanto sono entrambi protocolli sicuri per il trasferimento di file.

SFTP vs FTPS

Abbiamo descritto come funzionano FTPS e SFTP, sopra. In sostanza, entrambi i protocolli ottengono esattamente la stessa cosa: trasferimento di file sicuro e manipolazione sicura e remota dei file-sistemi.

Sono, tuttavia, protocolli completamente diversi e le persone che implementano una soluzione di trasferimento di file sicure dovranno decidere quale protocollo utilizzare.

L’uso esistente è naturalmente una considerazione importante. Se SFTP e/o SSH sono già utilizzati in altre aree di un’organizzazione, è prudente usare SFTP. Le conoscenze e le competenze esistenti all’interno dell’organizzazione possono essere sfruttate, nonché infrastrutture tecniche. Allo stesso modo, se FTP e/o FTPS sono già utilizzati altrove, potrebbe essere meglio utilizzare FTPS.

I requisiti del progetto possono anche dettare il protocollo. Se viene implementata una soluzione sul lato server, è possibile che i clienti siano limitati a un protocollo particolare e quindi non è necessario prendere alcuna decisione.

Ma cosa succede se il punto di partenza è una lavagna completamente pulita e non ci sono vincoli su quale protocollo potrebbe essere utilizzato? C’è un chiaro vincitore?

SFTP – Un chiaro vincitore

Sì, ed è SFTP. Alcuni anni fa, una tale decisione non era così semplice, principalmente a causa del dominio del protocollo FTP nella maggior parte delle organizzazioni. Ora i client e il software server sono ampiamente disponibili sia per SFTP che per FTPS, in effetti molte applicazioni come il completamento del supporto.

Ciò significa che una decisione può essere presa per motivi puramente tecnici e SFTP ha almeno due importanti vantaggi tecnici su FTP e FTPS.

SFTP è migliore con i firewall

Gli FTP possono essere dolorosi per lavorare con i firewall. Questo perché gli elenchi di directory e i trasferimenti di file vengono effettuati su una nuova connessione di rete separata dal canale di controllo sulla porta 21. Per impostazione predefinita, i firewall non consentiranno queste connessioni in FTPS (anche se di solito funzionerà con FTP poiché i firewall sono in grado di ispezionare il traffico di rete e aprire in anticipo la porta appropriata). Invece, il firewall e il server devono essere configurati per una determinata gamma di porte per il trasferimento dei dati, che possono complicarsi.

Al contrario, SFTP funziona solo con i firewall. I dati e i comandi vengono entrambi inviati sulla porta standard 22, che di solito è abilitata con firewall per impostazione predefinita. Questo è un vantaggio significativo rispetto a FTP.

Sftp non lo fa’t Utilizzare i certificati

FTPS utilizza i certificati per identificare il server al client. L’identificazione del server è importante, in quanto il client verifica che si sta connettendo al server corretto. Per essere utili, tuttavia, i certificati devono essere emessi da un’autorità di certificazione, un’organizzazione autorizzata a emetterli. Ottenere un certificato può essere costoso e richiedere molto tempo.

Sftp non lo fa’t Utilizzare i certificati: il server è identificato dalla sua chiave pubblica (che è ciò che un certificato contiene, quindi entrambi stanno utilizzando entrambi lo stesso meccanismo). Quindi fintanto che un client ha a portata di mano la chiave pubblica del server, può confermare che il server è quello corretto. Il server’La chiave pubblica (a differenza di un certificato) può essere generata dall’organizzazione e non è richiesta un’autorità di certificazione. Ciò riduce in modo significativo la quantità di amministrazione necessaria per far funzionare un server e in esecuzione.

Ci sono alcuni vantaggi nell’avere un’organizzazione riconosciuta come un’autorità di certificazione per emettere certificati, ma per la maggior parte del tempo non è necessario, in particolare per i progetti interni.

C’è qualche aspetto negativo nell’uso di SFTP?

L’assenza di certificati potrebbe essere un problema se si desidera il riconoscimento di un’autorità di certificazione, ma il principale svantaggio di SFTP è che si tratta di un protocollo complesso che è difficile da attuare. Scrivere un client SFTP o un server SFTP non è un’attività facile.

Questo, tuttavia, è molto improbabile che influenzi le organizzazioni utilizzando SFTP come parte della loro infrastruttura: una grande varietà di clienti e server sono disponibili su varie piattaforme e devono solo selezionare le applicazioni più adatte. Tutti i client e il server dovrebbero interagire, quindi c’è una notevole latitudine nella scelta dei prodotti. È probabile che le caratteristiche aggiuntive al protocollo dettino la selezione finale.

Conclusione

Questo contenuto ha spiegato come funzionano SSL/TLS e SSH per proteggere i dati trasferiti su una rete e in particolare i protocolli FTPS e SFTP. Sebbene simili nella funzionalità, FTPS e SFTP sono molto diversi nell’implementazione. In un confronto testa a testa, SFTP esce in cima, anche se può essere saggio scegliere di supportare entrambi i protocolli nell’infrastruttura tecnica della tua organizzazione.

Altri articoli tecnici

• Cosa è gestito il trasferimento di file (MFT)?
• Cos’è SFTP?
• Cos’è FTP?
• Cos’è FTPS?
• FTPS vs Sftp

SSL vs SSH-Un confronto non così tecnologico

Sapevi che SFTP e FTP hanno ottenuto la loro sicurezza dai protocolli sottostanti? Scopri le somiglianze e le differenze tra SSH e SSL oggi!

Panoramica

I protocolli di trasferimento di file sicuri più utilizzati, SFTP e FTPS, ottengono la loro sicurezza da protocolli sottostanti. SFTP da SSH e FTP da SSL. Confrontiamo i due.

In passato, c’era solo un metodo popolare per il trasferimento di file su una rete – FTP, che sta semplicemente per il protocollo di trasferimento di file. FTP supporta i trasferimenti di file in blocco e consente persino agli utenti di navigare nelle directory remote, creare directory, eliminare directory ed eseguire alcune altre attività simili a quelle svolte sui filesystem locali.

FTP è un protocollo basato su TCP. Quindi, può essere molto utile per scaricare/caricare file su una LAN o anche tramite Internet. Tuttavia, FTP è stato progettato in un momento in cui l’uso di Internet era limitato ad alcune organizzazioni e le minacce basate sulla rete erano inesistenti.

Oggi esistono già una moltitudine di minacce e le connessioni FTP possono essere compromesse attraverso attacchi sniffer, forza bruta e altre forme di attacchi informatici. Per proteggere i trasferimenti di file da queste minacce, sono stati sviluppati protocolli di trasferimento di file sicuri. Di questi protocolli, due hanno guadagnato un’adozione diffusa – FTPS e SFTP.

FTPS ottiene effettivamente la sua protezione da SSL/TLS (Sicurezza Secure Sockets Layer/Transport Layer), mentre SFTP ottiene il proprio da SSH (Shell Secure).

Somiglianze tra SSH e SSL

Quando confronti i loro attributi di sicurezza, scoprirai che SSH e SSL hanno somiglianze molto forti. Entrambi offrono meccanismi di crittografia dei dati-in-motion, autenticazione del server, autenticazione client e integrità dei dati.

Crittografia dati-in-motion

La crittografia dei dati-in-motion è una capacità di sicurezza che impedisce agli intercedri di visualizzare i dati inviati su una rete. In altre parole, continua a trasmettere dati riservati. È supportato in SSH e SSL e agisce convertendo i dati in chiaro in quello che è noto come testo cifrato.

Tutto ciò che un EavesRopper vedrebbe quando la visualizzazione del testo cifrato su una connessione crittografata sarebbe una stringa incomprensibile di caratteri.

Questi due screenshot mostrano ciò che vede un Eavesdropper quando annusano una connessione non crittografata e una connessione crittografata. Notare come la connessione non crittografata non riesce a nascondere il nome utente e la password. Nella connessione non crittografata, quelle credenziali di accesso sono già incomprensibili.

Connessione non crittografata (e.G. FTP)

Connessione crittografata (e.G. SFTP o FTPS)

Sia SSH che SSL forniscono la crittografia dei dati in movimento attraverso quella che è nota come crittografia a chiave simmetrica. Questo tipo di crittografia impiega una chiave condivisa utilizzata sia per la crittografia che per la decrittografia. Alcune cifre chiave simmetriche comuni includono eventi avversi, 3des, pompini, twofish e rc4.

Autenticazione del server e del client

Una connessione crittografata diventa inutile se hai inconsapevolmente connesso a un server fasullo o a un client dannoso. Mentre SSH e SSL usano la crittografia simmetrica per preservare la riservatezza dei dati trasmessi, usano un’altra forma di crittografia per l’autenticazione. L’autenticazione consente a una parte di verificare se l’altra parte è davvero chi afferma di essere.

Per implementare l’autenticazione, SSH e SSL usano la crittografia asimmetrica a.K.UN. Crittografia a chiave pubblica. I popolari algoritmi di crittografia della chiave pubblica sono RSA, DSA ed ECDSA, tutti supportati da SSH e SSL.

A differenza della crittografia simmetrica, che utilizza una singola chiave per la crittografia e la decryption, la crittografia asimmetrica utilizza due chiavi: una chiave pubblica e una chiave privata.

La crittografia della chiave pubblica può essere utilizzata da un client per autenticare il server. Questo è noto come autenticazione del server. L’autenticazione del server impedisce alle applicazioni client di connettere inavvertitamente e quindi transarsi con un server dannoso che sta impersonando uno legittimo.

Al contrario, la crittografia delle chiavi pubbliche può anche essere utilizzata da un server per autenticare un client. Questo è noto come autenticazione client. L’articolo Cos’è una chiave SFTP Include una bella introduzione sull’autenticazione client e sulla crittografia a chiave pubblica.

Meccanismi di integrità dei dati

Quando ricevi informazioni sensibili, l’integrità dei dati è importante quanto la riservatezza dei dati. Ti consigliamo di assicurarti che i dati che ricevi siano esattamente gli stessi dati che sono stati originariamente trasmessi dal mittente.

Le aziende, in particolare, richiedono un alto livello di garanzia per l’integrità dei dati quando conducono transazioni su Internet. I dati manomessi possono avere un impatto negativo sui processi aziendali e possono anche essere un segno di attività fraudolente.

I meccanismi di integrità dei dati consentono alle parti di transazione di verificare se il messaggio trasmesso era inalterato lungo la strada. Algoritmi MAC (Message Authentication) come Sha1, Sha256 (e altre versioni di SHA) e MD5 sono in genere impiegati da SSH e SSL per eseguire controlli di integrità dei dati sui messaggi trasmessi.

L’articolo che comprende hashing include una bella discussione sull’argomento.

Differenze tra SSL e SSH

Una delle differenze più evidenti tra SSL/TLS e SSH è che SSL normalmente (sì, ci possono essere eccezioni) impiega x.509 Certificati digitali per l’autenticazione del server e del client mentre SSH no. E poiché SSL utilizza certificati digitali, di conseguenza richiede anche la presenza di un’infrastruttura a chiave pubblica (PKI) e la partecipazione di un’autorità di certificazione (CA).

Sebbene sia possibile impiegare quelli che sono noti come certificati autofirmati, nel qual caso SSL diventa molto simile a SSH a causa dell’assenza di una CA, questa non è una pratica raccomandata. I certificati auto-firmati sono accettabili solo nelle transazioni intra-organizzative, tranne in grande (E.G. Organizzazioni distribuite a livello globale).

Un’altra grande differenza è che SSH ha più funzionalità integrate. Ad esempio, da solo, SSH può consentire agli utenti di accedere a un server ed eseguire i comandi in remoto. SSL non ha questa capacità. Dovresti abbinarlo a un altro protocollo (e.G. Http, ftp o webdav) per avere funzioni simili.

SSH supporta anche prontamente il multiplexing di connessione, il controllo del flusso, la gestione del terminale e altre funzionalità. Naturalmente, quelle caratteristiche aggiuntive non rientrano più nella nostra discussione originale in cui abbiamo iniziato a confrontare SSL e SSH in relazione a SFTP e FTPS.

Quindi prima di allontanarci ulteriormente, finiamo qui.

Iniziare

Vorresti provare il server di trasferimento di file che supporti FTPS e SFTP e altri protocolli? Prova oggi l’edizione di valutazione gratuita e pienamente funzionale di Jscape MFT Server.

Articoli popolari

Impostazione dell’autenticazione della chiave pubblica SFTP sulla riga di comando

6 minuti Leggi – 11 dicembre 2022

SFTP ti consente di autenticare i clienti utilizzando le chiavi pubbliche, il che significa che hanno vinto’T ha bisogno di una password. Scopri come impostarlo nella riga di comando online. Leggi l’articolo

Attivo vs. FTP passivo semplificato: comprensione delle porte FTP

7 minuti Leggi – 11 dicembre 2022

Se ci sono problemi di connessione al server FTP, controlla la modalità di trasferimento. Lascia che Jscape ti aiuti a capire la differenza nell’FTP attivo e passivo. Leggi l’articolo

Attivo-attivo vs. Clustering ad alta disponibilità attivo

3 minuti di lettura – 11 dicembre 2022

Le configurazioni di clustering ad alta disponibilità più comunemente utilizzate sono attive e attive attivo. Impara la differenza tra i due online! Leggi l’articolo

Utilizzando gli script FTP di Windows per automatizzare i trasferimenti di file

4 minuti Leggi – 11 dicembre 2022

Scopri come automatizzare i trasferimenti di file utilizzando gli script di Windows FTP. Questo post spiega quali sono gli script FTP e come creare script semplici per trasferire file. Leggi l’articolo

SSH usa TLS o SSL

Об этой сттце

Ыы зарегистрировали подозритеstituire. С помощю ээй ст р ы ыы сможем о imperceде quello. Почему ээо мо л поззти?

Эта страница отображается в тех с лччч, когда автоматическиtal систе quisi которые наршают условия иполззования. Страница перестан scegliere. До этого момента для иполззования сжж google необходимо пхоходить поверку по по по по по.

” ылку запросов. Если ы и ипоеете общий доступ в интернет, проmma. Обратитесь к с ое системому администратору. Подробнеi.

Проверка по слову может также появляться, если вы вводите сложные запросы, обычно распространяемые автоматизированными системами, или же вводите запросы очень часто.

SSH vs SSL: differenze e somiglianze tra loro [punte dei mini]

Quali sono le differenze tra SSH e SSL? Qual è il migliore? Se stai cercando di trovare queste domande’ Risposte, questo post è ciò di cui hai bisogno. Questo post di Minitool ne fornisce le definizioni e le informazioni su SSH vs SSL.

Cos’è ssh

Cosa significa SSH? SSH è anche noto come Shell Secure, che è un metodo di comunicazione sicura con computer remoti. SSH viene utilizzato per interagire con la shell operativa di un altro sistema per eseguire i comandi in remoto.

SSH può essere utilizzato solo su computer basati su Unix originariamente, ma ora puoi usarlo su Windows. SSH è un protocollo di crittografia che crea un tunnel tra due computer remoti. Forse, questo post – Come impostare il client SSH e il server su Windows 10 [Guida completa] è ciò di cui hai bisogno.

Cos’è ssl/tls

Cos’è SSL o cosa è TLS? SSL e TLS sono meccanismi per proteggere la sicurezza dei siti Web. Sebbene SSL e TLS facciano più o meno la stessa cosa, TLS sostituisce gradualmente SSL nell’implementazione della rete. Usano le firme digitali generate dalle autorità di certificazione per consentire la fiducia tra te e i fornitori.

SSH vs SSL

SSH e SSL/TLS di solito hanno usi diversi. SSH viene utilizzato per eseguire compiti con cui gli utenti di Internet normali non hanno mai avuto a che fare con. D’altra parte, gli utenti di Internet ordinari hanno utilizzato SSL/TLS. Di seguito sono riportate le informazioni su SSL vs SSH.

Analogie

Adesso molla’S Vedi le somiglianze tra SSH e SSL. Innanzitutto, sia SSH che SSL sono abbreviazioni a tre cifre che iniziano con la stessa lettera. Successivamente, questi sono i due protocolli utilizzati nelle connessioni sicure. Infine, entrambi usano la crittografia per proteggere i dati passati tra due dispositivi di rete.

Differenze

Proprio ora, hai conosciuto le somiglianze tra SSH e SSL. Quindi, lascia’S Vedi le differenze tra SSH e SSL.

1. SSH funziona sulla porta 22, mentre SSL funziona sulla porta 443.

2. SSH si basa su tunnel di rete e SSL si basa sui certificati.

3. Tecnicamente, SSH viene utilizzato per proteggere la rete di computer, mentre SSL viene utilizzato per proteggere la trasmissione dei dati online.

4. SSH utilizza un processo di autenticazione nome utente/password per stabilire una connessione sicura, mentre SSL non lo considera.

5. SSL viene utilizzato per trasferire in modo sicuro informazioni chiave come carte di credito e banche. E SSH viene utilizzato per eseguire comandi in modo sicuro su Internet.

6. SSL di solito (tranne le eccezioni) usa x.509 certificati digitali per l’autenticazione del server e del client, mentre SSH no.

7. SSL viene utilizzato per crittografare la comunicazione tra il browser e il server. D’altra parte, SSH viene utilizzato per crittografare la comunicazione tra due computer su Internet.

8. In SSL, la comunicazione è autenticata dalla coppia di chiavi private/pubbliche. In SSH, la comunicazione è autenticata tramite coppie di chiavi private/pubbliche o coppie di nomi utente/password.

9. Un’altra grande differenza è che SSH ha più funzionalità integrate di SSL. Ti aiuta ad accedere al server ed esegue i comandi in remoto e SSL non ha questa funzione. Per ottenere questa funzione, è necessario abbinarla ad altri protocolli: HTTP, FTP.

5 modi per risolvere l’errore HTTP 401 non autorizzato

Quando si apri il browser per cercare qualcosa, potresti imbatterti nell’errore HTTP 401 non autorizzato. Questo post mostra come risolvere questo errore 401.

Parole finali

Ecco tutte le informazioni su SSH vs SSL. Dopo aver letto questo post, dovresti sapere cosa sono SSH e SSL. E da questo post, hai saputo che le somiglianze e le differenze tra SSH e SSL.

• Facebook
• Twitter
• LinkedIn
• Reddit

Circa l’autore

Daisy si è laureata in inglese e poi si è unita al Minitool come editore. È specializzata nella scrittura di articoli sul backup di dati e sistemi, clonazione di dischi e file di sincronizzazione, ecc. È anche brava a scrivere articoli su conoscenze informatiche e problemi di computer. Nella vita quotidiana, le piace correre e andare al parco divertimenti con gli amici per giocare ad oggetti emozionanti.