SSL / TLS 101 для начинающих

Углубленный взгляд на шифрование, которое защищает наши интернет-соединения


Хотя Netscape изначально изобрел SSL в середине 90-х, для каждого веб-сайта не становилось обязательным устанавливать сертификат SSL / TLS до лета 2018 года, когда Google начал отмечать незашифрованные сайты ».Не является безопасным

Хотя Google – с его поисковой системой, браузером Chrome и ОС Android – может переопределять Интернет в одностороннем порядке, он не был одинок в этом мандате. Apple, Microsoft, Mozilla и другие основные заинтересованные стороны в технологической отрасли приняли согласованное решение о выдаче сертификатов SSL / TLS и HTTPS..

Причина этого проста: без SSL / TLS и возможности безопасного соединения через HTTPS все коммуникации между веб-сайтами и их посетителями будут передаваться в виде открытого текста и легко читаться третьей стороной..

Единственным недостатком этого недавнего стремления к универсальному шифрованию является то, что он вынудил новых клиентов попасть на незнакомый рынок, который очень мало делает для того, чтобы стать менее запутанным для среднего веб-сайта или владельца бизнеса.

Эта статья послужит исчерпывающим руководством по всем вопросам, связанным с SSL / TLS. Мы заложим основу, пройдясь по таким базовым понятиям, как шифрование, HTTPS и природа интернет-соединений..

Надеемся, что к концу вы будете уверены в выборе, покупке и внедрении сертификата TLS, и помните, если у вас есть какие-либо вопросы, которые вы можете оставить их в комментариях ниже.

Основополагающие элементы

Давайте начнем с обсуждения концепции, которая лежит в основе всего этого: шифрование.

Шифрование, в его самой простой итерации, представляет собой нечто большее, чем шифрование данных – с использованием заранее определенного шифра или ключа – так что оно становится нечитаемым для всех, кроме другой стороны с таким же закрытым ключом.

На протяжении всей истории шифрование с закрытым ключом было самой распространенной моделью. При шифровании с закрытым ключом обе стороны должны обладать или, по крайней мере, обмениваться закрытым ключом, который может использоваться как для шифрования, так и для дешифрования.

В начале большинство шифров, лежащих в основе этих криптосистем, были примитивными, полагаясь на простые замены или заменяя общие слова символами. Но со временем математика стала более подвержена влиянию математики и усложнилась..

Например, в середине 1600-х годов во Франции криптограф Короля Людовика XIV создал шифр, который был так хорошо спроектирован, что его не взломали до 250 лет спустя и только потом частично. На сегодняшний день во французских архивах хранятся записи за сотни лет, которые, возможно, никогда не расшифровать..

Но в то время как исторически шифрование было средством скрытности или тайности, появление Интернета сделало эту концепцию более распространенной. Интернет вездесущ, и он выполняет целый ряд важных функций. Каждый день миллиарды людей используют его для доступа и отправки конфиденциальной информации, управления своими финансами, ведения бизнеса – вы называете это.

Проблема в том, что интернет не был полностью разработан, чтобы соответствовать тому, чем он стал. В начале, когда академические круги и правительство США впервые разрабатывали сетевые протоколы, Интернет рассматривался только как механизм для свободного обмена информацией между правительством и академическими учреждениями. На тот момент коммерческая деятельность была нелегальной онлайн. Электронная коммерция еще не была изобретена. И веб-сайт был скорее географическим понятием.

Итак, когда HTTP или протокол передачи гипертекста был впервые введен в 1991 году, тот факт, что создаваемые им соединения обменивались данными в виде открытого текста, не был проблемой.

Вещи сильно отличаются сегодня. Информация, которой обмениваются онлайн, не является академическим исследованием или свободно доступной информацией, это личная информация и конфиденциальные данные, которые могут стоить людям денег или даже, в некоторых регионах, их жизни. Это требовало более безопасного подхода.

Ответ был шифрованием.

Вопрос обмена ключами

Одна проблема, которая исторически преследовала даже самые лучшие криптосистемы, сохраняется и по сей день.

То, что мы обсуждали ранее и что традиционно является стандартом шифрования, – это шифрование с закрытым ключом. Это также называется симметричным шифрованием или двусторонним шифрованием – с закрытыми ключами, выполняющими функции шифрования и дешифрования, необходимые для обмена данными..

Чтобы шифрование с закрытым ключом работало, закрытый ключ должен передаваться между сторонами, или обеим сторонам необходимо иметь свою собственную копию. В любом случае безопасность закрытого ключа была критически важной для целостности криптосистемы, и, как вы можете, без сомнения, предположить, обмен ключами является такой же старой проблемой, как само шифрование..

Затем, в 1970-х годах – технически два разных времени, на расстоянии целого океана – была концептуализирована и воплощена в жизнь новая форма шифрования: шифрование с открытым ключом..

