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

Содержание

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.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

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

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

Установка соединения 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

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

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

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

SSL. Безопасность передачи данных / Хабр

Как давно вы проверяли надежность своего SSL? Мало просто купить SSL сертификат и его установить, нужно его и настроить.

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

Тестирование конфигурации SSL

Проблемы связанные с версиями SSL протоколов:

SSL v2 небезопасен, устарел и не рекомендуется для использования. См. атаку DROWN по этому протоколу.

SSL v3 небезопасен и устаревший инструмент. См. атаку POODLE.

TLS v1.0 также является устаревшим протоколом, но на практике он все же оказывается необходим. Его основная слабость (BEAST) была смягчена в современных браузерах.

TLS v1.1 и TLS v1.2 оба не имеют известных проблем с безопасностью, но только v1.2 предоставляет современные криптографические алгоритмы.

SSL 2.0, SSL 3.0 и TLS 1.0 настоятельно рекомендуется отключить, так как большинство стандартов безопасности их уже давно не поддерживают (например, PCI DSS 3.1).

Рекомендуемые протоколы TLS v1.1 и TLS v1.2 с актуальными алгоритмами шифрование и снятия хэшей.

Анализ конфигурации SSL

Есть замечательный инструмент SSLLabs Test Tool для проверки тестирования надёжности конфигурации SSL.

A+ и А — это наилучший показатель конфигурация SSL. F — наихудший уровень.

Пример теста SSL для одного из наших сайтов продуктов

Ниже приведен еще один пример того, как быстро проверить уровень SSL-конфигурации с помощью инструмента nmap:

Надежные шифры

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

Этот ресурс предоставляет информацию о том, как настроить хорошие SSL-алгоритмы на Apache, nginx, HAProxy и т. д.

Конфигурация на Nginx

Ниже приведен пример конфигурации веб-серверов на nginx, которые повысили настройку SSL с уровня B до A + и повысили защиту системы:

Конфигурация на Windows

Windows Server 2016 и выше уже имеют конфигурацию SSL, которая соответствует действующим регламентам безопасности (например, SSL v2 и SSL v3 отключены).

В более ранних версиях Windows Servers (2008, 2012) SSL v3 все еще включен, т. е. Вам необходимо вручную отключить устаревшие протоколы. См. рекомендации Microsoft: как отключить PCT 1.0, SSL 2.0, SSL 3.0 или TLS 1.0

Мы используем инструмент IIS Crypto tool, который предоставляет графический интерфейс для отключения слабых шифров и устаревших протоколов. Это позволяет избежать опасной ручной работы с реестром Windows.

Использование SSLLabs Test Tool, его советов и функциональных возможностей позволяет быстро защитить SSL / TLS на Windows.

Реальный пример конфигурации SSL для Windows Server 2012 R2

Автор — Денис Колошко, CISSP

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 получил широкое применение в электронной почте.

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

Криптографическая безопасность: SSL устанавливает безопасное соединение между двумя сторонами.
Совместимость: Программисты, независимо друг от друга могут создавать приложения, использующие SSL, которые впоследствии будут способны успешно обмениваться криптографическими параметрами без всякого знания кода чужих программ.
Расширяемость: SSL стремится обеспечить рабочее пространство, в котором новые открытые ключи и трудоемкие методы шифрования могут быть включены по мере необходимости.
Относительная эффективность: работа протокола на основе 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 определяет следующие ошибки:

Unsupported_Certificate_Type_Error: такая ошибка возникает, когда клиент/сервер получает тип сертификата, который не поддерживается. Ошибка устранима (только для аутентификации клиента).
No_Cipher_Error: ошибка возникает, когда сервер не может найти размер ключа или шифр, который поддерживается также и клиентом. Ошибка неустранима.
Bad_Certificate_Error: такая ошибка возникает, когда сертификат считается принимающей стороной плохим. Это означает, что или некорректна подпись сертификата, или его значение некорректно. Ошибка устранима (только для аутентификации клиента).
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

типы, выбор, приемущества. / Хабр

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

Здесь я попытаюсь ответить на эти вопросы, рассмотрев:

Причемущества от наличия SSL вообще, и подписанного сертификата в частности.

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

Пути их получения.

