В предыдущем модуле
мы видели об аутентификации пользователя во многих деталях.
Мы видели, как пользователь отправляет свои учетные данные на свой сервер со стороны клиента
либо в заголовке
сообщения запроса, либо в теле сообщения запроса, а затем,
когда они аутентифицированы,
их клиент будет включать либо cookie, либо
токен в заголовок сообщения запроса, поступающего от клиента на сервер.
Я уверен, что некоторые из вас говорили о том,
что мы общались по небезопасному каналу,
что означает, что любой, сидящий посередине, который может
слушать их сообщения, идущие между клиентом
и сервером, будет легко в состоянии захватить
учетные данные, а затем выдавать себя за подлинного клиента.
Конечно, в тот момент
их акцент был больше на организацию
взаимодействия клиента и сервера с аутентификацией клиента на стороне сервера.
Но в любой момент, когда вам нужно использовать аутентификацию пользователя
, во-первых, в форме, скажем,
предоставления учетных данных для аутентификации себя, а затем,
аутентификации себя,
включив либо файл cookie, либо токен в заголовок сообщения запроса,
вы должны делать это через безопасный канал.
Вы никогда не должны общаться по небезопасному каналу,
что означает, что вы не должны использовать HTTP, а затем включать
эти учетные данные либо в заголовок, либо в тело сообщений запроса.
Вместо этого вы должны использовать защищенную версию протокола HTTP или HTTPS.
Давайте кратко поговорим о HTTPS в этой лекции.
По пути я дам вам пятиминутное знакомство с криптографией и безопасностью.
Очевидно, что криптография и безопасность — сама по себе очень большая тема.
Я просто собираюсь познакомить вас с голой первой необходимости, которые вам нужно
понять, чтобы узнать, как на самом деле работает HTTPS.
На этом фоне, давайте перейдем к пониманию криптографии, а затем к
протоколу HTTPS и как вы должны настроить сервер для использования
протокола HTTPS, а затем клиент для связи с сервером по протоколу HTTPS
, таким образом, связь между клиентом и сервером может быть выполняется безопасным образом
, шифруя данные, отправляемые между клиентом и сервером.
Когда вы начинаете заниматься криптографией и безопасностью,
вы часто слышите, как люди говорят о криптографии симметричных ключей.
Итак, что включает в себя криптографию?
Если вам нужно отправить сообщение по каналу другому пользователю,
то вы хотите иметь возможность зашифровать
сообщение таким образом, что только получатель сможет
расшифровать сообщение и получить
информацию, которую вы пытаетесь отправить получателю.
Таким образом, и отправитель, и получатель должны понять при установлении между
ними, как этот процесс шифрования и как будет работать расшифровка.
Для этого работает
любое шифрование и расшифровка на основе обмена секретными ключами.
Таким образом, в криптографии симметричных ключей,
и отправитель, и получатель будут делиться секретным ключом между двумя сайтами,
и этот секретный ключ известен только отправителю и стороне получателя.
Поэтому, когда отправителю нужно отправить сообщение,
отправитель шифрует это сообщение с помощью криптографического алгоритма,
который использует секретный ключ в качестве других входных данных для этого алгоритма.
И как только это сообщение будет передано через этот криптографический алгоритм,
то будет сгенерировано зашифрованное сообщение.
Теперь это зашифрованное сообщение будет отправлено на канал через сторону приемника.
Если у вас есть сторонний вредоносный пользователь
, прослушивающий и записывающий это зашифрованное сообщение, ему
будет трудно расшифровать
это сообщение, потому что для расшифровки зашифрованного сообщения
вам все равно нужен секретный ключ.
Теперь, на стороне получателя,
когда получено зашифрованное сообщение,
то приемник будет применять и алгоритм расшифровки,
который также принимает в качестве ввода
тот же секретный ключ, который использовался на стороне отправителя для шифрования сообщения.
Таким образом, после расшифровки исходное сообщение будет извлечено
и может быть обработано на стороне получателя.
Теперь, если вредоносная третья сторона захочет расшифровать это зашифрованное сообщение,
они столкнутся с тяжёлой борьбой, потому что
процесс шифрования с помощью секретного ключа превратит сообщение и может,
в свою очередь, зашифровать сообщение.
Без обладания секретным ключом,
расшифровать зашифрованное сообщение будет почти невозможно.
Ну, это растягивание немного далеко.
Было бы необычно сложно расшифровать зашифрованное сообщение.
Если вы используете методы грубой силы, то в конечном итоге
вы закончите расшифровку зашифрованного сообщения.
Но это займет так много времени и потребует столько вычислительной мощности.
Не стоит усилий для
стороннего злоумышленника, чтобы попытаться расшифровать зашифрованное сообщение.
Таким образом, вы, по сути, затрудняете для кого-то
расшифровать сообщение, если у них нет секретного ключа.
Теперь, поскольку секретный ключ известен только отправителю и
получателю, обе стороны, отправитель и получатель,
могут общаться с уверенностью,
что зашифрованное сообщение со
стороны отправителя может быть расшифровано только стороной получателя.
Вот как работает симметричная криптография ключей.
Тот факт, что у вас есть один и тот же секретный ключ,
разделяемый между отправителем и получателем, означает, что
включение процесса расшифровки использует один и тот же секретный ключ
, следовательно, симметричный ключ криптографии.
Конечно, при криптографии симметричного ключа
одна из проблем заключается в том, что и отправитель, и
получатель должны иметь доступ к одному и тому же секретному ключу.
Теперь, если отправитель и получатель обмениваются данными по небезопасному каналу,
обеим сторонам будет трудно прийти к пониманию одного и того
же секретного ключа, не раскрывая его другим.
Вот где очень полезен другой алгоритм, называемый криптографией с открытым ключом.
Как работает криптография с открытым ключом?
Теперь, в криптографии с открытым ключом,
идея заключается в том, что у вас есть два разных ключа.
У вас есть открытый и закрытый ключ.
Теперь открытый ключ может быть широко распространен среди всех, кого вы хотите.
Поэтому, когда кто-то хочет отправить вам сообщение
, он будет использовать ваш открытый ключ для шифрования сообщения.
Поэтому, если отправитель хочет отправить сообщение получателю,
отправитель будет использовать открытый ключ от получателя для
шифрования сообщения на стороне отправителя с помощью алгоритма шифрования.
Теперь, как только зашифрованное сообщение будет отправлено
по небезопасному каналу на сторону
получателя, получатель будет использовать закрытый ключ
, который знает только получатель, для расшифровки.
Теперь, чтобы криптография с открытым ключом работала так, как мы видели,
публичный ключ может быть широко распространен без каких-либо проблем.
Но так как закрытый ключ известен только стороне получателя,
только получатель сможет расшифровать сообщение, и,
опять же, сторонний злоумышленник, который захватывает
это зашифрованное сообщение, будет чрезвычайно трудно расшифровать сообщение.
Теперь, конечно, в криптографии с открытым ключом,
публичный и закрытый ключ являются двумя разными ключами.
Теперь ваш очевидный следующий вопрос будет: почему бы
просто не использовать криптографию с открытым ключом для шифрования.
Проблема в том, что использование криптографии с открытым ключом
для шифрования и расшифровки является дорогостоящим процессом,
поэтому мы не используем криптографию с открытым ключом для всей их коммуникации.
Вместо этого криптография с открытым ключом будет использоваться в
первую очередь для отправителя и получателя, чтобы
согласовать общий секретный ключ, который оба будут использовать.
Позже мы увидим, как криптография с открытым ключом
может быть использована для установления общего секретного ключа
между отправителем и получателем, а затем
использовать криптографию симметричного ключа для дальнейшей связи.
Одним из протоколов, использующих этот подход, является
уровень безопасности сокетов, а также протоколы безопасности транспортного уровня,
SSL и TLS.
Так много раз, когда вы читаете документацию,
вы можете услышать о SSL и TLS.
Эти криптографические протоколы обеспечивают безопасную связь между
отправителем и получателем по небезопасной сети, такой как Интернет.
Отправитель и получатель будут общаться через Интернет с помощью зашифрованных сообщений,
которые могут расшифровать только отправитель и получатель.
И этот подход, либо SSL, либо TLS,
использует комбинацию криптографии с открытым ключом вместе с криптографией симметричного ключа.
Их точный процесс сделать это,
я объясню на следующем слайде.
Кроме того, используя SSL или TLS,
мы пытаемся поддерживать две разные вещи.
Во-первых, мы пытаемся сохранить конфиденциальность
связи между отправителем и получателем, чтобы
ни одна вредоносная третья сторона не могла извлечь сообщение из зашифрованного сообщения.
Во-вторых, мы также пытаемся сохранить целостность,
что означает, что когда отправитель отправляет сообщение,
получатель сможет быть уверен, что сообщение не было изменено.
Таким образом, как безопасность, так и поддержание целостности очень важны в данном случае.
Таким образом, конфиденциальность и целостность должны поддерживаться
этим защищенным протоколом связи, который мы создаем
для обмена между отправителем и получателем.
Давайте кратко поговорим о том, как на самом деле работают SSL или TLS.
Это делается через процесс рукопожатия, который я проиллюстрировал на этой диаграмме здесь.
Когда клиент хочет связаться с сервером,
клиент отправляет сообщение на сервер,
указав, что клиент хочет безопасно взаимодействовать с сервером.
На этом этапе сервер отправит клиенту сертификат,
содержащий открытый ключ,
который был сертифицирован
центром сертификации как принадлежащий этому конкретному серверу.
Таким образом, когда клиент получает
этот открытый ключ плюс сертификацию центром сертификации,
клиент сможет проверить учетные данные сервера.
Таким образом, клиент должен установить, что он действительно разговаривает с сервером,
с которым он намерен общаться.
Таким образом, на данный момент,
когда клиент проверяет учетные данные сервера,
клиент теперь имеет доступ к публичному ключу сервера.
Как только клиент получит открытый ключ сервера,
клиент сгенерирует то, что называется секретом предварительного мастера.
Этот предварительный секрет - это то, что клиент и
сервер будут использовать для генерации того, что называется ключом сеанса.
Таким образом, клиент генерирует предварительный секрет,
клиент затем шифрует этот секрет, используя открытый ключ сервера,
а затем отправляет секрет на сервер.
Теперь помните, что после шифрования секрета с помощью открытого ключа
никто, кроме сервера, не сможет
извлечь информацию из зашифрованного сообщения.
Таким образом, когда сервер получает это зашифрованное сообщение,
сервер извлекает из этого сообщения секреты предварительного мастера.
Теперь и клиент, и сервер обладают одним и тем же секретом предварительного мастера.
На этом этапе и клиент, и сервер будут использовать один и
тот же набор шагов, начиная с секрета предварительного мастера,
и с тем же набором значений,
который будет генерировать ключ, называемый ключом сеанса.
Теперь, когда ключ сеанса генерируется как на стороне клиентов, так и на стороне сервера,
это будет точно тот же ключ сеанса,
потому что оба будут следовать точно тому же процессу для генерации ключа сеанса.
Итак, на данный момент,
как клиент, так и сервер,
теперь обладают секретным ключом, который одинаков на обоих сайтах.
Таким образом, все последующие связи между сервером и клиентом
могут затем продолжаться с использованием симметричного шифрования.
Таким образом, когда клиенту нужно связаться с сервером,
клиент будет шифровать данные с помощью секретного ключа сеанса,
а затем отправлять их данные.
Аналогично, когда сервер должен взаимодействовать с клиентом,
сервер, очевидно, будет использовать
тот же ключ сеанса для шифрования данных, а затем отправить его клиенту.
Теперь, поскольку клиент имеет тот же ключ сеанса,
клиент сможет расшифровать сообщение и извлечь незашифрованное сообщение.
Используя эту процедуру,
клиент и сервер гарантировали, что связь между ними является частной.
Кроме того, нам удается убедиться, что ни одна вредоносная третья сторона не может
перехватить сообщение и вызвать какие-либо изменения в сообщении.
Таким образом, целостность сообщения также поддерживается,
и конфиденциальность связи
между клиентом и сервером также поддерживается.
Итак, вся эта дискуссия, которую я представил вам за последние несколько слайдов,
в двух словах,
как безопасная связь между клиентом и сервером может быть обеспечена
с помощью криптографии симметричного ключа и криптографии открытого ключа.
Очевидно, в этом есть гораздо больше, чем то, что я здесь объяснил,
но этого понимания того, как работает криптография,
достаточно для того, чтобы вы поняли, как работает весь процесс.
Теперь, если вам интересно узнать больше об этом,
одним из хороших источников для изучения криптографических протоколов является очень хорошая книга
Джима Крозона Кита Росса под названием «Компьютерные сети».
Эта книга имеет очень простую для понимания главу
о криптографии и безопасности применительно к сетевой коммуникации.
Теперь, когда мы установили процесс
для безопасной связи между клиентом и сервером,
давайте посмотрим, как сам Интернет использует это,
для связи между клиентом и сервером с помощью HTTP.
Теперь, это то, где протокол HTTPS входит в картину.
Как вы уже понимаете об Интернете,
Интернет представляет собой многоуровневую архитектуру,
где IP и TCP образуют сеть,
а транспортный уровень, который работает поверх базовой сети.
Теперь, поверх транспортного уровня,
у вас есть защищенный слой сокета или подкладка безопасности транспортного уровня как
тонкий слой поверх TCP, который
обеспечивает безопасную связь между клиентом и сервером.
И поверх этого может работать HTTP.
Таким образом, HTTP по существу включает HTTP плюс использование шифрования,
расшифровки, поддерживаемых через SSL и TLS.
Очевидно, даже для протокола HTTPS
есть гораздо больше деталей.
Но с точки зрения реализации серверной стороны,
того, что мы поняли здесь, достаточно, чтобы понять, как
настроить сервер для использования безопасной связи между клиентом и сервером.
Теперь, конечно, первый вопрос, который придет вам на ум, заключается в
том, что сервер нуждается в открытом ключе и закрытом ключе.
Для криптографии с открытым ключом,
как сервер генерирует это?
Если вы используете реальный производственный сервер в
своей среде и предоставляете услуги пользователям для доступа к вашему серверу,
то, очевидно, вам нужно пройти процесс сертификации.
Здесь вы будете обращаться в центр сертификации, например, к
корпорациям, таким как VeriSign и Thawte Corporation
, которые являются государственными сертификационными центрами.
Есть еще несколько по всему миру.
Таким образом, вы обратитесь к ним,
и эти центры сертификации проведут аутентификацию ваших учетных данных,
они обеспечат, что вы являетесь тем, кем вы утверждаете,
и затем они проверят ваши учетные данные
, а затем в этот момент
они выдадут вам открытый ключ и закрытый ключ для использования на сайте сервера.
Таким образом, как только они выдают открытый ключ и закрытый
ключ, открытый ключ будет сертифицирован центром сертификации,
а затем открытый ключ также будет нести,
кроме того, сертификат.
Итак, это сертификат, который вы отправите на сайт клиента.
Поскольку клиенты могут установить
подлинность этих центров сертификации,
если вы посмотрите на любой браузер, вы заметите, что большинство браузеров будут иметь
сертификаты для всех установленных центров сертификации,
уже встроенных в них.
Таким образом, они смогут установить ваши учетные данные,
или, скорее, они смогут установить, что закрытый ключ принадлежит вам,
получая ваш сертификат, а затем проверяя или проверяя
ваш сертификат, зная, что он был подписан одним
из этих установленных сертификатов Власти.
После этого, клиент сможет установить вашу подлинность.
Теперь, в этом курсе,
мы просто хотим понять, как работает каждый HTTPS,
а также хотим иметь простой способ
настройки сервера с открытым ключом и закрытым ключом.
Поскольку мы делаем это как упражнение для понимания HTTPS,
мы можем использовать инструмент под названием open SSL, который уже доступен на
наших компьютерах, чтобы генерировать то, что называется самозаверяющим сертификатом.
Самозаверяющие ключи недопустимы во внешней работе.
Но поскольку мы знаем, что мы используем его только для наших целей тестирования,
мы можем использовать самозаверяющие сертификаты,
просто для понимания процесса
безопасной связи между клиентом и сервером.
Итак, как мы используем открытый SSL?
До сих пор, используя открытый SSL, вы можете генерировать ключи,
используя три команды, которые я показываю вам здесь.
Эти три команды выполняются в этой последовательности,
как указано здесь, и это поможет вам
создать закрытый ключ и сертификат, которые можно сделать доступными с
HTTPS-сервера для загрузки клиентов и,
таким образом, получить открытый ключ для безопасной связи.
Таким образом, это операция, которую мы собираемся сделать в нашем упражнении, которое следует за
этой лекцией для создания и выпуска DPS service.So три шага, которые мы делаем, это
, во-первых, мы будем генерировать закрытый ключ с помощью первой команды.
Затем мы сгенерируем cert.csr, который затем будет использоваться
для нас, чтобы создать сертификат, который
может быть распространен на стороне клиента третьей командой, показанной там.
Таким образом, эти шаги позволят вам создать закрытый ключ,
а также соответствующий сертификат, который может быть выдан клиенту.
Опять же, чтобы подчеркнуть, что если вы используете производственный
сервер, вам нужно получить открытый ключ, пару закрытого ключа,
от одного из центров сертификации, таких как VeriSign и Thawte корпорации.
Как сам узел работает, помогая нам настроить HTTPS?
Теперь здесь я кратко рассматриваю код, который мы будем
использовать в следующем упражнении, чтобы настроить наши серверы.
Сам узел имеет HTTPS в качестве основного модуля внутри узла.
Таким образом, мы настроим HTTPS, требуя этого основного модуля.
Мы также будем использовать модуль ядра файловой системы, потому что
закрытый ключ и сертификат, который мы генерируем, будут храниться на нашей стороне сервера,
и они будут необходимы для
вашего экспресс-приложения для настройки вашего безопасного сервера.
Таким образом, здесь мы будем использовать файловую систему с
методом ReadFileSync для чтения в закрытом ключе
и сертификат из файлов, которые мы
генерируем с помощью шагов, которые мы видели в предыдущем слоте.
Поэтому, как только эти два значения будут готовы,
параметры для вашего HTTPS сервера будут настроены, а затем вы можете настроить
свой безопасный сервер для обеспечения связи на основе HTTPS с сайта сервера.
Теперь, когда вы быстро понимаете, как работает ваш HTTPS,
и как он использует криптографию открытого ключа
и криптографию симметричных ключей для
обеспечения безопасной связи между клиентом и сервером.
Давайте перейдем к упражнению, чтобы фактически настроить
наш экспресс-сервер, который мы построили до сих пор для использования протокола HTTPS.