Как установить SSL на хостинг

Для чего нужен SSL-сертификат для сайта?

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

Так что ответ на вопрос «Для чего нужен SSL-сертификат для сайта» — для того, чтобы обеспечить безопасное соединение между браузером клиента и сервером, и используется SSL-сертификат.

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

Как уже было сказано, SSL расшифровывается как “Secure Sockets Layer” (уровень защищенных сокетов). Именно этот протокол позволяет зашифровать данные, передающиеся между компьютером пользователя и веб-сайтом. И для работы именно этого протокола на сайте должен быть установлен SSL-сертификат.

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

Следующий вопрос, который может у вас возникнуть, — а так ли необходимо устанавливать SSL-сертификат на свой сайт? Ответ один — да, это абсолютно необходимый в данный момент элемент сайта.

BEAST: как работает атака на SSL 2.0/3.0 и TLS 1.0

Эта достаточно нашумевшая атака (ну, благодаря прессе, у неё статус “Конец Интернета Почти Вот-Вот”), на самом деле, устроена достаточно просто.
Суть в том, что во всех протоколах до TLS 1.1 вместо генерации нового случайного IV (для каждого нового TLS message), использовался последний блок предыдущего TLS message. BEAST пользуется этим, чтобы значительно упростить процесс атаки на ключ – в частности, получив доступ к сессии, он может значительно упростить себе процедуру перебора сессионного ключа, влияя на состав нового вектора инициализации. В TLS 1.1 халтурить перестали, поэтому данная атака там просто не работает.

Если попробовать рамочно описать алгоритм атаки, можно это сделать так.

• Пользователь инициирует SSL-сессию к ресурсу (например, к веб-серверу). В этой сессии он постоянно передаёт какой-то элемент (например, жмёт на кнопку Like). Ну т.е. сессия одна, а он ходит по сайтам и делает что-то, что сопровождается хотя бы частично совпадающим обменом данными.
• Например, предположим, что согласовался протокол AES-128 (заметьте – стойкость самого протокола не критична, я его выбрал просто для удобного примера). Его блок будет равняться 128 / 8 = 16 байт.
• Атакующий участвует в обмене трафиком так, что может добавлять свои данные перед данными пользователя. Вариантов много – например, доп.заголовок в HTTP, или модификация исходных данных на уровне источника. Суть в том, чтобы атакующий мог добавить свои данные так, чтобы получился блок “Добавленные_данные_известные_атакующему + нормальные_данные_неизвестные_атакующему”. Т.е. исходное в атаке – это MITM. Если вы думаете, что условий дофига и это всё малореально, просто представьте себе обычного пользователя, который игнорирует антивирус, потому как, к примеру, верит рекламе “В нашей ОС нет вирусов, т.к. у неё красивые скруглённые уголочки да и цена намекает, что качество ну просто обязано быть”, который хочет в онлайне что-нибудь оплатить по карте и видит успокаивающую надпись “Protected by SSL 2.0/3.0 128bit cipher”.
• Атакующий начинает работать. Он вкидывает такие блоки данных в поток, чтобы последним получился блок, у которого 15 байт – добавленные данные, а единственный оставшийся – секретные. После пробует тестово расшифровывать этот блок перебором – перебирать-то интересно, т.к. из 16 байт 15 известны. А подбор 2^8 – это уже очень перспективно, учитывая, что в случае выигрыша можно будет вскрыть всю сессию (ведь никто не мешает впрок отправлять куда-нибудь полный дамп сессии, а после, в случае успеха метода, расшифровать всё целиком).
• Вскрыли 1 байт? Теперь будем подгадывать так, чтобы наших байт в блоке было 14, плюс один известный, плюс один пока что неизвестный

Акционные предложения по получению SSL сертификата бесплатно

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

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

Вот ссылка на страницу акции.

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

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

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

Управляем настройками согласования SSL/TLS в браузерах

Internet Explorer

Если Вы дочитали до этого места и всё поняли, но не знаете, как включить TLS в IE, то это, по сути, уникальная ситуация. Но тем не менее. Для включения поддержки TLS старших версий необходимо зайти в меню Internet Options -> Advanced, там в списке промотать до раздела Security и сделать соответствующие изменения (как минимум отключить SSL 2.0 и включить TLS 1.1 и TLS 1.2, остальное – на усмотрение).

Google Chrome

