Содержание

Как установить и настроить протокол HTTPS на сайте

Мы увеличиваем посещаемость и позиции в выдаче. Вы получаете продажи и платите только за реальный результат, только за целевые переходы из поисковых систем

Мы выпустили новую книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».

Подпишись на рассылку и получи книгу в подарок!

Мир помешался на интернет-безопасности. Если вы в тренде и переписываетесь исключительно в «Телеграме», то почитайте про то, как установить на сайт  протокол защищенного соединения HTTPS. Он пригодится в любом случае, а если вы интернет-магазин, то без него вообще нельзя будет обойтись. Попутно расскжем про сертификаты  SSL: что это такое и для чего они нужны.

Что такое HTTPS

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

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

Он формирует уникальную цифровую подпись сайта, которая и помогает защитить соединение. Без сертификата SSL получить протокол HTTPS не получится, как ни старайся.  В нем содержится:

  • домен сайта;
  • полное юридическое название компании-владельца;
  • физический адрес компании;
  • срок действия сертификата;
  • реквизиты разработчика SSL.

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

Как выбрать SSL-сертификат

Они делятся на два типа, в зависимости от степени защиты и верификации.

Domain Validation SSL

Самый простой вариант. Заработает после того, как вы подвтердите владение доменом. Сделать это можно тремя способами:

  • Через E-mail. Вам на почту придет письмо с инструкцией по верификации. В качестве адреса отправки выбирается либо почта из Whois домена, либо ящики админа или вебмастера.
  • Через запись в DNS. Если у вас настроен сервер электронной почты, создайте специальную запись в DNS. По ней система и подтвердит, что вы действительно владелец сайта. Метод автоматизирован и подходит тем, у кого почта Whois скрыта в настройках.
  • Через хэш-файл. Разместите специальный .txt файл у себя на сервере, чтобы центр сертификации смог установить его наличие.

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

Business Validation

Этот вид сертификата SSL надежней, потому что вы подтверждаете факт связи компании с сайтом. Для этого нужно отправить в верификационный центр несколько документов и принять звонок на корпоративный номер. Business Validation-сертификаты делятся на 3 вида:

  • Extended Validation SSL. Это сертификаты с расширенной проверкой. Они нужны всем, кто работает с большим объемом денег: банкам, крупным интернет-магазинам, финансовым компаниям, платежным системам.
  • Wildcard SSL. Такой сертификат защищает и сам сайт, и его поддомены. Причем их может быть любое количество, а располагаться они могут на разных серверах. Обязателен, если вы используете поддомены с разной региональной привязкой или разными проектами.
  • SAN SSl. Главное преимущество этого типа сертификата – поддержка альтернативных доменных имен: и внешних, и внутренних.

Можно ли установать на свой сайт бесплатный SSL-сертификат?

Да. Большинство таких продуктов платные, но есть и варианты, за которые не придется отдавать деньги. Это базовые сертификаты с валидацией по домену. Они не позволят прикрутить к ресурсу онлайн-кассу, но защитить соединение пользователя с сервером смогут. Такие SSL подойдут небольшим информационным сайтам или офлайн-бизнесам. Пример – базовый сертификат StartSSL.

Установка сертификата SSL

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

В процессе генерации ключа CSR нужно указать:

  • Имя сервера: «site.com» или «*.site.com», если получаете WIldcard сертификат. Звездочка означает любое количество любых символов перед точкой.
  • Код страны: RU, UA, KZ и так далее.
  • Область, например, Saratov Region.
  • Город.
  • Полное название организации или имя владельца сайта.

Запрос CSR отправляется в центр верификации. На выходе вы получаете сертификат SSL и файл с приватным ключом, который нельзя терять и выкладывать в открытый доступ.

После этого нужно установить сертификат на веб-сервер. Рассмотрим случаи с Apache и nginx.

Apache

Чтобы это сделать, нужно загрузить на сервер все сертификаты: и основные, и промежуточные. Первым делом нужно последний в директорию /usr/local/ssl/crt (используется по умолчанию, в вашем случае может отличаться). В ней будут храниться все сертификаты.

После этого скачайте основной сертификат, откройте его в любом текстовом редакторе и полностью скопируйте содержимое вместе со строчками «BEGIN» и «END».

В директории /ssl/crt/ создайте файл vashsite.crt и вставьте в него содержимое сертификата.

Файл приватного ключа переместите в директорию /usr/local/ssl/private/

В файле VirtualHost добавьте строки:

Указывать нужно действительные пути до файлов. Сохраните изменения и перезапустите сервер.

nginx

Здесь процесс установки SSL сертификата немного отличается. Сначала нужно объеденить корневой, промежуточный и SSL-сертификаты в один. Для этого создайте файл vashsite.crt и вставьте туда содержимое сертификатов вместе со строчками «BEGIN» и «END» (порядок: SSL, промежуточный, корневой). Пустых строк быть не должно.

