1 00:00:03,920 --> 00:00:06,615 Im vorherigen Modul 2 00:00:06,615 --> 00:00:10,905 haben wir über die Benutzerauthentifizierung in vielen Details gesehen. 3 00:00:10,905 --> 00:00:17,610 Wir hatten gesehen, wie der Benutzer seine Anmeldeinformationen von der Client-Seite 4 00:00:17,610 --> 00:00:20,270 entweder im Header 5 00:00:20,270 --> 00:00:26,460 seiner Anforderungsnachricht oder im Text der Anforderungsnachricht an 6 00:00:26,460 --> 00:00:31,680 seinen Server sendet und dann, wenn sie authentifiziert werden, dann wird sein Client entweder das Cookie oder das 7 00:00:31,680 --> 00:00:38,499 Token in der Header der Anforderungsnachricht, die vom Client zum Server geht. 8 00:00:38,499 --> 00:00:41,820 Ich bin sicher, dass einige von Ihnen über 9 00:00:41,820 --> 00:00:47,010 die Tatsache, dass wir über einen unsicheren Kanal kommunizieren, 10 00:00:47,010 --> 00:00:50,520 was bedeutet, dass jeder, der in der Mitte sitzt, der 11 00:00:50,520 --> 00:00:54,780 seine Nachrichten hören kann, die zwischen dem Client 12 00:00:54,780 --> 00:00:57,570 und dem Server gehen, leicht in der Lage sein würde, 13 00:00:57,570 --> 00:01:03,195 die Anmeldeinformationen zu erfassen und dann den echten Kunden ausgeben. 14 00:01:03,195 --> 00:01:04,815 Natürlich 15 00:01:04,815 --> 00:01:09,025 lag ihr Schwerpunkt zu diesem Zeitpunkt eher auf der Anordnung der Client- und 16 00:01:09,025 --> 00:01:13,575 Server-Kommunikation mit der Authentifizierung des Clients auf der Serverseite. 17 00:01:13,575 --> 00:01:19,215 Aber jedes Mal, wenn Sie 18 00:01:19,215 --> 00:01:21,945 die Benutzerauthentifizierung verwenden müssen, zuerst in Form von, sagen wir, 19 00:01:21,945 --> 00:01:25,940 die Anmeldeinformationen angeben, um sich selbst zu 20 00:01:25,940 --> 00:01:29,445 authentifizieren und danach, indem Sie entweder das Cookie oder das 21 00:01:29,445 --> 00:01:33,840 Token in den Header der Anforderungsnachricht einschließen, 22 00:01:33,840 --> 00:01:36,290 sollten Sie dies über eine sicherer Kanal. 23 00:01:36,290 --> 00:01:39,890 Sie sollten niemals über einen unsicheren Kanal kommunizieren, 24 00:01:39,890 --> 00:01:44,160 was bedeutet, dass Sie HTTP nicht verwenden sollten und 25 00:01:44,160 --> 00:01:48,780 diese Anmeldeinformationen dann entweder in den Header oder den Text der Anforderungsnachrichten aufnehmen sollten. 26 00:01:48,780 --> 00:01:56,455 Stattdessen sollten Sie eine sichere Version des HTTP-Protokolls oder des HTTPS verwenden. 27 00:01:56,455 --> 00:02:01,830 Lassen Sie uns kurz über HTTPS in dieser Vorlesung sprechen. 28 00:02:01,830 --> 00:02:07,140 Auf dem Weg werde ich Ihnen eine fünfminütige Einführung in Kryptographie und Sicherheit geben. 29 00:02:07,140 --> 00:02:12,143 Offensichtlich ist Kryptographie und Sicherheit ein sehr großes Thema für sich. 30 00:02:12,143 --> 00:02:16,110 Ich werde Ihnen nur das Wesentliche vorstellen, das Sie 31 00:02:16,110 --> 00:02:21,820 verstehen müssen, um zu lernen, wie HTTPS tatsächlich funktioniert. 32 00:02:21,820 --> 00:02:29,430 Vor diesem Hintergrund gehen wir über Kryptografie und dann auf 33 00:02:29,430 --> 00:02:34,110 das HTTPS-Protokoll zu verstehen und wie Sie einen Server konfigurieren würden, um 34 00:02:34,110 --> 00:02:40,276 das HTTPS-Protokoll zu verwenden und dann den Client, um den Server über das HTTPS-Protokoll zu kontaktieren 35 00:02:40,276 --> 00:02:45,165 , wodurch die Kommunikation zwischen dem Client und dem Server kann auf sichere Weise, 36 00:02:45,165 --> 00:02:51,180 indem die zwischen dem Client und der Serverseite gesendeten Daten verschlüsselt werden. 37 00:02:51,180 --> 00:02:56,175 Wenn Sie sich in den Bereichen Kryptografie und Sicherheit wagen, 38 00:02:56,175 --> 00:03:00,375 hören Sie oft Leute, die über symmetrische Schlüsselkryptografie sprechen. 39 00:03:00,375 --> 00:03:02,970 Was beinhaltet Kryptographie? 40 00:03:02,970 --> 00:03:07,635 Wenn Sie eine Nachricht über einen Kanal an einen anderen Benutzer senden müssen, 41 00:03:07,635 --> 00:03:10,800 dann möchten Sie in der Lage sein, die Nachricht 42 00:03:10,800 --> 00:03:14,310 so zu verschlüsseln, dass nur der Empfänger in der Lage ist, 43 00:03:14,310 --> 00:03:16,570 die Nachricht zu entschlüsseln und 44 00:03:16,570 --> 00:03:21,050 die Informationen zu erhalten, die Sie an den Empfänger senden möchten. 45 00:03:21,050 --> 00:03:26,730 So sollten sowohl der Sender als auch der Empfänger zwischen den beiden verstehen, 46 00:03:26,730 --> 00:03:32,930 wie dieser Verschlüsselungsprozess und wie die Entschlüsselung funktionieren wird. 47 00:03:32,930 --> 00:03:34,365 Damit dies funktioniert, funktioniert 48 00:03:34,365 --> 00:03:41,265 jede Verschlüsselung und Entschlüsselung basierend auf dem Austausch von geheimen Schlüsseln. 49 00:03:41,265 --> 00:03:43,765 In der symmetrischen Schlüsselkryptografie 50 00:03:43,765 --> 00:03:50,678 teilen sich sowohl der Sender als auch der Empfänger einen geheimen Schlüssel zwischen den beiden Seiten, 51 00:03:50,678 --> 00:03:55,165 und dieser geheime Schlüssel ist nur dem Absender und der Empfängerseite bekannt. 52 00:03:55,165 --> 00:03:58,260 Wenn also der Absender die Nachricht senden muss, 53 00:03:58,260 --> 00:04:04,755 verschlüsselt der Absender diese Nachricht mit einem Kryptografiealgorithmus, 54 00:04:04,755 --> 00:04:09,795 der den geheimen Schlüssel als die andere Eingabe für diesen Algorithmus verwendet. 55 00:04:09,795 --> 00:04:13,875 Und sobald diese Nachricht durch diesen Kryptografie-Algorithmus übergeben 56 00:04:13,875 --> 00:04:17,068 wird, wird eine verschlüsselte Nachricht generiert. 57 00:04:17,068 --> 00:04:24,160 Nun wird diese verschlüsselte Nachricht an den Kanal über die Empfängerseite gesendet. 58 00:04:24,160 --> 00:04:28,140 Wenn ein böswilliger Drittanbieter 59 00:04:28,140 --> 00:04:32,450 zwischendurch sitzt und diese verschlüsselte Nachricht abhört und erfasst, 60 00:04:32,450 --> 00:04:34,740 wäre es schwierig, 61 00:04:34,740 --> 00:04:38,580 diese Nachricht zu entschlüsseln, da 62 00:04:38,580 --> 00:04:40,645 Sie für die Entschlüsselung einer verschlüsselten Nachricht immer noch den geheimen Schlüssel benötigen. 63 00:04:40,645 --> 00:04:42,375 Nun, auf der Empfängerseite, 64 00:04:42,375 --> 00:04:44,856 wenn die verschlüsselte Nachricht empfangen wird, 65 00:04:44,856 --> 00:04:48,815 dann wird der Empfänger angewendet und ein Entschlüsselungsalgorithmus 66 00:04:48,815 --> 00:04:50,715 , der auch als Eingabe den 67 00:04:50,715 --> 00:04:56,590 gleichen geheimen Schlüssel nimmt, der auf der Senderseite verwendet wurde, um die Nachricht zu verschlüsseln. 68 00:04:56,590 --> 00:05:00,585 So wird bei der Entschlüsselung die ursprüngliche Nachricht abgerufen 69 00:05:00,585 --> 00:05:05,240 und kann auf der Empfängerseite verarbeitet werden. 70 00:05:05,240 --> 00:05:11,260 Nun, wenn ein böswilliger Dritter diese verschlüsselte Nachricht entschlüsseln möchte, 71 00:05:11,260 --> 00:05:14,280 werden sie sich einer ansteigenden Schlacht stellen, weil 72 00:05:14,280 --> 00:05:18,240 der Prozess der Verschlüsselung mit dem geheimen Schlüssel die Nachricht umdreht und 73 00:05:18,240 --> 00:05:19,590 die Nachricht wiederum verschlüsseln kann. 74 00:05:19,590 --> 00:05:21,830 Ohne den geheimen Schlüssel 75 00:05:21,830 --> 00:05:26,760 zu besitzen, wird es fast unmöglich sein, die verschlüsselte Nachricht zu entschlüsseln. 76 00:05:26,760 --> 00:05:30,200 Nun, das ist Stretching ein bisschen weit zu bekommen. 77 00:05:30,200 --> 00:05:35,490 Es wäre übermäßig schwierig, die verschlüsselte Nachricht zu entschlüsseln. 78 00:05:35,490 --> 00:05:39,210 Wenn Sie Brute-Force-Techniken verwenden, 79 00:05:39,210 --> 00:05:43,245 werden Sie schließlich die verschlüsselte Nachricht entschlüsseln. 80 00:05:43,245 --> 00:05:48,880 Aber es wird so lange dauern und so viel Rechenleistung erfordern. 81 00:05:48,880 --> 00:05:53,175 Es lohnt sich nicht, den 82 00:05:53,175 --> 00:05:58,580 böswilligen Drittanbieter-Benutzer zu versuchen, die verschlüsselte Nachricht zu entschlüsseln. 83 00:05:58,580 --> 00:06:01,770 Also machen Sie es im Wesentlichen schwierig für jemanden, 84 00:06:01,770 --> 00:06:05,355 die Nachricht zu entschlüsseln, wenn sie nicht den geheimen Schlüssel besitzen. 85 00:06:05,355 --> 00:06:12,390 Da nun der geheime Schlüssel nur dem Sender und dem Empfänger bekannt ist, 86 00:06:12,390 --> 00:06:16,335 können die beiden Endparteien, der Sender und der Empfänger, mit der Sicherheit kommunizieren, 87 00:06:16,335 --> 00:06:18,780 dass in verschlüsselter Nachricht von 88 00:06:18,780 --> 00:06:22,240 der Senderseite nur von der Empfängerseite entschlüsselt werden kann. 89 00:06:22,240 --> 00:06:25,485 So funktioniert die symmetrische Schlüsselkryptographie. 90 00:06:25,485 --> 00:06:30,330 Die Tatsache, dass Sie den gleichen geheimen Schlüssel haben, 91 00:06:30,330 --> 00:06:32,400 der zwischen dem Sender und dem Empfänger geteilt wird, bedeutet, dass 92 00:06:32,400 --> 00:06:35,420 die Aufnahme des Entschlüsselungsprozesses den gleichen geheimen Schlüssel verwendet 93 00:06:35,420 --> 00:06:38,911 , daher symmetrische Schlüsselkryptografie. 94 00:06:38,911 --> 00:06:41,395 Natürlich ist bei der symmetrischen Schlüsselkryptografie 95 00:06:41,395 --> 00:06:44,440 eines der Probleme, dass sowohl der Sender als auch 96 00:06:44,440 --> 00:06:48,805 der Empfänger Zugriff auf denselben geheimen Schlüssel haben müssen. 97 00:06:48,805 --> 00:06:53,940 Nun, wenn Sender und Empfänger über einen unsicheren Kanal kommunizieren, 98 00:06:53,940 --> 00:06:58,230 wird es für beide Seiten schwierig sein, zu einem Verständnis 99 00:06:58,230 --> 00:07:03,510 über denselben geheimen Schlüssel zu kommen, ohne ihn anderen zu offenbaren. 100 00:07:03,510 --> 00:07:09,315 Dies ist also, wo ein anderer Algorithmus namens Public-Key-Kryptografie sehr nützlich ist. 101 00:07:09,315 --> 00:07:12,195 Wie funktioniert Public-Key-Kryptografie? 102 00:07:12,195 --> 00:07:14,610 Nun, in der Public-Key-Kryptografie, 103 00:07:14,610 --> 00:07:17,595 ist die Idee, dass Sie zwei verschiedene Schlüssel haben. 104 00:07:17,595 --> 00:07:21,085 Sie haben einen öffentlichen Schlüssel und einen privaten Schlüssel. 105 00:07:21,085 --> 00:07:26,520 Nun kann der öffentliche Schlüssel an jeden, den Sie wollen, weit verbreitet werden. 106 00:07:26,520 --> 00:07:29,335 Wenn also jemand eine Nachricht an Sie senden möchte, 107 00:07:29,335 --> 00:07:34,350 wird er Ihren öffentlichen Schlüssel verwenden, um die Nachricht zu verschlüsseln. 108 00:07:34,350 --> 00:07:39,795 Wenn also ein Absender hier die Nachricht an den Empfänger senden möchte, 109 00:07:39,795 --> 00:07:44,385 verwendet der Absender den öffentlichen Schlüssel vom Empfänger, um die 110 00:07:44,385 --> 00:07:50,240 Nachricht auf der Senderseite mit dem Verschlüsselungsalgorithmus zu verschlüsseln. 111 00:07:50,240 --> 00:07:53,100 Sobald die verschlüsselte Nachricht 112 00:07:53,100 --> 00:07:56,640 über den unsicheren Kanal an die Empfängerseite gesendet 113 00:07:56,640 --> 00:07:59,625 wird, verwendet der Empfänger dann den privaten Schlüssel 114 00:07:59,625 --> 00:08:03,210 , den nur der Empfänger kennt, um zu entschlüsseln. 115 00:08:03,210 --> 00:08:06,645 Damit die Kryptografie mit öffentlichen Schlüsseln funktioniert, wie wir gesehen haben, 116 00:08:06,645 --> 00:08:10,760 kann der öffentliche Schlüssel ohne Bedenken weit verbreitet werden. 117 00:08:10,760 --> 00:08:14,150 Da der private Schlüssel jedoch nur der Empfängerseite bekannt ist, 118 00:08:14,150 --> 00:08:19,325 kann nur der Empfänger die Nachricht entschlüsseln, und 119 00:08:19,325 --> 00:08:23,070 wieder ein Drittanbieter-Eindringling, der 120 00:08:23,070 --> 00:08:28,410 diese verschlüsselte Nachricht erfasst, wird es unordentlich schwierig finden, die Nachricht zu entschlüsseln. 121 00:08:28,410 --> 00:08:29,670 Nun, natürlich in der Public-Key-Kryptografie, 122 00:08:29,670 --> 00:08:33,385 der öffentliche und der private Schlüssel sind zwei verschiedene Schlüssel. 123 00:08:33,385 --> 00:08:36,900 Nun, dann wäre Ihre offensichtliche nächste Frage, warum 124 00:08:36,900 --> 00:08:40,686 nicht einfach Public-Key-Kryptografie für die Verschlüsselung verwenden. 125 00:08:40,686 --> 00:08:44,445 Das Problem ist, dass die Verwendung von 126 00:08:44,445 --> 00:08:48,383 Public-Key-Kryptografie für Verschlüsselung und Entschlüsselung ein teurer Prozess 127 00:08:48,383 --> 00:08:54,890 ist, und deshalb verwenden wir keine Public-Key-Kryptografie für ihre gesamte Kommunikation. 128 00:08:54,890 --> 00:09:00,600 Stattdessen wird die Public-Key-Kryptografie 129 00:09:00,600 --> 00:09:04,290 hauptsächlich für den Sender und den Empfänger verwendet werden, um sich 130 00:09:04,290 --> 00:09:08,270 auf den gemeinsamen geheimen Schlüssel zu einigen, den die beiden verwenden werden. 131 00:09:08,270 --> 00:09:12,210 Wir werden später sehen, wie die Public-Key-Kryptografie 132 00:09:12,210 --> 00:09:16,380 verwendet werden kann, um den gemeinsamen geheimen Schlüssel 133 00:09:16,380 --> 00:09:19,845 zwischen dem Sender und dem Empfänger zu etablieren und anschließend 134 00:09:19,845 --> 00:09:24,686 symmetrische Schlüsselkryptographie für die weitere Kommunikation zu verwenden. 135 00:09:24,686 --> 00:09:29,790 Ein Protokoll, das diesen Ansatz verwendet, ist die Secure Sockets 136 00:09:29,790 --> 00:09:35,088 Layer und auch die Transport Layer Sicherheitsprotokolle, 137 00:09:35,088 --> 00:09:37,365 SSL und TLS kurz. 138 00:09:37,365 --> 00:09:40,395 So oft, wenn Sie die Dokumentation lesen, 139 00:09:40,395 --> 00:09:44,020 hören Sie vielleicht etwas über SSL und TLS. 140 00:09:44,020 --> 00:09:48,660 Diese Kryptografieprotokolle ermöglichen eine sichere Kommunikation zwischen 141 00:09:48,660 --> 00:09:55,110 Sender und Empfänger über ein unsicheres Netzwerk wie das Internet. 142 00:09:55,110 --> 00:10:03,150 Der Sender und der Empfänger kommunizieren über dieses Internet mit verschlüsselten Nachrichten, 143 00:10:03,150 --> 00:10:06,410 die nur der Absender und der Empfänger entschlüsseln können. 144 00:10:06,410 --> 00:10:09,266 Und dieser Ansatz, entweder das SSL oder TLS, 145 00:10:09,266 --> 00:10:16,220 verwendet eine Kombination aus Public-Key-Kryptografie zusammen mit symmetrischer Schlüsselkryptografie. 146 00:10:16,220 --> 00:10:18,905 Ihren genauen Prozess, dies zu tun, 147 00:10:18,905 --> 00:10:21,290 werde ich in der nächsten Folie erklären. 148 00:10:21,290 --> 00:10:25,050 Darüber hinaus 149 00:10:25,050 --> 00:10:27,415 versuchen wir mit SSL oder TLS, zwei verschiedene Dinge zu pflegen. 150 00:10:27,415 --> 00:10:29,940 Wir versuchen zunächst, die Privatsphäre der 151 00:10:29,940 --> 00:10:32,880 Kommunikation zwischen dem Absender und dem Empfänger zu wahren, so dass 152 00:10:32,880 --> 00:10:39,165 kein böswilliger Dritter die Nachricht aus der verschlüsselten Nachricht extrahieren kann. 153 00:10:39,165 --> 00:10:42,150 Zweitens versuchen wir auch, die Integrität aufrechtzuerhalten, 154 00:10:42,150 --> 00:10:44,550 was bedeutet, dass 155 00:10:44,550 --> 00:10:50,025 der Empfänger beim Senden einer Nachricht sicher sein kann, dass die Nachricht nicht manipuliert wurde. 156 00:10:50,025 --> 00:10:57,145 Daher ist in diesem Fall sowohl die Sicherheit als auch die Aufrechterhaltung der Integrität sehr wichtig. 157 00:10:57,145 --> 00:11:01,110 Daher müssen sowohl Privatsphäre als auch Integrität durch 158 00:11:01,110 --> 00:11:04,200 dieses sichere Kommunikationsprotokoll aufrechterhalten werden, das wir 159 00:11:04,200 --> 00:11:08,235 für den Austausch zwischen Sender und Empfänger erstellen. 160 00:11:08,235 --> 00:11:13,865 Lassen Sie uns kurz darüber sprechen, wie SSL oder TLS tatsächlich funktionieren. 161 00:11:13,865 --> 00:11:22,585 Dies geschieht durch einen Handshaking-Prozess, den ich hier in diesem Diagramm veranschaulicht habe. 162 00:11:22,585 --> 00:11:26,020 Wenn ein Client mit dem Server kommunizieren möchte, 163 00:11:26,020 --> 00:11:28,920 sendet der Client eine Nachricht an den Server, in der 164 00:11:28,920 --> 00:11:34,405 angegeben wird, dass der Client sicher mit dem Server kommunizieren möchte. 165 00:11:34,405 --> 00:11:40,068 Zu diesem Zeitpunkt sendet der Server das Zertifikat an den Client zurück 166 00:11:40,068 --> 00:11:42,105 , der einen öffentlichen Schlüssel 167 00:11:42,105 --> 00:11:43,800 enthält, 168 00:11:43,800 --> 00:11:48,410 der von der Zertifizierungsstelle als zu diesem bestimmten Server gehört. 169 00:11:48,410 --> 00:11:51,210 Auf diese Weise kann der Client, wenn der Client 170 00:11:51,210 --> 00:11:56,325 diesen öffentlichen Schlüssel und die Zertifizierung durch 171 00:11:56,325 --> 00:11:59,960 die Zertifizierungsstelle erhält, die Anmeldeinformationen des Servers überprüfen. 172 00:11:59,960 --> 00:12:03,510 Der Client muss also feststellen, dass er wirklich mit dem Server spricht, 173 00:12:03,510 --> 00:12:07,345 mit dem er kommunizieren will. 174 00:12:07,345 --> 00:12:09,040 An diesem Punkt, 175 00:12:09,040 --> 00:12:11,788 wenn der Client die Anmeldeinformationen des Servers überprüft, 176 00:12:11,788 --> 00:12:17,110 hat der Client nun Zugriff auf den öffentlichen Schlüssel des Servers. 177 00:12:17,110 --> 00:12:20,850 Sobald der Client den öffentlichen Schlüssel des Servers erhält, 178 00:12:20,850 --> 00:12:25,005 generiert der Client das, was als Pre-Master-Geheimnis bezeichnet wird. 179 00:12:25,005 --> 00:12:28,560 Dieses Pre-Master-Geheimnis ist etwas, das sowohl der Client 180 00:12:28,560 --> 00:12:33,045 als auch der Server verwenden, um einen sogenannten Sitzungsschlüssel zu generieren. 181 00:12:33,045 --> 00:12:36,870 So generiert der Client ein Pre-Master-Geheimnis, 182 00:12:36,870 --> 00:12:41,880 der Client verschlüsselt dann dieses Geheimnis mit dem öffentlichen Schlüssel des Servers 183 00:12:41,880 --> 00:12:44,880 und sendet dann das Geheimnis an den Server. 184 00:12:44,880 --> 00:12:48,735 Denken Sie nun daran, dass, sobald das Geheimnis mit dem öffentlichen Schlüssel verschlüsselt wurde, 185 00:12:48,735 --> 00:12:51,690 niemand außer dem Server in der Lage ist, 186 00:12:51,690 --> 00:12:55,110 die Informationen aus der verschlüsselten Nachricht zu extrahieren. 187 00:12:55,110 --> 00:12:58,440 Wenn der Server diese verschlüsselte Nachricht erhält, 188 00:12:58,440 --> 00:13:03,300 extrahiert der Server das Pre-Master-Geheimnis aus dieser Nachricht. 189 00:13:03,300 --> 00:13:08,863 Jetzt verfügen sowohl der Client als auch der Server über das gleiche Pre-Master-Geheimnis. 190 00:13:08,863 --> 00:13:12,720 An diesem Punkt verwenden sowohl der Client als auch der Server 191 00:13:12,720 --> 00:13:18,150 den gleichen Satz von Schritten, beginnend mit dem Geheimnis des Pre-Masters 192 00:13:18,150 --> 00:13:20,902 und mit dem gleichen Satz von Werten, 193 00:13:20,902 --> 00:13:24,230 die einen Schlüssel generieren, der als Sitzungsschlüssel bezeichnet wird. 194 00:13:24,230 --> 00:13:28,157 Wenn nun der Sitzungsschlüssel sowohl auf der Client- als auch auf der Serverseite generiert 195 00:13:28,157 --> 00:13:30,630 wird, ist er genau der gleiche Sitzungsschlüssel, 196 00:13:30,630 --> 00:13:36,565 da beide genau dem gleichen Prozess zum Generieren des Sitzungsschlüssels folgen. 197 00:13:36,565 --> 00:13:39,540 An dieser Stelle 198 00:13:39,540 --> 00:13:44,670 verfügen sowohl der Client als auch der Server nun über einen geheimen Schlüssel, der auf beiden Seiten gleich ist. 199 00:13:44,670 --> 00:13:48,570 So 200 00:13:48,570 --> 00:13:52,599 kann die gesamte nachfolgende Kommunikation zwischen dem Server und dem Client, dann mit symmetrischer Verschlüsselung fortfahren. 201 00:13:52,599 --> 00:13:55,035 Wenn der Client also mit dem Server kommunizieren muss, 202 00:13:55,035 --> 00:13:59,640 verschlüsselt der Client die Daten mit dem geheimen Sitzungsschlüssel 203 00:13:59,640 --> 00:14:01,340 und sendet dann seine Daten. 204 00:14:01,340 --> 00:14:05,100 Wenn der Server mit dem Client kommunizieren muss, 205 00:14:05,100 --> 00:14:07,440 verwendet der Server offensichtlich 206 00:14:07,440 --> 00:14:12,365 denselben Sitzungsschlüssel, um die Daten zu verschlüsseln und dann an den Client zu senden. 207 00:14:12,365 --> 00:14:15,215 Da der Client nun denselben Sitzungsschlüssel besitzt, 208 00:14:15,215 --> 00:14:21,255 kann der Client die Nachricht entschlüsseln und die unverschlüsselte Nachricht extrahieren. 209 00:14:21,255 --> 00:14:23,453 Mit diesem Verfahren haben 210 00:14:23,453 --> 00:14:30,099 der Client und der Server sichergestellt, dass die Kommunikation zwischen ihnen privat ist. 211 00:14:30,099 --> 00:14:33,930 Außerdem können wir sicherstellen, dass kein böswilliger Dritter 212 00:14:33,930 --> 00:14:38,310 die Nachricht abfangen und Änderungen an der Nachricht verursachen kann. 213 00:14:38,310 --> 00:14:41,125 Daher wird auch die Integrität der Nachricht beibehalten, 214 00:14:41,125 --> 00:14:43,260 und die Privatsphäre der Kommunikation zwischen 215 00:14:43,260 --> 00:14:46,108 dem Client und dem Server wird ebenfalls beibehalten. 216 00:14:46,108 --> 00:14:50,970 Also, diese ganze Diskussion, die ich Ihnen auf den letzten Folien vorgestellt habe, 217 00:14:50,970 --> 00:14:52,635 ist auf den Punkt gebracht, 218 00:14:52,635 --> 00:14:58,210 wie sichere Kommunikation zwischen Client und Server durch die 219 00:14:58,210 --> 00:15:05,454 symmetrische Schlüsselkryptographie und Public Key-Kryptographie gewährleistet werden kann. 220 00:15:05,454 --> 00:15:10,080 Nun, offensichtlich gibt es viel mehr als das, was ich hier erklärt habe, 221 00:15:10,080 --> 00:15:14,490 aber dieses Verständnis dafür, wie Kryptographie funktioniert, 222 00:15:14,490 --> 00:15:19,540 reicht aus, um zu verstehen, wie der gesamte Prozess funktioniert. 223 00:15:19,540 --> 00:15:22,860 Nun, wenn Sie daran interessiert sind, mehr darüber zu erfahren, 224 00:15:22,860 --> 00:15:28,515 ist eine gute Quelle für das Lernen von Kryptographie-Protokollen ein sehr gutes Buch 225 00:15:28,515 --> 00:15:34,800 von Jim Crozon Keith Ross namens Computer Networks. 226 00:15:34,800 --> 00:15:38,910 Dieses Buch hat ein sehr leicht zu verstehendes Kapitel 227 00:15:38,910 --> 00:15:44,995 über Kryptographie und Sicherheit, wie es auf die Netzwerkkommunikation angewendet wird. 228 00:15:44,995 --> 00:15:48,985 Nun, da wir den Prozess 229 00:15:48,985 --> 00:15:54,440 für die sichere Kommunikation zwischen einem Client und Server etabliert haben, 230 00:15:54,440 --> 00:16:00,640 schauen wir uns an, wie das Internet selbst dies 231 00:16:00,640 --> 00:16:05,320 für die Kommunikation zwischen einem Client und dem Server über HTTP nutzt. 232 00:16:05,320 --> 00:16:09,950 Nun, hier kommt das HTTPS-Protokoll ins Bild. 233 00:16:09,950 --> 00:16:13,915 Wie Sie bereits über das Internet wissen, 234 00:16:13,915 --> 00:16:17,905 ist das Internet eine mehrschichtige Architektur, 235 00:16:17,905 --> 00:16:22,165 bei der die IP und das TCP das Netzwerk bilden, 236 00:16:22,165 --> 00:16:27,490 und die Transportschicht, die über dem zugrunde liegenden Netzwerk läuft. 237 00:16:27,490 --> 00:16:29,755 Nun 238 00:16:29,755 --> 00:16:35,800 haben Sie auf der Transportschicht die Secure Socket Layer oder die Transportschicht-Sicherheits-Auskleidung als 239 00:16:35,800 --> 00:16:39,265 dünne Schicht auf TCP, die eine 240 00:16:39,265 --> 00:16:43,095 sichere Kommunikation zwischen dem Client und dem Server gewährleistet. 241 00:16:43,095 --> 00:16:45,492 Und darüber hinaus kann HTTP laufen. 242 00:16:45,492 --> 00:16:52,830 Daher beinhaltet HTTP im Wesentlichen HTTP plus die Verwendung von Verschlüsselung, 243 00:16:52,830 --> 00:16:56,073 Entschlüsselung unterstützt durch SSL und TLS. 244 00:16:56,073 --> 00:17:00,150 Offensichtlich 245 00:17:00,150 --> 00:17:01,530 gibt es auch für das HTTPS-Protokoll viel mehr Details. 246 00:17:01,530 --> 00:17:05,745 Aber aus der Perspektive der Implementierung der Serverseite 247 00:17:05,745 --> 00:17:12,075 ist das, was wir hier verstanden haben, ausreichend, um zu verstehen, wie 248 00:17:12,075 --> 00:17:19,120 ein Server konfiguriert werden kann, um eine sichere Kommunikation zwischen dem Client und dem Server zu nutzen. 249 00:17:19,120 --> 00:17:23,070 Nun, natürlich ist die erste Frage, die Ihnen in den Sinn kommen wird, 250 00:17:23,070 --> 00:17:27,360 dass der Server einen öffentlichen Schlüssel und einen privaten Schlüssel benötigt. 251 00:17:27,360 --> 00:17:29,330 Wie generiert der Server dies für eine Kryptografie mit öffentlichen Schlüsseln? 252 00:17:29,330 --> 00:17:32,265 Wenn Sie einen echten Produktionsserver in 253 00:17:32,265 --> 00:17:36,792 Ihrer Umgebung betreiben und den Benutzern einen Service für den Zugriff auf Ihren Server bereitstellen, 254 00:17:36,792 --> 00:17:40,525 müssen Sie natürlich den Zertifizierungsprozess durchlaufen. 255 00:17:40,525 --> 00:17:45,100 Hier wenden Sie sich an eine Zertifizierungsstelle, zum Beispiel an 256 00:17:45,100 --> 00:17:48,915 Unternehmen wie VeriSign und Thawte Corporation 257 00:17:48,915 --> 00:17:53,630 , die öffentliche Zertifizierungsstellen sind. 258 00:17:53,630 --> 00:17:55,987 Es gibt noch ein paar mehr auf der ganzen Welt. 259 00:17:55,987 --> 00:17:58,160 Sie werden sich also an sie wenden, 260 00:17:58,160 --> 00:18:03,960 und diese Zertifizierungsstellen authentifizieren dann Ihre Anmeldeinformationen, 261 00:18:03,960 --> 00:18:07,220 sie stellen sicher, dass Sie der sind, der Sie angeblich sind, 262 00:18:07,220 --> 00:18:09,285 und dann werden sie Ihre Anmeldeinformationen überprüfen 263 00:18:09,285 --> 00:18:10,680 , und dann 264 00:18:10,680 --> 00:18:18,725 werden sie Ihnen einen öffentlichen Schlüssel und einen privaten Schlüssel zur Verwendung ausgeben auf Ihrer Server-Site. 265 00:18:18,725 --> 00:18:21,705 Sobald sie also den öffentlichen Schlüssel und den privaten Schlüssel ausstellen, 266 00:18:21,705 --> 00:18:27,010 wird der öffentliche Schlüssel von der Zertifizierungsstelle zertifiziert, 267 00:18:27,010 --> 00:18:30,540 und dann wird der öffentliche Schlüssel auch 268 00:18:30,540 --> 00:18:32,626 das Zertifikat tragen. 269 00:18:32,626 --> 00:18:38,165 Dies ist also das Zertifikat, das Sie an den Standort des Clients senden. 270 00:18:38,165 --> 00:18:43,935 Da Clients 271 00:18:43,935 --> 00:18:48,446 die Authentizität dieser Zertifizierungsstellen feststellen können, 272 00:18:48,446 --> 00:18:52,950 würden Sie bei einem Browser feststellen, dass die meisten Browser 273 00:18:52,950 --> 00:18:58,115 die Zertifikate für all diese etablierten Zertifizierungsstellen 274 00:18:58,115 --> 00:18:59,715 bereits in sie integriert haben. 275 00:18:59,715 --> 00:19:03,685 So werden sie in der Lage sein, Ihre Anmeldeinformationen zu etablieren 276 00:19:03,685 --> 00:19:07,605 , oder besser gesagt, sie werden in der Lage sein, festzustellen, dass der private Schlüssel zu Ihnen gehört, 277 00:19:07,605 --> 00:19:12,540 indem sie Ihr Zertifikat erhalten und dann 278 00:19:12,540 --> 00:19:16,620 Ihr Zertifikat überprüfen oder verifizieren, in dem Wissen, dass es 279 00:19:16,620 --> 00:19:20,955 von einer dieser etablierten Zertifizierung signiert wurde Die Behörden. 280 00:19:20,955 --> 00:19:26,370 Bei diesem Prozess wird der Kunde in der Lage sein, Ihre Authentizität zu etablieren. 281 00:19:26,370 --> 00:19:27,870 Nun, in diesem Kurs 282 00:19:27,870 --> 00:19:31,125 wollen wir nur verstehen, wie jedes HTTPS funktioniert, 283 00:19:31,125 --> 00:19:34,050 und wollen auch eine einfache Möglichkeit haben, 284 00:19:34,050 --> 00:19:38,460 den Server mit einem öffentlichen Schlüssel und dem privaten Schlüssel einzurichten. 285 00:19:38,460 --> 00:19:43,791 Da wir dies als Übung zum Verständnis von HTTPS tun, 286 00:19:43,791 --> 00:19:48,690 können wir ein Tool namens Open SSL verwenden, das bereits auf 287 00:19:48,690 --> 00:19:55,375 unseren Computern verfügbar ist, um das so genannte selbstsignierte Zertifikat zu generieren. 288 00:19:55,375 --> 00:19:59,780 Selbstsignierte Schlüssel sind in der Außenarbeit nicht akzeptabel. 289 00:19:59,780 --> 00:20:03,705 Aber da wir wissen, dass wir es nur für unsere Testzwecke 290 00:20:03,705 --> 00:20:06,300 verwenden, können wir selbstsignierte Zertifikate verwenden, um 291 00:20:06,300 --> 00:20:08,685 einfach den Prozess 292 00:20:08,685 --> 00:20:12,910 der sicheren Kommunikation zwischen Client und Server zu verstehen. 293 00:20:12,910 --> 00:20:15,405 Also, wie verwenden wir Open SSL? 294 00:20:15,405 --> 00:20:18,585 Bisher können Sie mit Open SSL Keys generieren, 295 00:20:18,585 --> 00:20:22,680 indem Sie drei Befehle verwenden, die ich Ihnen hier zeige. 296 00:20:22,680 --> 00:20:26,475 Sie führen diese drei Befehle in dieser Reihenfolge aus, 297 00:20:26,475 --> 00:20:30,020 wie hier angegeben, und das wird Ihnen helfen, 298 00:20:30,020 --> 00:20:34,990 einen privaten Schlüssel und ein Zertifikat zu generieren, das Sie von 299 00:20:34,990 --> 00:20:38,910 Ihrem HTTPS-Server zur Verfügung stellen können, damit Clients herunterladen und 300 00:20:38,910 --> 00:20:44,555 damit Ihren öffentlichen Schlüssel für eine sichere Kommunikation erhalten. 301 00:20:44,555 --> 00:20:48,510 Dies ist also die Operation, die wir in unserer Übung tun werden, die 302 00:20:48,510 --> 00:20:54,510 diesen Vortrag folgt, um DPS Service zu etablieren und auszugeben. Also die drei Schritte, die wir tun, ist 303 00:20:54,510 --> 00:20:59,740 , erstens, werden wir den privaten Schlüssel mit dem ersten Befehl zu generieren. 304 00:20:59,740 --> 00:21:07,980 Danach werden wir eine cert.csr generieren, die dann 305 00:21:07,980 --> 00:21:12,090 für uns verwendet wird, um ein Zertifikat zu generieren, das 306 00:21:12,090 --> 00:21:16,720 durch den dritten Befehl auf der Client-Seite verteilt werden kann. 307 00:21:16,720 --> 00:21:22,545 Mit diesen Schritten können Sie also einen privaten Schlüssel und 308 00:21:22,545 --> 00:21:30,590 auch ein entsprechendes Zertifikat generieren, das an den Client ausgestellt werden kann. 309 00:21:30,590 --> 00:21:34,094 Um hervorzuheben, dass Sie, wenn Sie einen Produktionsserver ausführen, 310 00:21:34,094 --> 00:21:38,610 einen öffentlichen Schlüssel, ein privates Schlüsselpaar, 311 00:21:38,610 --> 00:21:44,205 von einer der Zertifizierungsstellen wie VeriSign und Thawte Corporation beziehen müssen. 312 00:21:44,205 --> 00:21:50,400 Wie funktioniert der Knoten selbst, um uns beim Einrichten des HTTPS zu helfen? 313 00:21:50,400 --> 00:21:54,900 Jetzt überprüfe ich kurz den Code, den wir 314 00:21:54,900 --> 00:22:00,357 in der folgenden Übung verwenden werden, um unsere Server einzurichten. 315 00:22:00,357 --> 00:22:07,910 Knoten selbst hat das HTTPS als Kernmodul innerhalb des Knotens. 316 00:22:07,910 --> 00:22:11,815 So werden wir HTTPS einrichten, indem wir dieses Kernmodul benötigen. 317 00:22:11,815 --> 00:22:15,410 Wir werden auch das Dateisystem-Kernmodul verwenden, da 318 00:22:15,410 --> 00:22:20,760 der private Schlüssel und das Zertifikat, das wir generieren, auf unserer Serverseite gespeichert 319 00:22:20,760 --> 00:22:23,250 werden und diese von 320 00:22:23,250 --> 00:22:28,170 Ihrer Express-Anwendung benötigt werden, um Ihren sicheren Server einzurichten. 321 00:22:28,170 --> 00:22:30,810 Also hier werden wir das Dateisystem mit 322 00:22:30,810 --> 00:22:36,135 der ReadFileSync-Methode verwenden, um den privaten Schlüssel 323 00:22:36,135 --> 00:22:40,440 und das Zertifikat aus den Dateien zu lesen, die wir 324 00:22:40,440 --> 00:22:45,380 mit den Schritten erzeugen, die wir im vorherigen Slot gesehen haben. 325 00:22:45,380 --> 00:22:48,780 Sobald diese beiden Werte bereit sind, werden 326 00:22:48,780 --> 00:22:54,930 die Optionen für Ihren HTTPS-Server eingerichtet, und Sie können dann 327 00:22:54,930 --> 00:23:02,225 Ihren sicheren Server so konfigurieren, dass HTTPS-basierte Kommunikation von der Server-Site aus bereitgestellt wird. 328 00:23:02,225 --> 00:23:07,680 Jetzt haben Sie ein schnelles Verständnis dafür, wie Ihr HTTPS funktioniert 329 00:23:07,680 --> 00:23:12,120 und wie es die Verwendung von Public Key-Kryptografie 330 00:23:12,120 --> 00:23:14,970 und symmetrischer Schlüsselkryptografie nutzt, 331 00:23:14,970 --> 00:23:18,545 um eine sichere Kommunikation zwischen dem Client und dem Server zu gewährleisten. 332 00:23:18,545 --> 00:23:21,885 Lassen Sie uns auf die Übung gehen, um tatsächlich 333 00:23:21,885 --> 00:23:29,230 unseren Express-Server zu konfigurieren, den wir bisher erstellt haben, um das HTTPS-Protokoll zu verwenden.