Поддержка ssl – знакомство с SSL/TLS / 1cloud.ru corporate blog / Habr

знакомство с SSL/TLS / 1cloud.ru corporate blog / Habr

Мы достаточно часто рассказываем о разных технологиях: от систем хранения до резервного копирования. Помимо этого мы делимся собственным опытом оптимизации работы нашего 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:

habr.com

Цифровые SSL сертификаты. Разновидности, как выбрать? / TutHost corporate blog / Habr

Существует достаточно много цифровых сертификатов, каждый из которых служит для своих целей. Самые распространенный тип сертификатов это естественно SSL сертификаты, которые также имеют несколько подвидов. Также существуют Code Signing сертификаты, Website Anti Malware Scanner сертификаты и Unified Communications сертификаты.

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

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

Начнем с самых распространенных SSL сертификатов.

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

Для того, чтобы активировать возможность работы протокола HTTPS как раз и нужны цифровые SSL сертификаты (также потребуется выделенный IP для конкретного сайта).

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

SSL — это сокращение от Secure Socket Layer — это стандартная интернет технология безопасности, которая используется, чтобы обеспечить зашифрованное соединение между веб-сервером (сайтом) и браузером. SSL сертификат позволяет нам использовать https протокол. Это безопасное соединение, которое гарантирует, что информация которая передается от вашего браузера на сервер остается приватной; то есть защищенной от хакеров или любого, кто хочет украсть информацию. Один из самых распространенных примеров использования SSL — это защита клиента во время онлайн транзакции (покупки товара, оплаты).

Как получить SSL сертификат?

Самый простой и бесплатный способ — это использовать, так называемый, самоподписной сертификат (self-signed), который можно сгенерировать прямо на веб-сервере. К слову во всех самых популярных панелях управления хостингом (Cpanel, ISPmanager, Directadmin) эта возможность доступна по умолчанию, поэтому техническую сторону процесса создания сертификата мы сейчас опустим.

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

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

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

По какому принципу работает SSL сертификат?

Итак для того, чтобы получить SSL сертификат самое первое, что нужно сделать, это сформировать специальный запрос на выпуск сертификата, так называемый (Certificate Signing Request). При формировании этого запроса вам будет задан ряд вопросов, для уточнения деталей о вашем домене и вашей компании. После завершения ваш веб сервер создаст 2 типа криптографических ключей — приватный ключ и публичный ключ.

Публичный ключ не является секретным и он помещается в запрос CSR.
Вот пример такого запроса:
——BEGIN CERTIFICATE REQUEST——
MIIC3zCCAccCAQAwgZkxCzAJBgNVBAYTAlVBMQ0wCwYDVQQIEwRLaWV2MQ0wCwYD
VQQHEwRLaWV2MRQwEgYDVQQKEwtIb3N0QXV0b21hdDEQMA4GA1UECxMHaG9zdGlu
ZzEmMCQGCSqGSIb3DQEJARYXc3VwcG9ydEBob3N0YXV0b21hdC5jb20xHDAaBgNV
BAMTE3d3dy5ob3N0YXV0b21hdC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDTg7iUv/iX+SyZl74GcUVFHjFC5IqlTNEzWgLWrsSmxGxlGzXkUKid
NyXWa0O3ayJHOiv1BSX1l672tTqeHxhGuM6F7l5FTRWUyFHUxSU2Kmci6vR6fw5c
cgWOMMNdMg7V5bMOD8tfI74oBkVE7hV95Ds3c594u7kMLvHR+xui2S3z2JJQEwCh
mflIojGnSCO/iv64RL9vjZ5B4jAWJwrruIXO5ILTdis41Z1nNIx3bBqkif0H/G4e
O5WF6fFb7etm8M+d8ebkqEztRAVdhXvTGBZ4Mt2DOV/bV4e/ffmQJxffTYEqWg8w
b465GdAJcLhhiSaHgqRzrprKns7QSGjdAgMBAAGgADANBgkqhkiG9w0BAQUFAAOC
AQEAuCfJKehyjt7N1IDv44dd+V61MIqlDhna0LCXh2uT7R9H8mdlnuk8yevEcCRI
krnWAlA9GT3VkOY3Il4WTGg3wmtq6WAgLkVXQnhIpGDdYAflpAVeMKil8Z46BGIh
KQGngL2PjWdhMVLlRTB/01nVSKSEk2jhO8+7yLOY1MoGIvwAEF4CL1lAjov8U4XG
NfQldSWT1o8z9sDeGsGSf5DAXpcccx0gCyk90HFJxhbm/vTxjJgchUFro/0goVpB
credpKxtkwBMuCzeSyDnkQft0eLtZ9b9Q4+ZNDWsPPKxo/zWHm6Pa/4F4o2QKvPC
Px9x4fm+/xHqkhkR79LxJ+EHzQ==
——END CERTIFICATE REQUEST——

Данные которые содержатся в этом ключе можно легко проверить с помощью сервисов CSR Decoder. Как пример: CSR Decoder 1 или CSR Decoder 2. Второй сервис выдает больше информации о CSR и проверяет ее на валидность, поле Signature в результатах проверки.

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

CSR Information:
Common Name: tuthost.ua — доменное имя, которое мы защищаем таким сертификатом
Organization: TutHost — название организации, которой принадлежит домен
Organization Unit: Hosting department — подразделение организации
Locality: Kiev — город, где находится офис организации
State: Kiev — область или штат
Country: UA — двухбуквенный код, страны офиса.
Email: [email protected] — контактный email технического администратора или службы поддержки

Важный момент — обратите внимание на поле Country — формат этого поля подразумевает только двухбуквенный код по стандарту ISO 3166-1, если вы не уверены в коде вашей страны, то проверить его можно например тут: Таблица ISO-3166-1. Я обращаю внимание на это поле, потому, что самая частая ошибка у наших клиентов при генерации запроса CSR — это неправильный код страны. И как следствие с такой CSR произвести выпуск сертификата невозможно.

После того как CSR сгенерирован вы можете приступать к оформлению заявки на выпуск сертификата. Во время этого процесса центр сертификации (CA — Certification Authority) произведет проверку введенных вами данных, и после успешной проверки выпустит SSL сертификат с вашими данными и даст возможность вам использовать HTTPS. Ваш сервер автоматически сопоставит выпущенный сертификат, со сгенерированным приватным ключем. Это означает, что вы готовы предоставлять зашифрованное и безопасное соединение между вашим сайтом и браузером клиентов.

Какие данные содержит в себе SSL сертификат?

В сертификате хранится следующая информация:

• полное (уникальное) имя владельца сертификата
• открытый ключ владельца
• дата выдачи ssl сертификата
• дата окончания сертификата
• полное (уникальное) имя центра сертификации
• цифровая подпись издателя

Что такое центры сертификации (CA)?

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

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

Говоря в общем, SSL сертификаты содержат и отображают (как минимум одно из) ваше доменное имя, ваше название организации, ваш адрес, город и страницу. Также сертификат всегда имеет дату окончания и данные о центре сертификации, ответственного за выпуск сертификата. Браузер подключается к защищенному сайту, получает от него SSL сертификат и делает ряд проверок: он не просрочен ли сертификат, потом он проверяет, выпущен ли сертификат известным ему центром сертификации (CA) используется ли сертификат на сайте, для которого он был выпущен.

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

Центров сертификации существует достаточно много, вот перечень самых популярных:
Comodo — работает с 1998 штабквартира в Jersey City, New Jersey, США.
Geotrust — основан в 2001, в 2006 продан Verisign, штабквартира Mountain View, California, США
Symantec — бывший Verisign в состав которого входит и Geotrust. Купил всех в 2010 году.
Thawte — основан в 1995, продан Verisign в 1999.
Trustwave — работает с 1995, штабквартира Chicago, Illinois, США.

Как видим самый крупный игрок на рынке SSL сертификатов это Symantec, который владеет тремя крупнейшими центрами сертификации — Thawte, Verisgin и Geotrust.

Есть ли разница в каком центре сертификации заказывать сертификат?

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

Чтобы проверить, корневые сертификаты каких центров сертификации установлены в вашем браузере, достаточно в настройках вашего браузера найти такую опцию. (В Chrome Настройки -> показать дополнительные настройки -> управление сертификатами -> Доверенные корневые центры сертификации). В Chrome установлено более 50 таких корневых сертификатов.

Важный момент — частенько у клиентов возникала ситуация, когда SSL сертификат на серверe установлен, но при заходе на сайт браузер все равно выдает ошибку. Такая ситуация может возникнуть или из-за отсутствия в файле ca-bundle.crt корневого сертификата центра выдавшего сертификат или из-за того, что корневой сертификат устарел. Корневые сертификаты также имеют свой срок действия (в браузерах они обновляются при обновлении браузера).

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

RapidSSL Certificate

GeoTrust SSL Certificates

Thawte SSL Certificates

VeriSign SSL Certificates

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

Итак мы вплотную подошли к видам SSL сертификатов.

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

