Ssl tls что это

SSL/TLS

SSL (Secure Sockets Layer) и TLS (Transport Level Security) — криптографические протоколы, обеспечивающие защищенную передачу данных в компьютерной сети. Они широко используются в веб-браузерах, а также при работе с электронной почтой, обмене мгновенными сообщениями и в IP-телефонии.

Соединение, защищенное протоколом TLS, обладает одним или несколькими следующими свойствами:

• Безопасность: симметричное шифрование защищает передаваемую информацию от прочтения посторонними лицами.
• Аутентификация: «личность» участника соединения можно проверить с помощью асимметричного шифрования.
• Целостность: каждое сообщение содержит код (Message Authentication Code, MAC), с помощью которого можно проверить, что данные не были изменены или потеряны в процессе передачи.

Так как большинство протоколов связи могут быть использованы как с TLS/SSL, так и без него, при установке соединения необходимо явно указать серверу, хочет ли клиент устанавливать TLS. Один способ добиться этого — использовать порт, по которому соединение всегда устанавливается с использованием TLS (например, 443 для HTTPS). Другой способ — использовать специальную команду серверу от клиента переключить соединение на TLS (например, STARTTLS для протоколов электронной почты).

История SSL

SSL изначально разработан компанией Netscape для добавления протокола — HTTPS в свой веб-браузер Netscape Navigator, потому что компания считала, что безопасное соединение между клиентом и сервером в первую очередь послужит успехом развитию Интернета как инструмента бизнеса.

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

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

Устройство протокола SSL

Протокол SSL размещается между двумя протоколами: протоколом, который использует программа-клиент (HTTP, FTP, LDAP, TELNET и т.д.) и транспортным протоколом TCP/IP. SSL защищает данные, выступая в роли фильтра для обеих сторон и передает их далее на транспортный уровень.

Работу протокола можно разделить на два уровня:

• Слой протокола подтверждения подключения (Handshake Protocol Layer)
• Слой протокола записи

Первый слой, в свою очередь, состоит из трех подпротоколов:

• Протокол подтверждения подключения (Handshake Protocol)
• Протокол изменения параметров шифра (Cipher Spec Protocol)
• Предупредительный протокол (Alert Protocol)

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

Протокол изменения параметров шифра используется для изменения данных ключа (keying material) — информации, которая используется для создания ключей шифрования. Протокол состоит всего из одного сообщения, в котором сервер говорит, что отправитель хочет изменить набор ключей.

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

Протокол записи

Протокол записи (Record Layer) — это уровневый протокол. На каждом уровне сообщения включают поля для длины, описания и проверки. Протокол записи принимает сообщения, которые нужно передать, фрагментирует данные в управляемые блоки, разумно сжимает данные, применяя MAC (message authentication code), шифрует и передаёт результат. Полученные данные он расшифровывает, проверяет, распаковывает, собирает и доставляет к более верхним уровням клиента.

Существует четыре протокола записи:

• Протокол рукопожатия (handshake protocol);
• Протокол тревоги (alert protocol);
• Протокол изменения шифра (the change cipher spec protocol);
• Протокол приложения (application data protocol);

Принцип работы SSL

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

Клиент инициирует рукопожатие посылая “hello”-сообщение серверу. Такое сообщение содержит список алгоритмов симметричного шифрования (cipher specs), поддерживаемых клиентом. Сервер отвечает похожим “hello”-сообщением, выбрав при этом наиболее подходящий алгоритм шифрования из полученного списка. Далее сервер отправляет сертификат, который содержит его публичный ключ.

Сертификат — это набор данных, который подтверждает подлинность. Подтвержденная третья сторона, известная как центр сертификации (CA), генерирует сертификат и проверяет его подлинность. Чтобы получить сертификат сервер должен использовать безопасные каналы для отправки своего публичного ключа в центр сертификации. Он генерирует сертификат, который содержит его собственный ID, ID сервера, публичный ключ сервера и другую информацию. А также центр сертификации создает отпечаток (digest) сертификата, который, по сути, является контрольной суммой. Далее центр сертификации создает подпись сертификата (certificate signature), которая формируется путем шифрования отпечатка сертификата приватным ключом центра сертификации.

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

Фаза рукопожатия завершается отправкой “finished”-сообщений, как только обе стороны готовы начать использование секретного ключа. Начинается фаза передачи данных, в ходе которой каждая сторона разбивает исходящие сообщения на фрагменты и прикрепляет к ним коды авторизации сообщений MAC (message authentication code). Код авторизации сообщения это зашифрованный отпечаток, вычисленный на основе содержимого сообщений. Из соображений безопасности, он не совпадает с секретным ключом и вычисляется вместе с секретным ключом на стадии рукопожатия. Для получения полноценного SSL пакета каждая из сторон объединяет данные фрагмента, код авторизации сообщения, заголовки сообщения и шифруют с использованием секретного. При получении пакета, каждая из сторон расшифровывает его и сверяет полученный код авторизации сообщения со своим. Если они не совпадают, то пакет был подделан.