В то время как шифрование с закрытым ключом представляет собой двустороннюю симметричную функцию с закрытым ключом, способным как шифровать, так и дешифровать данные, шифрование с открытым ключом является асимметричным; в одну сторону. Вместо одного закрытого ключа существует пара открытый-закрытый ключ. Открытый ключ обрабатывает шифрование и, как следует из названия, общедоступен, в то время как закрытый ключ, который выполняет дешифрование, держится в секрете его владельцем. Используя открытый ключ, можно зашифровать часть данных и отправить их владельцу ключа, где только они смогут его расшифровать..

Отлично, но как это полезно?

Что ж, одностороннее шифрование не является идеальным для шифрования интернет-соединений, довольно сложно общаться, когда одна сторона может только шифровать, а другая – только дешифровать. Нет, для шифрования интернет-соединения вам необходимо использовать симметричное шифрование с закрытым ключом.

Но как вы обмениваетесь ключами? Особенно онлайн?

Шифрование с открытым ключом.

И в этом заключается сущность SSL / TLS: безопасный обмен ключами..

Здесь мы свяжем все эти понятия вместе. Если вы хотите, чтобы ваше общение с веб-сайтом было конфиденциальным, вам необходимо безопасно подключиться к нему. Если вы хотите безопасно подключиться к этому веб-сайту, вам необходимо обменяться симметричными закрытыми ключами, чтобы вы могли использовать их для общения. SSL / TLS (и PKI в целом) – это просто причудливый механизм создания и обмена этим ключом сеанса.

Используя SSL / TLS, вы можете аутентифицировать сервер или организацию, к которой вы собираетесь подключиться, и обеспечить безопасный обмен секретными ключами, которые вы будете использовать для шифрования вашего общения с предполагаемой стороной..

К сожалению, SSL / TLS и PKI имеют много терминологии и движущихся частей, которые могут легко запутать людей, но те, кто верит в то, что когда вы отбросите все математические и технические термины, это просто элегантное современное технологическое решение для эпохи проблема: обмен ключами.

Теперь давайте рассмотрим несколько ключевых терминов

Прежде чем мы пойдем дальше, давайте рассмотрим пару других ключевых терминов. Мы уже ввели HTTP, протокол передачи гипертекста, который был основой Интернета на протяжении десятилетий. Но, как мы уже говорили, Интернет превратился в нечто совершенно иное, чем было, когда HTTP был впервые опубликован в 1991 году..

Необходим более безопасный протокол. Таким образом, HTTPS.

HTTPS, который иногда называют HTTP поверх TLS, использует шифрование, чтобы сделать данные, которыми обмениваются во время соединения, нечитаемыми никому, кроме предполагаемой стороны. Это особенно важно, если учесть характер современного подключения к интернету..

Если в первые дни Интернета соединение было достаточно прямым, то теперь соединения маршрутизируются через десятки устройств на пути к месту назначения. Если вы когда-либо хотели на практике продемонстрировать это, откройте командную строку в вашей ОС и введите команду «tracert geekflare.com».

То, что вы увидите, – это путь, по которому ваше соединение прошло по пути к месту назначения. До 30 прыжков. Это означает, что ваши данные проходят через каждое из этих устройств до того, как они попадают на какой-либо веб-сайт или приложение, к которому вы подключаетесь. И если у кого-либо на любом из этих устройств установлен перехватчик пакетов или прослушиватель, они могут украсть любые передаваемые данные и даже манипулировать соединением в некоторых случаях..

Это называется атака «человек посередине» (MITM).

Если вы хотите узнать об атаке MITM, то проверить этот онлайн-курс.

Современные интернет-соединения гораздо шире, чем кажется большинству людей, поэтому шифрование данных во время передачи имеет решающее значение. Вы понятия не имеете, кто может слушать, или как легко это сделать.

HTTP-соединение осуществляется через порт 80. Для наших целей вы можете рассматривать порты как конструкции, которые указывают на сетевую службу или протокол. Стандартный веб-сайт, обслуживаемый по протоколу HTTP, использует порт 80. HTTPS обычно использует порт 443. Когда веб-сайт устанавливает сертификат, он может перенаправить свои страницы HTTP на HTTPS, и браузеры пользователей будут пытаться подключиться через порт 443 в безопасном режиме, ожидая проверки подлинности..

К сожалению, термины SSL / TLS, HTTPS, PKI и шифрование часто встречаются, иногда даже взаимозаменяемо, поэтому, чтобы устранить любую давнюю путаницу, вот краткое руководство:

  • SSL – Secure Sockets Layer, оригинальный протокол шифрования, используемый с HTTPS
  • TLS – Transport Layer Security, более новый протокол шифрования, который заменил SSL
  • HTTPS – Безопасная версия HTTP, используемая для создания соединений с веб-сайтами.
  • ИПК – Инфраструктура открытых ключей, относится ко всей модели доверия, которая облегчает шифрование с открытым ключом.