Почти то же самое нужно сделать и с приватным ключом – создать файл vashsite.key и перенести содержимое ключа, загруженного с сайта поставщика.

Оба файла (vashsite.crt и vashsite.key) поместите в директорию /etc/ssl/ (она используется по умолчанию, но может отличаться).

В файле с конфигурациями отредактируйте VirtualHost. Добавьте:

Если директория с сертификатом и ключом отличается от дефолтной, поменяйте ее.

Теперь сохраните изменения и перезапустите nginx.

Как получить рабочее HTTPS-соединение

После установки сертификатов SSL сайт станет доступен по двум адресам: http://vashsite.com и https://vashsite.com. Вам нужно оставить только последний. Для этого настройте файл robots.txt и сделайте 301-редирект со старого сайта.

В «robots» нужно обновить host. Пример: Host: https://vashsite.com. Для настройки редиректа нужно добавить в файл .htacsess строчки:

Теперь осталось сообщить об изменениях поисковикам. В «Вебмастере» «Яндекса» добавьте страницу с https и укажите ее как главное зеркало для старого сайта.

Итоги

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

semantica.in

Как сделать свой сайт надежным: переход на https и виды ssl-сертификатов с иллюстрациями и примерами сайтов | Битрикс

С ростом кибер-преступлений владельцам веб-сайтов крайне важно знать, как предоставить своим клиентам безопасное соединение. Кроме того, Google обещает к июлю 2018 года помечать все сайты, которые работают по протоколу HTTP, как “Незащищенные”. Чтобы пополнить ряды “Надежных” веб-сайтов, необходимо установить SSL-сертификат на свой сайт или интернет-магазин. Но прежде нужно разобраться в том, что такое SSL-сертификат, какие бывают виды сертификатов безопасности, в чем их отличие и как перевести свой сайт на HTTPS.

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

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

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

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

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


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

Сказано — показано.

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

Вывод:

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

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

SSL-сертификат защищает вашу конфиденциальную информацию, такую ​​как данные кредитной карты, имена пользователей и пароли. А также:

  • Изменяется статус ресурса в строке браузера, что повышает доверие пользователей

  • Увеличивается вероятность конверсии, так как пользователи уверены, что данные их карт не будут переданы третьим лицам

  • Google увеличивает позиции сайта или интернет-магазина в поисковой выдаче

Сертификат безопасности позволит вашему сайту или интернет-магазину предоставить вашим посетителям защищенное соединение, а также уверенность в том, что данные их кредитных карт и другие персональные данные не будут скомпрометированы. Кроме того, в блоге Google Chrome появилась новость о том, что к июлю 2018 года, с выходом Google Chrome версии 68, все сайты, которые работают по протоколу HTTP будут отмечаться как ненадежные (“Не защищено” в российском варианте)


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


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

Стандартный SSL-сертификат (Single Domain) — сертификат, который создается для защиты одного уникального домена или поддомена. При условии, что на сайте есть поддомены, которые тоже необходимо защитить шифрованием — такой SSL-сертификат не подойдет. Во всех остальных случаях, для защиты одного уникального доменного имени прекрасно справляется обычный SSL-сертификат.

Пример корректной работы Стандартного SSL-сертификата:

company.ru

Пример, при котором возникает ошибка и Стандартный SSL-сертификат не работает:

отдел1.company.ru

отдел2.company.ru

Вайлкард SSL-сертификат (Wildcard SSL)

WildCard SSL — сертификат безопасности, который сохранит вам деньги и время, так как он предоставляет защищенное соединение для основного домена и неограниченного количества поддоменов сайта. И нужно учитывать, что это все — один сертификат. Wildcard SSL работает по такому же принципу, что и обычный SSL-сертификат, позволяя вам предоставлять пользователям защищенное соединение между вашим сайтом и браузером вашего клиента. Отличие лишь в том, что один вайлдкард SSL покрывает все поддомены основного домена сайта. Для примера рассмотрим внедрение wildcard SSL на поддомены сайта *.example.ru:

moscow.example.ru

spb.example.ru

krasnodar.example.ru

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

Сертификат на несколько доменов (Multi-Domain SSL) — такой сертификат защищает несколько доменных имен. Один мультидоменный SSL-сертификат может предоставить защищенное соединение для 100 уникальных доменных имен, в том числе поддомены.

Примеры:

example.ru

otherexample.ru

mail.example.ru

another.example.net

Резюме

Google стимулирует сайты и интернет-магазины делать интернет безопаснее для рядовых пользователей. Чтобы пополнить ряды “Надежных” сайтов, перейти на HTTPS, повысить позиции вашего ресурса в поисковых системах, необходимо купить SSL-сертификат с установкой на вашем сайте.