Цифровые сертификаты

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

Способы получения SSL-сертификата:

• Использовать сертификат, выданный центром сертификации (Certification authority)
• Использовать самоподписанный сертификат
• Использовать «пустой» сертификат

Самоподписанный сертификат — сертификат, созданный самим пользователем — в этом случае издатель сертификата совпадает с владельцем сертификата. «Пустой» сертификат — сертификат, содержащий фиктивную информацию, используемую в качестве временной для настройки SSL и проверки его функциональности в данной среде.

Хэширование

Хеш-значение является идентификатором сообщения, его размер меньше размера оригинального сообщения. Самыми известными хеш-алгоритмами являются MD5 (Message Digest 5), который создает 128-битное хеш-значение, SHA-1 (Standard Hash Algorithm), создающий 160-битное хеш-значение, SHA-2 и SHA-3. Результат работы алгоритма хеширования — значение, которое используется для проверки целостности передачи данных.

Шифрование

Существует два основных способа шифрования данных: симметричный ключ (общий секретный ключ) и асимметричный ключ (открытый ключ).

Открытый ключ

Суть асимметричного шифрования заключается в том, что используется пара ключей. Один из них используется в качестве открытого (как правило, он публикуется в самом сертификате владельца), второй ключ называется секретным — он держится в тайне и никогда никому не открывается. Оба ключа работают в паре: один используется для запуска противоположных функций другого ключа. Если открытый ключ используется для того, чтобы зашифровать данные, то расшифровать их можно только секретным ключом и наоборот. Такая взаимосвязь позволяет делать две важные вещи.

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

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

RSA — самый распространенный алгоритм шифрования с использованием асимметричных ключей.

Секретный ключ

При шифровании секретным ключом используется один и тот же ключ для шифрованных данных. Если стороны хотят обменяться зашифрованными сообщениями в безопасном режиме, то у обеих сторон должны быть одинаковые симметричные ключи. Такой тип шифрования используется для большого объёма данных. Обычно используются алгоритмы DES, 3-DES, RC2, RC4 и AES.

Комбинированный подход

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

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

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

Аутентификация и обмен ключами

SSL поддерживает 3 типа аутентификации:

• аутентификация обеих сторон (клиент — сервер),
• аутентификация сервера с неаутентифицированным клиентом,
• полная анонимность.

Обычно для аутентификации используются алгоритмы: RSA, DSA, ECDSA.

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

Главная цель процесса обмена ключами — это создание секрета клиента (pre_master_secret), известного только клиенту и серверу. Секрет (pre_master_secret) используется для создания общего секрета (master_secret). Общий секрет необходим для того, чтобы создать сообщение для проверки сертификата, ключей шифрования, секрета MAC (message authentication code) и сообщения «finished». Отсылая сообщение «finished», стороны указывают, что они знают верный секрет (pre_master_secret).

Анонимный обмен ключами

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

Аутентификация и обмен ключами при использовании RSA

В этом случае обмен ключами и аутентификация сервера может быть скомбинирована. Открытый ключ также может содержаться в сертификате сервера или может быть использован временный ключ RSA, который посылается в сообщении обмена ключами от сервера. Когда используется временный ключ RSA, сообщения обмена подписываются server’s RSA или сертификат DSS. Сигнатура содержит текущее значение сообщения Client_Hello.random, таким образом, старые сигнатуры и старые временные ключи не могут повторяться. Сервер может использовать временный ключ RSA только однажды для создания сессии. После проверки сертификата сервера клиент шифрует секрет (pre_master_secret) при помощи открытого ключа сервера. После успешного декодирования секрета (pre_master_secret) создается сообщение «finished», тем самым сервер демонстрирует, что он знает частный ключ, соответствующий сертификату сервера.

Когда RSA используется для обмена ключами, для аутентификации клиента используется сообщение проверки сертификата клиента. Клиент подписывается значением, вычисленным из master_secret и всех предшествующих сообщений протокола рукопожатия. Эти сообщения рукопожатия содержат сертификат сервера, который ставит в соответствие сигнатуре сервера сообщение Server_Hello.random, которому ставит в соответствие сигнатуру текущему сообщению рукопожатия.

Аутентификация и обмен ключами при использовании протокола Диффи-Хеллмана

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