Между собой сертификаты отличаются свойствами и уровнем валидации.

Типы сертификатов по типу валидации

• Сертификаты, которые подтверждают только доменное имя (Domain Validation — DV).
• Сертификаты, которые подтверждают домен и организацию (Organization Validation — OV).
• Сертификаты, с расширенной проверкой (Extendet Validation — EV).

Разберемся с ними по порядку:

Сертификаты, подтверждающие только домен

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

Важный момент, что это письмо может быть отправлено только на так называемый approver email, который вы указываете при заказе сертификата. И к адресу approver email есть определенные требования, он должен быть либо в том же домене для которого вы заказываете сертификат, либо он должен быть указан в whois домена.
Если вы указываете email в том же домене, что и сертификат, то указывать любой emal тоже нельзя, он должен соответствовать одному из шаблонов:
admin@
administrator@
hostmaster@
postmaster@
webmaster@

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

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

Сертификаты с валидацией организации.

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

Процесс выдачи сертификатов OV

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

Что проверяется в таких случаях?

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

1. Наличие организации в международных желтых страницах — проверяется не всеми центрами сертифации
2. Наличие в whois домена названия вашей организации — а вот это уже проверят обязательно, и если такое название там не указано от вас скорей всего затребуют гарантийное письмо, в котором нужно указать, что домен действительно принадлежит организации, иногда могут затребовать подтверждение от регистратора
3. Свидетельство о государственной регистрации — требуют все реже, чаще сейчас производится проверка через специальные компании, которые производят проверку существования организации по своим каналам. Например для Украины вас могут проверить по базе ЕДРПОУ
4. Счет от телефонной компании, в которой содержится название вашей организации и ваш номер телефона, указанный в заказе — таким образом проверяется валидность вашего телефона. Требуют все реже.
5. Проверочный звонок — все чаще правильность телефона проверяют осуществляя звонок, на номер телефона, указанный вами в заказе. При звонке спросят сотрудника, указанного в административном контакте. Не у всех центров сертификации есть русскоговорящие сотрудники, поэтому предупредите человека, который отвечает на телефон, что возможен звонок от англоязычной компании.

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

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

Вот как это выглядит на сайте у Thawte.

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

SSL cертификаты с расширенной проверкой (EV) выпускаются только когда центр сертификации (CA) выполняет две проверки, чтобы убедиться, что организация имеет право использовать определенный домен плюс центр сертификации выполняет тщательную проверку самой организации. Процесс выпуска сертификатов EV стандартизирован и должен строго соотвествовать правилам EV, которые были созданы на специализированном форуме CA/Browser Forum в 2007 году. Там указаны необходимые шаги, которые центр сертификации должен выполнить перед выпуском EV сертификата:

1. Должен проверить правовую, физическую и операционную деятельности субъекта.
2. Должен убедиться, что организация соответствует официальным документам.
3. Необходимо убедиться, что организация имеет исключительное право на использование домена, указанного в сертификате EV.
4. Необходимо убедиться, что организация полностью авторизована для выпуска EV сертификата.

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

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

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

Типы SSL сертификатов по своим свойствам.

Обычные SSL сертификаты

Тут все понятно, это сертификаты, которые выпускаются автоматически и подтверждают только домен. Подходят для всех сайтов.
Цена: от 20$ в год

SGC сертификаты

Сертификаты с поддержкой повышения уровня шифрования. Актуально для очень старых браузеров, которые поддерживали только 40 или 56 бит шифрование. При использовании этого сертификата уровень шифрования принудительно повышается до 128 бит.
За все время у нас не купили не одного такого сертификата. Мое мнение, что они уже не нужны, разве что для внутреннего использования в больших корпорациях, где сохранилось очень старое железо.
Цена: от 300 $ в год.

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

Нужны в том случае, когда вам кроме основного домена нужно обеспечить шифрование также на всех поддоменах одного домена. Например: есть домен domain.com и вам нужно установить такой же сертификат на support.domain.com, forum.domain.com и billing.domain.com

Совет: посчитайте количество поддоменов, на которые нужен сертификат, иногда бывает выгодней купить отдельно несколько обычных сертификатов.
Цена: от 180$ в год. Как видите, если у вас меньше 9 поддоменов, то дешевле купить обычный сертификат, хотя в использовании будет удобней один wildcard.

SAN сертификаты

Пригодится, если вы хотите использовать один сертификат для нескольких разных доменов, размещенных на одном сервере. Обычно в такой сертификат входит 5 доменов и их количество можно увеличивать с шагом в 5.
Цена: от 395 $ в год

EV сертификаты

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

Сертификаты c поддержкой IDN

Как правило, не у всех центров сертификации указана эта опция в описании сертификата, но не все сертификаты поддерживаются работу с IDN доменами. Поэтому я просто приведу здесь список сертификатов, у которых есть такая поддержка:

• Thawte SSL123 Certificate
• Thawte SSL Web Server
• Symantec Secure Site
• Thawte SGC SuperCerts
• Thawte SSL Web Server Wildcard
• Thawte SSL Web Server with EV
• Symantec Secure Site Pro
• Symantec Secure Site with EV
• Symantec Secure Site Pro with EV

Как выбрать самый дешевый сертификат?

У Geotrust самые дешевые SAN сертификаты. Сертификаты с валидацией только сайта, а также wildcard выгоднее всего у RapidSSL. EV сертификаты самые дешевые также у Geotrust. SGC сертификаты есть только у Thawte и Verisign, но у Thawte дешевле.

Чем еще отличаются сертификаты между собой

• Скоростью выпуска. Быстрее всего выпускаются сертификаты с валидацией только домена, дольше всего с EV валидацией, от 7 рабочих дней.
• Количество перевыпусков сертификата — у большинства центров сертификации неограниченно. Требуется, если допустили ошибку в данных об организации.
• Гарантия — для некоторых сертификатов есть гарантия от 10.000 $. Это гарантия скорее не для покупателя сертификата, а для посетителя сайта, где установлен сертификат. В случае если посетитель сайта с таким сертификатом пострадает от фрауда и потеряет деньги, то центр сертификации обязуется их ему компенсировать до суммы указанной в гарантии. То есть центр сертификации как бы дает гарантию на свои сертификаты и что их невозможно установить на «левый» домен. На практике такие случае мне не известны поэтому на этот параметр можно не обращать внимание.
• Бесплатный тестовый период — из платных сертификатов есть у symantec secure site, geotrust rapidssl, comodo positive ssl, thawte ssl web server. Также можете для тестов использовать бесплатные сертификаты: StartSSL™ Free
• Возврат средств — есть почти у всех сертификатов в течении 30 дней, хотя бывают и сертификаты без периода moneyback

Полезные утилиты:

1. OpenSSL — самая распространенная утилита для генерации открытого ключа (запроса на сертификат) и закрытого ключа.
   http://www.openssl.org/
2. CSR Decoder — утилита для проверки CSR и данных, которые в нем содержаться, рекомендую использовать перед заказом сертификата.
   CSR Decoder 1 или CSR Decoder 2
   
3. DigiCert Certificate Tester — утилита для проверки корректно самого сертификата
   http://www.digicert.com/help/?rid=011592
   http://www.sslshopper.com/ssl-checker.html
   

В следующих частях постараюсь рассказать про остальные виды сертификатов.

P.S. с удовольствием отвечу на любые вопросы связанные с выбором SSL сертификата в комментариях.
P.P.S. Желающие получить 30% скидку на ssl сертификаты — пишите в личку.

Update: Важный момент — некоторые сертификаты умеют работать на доменах с www и без www, то есть для защиты www.domain.com и domain.com достаточно одного сертификата, но заказывать его нужно на www.domain.com
Актуально для сертификатов:
• RapidSSL
• QuickSSL Premium
• True BusinessID
• True BusinessID with EV

habr.com

TLS и SSL: Необходимый минимум знаний

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

Что такое SSL и что такое TLS?

SSL — Secure Socket Layer, уровень защищенных сокетов. TLS — Transport Layer Security, безопасность транспортного уровня. SSL является более ранней системой, TLS появился позднее и он основан на спецификации SSL 3.0, разработанной компанией Netscape Communications. Тем не менее, задача у этих протоколов одна — обеспечение защищенной передачи данных между двумя компьютерами в сети Интернет. Такую передачу используют для различных сайтов, для электронной почты, для обмена сообщениями и много еще для чего. В принципе, можно передавать любую информацию таким образом, об этом чуть ниже.

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

SSL 1.0 — никогда не публиковался
SSL 2.0 — февраль 1995 года
SSL 3.0 — 1996 год
TLS 1.0 — январь 1999 года
TLS 1.1 — апрель 2006 года
TLS 1.2 — август 2008 года

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

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

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

Установка соединения обеспечивается в несколько этапов:

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

2) При установке соединения клиент предоставляет список алгоритмов шифрования, которые он «знает». Сервер сверяет полученный список со списком алгоритмов, которые «знает» сам сервер, и выбирает наиболее надежный алгоритм, после чего сообщает клиенту, какой алгоритм использовать