SSL / TLS работает в сочетании, чтобы включить HTTPS-соединения. И PKI относится ко всему, когда вы уменьшаете.

Понял? Не волнуйся, ты будешь.

Построение инфраструктуры открытого ключа

Теперь, когда мы заложили основу, давайте уменьшим масштаб и посмотрим на архитектуру, используемую моделью доверия в основе SSL / TLS..

Когда вы заходите на веб-сайт, первое, что делает ваш браузер, проверяет подлинность сертификата SSL / TLS, с которым его представляет сайт. Мы доберемся до того, что происходит после того, как эта аутентификация пройдет в нескольких разделах, но мы собираемся начать с обсуждения модели доверия, которая делает все это возможным.

Итак, начнем с постановки вопроса: как мой компьютер узнает, доверять ли данному SSL / TLS-сертификату??

Чтобы ответить на это, нам нужно обсудить PKI и различные элементы, которые заставляют его работать. Начнем с центров сертификации и корневых программ..

Центры сертификации

Центр сертификации – это организация, которая соответствует набору заранее определенных стандартов в обмен на возможность выпуска доверенных цифровых сертификатов..

Существуют десятки ЦС, как бесплатных, так и коммерческих, которые могут выдавать доверенные сертификаты..

Все они должны соблюдать ряд стандартов, которые были обсуждены и приняты на законодательном уровне через CA / Browser Forum, который действует как регулирующий орган для отрасли TLS. Эти стандарты обозначают такие вещи, как:

  • Технические меры предосторожности, которые должны быть на месте
  • Лучшие практики для выполнения проверки
  • Выдача лучших практик
  • Процедуры отзыва и сроки
  • Требования к регистрации сертификатов

Эти рекомендации были изложены браузерами совместно с центрами сертификации. Браузеры играют уникальную роль в экосистеме TLS.

Никто не может получить доступ к Интернету без своего веб-браузера. Таким образом, именно браузер будет получать и проверять цифровой сертификат TLS, а затем обмениваться ключами с сервером. Таким образом, учитывая их первостепенную роль, они несут значительное влияние.

И важно помнить, что браузеры были разработаны так, чтобы быть максимально скептическими. Верить ничему. Это лучший способ обеспечить безопасность своих пользователей. Таким образом, если браузер собирается доверять цифровому сертификату, который потенциально может быть использован не по назначению в ущерб пользователю, ему необходимы определенные гарантии того, что тот, кто выпустил этот сертификат, проявил должную осмотрительность..

Это роль и ответственность сертификационных органов. И браузеры тоже не допускают ошибок. Существует буквальное кладбище бывших ЦС, которые столкнулись с браузерами и были выведены на пастбище.

Когда центр сертификации продемонстрировал соответствие базовым требованиям CAB Forum и прошел все необходимые проверки и проверки, он может обратиться к различным корневым программам с просьбой добавить свои корневые сертификаты.

Корневые программы

Корневая программа, основными из которых являются Apple, Microsoft, Google и Mozilla, – это устройство, которое контролирует и поддерживает корневые хранилища (иногда называемые хранилищами доверия), которые представляют собой коллекции сертификатов корневого центра сертификации, которые находятся в системе пользователя. Опять же, эти корни невероятно ценны и невероятно опасны – в конце концов, они могут выдавать надежные цифровые сертификаты – поэтому безопасность является первостепенной задачей.

Вот почему ЦС почти никогда не выдают непосредственно из самих сертификатов корневого ЦС. Вместо этого они раскручивают промежуточные корневые сертификаты и используют их для выдачи конечных пользователей или конечных сертификатов. Они также могут передавать эти корни суб-CA, которые являются центрами сертификации, которые не имеют своих выделенных корней, но могут выпускать кросс-подписанные сертификаты от своих посредников..

Итак, давайте сложим все это вместе. Когда веб-сайт хочет выдать сертификат TLS, он генерирует нечто, называемое Запросом подписи сертификата (CSR), на сервере, на котором он размещен. В этом запросе содержатся все данные, которые веб-сайт хочет включить в сертификат. Как вы увидите чуть позже, объем информации может варьироваться от полной бизнес-информации до простой идентификации сервера, но после завершения CSR она отправляется в центр сертификации для выдачи..

Перед выдачей сертификата ЦС должен будет провести обязательную экспертизу, предписанную CA / Browser Forum, и подтвердить правильность информации, содержащейся в CSR. После проверки он подписывает сертификат своим закрытым ключом и отправляет его обратно владельцу веб-сайта для установки..