Я не претендую за 100% верность данной статьи, она основана только на моем мнении и личном опыте 🙂

SSL — Secure Sockets Layer — стандарт передачи защифрованных данных через сеть. Касательно web-индустрии это протокол HTTPS.

О сертификатах вообще и зачем их нужно подписывать.

Для начала разберемся, что такое SSL-сертификат.

Здесь и далее речь пойдет приемущественно о web-сайтах. Вопросы SSL + FTP, Email, цифровых подписей исходного кода и пр. до поры оставим в стороне.

SSL-сертификат, это индивидуальная цифровая подпись вашего домена. Он может быть:

Самоподписанным. Это значит, что вы сами выдали себе сертификат, и сами его подписали.

Подписанный недоверенным центром сертификации. Это значит, что сертификат сайта проверен, но сам «проверяющий» доверия не удостоен.

Подписанный доверенным ЦС. Это значит, что данные сертификата проверены компанией, которая имеет на это право, они как минимум существуют.

Разберем их более подробно.

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

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

Сертификат, подписанный доверенным источником (как пример — Thawte или VerySign) подтверждает, что:

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

Компания, которую представляет сайт — действительно существует в жизни, а не в мыслях Васи из соседнего подъезда.

Данные этой компании проверены и зарегистрированы центром сертификации.

На доверенные сертификаты браузеры ошибку не выдают.

Но это технически. А теперь о том, что показывает доверенный сертификат посетителю вашего сайта.

Это действительно тот сайт, на который мы шли, а не дефейс или фишинг.

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

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

Компанию волнует защищенность информации и подтверждение своей подлинности.

Если что-то случится, эту компанию можно найти через сертификатора.

Многих пользователей (особенно зарубежных — наши пока к этому не привыкли) самоподписанный сертификат (или отсутствие SSL в вещах, касающихся услуг\финансов\privacy) может если и не отпугнуть, то поставить жирный минус в вашу пользу.

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

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

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

Типы сертификатов:

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

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

SGC SSL-сертификат. — Аналогично Instant SSL, но с поддержкой 40-битных расширений (актуально для старых ОС и браузеров). Выдается на 1 домен, либо wildcard (см. ниже).

Обычный Wildcard. — тоже самое, что и обычный сертификат, но выдается не на 1 домен, а на все поддомены корневого домена. Т.е. не только на domain.com, a и на www.domain.com, bill.domain.com и т.д. Стоит на порядок дороже.

EV (Extended Validation) сертификат. — сертификат расширенной проверки, доступен только юридическим лицам. Проверяется владение доменом, компания, нотариально заверенные переводы документов на английский язык, требует подтверждения данных третьей стороной. Позволяет установить на сайте картинку-подтверждение владением и отображается в браузерах как гарантированно доверенный (зеленым цветом), против желтого у обычных сертификатов. Стоит в 2-3 раза дороже обычного, регистрация занимает продолжительное время.

В браузере выглядит так:

EV Wildcard и EV SGC. — аналогично Wildcard и SGC, но с расширенной проверкой.

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

Extended Validation — для сайтов, связанных с финансами, услугами (интернет-банкинг, платежные системы, интернет-магазины и пр.).

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

Для чего нужен SSL-сертификат и как его подключить 🔒

15 марта 2019

2 414

Время чтения ≈ 8 минут

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

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

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

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

Протокол HTTPS значительно расширил возможности обеспечения безопасности данных HTTP.

Если на сайте установлен SSL, то все данные передаются по HTTPS — защищенному варианту протокола HTTP. Он зашифровывает данные пользователя и переправляет их владельцу сайта через транспортный протокол TCP. Другими словами, вся информация, передаваемая пользователем, скрыта шифрованием от третьих лиц: операторов, администраторов Wi-Fi и провайдеров.

Как работает SSL-протокол

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

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

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

Что внутри SSL-сертификата

SSL-сертификат может содержать следующую важную информацию:

домен площадки, на которую устанавливается сертификат;
название компании-владельца;
страну, город прописки компании;
срок действия SSL-сертификата;
информация о удостоверяющем центре.

Доверенные и недоверенные сертификаты