Если клиент имеет сертификат, содержащий параметры алгоритма Diffie-Hellman, то сертификат также содержит информацию, требующуюся для того, чтобы завершить обмен ключами. В этом случае клиент и сервер должны будут сгенерировать одинаковые Diffie-Hellman результаты (pre_master_secret) каждый раз, когда они устанавливают соединение. Для того, чтобы предотвратить хранение секрета (pre_master_secret) в памяти компьютера на время дольше, чем необходимо, секрет должен быть переведен в общий секрет (master_secret) настолько быстро, насколько это возможно. Параметры клиента должны быть совместимы с теми, которые поддерживает сервер для того, чтобы работал обмен ключами.

Восстановление сессии

Создатели SSL знали, что алгоритмы шифрования открытым ключом вычислительно сложные, и клиент, создающий несколько новых соединений к одному и тому же серверу в течение короткого промежутка времени может сильно нагрузить сервер, что приведет к заметным временным задержкам ответа. Однако, если клиент и сервер уже установили соединение, то ему будет соответствовать уникальный идентификатор сессии, позволяющий ссылаться на него и использовать такой же секретный ключ при последующих соединениях в рамках некоторого временного отрезка. Безусловно, такой подход привносит определенный риск в безопасность соединения. Поэтому, если необходимо, клиент может пересоздать новые идентификатор и секретный ключ для данной сессии. Microsoft’s Internet Explorer, например, проделывают эту операцию каждые 2 минуты.

Администрирование

Обслуживание сертификатов и ключей

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

Хранилище идентификаторов сессий

Клиент и сервер обязаны хранить идентификаторы сессий и связанные с ними секретные ключи для использования во время восстановления соединения.

SSL 1.0, 2.0, 3.0 и TLS

Версия 1.0 никогда не была обнародована. Версии 2.0 была выпущена в феврале 1995 года, но содержала много недостатков по безопасности, которые привели к разработке SSL 3.0 версии.

Как только различные компании (Microsoft) начали предпринимать попытки разработки собственных безопасных протоколов транспортировки, IETF решило вмешаться и определить стандарт протокола шифрования. Впоследствии, при поддержке множества компаний, на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS 1.0. Его также часто называют SSL 3.1.

Хотя TLS и SSL имеют существенные различия в реализации, разработчики обычно замечают лишь немногие из них, а конечные пользователи вовсе их не различают. Тем не менее TLS 1.0 и SSL 3.0 несовместимы. Значительное различие состоит в том, что TLS требует определенные алгоритмы шифрования, которые SSL не поддерживает. Таким образом TLS сервер должен “откатиться” (downgrade) до SSL 3.0 для работы с клиентами, использующими SSL 3.0.

Принцип работы TLS

Протокол TLS делится на два слоя: TLS Record и TLS Handshake.

Подтверждение связи (handshake)

1. Клиент посылает сообщение ClientHello, указывающее версию SSL или TLS и поддерживаемые клиентом методы шифрования (англ. CipherSuite). Это сообщение также содержит случайное число (набор байт), которое используется в последующих вычислениях. Протокол также позволяет указать поддерживаемые клиентом методы сжатия данных.
2. Сервер отвечает сообщением ServerHello, которое содержит метод шифрования, выбранный сервером из списка, предложенного клиентом, а также идентификатор сессии и еще одно случайное число. Также сервер посылает свой цифровой сертификат. Если серверу нужен сертификат для аутентификации клиента, на этом шаге он может послать клиенту запрос такого сертификата.
3. Клиент проверяет сертификат сервера.
4. Клиент отправляет случайное число, которое клиент и сервер используют для шифрования последующих сообщений. Сама строка из байт шифруется публичным ключом сервера.
5. Если сервер потребовал у клиента сертификат, клиент отсылает набор байт, зашифрованный его секретным ключом, и свой цифровой сертификат, или оповещение об отсутствии сертификата.
6. Сервер проверяет сертификат клиента.
7. Клиент и сервер отправляют друг другу сообщение ChangeCipherSpec, объявляя об изменении режима передачи данных с незащищенного на защищенный.
8. Клиент отправляет сообщение Finished, зашифрованное секретным ключом, и таким образом завершает подтверждение связи со своей стороны.
9. Аналогичные действия производит сервер.
10. На протяжении данной сессии клиент и сервер могут обмениваться сообщениями, зашифрованными секретным ключом.

Возобновление сессии