Цепочка сертификатов

После того, как сертификат TLS был установлен, каждый раз, когда кто-либо посещает сайт, на котором размещается сервер, он предоставляет браузеру пользователя сертификат. Браузер будет смотреть на цифровую подпись на сертификате, которая была сделана доверенным центром сертификации, что подтверждает, что вся информация, содержащаяся в сертификате, является точной.

Здесь вступает в действие термин цепочка сертификатов.

Браузер собирается прочитать цифровую подпись и переместить ссылку вверх по цепочке – затем он проверит цифровую подпись на промежуточном сертификате, закрытый ключ которого использовался для подписи конечного сертификата. Он будет продолжать следовать подписи до тех пор, пока либо цепочка сертификатов не закончится на одном из доверенных корней в своем корневом хранилище, либо пока цепочка не прекратит работу, не достигнув корня, и в этом случае появится ошибка браузера, и соединение не будет установлено.

Вот почему вы не можете выдавать и подписывать сертификаты самостоятельно.

Браузеры будут доверять только сертификатам SSL / TLS, которые они могут связать обратно со своим корневым хранилищем (это означает, что они были выпущены доверенным лицом). Центры сертификации обязаны соблюдать определенные стандарты, чтобы поддерживать свою надежность, и даже в этом случае браузеры не хотят им доверять.

Браузеры не имеют таких гарантий относительно самозаверяющих сертификатов, поэтому их следует развертывать только во внутренних сетях, за брандмауэрами и в тестовых средах..

Типы и функциональность сертификатов SSL / TLS

Прежде чем мы рассмотрим SSL / TLS в движении, давайте поговорим о сертификатах и ​​различных доступных итерациях. Сертификаты TLS – это то, что облегчает протокол TLS и помогает определять условия зашифрованных соединений HTTPS, которые устанавливает веб-сайт..

Ранее мы упоминали, что установка сертификата TLS позволяет настроить ваш веб-сайт на подключение HTTPS через порт 443. Он также действует как своего рода значок имени для сайта или сервера, с которым вы взаимодействуете. Возвращаясь к идее, что в основе своей лежит SSL / TLS и PKI – все это изысканные формы безопасного обмена ключами, сертификат SSL / TLS помогает уведомить браузер о том, кому он отправляет ключ сеанса, – кому эта сторона на другом конце связь.

И когда вы разбиваете различные итерации сертификатов SSL / TLS, это уместно иметь в виду. Сертификаты различаются в зависимости от функциональности и уровня проверки. Или, другими словами, они различаются в зависимости от:

  • Сколько тождеств утверждать
  • Какие конечные точки для утверждения идентичности на

Ответ на эти два вопроса даст вам достаточно четкое представление о том, какой тип сертификата вам нужен..

Сколько тождеств утверждать

Для сертификатов SSL / TLS доступны три различных уровня проверки, и они различаются в зависимости от того, сколько информации о личности ваш сайт хочет утверждать..

  • Сертификаты SSL для проверки доменов – подтверждение личности сервера
  • SSL-сертификаты проверки организации – подтверждение частичной идентификации организации
  • SSL-сертификаты расширенной проверки – подтверждение полной идентичности организации

Сертификаты проверки доменов на сегодняшний день являются наиболее популярными благодаря своей цене и скорости, с которой они могут быть выданы. Сертификаты DV SSL / TLS требуют простой проверки управления доменом, которая может быть выполнена несколькими различными способами, но как только это сертификат может быть выдан. Вы также можете бесплатно получить некоторые 30-дневные и 90-дневные версии, что, несомненно, увеличило их долю на рынке..

Недостатком является то, что сертификаты DV SSL подтверждают минимальную идентичность. И учитывая, что почти на половине всех фишинговых сайтов теперь установлен сертификат DV SSL, они не обязательно приносят вам большую прибыль..

Сертификаты организации Сертификаты SSL являются исходным типом сертификата SSL / TLS. Они также являются единственным видом SSL-сертификата, который может защитить IP-адрес после решения CAB Forum от 2016 года об аннулировании всех SSL-сертификатов в интрасети. Валидация организации требует легкой проверки бизнеса и обычно может быть выдана в течение дня или двух, иногда быстрее. Сертификаты OV SSL содержат некоторую организационную информацию, но пользователю Интернета нужно будет щелкнуть значок замка и найти его. В настоящее время вы видите множество SSL-сертификатов OV, развернутых в крупных корпоративных и корпоративных сетях, например, для соединений, выполняемых за брандмауэрами..

Поскольку ни сертификаты DV, ни OV SSL не обеспечивают достаточную идентичность, чтобы удовлетворить большинство браузеров, к которым они относятся нейтрально.

