1
00:00:03,920 --> 00:00:06,615
В предыдущем модуле

2
00:00:06,615 --> 00:00:10,905
мы видели об аутентификации пользователя во многих деталях.

3
00:00:10,905 --> 00:00:17,610
Мы видели, как пользователь отправляет свои учетные данные на свой сервер со стороны клиента

4
00:00:17,610 --> 00:00:20,270
либо в заголовке

5
00:00:20,270 --> 00:00:24,870
сообщения запроса, либо в теле сообщения запроса, а затем,

6
00:00:24,870 --> 00:00:26,460
когда они аутентифицированы,

7
00:00:26,460 --> 00:00:31,680
их клиент будет включать либо cookie, либо

8
00:00:31,680 --> 00:00:38,499
токен в заголовок сообщения запроса, поступающего от клиента на сервер.

9
00:00:38,499 --> 00:00:41,820
Я уверен, что некоторые из вас говорили о том,

10
00:00:41,820 --> 00:00:47,010
что мы общались по небезопасному каналу,

11
00:00:47,010 --> 00:00:50,520
что означает, что любой, сидящий посередине, который может

12
00:00:50,520 --> 00:00:54,780
слушать их сообщения, идущие между клиентом

13
00:00:54,780 --> 00:00:57,570
и сервером, будет легко в состоянии захватить

14
00:00:57,570 --> 00:01:03,195
учетные данные, а затем выдавать себя за подлинного клиента.

15
00:01:03,195 --> 00:01:04,815
Конечно, в тот момент

16
00:01:04,815 --> 00:01:09,025
их акцент был больше на организацию

17
00:01:09,025 --> 00:01:13,575
взаимодействия клиента и сервера с аутентификацией клиента на стороне сервера.

18
00:01:13,575 --> 00:01:19,215
Но в любой момент, когда вам нужно использовать аутентификацию пользователя

19
00:01:19,215 --> 00:01:21,945
, во-первых, в форме, скажем,

20
00:01:21,945 --> 00:01:25,940
предоставления учетных данных для аутентификации себя, а затем,

21
00:01:25,940 --> 00:01:29,445
аутентификации себя,

22
00:01:29,445 --> 00:01:33,840
включив либо файл cookie, либо токен в заголовок сообщения запроса,

23
00:01:33,840 --> 00:01:36,290
вы должны делать это через безопасный канал.

24
00:01:36,290 --> 00:01:39,890
Вы никогда не должны общаться по небезопасному каналу,

25
00:01:39,890 --> 00:01:44,160
что означает, что вы не должны использовать HTTP, а затем включать

26
00:01:44,160 --> 00:01:48,780
эти учетные данные либо в заголовок, либо в тело сообщений запроса.

27
00:01:48,780 --> 00:01:56,455
Вместо этого вы должны использовать защищенную версию протокола HTTP или HTTPS.

28
00:01:56,455 --> 00:02:01,830
Давайте кратко поговорим о HTTPS в этой лекции.

29
00:02:01,830 --> 00:02:07,140
По пути я дам вам пятиминутное знакомство с криптографией и безопасностью.

30
00:02:07,140 --> 00:02:12,143
Очевидно, что криптография и безопасность — сама по себе очень большая тема.

31
00:02:12,143 --> 00:02:16,110
Я просто собираюсь познакомить вас с голой первой необходимости, которые вам нужно

32
00:02:16,110 --> 00:02:21,820
понять, чтобы узнать, как на самом деле работает HTTPS.

33
00:02:21,820 --> 00:02:29,430
На этом фоне, давайте перейдем к пониманию криптографии, а затем к

34
00:02:29,430 --> 00:02:34,110
протоколу HTTPS и как вы должны настроить сервер для использования

35
00:02:34,110 --> 00:02:40,276
протокола HTTPS, а затем клиент для связи с сервером по протоколу HTTPS

36
00:02:40,276 --> 00:02:45,165
, таким образом, связь между клиентом и сервером может быть выполняется безопасным образом

37
00:02:45,165 --> 00:02:51,180
, шифруя данные, отправляемые между клиентом и сервером.

38
00:02:51,180 --> 00:02:56,175
Когда вы начинаете заниматься криптографией и безопасностью,

39
00:02:56,175 --> 00:03:00,375
вы часто слышите, как люди говорят о криптографии симметричных ключей.

40
00:03:00,375 --> 00:03:02,970
Итак, что включает в себя криптографию?

41
00:03:02,970 --> 00:03:07,635
Если вам нужно отправить сообщение по каналу другому пользователю,

42
00:03:07,635 --> 00:03:10,800
то вы хотите иметь возможность зашифровать