Главным источником SSL-сертификатов служат доверенные центры сертификации или удостоверяющие центры (Certification authority, CA). Это организации, имеющие неоспоримый авторитет на рынке IT-услуг и пользующиеся известным открытым криптографическим ключём. В браузерах их список обычно можно посмотреть в разделе «Доверенные корневые центры сертификации».

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

SSL-сертификат от крупного центра — не всегда гарантия отсутствия проблем для сайта.

К недоверенным подписям относятся:

Самоподписанный сертификат, который владелец сайта выдает себе сам. Он также обеспечивает безопасность соединения, но при этом не является гарантией подлинности компании. В этом случае браузер будет предупреждать посетителя, что SSL не надежен.
Сертификат, который подписан недоверенным центром. В этом случае ресурс будет считаться проверенным, однако «проверяющий» остается под сомнением. Обычно такие центры продают сертификаты абсолютно всем, не проверяя подлинность фирмы.
Цифровая подпись, выданная центром, который потерял доверие. К этому разряду относятся, например, SSL-сертификаты от удостоверяющего центра Symantec, которую Google обвинил в выдаче большого числа неликвидных сертификатов. В браузере Google Chrome 70 была прекращена поддержка сертификатов, выпущенных этой компаний и аффилированными с ней центрами GeoTrust и Thawte до 1 декабря 2017 года.

SSL сертификаты Eternalhost — выгодный способ получить электронную цифровую подпись от 100% надёжного Удостоверяющего Центра.

Кому не обойтись без SSL-сертификата

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

Для SEO-специалистов, которые учитывают малейшие аспекты продвижения, также рекомендуется подключение подписи. Хотя на данный момент этот фактор слабо влияет на ранжирование страниц.

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

Типы SSL-сертификатов

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

DV (Domain Validation) — это подтверждение домена. Также он кодирует данные для их передачи с использованием HTTPS. Он доступен не только для юридических, но и физических лиц и устанавливается, как правило, в течение трех часов.
OV (Organization Validation) — помимо защиты данных он является гарантией подлинности компании, которой принадлежит. Выдается организациям, подтверждающим свой контактный номер, в течение трех дней.
EV (Extended Validation) похож на предыдущий вариант, однако проверке подлежат не только коммерческая деятельность фирмы, но и налоговая. Наличие сертификата с расширенной проверкой подтверждает «зелёная» адресная строка — выделение адреса дополнительной зелёной рамкой (Green Bar). Такой сертификат можно получить за 5 дней.

Зелёный замочек в адресной строке — сайту можно доверять.

Помимо этого, существуют дополнительные типы SSL:

Wildcard SSL — понадобится для того, чтобы защитить большое количество субдоменных имен в корне одного домена.
UC (Unified Communications) или SAN (Subject Alternative Name) — способен взять под свою защиту не только множество субдоменов, но и доменов как внешних, так и внутренних.
SGC (Server-Gated Cryptography) — поддерживает 40-битные расширения, что пригодится для операционных систем и браузеров старого образца.
CS (CodeSigning) — сертификаты для программных продуктов, которые позволяет пользователю безопасно скачивать ПО с сайтов разработчиков.

Выбор цифровой подписи

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

Для компаний дело обстоит несколько сложнее:

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

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

Чтобы получить цифровую подпись, необходимо зайти на сайт центра сертификации и предоставить необходимую информацию для данного типа цифровой подписи. Например, для получения DV SSL достаточно предоставить доменное имя, email и номер телефона. Для других разновидностей могут понадобится документы, которые подтверждают наличие юридического лица: ИНН, сведения из ЕГРЮЛ и прочее.

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

Приватный ключ SSL-сертификата выглядит именно так.

В архиве обычно содержаться три файла – приватный и публичный ключи, а также цепочка SSL-сертификатов (CA Bundle), которая нужна для повышения доверия к ресурсу. Далее можно подключить SSL-сертификат через панель управления хостингом или сервером. После этого меняем протокол с HTTP на HTTPS, путём настраивания редиректа.

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

Заключение

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

Оцените материал:

[Всего голосов: 2 Средний: 5/5]

Семь шагов к шифрованию SSL | Windows IT Pro/RE

Как установить и настроить автоматическое шифрование в SQL Server 2000 на кластере.