Сертификаты с расширенной проверкой SSL на сегодняшний день являются наиболее спорными, так как некоторые в техническом сообществе считают, что необходимо сделать больше для усиления проверки, от которой они зависят. Но EV SSL утверждает максимальную идентичность. Чтобы завершить расширенную проверку, центр сертификации проводит тщательную проверку организации, которая в некоторых случаях может занимать до недели..

Но преимущество неоспоримо: поскольку он обеспечивает достаточную идентичность, веб-сайт с сертификатом EV SSL получает уникальную обработку браузера, включая отображение его имени в адресной строке браузера..

Нет другого способа сделать это, и вы не можете подделать его – адресная строка EV является одним из самых мощных визуальных индикаторов, которые мы имеем сегодня.

Какие конечные точки для утверждения идентичности на

Другой способ изменения сертификатов SSL / TLS – это функциональность. С первых дней существования интернета веб-сайты развивались совсем немного, и различные компании размещали сайты по-разному. В некоторых есть несколько доменов для разных компаний. другие используют субдомены для множества функций и веб-приложений. Некоторые используют оба.

Независимо от контекста, есть сертификат SSL / TLS, который может помочь защитить его.

Единый домен

Основной веб-сайт и стандартный сертификат SSL – это всего лишь один домен. Большинство современных сертификатов SSL / TLS защищают как WWW, так и не WWW версии этого домена, но он ограничен одним доменом. Вы можете сравните SSL сертификаты здесь.

Multi-Domain

Многодоменные сертификаты или Сертификаты унифицированных коммуникаций (в случае серверов Microsoft Exchange и Office Communications) также существуют, чтобы дать организациям возможность шифровать несколько доменов с помощью одного сертификата. Это может быть привлекательным вариантом, поскольку это экономит деньги и значительно упрощает управление сертификатами (срок действия / продление).

Многодоменные и UCC сертификаты используют SAN, поле Subject Alternative Name в CSR, чтобы добавить дополнительные домены к сертификату. Большинство ЦС допускают до 250 различных SAN на один сертификат. И большинство многодоменных сертификатов поставляются с 2-4 бесплатными сетями SAN, остальные доступны для покупки по мере необходимости.

Wildcard SSL-сертификаты

Wildcard SSL сертификаты являются чрезвычайно полезными типами сертификатов, поскольку они могут шифровать неограниченное количество поддоменов на одном и том же уровне URL. Например, если у вас есть веб-сайт, который использует субдомены, такие как:

  • app.website.com
  • portal.website.com
  • user.website.com

Вы можете зашифровать их все одним и тем же сертификатом подстановочного знака, используя звездочку в поле FQDN вашего CSR: * .website.com

Теперь любой поддомен, даже тот, который вы еще не добавили, может быть защищен этим сертификатом..

Есть два недостатка к сертификатам Wildcard, хотя. Во-первых, используя один и тот же открытый ключ на некоторых конечных точках, вы более уязвимы для определенных эксплойтов, таких как атаки Bleichenbacher..

Другой заключается в том, что нет опции EV Wildcard. Из-за открытого характера функциональности Wildcard, браузеры не в порядке с делегированием им такого уровня доверия. Если вы хотите, чтобы адресная строка EV была в ваших поддоменах, вам придется зашифровать их по отдельности или использовать многодоменный сертификат EV.

Многодоменный подстановочный знак

Относительно новое дополнение к экосистеме SSL / TLS, Многодоменный подстановочный знак может шифровать до 250 различных доменов, но он также может использовать звездочку в полях SAN, что также позволяет шифровать 250 различных доменов И все их сопровождающие в первую очередь поддомены.

Другой вариант использования многодоменного подстановочного знака – это многоуровневый подстановочный знак, где он может зашифровать поддомен на нескольких уровнях URL-адреса (стандартный подстановочный знак может зашифровать их только на одном уровне).

Из-за функциональности подстановочных знаков, многодоменные подстановочные знаки не доступны в EV, либо.

SSL / TLS в движении

Теперь, когда мы рассмотрели все важные концепции, которые составляют SSL / TLS и PKI, давайте соберем все воедино и увидим в движении.

Проверка и выдача

Давайте начнем с самого начала с веб-сайта, покупающего сертификат SSL / TLS у ЦС или посредника. После покупки организационный контакт, который обрабатывает получение сертификата, создает запрос на подпись сертификата на сервере, на котором будет установлен сертификат (сервер, на котором размещен веб-сайт)..

Наряду с CSR сервер также сгенерирует пару открытый / закрытый ключ и сохранит закрытый ключ локально. Когда ЦС получает CSR и Открытый ключ, он выполняет необходимые шаги проверки, чтобы гарантировать точность любой информации, содержащейся в сертификате. Как правило, для сертификатов бизнес-аутентификации (не DV) это включает поиск информации о регистрации организации и публичных записей в государственных базах данных..