У меня под рукой кроме IE только хром, но, как известно из фольклора, оно не браузер. Что хорошо подтверждается тем, что никакого TLS 1.1 и TLS 1.2 в доступной сейчас рабочей версии (14.0.835.137) нет. Т.е. можно сказать проще – на сегодняшний день, 2.10.2011, все поддерживаемые хромом виды безопасных соединений на основе SSL/TLS уязвимы для сентябрьской атаки и данный инструмент не имеет смысла использовать для, допустим, финансовых транзакций, онлайн-платежей и прочих security sensitive штук.

Opera

Поставил оперу 11.51. Пожалуй, тут лучше всех сделано – можно не только выставить нужные протоколы (доступен выбор из SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2), но и нужные комплекты алгоритмов. Делается это зайдя в меню, там – Settings -> Preferences -> Advanced -> Security -> Security Protocols -> Details.
Правда, сделано плохо, потому что при включенном варианте “TLS 1.0 + 1.1 + 1.2” согласовывать начинает с TLS 1.0. Специально перепроверил, плюс посмотрел через netmon – удивительно, реально начинает с 1.0, согласовывает и успокаивается. Т.е. если включить все эти 3 протокола в Internet Explorer, то на тестовых сайтах клиент будет определяться как “TLS 1.2 compatible”, а в случае оперы – “TLS 1.0”. Плохо, по сути перечеркивает всё преимущество тонкой настройки – т.е. ну поддерживает она 1.2, что с того-то, если согласовывать пробует 1.0 для начала. То есть или надо вручную выключать TLS 1.0 (тогда большинство публичных https-сайтов типа gmail или facebook отвалятся), или сидеть с уязвимой версией.

После таких “мелочей” люди удивляются, почему IE является корпоративным стандартом.

SSL и WebSphere Application Server

Хорошим примером реализации протокола SSL является его поддержка в IBM WebSphere Application Server. Система безопасности этого сервера имеет многоуровневую архитектуру, показанную на рисунке 2.

Рисунок 2. Многоуровневая безопасность WebSphere Application Server

Уровень сетевой безопасности обеспечивает аутентификацию на транспортном уровне, целостность и шифрование сообщений. Коммуникации между различными серверами WebSphere Application Server могут быть сконфигурированы на использование протоколов SSL и HTTPS. Для дополнительной защиты сообщений также можно использовать протоколы IP Security и VPN (Virtual Private Network — виртуальная частная сеть).

Протокол SSL обеспечивает безопасность на транспортном уровне: аутентификацию, целостность и конфиденциальность для безопасного соединения между клиентом и сервером в WebSphere Application Server. Этот протокол работает поверх TCP/IP и под прикладными протоколами, такими как HTTP, LDAP, IIOP, обеспечивая достоверность и секретность передаваемых данных. В зависимости от конфигурации SSL на клиенте и сервере могут быть установлены различные уровни достоверности, целостности данных и секретности

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

Некоторые функции безопасности, предоставляемые протоколом SSL:

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

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

Протокол SSL используется различными компонентами внутри WebSphere Application Server для обеспечения достоверности и конфиденциальности. К этим компонентам относятся: встроенный HTTP-транспорт, ORB и безопасный LDAP-клиент.

Реализация SSL, используемая в WebSphere Application Server, — это либо расширение для Java — IBM Java Secure Sockets Extension (IBM JSSE), либо IBM System SSL. Провайдер IBM JSSE содержит эталонную реализацию, поддерживающую протоколы SSL и TLS (Transport Layer Security — безопасность транспортного уровня) и API для интеграции. С провайдером IBM JSSE также поставляется стандартный провайдер, предоставляющий поддержку RSA для функциональности цифровой подписи из библиотеки JCA (Java Cryptography Architecture — Архитектура Шифрования для Java) для платформы Java 2, стандартные наборы шифров для SSL и TLS, менеджеров доверенных источников сертификатов и ключей, использующих технологию X509, и реализацию технологии PKCS12 для хранилища цифровых сертификатов JCA.

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

• Провайдер JSSE поддерживает хранение собственного сертификата и сертификатов издателя в файле ключей SSL, но он также поддерживает и отдельный файл, т.н. файл источников сертификатов (trust file). Этот файл может содержать только сертификаты источников. Можно поместить свои собственные сертификаты в файл ключей SSL, а сертификаты издателей — в trust-файл. Это может потребоваться, например, при наличии недорогого аппаратного криптографического устройства, у которого памяти достаточно только для хранения персонального сертификата. В этом случае файл ключей указывает на аппаратное устройство, а trust-файл указывает на файл на диске, содержащий все сертификаты издателей.
• Провайдер JSSE не распознает специальный формат файла ключей SSL, используемый плагином — файлы с расширением .kdb. Провайдер JSSE распознает только стандартные форматы файлов, такие как Java Key Store (JKS — хранилище ключей Java). Совместное использование файлов ключей SSL плагином и сервером приложений невозможно. Более того, для управления ключами сервера приложений и trust-файлами необходимо использовать различные реализации утилиты управления ключами.