NB: При покупке готового шаблона в комплекте с 1С-Битрикс: Бизнес — SSL-сертификат предоставляется в подарок.

www.redsign.ru

что должен знать каждый Web-разработчик / Habr

Как же все-таки работает HTTPS? Это вопрос, над которым я бился несколько дней в своем рабочем проекте.

Будучи Web-разработчиком, я понимал, что использование HTTPS для защиты пользовательских данных – это очень и очень хорошая идея, но у меня никогда не было кристального понимания, как HTTPS на самом деле устроен.

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

Трубопровод

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

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

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

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

• Для этого требуется больше вычислительных мощностей
• Передается больше данных
• Нельзя использовать кеширование

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

Transport Layer Security (TLS)

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

TLS — наследник SSL — это такой протокол, наиболее часто применяемый для обеспечения безопасного HTTP соединения (так называемого HTTPS). TLS расположен на уровень ниже протокола HTTP в модели OSI. Объясняя на пальцах, это означает, что в процессе выполнения запроса сперва происходят все “вещи”, связанные с TLS-соединением и уже потом, все что связано с HTTP-соединением.

TLS – гибридная криптографическая система. Это означает, что она использует несколько криптографических подходов, которые мы и рассмотрим далее:

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

Криптосистема с открытым ключом

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

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

Это означает, что если кто-нибудь находится между клиентом и сервером и наблюдает за соединением – он все равно не сможет узнать ни закрытый ключ клиента, ни закрытый ключ сервера, ни секретный ключ сессии.

Как это возможно? Математика!

Алгоритм Ди́ффи — Хе́ллмана

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

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

Немного математики…

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

Пусть Алиса и Боб – две стороны, осуществляющие обмен ключами по DH-алгоритму. Сперва они договариваются о некотором основании root (обычно маленьком числе, таком как 2,3 или 5 ) и об очень большом простом числе prime (больше чем 300 цифр). Оба значения пересылаются в открытом виде по каналу связи, без угрозы компрометировать соединение.

Напомним, что и у Алисы, и у Боба есть собственные закрытые ключи (из более чем 100 цифр), которые никогда не передаются по каналам связи.

По каналу связи же передается смесь mixture, полученная из закрытых ключей, а также значений prime и root.

Таким образом:
Alice’s mixture = (root ^ Alice’s Secret) % prime
Bob’s mixture = (root ^ Bob’s Secret) % prime
где % — остаток от деления

Таким образом, Алиса создает свою смесь mixture на основе утвержденных значений констант (root и prime), Боб делает то же самое. Как только они получили значения mixture друг друга, они производят дополнительные математические операции для получения закрытого ключа сессии. А именно:

Вычисления Алисы
(Bob’s mixture ^ Alice’s Secret) % prime

Вычисления Боба
(Alice’s mixture ^ Bob’s Secret) % prime

Результатом этих операций является одно и то же число, как для Алисы, так и для Боба, и это число и становится закрытым ключом на данную сессию. Обратите внимание, что ни одна из сторон не должна была пересылать свой закрытый ключ по каналу связи, и полученный секретный ключ так же не передавался по открытому соединению. Великолепно!

Для тех, кто меньше подкован в математическом плане, Wikipedia дает прекрасную картинку, объясняющую данный процесс на примере смешивания цветов:

Обратите внимание как начальный цвет (желтый) в итоге превращается в один и тот же “смешанный” цвет и у Боба, и у Алисы. Единственное, что передается по открытому каналу связи так это наполовину смешанные цвета, на самом деле бессмысленные для любого прослушивающего канал связи.

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

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

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

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

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

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

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

Но, на самом деле, что это за сертификат, и как он предоставляет нам безопасность?

Сертификаты

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

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

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

Чтобы сертификату доверял любой веб-браузер, он должен быть подписан аккредитованным удостоверяющим центром (центром сертификации, Certificate Authority, CA). CA – это компании, выполняющие ручную проверку, того что лицо, пытающееся получить сертификат, удовлетворяет следующим двум условиям:

1. является реально существующим;
2. имеет доступ к домену, сертификат для которого оно пытается получить.

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

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

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

Прочие вещи которые нужно знать о сертификатах

Расширенная валидация

В дополнение к обычным X.509 сертификатам, существуют Extended validation сертификаты, обеспечивающие более высокий уровень доверия. Выдавая такой сертификат, CA совершает еще больше проверок в отношении лица, получающего сертификат (обычно используя паспортные данные или счета).

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

Обслуживание множества веб-сайтов на одном сервере

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

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

По этой теме много данных есть в википедии, есть курс на Coursera. Отдельное спасибо ребятам из чата на security.stackexchange.com, которые отвечали на мои вопросы сегодня утром.

Примечания переводчика:

1)Спасибо хабраюзеру wowkin за отличную ссылку по теме (видео переведено и озвученно хабраюзером freetonik):