3) Сервер отправляет клиенту свой цифровой сертификат, подписанный удостоверяющим центром, и открытый ключ сервера.

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

5) Генерируется сеансовый ключ для защищенного соединения. Это делается следующим образом:
— Клиент генерирует случайную цифровую последовательность
— Клиент шифрует ее открытым ключом сервера и посылает результат на сервер
— Сервер расшифровывает полученную последовательность при помощи закрытого ключа
Учитывая, что алгоритм шифрования является асимметричным, расшифровать последовательность может только сервер. При использовании асимметричного шифрования используется два ключа — приватный и публичный. Публичным отправляемое сообщение шифруется, а приватным расшифровывается. Расшифровать сообщение, имея публичный, ключ нельзя.

6) Таким образом устанавливается зашифрованное соединение. Данные, передаваемые по нему, шифруются и расшифровываются до тех пор, пока соединение не будет разорвано.

Корневой сертификат

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

Запрос на подпись (CSR, Certificate Sign Request)

Для получения подписанного серверного сертификата необходимо сгенерировать запрос на подпись (CSR, Certificate Sign Request) и отправить этот запрос авторизационному центру, который вернет подписанный сертификат, устанавливаемый непосредственно на сервер, чуть ниже посмотрим, как это сделать на практике. Сначала генерируется ключ для шифрования, затем на основании этого ключа генерируется запрос на подпись, CSR-файл.

Клиентский сертификат

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

Цепочка действий по генерации сертификатов

Давайте посмотрим на практике, как происходят действия, связанные с генерацией сертификатов, с самого начала, и при этом на практике.

Первое, что делается — это генерация корневого сертификата. Корневой сертификат подписывается самим собой. А потом уже этим сертификатом будут подписываться другие сертификаты.

$ openssl genrsa -out root.key 2048
Generating RSA private key, 2048 bit long modulus
..........+++
...........................................+++
e is 65537 (0x10001)

$ openssl req -new -key root.key -out root.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:RU
State or Province Name (full name) [Some-State]:N/A
Locality Name (eg, city) []:Saint-Petersburg
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
Organizational Unit Name (eg, section) []:IT Service
Common Name (e.g. server FQDN or YOUR name) []:My Company Root Certificate
Email Address []:[email protected]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:My Company

$ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem
Signature ok
subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected]
Getting Private key

Таким образом мы сгенерировали сначала приватный ключ, затем запрос подписи, а затем своим ключом подписали свой же запрос и получили собственный цифровой сертификат, выданный на 10 лет. Пароль (challenge password) при генерации сертификата можно не вводить.

Приватный ключ ОБЯЗАТЕЛЬНО необходимо хранить в надежном месте, имея его можно подписать от вашего имени любой сертификат. А полученный корневой сертификат можно использовать для идентификации того, что сертификат, например, сервера подписан именно нами, а не кем-то еще. Именно такие действия выполняют авторизационные центры, когда генерируют собственные сертификаты. После создания корневого сертификата можно приступать к генерации сертификата сервера.

Просмотр информации о сертификате

Содержимое сертификата можно просмотреть таким образом:

$ openssl x509 -noout -issuer -enddate -in root.pem
issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected]
notAfter=Jan 22 11:49:41 2025 GMT

Мы видим, кто выдал этот сертификат и когда заканчивается срок его годности.

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

Для подписи сертификата для сервера нам нужно выполнить следующие действия:

1) Сгенерировать ключ
2) Сгенерировать запрос на подпись
3) Отправить CSR-файл в авторизационный центр или подписать самостоятельно

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

$ openssl genrsa -out server.key 2048
Generating RSA private key, 2048 bit long modulus
...................................................................................+++
..........................+++
e is 65537 (0x10001)

$ openssl req -new -key server.key -out server.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:RU
State or Province Name (full name) [Some-State]:N/A
Locality Name (eg, city) []:Saint-Petersburg
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
Organizational Unit Name (eg, section) []:IT Service
Common Name (e.g. server FQDN or YOUR name) []:www.mycompany.com
Email Address []:[email protected]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

$ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out server.pem -days 365
Signature ok
subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/[email protected]
Getting CA Private Key

$ openssl x509 -noout -issuer -subject -enddate -in server.pem
issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected]
subject= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/[email protected]
notAfter=Jan 25 12:22:32 2016 GMT

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

Установка SSL/TLS-сертификата на сервер с nginx

Для установки SSL/TLS-сертификата на веб-сервер nginx надо выполнить несколько простых шагов:

1) Скопировать файлы .key и .pem на сервер. В различных операционных системах сертификаты и ключи могут храниться в разных директориях. В Debian’е, к примеру, это директория /etc/ssl/certs для сертификатов и /etc/ssl/private для ключей. В CentOS это /etc/pki/tls/certs и /etc/pki/tls/private

2) Прописать необходимые настройки в конфигурационный файл для хоста. Вот как это примерно должно выглядеть (это просто пример):

server {
       listen 443;
       server_name www.mycompany.com;

       root html;
       index index.html index.htm;

       ssl on;
       ssl_certificate server.pem;
       ssl_certificate_key server.key;

       ssl_session_timeout 5m;

       # Не рекомендуется использовать SSLv3 !!!
       # Он здесь только для примера
       ssl_protocols SSLv3 TLSv1;
       ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
       ssl_prefer_server_ciphers on;

       location / {
               try_files $uri $uri/ =404;
       }
}

3) Перезапустить nginx

4) Зайти браузером на 443 порт сервера — https://www.mycompany.com и проверить его работоспособность.

Установка SSL/TLS-сертификата на сервер с Apache

Установка SSL/TLS-сертификата на Apache выглядит примерно так же.

1) Скопировать файлы ключа и сертификата на сервер в соответствующие директории

2) Включить модуль ssl для Apache командой «a2enmod ssl», если он еще не включен

3) Создать виртуальный хост, который будет слушать 443 порт. Конфиг будет выглядеть примерно так:

<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerAdmin [email protected]

        DocumentRoot /var/www
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                AllowOverride None
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Order allow,deny
                Allow from all
        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log

        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined

        SSLEngine on

        SSLCertificateFile    /etc/ssl/certs/server.pem
        SSLCertificateKeyFile /etc/ssl/private/server.key

        # Эта директива добавляет файл, содержащий список
        # всех сертификатов, которыми подписан сертификат сервера
        #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt

        <FilesMatch "\.(cgi|shtml|phtml|php)$">
                SSLOptions +StdEnvVars
        </FilesMatch>
        <Directory /usr/lib/cgi-bin>
                SSLOptions +StdEnvVars
        </Directory>

        BrowserMatch "MSIE [2-6]" \
                nokeepalive ssl-unclean-shutdown \
                downgrade-1.0 force-response-1.0
        BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

</VirtualHost>
</IfModule>

При этом надо сделать еще кое-что. Найти в файле httpd.conf, или apache2.conf, или ports.conf, в зависимости от системы, такой участок конфига:

<IfModule mod_ssl.c>
    Listen 443
</IfModule>

Если такого условия нет, его надо добавить в конфиг. И еще одно: Надо добавить строку

NameVirtualHost *:443

Эта строка может находиться в файле httpd.conf, apache2.conf или ports.conf

4) Перезапустить веб-сервер Apache

Создание клиентского сертификата

Клиентский сертификат создается примерно так же, как серверный.

$ openssl genrsa -out client.key 2048

Generating RSA private key, 2048 bit long modulus
........................+++
..................................................+++
e is 65537 (0x10001)

$ openssl req -new -key client.key -out client.csr

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:RU
State or Province Name (full name) [Some-State]:Saint-Petersburg
Locality Name (eg, city) []:^C
mnorin@mnorin-work:~/Temp/certs/CA$ openssl req -new -key client.key -out client.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:RU
State or Province Name (full name) [Some-State]:N/A
Locality Name (eg, city) []:Saint-Petrersburg  
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
Organizational Unit Name (eg, section) []:Engineering
Common Name (e.g. server FQDN or YOUR name) []:Ivan Ivanov
Email Address []:[email protected]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

$ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out client.pem -days 365

Signature ok
subject=/C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/[email protected]
Getting CA Private Key

$ openssl x509 -noout -issuer -subject -enddate -in client.pem
issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected]
subject= /C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/[email protected]
notAfter=Jan 25 13:17:15 2016 GMT

Если необходим клиентский сертификат в формате PKCS12, создаем его:

$ openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12

Enter Export Password:
Verifying - Enter Export Password:

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

Настройка nginx на использование клиентских сертификатов

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

# Корневой сертификат(ы), которым(и) подписан клиентский
ssl_client_certificate /etc/nginx/certs/clientroot.pem;
# Возможные варианты: on | off | optional | optional_no_ca
ssl_verify_client optional;
# Глубина проверки цепочки сертификатов, которыми подписан клиентский
ssl_verify_depth 2;

После этого надо перезагрузить настройки или сервер целиком и можно проверять работу.