Издержки TLS-рукопожатия

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

Рукопожатия до TLS 1.2 требовали много ресурсов и в больших масштабах могли серьёзно нагрузить сервер. Даже рукопожатия TLS 1.2 могут замедлить работу, если их происходит много в один момент времени. Аутентификация, шифрование и дешифрование — дорогие процессы.

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

Что такое SSL и TLS

SSL – (secure sockets layer – уровень защищённых сокетов) – набор правил с более безопасной связью, регламентирующих применение шифровальных (криптографических) преобразований и алгоритмов в информационных процессах.

TLS – (Transport Layer Security – безопасность транспортного уровня) – протокол, основанный на спецификации протокола SSL версии 3.0. Хотя имена SSL и TLS взаимозаменяемы, они всё-таки отличаются, так как каждое описывает другую версию протокола.

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

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

Публичный ключ не является секретным и он присутствует в запросе.

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

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

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

Более подробную информацию об уже установленном на сайте сертификате вы можете посмотреть с помощью специальных сервисов, таких как:

https://www.ssllabs.com/ssltest/index.html – он передоставит расширенную техническую информацию о сертификате.

https://cryptoreport.websecurity.symantec.com/checker/views/certCheck.jsp – проверит, насколько верно установлен сертификат.

Оглавление

• Краткая история вопроса – SSL
• Версии и преимущества TLS
  • Про TLS 1.0
  • Про TLS 1.1
  • Про TLS 1.2
  • Про TLS 1.2 и Windows XP SP3
  • Про TLS 1.2 и Windows 2003 SP2
• BEAST: как работает атака на SSL 2.0/3.0 и TLS 1.0
• Включаем TLS на Windows-системе
• Отключаем SSL на Windows-системе
• Закручиваем гайки: Включаем безопасное пересогласование TLS на Windows-системе
• Атака на SSL/TLS – THC-SSL-DOS
• Закручиваем гайки: настройки криптоалгоритмов на хосте
• Управляем настройками согласования SSL/TLS в браузерах
• Проверяем работу TLS 1.1 и 1.2
• Что делать, если у меня нет возможности включить TLS новых версий

Приступим.

Различия

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

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

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

Какие преимущества дает использование SSL?

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

В чем сложность этой задачи? Вопрос безопасности данных в среде Web-приложений, подобных среде Integrated Solutions Console, может показаться немного размытым для новичков, потому что безопасность ИТ сама по себе — крайне широкая область, охватывающая много различных аспектов в открытых коммуникационных сетях.

В следующих двух статьях этой серии будет представлена организация безопасности данных на основе SSL в среде, основанной на Integrated Solutions Console. Сначала мы рассмотрим настройку и включение SSL для Integrated Solutions Console 5.1 с использованием пустого, собственного и выпущенного издателем сертификатов, а потом разберем, как выполнить те же действия для Integrated Solutions Console 6.0.1.

Похожие темы

• SSL on ISC, Part 1: What is SSL and why should I care? (EN): оригинал статьи.
• Self-signed server certificate (EN): пошаговая инструкция по созданию собственного сертификата
• IBM Workplace Collaboration Services information center (EN): в этой статье объясняется, какие компоненты в различных Web-браузерах требуют подписанных проверенных сертификатов.
• WebSphere Application Server and IBMJSSE (EN) — на этой странице ресурса InfoCenter приведена дополнительная информация по SSL.
• Launch the ISC console thru Web Browser (EN): в этой статье показано, как запустить Integrated Solutions Console через Web-браузер после установки.(EN)
• Embed the Integrated Solutions Console installation (EN) (developerWorks, март 2005 г.): эта статья демонстрирует, как с помощью установщика встраивать Integrated Solutions Console в другие продукты.
• Дополнительная информация по Java, продуктам Tivoli и WebSphere products, Eclipse, безопасности а также безопасности имеется в соответствующих разделах сайтов developerWorks и alphaWorks.
• Скачайте версию Integrated Solutions Console и ознакомьтесь с дополнительной информацией об этом продукте в Autonomic Computing Toolkit.(EN)
• WebSphere Application Server 6.1 — это платформа для приложений на базе Java 2 Enterprise Edition и Web-сервисов. Кроме обычной версии, предлагаются также версия Express (включающая сервер приложений J2EE, примеры приложений, инструменты разработчика и мастера), а также бесплатная упрощенная версия Community Edition.(EN)