После завершения проверки ЦС использует один из закрытых ключей одного из своих сертификатов-эмитентов, обычно промежуточного корня, и подписывает сертификат, прежде чем вернуть его владельцу сайта..

Теперь владелец веб-сайта может взять недавно выданный сертификат SSL / TLS, установить его на своем сервере и настроить веб-сайт для создания HTTPS-соединений через порт 443 (с помощью перенаправления 301 для отправки трафика с ранее существующих страниц HTTP на их новые аналоги HTTPS).

Аутентификация и SSL рукопожатие

Теперь, когда сертификат SSL / TLS установлен, а веб-сайт настроен для HTTPS, давайте посмотрим, как это облегчит зашифрованные соединения с посетителями сайта..

По прибытии на веб-сайт сервер предоставит сертификат SSL / TLS браузеру пользователя. Затем браузер пользователя выполняет серию проверок..

Во-первых, он собирается аутентифицировать сертификат, просматривая его цифровую подпись и следуя цепочке сертификатов. Он также проверит, не истек ли срок действия сертификата, и проверит журналы прозрачности сертификатов (CT) и списки отзыва сертификатов (CRL). При условии, что цепочка ведет к одному из корней в хранилище доверенных сертификатов системы и что она действительна, браузер будет доверять сертификату..

Теперь время рукопожатия.

Рукопожатие SSL / TLS – это последовательность шагов, когда клиент (пользователь) и сервер (веб-сайт) согласовывают параметры своего безопасного соединения, генерируют и затем обмениваются симметричными сеансовыми ключами..

Во-первых, они собираются принять решение о наборе шифров. Набор шифров – это группа алгоритмов и шифров, которые будут использоваться для соединения. Сертификат SSL / TLS предоставляет список комплектов шифров, которые поддерживает сервер. Как правило, набор шифров включает в себя алгоритм шифрования с открытым ключом, алгоритм генерации ключа, алгоритм аутентификации сообщения и алгоритм симметричного или массового шифрования, хотя это было усовершенствовано в TLS 1.3..

Получив список поддерживаемых шифров, клиент выберет подходящее и сообщит его серверу. После этого клиент сгенерирует симметричный сеансовый ключ, зашифрует его с помощью открытого ключа и затем отправит его на сервер, который обладает личным ключом, необходимым для расшифровки сеансового ключа..

Как только обе стороны получат копию сеансового ключа, связь может начаться.

И это SSL / TLS.

Вы можете увидеть, как все концепции, которые мы рассмотрели ранее, взаимодействуют друг с другом, создавая сложную и в то же время элегантную систему защиты интернет-соединений. Мы используем криптографию с открытым ключом для безопасного обмена ключами сеанса, с которым мы будем общаться. Сертификатам, которые утверждают идентификацию сервера или организации, можно доверять из-за инфраструктуры, которую мы располагаем между различными ЦС, браузерами и корневыми программами.

И общение происходит в результате симметричного шифрования с закрытым ключом, которое происходит от классических криптосистем древности.

Есть много движущихся частей, но когда вы замедляетесь и понимаете их все по отдельности, гораздо легче увидеть, как все это работает вместе.

Прежде чем идти, давайте закончим с несколькими шагами, связанными с SSL / TLS, которые вы можете сделать после установки / настройки, чтобы получить максимальную отдачу от ваших инвестиций.

После SSL / TLS – получение максимальной отдачи от вашей реализации

Простая установка сертификата и правильная настройка вашего веб-сайта не означает, что ваш веб-сайт безопасен. TLS является лишь одним из компонентов более широкой, комплексной стратегии киберзащиты. Но важный компонент, тем не менее. Давайте рассмотрим несколько вещей, которые вы можете сделать, чтобы обеспечить максимальную отдачу от реализации..

Отключить поддержку сервера для старых протоколов

Возвращаясь к разговору о Cipher Suites, который мы обсуждали ранее, мы можем решить, какие наборы шифров и версии SSL / TLS поддерживать. Необходимо отключить поддержку старых версий SSL / TLS, а также определенных алгоритмов, чтобы предотвратить уязвимость к нескольким известным эксплойтам..

SSL 2.0 и SSL 3.0 старше 20 лет. Лучшая практика состояла в том, чтобы прекратить оказывать им поддержку несколько лет назад, но по сей день около 7% из 100 000 лучших пользователей Alexa по-прежнему позволяют им. Это опасно, потому что оно подвергает вас атакам разборки и понижения SSL, таким как POODLE.

TLS 1.0 и TLS 1.1 тоже заняты.

Крупнейшие технологические компании, Apple, Microsoft, Google и Mozilla, сделали совместное заявление этой осенью, что они откажутся от поддержки TLS 1.0 и 1.1 в начале 2020 года..