Стараясь обеспечить максимальную безопасность пользовательских данных, разработчики Microsoft ввели в SQL Server 2000 несколько новых функций. Одна из таких функций — поддержка автоматического шифрования сетевого трафика между клиентами и сервером на основе протокола Secure Sockets Layer (SSL). Из-за шифрования происходит небольшой спад производительности, поскольку оно требует дополнительных действий на обоих концах сетевого соединения. Однако для пользователей, придающих особое значение безопасности своих сетей, преимущества шифрования перевешивают некоторое ухудшение производительности. Особенно полезно шифрование в том случае, когда клиенты соединены с SQL Server через Internet.

Шифрование SSL обрело статус промышленного стандарта — этот тип шифрования используется большинством компаний для Internet-приложений и приложений электронной коммерции. Два уровня шифрования SSL, 40-разрядное и 128-разрядное, представляют различные типы защиты данных. SQL Server 2000 поддерживает оба уровня. Ввести в действие шифрование SSL можно, только получив действительный ключ (или сертификат) от доверенного центра сертификатов (Certificate Authority, CA). После того как на компьютер с SQL Server 2000 установлен сертификат, у пользователя появляется возможность настроить SQL Server на усиленное шифрование между клиентами и сервером. Windows 2000 выпускается с собственным центром сертификатов CA, который можно использовать в работе приложений внутри сети предприятия. Для Internet-приложений большинство компаний использует CA от независимых поставщиков. Дополнительную информацию о CA можно найти во врезке «CA — основные понятия».

Шифрование SSL отличается от шифрования Multiprotocol Net-Library, которое реализовано в версиях, предшествующих SQL Server 2000. Шифрование SSL поддерживает все сетевые библиотеки и протоколы, включая самые популярные типы — TCP/IP и Named Pipes (в кластерных средах доступны только эти две сетевые библиотеки). Кроме того, шифрование SSL применимо для множественных экземпляров SQL Server, тогда как шифрование Multiprotocol Net-Library, которое использует API-интерфейс RPC-механизма вызова шифрования в Windows, распознает только устанавливаемый по умолчанию экземпляр SQL Server 2000. Шифрование SSL может запрашиваться либо клиентом, либо сервером (но не тем и другим одновременно). Шифрование по запросу клиента означает, что все данные, предназначенные для отправки с этого клиента на все подключенные серверы, будут шифроваться. Шифрование по запросу сервера означает, что все данные, предназначенные для отправки на сервер, будут шифроваться, а затем расшифровываться на сервере.

Выполнить настройку шифрования на кластере значительно сложнее, чем на одиночном сервере. Узнать, как настроить шифрование SSL на отдельной машине, несложно, а вот найти информацию о настройке шифрования SSL на кластере труднее. К сожалению, в библиотеке Books Online (BOL) по SQL Server содержится мало сведений о том, как конфигурировать шифрование SSL, и лишь вскользь упоминается о требованиях к настройке для кластерной среды. За пределами BOL также придется искать информацию о том, как правильно настроить сертификаты для аутентификации. С другой стороны, при наличии четких инструкций процедура настройки шифрования SSL проста и не требует изобретательности. Ниже я подробно расскажу о том, как можно было бы настроить шифрование SSL на кластере в некой компании IDM.

Условия

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

Чтобы создать кластер, в компании должна быть установлена служба Microsoft Cluster на каждом компьютере или узле. Все узлы должы работать или под Windows 2000 Datacenter Server, или под Windows 2000 Advanced Server, или под Windows NT 4.0 Enterprise Edition. Если требуется добиться высокого уровня доступности данных, то эффективное решение этой задачи обеспечит именно кластерная среда. При сбое кластеры в состоянии сократить время простоя системы до 1-2 мин. Информацию о конфигурации серверных кластеров можно найти в разделе «Creating a Failover Cluster» в BOL по SQL Server 2000.

Пусть в IDM имеется два хост-компьютера с базами данных SQL Server: idmdb1 и idmdb2. Оба компьютера работают под Windows 2000 AS Service Pack 2 (SP2), и у них одинаковая конфигурация аппаратного обеспечения. Они входят в состав домена tiga.tld и являются членами кластера MyCluster. Служба Cluster установлена на обеих машинах. Неименованный по умолчанию виртуальный экземпляр SQL Server 2000 Enterprise Edition устанавливается на MyCluster с названием idmsql. Виртуальный сервер — это параметр по умолчанию при установке SQL Server на кластере. Служба MSSQLServer запускается от имени учетной записи tigasqlsvc, которая входит в пользовательскую группу Administrators на каждом узле. Выделенный сервер сертификатов (CA) с именем TIGA2 установлен в домене tiga на PDC tiga-dc-01.