Настройка Apache на использование клиентских сертификатов

Apache настраивается также через добавление дополнительных опций в секцию виртуального хоста:

# Директория, содержащая корневые сертификаты для проверки клиентов
SSLCARevocationPath /etc/apache2/ssl.crl/
# или файл, содержащий сертификаты
SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl
# Опция верификации клиента. Возможные варианты:
# none, optional, require and optional_no_ca
SSLVerifyClient require
# Глубина просмотра цепочки подписей. По умолчанию 1
SSLVerifyDepth  2

Как видите, опции примерно такие же, как и для nginx, поскольку процесс проверки организован единообразно.

«Прослушка» информации о сертификате при помощи openssl

Для проверки взаимодействия сервера с клиентскими сертификатами можно проверить, устанавливается ли соединение с использованием TLS/SSL.

На стороне сервера запускаем прослушку порта при помощи openssl:

openssl s_server -accept 443 -cert server.pem -key server.key -state

На стороне клиента обращаемся к серверу, например, culr’ом:

curl -k https://127.0.0.1:443

В консоли со стороны сервера можно наблюдать процесс обмена информацией между сервером и клиентом.

Можно также использовать опции -verify [глубина проверки] и -Verify [глубина проверки]. Опция с маленькой буквы запрашивает у клиента сертификат, но он не обязан его предоставлять. С большой буквы — если сертификат не предоставлен, возникнет ошибка. Запустим прослушку со стороны сервера таким образом:

openssl s_server -accept 443 -cert server.pem -key server.key -state -Verify 3

Со стороны сервера ошибка выглядит так:

140203927217808:error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate:s3_srvr.c:3287:

Со стороны клиента так:

curl: (35) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

Добавим с клиентской стороны сертификат и доменное имя (можно для проверки вписать в файл /etc/hosts имя хоста для адреса 127.0.0.1):

curl https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key client.key

Теперь соединение пройдет успешно и можно устанавливать серверный сертификат на веб-сервер, клиентский отдать клиенту, и работать с ними.

Безопасность

При использовании SSL/TLS одним из основных методов является метод MITM (Man In The Middle), «человек посередине». Этот метод основывается на использовании серверного сертификата и ключа на каком-то узле, который будет прослушивать трафик и расшифровывать информацию, которой обмениваются сервер и клиент. Для организации прослушивания можно использовать, например, программу sslsniff. Поэтому корневой сертификат и ключ обычно желательно хранить на машине, которая не подключена к сети, для подписания приносить запросы на подпись на флэшке, подписывать и так же уносить. И, естественно, делать резервные копии.

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

• Нажмите здесь, чтобы поделиться контентом на Facebook. (Открывается в новом окне)
• Нажмите, чтобы поделиться на LinkedIn (Открывается в новом окне)
• Нажмите, чтобы поделиться на Reddit (Открывается в новом окне)
• Нажмите, чтобы поделиться на Twitter (Открывается в новом окне)
• Нажмите, чтобы поделиться записями на Tumblr (Открывается в новом окне)
• Нажмите, чтобы поделиться записями на Pinterest (Открывается в новом окне)
• Нажмите, чтобы поделиться записями на Pocket (Открывается в новом окне)
• Нажмите, чтобы поделиться в Telegram (Открывается в новом окне)
• Нажмите, чтобы поделиться в WhatsApp (Открывается в новом окне)
• Нажмите, чтобы поделиться в Skype (Открывается в новом окне)

mnorin.com

SSL-сертификат, что это такое и для чего нужен? Что дает ssl и https для сайта?

HTTPS — что за зверь?

Если вы уже сталкивались с созданием собственного сайта, то наверняка краем уха слышали бессвязный набор фраз «сертификат ssl https что это». В статье мы расскажем, что, как и почему. И эти слова перестанут быть для вас пустым звуком.

Невероятно, но факт: любое действие в Интернете — это обмен данными. Когда вы открываете любимый сайт, ищете видеоролик на «YouTube» или загружаете картинку в инстаграм, ваш поисковый браузер и сервер обмениваются информацией. Каждый вбитый в поисковую строку запрос проходит путь от вас (пользователя) к серверу и обратно. Такая коммуникация возможна благодаря работе протокола HTTP. Он был изобретён ещё в начале 90-х. Всем HTTP хорош, кроме одного: не шифрует данные. Следовательно, их без труда может перехватить третья сторона, личная информация (пароль, номер банковской карты, реквизиты, паспортные данные) может быть украдена злоумышленниками.

В современном мире защита данных имеет принципиальное значение. Поэтому внедрили HTTPS, который расшифровывается как протокол безопасного соединения. Принципом работы защищённого протокола HTTPS является обмен ключами шифрования. Прежде чем ответить на запрос от браузера, сервер предъявляет ключ — SSL-сертификат. Браузер проверяет подлинность ключа в Центре сертификации. Если ключ «подошёл», браузер и сервер доверяют друг другу и договариваются о разовом шифре. Так происходит каждую сессию, то есть каждый раз при обмене запросами и ответами. Вот таким хитрым способом и обеспечивается сохранность данных и конфиденциальность при обмене информацией.

Зачем нужен SSL-сертификат?

Чтобы сайт стал работать по протоколу безопасного соединения HТТPS, нужен SSL-сертификат. Это виртуальный документ, который содержит данные об организации, её владельце и подтверждает их существование. SSL позволяет узнать сервер и подтвердить безопасность сайта.

Использование SSL-сертификата гарантирует:

• Подлинность ресурса, к которому обращается пользователь. Это повышает у посетителей уровень доверия.
• Целостность передаваемой информации. При транспортировке от сервера к браузеру данные не изменятся и не потеряются.
• Конфиденциальность. 256-разрядное шифрование исключает доступ злоумышленников к информации.

Что дает SSL-сертификат для сайта кроме защиты данных? Он также помогает в SEO-продвижении проекта — позволяет занять более высокую позицию в поисковой выдаче. Поисковые системы (Google, Яндекс и пр.) дорожат доверием аудитории и выше ранжируют сайты, которые работают через безопасное соединение.

HTTP или HTTPS? Вот в чём вопрос!

Защита сайта протоколом HTTPS уже давно не просто признак хорошего тона, а необходимость. Несмотря на то, что некоторые сайты ещё работают по HTTP-соединению, очень скоро HTTPS станет обязательным требованием «экологии» Интернета.

Решать, конечно, вам. Но имейте в виду, что с июля 2018 года Google считает небезопасным каждый веб-сайт, не использующий протокол HTTPS. Также WordPress и другие популярные CMS заявили, что некоторые функции теперь будут доступны только для веб-сайтов с протоколом HTTPS.

У меня до сих пор HTTP, что делать?

Если ваш сайт обслуживается на хостинге REG.RU, достаточно заказать SSL-сертификат и перейти с HTTP протокола на HTTPS. Полный цикл:

Готово. Теперь ваш сайт будет работать по HTTPS.

Помогла ли вам статья?

1616 раз уже
помогла

www.reg.ru

Ssl что это такое. Принципы шифрования сертификатом

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

Что такое SSL и TLS

Secure Socket Layer или ssl это, технология, призванная сделать доступ к сайтам более надежным и безопасным. Сертификат шифрования позволяет, надежно защитить трафик, передаваемый между браузером пользователя и веб ресурсом (сервером), к которому браузер обращается, все это происходит за счет протокола https. Сделано, это все после того, как бурное развитие интернета привело к огромному количеству сайтов и ресурсов, которые требуют от пользователя ввод личных, персональных данных:

• Пароли
• Номера кредитных карт
• Переписка

Именно эти данные и являются добычей для хакеров, сколько уже было громких дел, с кражей персональной информации и сколько еще будет, ssl сертификат шифрования, призван это минимизировать. Разработкой технологии SSL выступила компания Netscape Communications, позднее она представила Transport Layer Security или проще TLS, это протокол основанный по спецификации SSL 3.0. И Secure Socket Layer и Transport Layer Security призваны обеспечить передачу данных между двумя узлами по интернету.

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

Если рассматривать современный интернет, то там в качестве сертификата безопасности сервера и шифрования используется TLS, просто знайте это

Для примера откройте сайт Яндекса, я это делаю в Google Chrome, там на против адресной строки есть значок замка, щелкаем по нему. Тут будет написано, что подключение к веб-сайту защищено и можно нажать подробнее.

сразу видим значок Secure TLS connection, как я и говорил, большая часть интернет ресурсов именно на этой технологии. Давайте посмотрим сам сертификат, для этого жмем View certificate.

В поле о сведениях о сертификате видим его предназначение:

1. Обеспечивает получение идентификации от удаленного компьютера
2. Подтверждает удаленному компьютеру идентификацию вашего компьютера
3. 1.2.616.1.113527.2.5.1.10.2

История версий сертификатов шифрования

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