2) По результатам развернувшейся в коменатариях дискуссии (спасибо за участие хабраюзерам a5b, Foggy4 и Allen) дополняю основную статью следующей информацией:

По данным netcraft на базе свежего SSL survey (2.4 млн SSL сайтов, июнь 2013), большинство SSL соединений не используют Perfect forward secrecy алгоритмы: news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html

Особенно ситуация плоха в случае с IE (даже 10 версии), который поддерживает Диффи-Хеллмана только на эллиптических кривых (RSA и ECDSA сертификаты), либо классический Диффи-Хеллман с более редкими сертификатами DSS (DSA).
По подсчетам netcraft 99,7 % соединений с IE и по 66% — с Chrome, Opera и Firefox не будут использовать Диффи-Хеллмана.

На Hacker News в обсуждении это тоже заметили.

Also (and I made the same mistake in my talk…), yes, explaining DH is important, but now it kind of sounds like in TLS both sides figure out the master secret using DH (and, in your talk, specifically, regular DH, not EC-based DH), when in reality that depends on the ciphersuite, and the vast majority of TLS connections don’t work that way. From what I understand to be most TLS configurations in the wild, the pre-master secret is encrypted using the server’s public key. (RFC 5246: 7.4.7.1, 8.1.1)
это важно и интересно, но не все понимают что он в реальности применяется не так часто. В большинстве сеансов SSL и TLS действительно обмен ключей происходит путем их шифрования с помощью RSA.

habr.com

SSL сертификат и настройка https на сервере — Технический блог

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

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

Как перевести сайт на HTTS

Пять простых шагов как перевести свой сайт на HTTPS

  1. Получение SSL сертификата
  2. Установка сертификата на сервер
  3. Настройка сайта, отказ от HTTP ссылок
  4. Настройка веб-сервера
  5. Информирование поисковых систем

Где взять SSL сертификат для сайта

Сразу стоит определиться к какой категории относитесь вы и ваш сайт. Если вы выступаете как частное (физическое) лицо, то вам доступен лишь один вид сертификата: DV (Domain Validation). Он самый простой, выпуск его занимает минимальное время. Необходимо лишь подтвердить права владения доменным именем. Если вы представляете юридическое лицо, то вам доступны все типы сертификатов. Выбирайте любой в зависимости от потребностей вашего сайта. Но готовьтесь к тому, что проверка займет длительное время, а сам сертификат может дорого стоить.
Ранее я писал, где взять сертификат бесплатно. Этот вариант отлично подходит блогерам и владельцам персональных сайтов. Как получить такой бесплатный сертификат хорошо описано на Хабре в статье-инструкции Получаем бесплатный SSL сертификат.

Установка сертификата на сервер

Перед приобретением Ssl сертификата следует выяснить возможность его использования у себя на хостинге. Если у вас виртуальный хостинг, то настроить использование HTTPS может только поставщик услуг хостинга. Заранее выясните у него такую возможность. Если у вас сервер, не важно виртуальный или выделенный, то сертификат SSL гарантированно можно установить или использовать.

Помните, что сертификат вы получаете на домен (доменное имя), а устанавливать его надо на сервер (веб-сервер).

Установка зависит от вебсервера. Apache и NGINX настраиваются по разному. Вот неплохая инструкция как все сделать своими руками Ручная установка SSL сертификата.
Но если вы на хостинге используете панель управления VestaCP, то все заметно упрощается. Эта панель позволяет установить сертификат для вашего домена прямо из веб-интерфейса.

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

Настройка сайта, отказ от HTTP ссылок

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

Вполне возможно, что обратившись к своему сайту в первый раз по HTTPS протоколу вы увидите такую картину:

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

Что нужно сделать, чтобы устранить проблему открытого замка HTTPS:

  • Исправить все внутренние ссылки на использование протокола HTTPS
  • Если используете картинки с внешних ресурсов, которые не работают по HTTPS, то скопируйте изображения себе на сайт
  • Отказаться от внешних сервисов и систем которые не работают по HTTPS
  • Убрать все плагины которые работают только по HTTP

Как исправить все ссылки на сайте

Для начала следует принять за правило использовать все ссылки без указания протокола. Это решение я подсмотрел в коде вызова скрипта Google.Adsense. Если раньше ваши ссылки выглядели так http://domainname.tld/page1.htm, то теперь они должны выглядеть так //domainname.tld/page1.htm. Ссылки такого рода будут работать и по HTTP и по HTTPS.
Если ваш сайт использует для хранения данных MySQL, а таких большинство. То проще всего сделать дамп базы. Скачать его себе на компьютер. Так как дамп базы данных MySQL представляет собой обыкновенный текстовый файл, то можно с помощью обычного текстового редактора произвести замену внутренних адресов на вариант описанный выше. После чего дамп базы данных нужно залить на сервер обратно.
Также можно поступить и с внешними ссылками. Но только не ставьте принудительно протокол HTTPS, так как нет никакой гарантии, что внешний ресурс его поддерживает.