Настройка SSL

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

Шаг 1: регистрация. При регистрации в системе на узле idmdb1 нужно указать пользовательское имя tigasqlsvc. Затем необходимо ввести пароль для регистрации в системе.

Шаг 2:запрос сертификата на полное имя виртуального сервера. Для того чтобы включить шифрование SSL, необходимо обеспечить сервер и клиентов цифровым сертификатом от доверенного корневого CA. В IDM имя виртуального сервера idmsql.tiga.tld. Чтобы создать запрос на получение сертификата, следует запустить Internet Explorer (IE) и ввести в поле адресов URL сайта выдачи сертификатов (CA) домена. В IDM используется адрес http://tiga-dc-01/certsrv. Certsrv.exe — это программа Windows, запускающая службу Microsoft Certificate Service. На Экране 1 показана первая страница сайта. Нужно выбрать параметр Request a certificate («Запросить сертификат») и щелкнуть Next. На следующей странице следует выбрать параметр Advanced request и снова щелкнуть Next. На странице Advanced Certificate Requests, изображенной на Экране 2, выбираем параметр по умолчанию Submit a certificate request to this CA using a form («При создании запроса на сертификат к этому CA использовать форму») и нажимаем Next. На следующей странице в текстовом поле Name следует ввести полное сетевое имя виртуального сервера SQL Server (не забывая, что это не имя кластерного узла, в котором выполнялась регистрация в системе). На Экране 3 показано имя SQL Server компании IDM — idmsql.tiga.tld. Необходимо убедиться, что в поле Intended Purpose выбран параметр Client Authentication Certificate. Если используется внутренний сервер сертификатов, то в поле Intended Purpose следует выбрать Web Server для вывода экранной формы и указания полного сетевого имени SQL Server.

Окно Advanced Certificate Requests также позволяет указать различные параметры шифрования и сертификации, такие, как провайдер шифрования и размер кода. Для компании IDM мы сохраняем все значения по умолчанию. Завершив выбор параметров, нужно щелкнуть Submit, что будет означать отправку запроса на сервер сертификатов. Затем система выдаст уведомление, что CA получил запрос на сертификат и что следует подождать, пока сетевой администратор не пришлет сертификат. Тем временем можно обратиться к администратору и попросить его заняться запросом.

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

Шаг 3: обработка запроса и выдача сертификата. Некоторые администраторы баз данных обладают правами управления CA, особенно если CA установлен на основном контроллере PDC. Как правило, приходится ждать, пока сетевой администратор обрабатывает запрос. Но если у пользователя имеются полномочия сетевого администратора, он может обработать запрос на сертификат самостоятельно. Сначала нужно зарегистрироваться на том сервере, где установлен CA и открыть Start, Programs, Administrative Tools, Certification Authority. В оснастке Certification Authority консоли Microsoft Management Console (MMC) следует раскрыть узел Pending Requests («Отложенные запросы»), найти запрос, который только что был отправлен, щелкнуть правой кнопкой по запросу и выбрать All Tasks, Issue, как показано на Экране 4. Чтобы убедиться в успешности операции, нужно раскрыть узел Issued Certificates («Выданные сертификаты») и отыскать свой сертификат.

