1 00:00:03,920 --> 00:00:06,615 Nel modulo precedente, 2 00:00:06,615 --> 00:00:10,905 abbiamo visto circa l'autenticazione utente in un sacco di dettaglio. 3 00:00:10,905 --> 00:00:17,610 Avevamo visto come l'utente invia le proprie credenziali al proprio server dal lato client 4 00:00:17,610 --> 00:00:20,270 nell'intestazione del 5 00:00:20,270 --> 00:00:24,870 messaggio di richiesta o nel corpo del messaggio di richiesta e quindi successivamente, 6 00:00:24,870 --> 00:00:26,460 quando vengono autenticati, il 7 00:00:26,460 --> 00:00:31,680 loro client includerà il cookie o il 8 00:00:31,680 --> 00:00:38,499 token in l'intestazione del messaggio di richiesta che va dal client al server. 9 00:00:38,499 --> 00:00:41,820 Sono sicuro che alcuni di voi stavano gridando per 10 00:00:41,820 --> 00:00:47,010 il fatto che stavamo comunicando su un canale insicuro, il 11 00:00:47,010 --> 00:00:50,520 che significa che chiunque seduto al centro che può 12 00:00:50,520 --> 00:00:54,780 ascoltare i propri messaggi tra il client 13 00:00:54,780 --> 00:00:57,570 e il server sarebbe facilmente in grado di acquisire 14 00:00:57,570 --> 00:01:03,195 le credenziali e poi impersonare il cliente autentico. 15 00:01:03,195 --> 00:01:04,815 Ovviamente, a quel punto, 16 00:01:04,815 --> 00:01:09,025 la loro enfasi era più sull'organizzazione della 17 00:01:09,025 --> 00:01:13,575 comunicazione client e server con l'autenticazione del client sul lato server. 18 00:01:13,575 --> 00:01:19,215 Ma ogni volta che è necessario utilizzare l'autenticazione utente 19 00:01:19,215 --> 00:01:21,945 , in primo luogo, sotto forma di, 20 00:01:21,945 --> 00:01:25,940 ad esempio, di fornire le credenziali per 21 00:01:25,940 --> 00:01:29,445 autenticarsi e successivamente, autenticarsi includendo 22 00:01:29,445 --> 00:01:33,840 il cookie o il token nell'intestazione del messaggio di richiesta, 23 00:01:33,840 --> 00:01:36,290 dovresti farlo su un canale sicuro. 24 00:01:36,290 --> 00:01:39,890 Non dovresti mai comunicare su un canale non sicuro, il 25 00:01:39,890 --> 00:01:44,160 che significa che non dovresti usare HTTP e quindi includere 26 00:01:44,160 --> 00:01:48,780 queste credenziali nell'intestazione o nel corpo dei messaggi di richiesta. 27 00:01:48,780 --> 00:01:56,455 Invece, dovresti usare una versione sicura del protocollo HTTP o HTTPS. 28 00:01:56,455 --> 00:02:01,830 Parliamo brevemente di HTTPS in questa lezione. 29 00:02:01,830 --> 00:02:07,140 Lungo la strada, ti darò un'introduzione di cinque minuti alla crittografia e alla sicurezza. 30 00:02:07,140 --> 00:02:12,143 Ovviamente, la crittografia e la sicurezza sono un argomento molto importante a sé stante. 31 00:02:12,143 --> 00:02:16,110 Ho solo intenzione di presentarti gli elementi essenziali che devi 32 00:02:16,110 --> 00:02:21,820 capire per imparare come funziona effettivamente HTTPS. 33 00:02:21,820 --> 00:02:29,430 Con questo background, procediamo a capire 34 00:02:29,430 --> 00:02:34,110 la crittografia e poi sul protocollo HTTPS e come si configura un server per utilizzare 35 00:02:34,110 --> 00:02:40,276 il protocollo HTTPS e quindi il client per contattare il server utilizzando il protocollo HTTPS, in 36 00:02:40,276 --> 00:02:45,165 tal modo, la comunicazione tra il client e il server può essere fatto in modo sicuro 37 00:02:45,165 --> 00:02:51,180 crittografando i dati inviati tra il client e il lato server. 38 00:02:51,180 --> 00:02:56,175 Quando ti avventurerai nel campo della crittografia e della sicurezza, 39 00:02:56,175 --> 00:03:00,375 sentirai spesso parlare di crittografia a chiave simmetrica. 40 00:03:00,375 --> 00:03:02,970 Ora, cosa comporta la crittografia? 41 00:03:02,970 --> 00:03:07,635 Se è necessario inviare un messaggio su un canale a un altro utente, 42 00:03:07,635 --> 00:03:10,800 si desidera essere in grado di crittografare il messaggio in 43 00:03:10,800 --> 00:03:14,310 modo tale che solo il destinatario sarà in grado di 44 00:03:14,310 --> 00:03:16,570 decrittografare il messaggio e ottenere 45 00:03:16,570 --> 00:03:21,050 le informazioni che si sta tentando di inviare al destinatario. 46 00:03:21,050 --> 00:03:26,730 Quindi sia il mittente che il destinatario dovrebbero capire su stabilire tra i due di 47 00:03:26,730 --> 00:03:32,930 loro come questo processo di crittografia e come funzionerà la decrittografia. 48 00:03:32,930 --> 00:03:34,365 Affinché ciò funzioni, 49 00:03:34,365 --> 00:03:41,265 qualsiasi crittografia e decrittografia funziona in base allo scambio di chiavi segrete. 50 00:03:41,265 --> 00:03:43,765 Quindi, nella crittografia a chiave simmetrica, 51 00:03:43,765 --> 00:03:50,678 sia il mittente che il destinatario condivideranno una chiave segreta tra i due siti, 52 00:03:50,678 --> 00:03:55,165 e questa chiave segreta è nota solo al mittente e al lato ricevitore. 53 00:03:55,165 --> 00:03:58,260 Quindi, quando il mittente deve inviare il messaggio, 54 00:03:58,260 --> 00:04:04,755 il mittente crittograferà questo messaggio utilizzando un algoritmo di crittografia, 55 00:04:04,755 --> 00:04:09,795 che utilizza la chiave segreta come altro input per questo algoritmo. 56 00:04:09,795 --> 00:04:13,875 E una volta passato questo messaggio attraverso questo algoritmo di crittografia, 57 00:04:13,875 --> 00:04:17,068 verrà generato un messaggio crittografato. 58 00:04:17,068 --> 00:04:24,160 Ora, questo messaggio crittografato verrà inviato al canale attraverso il lato ricevitore. 59 00:04:24,160 --> 00:04:28,140 Se hai un utente malintenzionato di terze parti 60 00:04:28,140 --> 00:04:32,450 seduto in mezzo e ascolta e cattura questo messaggio crittografato, 61 00:04:32,450 --> 00:04:34,740 sarebbe difficile decrittografare 62 00:04:34,740 --> 00:04:38,580 questo messaggio perché per decrittografare un messaggio crittografato, 63 00:04:38,580 --> 00:04:40,645 hai ancora bisogno della chiave segreta. 64 00:04:40,645 --> 00:04:42,375 Ora, sul lato ricevitore, 65 00:04:42,375 --> 00:04:44,856 quando viene ricevuto il messaggio crittografato, 66 00:04:44,856 --> 00:04:48,815 verrà applicato il ricevitore e un algoritmo di decrittografia, 67 00:04:48,815 --> 00:04:50,715 che prende anche come input, 68 00:04:50,715 --> 00:04:56,590 la stessa chiave segreta che è stata utilizzata sul lato mittente per crittografare il messaggio. 69 00:04:56,590 --> 00:05:00,585 Quindi, al momento della decrittografia, il messaggio originale verrà recuperato 70 00:05:00,585 --> 00:05:05,240 e può essere elaborato sul lato ricevitore. 71 00:05:05,240 --> 00:05:11,260 Ora, se una terza parte malintenzionata vuole decifrare questo messaggio crittografato, 72 00:05:11,260 --> 00:05:14,280 affronterà una battaglia in salita perché 73 00:05:14,280 --> 00:05:18,240 il processo di crittografia usando la chiave segreta trasformerà il messaggio e potrà, 74 00:05:18,240 --> 00:05:19,590 a sua volta, crittografare il messaggio. 75 00:05:19,590 --> 00:05:21,830 Senza possedere la chiave 76 00:05:21,830 --> 00:05:26,760 segreta, sarà quasi impossibile decrittografare il messaggio crittografato. 77 00:05:26,760 --> 00:05:30,200 Beh, questo è stretching andare un po 'lontano. 78 00:05:30,200 --> 00:05:35,490 Sarebbe inordinatamente difficile decrittografare il messaggio crittografato. 79 00:05:35,490 --> 00:05:39,210 Se usi tecniche di forza bruta, alla fine, 80 00:05:39,210 --> 00:05:43,245 finirai per decifrare il messaggio crittografato. 81 00:05:43,245 --> 00:05:48,880 Ma ci vorrà così tanto tempo e richiederà così tanta potenza di calcolo. 82 00:05:48,880 --> 00:05:53,175 Non varrà la pena per 83 00:05:53,175 --> 00:05:58,580 l'utente malintenzionato di terze parti provare a decodificare il messaggio crittografato. 84 00:05:58,580 --> 00:06:01,770 Quindi stai essenzialmente rendendo davvero difficile per qualcuno 85 00:06:01,770 --> 00:06:05,355 decrittografare il messaggio se non possiede la chiave segreta. 86 00:06:05,355 --> 00:06:09,480 Ora, poiché la chiave segreta è nota solo al mittente e al destinatario, 87 00:06:09,480 --> 00:06:12,390 le due parti finali, il mittente e il destinatario, 88 00:06:12,390 --> 00:06:16,335 possono comunicare con la certezza 89 00:06:16,335 --> 00:06:18,780 che nel messaggio crittografato 90 00:06:18,780 --> 00:06:22,240 dal lato mittente può essere decrittografato solo dal lato destinatario. 91 00:06:22,240 --> 00:06:25,485 Quindi questo è il modo in cui funziona la crittografia a chiave simmetrica. 92 00:06:25,485 --> 00:06:30,330 Il fatto che tu abbia la stessa chiave segreta condivisa tra 93 00:06:30,330 --> 00:06:32,400 il mittente e il destinatario significa che 94 00:06:32,400 --> 00:06:35,420 l'inclusione del processo di decrittografia ha utilizzato la stessa chiave segreta, 95 00:06:35,420 --> 00:06:38,911 quindi, crittografia a chiave simmetrica. 96 00:06:38,911 --> 00:06:41,395 Naturalmente, con la crittografia a chiave simmetrica, 97 00:06:41,395 --> 00:06:44,440 uno dei problemi è che sia il mittente che 98 00:06:44,440 --> 00:06:48,805 il destinatario devono avere accesso alla stessa chiave segreta. 99 00:06:48,805 --> 00:06:53,940 Ora, se il mittente e il destinatario comunicano su un canale insicuro, 100 00:06:53,940 --> 00:06:58,230 sarà difficile per entrambe le parti giungere ad una comprensione 101 00:06:58,230 --> 00:07:03,510 della stessa chiave segreta senza rivelarla ad altri. 102 00:07:03,510 --> 00:07:09,315 Quindi questo è dove un altro algoritmo chiamato crittografia a chiave pubblica è molto utile. 103 00:07:09,315 --> 00:07:12,195 Come funziona la crittografia a chiave pubblica? 104 00:07:12,195 --> 00:07:14,610 Ora, nella crittografia a chiave pubblica, 105 00:07:14,610 --> 00:07:17,595 l'idea è che tu abbia due chiavi diverse. 106 00:07:17,595 --> 00:07:21,085 Hai una chiave pubblica e una chiave privata. 107 00:07:21,085 --> 00:07:26,520 Ora, la chiave pubblica può essere ampiamente distribuita a chiunque tu desideri. 108 00:07:26,520 --> 00:07:29,335 Quindi, quando qualcuno vuole mandarti un messaggio, 109 00:07:29,335 --> 00:07:34,350 userà la tua chiave pubblica per crittografare il messaggio. 110 00:07:34,350 --> 00:07:39,795 Quindi, se un mittente qui vuole inviare il messaggio al destinatario, 111 00:07:39,795 --> 00:07:44,385 allora il mittente utilizzerà la chiave pubblica fuori dal ricevitore per 112 00:07:44,385 --> 00:07:50,240 crittografare il messaggio sul lato mittente utilizzando l'algoritmo di crittografia. 113 00:07:50,240 --> 00:07:53,100 Ora, una volta che il messaggio crittografato viene inviato attraverso 114 00:07:53,100 --> 00:07:56,640 il canale non sicuro al lato 115 00:07:56,640 --> 00:07:59,625 ricevitore, il ricevitore utilizzerà la chiave privata 116 00:07:59,625 --> 00:08:03,210 che solo il ricevitore conosce per decrittografare. 117 00:08:03,210 --> 00:08:06,645 Ora, affinché la crittografia a chiave pubblica funzioni come abbiamo visto, 118 00:08:06,645 --> 00:08:10,760 la chiave pubblica può essere ampiamente distribuita senza alcuna preoccupazione. 119 00:08:10,760 --> 00:08:14,150 Ma poiché la chiave privata è nota solo al lato ricevitore, 120 00:08:14,150 --> 00:08:19,325 solo il ricevitore sarà in grado di decrittografare il messaggio e, 121 00:08:19,325 --> 00:08:23,070 ancora una volta, un intruso di terze parti che cattura 122 00:08:23,070 --> 00:08:28,410 questo messaggio crittografato troverà inordinatamente difficile decifrare il messaggio. 123 00:08:28,410 --> 00:08:29,670 Ora, naturalmente nella crittografia a chiave pubblica, 124 00:08:29,670 --> 00:08:33,385 la chiave pubblica e la chiave privata sono due chiavi diverse. 125 00:08:33,385 --> 00:08:36,900 Ora, allora la tua ovvia domanda successiva sarebbe perché 126 00:08:36,900 --> 00:08:40,686 non usare semplicemente la crittografia a chiave pubblica per la crittografia. 127 00:08:40,686 --> 00:08:44,445 Il problema è che l'utilizzo della crittografia a chiave pubblica 128 00:08:44,445 --> 00:08:48,383 per la crittografia e la decrittografia è un processo costoso, 129 00:08:48,383 --> 00:08:54,890 ed è per questo che non usiamo la crittografia a chiave pubblica per l'intera comunicazione. 130 00:08:54,890 --> 00:09:00,600 Invece, la crittografia a chiave pubblica verrà utilizzata 131 00:09:00,600 --> 00:09:04,290 principalmente per il mittente e il destinatario per 132 00:09:04,290 --> 00:09:08,270 concordare la chiave segreta comune che i due utilizzeranno. 133 00:09:08,270 --> 00:09:12,210 In seguito vedremo come la crittografia a chiave pubblica 134 00:09:12,210 --> 00:09:16,380 può essere utilizzata per stabilire la chiave segreta comune 135 00:09:16,380 --> 00:09:19,845 tra il mittente e il destinatario e successivamente 136 00:09:19,845 --> 00:09:24,686 utilizzare la crittografia a chiave simmetrica per ulteriori comunicazioni. 137 00:09:24,686 --> 00:09:29,790 Un protocollo che utilizza questo approccio è Secure Sockets 138 00:09:29,790 --> 00:09:35,088 Layer e anche i protocolli di sicurezza Transport 139 00:09:35,088 --> 00:09:37,365 Layer, SSL e TLS in breve. 140 00:09:37,365 --> 00:09:40,395 Così tante volte quando leggi la documentazione, 141 00:09:40,395 --> 00:09:44,020 potresti sentire parlare di SSL e TLS. 142 00:09:44,020 --> 00:09:48,660 Questi protocolli di crittografia consentono una comunicazione sicura tra 143 00:09:48,660 --> 00:09:55,110 il mittente e il destinatario su una rete non sicura come Internet. 144 00:09:55,110 --> 00:10:03,150 Il mittente e il destinatario comunicheranno su Internet utilizzando messaggi crittografati, 145 00:10:03,150 --> 00:10:06,410 che solo il mittente e il destinatario possono decrittografare. 146 00:10:06,410 --> 00:10:09,266 E questo approccio, SSL o TLS, 147 00:10:09,266 --> 00:10:16,220 utilizza una combinazione di crittografia a chiave pubblica insieme alla crittografia a chiave simmetrica. 148 00:10:16,220 --> 00:10:18,905 Il loro processo esatto di fare questo, 149 00:10:18,905 --> 00:10:21,290 spiegherò nella prossima diapositiva. 150 00:10:21,290 --> 00:10:25,050 Inoltre, utilizzando SSL o TLS, 151 00:10:25,050 --> 00:10:27,415 stiamo cercando di mantenere due cose diverse. 152 00:10:27,415 --> 00:10:29,940 Stiamo, in primo luogo, cercando di mantenere la privacy 153 00:10:29,940 --> 00:10:32,880 della comunicazione tra il mittente e il destinatario in modo che 154 00:10:32,880 --> 00:10:39,165 nessun terzo malintenzionato possa estrarre il messaggio dal messaggio crittografato. 155 00:10:39,165 --> 00:10:42,150 In secondo luogo, stiamo anche cercando di mantenere l'integrità, 156 00:10:42,150 --> 00:10:44,550 il che significa che quando il mittente invia un messaggio, 157 00:10:44,550 --> 00:10:50,025 il destinatario sarà in grado di essere sicuro che il messaggio non è stato manomesso. 158 00:10:50,025 --> 00:10:57,145 Quindi sia la sicurezza che il mantenimento dell'integrità sono molto importanti in questo caso. 159 00:10:57,145 --> 00:11:01,110 Quindi sia la privacy che l'integrità devono essere mantenute da 160 00:11:01,110 --> 00:11:04,200 questo protocollo di comunicazione sicuro che costruiamo 161 00:11:04,200 --> 00:11:08,235 per lo scambio tra il mittente e il destinatario. 162 00:11:08,235 --> 00:11:13,865 Parliamo brevemente di come SSL o TLS funzionano effettivamente. 163 00:11:13,865 --> 00:11:22,585 Questo viene fatto attraverso un processo di handshaking che ho illustrato in questo diagramma qui. 164 00:11:22,585 --> 00:11:26,020 Quando un client desidera comunicare con il server, 165 00:11:26,020 --> 00:11:28,920 il client invia un messaggio al server, 166 00:11:28,920 --> 00:11:34,405 specificando che il client desidera comunicare con il server in modo sicuro. 167 00:11:34,405 --> 00:11:40,068 A questo punto, il server invierà il certificato al client, 168 00:11:40,068 --> 00:11:42,105 che contiene una chiave pubblica, 169 00:11:42,105 --> 00:11:43,800 che è stata certificata 170 00:11:43,800 --> 00:11:48,410 dall'autorità di certificazione come appartenente a quel particolare server. 171 00:11:48,410 --> 00:11:51,210 In questo modo, quando il client riceve 172 00:11:51,210 --> 00:11:56,325 questa chiave pubblica più la certificazione da parte dell'autorità di certificazione, 173 00:11:56,325 --> 00:11:59,960 il client sarà in grado di verificare le credenziali del server. 174 00:11:59,960 --> 00:12:03,510 Quindi, il client deve stabilire che sta realmente parlando con il server, 175 00:12:03,510 --> 00:12:07,345 con cui intende comunicare. 176 00:12:07,345 --> 00:12:09,040 Quindi, a questo punto, 177 00:12:09,040 --> 00:12:11,788 quando il client verifica le credenziali del server, 178 00:12:11,788 --> 00:12:17,110 il client ora ha accesso alla chiave pubblica del server. 179 00:12:17,110 --> 00:12:20,850 Una volta che il client ottiene la chiave pubblica del server, 180 00:12:20,850 --> 00:12:25,005 allora il client genererà ciò che viene chiamato come il segreto pre-master. 181 00:12:25,005 --> 00:12:28,560 Questo segreto pre-master è qualcosa che il client e il 182 00:12:28,560 --> 00:12:33,045 server utilizzeranno per generare ciò che viene chiamato come chiave di sessione. 183 00:12:33,045 --> 00:12:36,870 Quindi, il client genera un segreto pre-master, 184 00:12:36,870 --> 00:12:41,880 il client quindi crittografa quel segreto utilizzando la chiave pubblica del server 185 00:12:41,880 --> 00:12:44,880 e quindi invia il segreto al server. 186 00:12:44,880 --> 00:12:48,735 Ora, ricorda che una volta che il segreto viene crittografato usando la chiave pubblica, 187 00:12:48,735 --> 00:12:51,690 nessuno oltre al server sarà in grado di 188 00:12:51,690 --> 00:12:55,110 estrarre le informazioni dal messaggio crittografato. 189 00:12:55,110 --> 00:12:58,440 Quindi, quando il server riceve questo messaggio crittografato, 190 00:12:58,440 --> 00:13:03,300 il server estrae il segreto pre-master da questo messaggio. 191 00:13:03,300 --> 00:13:08,863 Ora, sia il client che il server possiedono lo stesso segreto pre-master. 192 00:13:08,863 --> 00:13:12,720 A questo punto, sia il client che il server utilizzeranno 193 00:13:12,720 --> 00:13:18,150 lo stesso insieme di passaggi a partire dal segreto del pre-master, 194 00:13:18,150 --> 00:13:20,902 e con lo stesso insieme di valori, 195 00:13:20,902 --> 00:13:24,230 che genererà una chiave chiamata come chiave di sessione. 196 00:13:24,230 --> 00:13:28,157 Ora, quando la chiave di sessione viene generata sia sul lato client che sul lato server, 197 00:13:28,157 --> 00:13:30,630 sarà esattamente la stessa chiave di sessione, 198 00:13:30,630 --> 00:13:36,565 perché entrambe seguiranno esattamente lo stesso processo per generare la chiave di sessione. 199 00:13:36,565 --> 00:13:37,950 Quindi, a questo punto, 200 00:13:37,950 --> 00:13:39,540 sia il client che il server, 201 00:13:39,540 --> 00:13:44,670 ora possiedono una chiave segreta che è la stessa su entrambi i siti. 202 00:13:44,670 --> 00:13:48,570 Quindi, tutte le comunicazioni successive tra il server e il client, 203 00:13:48,570 --> 00:13:52,599 possono quindi procedere utilizzando la crittografia simmetrica. 204 00:13:52,599 --> 00:13:55,035 Pertanto, quando il client deve comunicare con il server, 205 00:13:55,035 --> 00:13:59,640 il client crittograferà i dati utilizzando la chiave di sessione segreta 206 00:13:59,640 --> 00:14:01,340 e quindi invierà i loro dati. 207 00:14:01,340 --> 00:14:05,100 Allo stesso modo, quando il server deve comunicare con il client, 208 00:14:05,100 --> 00:14:07,440 il server utilizzerà ovviamente 209 00:14:07,440 --> 00:14:12,365 la stessa chiave di sessione per crittografare i dati e quindi inviarli al client. 210 00:14:12,365 --> 00:14:15,215 Ora, poiché il client possiede la stessa chiave di sessione, 211 00:14:15,215 --> 00:14:21,255 il client sarà in grado di decrittografare il messaggio ed estrarre il messaggio non crittografato. 212 00:14:21,255 --> 00:14:23,453 Utilizzando questa procedura, 213 00:14:23,453 --> 00:14:30,099 il client e il server hanno assicurato che la comunicazione tra di loro sia privata. 214 00:14:30,099 --> 00:14:33,930 Inoltre, riusciamo a garantire che nessuna terza parte malintenzionata possa 215 00:14:33,930 --> 00:14:38,310 intercettare il messaggio e causare eventuali modifiche al messaggio. 216 00:14:38,310 --> 00:14:41,125 Quindi, viene mantenuta anche l'integrità 217 00:14:41,125 --> 00:14:43,260 del messaggio e viene mantenuta anche la privacy 218 00:14:43,260 --> 00:14:46,108 della comunicazione tra il client e il server. 219 00:14:46,108 --> 00:14:50,970 Quindi, tutta questa discussione che vi ho presentato nelle ultime diapositive, 220 00:14:50,970 --> 00:14:52,635 è in poche parole, 221 00:14:52,635 --> 00:14:58,210 come garantire la comunicazione sicura tra il client e il server 222 00:14:58,210 --> 00:15:05,454 utilizzando la crittografia a chiave simmetrica e la crittografia a chiave pubblica. 223 00:15:05,454 --> 00:15:10,080 Ora, ovviamente, c'è molto di più di quello che ho spiegato qui, 224 00:15:10,080 --> 00:15:14,490 ma questa comprensione di come funziona la crittografia è 225 00:15:14,490 --> 00:15:19,540 sufficiente per capire come funziona l'intero processo. 226 00:15:19,540 --> 00:15:22,860 Ora, se siete interessati a saperne di più su questo, 227 00:15:22,860 --> 00:15:28,515 una buona fonte per conoscere i protocolli di crittografia è un ottimo libro 228 00:15:28,515 --> 00:15:34,800 di Jim Crozon Keith Ross chiamato Computer Networks. 229 00:15:34,800 --> 00:15:38,910 Questo libro ha un capitolo molto facile da capire 230 00:15:38,910 --> 00:15:44,995 sulla crittografia e la sicurezza come applicato alla comunicazione di rete. 231 00:15:44,995 --> 00:15:48,985 Ora che abbiamo stabilito il processo 232 00:15:48,985 --> 00:15:54,440 per essere in grado di comunicare in modo sicuro tra un client e un server, 233 00:15:54,440 --> 00:16:00,640 diamo un'occhiata a come Internet stesso sfrutta questo, 234 00:16:00,640 --> 00:16:05,320 per la comunicazione tra un client e il server utilizzando HTTP. 235 00:16:05,320 --> 00:16:09,950 Ora, questo è dove entra in scena il protocollo HTTPS. 236 00:16:09,950 --> 00:16:13,915 Come hai già capito su Internet, 237 00:16:13,915 --> 00:16:17,905 Internet è un'architettura a più livelli, 238 00:16:17,905 --> 00:16:22,165 in cui l'IP e il TCP formano la rete 239 00:16:22,165 --> 00:16:27,490 e il livello di trasporto che gira sulla rete sottostante. 240 00:16:27,490 --> 00:16:29,755 Ora, al di sopra del livello di trasporto, 241 00:16:29,755 --> 00:16:35,800 si ha il livello di socket sicuro o il rivestimento di sicurezza del livello 242 00:16:35,800 --> 00:16:39,265 di trasporto come strato sottile sopra il TCP che 243 00:16:39,265 --> 00:16:43,095 garantisce una comunicazione sicura tra il client e il server. 244 00:16:43,095 --> 00:16:45,492 E sopra di esso HTTP può essere eseguito. 245 00:16:45,492 --> 00:16:52,830 Quindi, HTTP implica essenzialmente HTTP più l'uso della crittografia, la 246 00:16:52,830 --> 00:16:56,073 decrittografia supportata tramite SSL e TLS. 247 00:16:56,073 --> 00:17:00,150 Ovviamente, anche per il protocollo HTTPS, 248 00:17:00,150 --> 00:17:01,530 ci sono molti più dettagli. 249 00:17:01,530 --> 00:17:05,745 Ma dal punto di vista dell'implementazione del lato server, 250 00:17:05,745 --> 00:17:12,075 ciò che abbiamo capito qui è sufficiente per capire come 251 00:17:12,075 --> 00:17:19,120 configurare un server per utilizzare la comunicazione sicura tra il client e il server. 252 00:17:19,120 --> 00:17:23,070 Ora, ovviamente la prima domanda che ti verrà in mente è 253 00:17:23,070 --> 00:17:25,800 che il server ha bisogno di una chiave pubblica e una chiave privata. 254 00:17:25,800 --> 00:17:27,360 Per una crittografia a chiave pubblica, in 255 00:17:27,360 --> 00:17:29,330 che modo il server genera questo? 256 00:17:29,330 --> 00:17:32,265 Se si esegue un vero server di produzione nel 257 00:17:32,265 --> 00:17:36,792 proprio ambiente e si fornisce un servizio per gli utenti di accedere al server, 258 00:17:36,792 --> 00:17:40,525 allora ovviamente è necessario passare attraverso il processo di certificazione. 259 00:17:40,525 --> 00:17:45,100 Questo è il punto in cui ci si avvicina a un'autorità di certificazione, ad esempio 260 00:17:45,100 --> 00:17:48,915 società come VeriSign e Thawte Corporation 261 00:17:48,915 --> 00:17:53,630 che sono Autorità di certificazione pubbliche. Ce 262 00:17:53,630 --> 00:17:55,987 ne sono altri in tutto il mondo. 263 00:17:55,987 --> 00:17:58,160 Quindi, ti avvicinerai a loro, 264 00:17:58,160 --> 00:18:03,960 e queste Autorità di certificazione autenticheranno le tue credenziali, 265 00:18:03,960 --> 00:18:07,220 assicureranno che tu sia chi affermi di essere, 266 00:18:07,220 --> 00:18:09,285 e quindi verificheranno le tue credenziali, 267 00:18:09,285 --> 00:18:10,680 e poi a quel punto, 268 00:18:10,680 --> 00:18:18,725 ti emetteranno una chiave pubblica e una chiave privata per l'uso sul sito del server. 269 00:18:18,725 --> 00:18:21,705 Quindi, una volta rilasciata la chiave pubblica e la chiave privata, 270 00:18:21,705 --> 00:18:27,010 la chiave pubblica sarà certificata dall'Autorità di certificazione, 271 00:18:27,010 --> 00:18:30,540 e quindi la chiave pubblica porterà anche, 272 00:18:30,540 --> 00:18:32,626 in aggiunta, il certificato. 273 00:18:32,626 --> 00:18:38,165 Quindi, questo è il certificato che invierai al sito del client. 274 00:18:38,165 --> 00:18:43,935 Dal momento che i client possono stabilire 275 00:18:43,935 --> 00:18:48,446 l'autenticità di queste autorità di certificazione, 276 00:18:48,446 --> 00:18:52,950 se si guarda a qualsiasi browser si noterà che la maggior parte dei browser avrà 277 00:18:52,950 --> 00:18:58,115 i certificati per tutte queste autorità di certificazione stabilite 278 00:18:58,115 --> 00:18:59,715 già incorporati in essi. 279 00:18:59,715 --> 00:19:03,685 Quindi saranno in grado di stabilire le tue credenziali, 280 00:19:03,685 --> 00:19:07,605 o meglio, saranno in grado di stabilire che la chiave privata appartiene a te, 281 00:19:07,605 --> 00:19:12,540 ottenendo il tuo certificato e quindi controllando o verificando 282 00:19:12,540 --> 00:19:16,620 il tuo certificato sapendo che è stato firmato da una 283 00:19:16,620 --> 00:19:20,955 di queste Certificazioni stabilite Le autorita'. 284 00:19:20,955 --> 00:19:26,370 In questo processo, il cliente sarà in grado di stabilire la tua autenticità. 285 00:19:26,370 --> 00:19:27,870 Ora, in questo corso, 286 00:19:27,870 --> 00:19:31,125 vogliamo solo capire come funziona ogni HTTPS 287 00:19:31,125 --> 00:19:34,050 e vogliamo anche avere un modo semplice di 288 00:19:34,050 --> 00:19:38,460 configurare il server con una chiave pubblica e la chiave privata. 289 00:19:38,460 --> 00:19:43,791 Poiché stiamo facendo questo come un esercizio per capire HTTPS, 290 00:19:43,791 --> 00:19:48,690 possiamo usare uno strumento chiamato SSL aperto che è già disponibile sui 291 00:19:48,690 --> 00:19:55,375 nostri computer per generare quello che viene chiamato il certificato autofirmato. 292 00:19:55,375 --> 00:19:59,780 Le chiavi autofirmate non sono accettabili nel lavoro esterno. 293 00:19:59,780 --> 00:20:03,705 Ma poiché sappiamo che lo stiamo usando solo per i nostri scopi di test, 294 00:20:03,705 --> 00:20:06,300 possiamo usare certificati autofirmati, 295 00:20:06,300 --> 00:20:08,685 semplicemente per comprendere il processo 296 00:20:08,685 --> 00:20:12,910 di comunicazione sicura tra client e server. 297 00:20:12,910 --> 00:20:15,405 Quindi, come usiamo SSL aperto? 298 00:20:15,405 --> 00:20:18,585 Finora usando SSL aperto puoi generare chiavi, 299 00:20:18,585 --> 00:20:22,680 usando tre comandi che ti mostro qui. 300 00:20:22,680 --> 00:20:26,475 Si eseguono questi tre comandi in quella sequenza, 301 00:20:26,475 --> 00:20:30,020 come specificato qui e che vi aiuterà a generare 302 00:20:30,020 --> 00:20:34,990 una chiave privata e un certificato che è possibile rendere disponibili dal 303 00:20:34,990 --> 00:20:38,910 server HTTPS per i client da scaricare e 304 00:20:38,910 --> 00:20:44,555 quindi ottenere la chiave pubblica per la comunicazione sicura. 305 00:20:44,555 --> 00:20:48,510 Quindi questa è l'operazione che stiamo per fare nel nostro esercizio che segue 306 00:20:48,510 --> 00:20:54,510 questa lezione per stabilire e rilasciare DPS service.Così i tre passi che facciamo è, in 307 00:20:54,510 --> 00:20:59,740 primo luogo, genereremo la chiave privata utilizzando il primo comando. 308 00:20:59,740 --> 00:21:07,980 Poi dopo che genereremo un cert.csr che verrà poi utilizzato 309 00:21:07,980 --> 00:21:12,090 per noi per generare un certificato che 310 00:21:12,090 --> 00:21:16,720 può essere distribuito al lato client dal terzo comando mostrato lì. 311 00:21:16,720 --> 00:21:22,545 Quindi questi passaggi ti permetteranno di generare una chiave privata e 312 00:21:22,545 --> 00:21:30,590 anche un certificato corrispondente che può essere rilasciato al client. 313 00:21:30,590 --> 00:21:34,094 Ancora una volta per sottolineare, se si esegue un server di produzione, 314 00:21:34,094 --> 00:21:38,610 è necessario ottenere una chiave pubblica, coppia di chiavi private, 315 00:21:38,610 --> 00:21:44,205 da una delle autorità di certificazione come VeriSign e Thawte Corporation. 316 00:21:44,205 --> 00:21:50,400 In che modo il nodo stesso funziona per aiutarci a configurare l'HTTPS? 317 00:21:50,400 --> 00:21:54,900 Ora è qui che sto esaminando brevemente il codice che 318 00:21:54,900 --> 00:22:00,357 useremo nell'esercizio che segue per impostare i nostri server. Il 319 00:22:00,357 --> 00:22:07,910 nodo stesso ha l'HTTPS come modulo principale all'interno del nodo. 320 00:22:07,910 --> 00:22:11,815 Quindi imposteremo HTTPS richiedendo questo modulo di base. 321 00:22:11,815 --> 00:22:15,410 Useremo anche il modulo principale del file system perché 322 00:22:15,410 --> 00:22:20,760 la chiave privata e il certificato che generiamo saranno memorizzati sul nostro lato server, 323 00:22:20,760 --> 00:22:23,250 e saranno richiesti dalla 324 00:22:23,250 --> 00:22:28,170 vostra applicazione esplicita per configurare il vostro server sicuro. 325 00:22:28,170 --> 00:22:30,810 Quindi qui useremo il file system con 326 00:22:30,810 --> 00:22:36,135 il metodo ReadFileSync per leggere nella chiave privata 327 00:22:36,135 --> 00:22:40,440 e il certificato dai file che 328 00:22:40,440 --> 00:22:45,380 generiamo utilizzando i passaggi che abbiamo visto nello slot precedente. 329 00:22:45,380 --> 00:22:48,780 Quindi, una volta che questi due valori sono pronti, 330 00:22:48,780 --> 00:22:54,930 le opzioni per il server HTTPS sono configurate e quindi è possibile configurare 331 00:22:54,930 --> 00:23:02,225 il server sicuro per fornire comunicazioni basate su HTTPS dal sito server. 332 00:23:02,225 --> 00:23:07,680 Ora che hai una rapida comprensione del funzionamento del tuo HTTPS 333 00:23:07,680 --> 00:23:12,120 e del modo in cui sfrutta l'uso sia della crittografia a chiave pubblica che della 334 00:23:12,120 --> 00:23:14,970 crittografia a chiave simmetrica per 335 00:23:14,970 --> 00:23:18,545 garantire una comunicazione sicura tra il client e il server. 336 00:23:18,545 --> 00:23:21,885 Passiamo all'esercizio per configurare effettivamente il 337 00:23:21,885 --> 00:23:29,230 nostro server espresso che abbiamo costruito finora per utilizzare il protocollo HTTPS.