Версии протокола подвержены уязвимостям, таким как POODLE, FREAK, BEAST и CRIME (все это аббревиатуры). TLS 1.2 был выпущен в течение десяти лет и должен быть стандартом. TLS 1.3 был доработан прошлым летом, и с момента его внедрения.

Кроме того, существуют определенные алгоритмы, которые также не должны использоваться. Например, DES может быть сломан за считанные часы. RC4 более уязвим, чем считалось ранее, и он уже был запрещен стандартами безопасности данных индустрии платежных карт. И, наконец, учитывая новости о последних подвигах, больше не рекомендуется использовать RSA для обмена ключами..

Предлагаемые алгоритмы / шифры:

  • Обмен ключами: эллиптическая кривая Диффи-Хелмана (ECDH)
  • Аутентификация: алгоритм цифровой подписи эллиптической кривой (ECDSA)
  • Симметричное / массовое шифрование: AES 256 в режиме счетчика Галуа (AES256-GCM)
  • Алгоритм MAC: SHA-2 (SHA384)

Постоянный SSL

В прошлом веб-сайты иногда переносили только те веб-страницы, которые собирают информацию в HTTPS, при этом обслуживая остальную часть сайта через HTTP. Это плохая практика.

В дополнение к тому факту, что Google помечает эти страницы как «Незащищенные», вы также потенциально подвергаете посетителей своего сайта риску, заставляя их браузеры переходить назад и вперед между зашифрованными страницами и HTTP..

Вы должны настроить весь ваш сайт для HTTPS. Это называется Always-on SSL. В конце концов, вы не платите за страницу, ваш сертификат SSL / TLS может зашифровать весь ваш сайт. Так сделай так.

Настройка записи авторизации центра сертификации (CAA)

В целом одним из наиболее значительных рисков, связанных с цифровыми сертификатами, является их неправильная выдача. Если какой-либо стороне, кроме вас, выдан сертификат SSL / TLS для ВАШЕГО веб-сайта, они могут эффективно выдать себя за вас и вызвать всевозможные проблемы..

Записи CAA помогают снизить этот риск за счет ограничения того, какие центры сертификации могут выпускать цифровые сертификаты для вашего веб-сайта. CA / Browser Forum требует от Центров сертификации проверки записей CAA перед выдачей любого сертификата. Если у ЦС нет разрешения на выдачу для этого сайта, он не может. Это будет считаться ошибкой в ​​выпуске и вызовет гнев сообщества браузеров..

Добавить запись CAA относительно просто, это простая запись DNS, которую можно добавить через интерфейс большинства хостинговых платформ. Вы можете ограничить центры сертификации, которые могут выдавать для вашего домена, а также возможность выдачи сертификатов Wildcard для него..

Добавьте ваш сайт в список предварительной загрузки HSTS

HTTP Strict Transport Security, или HSTS, является HTTP-заголовком, который заставляет браузеры только устанавливать HTTPS-соединения с данным сайтом. Таким образом, даже если веб-пользователь попытается перейти на HTTP-версию страницы, он в конечном итоге посетит только HTTPS-версию. Это важно, потому что закрывает окно для нескольких известных эксплойтов, таких как атаки с понижением версии и захват файлов cookie..

К сожалению, крошечный вектор атаки остается с HSTS, поэтому вы должны добавить свой сайт в список предварительной загрузки. Как правило, когда посетитель попадает на ваш веб-сайт, его браузер загружает заголовок HTTP, а затем придерживается его в течение всего срока действия политики. Но в тот самый первый визит, до того, как заголовок был получен, злоумышленнику все еще остается крошечное отверстие.

Список записей предварительной загрузки HSTS находится в ведении Google, а некоторые его разновидности используются всеми основными браузерами. Эти браузеры знают только для подключения через HTTPS к любому веб-сайту, который есть в списке – даже если он никогда не посещал там раньше. Для появления вашего сайта в списке может потребоваться неделя или две из-за того, что обновления в списке выталкиваются вместе с графиками выпуска браузеров..

SSL / TLS FAQ

Что такое сертификат X.509?

X.509 относится к типу цифрового сертификата, который используется с SSL / TLS и другими типами PKI. X.509 – это стандарт шифрования с открытым ключом. Иногда вы увидите, что компании используют сертификат X.509 вместо «цифрового сертификата» или «сертификата PKI».

Почему срок действия сертификатов SSL / TLS истекает?

Есть две причины для этого.

Во-первых, Интернет постоянно меняется, веб-сайты приходят и веб-сайты уходят. И учитывая, насколько чувствительны браузеры к тому, чтобы доверять этим сертификатам, в первую очередь они хотят знать, что веб-сайты, представляющие сертификаты, проходят регулярные проверки. Это не отличается от того, как вам иногда приходится регистрироваться, чтобы обновить информацию о ваших водительских правах.