Обмен ключами RSA

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

Вот как это происходит:

1. Клиент и сервер обмениваются двумя простыми числами (x и y), которые называют случайными числами.
2. Клиент генерирует pre-master secret (a), а затем использует открытый ключ сервера для его шифрования и отправки на сервер.
3. Сервер расшифровывает pre-master secret с помощью соответствующего закрытого ключа. Теперь обе стороны имеют все три входных переменных и смешивают их с некоторыми псевдослучайными функциями (PRF) для создания мастер-ключа.
4. Обе стороны смешивают мастер-ключ с ещё большим количеством PRF и получают совпадающие сеансовые ключи.

Обмен ключами DH

Вот как работает ECDH:

1. Клиент и сервер обмениваются двумя простыми числами (x и y), которые называют случайными числами.
2. Одна сторона выбирает секретный номер, называемый pre-master secret (a), и вычисляет: xa mod y. Затем отправляет результат (A) другому участнику.
3. Другая сторона делает то же самое, выбирая свой собственный pre-master secret (b) и вычисляет xb mod y, а затем отправляет обратно своё значение (B).
4. Обе стороны заканчивают эту часть, принимая заданные значения и повторяя операцию. Один вычисляет ba mod y, другой вычисляет ab mod y.

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

Рукопожатие TLS 1.2 для DH

Теперь, когда мы узнали, чем DH отличается от RSA, посмотрим, как выглядит рукопожатие TLS 1.2 на основе DH.

Опять же, между этими двумя подходами существует множество сходств. Мы будем использовать ECDHE для обмена ключами и ECDSA для аутентификации.

1. Как и в случае с RSA, клиент начинает с сообщения «Client Hello», которое включает в себя список шифронаборов, а также случайное число клиента.
2. Сервер отвечает своим сообщением «Server Hello», которое включает в себя выбранный шифронабор и случайное число сервера.
3. Сервер отправляет свой SSL-сертификат. Как и при TLS-рукопожатии RSA клиент выполнит серию проверок подлинности сертификата, но, поскольку сам DH не может аутентифицировать сервер, необходим дополнительный механизм.
4. Чтобы провести аутентификацию, сервер берёт случайные числа клиента и сервера, а также параметр DH, который будет использоваться для вычисления сеансового ключа, и шифрует их с помощью своего закрытого ключа. Результат будет выполнять роль цифровой подписи: клиент использует открытый ключ для проверки подписи и того, что сервер является законным владельцем пары ключей, и ответит своим собственным параметром DH.
5. Сервер завершает эту фазу сообщением «Server Hello Done».
6. В отличие от RSA, клиенту не нужно отправлять pre-master secret на сервер с использованием асимметричного шифрования, вместо этого клиент и сервер используют параметры DH, которыми они обменялись ранее, чтобы получить pre-master secret. Затем каждый использует pre-master secret, который он только что рассчитал, для получения одинакового сеансового ключа.
7. Клиент отправляет сообщение «Change Cipher Spec», чтобы сообщить другой стороне о своём переходе на шифрование.
8. Клиент отправляет финальное сообщение «Finished», чтобы сообщить, что он завершил свою часть рукопожатия.
9. Аналогично, сервер отправляет сообщение «Change Cipher Spec».
10. Рукопожатие завершается сообщением «Finished» от сервера.

Влияет ли SSL/TLS на SEO?

Короткий ответ: да.

Google внёс изменения в свой алгоритм еще в 2014 году, чтобы определить приоритеты веб-сайтов, которые использовали SSL-сертификат, и с тех пор они продолжают уделять особое внимание сертификатам SSL. Они официально заявили, что сайты со статистикой SSL обойдут сайты без таковой, чтобы все остальные факторы были равны, и хотя защищённые сайты составляют только 1% результатов, 40% запросов возвращают хотя бы один защищённый SSL сайт на первую страницу

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

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

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

Настройка SSL-сертификата повлияет на производительность поисковой системы (англ) вашего сайта, но вы должны использовать его не только по этой причине. Вместо этого настройте SSL-сертификат, чтобы повысить доверие между вашими посетителями и улучшить SEO в качестве бонуса.