43
00:03:10,800 --> 00:03:14,310
сообщение таким образом, что только получатель сможет

44
00:03:14,310 --> 00:03:16,570
расшифровать сообщение и получить

45
00:03:16,570 --> 00:03:21,050
информацию, которую вы пытаетесь отправить получателю.

46
00:03:21,050 --> 00:03:26,730
Таким образом, и отправитель, и получатель должны понять при установлении между

47
00:03:26,730 --> 00:03:32,930
ними, как этот процесс шифрования и как будет работать расшифровка.

48
00:03:32,930 --> 00:03:34,365
Для этого работает

49
00:03:34,365 --> 00:03:41,265
любое шифрование и расшифровка на основе обмена секретными ключами.

50
00:03:41,265 --> 00:03:43,765
Таким образом, в криптографии симметричных ключей,

51
00:03:43,765 --> 00:03:50,678
и отправитель, и получатель будут делиться секретным ключом между двумя сайтами,

52
00:03:50,678 --> 00:03:55,165
и этот секретный ключ известен только отправителю и стороне получателя.

53
00:03:55,165 --> 00:03:58,260
Поэтому, когда отправителю нужно отправить сообщение,

54
00:03:58,260 --> 00:04:04,755
отправитель шифрует это сообщение с помощью криптографического алгоритма,

55
00:04:04,755 --> 00:04:09,795
который использует секретный ключ в качестве других входных данных для этого алгоритма.

56
00:04:09,795 --> 00:04:13,875
И как только это сообщение будет передано через этот криптографический алгоритм,

57
00:04:13,875 --> 00:04:17,068
то будет сгенерировано зашифрованное сообщение.

58
00:04:17,068 --> 00:04:24,160
Теперь это зашифрованное сообщение будет отправлено на канал через сторону приемника.

59
00:04:24,160 --> 00:04:28,140
Если у вас есть сторонний вредоносный пользователь

60
00:04:28,140 --> 00:04:32,450
, прослушивающий и записывающий это зашифрованное сообщение, ему

61
00:04:32,450 --> 00:04:34,740
будет трудно расшифровать

62
00:04:34,740 --> 00:04:38,580
это сообщение, потому что для расшифровки зашифрованного сообщения

63
00:04:38,580 --> 00:04:40,645
вам все равно нужен секретный ключ.

64
00:04:40,645 --> 00:04:42,375
Теперь, на стороне получателя,

65
00:04:42,375 --> 00:04:44,856
когда получено зашифрованное сообщение,

66
00:04:44,856 --> 00:04:48,815
то приемник будет применять и алгоритм расшифровки,

67
00:04:48,815 --> 00:04:50,715
который также принимает в качестве ввода

68
00:04:50,715 --> 00:04:56,590
тот же секретный ключ, который использовался на стороне отправителя для шифрования сообщения.

69
00:04:56,590 --> 00:05:00,585
Таким образом, после расшифровки исходное сообщение будет извлечено

70
00:05:00,585 --> 00:05:05,240
и может быть обработано на стороне получателя.

71
00:05:05,240 --> 00:05:11,260
Теперь, если вредоносная третья сторона захочет расшифровать это зашифрованное сообщение,

72
00:05:11,260 --> 00:05:14,280
они столкнутся с тяжёлой борьбой, потому что

73
00:05:14,280 --> 00:05:18,240
процесс шифрования с помощью секретного ключа превратит сообщение и может,

74
00:05:18,240 --> 00:05:19,590
в свою очередь, зашифровать сообщение.

75
00:05:19,590 --> 00:05:21,830
Без обладания секретным ключом,

76
00:05:21,830 --> 00:05:26,760
расшифровать зашифрованное сообщение будет почти невозможно.

77
00:05:26,760 --> 00:05:30,200
Ну, это растягивание немного далеко.

78
00:05:30,200 --> 00:05:35,490
Было бы необычно сложно расшифровать зашифрованное сообщение.

79
00:05:35,490 --> 00:05:39,210
Если вы используете методы грубой силы, то в конечном итоге

80
00:05:39,210 --> 00:05:43,245
вы закончите расшифровку зашифрованного сообщения.

81
00:05:43,245 --> 00:05:48,880
Но это займет так много времени и потребует столько вычислительной мощности.

82
00:05:48,880 --> 00:05:53,175
Не стоит усилий для

83
00:05:53,175 --> 00:05:58,580
стороннего злоумышленника, чтобы попытаться расшифровать зашифрованное сообщение.

84
00:05:58,580 --> 00:06:01,770
Таким образом, вы, по сути, затрудняете для кого-то