1. Клиент посылает сообщение ClientHello, используя ID сессии, которую нужно возобновить.
2. Сервер проверяет, есть ли у него в кэше соответствующий идентификатор. Если есть и сервер способен возобновить сессию, он отсылает клиенту сообщение ServerHello с этим же ID сессии. Если нет, сервер генерирует новый ID сессии и выполняет процедуру handshake с клиентом.
3. Клиент и сервер обмениваются сообщениями ChangeCipherSpec, а затем Finished.
4. Передача данных по защищенному каналу возобновляется.

Протокол записи (TLS Record)

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

• Разбиение исходящих сообщений на блоки нужного размера и «склеивание» входящих сообщений.
• Сжатие исходящих сообщений и распаковку входящих (используется не всегда).
• Применение кода аутентификации к исходящим сообщениям и проверку входящих с помощью MAC.
• Шифрование исходящих сообщений и дешифровку входящих.

После обработки протоколом TLS Record зашифрованные данные передаются на слой TCP для передачи.

Состав записи

• Content type: тип сообщения — подтверждение связи (22), обычное сообщение (23) или оповещение (21).
• Version: версия SSL/TLS.
• Length: длина оставшейся части сообщения.
• Payload: собственно зашифрованные данные.
• MAC: код аутентификации.
• Padding: «отступ» для получения нужного размера сообщения.

Цифровые сертификаты (стандарт X.509)

• Удобный способ показать, что кто-то владеет публичным ключом.
• Выпускаются центрами сертификации (Certificate Authority, CA): GlobalSign, Comodo и др.
• PKI (public key infrastructure) — механизм, регулирующий распространение и использование сертификатов (включая создание, отзыв и проверку подлинности).
• Список доверенных CA поддерживается приложением (у браузеров свои списки).
• Сертификаты подписываются другими сертификатами, что повышает надежность.
• Сертификат может быть отозван. Система поддерживает список таких сертификатов (Certificate Revocation List, CRL). На стороне CA список обновляется каждые несколько часов.

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

1. Пользователь генерирует ключ и посылает запрос серверу CA.
2. CA отвечает сообщением со своим сертификатом.
3. Пользователь собирает данные, необходимые для выдачи сертификата (email, отпечаток ключа и т.д.).
4. Пользователь отправляет данные в CA, зашифровав их публичным ключом CA.
5. CA проверяет полученные данные и отправляет сертификат пользователю.

Структура сертификата

