подключение безопасного протокола на системе UralCMS
В связи с требованиями к повышению уровня безопасности передачи данных, многие современные браузеры помечают соединение HTTP (используемое ранее практически на всех сайтах) как незащищенное, поэтому, многие пользователи могли получать уведомление о проблемах с онлайн-платежами и прочими действиями, связанными с передачей данных через браузер, например через форму регистрации, авторизации и многих других.
Защиту данных в HTTPS обеспечивает криптографический протокол SSL/TLS, который шифрует передаваемую информацию. По сути этот протокол является обёрткой для HTTP. Он обеспечивает шифрование данных и делает их недоступными для просмотра посторонними. Протокол SSL/TLS хорош тем, что позволяет двум незнакомым между собой участникам сети установить защищённое соединение через незащищённый канал.
Из описания HTTPS от Яндекс (подробнее: https://yandex.ru/blog/company/77455)
Переход с HTTP на HTTPS
Сайт на HTTP и HTTPS — это два разных сайта для поисковой системы, поэтому переезд с одного на другой протокол происходит по аналогии, как если бы Вы меняли одно доменное имя на другое.
Следовательно, чтобы процедура обновления прошла корректно, необходимо следовать нескольким несложным правилам в определенном порядке.
Подключить HTTPS в редакторе сайта:
1. В системе управления сайтом перейдите в раздел «Настройки и оформление» — «Настройки сайта».
2. На открывшейся странице спуститесь вниз и найдите блок «Настройка защищенного соединения HTTPS».
3. Установите «галочку» напротив параметра «Перевести сайт на https» и нажмите на кнопку «Применить».
Система управления сайтом запустит выпуск сертификата безопасности для Вашего сайта. Выпуск сертификата может занимать до 30 минут.
4. После успешного выпуска сертификата безопасности в разделе системы управления «Настройки и оформление» — «Настройки сайта» в блоке «Настройка защищенного соединения HTTPS» Вам станут доступны два новых параметра:
- Сделать протокол HTTPS основным для сайта;
- Включить перенаправление с HTTP на HTTPS.
Установите «галочки» напротив этих параметров и нажмите на кнопку «Применить».
Внесение изменений в файл robots.txt:
Для корректной работы сайта после перехода на защищенный протокол HTTPS необходимо внести изменения в файл robots.txt.
1. В системе управления сайтом перейдите в раздел «Настройки и оформление» — «Настройки поисковых систем» — «Изменение robots.txt».
2. На открывшейся странице Вам необходимо внести изменения в две строки файла robots.
txt:
- Вместо «Host: адрес_сайта» укажите «Host: https://адрес_сайта»
- Вместо «Sitemap: http://адрес_сайта/?sitemap.xml» укажите «Sitemap:
После внесения изменений нажмите на кнопку «Сохранить».
Правка контента и перенаправлений:
1. Дополнительно необходимо скорректировать адреса загруженных файлов в содержимом разделов. Иначе браузер продолжит отмечать отдельные страницы Вашего сайта как не полностью защищенные.
Скорректировать адреса необходимо для следующих файлов:
- картинки, размещенные в тексте раздела через визуальный редактор;
- файлы для скачивания, размещенные в тексте раздела через визуальный редактор;
Также следует проверить все ссылки, и если они имеют абсолютный адрес, например «http://адрес_сайта/название_страницы» — изменить на относительный: «/название_страницы» или оставив абсолютный, изменить протокол «
2. Проверьте и скорректируйте ранее созданные перенаправления (если были добавлены) в разделе «Настройки и оформление» — «Перенаправления».
Если адреса страниц в созданных Вами перенаправления содержат протокол http, Вам необходимо заменить его на безопасный протокол https.
Дополнительные рекомендации при подключении HTTPS:
1. Если Вы ранее добавляли сайт в Яндекс.Вебмастер активировать переезд сайта на HTTPS
В разделе «Индексирование — Переезд сайта» укажите домен вашего сайта и установите галочку «Добавить HTTPS», нажмите «Сохранить».
Если Вы не добавляли сайт в Яндекс.Вебмастер ранее, тогда Вы можете это сделать по инструкции — http://uralcms.ru/additional/webmaster/yandex/ сразу по новому протоколу, без необходимости переезда.
2. Вы можете добавить новый сайт на HTTPS не удаляя старый на HTTP в Search Console от Google.
На панели Search Console выберите «Ресурс с префиксом в URL», укажите домен вашего сайта, нажмите «Продолжить».
Если Вы не добавляли сайт в Search Console ранее, Вы можете это сделать по инструкции — http://uralcms.ru/additional/webmaster/google/ сразу по новому протоколу, без необходимости переезда.
3. Ожидать переиндексацию сайта в поисковых системах.
В зависимости от объема сайта, «переезд» сайта для поисковых систем (в результатах выдачи по запросам) — может занять от нескольких дней или недель — до нескольких месяцев.
Также, необходимо учесть, что при изменении основного домена — возможно кратковременное (в течение нескольких минут) несоответствие сертификатов от прежнего и нового доменных имен.
Для сайтов, установленных на автономных версиях системы управления — может потребоваться дополнительная настройка хостинга, покупка, установка и контроль продления сертификата.
Если после смены протокола, вы продолжаете получать предупреждение о незащищенном соединении, проверьте, что все домены, подключенные к Вашему сайту, ведут на Ваш сайт, в том числе домены с WWW.
Если при переходе по какому-либо домену не происходит переход на основной домен сайта с безопасным соединением — обратитесь в службу технической поддержки.
Если Вы сами управляете DNS записями домена — направьте домен с WWW аналогично домену без WWW, затем повторите попытку активации https.
Включение HTTPS на вашем веб-сервере—Portal for ArcGIS
Для обеспечения сетевой связи между ArcGIS Web Adaptor и ArcGIS Enterprise используйте протокол HTTPS.
Протокол HTTPS представляет собой стандартную технологию безопасности, которая используется для установления шифрованного соединения между веб-сервером и веб-клиентом. HTTPS позволяет безопасно обмениваться данными благодаря идентификации и проверки подлинности сервера, а также обеспечению конфиденциальности и целостности всех передаваемых данных. Поскольку HTTPS предотвращает перехват или взлом данных, отправляемых по сети, его необходимо использовать со всеми механизмами регистрации или аутентификации, а также во всех сетях, в которых происходит обмен конфиденциальной информацией.
Использование порта HTTPS по умолчанию 443 подходит для подавляющего большинства развертываний. В редких случаях, экземпляр ArcGIS Web Adaptor не может использовать порт 443 на своем веб-сервере из-за ограничений, принятых в организации. Если это применимо к вашей организации, см. Использование портов, не предлагаемых по умолчанию, для ArcGIS Web Adaptor портала, где описываются дополнительные шаги по настройке.
Для включения HTTPS на веб-сервере требуется сертификат сервера, содержащий открытый и персональный ключ. Каждый веб-сервер имеет свой собственный метод импорта или привязывания к сертификату в приемнике HTTPS.
Также убедитесь, что ваш веб-сервер настроен на игнорирование клиентских сертификатов для доступа к защищенным сервисам через HTTPS, если только не настроена аутентификация на веб-уровне через PKI.
Создание или получение сертификата сервера
Для создания HTTPS-соединения между ArcGIS Web Adaptor и организацией веб-серверу требуется сертификат сервера.
Сертификат – это цифровой файл, содержащий информацию об удостоверении веб-сервера. Он также содержит метод шифрования, который используется при создании защищенного канала между веб-сервером и организацией. Сертификат должен создаваться владельцем веб-сайта и иметь цифровую подпись. Существует три типа сертификатов – подписанные центром сертификации (ЦС), домена и самозаверенный – которые описываются ниже.
Сертификаты, подписанные центром сертификации (ЦС)
Сертификаты, подписанные независимым центром сертификации (ЦС), гарантируют клиентам, что идентичность веб-сайта была проверена. Центр сертификации обычно является доверенной третьей стороной, которая может подтвердить подлинность веб-сайта. Если веб-сайт заслуживает доверия, центр сертификации добавляет свою собственную цифровую подпись к самозаверенному сертификату этого веб-сайта. Это говорит веб-клиентам, что идентичность веб-сайта проверена.
Используйте сертификаты для производственных систем, подписанные ЦС, особенно если к вашей организации ArcGIS Enterprise будут иметь доступ пользователи за пределами вашей организации.
Когда вы используете сертификат, выпущенный известным центром сертификации, безопасная связь между сервером и веб-клиентом происходит автоматически, без каких-либо специальных действий со стороны администратора организации или клиентов, которые обращаются к нему. Когда вы используете сертификат, выпущенный известным центром сертификации, безопасная связь между сервером и веб-клиентом происходит автоматически, без каких-либо специальных действий со стороны администратора портала или клиентов, которые обращаются к нему.
Сертификаты домена
Если организация расположена за вашим брандмауэром, и вы не можете использовать сертификат, подписанный ЦС, используйте сертификат домена. Доменный сертификат – это внутренний сертификат, подписанный ЦС вашей организации. Использование сертификата домена помогает снизить стоимость выпуска сертификатов и упрощает развертывание сертификатов, поскольку сертификаты могут быть сгенерированы в вашей организации для доверительного внутреннего пользования.
Пользователи в вашем домене не столкнутся с неожиданным поведением или предупреждающими сообщениями, которые обычно связаны с самозаверенным сертификатом, поскольку веб-сайт был проверен с помощью сертификата домена. Однако сертификаты домена не проверяются внешним центром сертификации, а это означает, что пользователи, посещающие ваш сайт из-за пределов вашего домена, не смогут проверить подлинность вашего сертификата. Внешние пользователи увидят в веб-браузере сообщения об отсутствии доверия к сайту, пользователь может считать, что зашел на вредоносный сайт и уйти с него.
Создание доменного сертификата и включение HTTPS
Для успешного завершения мастера настройки ArcGIS Enterprise требуется, чтобы HTTPS был включен на веб-сервере на компьютере, на котором установлено базовое развертывание.
Если HTTPS не включен, мастер настройки не завершит работу, и вы получите следующее сообщение об ошибке:
URL-адрес веб-адаптера https://mymachine.mydomain.com/server не доступен.
Убедитесь, что для веб-сервера включена поддержка HTTPS. Инструкции по включению HTTPS см. в разделе справки Введение в ArcGIS Enterprise > ArcGIS Enterprise Builder > Планирование базового развертывания.
В большинстве случаев ваш IT-администратор даст вам сертификаты и привяжет их к HTTPS порту 443.
В 2017 году Google Chrome начал работать только с доверенными сертификатами с параметром Subject Alternative Name (SAN), которые не может быть настроен, если сертификат был создан в приложении IIS Manager.
Если вы используете IIS, и вам необходимо создать сертификат домена, см. Создать сертификат домена, где можно воспользоваться скриптом для запуска на вашем компьютере, который создаст соответствующий сертификат и встроит его в HTTPS порт 443.
Самозаверенные сертификаты
Сертификат, подписанный только владельцем веб-сайта, называется самозаверенным сертификатом. Самозаверенные сертификаты обычно используются на веб-сайтах, которые доступны только пользователям внутренней сети организации (LAN).
Если веб-сайт, использующий самозаверенный сертификат, находится вне вашей собственной сети, вы не сможете проверить, действительно ли сайт, выпустивший сертификат, представляет указанную в нем организацию. При работе с таким сайтом вы подвергаете риску вашу информацию, поскольку за ним могут стоять злоумышленники.
Создание самозаверенного сертификата не подходит для производственной среды, поскольку приводит к непредсказуемым результатам и неудобствам в работе для всех пользователей организации.
При настройке организации вы можете использовать самозаверенный сертификат для начального тестирования, чтобы проверить заданную конфигурацию. Однако если вы используете самозаверенный сертификат, во время тестирования вы увидите следующее:
- Вы получите предупреждения о том, что сайт не является доверенным, когда вы заходите в организацию из веб-браузера или настольного клиента.
При обнаружении самозаверенного сертификата веб-браузер обычно выдает предупреждение и просит подтвердить переход на сайт.
Если вы используете самозаверенный сертификат, многие браузеры предупреждают об этом с помощью значков или красного цвета в адресной строке. Ожидайте увидеть подобные предупреждения, если вы настроите организацию с использованием самозаверенного сертификата. - Вы не сможете открыть интегрированный сервис во вьюере карт, добавить защищенный элемент сервиса в организацию, войти в ArcGIS Server Manager на интегрированном сервере или подключиться к организации из ArcGIS for Office.
Чтобы разрешить вход из ArcGIS for Office, установите самозаверенный сертификат в хранилище сертификатов Доверенных корневых центров сертификации на компьютере с запущенным ArcGIS for Office.
- Вы можете столкнуться с неожиданным поведением при печати размещенных сервисов и доступе к организации из клиентских приложений.
Если вы используете самозаверенный сертификат, многие браузеры предупреждают об этом с помощью значков или красного цвета в адресной строке. Ожидайте увидеть подобные предупреждения, если вы настроите организацию с использованием самозаверенного сертификата.Внимание:
Выше приведен частичный список проблем, которые могут возникнуть при использовании самозаверенного сертификата.
Для полного тестирования и развертывания организации ArcGIS Enterprise рекомендуется использовать сертификат домена или сертификат, подписанный ЦС.
Создание приемника HTTPS
При создании HTTPS-приемника пользователю, управляющему веб-сервером, потребуется разрешение на доступ к сертификату сервера, используемому для TLS-коммуникаций на определенном порту. Если HTTP-приемник функционирует, но HTTPS недоступен, в журнале веб-сервера будет указана причина, по которой приемнику не удалось привязаться к порту.
Проверка вашего сайта
После получения или создания сертификата, привязанного к порту 443, настройте Web Adaptor для использования с порталом. Вы должны открыть страницу настройки ArcGIS Web Adaptor с использованием URL по протоколу HTTPS, например, https://webadaptorhost.domain.com/webadaptorname/webadaptor.
После настройки Web Adaptor проверьте правильность работы HTTPS, отправив HTTPS-запрос организации, например, https://webadaptorhost.domain.com/webadaptorname/home.
Если вы проводите тестирование с самозаверенным сертификатом, отключите предупреждения браузера о небезопасном подключении. Обычно это делается путем добавления в браузер исключения, разрешающего работать с сайтом, имеющим самозаверенный сертификат.
Отзыв по этому разделу?
Стандарт только для HTTPS. Введение в HTTPS
Ниже приведены некоторые часто задаваемые вопросы и ответы о HTTPS.
Для подробного ознакомления (техническое образование не требуется) ознакомьтесь с презентацией Университета DigitalGov, «Введение в HTTPS» , чтобы узнать, что такое HTTPS и как он защищает веб-службы и пользователей.
- Что делает HTTPS?
- Какую информацию защищает HTTPS?
- Какую информацию предоставляет HTTPS не защитить?
- Какое отношение HTTPS имеет к HTTP/2?
- Как переход на HTTPS влияет на поисковую оптимизацию (SEO)?
- Как сайт HTTPS может продолжать отправлять информацию о реферере на связанные сайты HTTP?
- Насколько сложно атаковать соединение HTTPS?
- Почему сегодня доменные имена не шифруются через HTTPS?
- Почему DNSSEC недостаточно хорош?
- Как HTTPS защищает от спуфинга DNS?
Что делает HTTPS?
При правильной настройке соединение HTTPS гарантирует три вещи:
- Конфиденциальность.
- Подлинность. Посетитель общается с «настоящим» веб-сайтом, а не с имитатором или через посредника.
- Целостность. Данные, передаваемые между посетителем и веб-сайтом, не были подделаны или изменены.
Простое HTTP-соединение можно легко отслеживать, изменять и олицетворять.
Какую информацию защищает HTTPS?
HTTPS шифрует почти всю информацию, передаваемую между клиентом и веб-службой.
Например, незашифрованный запрос HTTP раскрывает не только тело запроса, но и полный URL-адрес, строку запроса и различные заголовки HTTP о клиенте и запросе:
вещи:
То же самое для всех методов HTTP (GET, POST, PUT и т. д.). URL-адрес и параметры строки запроса зашифрованы, как и тела POST.
Какую информацию защищает протокол HTTPS
, а не ? Хотя HTTPS шифрует весь HTTP-запрос и ответ, разрешение DNS и настройка соединения могут раскрывать другую информацию, например полный домен или поддомен и исходный IP-адрес, как показано выше.
Кроме того, злоумышленники по-прежнему могут анализировать зашифрованный HTTPS-трафик на наличие информации о «побочном канале». Это может включать время, проведенное на сайте, или относительный размер пользовательского ввода.
Какое отношение HTTPS имеет к HTTP/2?
HTTP/2 (завершено в 2015 г.) — это обратно совместимое обновление HTTP/1.1 (завершено в 1999 г.), оптимизированное для современной сети.
HTTP/2 включает в себя множество функций, которые могут значительно повысить производительность веб-сайта и появились благодаря достижениям Google, продемонстрированным с помощью SPDY в 2009 году.
Хотя HTTP/2 не требует использования внедрил HTTP/2, реализовал только поддержку зашифрованных соединений, и ни один из основных браузеров не работает над поддержкой HTTP/2 через незашифрованные соединения.
Это означает, что на практике основные преимущества HTTP/2 в производительности в первую очередь требуют использования HTTPS.
Для получения дополнительной информации:
- Часто задаваемые вопросы рабочей группы HTTP/2
- RFC 7540, окончательная спецификация
- Состояние реализации HTTP/2, Марк Ноттингем (председатель рабочей группы)
Как переход на HTTPS влияет на поисковую оптимизацию (SEO)?
В целом, переход на HTTPS улучшает SEO и аналитику веб-сайта.
- По состоянию на август 2014 года Google использует HTTPS в качестве сигнала ранжирования, что может повысить рейтинг поиска.
- Переход на HTTPS улучшит аналитику веб-трафика, направляемого с веб-сайтов HTTPS, поскольку информация о реферере не передается с веб-сайтов HTTPS на веб-сайты HTTP.
Чтобы сделать миграцию как можно более плавной и избежать проблем с поисковой оптимизацией:
- Используйте правильное перенаправление 301 для перенаправления пользователей с
http://наhttps://. Не используйте переадресацию 302 , так как это может негативно повлиять на ранжирование в поиске. - Используйте элемент канонической ссылки (
https://.
Как сайт HTTPS может продолжать отправлять информацию о реферере на связанные сайты HTTP?
По умолчанию, когда пользователь находится на веб-сайте HTTPS и щелкает ссылку на веб-сайт HTTP, браузеры не отправляют Заголовок Referer на веб-сайт HTTP.
Это определено в спецификации HTTP 1.1 и предназначено для предотвращения раскрытия URL-адресов HTTPS, которые в противном случае оставались бы защищенными гарантиями HTTPS.
Однако это означает, что если веб-сайт перейдет на HTTPS, любые HTTP-сайты, на которые он ссылается, перестанут получать данные о реферере с веб-сайта HTTPS. Это может быть сдерживающим фактором для перехода на HTTPS, поскольку он лишает связанные HTTP-сайты аналитических данных и означает, что веб-сайт HTTPS не получит «кредит» за перенаправление трафика на связанные веб-сайты.
Владельцы веб-сайтов, которые хотят продолжать отправлять информацию об исходящих источниках перехода на связанные HTTP-сайты, могут использовать политику источников перехода , чтобы переопределить поведение браузера по умолчанию, сохранив при этом конфиденциальность URL-адресов HTTPS.
Для этого веб-сайты должны использовать политику происхождения при пересечении происхождения .
Это позволит поддерживающим браузерам отправлять только источник в качестве заголовка Referer . Эта ограниченная реферальная информация применяется, даже если оба сайта используют HTTPS.
Например, если пользователь находится на https://agency.gov/help/aids.html и щелкает ссылку на https://moreinformation.com , то если origin-when-cross-origin , браузер отправит HTTP-запрос на https://moreinformation.com с заголовком Referer https://agency.gov .
Самый простой способ установить эту политику — включить тег в тело веб-сайта HTTPS:
HTTP-заголовок Referrer-Policy также может использоваться в качестве альтернативного механизма доставки, но он не получил широкой поддержки в веб-браузерах (по состоянию на конец 2016 г.).
Веб-сайты не должны использовать политику unsafe-url , так как это приведет к тому, что URL-адреса HTTPS будут отображаться в сети через HTTP-соединение, что нарушает одну из важных гарантий конфиденциальности и безопасности HTTPS.
Насколько сложно атаковать соединение HTTPS?
Атаки на HTTPS-соединения обычно делятся на 3 категории:
- Компрометация качества HTTPS-соединения посредством криптоанализа или других недостатков протокола.
- Компрометация клиентского компьютера, например, путем установки вредоносного корневого сертификата в хранилище доверенных сертификатов системы или браузера.
- Получение «мошеннического» сертификата, которому доверяют основные браузеры, как правило, путем манипулирования или компрометации центра сертификации.
Все это возможно, но для большинства злоумышленников это очень сложно и требует значительных затрат. Важно отметить, что все они представляют собой целевых атак , и их невозможно выполнить против любого пользователя, подключающегося к любому веб-сайту.
Напротив, обычные HTTP-соединения могут быть легко перехвачены и изменены любым участником сетевого соединения, поэтому атаки могут выполняться в больших масштабах и с низкими затратами.
В первую очередь для поддержки Индикация имени сервера (SNI), расширение TLS, позволяющее обслуживать несколько имен хостов через HTTPS с одного IP-адреса.
Расширение SNI было представлено в 2003 году, чтобы упростить и удешевить развертывание HTTPS, но это означает, что имя хоста отправляется браузерами на серверы «в открытом виде», чтобы принимающий IP-адрес знал, какой сертификат предоставить клиент.
Когда сам домен или поддомен раскрывает конфиденциальную информацию (например, «contraception.foo.gov» или «suicide-help.foo.gov»), это может раскрыть эту информацию пассивным перехватчикам.
С точки зрения конфиденциальности сети, сегодня DNS также «сливает» имена хостов в открытом виде по сети (даже при использовании DNSSEC). В сообществе сетевых стандартов продолжаются усилия по шифрованию как имени хоста SNI, так и поиска DNS, но по состоянию на конец 2015 года ничего не было развернуто для поддержки этих целей.
Сегодня большинство клиентов поддерживают SNI, и владельцам сайтов рекомендуется оценить целесообразность поддержки SNI, чтобы сэкономить деньги и ресурсы.
Однако независимо от того, требуется ли поддержка SNI для доступа к конкретному веб-сайту или нет, владелец веб-сайта должен учитывать, что их имена хостов не зашифрованы через HTTPS, и учитывать это при предоставлении доменов и субдоменов.
Почему DNSSEC недостаточно хорош?
DNSSEC пытается гарантировать, что доменные имена разрешаются для правильных IP-адресов.
Однако разрешение DNS — это лишь один из аспектов безопасного обмена данными в Интернете. DNSSEC не обеспечивает полной защиты домена:
После завершения разрешения DNS DNSSEC не обеспечивает конфиденциальность или целостность связи между клиентом и IP-адресом назначения.
Ни один из основных веб-браузеров не информирует пользователя о сбое проверки DNSSEC, что ограничивает ее надежность и применимость.
HTTPS гарантирует конфиденциальность и целостность связи между клиентом и сервером, а веб-браузеры имеют строгие и развивающиеся политики обеспечения соблюдения HTTPS.
Как HTTPS защищает от спуфинга DNS?
На практике HTTPS может защитить связь с доменом даже при отсутствии поддержки DNSSEC.
Действительный сертификат HTTPS показывает, что сервер продемонстрировал право собственности на домен доверенному центру сертификации во время выдачи сертификата.
Чтобы гарантировать, что злоумышленник не сможет использовать спуфинг DNS для перенаправления пользователя на простое соединение http:// , где трафик может быть перехвачен, веб-сайты могут использовать HTTP Strict Transport Security (HSTS), чтобы дать браузерам указание требовать HTTPS-соединение для их владения во все времена.
Это означает, что злоумышленник, который успешно подделывает разрешение DNS, также должен создать действительное соединение HTTPS. Это делает DNS-спуфинг таким же сложным и дорогим, как атака на HTTPS в целом.
Если злоумышленник подменит DNS, но не скомпрометирует HTTPS, пользователи получат заметное предупреждающее сообщение от своего браузера, которое не позволит им посетить потенциально вредоносный сайт.
Если сайт использует HSTS, у посетителя не будет возможности проигнорировать предупреждение и нажать на него.
HTTPS и HSTS совместно защищают домен от спуфинга DNS.
Полное руководство по SSL и TLS
Учитывая постоянно растущие глобальные угрозы кибербезопасности и ужесточение стандартов безопасности Google, для владельцев бизнеса как никогда важно принимать активные меры для защиты своих сайтов.
В противном случае вы подвергаете риску себя и своих клиентов. Не хорошо.
Но есть надежда! Вы можете показать пользователям, что они могут вам доверять, предложив им безопасный зашифрованный опыт с помощью так называемого защищенного протокола передачи гипертекста (HTTPS). Чтобы использовать HTTPS, вам необходимо приобрести сертификат Secure Sockets Layer (SSL) или Transport Layer Security (TLS), который доказывает, что ваш сайт безопасен. Мы расскажем об этом позже.
В этом посте объясняется, что такое SSL/TLS и HTTPS, и обсуждается важность наличия этих функций на вашем веб-сайте.
Затем мы покажем вам, как внедрить сертификат SSL/TLS. Давайте прыгать!
SSL и TLS — это сертификаты, которые вы можете добавить на свой веб-сайт. Они создают зашифрованные соединения между браузерами и веб-серверами. Когда вы посещаете сайт, использующий соединение, сертифицированное с помощью SSL или TLS, только этот сайт может получить доступ к отправляемым вами данным.
SSL является предшественником TLS, который в настоящее время считается устаревшим и небезопасным. Однако аббревиатура «SSL» часто используется взаимозаменяемо при ссылке на любой тип сертификата. Поэтому мы будем называть их «SSL/TLS».
Чтобы настроить SSL/TLS, вам необходимо установить сертификат на свой сайт. Это убедит пользователей в том, что ваш сайт безопасен. На практике ваш сайт будет использовать протокол HTTPS для установления соединений. Вы можете узнать это как безопасную версию стандартного HTTP.
Вот как HTTPS защищает ваш сайт- Шифрование для предотвращения перехвата данных в процессе обмена.
- Целостность данных, поэтому попытки вмешательства в данные обнаруживаются.
- Проверка подлинности для предотвращения атак и повышения доверия пользователей.
SSL/TLS позволяет вам доставлять ваш сайт с помощью HTTPS, что обеспечивает безопасное, частное соединение между вашим сайтом и вашими пользователями. Если URL-адрес сайта использует http:// , он не защищен с помощью SSL/TLS. Однако, если он использует https:// , он безопасен — и для этого вам нужен сертификат SSL/TLS.
В Google Chrome вы можете идентифицировать сайты, которые обслуживаются через HTTPS, по значку замка на панели браузера. Когда посетитель запрашивает соединение с веб-сайтом, страница отправляет сертификат SSL, который содержит открытый ключ, необходимый для защиты сеанса. Затем сервер и браузер вступают в процесс, известный как рукопожатие SSL/TLS. Короче говоря, компьютеры взаимодействуют друг с другом, чтобы установить безопасное соединение.
youtube.com/embed/QeicRf_Ri3Y» frameborder=»0″ allowfullscreen=»allowfullscreen»> Почему сертификат SSL/TLS важен для вашего веб-сайта
Наличие сертификата SSL/TLS (и, в свою очередь, обслуживание соединения HTTPS) имеет решающее значение для безопасности вашего веб-сайта. Это гарантирует, что никто не сможет перехватить или получить доступ к передаче данных между вашим сервером и браузерами ваших посетителей (также известная как атака «человек посередине»).
Это не единственные типы атак. Ранее в этом году была обнаружена уязвимость в mitmproxy: прокси-сервере HTTPS с открытым исходным кодом, который делает возможной контрабанду HTTP-запросов.
При таком количестве угроз безопасности в Интернете использование протокола HTTPS является обязательным. Фактически, начиная с июля 2018 года Google Chrome начал перечислять сайты, использующие HTTP, как «небезопасные»:
Потеря доверия Google может серьезно повлиять на ваш поисковый рейтинг.
Это также может заставить посетителей опасаться вашего сайта. В конце концов, если их браузер предупредит их о том, что ваш сайт может быть опасным, вы, скорее всего, увидите потерю трафика.
Google начал менять свой алгоритм еще в 2014 году, чтобы отдать предпочтение сайтам, использующим SSL-сертификаты. Сегодня им уделяется еще больше внимания, заявляя, что те, у кого есть SSL-сертификаты, превзойдут тех, у кого нет, даже если все остальные факторы одинаковы.
Еще одна важная причина для установки сертификата SSL/TLS — если вы работаете в отрасли, требующей соблюдения определенных стандартов. Например, в финансовой сфере требуется соблюдение стандартов безопасности в отношении платежной информации. Индустрия платежных карт (PCI) устанавливает правила, которым должны следовать владельцы сайтов, чтобы безопасно принимать информацию о кредитных картах на своих веб-сайтах.
Как узнать, использует ли ваш веб-сайт SSL/TLS Важно убедиться, что ваш веб-сайт использует сертификат SSL или TLS.
Также важно постоянно следить за ним, чтобы убедиться, что срок его действия не истек. Отчет Keyfactor показал, что за последние два года 81% компаний столкнулись с перебоями в работе, связанными с сертификатами.
Если срок действия вашего сертификата неожиданно истечет, это может поставить под угрозу ваш сайт. На восстановление после сбоев могут уйти часы, а продолжительные простои могут нанести ущерб вашему бизнесу.
Проверить, есть ли у вас действующий сертификат SSL/TLS, очень просто. Для начала откройте свой сайт в Google Chrome (или любом другом браузере). Затем проверьте адресную строку в верхней части браузера, чтобы узнать, использует ли ваш сайт http:// или https://.
Вы также можете увидеть цветной замок рядом с URL-адресом. Если цвет красный, ваш сайт не использует SSL/TLS. Однако, если ваш сайт защищен с помощью SSL/TLS, вы можете увидеть зеленый замок:
Однако этот значок отображается не на всех сайтах с сертификатом SSL/TLS.
Его наличие зависит от используемого типа проверки (подробнее об этом позже). Например, некоторые SSL/TLS-сертификаты вместо этого будут отображать простой серый значок:
Это означает, что сайт может быть небезопасным, но браузер не может определить это точно. Если ваш сайт не защищен с помощью SSL/TLS, возможно, у вас все еще есть сертификат. Однако срок его действия, скорее всего, истек, что можно проверить, щелкнув значок предупреждения рядом с URL-адресом:
Здесь вы можете щелкнуть ссылку Сертификат, чтобы просмотреть дополнительную информацию. Например, мы видим, что у этого сайта есть сертификат SSL/TLS, но срок его действия истек:
Наконец, также возможно, что у вас есть действительный, актуальный сертификат SSL/TLS, но ваш сайт не использует его по умолчанию. В этом случае вам нужно будет принудительно перенаправить ваш сайт на HTTPS.
Различные типы SSL-сертификатов Если вы обнаружили, что на вашем сайте нет SSL/TLS-сертификата, вам необходимо его приобрести.
Однако, прежде чем вы это сделаете, вам нужно знать, какой сертификат вы ищете.
Сертификаты SSL/TLS бывают разных форм, каждая из которых имеет свои уникальные преимущества и недостатки. Чтобы приобрести его, ваш сайт должен быть проверен центром сертификации (CA). В зависимости от типа сертификата SSL/TLS, который вы решите купить, ваш сайт необходимо будет проверить на наличие различной информации.
Выбор сертификата во многом зависит от ваших требований и бюджета. Давайте рассмотрим различные категории, чтобы помочь вам найти вариант, который лучше всего подходит для вас:
Проверка домена (DV) Этот тип сертификата требует, чтобы вы доказали, что имеете право использовать определенный домен. Это делает его наименее безопасным вариантом. Однако это также самый дешевый тип сертификата SSL/TLS, и вы даже можете получить его бесплатно. Вы также можете получить одобрение очень быстро — даже в течение нескольких минут. Это рекомендуется для небольших сайтов, которые не обрабатывают конфиденциальные данные, такие как блоги или портфолио.
Это более безопасный вариант, требующий более тщательной проверки вашего сайта. ЦС проверит вашу организацию, чтобы убедиться, что вы законны и заслуживаете доверия. Таким образом, это также немного дороже, и приобретение займет немного больше времени. Однако этот тип сертификата рекомендуется для более крупных сайтов, которые обрабатывают пользовательские данные и совершают покупки.
Расширенная проверка (EV)Это наиболее безопасный вариант, но и самый дорогой и трудоемкий. Получение расширенной проверки требует тщательного процесса проверки и обычно обходится дороже, чем предыдущий вариант. Это также означает, что одобрение занимает больше всего времени. Этот тип сертификата предназначен для очень крупных сайтов с высокой посещаемостью, таких как предприятия электронной коммерции и официальные правительственные сайты.
Как мы указывали ранее, тип сертификата SSL/TLS, который вам нужен, полностью зависит от цели и требований вашего сайта.
Мы рекомендуем вам прочитать больше о различных уровнях сертификатов, чтобы убедиться, что вы выбираете правильный вариант.
На данный момент вы знаете, что вам нужен сертификат SSL/TLS. Более того, у вас есть представление о типе сертификата, который требуется вашему сайту. Теперь вам просто нужно купить один.
Сертификат SSL/TLS можно получить в центре сертификации, например GlobalSign. Кроме того, некоторые хостинг-провайдеры предлагают их в качестве бесплатных дополнений или в комплекте с платными планами.
В DreamHost сертификаты SSL/TLS можно легко добавить на ваш сайт с панели управления. Давайте взглянем на доступные варианты:
SSL, проверенный Sectigo Это сертификат DV (ранее известный как Comodo), который стоит 15 долларов в год. Это гарантирует, что ваш сайт будет отображаться в браузерах как полностью защищенный. Это делает его лучшим вариантом для коммерческих сайтов или сайтов, обрабатывающих конфиденциальные данные.
Это еще один бесплатный сертификат DV, но более безопасный, чем предыдущий вариант. Сертификат Let’s Encrypt почти так же надежен, как Sectigo. Таким образом, он идеально подходит для небольших сайтов, которые не обрабатывают много личных данных, таких как блоги.
Если у вас уже есть учетная запись DreamHost, вы можете приобрести один из этих сертификатов, перейдя к Веб-сайты > Безопасные сертификаты на панели управления. Здесь вы увидите все свои домены и доступные параметры SSL/TLS:
Нажмите кнопку Добавить рядом с вашим доменным именем. Это приведет вас к экрану, где вы сможете выбрать между бесплатным SSL-сертификатом Let’s Encrypt или платным сертификатом Sectigo DV.
Когда вы решили, какой вариант лучше всего подходит для вашего сайта, нажмите Выберите этот сертификат :
Теперь ваш сайт DreamHost будет защищен SSL/TLS. Подождите 15 минут, пока изменения будут отправлены на сервер.
Однако у вас может возникнуть вопрос: что, если я хочу использовать сертификат SSL/TLS, который я уже приобрел в другом месте? В следующем разделе мы покажем вам, как установить сертификат, приобретенный у третьей стороны.
Как установить сертификат SSL/TLS на ваш веб-сайт WordPress (2 варианта)Если вы приобрели сертификат SSL/TLS во внешнем центре сертификации, вам необходимо подключить его к своему сайту и установить. . Процесс может варьироваться в зависимости от вашего сайта, вашего веб-хостинга и типа выбранного вами сертификата.
Однако существует два основных способа установки SSL/TLS-сертификата: с помощью плагина и панели управления хостингом. Рассмотрим подробнее каждый метод.
Вариант 1. Установите действительно простой подключаемый модуль SSLОдин из самых простых способов добавить на сайт сертификат SSL/TLS — использовать подключаемый модуль. Really Simple SSL — это инструмент, который оправдывает свое название:
Инструмент можно загрузить и установить бесплатно, хотя доступна расширенная версия.
Он также невероятно прост в использовании благодаря простому процессу настройки и удобному интерфейсу.
Плагин выполнит за вас весь процесс установки и активации. Все, что вам нужно, — это сертификат SSL/TLS, а инструмент обрабатывает почти все остальное.
Начните с установки и активации Really Simple SSL на вашем сайте WordPress. Затем на панели инструментов появится сообщение с дополнительной информацией о том, что вам нужно сделать перед активацией SSL/TLS. Прежде чем продолжить, убедитесь, что вы выполнили все эти шаги:
Если к вашему сайту уже подключен сертификат SSL/TLS, вы увидите опцию Активируйте SSL! Если вы нажмете на эту кнопку, плагин установит и активирует ваш сертификат.
Однако, если вы не добавили SSL/TLS через свой веб-хост, вы увидите сообщение, информирующее вас об этом факте. Вам нужно будет вернуться на панель инструментов или панель управления вашего хоста и следовать их конкретным рекомендациям по добавлению вашего сертификата.
После этого вы можете вернуться в панель управления WordPress и активировать сертификат SSL/TLS:
В процессе установки инструмент будет держать вас в курсе состояния. Вы можете просмотреть некоторые задачи, которые вам все еще могут понадобиться, а также обновить процесс в любой момент.
Вариант 2: Используйте панель управления DreamHostМы уже показали вам, как DreamHost упрощает покупку и активацию сертификата SSL/TLS с панели управления. Вы можете использовать аналогичный процесс для добавления стороннего сертификата.
Во-первых, вам необходимо войти в свою учетную запись и перейти к веб-сайтам > Безопасные сертификаты. Затем выберите вкладку Импорт сертификата . На этом экране вы сможете установить сторонний сертификат SSL/TLS на свой сайт:
Вам потребуется добавить сертификат SSL/TLS вместе с закрытым ключом и запросом на подпись сертификата. Если у вас есть промежуточный сертификат, вам также потребуется добавить эту информацию здесь.
Важно, чтобы все они были получены из одного центра сертификации и были приобретены одновременно, иначе они не будут совместимы.
Кроме того, вы должны убедиться, что вы включили все при добавлении этой информации. Например, когда вы вставляете свой сертификат, вы также должны включать строки —– СЕРТИФИКАТ НАЧАЛА —– и —– СЕРТИФИКАТ КОНЦА —– в начале и в конце соответственно.
Когда вы добавили все необходимые данные, нажмите Сохранить изменения . Если сертификат SSL/TLS действителен и вы все ввели правильно, теперь он будет активен на вашем сайте.
Вы можете проверить, правильно ли работает процесс, используя метод, который мы показали вам ранее. Просто зайдите на свой сайт в браузере и убедитесь, что он использует https:// и имеет зеленый замок рядом с URL-адресом (если применимо). Если это так, вы успешно добавили SSL/TLS на свой сайт WordPress!
Существуют ли риски при переходе вашего сайта на HTTPS? Риски перехода вашего сайта с HTTP на HTTPS минимальны, а преимущества намного перевешивают любые потенциальные недостатки.
Единственный реальный риск заключается в том, что ваш сайт может быть временно недоступен во время процесса. Однако, как правило, это очень незначительная проблема, которая может быть решена быстро.
Тем не менее, есть некоторые вещи, о которых следует помнить при переходе с HTTP на HTTPS. Лучший способ обеспечить безопасный и плавный переход — это планировать заранее.
Перед началом процесса миграции важно убедиться, что приобретенный сертификат SSL работает. Вы можете сделать это с помощью инструмента тестирования SSL Labs:
. Вам также потребуется создать подробный план миграции и перенаправления. Перенаправление 301 должно быть размещено на каждом URL-адресе HTTP, указывающем на его эквивалент HTTPS.
Также необходимо учитывать несколько факторов поисковой оптимизации (SEO). Вы должны убедиться, что ваша карта сайта XML обновлена и включает только ваши URL-адреса HTTPS. Также важно обновить все ваши внутренние ссылки, а также любые внешние ссылки, указывающие на ваш сайт, который вы контролируете.
Мы также рекомендуем воспользоваться помощью разработчика или эксперта по WordPress для помощи в процессе миграции. После завершения миграции убедитесь, что ваша версия HTTPS подключена к вашим учетным записям Google Analytics и Search Console.
Будущее безопасности веб-сайтовПо мере того, как Интернет продолжает развиваться, растет и потребность в безопасности веб-сайтов. В прошлом обновления безопасности выпускались по мере необходимости, обычно в ответ на обнаружение конкретной угрозы или уязвимости.
Однако сегодняшний климат безопасности веб-сайтов сильно отличается. С ростом количества изощренных атак и появлением новых угроз каждый день владельцы веб-сайтов больше не могут позволить себе ждать, пока что-то пойдет не так, чтобы принять меры.
Вместо этого им необходимо проявлять инициативу в отношении безопасности веб-сайтов и всегда искать новые способы защиты своих онлайн-ресурсов. Это означает быть в курсе последних тенденций в области безопасности и следить за новыми обновлениями, которые могут помочь улучшить защиту вашего веб-сайта.
Будущее безопасности веб-сайтов всегда меняется, и идти в ногу с последними тенденциями и технологиями может быть непросто. В ближайшие годы мы ожидаем увидеть ряд крупных обновлений безопасности, которые могут существенно повлиять на то, как владельцы веб-сайтов защищают свои сайты. Давайте рассмотрим некоторые новые тенденции, которые, по нашему мнению, сыграют роль в будущем безопасности веб-сайтов.
Переключение на HTTPS по умолчаниюОдним из самых больших изменений в безопасности веб-сайтов является переключение на HTTPS по умолчанию. Это изменение разрабатывалось в течение нескольких лет, но, наконец, оно начинает становиться реальностью.
Google настаивает на этом изменении с 2014 года и даже начал отдавать предпочтение HTTPS-сайтам в результатах поиска. Поэтому все веб-сайты должны перейти на HTTPS, если они хотят идти в ногу со временем. Это не только поможет с SEO, но и сделает ваш сайт более безопасным для ваших пользователей.
Новые функции безопасности доменных имен Для защиты от захвата доменных имен Интернет-корпорация по присвоению имен и номеров (ICANN) представила новый набор функций безопасности для всех доменов, зарегистрированных после 1 января 2018 г.
Эти функции включают Блокировка домена, которая предотвращает несанкционированное изменение записей DNS, и блокировка регистратора, которая предотвращает несанкционированную передачу домена другому регистратору.
В настоящее время эти меры безопасности не являются обязательными. Тем не менее, они, вероятно, станут более популярными, потому что они могут иметь большое значение для защиты вашего доменного имени от взлома.
Еще одно большое изменение, которое произойдет в 2022 году, — введение расширений безопасности системы доменных имен (DNSSEC). Этот новый протокол безопасности поможет защитить DNS-серверы от эксплуатации и затруднит злоумышленникам подделку DNS-записей.
DNSSEC уже используется некоторыми крупнейшими компаниями мира, включая Google, Facebook и Netflix. Это только вопрос времени, когда это станет требованием для всех веб-сайтов.
Более изощренные атаки По мере того, как хакеры становятся все умнее, мы можем ожидать более изощренных атак.
Это может включать в себя все, от целевых фишинговых атак до крупномасштабных распределенных атак типа «отказ в обслуживании» (DDoS). Владельцы веб-сайтов должны быть готовы к этим угрозам и иметь план восстановления.
С введением Общего регламента по защите данных (GDPR) и других правил конфиденциальности данных мы можем ожидать более пристального внимания к тому, как владельцы веб-сайтов собирают и используют личные данные. Это может привести к ужесточению требований к веб-сайтам, а также к более строгим наказаниям для тех, кто не соблюдает новые правила.
Повышение осведомленности об угрозах безопасности По мере того, как безопасность веб-сайтов становится все более серьезной проблемой, мы можем ожидать, что все больше людей предпримут шаги для защиты своей онлайн-информации. Это может включать в себя все, от использования надежных паролей до инвестиций в продукты и услуги для обеспечения безопасности веб-сайтов.