Шаг 4: установка сертификата. После подтверждения о выдаче сертификата от сетевого администратора или самостоятельного получения сертификата, нужно вернуться на Web-страницу CA (http://tiga-dc-01/certsrv). В окне приветствия, изображенном на Экране 1, следует выбрать параметр Check on a pending certificate и щелкнуть Next. На следующей странице необходимо выбрать в списке свой сертификат и нажать Next. В окне Certificate Issued (которое появится почти сразу после выполнения шага 2, если имеется внутренний CA) нужно щелкнуть параметр Install this certificate. Следующая страница будет содержать подтверждение, что сертификат успешно установлен.

Шаг 5: проверка сертификата. Для проверки корректной установки сертификата на компьютере требуется щелкнуть правой кнопкой по значку IE на настольном компьютере и выбрать Properties. Затем следует перейти на вкладку Content и щелкнуть Certificates. Если сертификат, который только что был установлен, есть в списке, можно включить шифрование SSL. Необходимо убедиться, что в поле Issued To указан полный сетевой адрес SQL Server (idmsql.tiga.tld — в этом случае). Нужно выбрать свой сертификат и щелкнуть View. В нижней части окна должно быть сказано, что статус этого сертификата «OK» (см. Экран 5).

Экран 5. Проверка полного имени и статуса сертификата.

Если используется некластеризованный SQL Server, то при выдаче сертификата серверу указывается его полное доменное имя. В этом примере, в компании IDM, полное имя компьютера было бы idmdb1.tiga.tld. Остальная часть процедуры та же. Работая с SQL Server на кластере, следует повторить для каждого узла шаги с 1-го по 5-й.

Шаг 6: запрос на шифрование SSL для сервера. После успешной установки сертификатов на все узлы необходимо перейти на тот узел, который в данный момент владеет службой SQL Server, и выбрать Start, Programs, Microsoft SQL Server, Server Network Utility. Выбрав параметр Force protocol encryption, как показано на Экране 6, нужно щелкнуть OK. Эта функция включает шифрование всех входящих данных.

Шаг 7: перезапуск службы SQL Server для ввода шифрования в действие. Чтобы остановить службу SQL Server на кластере, следует перейти на любой узел и открыть Start, Programs, Administrative Tools, Cluster Administration. Затем требуется щелкнуть правой кнопкой по SQL Server в секции Active Resources и выбрать пункт Take Offline, как показано на Экране 7. Дождитесь завершения работы SQL Server и всех зависимых ресурсов (например, SQL Server Agent, Microsoft Search). Затем нужно снова щелкнуть правой кнопкой по SQL Server и Bring Online. Наконец, необходимо проверить, что служба SQL Server запущена, подключившись к ней через Query Analyzer. Далее следует просмотреть журнал ошибок и убедиться, что сервер не сделал никаких записей об ошибках во время запуска.

Шифрование SSL — последние приготовления

Чтобы определить, действительно ли шифрование SSL установлено, нужно проследить за взаимодействием между клиентом и SQL Server с помощью Network Monitor. Об установке Network Monitor можно прочитать в статье Microsoft «HOW TO: Install Network Monitor in Windows 2000» (Q243270, http://support.microsoft.com).

Кроме того, должны быть установлены последние пакеты исправлений. В Microsoft знают, что на кластере под Windows 2000 виртуальный SQL Server после настройки шифрования SSL может не запускаться. Ошибка исправлена в SQL Server 2000 SP2. Если поверх SQL Server не установлен пакет SP2, то для успешного перезапуска службы после настройки протокола шифрования следует обеспечить наличие учетной записи службы SQL Server в составе группы Administrators (как в приведенном примере).

Процедуру, подобную описанной в этой статье, можно использовать для включения шифрования на отдельном клиенте, но тогда придется задействовать Client Network Utility вместо Server Network Utility. Дополнительную информацию о применении шифрования SSL на клиенте можно найти в статье Microsoft «HOW TO: Enable SSL encryption for SQL Server 2000 with Certificate Server» (Q276553, http://support.microsoft.com).

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

CA — основные понятия

Главное условие для включения шифрования SSL заключается в том, что сервер и клиенты должны иметь цифровой сертификат, полученный от доверенного корневого центра сертификатов Certificate Authority (CA). Сертификаты сервера и клиента должны быть выданы одним и тем же CA. Большинство систем Windows имеет службу Microsoft Certificate Services, установленную на PDC, но ничто не мешает воспользоваться подобной службой от независимого поставщика, например VeriSign. В примере статьи используется служба Microsoft Certificate Services, через нее выдаются сертификаты всем клиентам внутри компании.

Существует два главных типа CA: внутренний корневой CA и выделенный корневой CA. Выделенный CA не нуждается в службах Active Directory (AD), что делает его более популярным, поскольку многие небольшие и средние компании не используют AD. По умолчанию выделенный CA временно откладывает запросы на сертификаты, а затем обрабатывает их. Администратор CA должен ответить на каждый запрос на сертификат либо подтверждением о выдаче, либо отказом. Внутренний CA обрабатывает каждый запрос незамедлительно.

Для того чтобы послать запрос на сертификат, SQL Server должен быть запущен от имени доменной учетной записи, но не учетной записи LocalSystem по умолчанию. Чтобы убедиться, что используется правильная учетная запись, нужно щелкнуть правой кнопкой мыши по имени экземпляра SQL Server в Enterprise Manager, выбрать Properties и перейти на вкладку Security. Необходимо проверить, выбран ли параметр This account и верно ли указано имя доменной учетной записи.

Гарри Зайка — старший консультант Нью-Йоркского отделения Microsoft Consulting Services, работает с SQL Server более восьми лет. Имеет квалификацию MCDBA и MCSD. С ним можно связаться по адресу: [email protected].

Поделитесь материалом с коллегами и друзьями

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

Купить
Корзина

ПодобратьWhois

Регистрация
Войти

Все о SSL-криптографии | DigiCert.com

Все, что вы хотите знать о криптографии, лежащей в основе шифрования SSL

Фон

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

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

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

Не уверены, что понимаете основы SSL-сертификатов и технологии? Узнать о сертификатах SSL >>

Асимметричное шифрование

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

Асимметричные ключи обычно имеют длину 1024 или 2048 бит. Однако ключи меньше 2048 бит больше не считаются безопасными для использования. Для 2048-битных ключей достаточно уникальных кодов шифрования, поэтому мы не будем записывать здесь число (это 617 цифр). Хотя могут быть созданы более крупные ключи, возросшая вычислительная нагрузка настолько велика, что ключи размером более 2048 бит используются редко. Для сравнения: среднему компьютеру потребуется более 14 миллиардов лет, чтобы взломать 2048-битный сертификат.Узнать больше >>

Симметричное шифрование

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

Размеры симметричного ключа обычно составляют 128 или 256 бит — чем больше размер ключа, тем сложнее его взломать. Например, 128-битный ключ имеет 340 282 366 920 938 463 463 374 607 431 768 211 456 возможных кодов шифрования. Как вы понимаете, атака методом «грубой силы» (при которой злоумышленник пробует все возможные ключи, пока не
найти правильный) потребуется довольно много времени, чтобы сломать 128-битный ключ.

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

Что сильнее?

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

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

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

Как SSL использует как асимметричное, так и симметричное шифрование

Инфраструктура открытых ключей (PKI) — это набор оборудования, программного обеспечения,
люди, политики и процедуры, необходимые для создания,
управлять, распространять, использовать, хранить и отзывать цифровые сертификаты.PKI также связывает ключи с идентификаторами пользователей с помощью
Центр сертификации (CA). PKI использует гибридную криптосистему и
выигрывает от использования обоих типов шифрования. Например, в
SSL-соединение, SSL-сертификат сервера содержит
асимметричная пара открытого и закрытого ключей. Ключ сеанса, который
сервер и браузер создают во время установления связи SSL.
симметричный. Это объясняется далее на схеме ниже.

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

Алгоритмы шифрования с открытым ключом

Криптография с открытым ключом (асимметричная) использует шифрование
алгоритмы, такие как RSA и криптография на эллиптических кривых (ECC) для
создать открытый и закрытый ключи. Эти алгоритмы основаны
о неразрешимости * некоторых математических задач.

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

RSA

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

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

RSA означает Рон Ривест, Ади Шамир и Леонард Адлеман.
люди, которые впервые публично описали алгоритм в 1977 году.

ECC

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

Использование эллиптических кривых в криптографии было предложено как
Нил Коблиц и Виктор С. Миллер независимо друг от друга в 1985 году;
Алгоритмы ECC стали широко использоваться в 2004 году.

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

Алгоритмы шифрования с предварительным общим ключом

Шифрование с предварительным общим ключом (симметричное) использует такие алгоритмы, как Twofish, AES или Blowfish, для создания ключей — AES в настоящее время является наиболее популярным. Все эти алгоритмы шифрования относятся к
два типа: потоковые шифры и блочные шифры. Потоковые шифры применяют криптографический ключ и алгоритм к каждой двоичной цифре в потоке данных, по одному биту за раз. Блочные шифры применяют криптографический ключ и алгоритм к блоку данных (например, 64 последовательных бита) как к группе.Блочные шифры в настоящее время являются наиболее распространенным алгоритмом симметричного шифрования.

* Примечание: Проблемы, которые могут быть решены теоретически (например, за бесконечное время), но которые на практике требуют слишком много времени, чтобы их решения стали полезными, известны как неразрешимые проблемы.

128-битное шифрование SSL против 256-битного шифрования SSL

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

Обзор:

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

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

До появления стандарта Advanced Encryption Standard (AES) информация отправлялась через Интернет с использованием стандарта Data Encryption Standard (DES) , который был изобретен в 1970 году с размером ключа 56 бит.DES может быстро передавать большие объемы данных с высокой скоростью с помощью шифра с симметричным ключом. Когда о ключе узнало больше пользователей, они манипулировали им, и встал вопрос о безопасности. После DES использование открытого ключа стало популярным для шифрования, а затем появился гибрид двух ключевых систем. Также вступил в силу протокол SSL, который проложил путь онлайн-транзакциям.

Настало время беспроводной сети Интернет, которая требует еще более надежного уровня шифрования. С момента появления Интернета и электронной коммерции сила шифрования постоянно меняется, например, 40-битное, 56-битное, 128-битное, 192-битное и 256-битное шифрование.Причина изменения уровня шифрования заключается в обеспечении надежной защиты пользователей. Чем больше вы используете надежное шифрование, тем в большей степени ваша онлайн-информация будет оставаться в безопасности. Теперь, после обзора шифрования, давайте сосредоточимся на текущем стандарте шифрования под названием AES (Advanced Encryption Standard), на котором работает текущее шифрование.

AES (стандарт расширенного шифрования):

AES — это алгоритм блочного шифрования, используемый в качестве стандарта шифрования и объявленный NIST (Национальным институтом стандартов и технологий) в США.AES — одна из самых известных криптографий, используемых во всем мире. AES обычно используется в криптографии с симметричным ключом (и отправитель, и получатель используют один и тот же ключ). AES быстро и легко реализуется и требует меньше памяти, чем DES. AES основан на шифре Rijndael, который был разработан бельгийскими криптографами Джоан Дэемен и Винсент Риджмен, чье предложение было позже принято NIST. AES работает с фиксированным размером блока, например с 128-битным, 192-битным и 256-битным шифрованием. Причина внедрения более сильного ключа шифрования возникла после атаки грубой силы, которая произошла в 2006 году, сделав 56-битный ключ RC5 уязвимым.

Потребность в шифровании:

Ниже приведены некоторые ситуации, в которых необходимо надежное шифрование.

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

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

Почему стоит выбрать 256-битное шифрование?

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

С изменением времени безопасность должна иметь более надежное шифрование для защиты от сетевых атак.Хакеры постоянно занимаются взломом слабого или старого шифрования.
256-битное шифрование намного сильнее 128-битного. 256-битное шифрование обеспечивает более высокий уровень защиты. По мере развития технологий ожидается, что в какой-то момент отраслевому стандарту придется перейти на 256-битное шифрование для защиты уровня безопасных сокетов.
Большинство центров сертификации, которые обеспечивают безопасность SSL, в интересах своих клиентов перешли со 128-битного на 256-битное шифрование.Чем сильнее вы применяете шифрование, тем в большей безопасности ваши данные.
Ключ большего размера всегда имеет больше шансов остаться в безопасности. Использование AES с 256-битными ключами увеличивает количество раундов AES, которые необходимо выполнить для каждого блока данных, например 10 раундов для 128-битного и 14 раундов для 256-битного шифрования.
Он добавляет дополнительный уровень безопасности для пользователей. Имя пользователя и пароль будут в безопасности с 256-битным шифрованием. Проблема скорости для ISP будет решена с помощью 256-битного шифрования.56 лет.
С точки зрения ключа RSA, и если вы посмотрите на график выше, чем длиннее ключ RSA, тем больше времени потребуется для расшифровки. В последнее время 2048-битный ключ RSA поддерживает 256-битное шифрование, поэтому будет полезно иметь 256-битное шифрование и 2048-битный ключ RSA.

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

Похожие сообщения :