Картинки с внешних ресурсов

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

Внешние сервисы которые не поддерживают HTTPS

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

Плагины работающие по HTTP

На моем сайте оказалось два плагина которые никак не хотели работать по безопасному протоколу HTTPS. Пришлось от них отказаться. Кроме того я проверил весь HTML код сайта на предмет загрузки скриптов и прочего с внешних ресурсов. Многие на автомате заработали по безопасному протоколу. Так же вычистил кучу мусора и неиспользуемого кода.

После проведения всех вышеописанных процедур сайт полноценно заработал по протоколу HTTPS, и замок безопасности оставался закрытым при посещении всех страниц.

Настройка веб-сервера на использование HTTPS

Для поисковых систем сайты доступные по разным протоколам http://domainname.tld и https://domainname.tld — это совершенно разные сайты. Поэтому необходимо поисковому роботу указать, кто тут главный. Для это в файле robots.txt необходимо написать название сайта с явным указанием протокола:

Host: https://domainname.tld

Затем необходимо настроить принудительную переадресацию всех запросов на протокол HTTPS. Чтобы пользователь который набрал http://domainname.tld все равно попал на безопасную версию сайта https://domainname.tld.
Если вы используете вебсервер Apache, то можно поступить следующим образом, добавьте в файл .htaccess нижеследующий код:


RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Информирование поисковых систем об использовании протокола HTTPS

В панели для вебмастеров поисковых систем Яндекс и Google необходимо добавить и подтвердить новый сайт, указав версию https.

[pcenter][/pcenter]

Теперь у вас в списке сайтов будет две записи по сути об одном и том же сайте. Для Google дополнительных настроек больше делать не надо, достаточно присутствия 301 редиректа. А для Яндекса у сайта работающего по HTTP необходимо указать в качестве главного зеркала HTTPS версию сайта.

[pcenter][/pcenter]

Не забудьте для нового сайта указать файл Sitemap.xml.

Яндекс не гарантирует сохранение количества страниц сайта в поиске, его позиций или посещаемости в случае изменения главного зеркала.

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

Благодарности

При написании этой инструкции были использованы следующие источники

  1. https://devaka.ru/articles/moving-to-https
  2. http://habrahabr.ru/post/127643/
  3. http://ru.ispdoc.com/index.php/Ручная_установка_SSL_сертификата
  4. http://habrahabr.ru/post/165701/

Поделись этой страницей с друзьями!

moonback.ru

Как настроить https протокол на сайте. Пошаговое руководство.

Настройка протокола https для «чайников»

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

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

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

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

Подготовительный этап к переходу на https протокол

  1. Заменить все абсолютные ссылки в рамках внутренней перелинковки на относительные. Этот пункт желательно выполнить до того, как начать использовать протокол https, чтобы избежать неожиданных технических проблем с доступностью элементов веб-сайта и его переиндексацией поисковиками  после перехода.


     

  2. Исправить ссылки для вложений с медиа-контентом. Если контент находится на сторонних сайтах, то изменять в таких URL http на https следует только, если конечный веб-ресурс доступен по данному протоколу. Но если медиа-файлы расположены в пределах веб-сайта, то их адреса необходимо переделать на относительные по аналогии с обычными внутренними ссылками.
     
  3. Проверить и при необходимости исправить настройки подключения внешних скриптов. Если в скриптах используются абсолютные ссылки, в них также нужно сделать соответствующие изменения и прописать относительные пути.

 
Эти три этапа являются предварительной подготовкой и в основном являются самой затратной (с точки зрения временных ресурсов) статьей расходов при переходе на https протокол.

Основной этап настройки протокола https

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

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

    b) Extended Validation (EV). В этой категории находятся сертификаты с расширенной проверкой: помимо подтверждения прав доступа к домену, проверяется свидетельство о госрегистрации организации, наличие имени организации в данных Whois, совершаются проверочные звонки и т. д.
    При приобретении сертификата данного вида появляется возможность получить зеленую пометку в виде «замочка» с названием компании в адресной строке, что для большинства интернет-пользователей является символом надежности веб-сайта.

    c) Wildcard-сертификаты. Используются для поддоменов.

    d) Сертификаты, поддерживающие IDN. Используются для сайтов с доменом на кириллице.
     

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

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

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

  3. Проверить доступность веб-сайта. Убедитесь в том, что доступ к успешно настроенному сайту с протоколом https имеется по обоим вариантам: и с http, и с https в начале адреса. Теперь по умолчанию при вводе в адресную строку URL сайта с http должно происходить автоматическое перенаправление на защищенный протокол https.

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