85
00:06:01,770 --> 00:06:05,355
расшифровать сообщение, если у них нет секретного ключа.

86
00:06:05,355 --> 00:06:09,480
Теперь, поскольку секретный ключ известен только отправителю и

87
00:06:09,480 --> 00:06:12,390
получателю, обе стороны, отправитель и получатель,

88
00:06:12,390 --> 00:06:16,335
могут общаться с уверенностью,

89
00:06:16,335 --> 00:06:18,780
что зашифрованное сообщение со

90
00:06:18,780 --> 00:06:22,240
стороны отправителя может быть расшифровано только стороной получателя.

91
00:06:22,240 --> 00:06:25,485
Вот как работает симметричная криптография ключей.

92
00:06:25,485 --> 00:06:30,330
Тот факт, что у вас есть один и тот же секретный ключ,

93
00:06:30,330 --> 00:06:32,400
разделяемый между отправителем и получателем, означает, что

94
00:06:32,400 --> 00:06:35,420
включение процесса расшифровки использует один и тот же секретный ключ

95
00:06:35,420 --> 00:06:38,911
, следовательно, симметричный ключ криптографии.

96
00:06:38,911 --> 00:06:41,395
Конечно, при криптографии симметричного ключа

97
00:06:41,395 --> 00:06:44,440
одна из проблем заключается в том, что и отправитель, и

98
00:06:44,440 --> 00:06:48,805
получатель должны иметь доступ к одному и тому же секретному ключу.

99
00:06:48,805 --> 00:06:53,940
Теперь, если отправитель и получатель обмениваются данными по небезопасному каналу,

100
00:06:53,940 --> 00:06:58,230
обеим сторонам будет трудно прийти к пониманию одного и того

101
00:06:58,230 --> 00:07:03,510
же секретного ключа, не раскрывая его другим.

102
00:07:03,510 --> 00:07:09,315
Вот где очень полезен другой алгоритм, называемый криптографией с открытым ключом.

103
00:07:09,315 --> 00:07:12,195
Как работает криптография с открытым ключом?

104
00:07:12,195 --> 00:07:14,610
Теперь, в криптографии с открытым ключом,

105
00:07:14,610 --> 00:07:17,595
идея заключается в том, что у вас есть два разных ключа.

106
00:07:17,595 --> 00:07:21,085
У вас есть открытый и закрытый ключ.

107
00:07:21,085 --> 00:07:26,520
Теперь открытый ключ может быть широко распространен среди всех, кого вы хотите.

108
00:07:26,520 --> 00:07:29,335
Поэтому, когда кто-то хочет отправить вам сообщение

109
00:07:29,335 --> 00:07:34,350
, он будет использовать ваш открытый ключ для шифрования сообщения.

110
00:07:34,350 --> 00:07:39,795
Поэтому, если отправитель хочет отправить сообщение получателю,

111
00:07:39,795 --> 00:07:44,385
отправитель будет использовать открытый ключ от получателя для

112
00:07:44,385 --> 00:07:50,240
шифрования сообщения на стороне отправителя с помощью алгоритма шифрования.

113
00:07:50,240 --> 00:07:53,100
Теперь, как только зашифрованное сообщение будет отправлено

114
00:07:53,100 --> 00:07:56,640
по небезопасному каналу на сторону

115
00:07:56,640 --> 00:07:59,625
получателя, получатель будет использовать закрытый ключ

116
00:07:59,625 --> 00:08:03,210
, который знает только получатель, для расшифровки.

117
00:08:03,210 --> 00:08:06,645
Теперь, чтобы криптография с открытым ключом работала так, как мы видели,

118
00:08:06,645 --> 00:08:10,760
публичный ключ может быть широко распространен без каких-либо проблем.

119
00:08:10,760 --> 00:08:14,150
Но так как закрытый ключ известен только стороне получателя,

120
00:08:14,150 --> 00:08:19,325
только получатель сможет расшифровать сообщение, и,

121
00:08:19,325 --> 00:08:23,070
опять же, сторонний злоумышленник, который захватывает

122
00:08:23,070 --> 00:08:28,410
это зашифрованное сообщение, будет чрезвычайно трудно расшифровать сообщение.

123
00:08:28,410 --> 00:08:29,670
Теперь, конечно, в криптографии с открытым ключом,

124
00:08:29,670 --> 00:08:33,385
публичный и закрытый ключ являются двумя разными ключами.

125
00:08:33,385 --> 00:08:36,900
Теперь ваш очевидный следующий вопрос будет: почему бы

126
00:08:36,900 --> 00:08:40,686
просто не использовать криптографию с открытым ключом для шифрования.