• SSL 1.0 > данная версия в народ так и не попала, причины, возможно нашли его уязвимость
• SSL 2.0 > эта версия ssl сертификата была представлена в 1995 году, на стыке тысячелетий, она так же была с кучей дыр безопасности, сподвигнувшие компанию Netscape Communications к работе над третье версией сертификата шифрования
• SSL 3.0 > пришел на смену SSL 2.0 в 1996 году.  Стало это чудо развиваться и в 1999 году крупные компании Master Card и Visa купили коммерческую лицензию на его использование. Из 3.0 версии появился  TLS 1.0
• TLS 1.0 > 99 год, выходит обновление SSL 3.0 под названием TLS 1.0, проходит еще семь лет, интернет развивается и хакеры не стоят на месте, выходит следующая версия.
• TLS 1.1 > 04.2006  это его отправная точка, было исправлено несколько критичных ошибок обработки, а так же появилась защита от атак, где делался режим сцепления блоков шифротекста
• TLS 1.2 > появился в августе 2008
• TLS 1.3 > появится в конце 2016 года

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

Давайте разбираться как работает протоколы SSL и TLS. Начнем с основ, все сетевые устройства имеют четко прописанный алгоритм общения друг с другом, называется он OSI, который порезан на 7 уровней. В ней есть транспортный уровень отвечающий за доставку данных, но так как модель OSI это некая утопия, то сейчас все работаю по упрощенной модели TCP/IP, из 4 уровней. Стек TCP/IP, сейчас стандарт передачи данных в компьютерных сетях и он включает в себя, большое количество известных вам протоколов прикладного уровня:

Список можно продолжать очень долго, так их более 200 наименований. Ниже представлена схема сетевых уровней.

Ну и схема стека SSL/TLS, для наглядности.

Теперь все тоже самое простым языком, так как не всем понятны эти схемы и принцип работы ssl и tls не понятен. Когда вы открываете например мой блог pyatilistnik.org, то вы обращаетесь по прикладному протоколу http, при обращении сервер видит вас и передает на ваш компьютер данные. Если это представить схематично, то это будет простая матрешка, прикладной протокол http, кладется в стек tcp-ip.

Если бы на Pyatilistnik.org стоял бы сертификат шифрования TLS, то матрешка протоколов была бы посложнее и выглядела бы вот так. Тут прикладной протокол http, кладется в SSL/TLS, который в свою очередь кладется в стек TCP/IP. Все тоже самое, но уже зашифровано, и если хакер перехватит эти данные по пути их передачи, то получит всего навсего цифровой мусор, а вот расшифровать данные может только та машина, которая устанавливала соединение с сайтом.

Этапы установки соединения SSL/TLS

1. Клиент обращается к серверу, устанавливая с ним соединение, далее запрашивается защищенное подключение, тут два варианта, если вы изначально обращаетесь на порт 443, который предназначен для TLS/SSL соединения, или после того как вы установили обычное подключение, клиент делает дополнительный запрос на защищенное соединение.
2. Когда идет установка соединения, клиент говорит серверу, какие алгоритмы шифрования ему известны, сервер сравнивает его со своим списком алгоритмов шифрования и находит тот, который поддерживается обоими сторонами. Далее он говорит клиенту, что будет использоваться именно этот метод защиты. По умолчанию сервер будет стараться использовать самый современный алгоритм (SSLv3, TLSv1, TLSv1.1, TLSv1.2)
3. После того, как определились с алгоритмами шифрования, сервер передает клиенту свой цифровой сертификат, который подписан вышестоящим, мировым центром сертификации и открытый ключ сервера.
4. Клиент проверяет ликвидность полученного сертификата от сервера, для этого он обращается к центру сертификации, который его выдавал, и спрашивает есть ли у тебя такой сертификат, если все нормально, можно продолжать. Тут главное, чтобы сертификат не был отозван и вы доверяли корневому центру сертификации, выдавшим его, по умолчанию в операционной системе Windows, уже есть большое количество корневых сертификатов, которым вы доверяете, и они обновляются при установке новых обновлений в систему.
5. Следующим этапом, после получения клиентом нужных ключей, начинается генерация сеансового ключа для защищенного соединения по принципу: Клиентом происходит генерация случайной цифровой последовательности, которую он шифрует с помощью открытого ключа полученного от сервера и отсылает результат шифрования на сервер. Полученный сеансовый ключ расшифровывается сервером с помощью его закрытого ключа, в виду того, что используется асимметричный алгоритм шифрования, то расшифровать последовательность полученную от клиента, может только сервер. Об алгоритмах шифрования мы еще поговорим ниже.
6. Все защищенный канал настроен и будет работать до тех пор, пока не будет разорвано соединение.

Вот еще одна красивая и наглядная схема создания защищенного канала.

Установка соединения SSL/TLS на уровне сетевых пакетов

На иллюстрации, черные стрелки показывают сообщения, которые отправляются открытым текстом, синие — это сообщения, подписанные открытым ключом, а зеленые — это сообщения, отправленные с помощью шифрования объёмных данных и того MAC, о которых стороны договорились в процессе переговоров.

Ну и подробно про каждый этап обмена сетевых сообщений протоколов SSL/TLS.

• 1. ClientHello > пакет ClientHello делает предложение со списком поддерживаемых версий протоколов, поддерживаемые наборы шифров в порядке предпочтения и список алгоритмов сжатия (обычно NULL). Еще от клиента приходит случайное значение 32 байта, его содержимое указывает отметку текущего времени, его позже будут использовать для симметричного ключа и идентификатора сессии, который будет иметь значение ноль, при условии, что не было предыдущих сессий.
• 2. ServerHello > пакет  ServerHello, отсылается сервером, в данном сообщении идет выбранный вариант, алгоритма шифрования и сжатия. Тут так же будет случайное значение 32 байта (отметка текущего времени), его также используют для симметричных ключей. Если ID текущей сессии в ServerHello имеет значение ноль, то создаст и вернёт идентификатор сессии.  Если в сообщении ClientHello был предложен идентификатор предыдущей сессии, известный данному серверу, то протокол рукопожатия будет проведён по упрощённой схеме. Если клиент предложил неизвестный серверу идентификатор сессии, сервер возвращает новый идентификатор сессии и протокол рукопожатия проводится по полной схеме.
• 3.Certificate (3) > в данном пакете сервер отправляет клиенту свой открытый ключ (сертификат X.509), он совпадает с алгоритмом обмена ключами в выбранном наборе шифров. Вообще можно сказать в протоколе, запроси открытый ключ в DNS, запись типа KEY/TLSA RR. Как я писал выше этим ключом будет шифроваться сообщение.
• 4. ServerHelloDone > Сервер говорит, что сессия установилось нормально.
• 5. ClientKeyExchange > Следующим шагом идет отсылка клиентом ключа pre-master key, используя случайные числа (или отметки текущего времени) сервера и клиента. Данный ключ (pre-master key) как раз и шифруется открытым ключом сервера. Данное сообщение может расшифровать только сервер, с помощью закрытого ключа. Теперь оба участника вычисляют общий секретный ключ master key из ключа pre-master.
• 6. ChangeCipherSpec — клиент > смысл пакета, указать на то, что теперь весь трафик, который идет от клиента, будет шифроваться, с помощью выбранного алгоритма шифрования объёмных данных и будет содержать MAC, вычисленный по выбранному алгоритму.
• 7. Finished — клиент > Это сообщение содержит все сообщения, отправленные и полученные во время протокола рукопожатия, за исключением сообщения Finished. Оно шифруется с помощью алгоритма шифрования объемных данных и хэшируется с помощью алгоритма MAC, о которых договорились стороны. Если сервер может расшифровать и верифицировать это сообщение (содержащее все предыдущие сообщения), используя независимо вычисленный им сеансовый ключ, значит диалог был успешным. Если же нет, на этом месте сервер прерывает сессию и отправляет сообщение Alert с некоторой (возможно, неконкретной) информацией об ошибке
• 8. ChangeCipherSpec — сервер > пакет, говорит, что теперь весь исходящий трафик с данного сервера, будет шифроваться.
• 9.Finished — сервер > Это сообщение содержит все сообщения, отправленные и полученные во время протокола рукопожатия, за исключением сообщения Finished
• 10. Record Protocol (протокол записи) > теперь все сообщения шифруются ssl сертификатом безопасности

Как получить ssl сертификат безопасности

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

Бесплатный способ получить tls сертификат безопасности

Этот способ, подразумевает использование самоподписного сертификата (self-signed), его можно сгенерировать на любом веб-сервере с ролью IIS или Apache. Если рассматривать современные хостинги, то в панелях управления, таких как:

• Directadmin
• ISPmanager
• Cpanel

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

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

Давайте смотреть как можно получить ssl сертификат безопасности, для этого формируется запрос на выпуск сертификата, называется он CSR запрос (Certificate Signing Request). Делается это чаще всего у специальной компании в веб форме, которая спросит вас несколько вопросов, про ваш домен и вашу компанию. Как только вы все внесете, сервер сделает два ключа, приватный (закрытый) и публичный (открытый). Напоминаю открытый ключ не является конфиденциальным, поэтому вставляется в CSR запрос. Вот пример Certificate Signing Request запроса.

