Nel modulo precedente,
abbiamo visto circa l'autenticazione utente in un sacco di dettaglio.
Avevamo visto come l'utente invia le proprie credenziali al proprio server dal lato client
nell'intestazione del
messaggio di richiesta o nel corpo del messaggio di richiesta e quindi successivamente,
quando vengono autenticati, il
loro client includerà il cookie o il
token in l'intestazione del messaggio di richiesta che va dal client al server.
Sono sicuro che alcuni di voi stavano gridando per
il fatto che stavamo comunicando su un canale insicuro, il
che significa che chiunque seduto al centro che può
ascoltare i propri messaggi tra il client
e il server sarebbe facilmente in grado di acquisire
le credenziali e poi impersonare il cliente autentico.
Ovviamente, a quel punto,
la loro enfasi era più sull'organizzazione della
comunicazione client e server con l'autenticazione del client sul lato server.
Ma ogni volta che è necessario utilizzare l'autenticazione utente
, in primo luogo, sotto forma di,
ad esempio, di fornire le credenziali per
autenticarsi e successivamente, autenticarsi includendo
il cookie o il token nell'intestazione del messaggio di richiesta,
dovresti farlo su un canale sicuro.
Non dovresti mai comunicare su un canale non sicuro, il
che significa che non dovresti usare HTTP e quindi includere
queste credenziali nell'intestazione o nel corpo dei messaggi di richiesta.
Invece, dovresti usare una versione sicura del protocollo HTTP o HTTPS.
Parliamo brevemente di HTTPS in questa lezione.
Lungo la strada, ti darò un'introduzione di cinque minuti alla crittografia e alla sicurezza.
Ovviamente, la crittografia e la sicurezza sono un argomento molto importante a sé stante.
Ho solo intenzione di presentarti gli elementi essenziali che devi
capire per imparare come funziona effettivamente HTTPS.
Con questo background, procediamo a capire
la crittografia e poi sul protocollo HTTPS e come si configura un server per utilizzare
il protocollo HTTPS e quindi il client per contattare il server utilizzando il protocollo HTTPS, in
tal modo, la comunicazione tra il client e il server può essere fatto in modo sicuro
crittografando i dati inviati tra il client e il lato server.
Quando ti avventurerai nel campo della crittografia e della sicurezza,
sentirai spesso parlare di crittografia a chiave simmetrica.
Ora, cosa comporta la crittografia?
Se è necessario inviare un messaggio su un canale a un altro utente,
si desidera essere in grado di crittografare il messaggio in
modo tale che solo il destinatario sarà in grado di
decrittografare il messaggio e ottenere
le informazioni che si sta tentando di inviare al destinatario.
Quindi sia il mittente che il destinatario dovrebbero capire su stabilire tra i due di
loro come questo processo di crittografia e come funzionerà la decrittografia.
Affinché ciò funzioni,
qualsiasi crittografia e decrittografia funziona in base allo scambio di chiavi segrete.
Quindi, nella crittografia a chiave simmetrica,
sia il mittente che il destinatario condivideranno una chiave segreta tra i due siti,
e questa chiave segreta è nota solo al mittente e al lato ricevitore.
Quindi, quando il mittente deve inviare il messaggio,
il mittente crittograferà questo messaggio utilizzando un algoritmo di crittografia,
che utilizza la chiave segreta come altro input per questo algoritmo.
E una volta passato questo messaggio attraverso questo algoritmo di crittografia,
verrà generato un messaggio crittografato.
Ora, questo messaggio crittografato verrà inviato al canale attraverso il lato ricevitore.
Se hai un utente malintenzionato di terze parti
seduto in mezzo e ascolta e cattura questo messaggio crittografato,
sarebbe difficile decrittografare
questo messaggio perché per decrittografare un messaggio crittografato,
hai ancora bisogno della chiave segreta.
Ora, sul lato ricevitore,
quando viene ricevuto il messaggio crittografato,
verrà applicato il ricevitore e un algoritmo di decrittografia,
che prende anche come input,
la stessa chiave segreta che è stata utilizzata sul lato mittente per crittografare il messaggio.
Quindi, al momento della decrittografia, il messaggio originale verrà recuperato
e può essere elaborato sul lato ricevitore.
Ora, se una terza parte malintenzionata vuole decifrare questo messaggio crittografato,
affronterà una battaglia in salita perché
il processo di crittografia usando la chiave segreta trasformerà il messaggio e potrà,
a sua volta, crittografare il messaggio.
Senza possedere la chiave
segreta, sarà quasi impossibile decrittografare il messaggio crittografato.
Beh, questo è stretching andare un po 'lontano.
Sarebbe inordinatamente difficile decrittografare il messaggio crittografato.
Se usi tecniche di forza bruta, alla fine,
finirai per decifrare il messaggio crittografato.
Ma ci vorrà così tanto tempo e richiederà così tanta potenza di calcolo.
Non varrà la pena per
l'utente malintenzionato di terze parti provare a decodificare il messaggio crittografato.
Quindi stai essenzialmente rendendo davvero difficile per qualcuno
decrittografare il messaggio se non possiede la chiave segreta.
Ora, poiché la chiave segreta è nota solo al mittente e al destinatario,
le due parti finali, il mittente e il destinatario,
possono comunicare con la certezza
che nel messaggio crittografato
dal lato mittente può essere decrittografato solo dal lato destinatario.
Quindi questo è il modo in cui funziona la crittografia a chiave simmetrica.
Il fatto che tu abbia la stessa chiave segreta condivisa tra
il mittente e il destinatario significa che
l'inclusione del processo di decrittografia ha utilizzato la stessa chiave segreta,
quindi, crittografia a chiave simmetrica.
Naturalmente, con la crittografia a chiave simmetrica,
uno dei problemi è che sia il mittente che
il destinatario devono avere accesso alla stessa chiave segreta.
Ora, se il mittente e il destinatario comunicano su un canale insicuro,
sarà difficile per entrambe le parti giungere ad una comprensione
della stessa chiave segreta senza rivelarla ad altri.
Quindi questo è dove un altro algoritmo chiamato crittografia a chiave pubblica è molto utile.
Come funziona la crittografia a chiave pubblica?
Ora, nella crittografia a chiave pubblica,
l'idea è che tu abbia due chiavi diverse.
Hai una chiave pubblica e una chiave privata.
Ora, la chiave pubblica può essere ampiamente distribuita a chiunque tu desideri.
Quindi, quando qualcuno vuole mandarti un messaggio,
userà la tua chiave pubblica per crittografare il messaggio.
Quindi, se un mittente qui vuole inviare il messaggio al destinatario,
allora il mittente utilizzerà la chiave pubblica fuori dal ricevitore per
crittografare il messaggio sul lato mittente utilizzando l'algoritmo di crittografia.
Ora, una volta che il messaggio crittografato viene inviato attraverso
il canale non sicuro al lato
ricevitore, il ricevitore utilizzerà la chiave privata
che solo il ricevitore conosce per decrittografare.
Ora, affinché la crittografia a chiave pubblica funzioni come abbiamo visto,
la chiave pubblica può essere ampiamente distribuita senza alcuna preoccupazione.
Ma poiché la chiave privata è nota solo al lato ricevitore,
solo il ricevitore sarà in grado di decrittografare il messaggio e,
ancora una volta, un intruso di terze parti che cattura
questo messaggio crittografato troverà inordinatamente difficile decifrare il messaggio.
Ora, naturalmente nella crittografia a chiave pubblica,
la chiave pubblica e la chiave privata sono due chiavi diverse.
Ora, allora la tua ovvia domanda successiva sarebbe perché
non usare semplicemente la crittografia a chiave pubblica per la crittografia.
Il problema è che l'utilizzo della crittografia a chiave pubblica
per la crittografia e la decrittografia è un processo costoso,
ed è per questo che non usiamo la crittografia a chiave pubblica per l'intera comunicazione.
Invece, la crittografia a chiave pubblica verrà utilizzata
principalmente per il mittente e il destinatario per
concordare la chiave segreta comune che i due utilizzeranno.
In seguito vedremo come la crittografia a chiave pubblica
può essere utilizzata per stabilire la chiave segreta comune
tra il mittente e il destinatario e successivamente
utilizzare la crittografia a chiave simmetrica per ulteriori comunicazioni.
Un protocollo che utilizza questo approccio è Secure Sockets
Layer e anche i protocolli di sicurezza Transport
Layer, SSL e TLS in breve.
Così tante volte quando leggi la documentazione,
potresti sentire parlare di SSL e TLS.
Questi protocolli di crittografia consentono una comunicazione sicura tra
il mittente e il destinatario su una rete non sicura come Internet.
Il mittente e il destinatario comunicheranno su Internet utilizzando messaggi crittografati,
che solo il mittente e il destinatario possono decrittografare.
E questo approccio, SSL o TLS,
utilizza una combinazione di crittografia a chiave pubblica insieme alla crittografia a chiave simmetrica.
Il loro processo esatto di fare questo,
spiegherò nella prossima diapositiva.
Inoltre, utilizzando SSL o TLS,
stiamo cercando di mantenere due cose diverse.
Stiamo, in primo luogo, cercando di mantenere la privacy
della comunicazione tra il mittente e il destinatario in modo che
nessun terzo malintenzionato possa estrarre il messaggio dal messaggio crittografato.
In secondo luogo, stiamo anche cercando di mantenere l'integrità,
il che significa che quando il mittente invia un messaggio,
il destinatario sarà in grado di essere sicuro che il messaggio non è stato manomesso.
Quindi sia la sicurezza che il mantenimento dell'integrità sono molto importanti in questo caso.
Quindi sia la privacy che l'integrità devono essere mantenute da
questo protocollo di comunicazione sicuro che costruiamo
per lo scambio tra il mittente e il destinatario.
Parliamo brevemente di come SSL o TLS funzionano effettivamente.
Questo viene fatto attraverso un processo di handshaking che ho illustrato in questo diagramma qui.
Quando un client desidera comunicare con il server,
il client invia un messaggio al server,
specificando che il client desidera comunicare con il server in modo sicuro.
A questo punto, il server invierà il certificato al client,
che contiene una chiave pubblica,
che è stata certificata
dall'autorità di certificazione come appartenente a quel particolare server.
In questo modo, quando il client riceve
questa chiave pubblica più la certificazione da parte dell'autorità di certificazione,
il client sarà in grado di verificare le credenziali del server.
Quindi, il client deve stabilire che sta realmente parlando con il server,
con cui intende comunicare.
Quindi, a questo punto,
quando il client verifica le credenziali del server,
il client ora ha accesso alla chiave pubblica del server.
Una volta che il client ottiene la chiave pubblica del server,
allora il client genererà ciò che viene chiamato come il segreto pre-master.
Questo segreto pre-master è qualcosa che il client e il
server utilizzeranno per generare ciò che viene chiamato come chiave di sessione.
Quindi, il client genera un segreto pre-master,
il client quindi crittografa quel segreto utilizzando la chiave pubblica del server
e quindi invia il segreto al server.
Ora, ricorda che una volta che il segreto viene crittografato usando la chiave pubblica,
nessuno oltre al server sarà in grado di
estrarre le informazioni dal messaggio crittografato.
Quindi, quando il server riceve questo messaggio crittografato,
il server estrae il segreto pre-master da questo messaggio.
Ora, sia il client che il server possiedono lo stesso segreto pre-master.
A questo punto, sia il client che il server utilizzeranno
lo stesso insieme di passaggi a partire dal segreto del pre-master,
e con lo stesso insieme di valori,
che genererà una chiave chiamata come chiave di sessione.
Ora, quando la chiave di sessione viene generata sia sul lato client che sul lato server,
sarà esattamente la stessa chiave di sessione,
perché entrambe seguiranno esattamente lo stesso processo per generare la chiave di sessione.
Quindi, a questo punto,
sia il client che il server,
ora possiedono una chiave segreta che è la stessa su entrambi i siti.
Quindi, tutte le comunicazioni successive tra il server e il client,
possono quindi procedere utilizzando la crittografia simmetrica.
Pertanto, quando il client deve comunicare con il server,
il client crittograferà i dati utilizzando la chiave di sessione segreta
e quindi invierà i loro dati.
Allo stesso modo, quando il server deve comunicare con il client,
il server utilizzerà ovviamente
la stessa chiave di sessione per crittografare i dati e quindi inviarli al client.
Ora, poiché il client possiede la stessa chiave di sessione,
il client sarà in grado di decrittografare il messaggio ed estrarre il messaggio non crittografato.
Utilizzando questa procedura,
il client e il server hanno assicurato che la comunicazione tra di loro sia privata.
Inoltre, riusciamo a garantire che nessuna terza parte malintenzionata possa
intercettare il messaggio e causare eventuali modifiche al messaggio.
Quindi, viene mantenuta anche l'integrità
del messaggio e viene mantenuta anche la privacy
della comunicazione tra il client e il server.
Quindi, tutta questa discussione che vi ho presentato nelle ultime diapositive,
è in poche parole,
come garantire la comunicazione sicura tra il client e il server
utilizzando la crittografia a chiave simmetrica e la crittografia a chiave pubblica.
Ora, ovviamente, c'è molto di più di quello che ho spiegato qui,
ma questa comprensione di come funziona la crittografia è
sufficiente per capire come funziona l'intero processo.
Ora, se siete interessati a saperne di più su questo,
una buona fonte per conoscere i protocolli di crittografia è un ottimo libro
di Jim Crozon Keith Ross chiamato Computer Networks.
Questo libro ha un capitolo molto facile da capire
sulla crittografia e la sicurezza come applicato alla comunicazione di rete.
Ora che abbiamo stabilito il processo
per essere in grado di comunicare in modo sicuro tra un client e un server,
diamo un'occhiata a come Internet stesso sfrutta questo,
per la comunicazione tra un client e il server utilizzando HTTP.
Ora, questo è dove entra in scena il protocollo HTTPS.
Come hai già capito su Internet,
Internet è un'architettura a più livelli,
in cui l'IP e il TCP formano la rete
e il livello di trasporto che gira sulla rete sottostante.
Ora, al di sopra del livello di trasporto,
si ha il livello di socket sicuro o il rivestimento di sicurezza del livello
di trasporto come strato sottile sopra il TCP che
garantisce una comunicazione sicura tra il client e il server.
E sopra di esso HTTP può essere eseguito.
Quindi, HTTP implica essenzialmente HTTP più l'uso della crittografia, la
decrittografia supportata tramite SSL e TLS.
Ovviamente, anche per il protocollo HTTPS,
ci sono molti più dettagli.
Ma dal punto di vista dell'implementazione del lato server,
ciò che abbiamo capito qui è sufficiente per capire come
configurare un server per utilizzare la comunicazione sicura tra il client e il server.
Ora, ovviamente la prima domanda che ti verrà in mente è
che il server ha bisogno di una chiave pubblica e una chiave privata.
Per una crittografia a chiave pubblica, in
che modo il server genera questo?
Se si esegue un vero server di produzione nel
proprio ambiente e si fornisce un servizio per gli utenti di accedere al server,
allora ovviamente è necessario passare attraverso il processo di certificazione.
Questo è il punto in cui ci si avvicina a un'autorità di certificazione, ad esempio
società come VeriSign e Thawte Corporation
che sono Autorità di certificazione pubbliche. Ce
ne sono altri in tutto il mondo.
Quindi, ti avvicinerai a loro,
e queste Autorità di certificazione autenticheranno le tue credenziali,
assicureranno che tu sia chi affermi di essere,
e quindi verificheranno le tue credenziali,
e poi a quel punto,
ti emetteranno una chiave pubblica e una chiave privata per l'uso sul sito del server.
Quindi, una volta rilasciata la chiave pubblica e la chiave privata,
la chiave pubblica sarà certificata dall'Autorità di certificazione,
e quindi la chiave pubblica porterà anche,
in aggiunta, il certificato.
Quindi, questo è il certificato che invierai al sito del client.
Dal momento che i client possono stabilire
l'autenticità di queste autorità di certificazione,
se si guarda a qualsiasi browser si noterà che la maggior parte dei browser avrà
i certificati per tutte queste autorità di certificazione stabilite
già incorporati in essi.
Quindi saranno in grado di stabilire le tue credenziali,
o meglio, saranno in grado di stabilire che la chiave privata appartiene a te,
ottenendo il tuo certificato e quindi controllando o verificando
il tuo certificato sapendo che è stato firmato da una
di queste Certificazioni stabilite Le autorita'.
In questo processo, il cliente sarà in grado di stabilire la tua autenticità.
Ora, in questo corso,
vogliamo solo capire come funziona ogni HTTPS
e vogliamo anche avere un modo semplice di
configurare il server con una chiave pubblica e la chiave privata.
Poiché stiamo facendo questo come un esercizio per capire HTTPS,
possiamo usare uno strumento chiamato SSL aperto che è già disponibile sui
nostri computer per generare quello che viene chiamato il certificato autofirmato.
Le chiavi autofirmate non sono accettabili nel lavoro esterno.
Ma poiché sappiamo che lo stiamo usando solo per i nostri scopi di test,
possiamo usare certificati autofirmati,
semplicemente per comprendere il processo
di comunicazione sicura tra client e server.
Quindi, come usiamo SSL aperto?
Finora usando SSL aperto puoi generare chiavi,
usando tre comandi che ti mostro qui.
Si eseguono questi tre comandi in quella sequenza,
come specificato qui e che vi aiuterà a generare
una chiave privata e un certificato che è possibile rendere disponibili dal
server HTTPS per i client da scaricare e
quindi ottenere la chiave pubblica per la comunicazione sicura.
Quindi questa è l'operazione che stiamo per fare nel nostro esercizio che segue
questa lezione per stabilire e rilasciare DPS service.Così i tre passi che facciamo è, in
primo luogo, genereremo la chiave privata utilizzando il primo comando.
Poi dopo che genereremo un cert.csr che verrà poi utilizzato
per noi per generare un certificato che
può essere distribuito al lato client dal terzo comando mostrato lì.
Quindi questi passaggi ti permetteranno di generare una chiave privata e
anche un certificato corrispondente che può essere rilasciato al client.
Ancora una volta per sottolineare, se si esegue un server di produzione,
è necessario ottenere una chiave pubblica, coppia di chiavi private,
da una delle autorità di certificazione come VeriSign e Thawte Corporation.
In che modo il nodo stesso funziona per aiutarci a configurare l'HTTPS?
Ora è qui che sto esaminando brevemente il codice che
useremo nell'esercizio che segue per impostare i nostri server. Il
nodo stesso ha l'HTTPS come modulo principale all'interno del nodo.
Quindi imposteremo HTTPS richiedendo questo modulo di base.
Useremo anche il modulo principale del file system perché
la chiave privata e il certificato che generiamo saranno memorizzati sul nostro lato server,
e saranno richiesti dalla
vostra applicazione esplicita per configurare il vostro server sicuro.
Quindi qui useremo il file system con
il metodo ReadFileSync per leggere nella chiave privata
e il certificato dai file che
generiamo utilizzando i passaggi che abbiamo visto nello slot precedente.
Quindi, una volta che questi due valori sono pronti,
le opzioni per il server HTTPS sono configurate e quindi è possibile configurare
il server sicuro per fornire comunicazioni basate su HTTPS dal sito server.
Ora che hai una rapida comprensione del funzionamento del tuo HTTPS
e del modo in cui sfrutta l'uso sia della crittografia a chiave pubblica che della
crittografia a chiave simmetrica per
garantire una comunicazione sicura tra il client e il server.
Passiamo all'esercizio per configurare effettivamente il
nostro server espresso che abbiamo costruito finora per utilizzare il protocollo HTTPS.