127
00:08:40,686 --> 00:08:44,445
Проблема в том, что использование криптографии с открытым ключом

128
00:08:44,445 --> 00:08:48,383
для шифрования и расшифровки является дорогостоящим процессом,

129
00:08:48,383 --> 00:08:54,890
поэтому мы не используем криптографию с открытым ключом для всей их коммуникации.

130
00:08:54,890 --> 00:09:00,600
Вместо этого криптография с открытым ключом будет использоваться в

131
00:09:00,600 --> 00:09:04,290
первую очередь для отправителя и получателя, чтобы

132
00:09:04,290 --> 00:09:08,270
согласовать общий секретный ключ, который оба будут использовать.

133
00:09:08,270 --> 00:09:12,210
Позже мы увидим, как криптография с открытым ключом

134
00:09:12,210 --> 00:09:16,380
может быть использована для установления общего секретного ключа

135
00:09:16,380 --> 00:09:19,845
между отправителем и получателем, а затем

136
00:09:19,845 --> 00:09:24,686
использовать криптографию симметричного ключа для дальнейшей связи.

137
00:09:24,686 --> 00:09:29,790
Одним из протоколов, использующих этот подход, является

138
00:09:29,790 --> 00:09:35,088
уровень безопасности сокетов, а также протоколы безопасности транспортного уровня,

139
00:09:35,088 --> 00:09:37,365
SSL и TLS.

140
00:09:37,365 --> 00:09:40,395
Так много раз, когда вы читаете документацию,

141
00:09:40,395 --> 00:09:44,020
вы можете услышать о SSL и TLS.

142
00:09:44,020 --> 00:09:48,660
Эти криптографические протоколы обеспечивают безопасную связь между

143
00:09:48,660 --> 00:09:55,110
отправителем и получателем по небезопасной сети, такой как Интернет.

144
00:09:55,110 --> 00:10:03,150
Отправитель и получатель будут общаться через Интернет с помощью зашифрованных сообщений,

145
00:10:03,150 --> 00:10:06,410
которые могут расшифровать только отправитель и получатель.

146
00:10:06,410 --> 00:10:09,266
И этот подход, либо SSL, либо TLS,

147
00:10:09,266 --> 00:10:16,220
использует комбинацию криптографии с открытым ключом вместе с криптографией симметричного ключа.

148
00:10:16,220 --> 00:10:18,905
Их точный процесс сделать это,

149
00:10:18,905 --> 00:10:21,290
я объясню на следующем слайде.

150
00:10:21,290 --> 00:10:25,050
Кроме того, используя SSL или TLS,

151
00:10:25,050 --> 00:10:27,415
мы пытаемся поддерживать две разные вещи.

152
00:10:27,415 --> 00:10:29,940
Во-первых, мы пытаемся сохранить конфиденциальность

153
00:10:29,940 --> 00:10:32,880
связи между отправителем и получателем, чтобы

154
00:10:32,880 --> 00:10:39,165
ни одна вредоносная третья сторона не могла извлечь сообщение из зашифрованного сообщения.

155
00:10:39,165 --> 00:10:42,150
Во-вторых, мы также пытаемся сохранить целостность,

156
00:10:42,150 --> 00:10:44,550
что означает, что когда отправитель отправляет сообщение,

157
00:10:44,550 --> 00:10:50,025
получатель сможет быть уверен, что сообщение не было изменено.

158
00:10:50,025 --> 00:10:57,145
Таким образом, как безопасность, так и поддержание целостности очень важны в данном случае.

159
00:10:57,145 --> 00:11:01,110
Таким образом, конфиденциальность и целостность должны поддерживаться

160
00:11:01,110 --> 00:11:04,200
этим защищенным протоколом связи, который мы создаем

161
00:11:04,200 --> 00:11:08,235
для обмена между отправителем и получателем.

162
00:11:08,235 --> 00:11:13,865
Давайте кратко поговорим о том, как на самом деле работают SSL или TLS.

163
00:11:13,865 --> 00:11:22,585
Это делается через процесс рукопожатия, который я проиллюстрировал на этой диаграмме здесь.

164
00:11:22,585 --> 00:11:26,020
Когда клиент хочет связаться с сервером,

165
00:11:26,020 --> 00:11:28,920
клиент отправляет сообщение на сервер,

166
00:11:28,920 --> 00:11:34,405
указав, что клиент хочет безопасно взаимодействовать с сервером.

167
00:11:34,405 --> 00:11:40,068
На этом этапе сервер отправит клиенту сертификат,

168
00:11:40,068 --> 00:11:42,105
содержащий открытый ключ,