• Собственно сертификат
  • Версия
  • Серийный номер
  • Эмитент (тот, кто выпустил сертификат)
  • Субъект
  • Публичный ключ субъекта
  • Период действия
  • Дополнительные поля

  Меры безопасности в TLS

  • Защита от downgrade-атаки — понижения версии протокола к предыдущей (менее защищённой) версии или менее надёжному алгоритму шифрования;
  • Нумерация последовательных записей приложения и использование порядкового номера в коде аутентификации сообщения (MAC);
  • Использование ключа в идентификаторе сообщения (только владелец ключа может сгенерировать код аутентификации сообщения).
  • Сообщение, которым заканчивается подтверждение связи («Finished»), содержит хэш всех handshake-сообщений, отправленных обеими сторонами, что позволяет проверить подлинность выбранных параметров TLS-соединения.
  • Псевдослучайная функция делит подаваемые ей на вход данные пополам, применяет к половинкам разные хэш-алгоритмы (MD5 и SHA-1), а затем XOR’ит результаты для получения MAC. Это повышает безопасность в случае, если в одном из алгоритмов обнаружится уязвимость.

  Ключевые отличия SSL и TLS

  • Аутентификация сообщений: в TLS используется HMAC, работающий с любой хэш-функцией (а не только с MD5 или SHA, как в SSL).
  • Генерация ключа: в TLS при создании ключа используется псевдослучайная функция стандарта HMAC; в SSL — RSA, Diffie-Hellman или Fortezza/DMS.
  • Проверка сертификата: в SSL проверка требует передачи сложной последовательности сообщений; в TLS информация о проверке полностью передается в сообщениях во время handshake.
  • Методы шифрования: SSL поддерживает только алгоритмы RSA, Diffie-Hellman и Fortezza/DMS. В TLS отказались от поддержки Fortezza/DMS, но возможно добавление новых методов шифрования в последующих версиях.

  Виды возможных атак

  • Атака по словарю
  • Атака отражением
  • Атака протокола рукопожатия
  • Взлом SSL-соединений внутри ЦОД
  • BEAST атака
  • Раскрытие шифров
  • Атака «злоумышленник посередине»
  • THC-SSL-DOS
  • SSLstrip

  Источники информации

  • SSL and TLS: A Beginner’s Guide
  • Wikipedia: Secure Sockets Layer
  • Inside SSL: The Secure Sockets Layer Protocol
  • Tanenbaum-Structured-Computer-Organization-6th-Edition
  • SSL/TLS Strong Encryption: An Introduction
  • Wikipedia: Transport Layer Security
  • Microsoft Developer Resources: Transport Layer Security Protocol
  • IBM Knowledge Center: Cryptographic security protocols: SSL and TLS
  • Thomas, Stephen. SSL and TLS Essentials: Securing the Web.

  Полезные материалы

  • Криптографический пакет с открытым исходным кодом для работы с SSL/TLS. Позволяет создавать ключи RSA, DH, DSA и сертификаты X.509, подписывать их, формировать CSR и CRT
  • How To Create an SSL Certificate on Nginx for Ubuntu 14.04
  • Usage Statistics and Market Share of SSL Certificate Authorities

  Что такое сертификат SSL/TLS?

  

  Сертификат SSL/TLS — это цифровой объект, который позволяет системам проверять личность и впоследствии устанавливать зашифрованное сетевое соединение с другой системой с использованием протокола Secure Sockets Layer/Transport Layer Security (SSL/TLS). Сертификаты используются в рамках криптографической системы, известной как инфраструктура открытого ключа (PKI). PKI дает одной стороне возможность устанавливать подлинность другой стороны с помощью сертификатов (при условии, что обе стороны доверяют третьей стороне, известной как центр сертификации). Таким образом, сертификаты SSL/TLS действуют как цифровые удостоверения личности для защиты сетевых подключений и установления подлинности веб-сайтов в Интернете, а также ресурсов в частных сетях.

  Почему сертификаты SSL/TLS важны?

  Сертификаты SSL/TLS укрепляют доверие среди пользователей веб-сайта. Компании устанавливают сертификаты SSL/TLS на веб-серверы для создания веб-сайтов, защищенных SSL/TLS. Характеристики веб-страницы, защищенной SSL/TLS, следующие:

  • Значок замка и зеленая адресная строка в веб-браузере
  • Префикс https в адресе веб-сайта в браузере
  • Действующий сертификат SSL/TLS Вы можете проверить, действителен ли сертификат SSL/TLS, щелкнув и развернув значок замка в адресной строке URL-адреса.
  • После установления зашифрованного соединения только клиент и веб-сервер могут видеть отправленные данные.

  Ниже мы приводим некоторые преимущества сертификатов SSL/TLS.

  Защищает личные данные

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

  Укрепляйте доверие клиентов

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

  Соответствие нормативным требованиям

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

  Улучшить SEO

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

  Каковы ключевые принципы технологии сертификации SSL/TLS?

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

  Шифрование

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

  Существуют два типа ключей:

  Открытый ключ

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

  Закрытый ключ

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

  Аутентификация

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

  Цифровая подпись

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

  Кто проверяет сертификаты SSL/TLS?

  Центр сертификации (ЦС) – это организация, которая продает сертификаты SSL/TLS владельцам веб-сайтов, хостинговым компаниям или предприятиям. Центр сертификации проверяет сведения о домене и владельце перед выпуском сертификата SSL/TLS. Чтобы стать центром сертификации, организация должна соответствовать определенным требованиям, установленным компанией, выпускающей операционную систему, браузеры или мобильные устройства, и подать заявку на включение в список корневого центра сертификации. Это важно для завоевания доверия среди пользователей Интернета. Например, Amazon Trust Services является центром сертификации и может выдавать веб-сайтам сертификаты SSL/TLS.

  Каков срок действия сертификата SSL/TLS?

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

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

  Что входит в сертификат SSL/TLS?

  Сертификат SSL/TLS содержит следующую информацию.

  • Доменные имена
  • Центр сертификации
  • Цифровая подпись центра сертификации
  • Дата выпуска
  • Дата истечения срока действия
  • Открытый ключ
  • Версия SSL/TLS

  TLS означает безопасность транспортного уровня. Это преемник и продолжение протокола SSL/TLS версии 3.0. Существуют лишь незначительные технические различия между SSL/TLS и TLS. Как и SSL/TLS, TLS обеспечивает зашифрованный канал передачи данных между браузером и веб-сервером. Современные сертификаты SSL/TLS используют протокол TLS вместо SSL/TLS, но SSL/TLS остается популярной аббревиатурой среди экспертов по безопасности. Хотя термины SSL и TLS не совсем одинаковы, они обычно используются для обозначения одного и того же. Они также могут называть протокол криптографического шифрования SSL/TLS.

  Как работает сертификат SSL/TLS?

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

  Рукопожатие SSL/TLS

  Рукопожатие SSL/TLS включает в себя следующие шаги:

  1. Браузер открывает защищенный SSL/TLS веб-сайт и подключается к веб-серверу.
  2. Браузер пытается проверить подлинность веб-сервера, запрашивая идентифицирующую информацию.
  3. В ответ веб-сервер отправляет сертификат SSL/TLS, содержащий открытый ключ.
  4. Браузер проверяет сертификат SSL/TLS, проверяя, что он действителен и соответствует домену веб-сайта. Как только браузер удовлетворен сертификатом SSL/TLS, он использует открытый ключ для шифрования и отправки сообщения, содержащего секретный ключ сеанса.
  5. Веб-сервер использует свой закрытый ключ для расшифровки сообщения и получения ключа сеанса. Затем сеансовый ключ используется для шифрования и отправки подтверждающего сообщения в браузер.
  6. Теперь и браузер, и веб-сервер переходят на использование одного и того же сеансового ключа для безопасного обмена сообщениями.

  Ключ сеанса

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

  

  Что такое Менеджер сертификатов AWS?

  Менеджер сертификатов AWS (ACM) – это сервис, позволяющий легко предоставлять и развертывать публичные и частные сертификаты SSL/TLS для использования вместе с сервисами AWS или внутренними подключенными ресурсами, а также помогающий управлять этими сертификатами. Этот сервис избавляет от необходимости тратить время на покупку, загрузку и обновление сертификатов SSL/TLS вручную. Вместо этого можно быстро запросить сертификат и выполнить его развертывание с помощью таких интегрированных с ACM ресурсов AWS, как эластичная балансировка нагрузки, Amazon CloudFront или в API шлюза Amazon. После этого можно поручить Менеджеру сертификатов AWS обновление сертификатов. Этот сервис позволяет также создавать частные сертификаты для внутренних ресурсов и централизованно управлять жизненным циклом сертификатов.

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

  Начните работу с Менеджером сертификатов AWS, зарегистрировав аккаунт AWS уже сегодня.

  Какие существуют типы сертификатов SSL/TLS?

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

  • Сертификаты расширенной проверки
  • Сертификаты, подтвержденные организацией
  • Сертификаты, подтвержденные доменом

  Сертификаты SSL/TLS, поддерживающие различные типы доменов:

  • Сертификат на один домен
  • Подстановочный сертификат
  • Мультидоменный сертификат

  Сертификаты расширенной проверки

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

  Компании используют EV SSL/TLS для защиты пользователей от неавторизованных третьих лиц. Это важно, когда компания обрабатывает конфиденциальные данные на веб-сайте, такие как финансовые транзакции и медицинские записи. Сертификат EV SSL/TLS содержит сведения об организации бизнеса, которые можно просмотреть в браузере.

  Сертификаты проверки организации

  Сертификаты проверки организации (OV SSL/TLS) занимают второе место после EV SSL/TLS с точки зрения уровня проверки и доверия. Как и EV SSL/TLS, компании должны пройти процесс проверки при подаче заявки на получение SSL/TLS OV. Хотя процесс проверки менее строгий, заявители должны доказать сертификационным органам право собственности на домен.

  Сертификат OV SSL/TLS содержит проверенную деловую информацию и может быть проверен в браузере. Фронтальные и коммерческие компании используют сертификат OV SSL/TLS для укрепления доверия среди клиентов. OV SSL/TLS обеспечивает надежное шифрование для защиты конфиденциальности клиентов при просмотре веб-страниц.

  Сертификаты проверки домена

  Сертификаты проверки домена (DV SSL/TLS) – это цифровые сертификаты с самым низким уровнем проверки. Подача заявки на них также обходится дешевле всего. В отличие от SLL EV и OV SSL/TLS, кандидаты на получение сертификата DV проходят менее строгий процесс проверки. Заявитель подтверждает право собственности на домен, ответив на электронное письмо с подтверждением или телефонный звонок.

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

  SSL/TLS сертификаты для одного домена

  Сертификат SSL/TLS для одного домена – это сертификат SSL/TLS, который защищает только один домен или субдомен. Домен – это основной URL-адрес или адрес веб-сайта, такого как amazon.com. Субдомен – это веб-адрес с текстовым расширением, который предшествует основному домену, например aws.amazon.com.

  «Как это работает»: знакомство с SSL/TLS

  Мы достаточно часто рассказываем о разных технологиях: от систем хранения до резервного копирования. Помимо этого мы делимся собственным опытом оптимизации работы нашего IaaS-провайдера — говорим об управленческих аспектах и возможностях для улучшения usability сервиса.

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

  

  / Flickr / David Goehring / CC-BY

  SSL (secure sockets layer — уровень защищённых cокетов) представляет собой криптографический протокол для безопасной связи. С версии 3.0 SSL заменили на TLS (transport layer security — безопасность транспортного уровня), но название предыдущей версии прижилось, поэтому сегодня под SSL чаще всего подразумевают TLS.

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

  Рукопожатие

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

  Кроме того, проверяется дата действия сертификата и наличие корневого сертификата, выданного надежным центром сертификации. Если браузер доверяет сертификату, то он генерирует предварительный секрет (pre-master secret) сессии на основе открытого ключа, используя максимально высокий уровень шифрования, который поддерживают обе стороны.

  

  Сервер расшифровывает предварительный секрет с помощью своего закрытого ключа, соглашается продолжить коммуникацию и создать общий секрет (master secret), используя определенный вид шифрования. Теперь обе стороны используют симметричный ключ, который действителен только для данной сессии. После ее завершения ключ уничтожается, а при следующем посещении сайта процесс рукопожатия запускается сначала.

  Алгоритмы шифрования

  Для симметричного шифрования использовались разные алгоритмы. Первым был блочный шифр DES, разработанный компанией IBM. В США его утвердили в качестве стандарта в 70-х годах. В основе алгоритма лежит сеть Фейстеля с 16-ю циклами. Длина ключа составляет 56 бит, а блока данных — 64.

  Развитием DES является алгоритм 3DES. Он создавался с целью совершенствования короткого ключа в алгоритме-прародителе. Размер ключа и количество циклов шифрования увеличилось в три раза, что снизило скорость работы, но повысило надежность.

  Еще был блочный шифр RC2 с переменной длиной ключа, который работал быстрее DES, а его 128-битный ключ был сопоставим с 3DES по надежности. Потоковый шифр RC4 был намного быстрее блочных и строился на основе генератора псевдослучайных битов. Но сегодня все эти алгоритмы считаются небезопасными или устаревшими.

  Самым современным признан стандарт AES, который официально заменил DES в 2002 году. Он основан на блочном алгоритме Rijndael и скорость его работы в 6 раз выше по сравнению с 3DES. Размер блока здесь равен 128 битам, а размер ключа — 128/192/256 битам, а количество раундов шифрования зависит от размера ключа и может составлять 10/12/14 соответственно.

  Что касается асимметричного шифрования, то оно чаще всего строится на базе таких алгоритмов, как RSA, DSA или ECC. RSA (назван в честь авторов Rivest, Shamir и Adleman) используется и для шифрования, и для цифровой подписи. Алгоритм основан на сложности факторизации больших чисел и поддерживает все типы SSL-сертификатов.

  DSA (Digital Signature Algorithm) используется только для создания цифровой подписи и основан на вычислительной сложности взятия логарифмов в конечных полях. По безопасности и производительности полностью сопоставим с RSA.

  ECC (Elliptic Curve Cryptography) определяет пару ключей с помощью точек на кривой и используется только для цифровой подписи. Основным преимуществом алгоритма является более высокий уровень надежности при меньшей длине ключа (256-битный ECC-ключ сопоставим по надежности с 3072-битным RSA-ключом.

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

  Хеш и MAC

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

  Хеш-алгоритм также использует величину, необходимую для проверки целостности передаваемых данных — MAC (message authentication code). MAC использует функцию отображения, чтобы представлять данные сообщения как фиксированное значение длины, а затем хеширует сообщение.

  В протоколе TLS применяется HMAC (hashed message authentication code), который использует хеш-алгоритм сразу с общим секретным ключом. Здесь ключ прикрепляется к данным, и для подтверждения их подлинности обе стороны должны использовать одинаковые секретные ключи, что обеспечивает большую безопасность.

  Все алгоритмы шифрования сегодня поддерживают алгоритм хеширования SHA2, чаще всего именно SHA-256. SHA-512 имеет похожую структуру, но в нем длина слова равна 64 бита (вместо 32), количество раундов в цикле равно 80 (вместо 64), а сообщение разбивается на блоки по 1024 бита (вместо 512 бит). Раньше для тех же целей применялся алгоритм SHA1 и MD5, но сегодня они считаются уязвимыми.

  Разговоры об отказе от SHA1 велись достаточно давно, но в конце февраля алгоритм был официально взломан. Исследователям удалось добиться коллизии хешей, то есть одинакового хеша для двух разных файлов, что доказало небезопасность использования алгоритма для цифровых подписей. Первая попытка была сделана еще в 2015, хотя тогда удалось подобрать только те сообщения, хеш которых совпадал. Сегодня же речь идет о целых документах.

  Сертификаты бывают разные

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

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

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

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

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

  Кроме того, сертификаты могут различаться в зависимости от количества доменов, на которые они были выданы. Однодоменные сертификаты (Single Certificate) привязываются к одному домену, который указывается при покупке. Мультидоменные сертификаты (типа Subject Alternative Name, Unified Communications Certificate, Multi Domain Certificate) будут действовать уже для большего числа доменных имен и серверов, которые также определяются при заказе. Однако за включение дополнительных доменов, свыше определенной нормы, потребуется платить отдельно.

  Еще существуют поддоменные сертификаты (типа WildCard), которые охватывают все поддомены указанного при регистрации доменного имени. Иногда могут потребоваться сертификаты, которые будут одновременно включать не только несколько доменов, но и поддомены. В таких случаях можно приобрести сертификаты типа Comodo PositiveSSL Multi-Domain Wildcard и Comodo Multi-Domain Wildcard SSL или (лайфхак) обычный мультидоменный сертификат, где в списке доменов указать также и нужные поддоменные имена.

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

  P.S. Дополнительно по теме из блога IaaS-провайдера 1cloud:

  • Кириллические домены и SSL-сертификаты
  • Цепочки SSL-сертификатов
  • Зачем покупать SSL-сертификат
  • Как узнать, из чего состоит SSL-сертификат
  • SSL SSL-ю рознь: какой сертификат выбрать

  SSL/TLS-сертификат: что это, как он работает и как узнать, что у сайта он есть?

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

  Что такое SSL/TLS-сертификат?

  SSL расшифровывается как Secure Sockets Layer, TLS – Transport Layer Security. Сертификат представляет собой технологию безопасности, с помощью которой шифруется связь между браузером и сервером. Из-за такого сертификата хакерам намного сложнее украсть или подменить данные пользователей. SSL/TLS-сертификат устанавливают на сервер. Помимо шифрования всех коммуникаций, с его помощью можно проверить подлинность веб-сайта.

  Может возникнуть вопрос: а в чем разница между сертификатами SSL и TLS? Ответ: ее нет. TLS 1.0 создавали как обновленную версию SSL 3.0 вместо SSL 4.0. Это также было сделано, чтобы подчеркнуть, что создание SSL/TLS больше не связано с компанией Netscape. Именно она выпустила первый SSL. А людям просто удобнее использовать название «SSL-сертификат», поэтому оно прижилось.

  Как это работает?

  Для того чтобы установить https-соединение между браузером и веб-сервером, используется «SSL-рукопожатие». Сначала сервер и клиент согласуют шифронабор (набор алгоритмов, которые определяют параметры безопасного соединения). Потом сервер отправляет клиенту SSL-сертификат. Клиент же проверяет его на подлинность. Если все в порядке, создается «сеансовый ключ».

  И вот мы подошли к SSL-криптографии. Для установки SSL-соединения нужен один симметричный (сеансовый) ключ и два ассиметричных.

  • Симметричный ключ и шифрует, и расшифровывает сообщение. Он бывает 128- и 256-битным. Чем он длиннее, тем сложнее его взломать. Длина ключа зависит от возможностей ПО сервера и клиента.
  • Когда происходит ассиметричное шифрование, генерируются два ключа – публичный и приватный. Публичный ключ шифрует данные, а приватный расшифровывает их. Приватный ключ хранится только на сервере. Ассиметричные ключи бывают 1024- и 2048-битными.

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

  Весь процесс обычно занимает несколько сотен миллисекунд.

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

  Все SSL-сертификаты одинаковые?

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

  SSL-сертификаты также бывают разными в зависимости от уровня валидации:

  • Domain Validation (DM) используется для подтверждения доменного имени. Он чаще всего устанавливается на информационные сайты и блоги и имеет самый низкий уровень доверия;
  • Organization Validation (OV) подтверждает некоторые данные о владельце домена (компанию, физический адрес и доменное имя). Имеет средний уровень доверия;
  • Extended Validation (EV) – этот сертификат необходим для компаний, у которой есть конфиденциальные данные. Он обладает самым высоким уровнем безопасности. При выдаче такого сертификата происходит проверка корпоративных документов, проверка личности клиента и т.д.

  Как узнать, есть ли у сайта SSL-сертификат?

  Будет несколько визуальных подсказок: замок рядом с адресной строкой, в адресе будет использоваться https вместо http. Если сайт получил EV-сертификат, в адресной строке можно будет увидеть зеленый ярлык (Green Bar).

  Похожие публикации:

  1. Id number что это в россии
  2. Как преобразовать qstring в char
  3. Как скачать файл по ссылке linux
  4. Как установить ардуино на windows 10