Этап настройки сайта после перехода на https протокол

  1. Настроить 301 редирект. Чтобы не заниматься тратой времени, внося соответствующие команды в код каждой странички сайта, следует воспользоваться возможностью прописывания редиректа 301 в файле .htaccess с помощью модуля  mod_rewrite или же обратиться за соответствующей просьбой к техподдержке хостера.

     
  2. Найти и устранить ошибки. В процессе перехода сайта на https протокол невозможно уследить за всеми нюансами. Поэтому по завершению этого процесса следует убедиться в том, что доступны все страницы веб-сайта, ссылки на них работают корректно, медиа-вложения отображаются верно и находятся на своих местах.
     
  3. Уведомить поисковики о переходе на https протокол. Этот этап необходим для того, чтобы обезопасить свой веб-сайт от потери трафика из поисковиков.
    Используя Google Search Console, нужно добавить и указать в качестве главного зеркала новую версию сайта с протоколом https.

 
В Яндекс.Вебмастере в разделе настроек индексирования имеется функция «Переезд сайта», воспользовавшись которой нужно указать домен и поставить галочку «Добавить HTTPS».



 
На этом все. Остается только дождаться переиндексации сайта после перехода на https протокол. После этого в поисковых выдачах начнут отображаться URL его страниц с https.

На этом этапе возможны скачки в количестве загруженных в индекс поисковика страничек и занимаемым ими позициями. Но если все вышеперечисленные рекомендации были выполнены правильно, довольно скоро все должно вернуться к изначальным показателям (с допустимыми потерями в 2-3%).

Надеемся, после прочтения этого материала переход на https протокол перестанет Вам казаться чем-то чрезвычайно сложным.

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

 

seo-akademiya.com

Мигрируем на HTTPS / Habr

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

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

Для кого предназначена эта инструкция?

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

Если вы ещё не получили сертификаты – необходимо выбрать поставщика, и купить сертификат. Сейчас есть пара возможностей даже получить сертификаты бесплатно – например, их выдаёт контора RapidSSL. Кроме того, в 2015 году Mozilla обещают сделать бесплатную выдачу сертификатов.

Скопируйте полученные сертификаты на ваши фронтенд-сервера куда-нибудь в /etc/ssl (Linux / Unix) или в приемлемое место для IIS (Windows).

2: Включение HTTPS на сервере

Здесь надо определиться:

— либо использовать хостинг по IP, когда у каждого хоста свой IP
— либо отказаться от поддержки пользователей, которые используют IE на Windows XP или Android с версией менее 2.3

На большинстве сайтов настроен виртуальный хостинг, который работает с доменными именами (name-based) – это экономит IP-адреса и вообще более удобно. Проблема в том, что IE и древний Android не понимают Server Name Indication (SNI), а это критично для работы HTTPS при name-based хостинге.

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

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

Если у вас много хостов и поддоменов – кажды из них потребует установки подходящего сертификата. Для поддоменов лучше использовать сертификаты с маской типа *.domain.ru

В идеале, вам необходимо переадресовывать все запросы к HTTP на HTTPS и использовать Strict Transport Security (см. шаги 4 и 5)

После этого проверьте работу сайта с новыми настройками при помощи инструмента Qualys SSL Server Test. Добейтесь того, чтобы сайт заслуживал оценки A или A+.

3: Сделайте все внутренние ссылки относительными

Теперь, когда ваш сайт работает и на HTTP и на HTTPS, вам нужно добиться его работы вне зависимости от протокола. Может возникнуть проблема смешанных протоколов – когда на странице, которую грузят через HTTPS, указаны ресурсы, доступные по HTTP. В этом случае браузер предупредит пользователя, что защита, предоставляемая HTTPS, перестала работать на 100%.

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

Проблема эта решается заменой полных линков на относительные. Вместо такого:

<h2>Welcome To Example.com</h2>
<script src="http://example.com/jquery.js"></script>
<link rel="stylesheet" href="http://assets.example.com/style.css"/>
<img src="http://img.example.com/logo.png"/>
<p>Read this nice <a href="http://example.com/2014/12/24/">new post on cats!</a></p>
<p>Check out this <a href="http://foo.com/">other cool site.</a></p>

надо сделать такое:

<h2>Welcome To Example.com</h2>
<script src="//example.com/jquery.js"></script>
<link rel="stylesheet" href="//assets.example.com/style.css"/>
<img src="1450829848287066165294"/>
<p>Read this nice <a href="//example.com/2014/12/24/">new post on cats!</a></p>
<p>Check out this <a href="http://foo.com/">other cool site.</a></p>

или такое:

<h2>Welcome To Example.com</h2>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="//assets.example.com/style.css"/>
<img src="1450829848287066165294"/>
<p>Read this nice <a href="/2014/12/24/">new post on cats!</a></p>
<p>Check out this <a href="http://foo.com/">other cool site.</a></p>