169
00:11:42,105 --> 00:11:43,800
который был сертифицирован

170
00:11:43,800 --> 00:11:48,410
центром сертификации как принадлежащий этому конкретному серверу.

171
00:11:48,410 --> 00:11:51,210
Таким образом, когда клиент получает

172
00:11:51,210 --> 00:11:56,325
этот открытый ключ плюс сертификацию центром сертификации,

173
00:11:56,325 --> 00:11:59,960
клиент сможет проверить учетные данные сервера.

174
00:11:59,960 --> 00:12:03,510
Таким образом, клиент должен установить, что он действительно разговаривает с сервером,

175
00:12:03,510 --> 00:12:07,345
с которым он намерен общаться.

176
00:12:07,345 --> 00:12:09,040
Таким образом, на данный момент,

177
00:12:09,040 --> 00:12:11,788
когда клиент проверяет учетные данные сервера,

178
00:12:11,788 --> 00:12:17,110
клиент теперь имеет доступ к публичному ключу сервера.

179
00:12:17,110 --> 00:12:20,850
Как только клиент получит открытый ключ сервера,

180
00:12:20,850 --> 00:12:25,005
клиент сгенерирует то, что называется секретом предварительного мастера.

181
00:12:25,005 --> 00:12:28,560
Этот предварительный секрет - это то, что клиент и

182
00:12:28,560 --> 00:12:33,045
сервер будут использовать для генерации того, что называется ключом сеанса.

183
00:12:33,045 --> 00:12:36,870
Таким образом, клиент генерирует предварительный секрет,

184
00:12:36,870 --> 00:12:41,880
клиент затем шифрует этот секрет, используя открытый ключ сервера,

185
00:12:41,880 --> 00:12:44,880
а затем отправляет секрет на сервер.

186
00:12:44,880 --> 00:12:48,735
Теперь помните, что после шифрования секрета с помощью открытого ключа

187
00:12:48,735 --> 00:12:51,690
никто, кроме сервера, не сможет

188
00:12:51,690 --> 00:12:55,110
извлечь информацию из зашифрованного сообщения.

189
00:12:55,110 --> 00:12:58,440
Таким образом, когда сервер получает это зашифрованное сообщение,

190
00:12:58,440 --> 00:13:03,300
сервер извлекает из этого сообщения секреты предварительного мастера.

191
00:13:03,300 --> 00:13:08,863
Теперь и клиент, и сервер обладают одним и тем же секретом предварительного мастера.

192
00:13:08,863 --> 00:13:12,720
На этом этапе и клиент, и сервер будут использовать один и

193
00:13:12,720 --> 00:13:18,150
тот же набор шагов, начиная с секрета предварительного мастера,

194
00:13:18,150 --> 00:13:20,902
и с тем же набором значений,

195
00:13:20,902 --> 00:13:24,230
который будет генерировать ключ, называемый ключом сеанса.

196
00:13:24,230 --> 00:13:28,157
Теперь, когда ключ сеанса генерируется как на стороне клиентов, так и на стороне сервера,

197
00:13:28,157 --> 00:13:30,630
это будет точно тот же ключ сеанса,

198
00:13:30,630 --> 00:13:36,565
потому что оба будут следовать точно тому же процессу для генерации ключа сеанса.

199
00:13:36,565 --> 00:13:37,950
Итак, на данный момент,

200
00:13:37,950 --> 00:13:39,540
как клиент, так и сервер,

201
00:13:39,540 --> 00:13:44,670
теперь обладают секретным ключом, который одинаков на обоих сайтах.

202
00:13:44,670 --> 00:13:48,570
Таким образом, все последующие связи между сервером и клиентом

203
00:13:48,570 --> 00:13:52,599
могут затем продолжаться с использованием симметричного шифрования.

204
00:13:52,599 --> 00:13:55,035
Таким образом, когда клиенту нужно связаться с сервером,

205
00:13:55,035 --> 00:13:59,640
клиент будет шифровать данные с помощью секретного ключа сеанса,

206
00:13:59,640 --> 00:14:01,340
а затем отправлять их данные.

207
00:14:01,340 --> 00:14:05,100
Аналогично, когда сервер должен взаимодействовать с клиентом,

208
00:14:05,100 --> 00:14:07,440
сервер, очевидно, будет использовать

209
00:14:07,440 --> 00:14:12,365
тот же ключ сеанса для шифрования данных, а затем отправить его клиенту.

210
00:14:12,365 --> 00:14:15,215
Теперь, поскольку клиент имеет тот же ключ сеанса,

211
00:14:15,215 --> 00:14:21,255
клиент сможет расшифровать сообщение и извлечь незашифрованное сообщение.