Все эти не понятные данные легко можно интерпретировать специальными CSR Decoder сайтами.

Примеры двух сайтов CSR Decoder:

• http://www.sslshopper.com/csr-decoder.html
• http://certlogik.com/decoder/

Состав CSR запроса

• Common Name: доменное имя, которое мы защищаем таким сертификатом
• Organization: название организации
• Organization Unit: подразделение организации
• Locality: город, где находится офис организации
• State: область или штат
• Country:двухбуквенный код, страны офиса
• Email: контактный email технического администратора или службы поддержки

Как только Certificate Signing Request сгенерирован, можно начинать оформлять заявку на выпуск сертификата шифрования. Центр сертификации будет производить проверку, всех данных указанных вами в CSR запросе, и если все хорошо, вы получите свой ssl сертификат безопасности и вы его сможете использовать для https. Теперь ваш сервер, автоматом сопоставит выпущенный сертификат, со сгенерированным приватным ключом, все вы можете шифровать трафик подключения клиента к серверу.

Что такое центр сертификации

Что такое CA — Certification Authority или центр сертификации, читайте по ссылке слева, я подробно рассказал об этом там.

Какие данные содержит в себе SSL сертификат

В сертификате хранится следующая информация:

• полное (уникальное) имя владельца сертификата
• открытый ключ владельца
• дата выдачи ssl сертификата
• дата окончания сертификата
• полное (уникальное) имя центра сертификации
• цифровая подпись издателя

Какие существуют виды SSL сертификатов шифрования

Основных видов сертификатов безопасности три:

• Domain Validation — DV >  Это сертификат шифрования, который только подтверждает доменное имя ресурса
• Organization Validation — OV > Это сертификат шифрования, который подтверждает организацию и домен
• Extendet Validation — EV > Это сертификат шифрования, который имеет расширенную проверку

Назначение Domain Validation — DV

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

approver email так же имеет требования, логично, что если вы заказываете сертификаты шифрования для домена, то и электронный ящик должен быть из него, а не mail или rambler, либо он должен быть указан в whois домена и еще одно требование название approver email, должно быть по такому шаблону:

• webmaster@ваш домен
• postmaster@ваш домен
• hostmaster@ваш домен
• administrator@ваш домен
• admin@

Я обычно беру ящик postmaster@ваш домен

Сертификат tls-ssl подтверждающие доменное имя выпускаются, когда CA произвел валидацию того, что заказчик обладает правами на доменное имя, все остальное, что касается организации в сертификате не отображается.

Назначение Organization Validation — OV

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

Назначение Extendet Validation — EV

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

• Могут посмотреть есть ли организация международных желтых страницах, кто не знает, что это такое, то это телефонные справочники в Америке. Проверяют так не все CA.
• Смотрят whois домена у вашей организации, делают это все центры сертификации, если в whois нет ни слова о вашей организации, то с вас будут требовать гарантийное письмо, что домен ваш.
• Свидетельство о государственной регистрации ЕГРИП или ЕГРЮЛ
• Могут проверить ваш номер телефона, запросив счет у вашей телефонной компании, в котором будет фигурировать номер.
• Могут позвонить и проверить наличие компании по этому номеру, попросят к телефону человека указанного администратором в заказе, так что смотрите, чтобы человек знал английский.

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

 

К расширенным сертификатам шифрования (extendet Validation — EV) самое большое доверие, это и логично вы сразу видите, что компания существует и прошла жесткие требования к выдаче сертификата. SSL cертификаты extendet Validatio делаются CA, только при выполнении двух требований, что организация владеет нужным доменом и, что она сама существует в природе. При выпуске EV SSL сертификатов, существует строгий регламент, в котором описаны требования перед выпуском EV сертификата

• Должен проверить правовую, физическую и операционную деятельности субъекта
• Проверка организации и ее документов
• Право владения доменом, организации
• Проверить, что организация полностью авторизована для выпуска EV сертификата

SSL cертификаты extendet Validatio выпускаются примерно от 10-14 дней, подходят как для некоммерческих организаций, так и для государственных учреждений.

Типы SSL сертификатов шифрования

Следующим важным вопросом, будет какие типы SSL — TLS сертификатов шифрования существуют, и их отличия и стоимость.

• Обычные SSL сертификаты > это самые распространенные сертификаты, делаются автоматически, для подтверждения только домена. Стоят в среднем 18-22 доллара.
• SGC сертификаты > это SSL — TLS сертификаты с поддержкой, более высокого уровня шифрования. Они в основном идут для старперных браузеров, у которых есть поддержка только 40-56 битное шифрование. SGC принудительно повышает уровень шифрования , до 128 бит, что в несколько раз выше. Так как XP доживает свои последние годы, скоро SGC сертификаты шифрования не будут нужны. Стоит это чудо около 300-ста баксов за год.
• Wildcard сертификаты > Требуются, для субдоменов вашего основного домена. Простой пример мой блог pyatilistnik.org, если я покупаю Wildcard, то имею возможно его вешать на все домены 4 уровня у себя, *.pyatilistnik.org. Стоимость Wildcard сертификатов шифрования варьируется от количества поддоменов, от 190 баксов.
• SAN сертификаты > Допустим у вас есть один сервер, но на нем хостятся много разных доменов, вот SAN сертификат можно повесить на сервер и все домены будут использовать его, стоит от 400 баксов в год.
• EV сертификаты > про расширенные мы уже все обсудили выше, стоят от 250 баксов в год.
• Сертификаты c поддержкой IDN доменов

список сертификатов, у которых есть такая поддержка, IDN доменов:

• Thawte SSL123 Certificate
• Thawte SSL Web Server
• Symantec Secure Site
• Thawte SGC SuperCerts
• Thawte SSL Web Server Wildcard
• Thawte SSL Web Server with EV
• Symantec Secure Site Pro
• Symantec Secure Site with EV
• Symantec Secure Site Pro with EV

Полезные утилиты:

1. OpenSSL — самая распространенная утилита для генерации открытого ключа (запроса на сертификат) и закрытого ключа.
   http://www.openssl.org/
2. CSR Decoder — утилита для проверки CSR и данных, которые в нем содержаться, рекомендую использовать перед заказом сертификата.
   http://www.sslshopper.com/csr-decoder.html или http://certlogik.com/decoder/
3. DigiCert Certificate Tester — утилита для проверки корректно самого сертификата
   http://www.digicert.com/help/?rid=011592
   http://www.sslshopper.com/ssl-checker.html

В будущих статьях, мы еще сами по настраиваем CA и будем на практике использовать SSL/TLS сертификаты шифрования.

pyatilistnik.org

SSL — это… Что такое SSL?

SSL (англ. Secure Sockets Layer — уровень защищённых сокетов) — криптографический протокол, который обеспечивает установление безопасного соединения между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS.

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

Описание

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

SSL предоставляет канал, имеющий 3 основных свойства:

• Аутентификация. Сервер всегда аутентифицируется, в то время как клиент аутентифицируется в зависимости от алгоритма.
• Целостность. Обмен сообщениями включает в себя проверку целостности.
• Конфиденциальность канала. Шифрование используется после установления соединения и используется для всех последующих сообщений.

В протоколе SSL все данные передаются в виде записей-объектов, состоящих из заголовка и передаваемых данных. Передача начинается с заголовка. Заголовок содержит либо два, либо три байта кода длины. Причём, если старший бит в первом байте кода равен единице, то запись не имеет заполнителя и полная длина заголовка равна двум байтам, иначе запись содержит заполнитель и полная длина заголовка равна трём байтам. Код длины записи не включает в себя число байт заголовка. Длина записи 2-байтового заголовка:

RecLength = ((byte[ 0 ] & 0x7F) << 8) | byte[ 1 ];

Здесь byte[0] и byte[1] — первый и второй полученные байты. Длина записи 3-байтового заголовка:

RecLength = ((byte[ 0 ] & 0x3F) << 8) | byte[ 1 ];
Escape = (byte[ 0 ] & 0x40) != 0;
Padding = byte[ 2 ];

Здесь Padding определяет число байтов, добавленных отправителем к исходному тексту, для того, чтобы сделать длину записи кратной размеру блока шифра, при использовании блочного шифра.
Теперь отправитель «заполненной» записи добавляет заполнитель после имеющихся данных и шифрует всё это. Причем, содержимое заполнителя никакой роли не играет. Из-за того, что известен объём передаваемых данных, заголовок может быть сформирован с учетом Padding.
В свою очередь получатель записи дешифрует все поля данных и получает полную исходную информацию. Затем производится вычисление значения RecLength по известному Padding, и заполнитель из поля данных удаляется. Данные записи SSL состоят из 3 компонент:

• MAC_Data[Mac_Size] — (Message Authentication Code) — код аутентификации сообщения
• Padding_Data[Padding] — данные заполнителя
• Actual_Data[N] — реальные данные