Другая причина более техническая. Труднее распространять обновления и технические изменения, если срок действия сертификатов не истекает в течение 3-5 лет. Принимая во внимание, что если срок действия сертификатов истекает каждые 24 месяца, самый длинный из них может быть устаревшим – два года. В 2017 году максимальный срок действия был сокращен с трех лет до двух. Вероятно, он будет сокращен до 12 месяцев в ближайшее время.

Как продлить сертификат SSL / TLS??

Продление может быть немного неправильным, потому что вы заменяете старый сертификат новым. Регулярное выполнение этого позволяет вам быть в курсе новых достижений с технологией шифрования и обеспечивает актуальность вашей информации для проверки. Центры сертификации могут повторно использовать только проверочную информацию, которая была первоначально предоставлена ​​так долго, пока базовые требования не заставили их повторно подтвердить ее..

Когда вы продлеваете, вы можете либо сохранить тот же тип сертификата, что у вас был раньше, либо вы можете использовать что-то новое, вы даже можете изменить CA. Главное, сколько времени у вас осталось на сертификате с истекшим сроком действия – вы можете продлить срок до трех месяцев. Если вы продлите действие до истечения срока действия сертификата, вы можете перенести любое оставшееся время и повторно использовать любую информацию для проверки, которая не истекла со времени вашей последней проверки. Если вы позволите ему истечь, вы начинаете с нуля.

Что такое HTTPS инспекция?

Многие крупные компании с большими сетями любят видеть свой трафик. В этом отношении HTTPS – обоюдоострый меч. Он защищает конфиденциальность людей, но также может помочь скрыться и киберпреступникам. Многие организации дешифруют свой HTTPS-трафик на периферийном устройстве или промежуточном устройстве, а затем либо отправляют его в виде открытого текста за брандмауэром, либо повторно шифруют его и отправляют в пути. Когда вы не перешифруете трафик, это называется SSL-терминация. Когда вы делаете повторное шифрование, это называется мостом SSL.

Что такое разгрузка SSL?

Разгрузка SSL – еще одна корпоративная практика. В масштабе, выполнение тысяч рукопожатий, а затем шифрование и дешифрование всех этих данных может облагать ресурсы сети. Таким образом, многие крупные сети будут выгружать функции SSL на другое устройство, чтобы сервер приложений мог сосредоточиться на своих основных задачах. Это иногда называют балансировкой нагрузки.

Почему мой ЦС прислал мне промежуточный сертификат?

Помните ранее, когда мы обсуждали корневые программы?

У самой ОС есть корневое хранилище, которое она использует для оценки доверия к PKI. Но центры сертификации не выпускают сертификаты конечных пользователей от этих корней из-за боязни того, что произойдет, если их когда-нибудь отозвать. Вместо этого они раскручивают промежуточные корни и выпускают их. Проблема в том, что эти промежуточные корни не находятся в хранилище доверия системы.

Таким образом, если веб-сайт не предоставляет промежуточный сертификат вместе с листовым сертификатом SSL / TLS, многие браузеры не смогут завершить цепочку сертификатов и выдают предупреждение. Некоторые браузеры кэшируют промежуточные сертификаты, но все же рекомендуется устанавливать промежуточные сертификаты вместе с вашим листовым сертификатом..

Какая документация мне нужна для SSL-сертификата расширенной проверки?

В большинстве случаев центр сертификации, выполняющий расширенную проверку, сначала попытается получить доступ к информации через общедоступные ресурсы «государственных органов».

Однако в некоторых местах это может быть невозможно. Есть несколько вещей, которые могут помочь в ускорении валидации. Хотя количество проверочных проверок, которые может удовлетворить Письмо профессионального мнения, в последнее время сократилось, при наличии адвоката или бухгалтера, имеющего хорошую репутацию, можно все же значительно помочь.

Кроме того, вы можете предоставить правительственные документы, удостоверяющие личность, или документ, подтверждающий права, который дает вашей организации право вести бизнес под указанным именем. Некоторые примеры этих документов:

  • Устав корпорации
  • Свидетельства об образовании
  • Бизнес / Продавец / Торговые лицензии
  • Уставные документы
  • Партнерские соглашения
  • Регистрация торгового или предполагаемого имени
  • Registro Mercantil

В заключение

Я надеюсь, что это дает вам представление о SSL / TLS. Если вы заинтересованы в получении дополнительной информации, то я бы порекомендовал пройти этот онлайн-курс.

Этот пост предоставлен Патриком Ноэ, редактором Хешируется магазином SSL, блог, освещающий новости и тенденции в области кибербезопасности.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map