212
00:14:21,255 --> 00:14:23,453
Используя эту процедуру,

213
00:14:23,453 --> 00:14:30,099
клиент и сервер гарантировали, что связь между ними является частной.

214
00:14:30,099 --> 00:14:33,930
Кроме того, нам удается убедиться, что ни одна вредоносная третья сторона не может

215
00:14:33,930 --> 00:14:38,310
перехватить сообщение и вызвать какие-либо изменения в сообщении.

216
00:14:38,310 --> 00:14:41,125
Таким образом, целостность сообщения также поддерживается,

217
00:14:41,125 --> 00:14:43,260
и конфиденциальность связи

218
00:14:43,260 --> 00:14:46,108
между клиентом и сервером также поддерживается.

219
00:14:46,108 --> 00:14:50,970
Итак, вся эта дискуссия, которую я представил вам за последние несколько слайдов,

220
00:14:50,970 --> 00:14:52,635
в двух словах,

221
00:14:52,635 --> 00:14:58,210
как безопасная связь между клиентом и сервером может быть обеспечена

222
00:14:58,210 --> 00:15:05,454
с помощью криптографии симметричного ключа и криптографии открытого ключа.

223
00:15:05,454 --> 00:15:10,080
Очевидно, в этом есть гораздо больше, чем то, что я здесь объяснил,

224
00:15:10,080 --> 00:15:14,490
но этого понимания того, как работает криптография,

225
00:15:14,490 --> 00:15:19,540
достаточно для того, чтобы вы поняли, как работает весь процесс.

226
00:15:19,540 --> 00:15:22,860
Теперь, если вам интересно узнать больше об этом,

227
00:15:22,860 --> 00:15:28,515
одним из хороших источников для изучения криптографических протоколов является очень хорошая книга

228
00:15:28,515 --> 00:15:34,800
Джима Крозона Кита Росса под названием «Компьютерные сети».

229
00:15:34,800 --> 00:15:38,910
Эта книга имеет очень простую для понимания главу

230
00:15:38,910 --> 00:15:44,995
о криптографии и безопасности применительно к сетевой коммуникации.

231
00:15:44,995 --> 00:15:48,985
Теперь, когда мы установили процесс

232
00:15:48,985 --> 00:15:54,440
для безопасной связи между клиентом и сервером,

233
00:15:54,440 --> 00:16:00,640
давайте посмотрим, как сам Интернет использует это,

234
00:16:00,640 --> 00:16:05,320
для связи между клиентом и сервером с помощью HTTP.

235
00:16:05,320 --> 00:16:09,950
Теперь, это то, где протокол HTTPS входит в картину.

236
00:16:09,950 --> 00:16:13,915
Как вы уже понимаете об Интернете,

237
00:16:13,915 --> 00:16:17,905
Интернет представляет собой многоуровневую архитектуру,

238
00:16:17,905 --> 00:16:22,165
где IP и TCP образуют сеть,

239
00:16:22,165 --> 00:16:27,490
а транспортный уровень, который работает поверх базовой сети.

240
00:16:27,490 --> 00:16:29,755
Теперь, поверх транспортного уровня,

241
00:16:29,755 --> 00:16:35,800
у вас есть защищенный слой сокета или подкладка безопасности транспортного уровня как

242
00:16:35,800 --> 00:16:39,265
тонкий слой поверх TCP, который

243
00:16:39,265 --> 00:16:43,095
обеспечивает безопасную связь между клиентом и сервером.

244
00:16:43,095 --> 00:16:45,492
И поверх этого может работать HTTP.

245
00:16:45,492 --> 00:16:52,830
Таким образом, HTTP по существу включает HTTP плюс использование шифрования,

246
00:16:52,830 --> 00:16:56,073
расшифровки, поддерживаемых через SSL и TLS.

247
00:16:56,073 --> 00:17:00,150
Очевидно, даже для протокола HTTPS

248
00:17:00,150 --> 00:17:01,530
есть гораздо больше деталей.

249
00:17:01,530 --> 00:17:05,745
Но с точки зрения реализации серверной стороны,

250
00:17:05,745 --> 00:17:12,075
того, что мы поняли здесь, достаточно, чтобы понять, как

251
00:17:12,075 --> 00:17:19,120
настроить сервер для использования безопасной связи между клиентом и сервером.

252
00:17:19,120 --> 00:17:23,070
Теперь, конечно, первый вопрос, который придет вам на ум, заключается в

253
00:17:23,070 --> 00:17:25,800
том, что сервер нуждается в открытом ключе и закрытом ключе.