Когда записи посылаются открытым текстом, очевидно, что никакие шифры не используются. Тогда длина Padding_Data и MAC_Data равны нулю. При использовании шифрования Padding_Data зависит от размера блока шифра, а MAC_Data зависит от выбора шифра. Пример вычисления MAC_Data:

MacData = Hash(Secret, Actual_Data, Padding_Data, Sequence_Number);

Значение Secret зависит от того, кто (клиент или сервер) посылает сообщение. Sequence_Number — счётчик, который инкрементируется как сервером, так и клиентом. Здесь Sequence_Number представляет собой 32-битовый код, передаваемый хэш-функции в виде 4 байт, причём, первым передаётся старший байт. Для MD2, MD5 MAC_Size равен 16 байтам (128 битам). Для 2-байтового заголовка максимальная длина записи равна 32767 байтов, а для 3-байтного заголовка — 16383 байтов.

История и развитие

Протокол SSL был изначально разработан компанией Netscape. Версия протокола 1.0 публично не выпускалась. Версия 2.0 была выпущена в феврале 1995 года, но «содержала много недостатков по безопасности, которые, в конечном счёте, привели к созданию версии 3.0», которая была выпущена в 1996 году. Тем самым версия SSL 3.0 послужила основой для создания протокола TLS 1.0, стандарт протокола Internet Engineering Task Force (IETF) впервые был определен в RFC 2246 в январе 1999 года. Visa, Master Card, American Express и многие другие организации, работающие с интернет деньгами, имеют лицензию на использование протокола SSL для коммерческих целей в сети Интернет.

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

Применение

Значительное использование протокола SSL привело к формированию протокола HTTPS (Hypertext Transfer Protocol Secure), поддерживающего шифрование. Данные, которые передаются по протоколу HTTPS, «упаковываются» в криптографический протокол SSL или TLS, тем самым обеспечивая защиту этих данных. Такой способ защиты широко используется в мире Веб для приложений, в которых важна безопасность соединения, например в платёжных системах. HTTPS поддерживается всеми браузерами. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443.

Изначально виртуальные частные сети (VPN) на основе SSL разрабатывались как дополнительная и альтернативная технология удалённого доступа на основе IPsec VPN. Однако, такие факторы, как достаточная надёжность и дешевизна сделали эту технологию привлекательной для организации VPN. Также SSL получил широкое применение в электронной почте.

Основные цели протокола в порядке приоритетности

1. Криптографическая безопасность: SSL устанавливает безопасное соединение между двумя сторонами.
2. Совместимость: Программисты, независимо друг от друга могут создавать приложения, использующие SSL, которые впоследствии будут способны успешно обмениваться криптографическими параметрами без всякого знания кода чужих программ.
3. Расширяемость: SSL стремится обеспечить рабочее пространство, в котором новые открытые ключи и трудоемкие методы шифрования могут быть включены по мере необходимости.
4. Относительная эффективность: работа протокола на основе SSL требует больших скоростей от CPU, в частности для работы с открытыми ключами. По этой причине SSL протокол был включен в необязательную сессию схемы кеширования для уменьшения числа соединений, которые необходимо устанавливать с нуля. Кроме того, большое внимание уделяется тому, чтобы уменьшить сетевую активность.

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

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

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