Все линки должны быть относительными, и чем относительнее, тем лучше. По возможности надо убрать протокол (//example.com) или домен (/jquery.js).

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

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

Если в вашем сайте используются скрипты и другие ресурсы от третьих лиц, например CDN, jquery.com, у вас есть 2 варианта:

— также использовать URL без указания протокола
— скопируйте эти ресурсы к себе на сервер. Это в любом случае надёжнее

4: Переадресация с HTTP на HTTPS

Установите тег
<link rel="canonical" href="https://…"/>

на ваших страницах. Это поможет поисковым системам лучше ориентироваться у вас.

Большинство веб-серверов предлагают простые решения для редиректа. Инструкции для Apache и для nginx. Используйте код 301 (Moved Permanently).

5: Включите Strict Transport Security и Secure Cookies

На этом шаге вы уже ограничиваете доступ к сайту только для HTTPS. Strict Transport Security сообщает клиентам, что им надо соединяться с сайтом только по HTTPS, даже если ссылка идёт на http://. Это помогает против атак типа SSL Stripping и экономит время на переадресациях из четвёртого шага.

Убедитесь, что ваши TLS-настройки реально работают – например, сертификат не просрочен. На этом шаге любая ошибка будет блокировать доступ к сайту.

Включите HTTP Strict Transport Security посредством заголовка Strict-Transport-Security. На этой странице есть ссылки на инструкции для разных серверов.

Примечание: max-age измеряется в секундах. Начните с небольших величин и по мере роста уверенности в работе сайта увеличивайте их.

Для того, чтобы клиенты всегда отправляли куки по защищённому каналу, включите флаг Secure для куков. На этой странице есть инструкция для этого.

Проблемы с миграцией

Позиция в поисковой выдаче

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

Быстродействие

Когда сервер работает нормально, траты на TLS обычно малы. По поводу их оптимизации читайте High Performance Browser Networking by Ilya Grigorik и Ivan Ristic’s OpenSSL Cookbook и Bulletproof SSL And TLS.

В некоторых случаях TLS может увеличить быстродействие – это справедливо в случае использования HTTP/2.

Заголовки Referer

Клиентские программы не отправляют Referer, когда пользователи переходят по ссылкам с вашего HTTPS-сайта на другие HTTP-сайты. Если вам это не нравится:

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

Так как поисковики мигрируют на HTTPS, то вы скорее всего получите больше заголовков Referer, когда сами перейдёте на HTTPS.

Согласно HTTP RFC:

Клиент НЕ ДОЛЖЕН включать заголовок Referer в небезопасный HTTP-запрос, если ссылающаяся страница получена по безопасному протоколу.

Монетизация

Если на вашем сайте крутятся объявления рекламной сети, может возникнуть проблема –iframe с HTTP не будут работать на странице с HTTPS. Пока все рекламодатели не перейдут на HTTPS, операторы не могут перейти на HTTPS, не теряя рекламных доходов. Но пока операторы не мигрируют на HTTPS, у рекламодателей нет мотивации для миграции.

Рекламодатели должны хотя бы предлагать вариант своих сервисов с поддержкой HTTPS (достаточно дойти до 2 шага этой инструкции). Многие так и делают. Вам, возможно, придётся отложить 4-й шаг до тех пор, пока большинство из них не станут нормально поддерживать этот протокол.

habr.com

Почему подключение сайта не защищено в браузере?

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

Содержание:
  1. Суть проблемы.
  2. Как работают безопасные «HTTPS-сайты», помеченные индикатором «защищено»?
  3. Почему веб-сайты помечаются индикатором «Не защищено», если они не зашифрованы?
  4. Почему «Google» создал это изменение?

Суть проблемы

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

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

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

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

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

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

Сегодня мы остановимся на освещении популярного веб-браузера «Google Chrome», и рассмотрим его способ отображения сведений о сайтах.

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

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

Как работают безопасные «HTTPS-сайты», помеченные индикатором «защищено»

Когда вы посещаете веб-сайт, использующий шифрование «HTTPS», вы увидите знакомый значок зеленого замка и слово «Защищено» в адресной строке веб-браузера.

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

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

«HTTPS» также обеспечивает защиту от злоумышленников, имитирующих оригинальный веб-сайт. Например, если вы подключены к сети «Интернет» через общественную точку доступа «Wi-Fi» и открываете сайт «google.com», то серверы «Google» предоставят сертификат безопасности, действительный только для «google.com». Если бы «Google» просто бы использовал незашифрованное соединение «HTTP», то у пользователя не было бы возможности узнать, действительно ли он перешел на реальный веб-сайт «google.com» или перенаправлен на сайт интернет-мошенника, предназначенный для обмана и кражи личных и конфиденциальных данных пользователя. Например, зараженная вредоносная точка доступа «Wi-Fi» может перенаправлять пользователей на такие типы мошеннических веб-сайтов, пока они подключены к общественной точке доступа «Wi-Fi» (при использовании общественного «Wi-Fi» технически не происходит проверки идентификационных данных или сертификатов расширенной проверки «EV», но в любом случае, это лучше чем ничего).

Зашифрованное соединение «HTTPS» также предоставляет и другие преимущества. С «HTTPS» никто не может увидеть полный путь к веб-страницам, которые вы посещаете. Они могут видеть только основной адрес веб-сайта, к которому вы подключаетесь. Поэтому, если вы читаете о состоянии здоровья на странице, например «example.com/medical_condition», то даже ваш поставщик интернет-услуг будет видеть, что вы подключены к сайту «example.com», а не то, что читаете определенную страницу. Если вы посещаете «Википедию», то ваш «Интернет-провайдер» или кто-то еще сможет увидеть лишь то, что вы находитесь на главной странице домена «Википедия», а не конкретную страницу, которую вы читаете.

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

Почему веб-сайты помечаются индикатором «Не защищено», если они не зашифрованы

Раньше существовала определенная градация сайтов: сайты «HTTP» считались обычными сайтами, а сайты «HTTPS» – защищёнными. Теперь порядок индикации сайтов переходит на одну ступень вверх в вопросе защиты передачи данных. А именно, обычными становятся сайты «HTTPS», а раздел защищённых сайтов теперь отсутствует, ведь по умолчанию все обычные сайты принимаются как защищённые. Поэтому тот сайт, который не защищен сертификатом, не удовлетворяет принятым стандартам безопасности и требует более пристального внимания, которое выражается в отдельной индикации его, как незащищённого.

И сайты с протоколом «HTTP» теперь кажутся веб-браузеру более подозрительными. По этой причине в последнем обновлении «Google Chrome 68» присутствует индикатор «Не защищено» в адресной строке, когда вы посещаете незашифрованный сайт «HTTP» (ранее для обозначения сайтов с протоколом «HTTP» «Google» использовал обозначение кружка с латинской буквой «i» внутри). Если вы нажмете на индикатор «Не защищено», то браузер во всплывающем сообщении предупредит вас «Подключение к сайту не защищено».

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

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

Незашифрованный веб-сайт дополнительно уязвим для подделки. Если злоумышленник появится между вами и веб-сайтом, то он может изменять данные, которые веб-сайт отправляет вам, или изменять данные, которые вы отправляете на веб-сайт, выполняя «атаку посредника» (или атака «человек посередине»). Например, это может произойти, если вы используете общественную точку доступа «Wi-Fi». Оператор может шпионить за вами, отслеживать ваши действия, захватывать ваши личные данные или изменять содержимое веб-страницы прежде, чем вы достигнете ее. Например, злоумышленник может вставлять ссылки для загрузки вредоносных программ на легитимную страницу загрузки, если эта страница была соединена через «HTTP» вместо «HTTPS». Он может даже создать поддельный сайт-прокладку, который с точностью похож на оригинальный веб-сайт, если он не использует «HTTPS», и у вас не будет способа понять, что вы связаны с поддельным, а не с реальным, веб-сайтом.

Почему «Google» создал это изменение

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

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

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

Чтобы обеспечить конфиденциальность, безопасность и проверку подлинности, «Google» и другие захотели направить «Интернет» в сторону популяризации «HTTPS». Они используют для этого разные способы: протокол «HTTPS» теперь даже быстрее, чем «HTTP», благодаря новым технологиям, и владельцы сайтов могут получить бесплатные криптографические «SSL-сертификаты» для шифрования своих сайтов от публичного центра сертификации «Let’s Encrypt». «Google» предпочитает сайты, использующие «HTTPS», и сильнее продвигает их в результатах поисковой выдачи «Google», повышая их посещаемость и увеличивая их репутацию в глазах пользователей.

Согласно данным «Google», 75% веб-сайтов, посещенных пользователями в веб-браузере «Google Chrome» в операционной системе «Windows», использовали безопасное соединение «HTTPS». Поэтому пришло время принять за стандарт соединение «HTTPS» и начать предупреждать пользователей веб-сайтов о не защищенности соединения «HTTP».

Подводя промежуточный итог, можно утверждать, что критических изменений не произошло. «HTTP» протоколы имеют определенные уязвимости в защите при передаче данных, и мошенники могут ими воспользоваться для похищения конфиденциальной информации пользователя. «Google» и другие популярные компании призывают владельцев веб-сайтов переходить на современный вид протокола «HTTPS», принимая его за новый стандарт соединения, и предупреждая пользователей о протоколе «HTTP», как о незащищенном его виде. Переход на «HTTPS» сделает «Интернет» быстрее, благодаря применению новых технологий, и улучшит общую безопасность и конфиденциальность, а также повысит защищенность общественных точек доступа «Wi-Fi».

hetmanrecovery.com

No related posts.