254
00:17:25,800 --> 00:17:27,360
Для криптографии с открытым ключом,

255
00:17:27,360 --> 00:17:29,330
как сервер генерирует это?

256
00:17:29,330 --> 00:17:32,265
Если вы используете реальный производственный сервер в

257
00:17:32,265 --> 00:17:36,792
своей среде и предоставляете услуги пользователям для доступа к вашему серверу,

258
00:17:36,792 --> 00:17:40,525
то, очевидно, вам нужно пройти процесс сертификации.

259
00:17:40,525 --> 00:17:45,100
Здесь вы будете обращаться в центр сертификации, например, к

260
00:17:45,100 --> 00:17:48,915
корпорациям, таким как VeriSign и Thawte Corporation

261
00:17:48,915 --> 00:17:53,630
, которые являются государственными сертификационными центрами.

262
00:17:53,630 --> 00:17:55,987
Есть еще несколько по всему миру.

263
00:17:55,987 --> 00:17:58,160
Таким образом, вы обратитесь к ним,

264
00:17:58,160 --> 00:18:03,960
и эти центры сертификации проведут аутентификацию ваших учетных данных,

265
00:18:03,960 --> 00:18:07,220
они обеспечат, что вы являетесь тем, кем вы утверждаете,

266
00:18:07,220 --> 00:18:09,285
и затем они проверят ваши учетные данные

267
00:18:09,285 --> 00:18:10,680
, а затем в этот момент

268
00:18:10,680 --> 00:18:18,725
они выдадут вам открытый ключ и закрытый ключ для использования на сайте сервера.

269
00:18:18,725 --> 00:18:21,705
Таким образом, как только они выдают открытый ключ и закрытый

270
00:18:21,705 --> 00:18:27,010
ключ, открытый ключ будет сертифицирован центром сертификации,

271
00:18:27,010 --> 00:18:30,540
а затем открытый ключ также будет нести,

272
00:18:30,540 --> 00:18:32,626
кроме того, сертификат.

273
00:18:32,626 --> 00:18:38,165
Итак, это сертификат, который вы отправите на сайт клиента.

274
00:18:38,165 --> 00:18:43,935
Поскольку клиенты могут установить

275
00:18:43,935 --> 00:18:48,446
подлинность этих центров сертификации,

276
00:18:48,446 --> 00:18:52,950
если вы посмотрите на любой браузер, вы заметите, что большинство браузеров будут иметь

277
00:18:52,950 --> 00:18:58,115
сертификаты для всех установленных центров сертификации,

278
00:18:58,115 --> 00:18:59,715
уже встроенных в них.

279
00:18:59,715 --> 00:19:03,685
Таким образом, они смогут установить ваши учетные данные,

280
00:19:03,685 --> 00:19:07,605
или, скорее, они смогут установить, что закрытый ключ принадлежит вам,

281
00:19:07,605 --> 00:19:12,540
получая ваш сертификат, а затем проверяя или проверяя

282
00:19:12,540 --> 00:19:16,620
ваш сертификат, зная, что он был подписан одним

283
00:19:16,620 --> 00:19:20,955
из этих установленных сертификатов Власти.

284
00:19:20,955 --> 00:19:26,370
После этого, клиент сможет установить вашу подлинность.

285
00:19:26,370 --> 00:19:27,870
Теперь, в этом курсе,

286
00:19:27,870 --> 00:19:31,125
мы просто хотим понять, как работает каждый HTTPS,

287
00:19:31,125 --> 00:19:34,050
а также хотим иметь простой способ

288
00:19:34,050 --> 00:19:38,460
настройки сервера с открытым ключом и закрытым ключом.

289
00:19:38,460 --> 00:19:43,791
Поскольку мы делаем это как упражнение для понимания HTTPS,

290
00:19:43,791 --> 00:19:48,690
мы можем использовать инструмент под названием open SSL, который уже доступен на

291
00:19:48,690 --> 00:19:55,375
наших компьютерах, чтобы генерировать то, что называется самозаверяющим сертификатом.

292
00:19:55,375 --> 00:19:59,780
Самозаверяющие ключи недопустимы во внешней работе.

293
00:19:59,780 --> 00:20:03,705
Но поскольку мы знаем, что мы используем его только для наших целей тестирования,

294
00:20:03,705 --> 00:20:06,300
мы можем использовать самозаверяющие сертификаты,

295
00:20:06,300 --> 00:20:08,685
просто для понимания процесса

296
00:20:08,685 --> 00:20:12,910
безопасной связи между клиентом и сервером.

297
00:20:12,910 --> 00:20:15,405
Итак, как мы используем открытый SSL?