Всякий раз, когда сервер аутентифицируется, канал безопасен против попытки перехвата данных между веб-сервером и браузером, но полностью анонимная сессия по своей сути уязвима к такой атаке. Анонимный сервер не может аутентифицировать клиента. Если сервер аутентифицирован, то его сообщение сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный клиент должен предоставить допустимый сертификат серверу. Каждая сторона отвечает за проверку того, что сертификат другой стороны еще не истек и не был отменен. Главная цель процесса обмена ключами — это создание секрета клиента (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, которому ставит в соответствие сигнатуру текущему сообщению рукопожатия.

Обмен ключами при использовании Diffie-Hellman и аутентификация

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

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

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

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

Существует четыре протокола записи: протокол рукопожатия (handshake protocol), протокол тревоги (alert protocol), протокол изменения шифра (the change cipher spec protocol), протокол приложения (application data protocol). Если SSL реализация получает тип записи, который ей неизвестен, то эта запись просто игнорируется. Любой протокол созданный для использования совместно с SSL должен быть хорошо продуман, так как будет иметь дело с атаками на него. Заметим, что из-за типа и длины записи, протокол не защищен шифрованием. Внимание следует уделить тому, чтобы минимизировать трафик.

Протокол рукопожатия (handshake)

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

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

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

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

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

• Из случайного числа обе стороны создают ключевые данные для шифрования и расшифровывания.

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

Протокол изменения параметров шифрования (The Change Cipher Spec Protocol)

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

struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;

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

Протокол тревоги (Alert Protocol)

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

Протокол приложения (Application Data Protocol)

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

Ошибки в протоколе SSL

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

1. Unsupported_Certificate_Type_Error: такая ошибка возникает, когда клиент/сервер получает тип сертификата, который не поддерживается. Ошибка устранима (только для аутентификации клиента).
2. No_Cipher_Error: ошибка возникает, когда сервер не может найти размер ключа или шифр, который поддерживается также и клиентом. Ошибка неустранима.
3. Bad_Certificate_Error: такая ошибка возникает, когда сертификат считается принимающей стороной плохим. Это означает, что или некорректна подпись сертификата, или его значение некорректно. Ошибка устранима (только для аутентификации клиента).
4. No_Certificate_Error: если послано сообщение Request_Certificate, то эта ошибка может быть прислана по причине того, что клиент не имеет сертификата. Ошибка устранима.

Атаки

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

«Взлом» агентами ФБР SSL-соединений с помощью систем прослушки Carnivore и NarusInsight

Наиболее известный инцидент по массовому «взлому» информации защищенной SSL-протоколами был произведен агентами ФБР с помощью систем Carnivore и NarusInsight, что привело к судебному процессу от лица правозащитной организации Electronic Frontier Foundation против AT&T (подробнее в статье о NarusInsight), который установил данные комплексы для взлома криптографически защищенной информации.

Несмотря на высокий общественный резонанс в США данного дела и расследование на уровне конституционного комитета Палаты представителей (см. подробнее в статье Carnivore), технологически взлом протокола SSL агентами ФБР не производился. Carnivore и NarusInsight были установле в самом ЦОД, где находились сервера ведущие SSL-соединенения с удаленными клиентами. NarusInsight полностью восстановил зашифрованную информацию путем прослушивания не SSL-соединения, а внутреннего траффика между серверами приложений внутри самого ЦОД, уже после того как данные поступившие по SSL была расшифрованы сами сервером их принявшим от внешних пользователей.

Тем не менее, указанный инцидент показал, что SSL не может являться надежным средством криптозащиты данных серверов в Интернет покуда спецслужбы устанавливают системы прослушивания в ЦОД такие как NarusInsight или СОРМ-2. Любой вид криптографии подразумевающий, что ключи от шифров находятся у сервера-получателя в ЦОД взламываются снифферами спецслужб в автоматическом режиме за счет внедрения их в самого получателя. Далее данные полностью реконструируются по процедурам, которые на данный момент регулируется и законодательными актами такими как «Патриотический акт». Причем указанные законодательные акты запрещают вплоть до судебного преследования владельцов ЦОД удаление снифферов спецслужб из внутренней части серверов-получателей. С учетом наличия данных систем, SSL-протокол может защищать только соединение двух пользователей в Интернет, но не защищает от спецслужб любое SSL-соединение с внешним Web-сайтом.

Раскрытие шифров

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

Злоумышленник посередине

Также известна как MitM (Man-in-the-Middle) атака. Предполагает участие трех сторон: сервера, клиента и злоумышленника, находящегося между ними. В данной ситуации злоумышленник может перехватывать все сообщения, которые следуют в обоих направлениях, и подменять их. Злоумышленник представляется сервером для клиента и клиентом для сервера. В случае обмена ключами по алгоритму Диффи-Хелмана данная атака является эффективной, так как целостность принимаемой информации и ее источник проверить невозможно. Однако такая атака невозможна при использовании протокола SSL, так как для проверки подлинности источника (обычно сервера) используются сертификаты, заверенные центром сертификации.

Атака будет успешной, если:

• Сервер не имеет подписанного сертификата.
• Клиент не проверяет сертификат сервера.
• Пользователь игнорирует сообщение об отсутствии подписи сертификата центром сертификации или о несовпадении сертификата с кэшированным.

Данный вид атаки можно встретить в крупных организациях, использующих межсетевой экран Forefront TMG компании Microsoft. В данном случае «злоумышленник» находится на границе сети организации и производит подмену оригинального сертификата своим. Данная атака становится возможной благодаря возможности указать в качестве доверенного корневого центра сертификации сам Forefront TMG. Обычно подобная процедура внедрения проходит прозрачно для пользователя за счет работы корпоративных пользователей в среде Active Directory. Данное средство может использоваться как для контроля за передаваемой информацией, так и в целях похищения личных данных, передаваемых с помощью защищенного соединения HTTPS.

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

Атака отклика

Злоумышленник записывает коммуникационную сессию между сервером и клиентом. Позднее, он пытается установить соединение с сервером, воспроизводя записанные сообщения клиента. Но SSL отбивает эту атаку при помощи особого уникального идентификатора соединения (ИС). Конечно, теоретически третья сторона не в силах предсказать ИС, потому что он основан на наборе случайных событий. Однако, злоумышленник с большими ресурсами может записать большое количество сессий и попытаться подобрать «верную» сессию, основываясь на коде nonce, который послал сервер в сообщение Server_Hello. Но коды nonce SSL имеют, по меньшей мере, длину 128 бит, а значит, злоумышленнику необходимо записать кодов nonce, чтобы получить вероятность угадывания 50 %. Но достаточно большое число, что делает эти атаки бессмысленными.

Атака против протокола рукопожатия

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

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

Алгоритмы, использующиеся в SSL

• Для обмена ключами и проверки их подлинности применяются: RSA, Diffie-Hellman, ECDH, SRP, PSK.
• Для аутентификации: RSA, DSA, ECDSA.
• Для симметричного шифрования: RC2, RC4, IDEA, DES, Triple DES или AES, Camellia.
• Для хеш-функций: SHA, MD5, MD4 и MD2.

См. также

Ссылки

• Mozilla.org — введение в SSL протокол
• inSSL — ресурс про SSL

dic.academic.ru

что это и как работает, особенности и виды — Ringostat Blog

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

Что такое SSL

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

Есть 3 ключа, которые используются для шифрования соединений:

• открытый;
• закрытый;
• сеансовый.

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

Посмотреть SSL можно, кликнув мышью в поисковой строке на замке перед HTTPS.

Что тут важно:

• издатель;
• владелец;
• тип сертификата;
• срок действия.

Остальная информация носит технический характер.

Пару слов о терминологии. В данной статье под SSL я подразумеваю стандарт SSL, который был разработан компанией Netscape, и с января 1999 года IETF стандартизирует его под именем TLS. Как утверждается в TLS-документации, «разница между этим протоколом и SSL 3.0 некритична». SSL и TLS представляют собой постоянно обновляемую серию протоколов, и их часто в обиходе объединяют в общее название SSL/TLS.

 

HTTP и HTTPS

Для лучшего понимания, что такое SSL и какова разница между его типами, немного коснемся протоколов HTTP и HTTPS. Есть подробные технические описания и гайды, мы их приводить не будем. Для обычного пользователя ситуация выглядит вот так:

И

Многим владельцам сайтов непонятно, почему Google уже несколько лет досаждает рекомендациями перейти на HTTPS — HyperText Transfer Protocol Secure. Суть в том, что шифрованный протокол позволяет устанавливать относительно безопасное соединение между браузерами и сайтами. HTTPS значительно снижает вероятность взлома коммерческих данных — а значит и воровства ваших средств.

Вот краткое описание из search-консоли:

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

 

Почему SSL-сертификат — это важно

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

С 2014 года, когда Google включил протокол HTTPS в факторы ранжирования, SSL сертификаты стали must-have для любого коммерческого проекта. Так, эксперт Hubspot Сэм Кусиниц написал статью «Окончательное руководство по факторам рейтинга Google в 2019 году». Среди факторов продвижения, связанных с контентом, соцсетями и ссылками, характеристику «очень важно» получила безопасность домена. А она реализуется благодаря сертификатам SSL в протоколе HTTPS.

Больше года назад ведущий специалист moz.com доктор Питер Мейерс писал о том, что примерно 30% ТОПа выдачи Google — сайты с SSL. Теперь их количество более 80%.

Аналитик предполагает, что для этого есть несколько причин.

1. Google с 2014 года поднимает в выдаче сайты с SSL, потому что они более безопасные. Значение этого параметра среди общих факторов ранжирования увеличивается примерно два раза в году.
2. Само наличие сертификата положительно сказывается на поведенческом факторе. Пользователи не склонны делать интернет-заказы в незащищенных магазинах.
3. Владельцы успешных сайтов видят перспективы в таком «апдейте» и сами модернизируют ресурсы.

Плюсы SSL-сертификатов

В важности SSL-сертификата и работы сайта через HTTPS уже почти никто не сомневается. Но есть еще другой насущный вопрос — какие сертификаты лучше подходят для продвижения сайта и у кого их заказывать?

 

Виды SSL-сертификатов: плюсы и минусы

Есть три варианта, где можно взять сертификат:

• сделать собственный;
• заказать бесплатный;
• купить платный, коммерческий SSL.

Разберем каждый из видов подробнее.

 

Самоподписные SSL

Их также называют self-signed и создают в хостинговых сервисах типа Cpanel. Эта возможность есть у каждого владельца сайта. Мы не будем рассматривать технический аспект генерирования — нас интересуют особенности таких SSL.

 

Плюс

Это быстро и бесплатно.

 

Минус

Вы, наверное, видели такую картину — это и есть результат использования самоподписного сертификата:

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

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

 

Бесплатные сертификаты

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

• letsencrypt.org
• startssl.com
• buy.wosign.com/free/

 

Плюсы

1. На этих сайтах несложно получить SSL, и он не будет вызывать браузерную ошибку.
2. Компании, которые предоставляют сертификаты, зарекомендовали себя на рынке. Например, letsencrypt.org — имеет деловые связи с поисковиком Google, соцсетью Facebook и несколькими другими крупными корпорациями.

 

Минусы

1. Сертификат не подразумевает финансовых гарантий, то есть компенсаций при хакинге.
2. Срок действия всего 90 дней.
3. В letsencrypt и startssl используется технология идентификации SNI, с которой не работают большинство платежных систем. Для коммерции эти сертификаты непригодны.
4. Они подтверждают только то, что существует такое доменное имя. Никакой информации о владельцах не несут и обеспечивают минимальный уровень защиты.

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

 

Платные сертификаты

Купить SSL несложно, для этого нужно просто связаться с издателем и сделать заказ. Время регистрации составляет от нескольких часов до недели. Есть несколько основных типов платных сертификатов.

1. DV (Domain Validation) SSL — подтверждают только имя домена.
2. OV (Organization Validation) SSL — подтверждающие домен и компанию.
3. EV (Extended Validation) SSL — самые надежные с «зеленой строкой» и проверкой расширенного типа.
4. Сертификаты для нескольких доменов.

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

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

Популярные издатели сертификатов:

• Comodo;
• Symantec;
• DigiCert;
• GlobalSign.

Плюсы

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

1. Улучшение поведенческого фактора. Согласно недавнему исследованию HubSpot, до 85% пользователей не будут продолжать просмотр, если сайт не является безопасным. В январе 2017 года Google выпустил обновление, которое применяется только к сайтам, собирающим конфиденциальную информацию. Например, пароли или номера кредитных карт. Теперь речь идет о всех сайтах без HTTPS. Уведомление о небезопасности заметно увеличивает количество отказов, особенно если речь идет о финансовых рисках. Чтобы этого избежать, нужно использовать самый надежный сертификат — платный. 
2. Оптимизация платежей. На сайтах с бесплатными сертификатами совершать торговые операции сложно, потому что далеко не все системы платежей поддерживают их. Опять же растут отказы и это негативно сказывается на коммерческом SEO-продвижении.
3. Защита. Один из важных моментов — уровень шифрования. Платные сертификаты позволяют обеспечить ключи большей длины и с высокой степенью защиты. Чтобы расшифровать их, потребуются десятки лет. Google анализирует это и повышает сайт в выдаче.
4. Гарантии издателя от взлома сертификатов. Взломают реально или нет — другой вопрос, но если гарантия есть, то это успокаивает. В зависимости от издателя и типа SSL гарантии разнятся, например, взлом QuickSSL оценен в 10 000 у. е., что говорит о надежности компании.
5. Удобство. Не обязательно каждые 90 дней перерегистрировать сертификаты. Платные SSL нужно обновлять раз в год.

 

Минусы

1. На сертификат все-таки придется потратиться. Стоимость использования зависит от степени защиты и составляет от 20 до 500 у.е.
2. Регистрация дорогих сертификатов, где требуется юридическое подтверждение и документы, может занять немало времени.

 

Полезные сервисы при работе с SSL/TLS

1. SSL Shopper — этот ssl-чекер поможет понять, правильно ли установлен ssl-сертификат у вас на сайте.
2. SSL Server Test —  с помощью этого бесплатного сервиса вы сможете оценить уровень защищенности конфигурации SSL/TLS.

 

Выводы

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

Но есть и сложности.

1. Сразу после перехода на SSL и HTTPS отмечают временное падение позиций в выдаче.  
2. HTTPS более требователен к системе, поэтому может немного снизиться скорость загрузки сайта. Решается оптимизацией кода или увеличением серверных мощностей.
3. Нужно проводить ряд технических работ при переходе, что требует времени и ресурсов.

Если вы нашли ошибку — выделите её и нажмите Ctrl + Enter или нажмите сюда.

blog.ringostat.com