подключить https в php

Настройка сайта для работы по HTTPS

Настройка сайта для работы по HTTPS

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

В первую очередь осуществляется переадресация сайта на защищенный протокол HTTPS. Переадресация с протокола HTTP на протокол HTTPS реализуется добавлением в файл .htaccess следующих директив:

RewriteEngine on
SetEnvIf X-Forwarded-Proto https SERVER_PORT=443
SetEnvIf X-Forwarded-Proto https HTTPS=on
RewriteCond % !=on [NC]
RewriteRule ^(.*)$ https://%% [R=301,L]

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

Проверить страницы сайта можно с помощью следующего сервиса.

При наличии элементов, доступных только по протоколу HTTP, ссылки на них нужно изменить на относительные (к примеру, вместо http://yourdomain.com/content/pic.jpg в коде страницы ссылка должна иметь вид /content/pic.jpg ), либо явно указывать использование протокола HTTPS (в таком случае ссылка будет иметь вид https://yourdomain.com/content/pic.jpg «).

Сайт, на котором расположен элемент, также должен иметь валидный SSL-сертификат.

Настройка известных CMS для работы по HTTPS

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

Joomla!

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

WordPress

В административной панели WordPress производится смена протокола в адресе сайта. Для этого в разделе «Настройки» > «Общие«, в полях «Адрес WordPress» и «Адрес сайта» протокол «http» меняется на «https».

Для быстрой и удобной настройки SSL можно воспользоваться специальным плагином Really Simple SSL. Для безопасности сайта все установленные компоненты и плагины необходимо своевременно обновлять.

Bitrix

Drupal

Для расширенной настройки доступа к сайту по защищенному протоколу рекомендуем установить модуль «SSL 1.0.0-ga«, доступный по следующей ссылке. При использовании MODX Revolution для настройки работы сайта по https вносятся следующие изменения в конфигурационный файл core/config/config.inc.php:

После внесения изменений очищается кэш MODX.

Как указать поисковым системам, что сайт является защищенным

Компания Google рассматривает использование HTTPS на сайте в качестве фактора ранжирования. Для корректного индексирования сайта по протоколу HTTPS компания Google рекомендует соблюдать следующие правила:

Перенаправляйте пользователей и поисковые системы на страницу HTTPS или ресурс с переадресацией 301 на стороне сервера для адресов HTTP.

Используйте схожие по протоколам URL-адреса для всех остальных доменов (например //petstore.example.com/dogs/biscuits.php ), или обновите ссылки своего сайта для перехода непосредственно на ресурс HTTPS.

Включение шифрования SSL без сертификата приведет к некорректной работе сайта.

Источник

https://

Описание

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

Использование

Опции

Примеры

Пример #1 Определение URL, с которого был забран документ после переадресаций

Примечания

Замечание: Протокол HTTPS поддерживается только когда модуль openssl включён.

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

Отправка запросов POST и PUT, например, может быть выполнена с помощью HTTP-контекста.

Смотрите также

User Contributed Notes 4 notes

HTTP post function;

As it says on this page:

If you want to send more than one custom header, just make header an array:

Источник

petukhovsky.com

Настал 2020-й год и я перевел свой сайт на https и на странице одной из самых популярных записей в блоге перестал работать пример анонимного чата на технологии WebSocket. К моему удивлению, задача перехода на https весьма ощутимо затронула WebSocket: от небольших правок скрипта JavaScript, до значительной доработки PHP кода, в том числе и с погружением в некоторые детали стандарта RFC-6455.

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

Для новичков попавших на эту страницу миновав изучение базовых принципов работы технологии WebScoket настоятельно рекомендую ознакомиться со статьями в моём блоге на тему WebScoket начиная с простой веб-сокет на PHP или веб-сокеты с абсолютного 0.

История массового перехода на https

С развитием сети Интернет со временем компании стали задумываться о безопасности данных пользователей передаваемых по сети. Времена HTTP/0.9 и HTTP/1.0 когда данные передавались в незашифрованном виде давно прошли. В середине нулевых с появлением большого количества веб-сайтов требующих авторизации и содержащих большое количество данных пользователей начало набирать популярность расширение протокола HTTP HTTPS (HTTP Sercure), которое обеспечивало ассиметричное шифрование тела HTTP запроса передаваемого по сети. А в середине десятых, в эру Facebook, Google и регуляторов Интернета из Евросоюза, запрос общества на полную защищенность передаваемых данных в сети Интернет сформировался в требование поддержки HTTPS для большинства сайтов. И это требование не то, что можно игнорировать – ведь сайты без поддержки HTTPS стали понижаться в поисковой выдаче, браузеры стали предупреждать о нежелательности посещения сайтов без поддержки HTTPS, а также отключать возможность смешанного использования HTTP и HTTPS в рамках одного веб-сайта. Нужно понимать, что это не прихоть, а к такому стремлению использовать везде HTTPS подтолкнуло развитие технологий анализа трафика (снифферов) позволяющих перехватывать все данные пользователей вплоть до паролей передаваемых по незашифрованному HTTP протоколу.

В каких случаях нужна поддержка веб-сокетами https?

Очевидно, что во всех приложениях в которых передаются мало-мальски чувствительные данные или пароли настоятельно рекомендуется использовать secure версию протокола веб-сокетов wss://. Казалось бы, как это может относиться к скрипту моего чата, который не передаёт никаких конфиденциальных данных? А всё дело в том, что современные браузеры открывая страницу по HTTPS автоматически запрещают использовать внутри неё незащищенное соединение по протоколу WS. Поэтому задача реализации и поддержки шифрованного протокола веб-сокетов WSS становится как никогда актуальной для всех сайтовладельцев использующих протокол HTTPS.

Переход на wss

В качестве примера я обновлю версию своего анонимного чата на веб-сокетах выпустив новую версию wss server admin panel v.0.5.1 & chat v.0.2..

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

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

Сервер WSS поднялся и прекрасно заработал на базе моего SSL сертификата используемого в шифровании данных передаваемых по HTTPS на мой домен. Но для меня это решение казалось не очень удачным, потому как не хотелось хранить в директории веб-сайта *.crt и *.key файлы содержащие ключи HTTPS домена, ко всему также не хотелось обновлять их вручную каждый раз при обновлении сертификата домена. Но, к сожалению, использовать их из директории сертификатов тоже оказалось проблематичным из-за ограничения доступа накладываемых на уровне файловой системы. Не помогло и точечное присвоение прав, по причине того что пользовательская директория с содержимым веб-сайта и скриптов PHP оказалась сильно изолированной от директории хранения файлов сертификатов и для доступа к ней пришлось бы давать PHP скриптам доступ ко многим критическим каталогам сервера.

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

Upd 2021.04.13: Утомившись ручным копированием *.crt и *.key, я написал простой скрипт копирующий данные сертификатов в директорию проекта.

Я остановился на втором способе как наиболее подходящем для себя.

Источник

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

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

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

HTTPS: что это такое и зачем на него переходить

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

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

На смену HTTP пришел HTTPS — особое расширение протокола, включающее в себя настройки шифрования. Благодаря этому все платежи, покупки, пароли и прочие данные защищены, и добраться до них злоумышленнику практически невозможно. Также этот интернет-протокол позволяет повысить доверие пользователей, разместить рекламные баннеры в Google AdWords, получить приоритетное ранжирование в поисковых системах и многое другое.

Использование HTTPS сопровождается получением специального SSL-сертификата. Сертификаты разделяются на три вида:

Каждый из вышеупомянутых сертификатов обеспечивает шифрование трафика между сайтом и браузером.

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

Переходим на HTTPS

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

Шаг 1: Подготовка сайта

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

Чтобы избежать предупреждения, указанного выше, необходимо изменить все внутренние ссылки с абсолютных на относительные. Например, ссылку http://ssl.ru/testpage/ потребуется заменить на /testpage/. Также стоит внимательно проверить все ссылки на скрипты в коде страниц.

Второй момент — проверка медиаконтента, в который входят изображения, видеоклипы, презентации и прочее. Необходимо посмотреть, какой на страницах сайта используется контент и по какому протоколу он запрашивается. Если используется HTTP, то рекомендуется загрузить все файлы на сервер и установить относительные ссылки. В противном случае указывайте только проверенные сайты: YouTube, Facebook, VK и так далее.

Теперь можно переходить к подключению SSL.

Шаг 2: Установка SSL-сертификата

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

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

Шаг 3: Настройка редиректа на HTTPS

Также мы можем сделать редирект с HTTP через административную панель CMS системы. В OpenCart для этого нужно открыть файл config.php и прописать в него следующее:

В WordPress изменить wp-config.php:

Для получения подробной информации о редиректах на других CMS обратитесь к их документации.

Ш аг 4: Настройка для поисковых систем

Если ваш сайт индексируется Google, Яндекс или другими поисковиками, то после перехода на HTTPS необходимо им об этом сообщить. В частности, нужно:

Готово! На этом переход с HTTP на HTTPS завершен. Надеюсь, что у вас не возникло сложностей. Спасибо за внимание!

Источник

Настраиваем HTTPS-сервер на nginx

Для чего я это пишу?

В последнее время в связи с кучей факторов (АНБ, DPI с рекламой и другое) у меня начала просыпаться паранойя и я подумал полностью перевести свой небольшой сайт на https. На хабре было несколько статей с техническими подробностями работы SSL/TLS, однако поискав информацию на тему настройки https-вебсервера обнаружил традиционное деление статей — либо это статьи «Делайте вот так», где просто даны настройки без каких-либо разъяснений и вариантов использования, либо это большие теоретические статьи, где обсуждаются различные схемы использования, но без практически применимых готовых вариантов. На хабре была статья о настройке, однако в ней нет информации про DH-кодировки, да и некоторые параметры не описаны. Подумал, что стоит упорядочить найденное в виде статьи, которая будет полезна тем, кто хотел бы развернуть https у себя на сервере, но не слишком углубляться в дебри SSL.

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

Сертификат

У меня уже был сертификат от StartSSL. О нем уже писали на хабре, так что на этом шаге задерживаться не буду. Скажу только, что в течении первых двух-трех дней браузеры, проверяющие сертификат на сервере, могут на него ругаться (у меня такое происходило с Opera 12 и Firefox), видимо у StartCom кеши валидных сертификатов обновляются не так часто. Про установку же будет сказано ниже

О вариантах настройки

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

В общем случае есть два актуальных на данный момент варианта настройки — с Forward Secrecy и без него. При настройке различие только в наборе кодировок (директива ssl_ciphers), однако тут стоит задуматься, что же вы хотите от https.

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

Тут стоит задуматься, для чего нужен https конкретно у вас на сайте. При большом количестве посетителей использование DH-алгоритмов шифрования может прилично увеличить нагрузку (которая в любом случае повысится при переходе на HTTPS), в некоторых случаях придется увеличить тариф на VDS и т.п. В большинстве случаев RC4 достаточно, однако многим хочется чтобы все было «по высшему классу», так почему бы не сделать, если ресурсы позволяют?

Настройка nginx

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

В секции http необходимо добавить:

Секция server же получится приблизительно такая:

В данном примере не используются DH-алгоритмы, т.е. нет Forward Secrecy. Из улучшений тут можно опустить поддержку SSLv3 (убрав его из ssl_ciphers), таким образом перестанет поддерживаться IE 6 и ниже, поскольку он не поддерживает TLS, а так же увеличить время STS, но об этом ниже.
Без SSLv3 такая настройка дает оценку 100-95-100-90 в тесте SSL.

Пройдемся по параметрам

4000 сессий, таким образом при этих настройках можно хранить до 40 тысяч сессий), 5m — таймаут сессии в кеше (5 минут).

ssl_prefer_server_ciphers on;
«Указывает, чтобы при использовании протоколов SSLv3 и TLS серверные шифры были более приоритетны, чем клиентские.» (nginx.org) — клиентские шифры (CBC) уязвимы к некоторым типам атак.

ssl_stapling on;
Позволяет серверу прикреплять OCSP-ответы, тем самым уменьшая время загрузки страниц у пользователей. ЗДесь имеются ввиду ответы о валидности сертификата (при проверке на отозванность). С точки зрения безопасности пользователя не важно, кто передает ответы — веб-сервер или сервер CA — ведь ответ в любом случае подписан и валидность ответа тоже можно проверить, а ответ включает в себя свой срок действия.
Для работы этой функции нужно указать DNS-сервер, что и делается директивой resolver.

keepalive_timeout — думаю в описании не нуждается, не стоит выключать или ставить слишком малым для уменьшения нагрузки из-за повторного установления соединения.

ssl_certificate и ssl_certificate_key указывают на файл сертфиката и файл приватного ключа для него. Так как я рассказываю на примере сертификата от StartSSL, то здесь допущу небольшой комментарий относительно инструкций StartSSL по установке сертификата — не нужно добавлять сертификат Root CA в обобщенный файл сертификата, поскольку это не имеет смысла и только увеличивает, хоть и не на много, размер передаваемых данных. Достаточно иметь в файле последовательно личный сертификат и сертификат промежуточного центра сертификации. Готовый файл сертификата для nginx (для сетификата StartSSL) можно получить следующей командой:

Где ваш сертификат — certificate.crt, а промежуточный сертификат — www.startssl.com/certs/sub.class1.server.ca.pem

add_header Strict-Transport-Security ‘max-age=604800’;
Strict-Transport-Secutiry — заголовок, указывающий браузеру на то, что сайт доступен только по https. Это предотвращает возможность перехода обратно на http-версию для последующей атаки через незашифрованное соединение. Кстати данный параметр еще удобен тем, что при наличии в коде страницы «забытого» подключения ресурса (картинки/скрипта/стиля/. ) с того же сайта по http, браузер сам пойдет на https-версию и не будет ругаться на частично незашифрованное соединение. Конечно же это не сработает для внешних ресурсов. Время — неделя. Многие рекомендуют ставить 1 год, однако в случае решения в будущем отказаться от использования https это может доставить проблемы некоторым пользователям. Время обновляется при каждой передаче этого заголовка, т.е. при каждом заходе на сайт.

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Указывает поддерживаемые протоколы. SSLv2 и v3 имеют критические уязвимости.

Forward Secrecy

Для включения Forward Secrecy можно использовать например такой набор шифров:

Кроме того, необходимо настроить приоритет шифров OpenSSL:

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

Для усиления шифрования можно увеличить стойкость DH-шифров, создав файл параметров DH-шифров (создание файла займет некоторое время!), скажем длинной 4096 бит:

И добавив в конфиг nginx директиву

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

Про CDN-сервисы

В обсуждении инструкций по настройке Forward Secrecy было замечено, что по крайней мере CDN Amazon CloudFront не поддерживает обмен с вашим сервером в DH-кодировках, да и RC4 вроде тоже, что не радует. Возможно что и с другими CDN тоже не все идеально, но я лично пока с ними не сталкивался, поэтому ничего сказать не могу.

Источник