298
00:20:15,405 --> 00:20:18,585
До сих пор, используя открытый SSL, вы можете генерировать ключи,

299
00:20:18,585 --> 00:20:22,680
используя три команды, которые я показываю вам здесь.

300
00:20:22,680 --> 00:20:26,475
Эти три команды выполняются в этой последовательности,

301
00:20:26,475 --> 00:20:30,020
как указано здесь, и это поможет вам

302
00:20:30,020 --> 00:20:34,990
создать закрытый ключ и сертификат, которые можно сделать доступными с

303
00:20:34,990 --> 00:20:38,910
HTTPS-сервера для загрузки клиентов и,

304
00:20:38,910 --> 00:20:44,555
таким образом, получить открытый ключ для безопасной связи.

305
00:20:44,555 --> 00:20:48,510
Таким образом, это операция, которую мы собираемся сделать в нашем упражнении, которое следует за

306
00:20:48,510 --> 00:20:54,510
этой лекцией для создания и выпуска DPS service.So три шага, которые мы делаем, это

307
00:20:54,510 --> 00:20:59,740
, во-первых, мы будем генерировать закрытый ключ с помощью первой команды.

308
00:20:59,740 --> 00:21:07,980
Затем мы сгенерируем cert.csr, который затем будет использоваться

309
00:21:07,980 --> 00:21:12,090
для нас, чтобы создать сертификат, который

310
00:21:12,090 --> 00:21:16,720
может быть распространен на стороне клиента третьей командой, показанной там.

311
00:21:16,720 --> 00:21:22,545
Таким образом, эти шаги позволят вам создать закрытый ключ,

312
00:21:22,545 --> 00:21:30,590
а также соответствующий сертификат, который может быть выдан клиенту.

313
00:21:30,590 --> 00:21:34,094
Опять же, чтобы подчеркнуть, что если вы используете производственный

314
00:21:34,094 --> 00:21:38,610
сервер, вам нужно получить открытый ключ, пару закрытого ключа,

315
00:21:38,610 --> 00:21:44,205
от одного из центров сертификации, таких как VeriSign и Thawte корпорации.

316
00:21:44,205 --> 00:21:50,400
Как сам узел работает, помогая нам настроить HTTPS?

317
00:21:50,400 --> 00:21:54,900
Теперь здесь я кратко рассматриваю код, который мы будем

318
00:21:54,900 --> 00:22:00,357
использовать в следующем упражнении, чтобы настроить наши серверы.

319
00:22:00,357 --> 00:22:07,910
Сам узел имеет HTTPS в качестве основного модуля внутри узла.

320
00:22:07,910 --> 00:22:11,815
Таким образом, мы настроим HTTPS, требуя этого основного модуля.

321
00:22:11,815 --> 00:22:15,410
Мы также будем использовать модуль ядра файловой системы, потому что

322
00:22:15,410 --> 00:22:20,760
закрытый ключ и сертификат, который мы генерируем, будут храниться на нашей стороне сервера,

323
00:22:20,760 --> 00:22:23,250
и они будут необходимы для

324
00:22:23,250 --> 00:22:28,170
вашего экспресс-приложения для настройки вашего безопасного сервера.

325
00:22:28,170 --> 00:22:30,810
Таким образом, здесь мы будем использовать файловую систему с

326
00:22:30,810 --> 00:22:36,135
методом ReadFileSync для чтения в закрытом ключе

327
00:22:36,135 --> 00:22:40,440
и сертификат из файлов, которые мы

328
00:22:40,440 --> 00:22:45,380
генерируем с помощью шагов, которые мы видели в предыдущем слоте.

329
00:22:45,380 --> 00:22:48,780
Поэтому, как только эти два значения будут готовы,

330
00:22:48,780 --> 00:22:54,930
параметры для вашего HTTPS сервера будут настроены, а затем вы можете настроить

331
00:22:54,930 --> 00:23:02,225
свой безопасный сервер для обеспечения связи на основе HTTPS с сайта сервера.

332
00:23:02,225 --> 00:23:07,680
Теперь, когда вы быстро понимаете, как работает ваш HTTPS,

333
00:23:07,680 --> 00:23:12,120
и как он использует криптографию открытого ключа

334
00:23:12,120 --> 00:23:14,970
и криптографию симметричных ключей для

335
00:23:14,970 --> 00:23:18,545
обеспечения безопасной связи между клиентом и сервером.

336
00:23:18,545 --> 00:23:21,885
Давайте перейдем к упражнению, чтобы фактически настроить

337
00:23:21,885 --> 00:23:29,230
наш экспресс-сервер, который мы построили до сих пор для использования протокола HTTPS.