Сайт https – Полное руководство по переходу с HTTP на HTTPS / Habr

29.03.2020 alexxlab

Содержание

что должен знать каждый 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

Мигрируем на 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

«Чем отличается протокол HTTP от HTTPS?» – Яндекс.Знатоки

http — незащищённый протокол. Это означает, что данные, например номера банковских карт или пароли, которые пользователи вводят на сайте могут быть перехвачены посторонними.

Сейчас идёт активная работа по побуждению владельцев сайтов переходить на работу по протоколу https. К примеру, в популярных браузерах такие сайты получают «чёрную метку»:

Кроме этого сайты работающие по протоколу http ранжируются ниже в поисковой выдаче.

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

Hypertext Transport Protocol Secure ( https ) – это протокол, который обеспечивает конфиденциальность обмена данными между сайтом и пользовательским устройством.

Такое шифрование не допускает утечки данных, а значит, защищает сайт от взлома.

Чтобы получить возможность шифровать трафик владелец сайта должен установить на сервере специальный сертификат безопасности (SSL-сертификат)

Чтобы использовать протокол https нужно настроить сервер вашего сайта, а также Внести изменения на сайт

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

yandex.ru

Как перейти с http на https? Пошаговая инструкция. Переход на Https в Joomla и WordPress

Всем привет! В данной статье затронем тему безопасности, а именно безопасный протокол передачи данных — https. Если вы обратили внимание мой блог, на котором вы сейчас находитесь работает по протоколу https, на который я перешел недавно. Также, на https я перевел один из моих клиентских сайтов. Пришлось немного повозиться и понервничать, но в итоге все получилось. Я подумал, что надо обязательно написать об этом на блоге — как перейти с http на https безболезненно для сайта, тем более эта тема я считаю уже популярна, т.к. сегодня все больше и больше сайтов переходят на https.

Что меня побудило перейти на протокол https? В последнее время мне на глаза стали попадаться вот такие заголовки: Браузер Mozilla Firefox в скором времени перестанет поддерживать небезопасные http-соединения; Правительство США поручило всем государственным сайтам перейти на HTTPS; C января 2017 года все сайты, передающие секретные данные (пароли, номера кредитных карт и т.д.) по незащищенному соединению в браузере Google Chrome будут помечаться как небезопасные. Плюс ко всему где-то в интернете читал, что скоро всем сайтам придется перейти на протокол https в обязательном порядке. Я подумал, что в один прекрасный день все равно эта участь постигнет и меня. Так зачем же тянуть? Тем более хостинг beget.ru, на котором я сижу предоставил возможность для приобретения бесплатных SSL-сертификатов. В общем, собрал всю необходимую информацию по тому, как перейти с HTTP на HTTPS и сделал это. 🙂

Структура статьи

Зачем нужно использовать https и что имеется ввиду под безопасностью?

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

Весь процесс я решил разделить на шаги и выполнять их как раз именно в такой последовательности. Также ниже я дам рекомендации по переходу для популярных cms Joomla и WordPress. У каждого есть свои особенности.

Приобретение сертификата

Для начала необходимо приобрести SSL сертификат, чтобы ваш сайт был доступен по обоим протоколам — http и https. Давайте сначала внесем некоторые ясности в виды SSL сертификатов.

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

Простые сертификаты

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

Wildcard SSL

Wildcard SSL — прекрасно подойдет сайтам с наличием поддоменов. В данном случае достаточно выпустить один сертификат, который будет работать на всех поддоменах и позволит сэкономить деньги на покупку отдельных сертификатов.

Мультидоменные SSL сертификаты

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

EV (Extended Validation) сертификаты

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

Смотрится круто и повышает доверие потенциального клиента. Поэтому, владельцам крупных компаний рекомендуется выпуск именно EV сертификатов.

Сертификаты с поддержкой IDN

Не все сертификаты поддерживают кириллические домены. Если у вас домен кириллицей в зоне РФ, то вам следует приобрести сертификат с поддержкой IDN.

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

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

Сегодня приобрести сертификат SSL для сайта можно абсолютно бесплатно. Уже давно Google заявил о том, что пора уже переходить всем на безопасный прокол https и что предпочтение в ранжировании будет отдаваться сайтам именно с защищенным соединением. Кстати, это еще одна причина по которой я перешел на https. В общем, в связи с этим всем в свет появился проект под названием Let’s Encrypt. В первую очередь данный проект рассчитан на доступность приобретения SSL сертификата, а также облегчить жизнь рядовым веб-разработчикам с установкой сертификатов (генерация приватных ключей и прочее). И что самое главное — сертификаты, выдаваемые Let’s Encrypt, абсолютно бесплатные. Лично на моем блоге стоит именно такой сертификат.

Я получил сертификат SSL от Let’s Encrypt в панели управления beget.ru. Если вы пользуетесь данным хостингом, то получить его будет проще простого. Заходите в панель управления Бегет, далее переходите в раздел «Домены» и в списке доменов щелкаете по иконке SSL.

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

Настройка сайта

Загружаемые ресурсы

Для перевода сайта на HTTPS необходимо выполнить некоторые настройки на сайте, касается это загружаемых ресурсов. Что подразумевается под ресурсами, это — скрипты, стили, картинки, аудио, видео, т.е. все те ресурсы, которые загружаются браузером с вашего сайта через протокол http. Существуют относительные и абсолютные адреса. Чем они отличаются?

Относительный адрес:

/image.jpg

Относительный адрес вне зависимости от протокола:

//sitename.ru/image.jpg

Абсолютный адрес:

http://sitename.ru/image.jpg

В абсолютном адресе указывается доменное имя сайта с протоколом. Так вот, при переходе на https необходимо применять относительные адреса вне зависимости от протокола, т.е. отсекая сам протокол. При таком подходе ресурсы будут загружаться по такому же протоколу, что и ваш и не важно на http он или на https. Единственное условие — если вы загружаете ресурсы с внешних сайтов (например, с CDN), то данные сайты должны быть доступны по https, иначе от них придется отказаться.

Например, загрузка библиотеки jQuery с CDN с поддержкой https будет следующей:

<script src="//code.jquery.com/jquery-1.12.4.min.js"></script>

Также, как вариант вы можете просто указать все абсолютные ссылки с протоколом https (так например сделано в WordPress).

Тег <base />

Обратите внимание, если вы на сайте используете тег <base> с адресом сайта, то обязательно проследите, чтобы адрес был указан с протоколом https. Например, <base href=»https://zaurmag.ru» />. Данный тег не является обязательным, но все же, если в вашей cms он используется, то потрудитесь его исправить в случае чего. Находится он в самом начале секции <head>. Если получится так, что вы все ссылки изменили на относительные вне зависимости от протокола (//sitename.ru), а в теге <base> содержится адрес с http, то все ваши относительные ссылки будут считаться относительными в зависимости от протокола http. В результате в консоле браузера вы получите кучу ошибок, а на сайте поплывет дизайн.

Тег rel=»canonical»

Если у вас на сайте используется тег rel=»canonical», то проследите за тем, чтобы канонический адрес страницы в данном теге был абсолютным с указанием протокола https. Иначе, если будет http он будет работать только во вред.

301 редирект с http на https

Чтобы не потерять трафик нам необходимо сделать так, что когда пользователь заходит на сайт по протоколу http его бы автоматически перекидывало на https. Склейка зеркал и переиндексация сайта в поисковиках дело долгое (Гугл правда быстро реагирует, вот с Яндексом придется ждать), поэтому 301 редирект может это дело ускорить и не дать потерять трафик. Для этого в файл .htaccess нужно добавить всего две строчки:

RewriteCond %{SERVER_PORT} !^443$ 
RewriteRule ^(.*)$ https://sitename.ru/$1 [R=301,L]

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

RewriteEngine On # Если этой строки нет выше
RewriteCond %{HTTP:X-Forwarded-Protocol} !=https
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

А вот еще один код редиректа. Бывало такое у меня, что выше два кода не работали. Помог только этот.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

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

Еще советую добавить код, который будет перекидывать по 301 редиректу на www или на без www, в зависимости от того, какой домен вы выбрали основным.

## редирект с без www на www:
RewriteCond %{HTTP_HOST} ^sitename.ru$ [NC]
RewriteRule ^(.*)$ https://www.sitename/$1 [R=301,L] ## редирект c www на без www:
RewriteCond %{HTTP_HOST} ^www.sitename.ru$ [NC]
RewriteRule ^(.*)$ https://sitename.ru/$1 [R=301,L]

Файл robots.txt

В robots.txt нам обязательно следует указать главное зеркало с протоколом https. Также указать ссылку на карту сайта так с протоколом https. Вот как я сделал на своем блоге:

Host: https://zaurmag.ru
Sitemap: https://zaurmag.ru/sitemap.xml

Переезд сайта в панели вебмастеров Яндекс и Гугл

После вышеперечисленных действий нам необходимо сообщить поисковикам, что сайт переехал на новый протокол https. Как известно адрес с http и с https это абсолютно два разных адреса в глазах поисковиков.

Яндекс вебмастер

Для переезда сайта в Яндекс заходим в панель Яндекс Вебмастер по адресу https://webmaster.yandex.ru. Выбираем свой сайт и в разделе «Настройка индексирования» вводим свой домен и отмечаем чек-бокс «Добавить HTTPS«, сохраняем.

Далее переходим в раздел «Настройка индексирования» -> «Файлы Sitemap» и добавляем адрес карты сайта с протоколом https. Данный адрес, если помните мы указывали и в файле robots.txt.

Добавляем адрес sitemap в панели Яндекс вебмастер

Центр вебмастеров Гугл

С Яндексом разобрались, теперь давайте перейдем к Google. Идем в центр вебмастеров Гугл — https://www.google.com/webmasters и добавляем все версии (зеркала) сайта. Всего их должно быть 4. Например, для моего блога я добавил:

https://zaurmag.ru 
https://zaurmag.ru 
http://www.zaurmag.ru 
https://www.zaurmag.ru

Далее выбираем основное зеркало с https естественно, только с www или без www. Для своего сайта я выбрал без www — https://zaurmag.ru. Открываем сайт и в настройках сайта (кликаем по шестеренке справа) указываем основной домен. Вот на примере моего блога.

Основное зеркало сайта zaurmag.ru в вебмастере гугл

Далее указываем адрес карты сайта. Для этого идем в «Сканирование» -> «Файлы Sitemap» и добавляем адрес карты сайта, щелкнув по красной кнопочке справа. Кстати, пока писал статью обнаружил, что я не добавил карту сайта для основного домена сайта zaurmag.ru. 🙂

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

Также хотелось бы сказать, что процесс переиндексации в Гугл занимает не так много времени, примерно 2 недели хватит, а может и меньше. Вот в Яндекс по сложнее с этим, я и не удивлен. Яндекс всегда был тугой в этом плане. В первое время у вас обнулится ТИЦ, если он у вас был и в первый же апдейт ТИЦа должен будет вернуться. Это я написал, чтобы вы не пугались. Ну а далее в Яндекс Вебмастер вы обнаружите следующую картину…

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

Парус слов про Яндекс Метрику. Если у вас был установлен код яндекс метирки, то в панели метирики вам придется добавить сайт заново с протоколом https.

Переход на HTTPS в Joomla

Обновлено — 15.12.2016

В последних версиях Joomla с переходом на https не должно возникнуть проблем. В файл .htaccess не обязательно добавлять директивы редиректов, движок сам перекинет с http на https. Для этого необходимо просто включить опцию в общих настройках Joomla — «Сервер» -> «Включить SSL» -> «Весь сайт».

Важно! Включайте данную опцию именно тогда, когда вы уверены, что сертификат у вас уже установлен и сайт доступен по протоколу Https.

Переключение на https в глобальных настройках Joomla

Ошибка при переходе на Https в Joomla

Один раз у меня было такое, что мне пришлось немного потрудиться, на одном из клиентских сайтов переход на https прошел не так гладко. Браузер ругался на относительные адреса загружаемых ресурсов, хотя адреса были указаны относительными вне зависимости от протокола. Проблема была в теге <base />. Давайте расскажу по порядку.

Помимо тех настроек сайта, что были указаны выше нам необходимо открыть файл configuration.php и в поле live_site вписать абсолютный адрес с проколом https.

public $live_site = 'https://sitename.ru';

По идее после этой настройки в теге <base /> адрес сайта должен быть указан с протоколом https. Но нет, он был указан с протоколом http, от того и пошли все ошибки. Поискал решение проблемы в интернете, конкретно на форуме joomlaforum.ru и нашел решение. Необходимо было сделать некоторый хак ядра, правда уверяли, что после обновления данные изменения не затрутся. Открываем файл — /libraries/joomla/document/renderer/html/head.php и заменяем (77 строка)

$buffer .= $tab . '<base href="' . $base . '" />' . $lnEnd;

на

$buffer .= $tab . '<base href="' . Juri::base() . '" />' . $lnEnd;

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

Пока я эту проблему так и не решил. Не понимаю почему так происходит — версия движка последняя.

После этих действий все пришло в норму. Также в общих настройках Joomla, включил SSL. Ее включение привело к неработоспособности сайта. Если вдруг вы выбрали опцию «Весь сайт» и сайт перестал работать, то вам необходимо открыть файл configuration.php по Ftp, найти $force_ssl и установить значение на 0.

public $force_ssl = '0';

После этого сайт заработает.

Переход на HTTPS в WordPress

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

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

На этом и завершу. Всем спасибо за внимание. Не стесняемся, задаем вопросы в комментариях.

zaurmag.ru

Как установить и настроить протокол 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 за 4 шага
Вчера решил, что хватит это терпеть и пора перевести свой сайт с http на https. По случаю решил описать весь процесс, как я его делаю. Честно говоря преследую этим еще одну цель — когда меня в очередной раз попросят помочь переехать на https, я просто дам ссылку на подробное руководство.
HTTP, HTTP/2, HTTPS, SSL — о чем речь?
Hypertext Transfer Protocol (HTTP) — это основном протокол связи, который используется на любом сайте для установки соединения.
HTTP/2 — более современный протокол, в котором добавлены увеличивающие производительность и безопасность.
HTTPS — расширение протокола HTTP, которое поддерживает шифрование.
Secure Sockets Layer (SSL) — криптографический протокол для безопасной связи.
Переход на https — зачем мне это?
Я бы выделил 4 причины:
Забота о безопасности данных: сейчас по этой теме сходят все с ума (раньше все клали с пробором, но теперь…). Для сайтов работающих с деньгами и онлайн оплатой — это острая необходимость, т.к. шифруются все данные. Для простых информационных ресурсов — вас все равно заставят перейти на https, т.ч. выбора особо нет.
Это фактор ранжирования: и Яндекс и Google открыто об этом говорили. Если раньше только Гугл заставлял переводить сайты на https, то сейчас за это взялось зеркало Рунета и с 24 января 2019 года в вебмастере уже многие увидели предупреждение:
Предупреждение в Яндекс Вебмастере
Т.е. это благотворно скажется на ваших позициях и трафике с поисковых систем (на самом деле нет, чаще вообще никак не скажется 🙂 )
Больше доверия со стороны пользователей. Когда посетитель видит в браузере метку:
Меня это не пугает и я все равно юзаю сервис 🙂
Это может его отпугнуть/насторожить, особенно если это человек не сильно понимающий сути происходящего.
Ради HTTP/2 и большей скорости, которая так же является фактором ранжирования. В среднем прирост по скорости достигает 20-30% практически за 20-30 минут работы.
Ну а теперь перейдем к пошаговому плану по переходу с http на защищенный протокол https.
Шаг 1: Подготовка сайта
Многих сложностей может не быть вообще, если изначально за сайтом следили и делали все чисто и без костылей.
Бэкап
Любое вмешательство в жизнь сайта (если это не простые действия с контентом или вы не самоуверенный программист) начинается с бэкапа, т.к. в случае появления проблем — вы быстро восстанавливаете данные и программист уходит все делать на своем серваке.
Относительные ссылки
Когда на сайте абсолютные ссылки вида http://romanus.ru/page-name — это может быть проблемой, т.к. их нужно:
Либо заменить на относительные вида /page-name;
Либо в абсолютных заменить протокол на https.
Я бы выбирал 1 вариант, т.к. он более гибкий и пригодится не только в решении текущей задачи. Однако и там есть свои минусы, но это не тема данной статьи.
Уверен, на любом сайте вы найдете волшебную таблетку (пример замены домена в статьях):

Пример замены домена через SQL-запрос: кто-то его проверял?
Почему люди везде это пишут — хз, видимо никто не проверял работоспособность т.к. этот вариант просто не работает. SQL запрос не может заменить домен в ячейке, содержащей целый текст, т.к. это просто замена в лоб (как в Excel). Т.е. вы не можете заменить ячейку, если она не равняется вашему тексту (читай, ячейка = текст и ничего более).
Но у нас же в ячейках текст статей в html формате.
Даю 2 рабочих вариант:
Для понимающих (хотя им не нужно объяснять). Идем в PhpMyAdmin, экспортируем нашу базу данных (или конкретную таблицу, в которой нужно сделать изменения). Далее открываем редактором типа Sublime или Notepad++ и через замену все меняем. Далее импортируем исправленный вариант обратно в нашу базу данных.
Чтобы не накосячить. Во многих CMS есть плагины, которые с помощью регулярок могут делать замены (да и без них). Например, для WordPress есть хороший плагин Search Regex — который быстро и без проблем поможет сделать замену в тех местах, в которых это нужно.
Пример работы плагина Search Regex
Все пути к файлам и изображениям также должны быть изменены.
Адрес сайта
В CMS нужно изменить адрес вашего сайта на корректный, в WordPress это делается так:

Замена домена в админке WordPress
Внешние скрипты
Все внешние скрипты должны подключаться строго через https, т.к. в противном случае у вас будет смешанный протокол.
Чтобы убедиться — смотрите страницы через режим исходного кода и проходитесь поиском или любой краулер аля Screaming Frog, Netpeak и т.д.
Robots.txt и Sitemap.xml
В robots.txt чаще всего не нужно никаких изменений вносить (раньше нужно было добавить директиву для Яндекса: host: https://romanus.ru — но теперь это уже не нужно), кроме замены пути для sitemap.xml.
В самой карте сайта нужно изменить все ссылки. Если она у вас выводится автоматом + все ссылки в базе данных вы изменили — чаще всего никаких доработок не понадобится. Но лучше перепроверить:

В sitemap.xml не должно быть ссылок на незащищенный протокол
P.S. Многие рекомендуют делать исключения в .htaccess, чтобы robots.txt открывался по 2 протоколам. Я не делаю этого — проблем не замечал, но держу вас в курсе.
Шаг 2: Покупка SSL сертификата
Прежде чем приобретать SSL нам нужно определиться с нашими потребностями.
Типы ssl
Все сертификаты выдаются для 1 домена:
С проверкой домена (DV): отлично подойдет для блогов, сайтов-визиток, интернет-магазинов и любых сайтов, для которых важно само наличие SSL. Стоит дешево, выдается быстро., замок показывается в браузере.
С проверкой компании (OV): вариант для тех, кому важно большее доверие, т.к. центр сертификации проверяет принадлежность компании к домену. Нужно крупным компаниям и магазинам. Делается за 3 дня.
С расширенной проверкой (EV): максимальное доверие к компании, т.к. выдается только юридическим лицам и центр сертификации проверяет больше данных. Делается за 7-10 дней, стоит дорого, но вы получаете в браузере вывод вашей компании:
Пример отображения в браузере EV сертификата
Если у вас много поддоменов и вы хотите их перевести на https — стоит обратить внимание на сертификаты с пометкой Wildcard (количество поддоменов неограниченно).
Активация https для домена
После того, как вы решили какой тип сертификата вам нужен, купили его (свои сертификаты я покупал на gogetssl.com, а для блога решил потестить бесплатный Let’s Encrypt) и не забыли сохранить все ключи, которые вам были даны — самое время привязать все к вашему домену.
После активации домена он должен пройти валидацию:

Валидация домена пройдена
Все, теперь можно переходить к следующему шагу.
Бесплатный SSL от Let’s Encrypt
Let’s Ecnrypt — это некоммерческий центр сертификации. Вы можете без проблем взять их бесплатный сертификат, если вам важно само наличие https.
Яндекс и Google (а также браузеры) нормально относятся к нему, т.е. никаких трудностей у вас не будет.

У хостеров бесплатный сертификат подключается за 1 минуту
На многих хостингах можно буквально за минуту подключить бесплатный SSL.
Установка SSL на примере FastVPS
У вас есть ключи и все что вам нужно сделать — это добавить их в панели своего хостинга.

Просто вставить в поля свои ключи от центра сертификации
Шаг 3: Оповещаем поисковые системы
После покупки и установки сертификата на подготовленный сайт мы можем оповестить о наших действиях поисковые системы Яндекс и Google в их кабинетах.
Яндекс.Вебмастер
Добавляем версию с https в панель вебмастера;
На старом зеркале с http заходим в переезд сайта и ставим галочку;
Залить новую карту сайта;
Не забыть поставить регион
Меняем зеркало в Яндекс Вебмастере
По сути в Яндексе переезд на https осуществляется 1 галочкой + перенести свежие данные.
Google Search Console
Самое страшное, что может произойти во время переезда сайта на https в Гугл — забыть перенести Disavow файл, потому краткий чек-лист:
Добавить новое зеркало с https;
Если у вас были отклонены ссылки через Disavow Links — нужно обязательно обновить данные;
Добавить карту сайта;
Шаг 4: 301-редирект с http на https
Здесь все сложно и просто одновременно. Подробная статья о 301 редиректах с примерами, рекомендую изучить.
Скорее всего вам подойдет один из вариантов:
RewriteCond %{SERVER_PORT} !^443$ RewriteRule ^(.*)$ https://site.ru/$1 [R=301,L]
или
RewriteEngine on RewriteCond %{ENV:HTTPS} !on RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [NC,R=301,L]
Если варианты не подошли — дергаем программиста с просьбой “склеить 301 редиректом все страницы на http со страницами на https” соответственно.
Шаг 5: Ожидание переиндексации
Если вы нигде не накосячили то склейка происходит довольно быстро: 1-2 недели в Google и 2-4 недели в Яндексе.
Все нормально:
Если у вас были скрипты репостов — они будут показывать 0, т.к. http и https это 2 разные версии;
Сайт временно может падать по трафику и позициям в момент склейки. После всей процедуры с большей вероятностью все восстановится;
Ссылки будут переклеены в среднем от 4 недель до пары месяцев;
Вроде все страхи описал.
Поздравляю, теперь у вас рабочий сайт на https, проверить можно на https://www.ssllabs.com/ssltest/:

Проверка корректности SSL
13 популярных ошибок при переходе сайта на https
Пишу самые популярные моменты, которые знаю из своего опыта или опыта коллег:
Сделать 302 редирект вместо 301 для склейки версий http с https;
Сделать редирект всех внутренних страниц на главную;
Допустить цикличные редиректы;
Забыл, что твой сайт без www, но склеить с https://www.site.ru;
Забыл прописать новый путь для sitemap.xml;
Пропустил этап с заменой абсолютных ссылок;
Не изменил урлы в скриптах и медиа-контенте;
В карте сайта указаны урлы на версию с http;
Описался при наборе домена при получении сертификата;
Может сломаться 1С, если забыли обновить данные;
Сайт интегрирован с различными API и вы забыли изменить адреса;
Косяки с rel=”canonical” на старые страницы;
Не очистил кэш и начал сам себе выдумывать проблемы.
А с какими косяками вы сталкивались?
Ответы на несколько вопросов
Напоследок несколько популярных вопросов, которые могут всплыть:
Почему сам тянул с переездом на https?
Я все никак не могу взяться за свои проекты (это видно по дате последних постов и съемки видео на канале), ну и решающим моментом стало оповещение Яндекса о том, что уже пора бы.
Могу ли я потерять посещаемость?
Да. Любые действия с сайтом в теории могут негативно повлиять на трафик. Но чаще проблем не бывает, если нигде не напортачил.
После перехода на https упали позиции, что делать?
Это тоже нормально. От момента переезда я обычно засекаю 3-4 недели (примерно) и не обращаю внимания на колебания. По истечении этого срока уже должна произойти склейка (в вебмастере зеркала будут слеплены вместе) и тогда можно делать какие-то выводы. Чаще всего все восстанавливается и иногда даже с плюсом.
Я хочу ЧПУ и SSL — в какой последовательности делать
Очень скользкий вопрос, сродни «Какой рукой открывать дверь: правой или левой?». Я опасный и потому делаю все сразу за 1 раз :). Проблем вроде не было, но склейка была дольше.
romanus.ru
Простым языком об HTTP / Habr
Вашему вниманию предлагается описание основных аспектов протокола HTTP — сетевого протокола, с начала 90-х и по сей день позволяющего вашему браузеру загружать веб-страницы. Данная статья написана для тех, кто только начинает работать с компьютерными сетями и заниматься разработкой сетевых приложений, и кому пока что сложно самостоятельно читать официальные спецификации.
HTTP — широко распространённый протокол передачи данных, изначально предназначенный для передачи гипертекстовых документов (то есть документов, которые могут содержать ссылки, позволяющие организовать переход к другим документам).
Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol, «протокол передачи гипертекста». В соответствии со спецификацией OSI, HTTP является протоколом прикладного (верхнего, 7-го) уровня. Актуальная на данный момент версия протокола, HTTP 1.1, описана в спецификации RFC 2616.
Протокол HTTP предполагает использование клиент-серверной структуры передачи данных. Клиентское приложение формирует запрос и отправляет его на сервер, после чего серверное программное обеспечение обрабатывает данный запрос, формирует ответ и передаёт его обратно клиенту. После этого клиентское приложение может продолжить отправлять другие запросы, которые будут обработаны аналогичным образом.
Задача, которая традиционно решается с помощью протокола HTTP — обмен данными между пользовательским приложением, осуществляющим доступ к веб-ресурсам (обычно это веб-браузер) и веб-сервером. На данный момент именно благодаря протоколу HTTP обеспечивается работа Всемирной паутины.

Также HTTP часто используется как протокол передачи информации для других протоколов прикладного уровня, таких как SOAP, XML-RPC и WebDAV. В таком случае говорят, что протокол HTTP используется как «транспорт».
API многих программных продуктов также подразумевает использование HTTP для передачи данных — сами данные при этом могут иметь любой формат, например, XML или JSON.
Как правило, передача данных по протоколу HTTP осуществляется через TCP/IP-соединения. Серверное программное обеспечение при этом обычно использует TCP-порт 80 (и, если порт не указан явно, то обычно клиентское программное обеспечение по умолчанию использует именно 80-й порт для открываемых HTTP-соединений), хотя может использовать и любой другой.
Как отправить HTTP-запрос?

Самый простой способ разобраться с протоколом HTTP — это попробовать обратиться к какому-нибудь веб-ресурсу вручную. Представьте, что вы браузер, и у вас есть пользователь, который очень хочет прочитать статьи Анатолия Ализара.
Предположим, что он ввёл в адресной строке следующее:
http://alizar.habrahabr.ru/
Соответственно вам, как веб-браузеру, теперь необходимо подключиться к веб-серверу по адресу alizar.habrahabr.ru.
Для этого вы можете воспользоваться любой подходящей утилитой командной строки. Например, telnet:
telnet alizar.habrahabr.ru 80
Сразу уточню, что если вы вдруг передумаете, то нажмите Ctrl + «]», и затем ввод — это позволит вам закрыть HTTP-соединение. Помимо telnet можете попробовать nc (или ncat) — по вкусу.
После того, как вы подключитесь к серверу, нужно отправить HTTP-запрос. Это, кстати, очень легко — HTTP-запросы могут состоять всего из двух строчек.
Для того, чтобы сформировать HTTP-запрос, необходимо составить стартовую строку, а также задать по крайней мере один заголовок — это заголовок Host, который является обязательным, и должен присутствовать в каждом запросе. Дело в том, что преобразование доменного имени в IP-адрес осуществляется на стороне клиента, и, соответственно, когда вы открываете TCP-соединение, то удалённый сервер не обладает никакой информацией о том, какой именно адрес использовался для соединения: это мог быть, например, адрес alizar.habrahabr.ru, habrahabr.ru или m.habrahabr.ru — и во всех этих случаях ответ может отличаться. Однако фактически сетевое соединение во всех случаях открывается с узлом 212.24.43.44, и даже если первоначально при открытии соединения был задан не этот IP-адрес, а какое-либо доменное имя, то сервер об этом никак не информируется — и именно поэтому этот адрес необходимо передать в заголовке Host.
Стартовая (начальная) строка запроса для HTTP 1.1 составляется по следующей схеме:
Метод URI HTTP/Версия
Например (такая стартовая строка может указывать на то, что запрашивается главная страница сайта):
GET / HTTP/1.1
Метод (в англоязычной тематической литературе используется слово method, а также иногда слово verb — «глагол») представляет собой последовательность из любых символов, кроме управляющих и разделителей, и определяет операцию, которую нужно осуществить с указанным ресурсом. Спецификация HTTP 1.1 не ограничивает количество разных методов, которые могут быть использованы, однако в целях соответствия общим стандартам и сохранения совместимости с максимально широким спектром программного обеспечения как правило используются лишь некоторые, наиболее стандартные методы, смысл которых однозначно раскрыт в спецификации протокола.
URI (Uniform Resource Identifier, унифицированный идентификатор ресурса) — путь до конкретного ресурса (например, документа), над которым необходимо осуществить операцию (например, в случае использования метода GET подразумевается получение ресурса). Некоторые запросы могут не относиться к какому-либо ресурсу, в этом случае вместо URI в стартовую строку может быть добавлена звёздочка (астериск, символ «*»). Например, это может быть запрос, который относится к самому веб-серверу, а не какому-либо конкретному ресурсу. В этом случае стартовая строка может выглядеть так:
OPTIONS * HTTP/1.1
Версия определяет, в соответствии с какой версией стандарта HTTP составлен запрос. Указывается как два числа, разделённых точкой (например 1.1).
Для того, чтобы обратиться к веб-странице по определённому адресу (в данном случае путь к ресурсу — это «/»), нам следует отправить следующий запрос:
GET / HTTP/1.1
Host: alizar.habrahabr.ru
При этом учитывайте, что для переноса строки следует использовать символ возврата каретки (Carriage Return), за которым следует символ перевода строки (Line Feed). После объявления последнего заголовка последовательность символов для переноса строки добавляется дважды.
Впрочем, в спецификации HTTP рекомендуется программировать HTTP-сервер таким образом, чтобы при обработке запросов в качестве межстрочного разделителя воспринимался символ LF, а предшествующий символ CR, при наличии такового, игнорировался. Соответственно, на практике бо́льшая часть серверов корректно обработает и такой запрос, где заголовки отделены символом LF, и он же дважды добавлен после объявления последнего заголовка.
Если вы хотите отправить запрос в точном соответствии со спецификацией, можете воспользоваться управляющими последовательностями \r и \n:
echo -en "GET / HTTP/1.1\r\nHost: alizar.habrahabr.ru\r\n\r\n" | ncat alizar.habrahabr.ru 80
Как прочитать ответ?

Стартовая строка ответа имеет следующую структуру:
HTTP/Версия Код состояния Пояснение
Версия протокола здесь задаётся так же, как в запросе.
Код состояния (Status Code) — три цифры (первая из которых указывает на класс состояния), которые определяют результат совершения запроса. Например, в случае, если был использован метод GET, и сервер предоставляет ресурс с указанным идентификатором, то такое состояние задаётся с помощью кода 200. Если сервер сообщает о том, что такого ресурса не существует — 404. Если сервер сообщает о том, что не может предоставить доступ к данному ресурсу по причине отсутствия необходимых привилегий у клиента, то используется код 403. Спецификация HTTP 1.1 определяет 40 различных кодов HTTP, а также допускается расширение протокола и использование дополнительных кодов состояний.
Пояснение к коду состояния (Reason Phrase) — текстовое (но не включающее символы CR и LF) пояснение к коду ответа, предназначено для упрощения чтения ответа человеком. Пояснение может не учитываться клиентским программным обеспечением, а также может отличаться от стандартного в некоторых реализациях серверного ПО.
После стартовой строки следуют заголовки, а также тело ответа. Например:
HTTP/1.1 200 OK Server: nginx/1.2.1 Date: Sat, 08 Mar 2014 22:53:46 GMT Content-Type: application/octet-stream Content-Length: 7 Last-Modified: Sat, 08 Mar 2014 22:53:30 GMT Connection: keep-alive Accept-Ranges: bytes Wisdom

Тело ответа следует через два переноса строки после последнего заголовка. Для определения окончания тела ответа используется значение заголовка Content-Length (в данном случае ответ содержит 7 восьмеричных байтов: слово «Wisdom» и символ переноса строки).
Но вот по тому запросу, который мы составили ранее, веб-сервер вернёт ответ не с кодом 200, а с кодом 302. Таким образом он сообщает клиенту о том, что обращаться к данному ресурсу на данный момент нужно по другому адресу.
Смотрите сами:
HTTP/1.1 302 Moved Temporarily Server: nginx Date: Sat, 08 Mar 2014 22:29:53 GMT Content-Type: text/html Content-Length: 154 Connection: keep-alive Keep-Alive: timeout=25 Location: http://habrahabr.ru/users/alizar/ <html> <head><title>302 Found</title></head> <body bgcolor="white"> <center><h2>302 Found</h2></center> <hr><center>nginx</center> </body> </html>

В заголовке Location передан новый адрес. Теперь URI (идентификатор ресурса) изменился на /users/alizar/, а обращаться нужно на этот раз к серверу по адресу habrahabr.ru (впрочем, в данном случае это тот же самый сервер), и его же указывать в заголовке Host.
То есть:
GET /users/alizar/ HTTP/1.1
Host: habrahabr.ru
В ответ на этот запрос веб-сервер Хабрахабра уже выдаст ответ с кодом 200 и достаточно большой документ в формате HTML.
Если вы уже успели вжиться в роль, то можете теперь прочитать полученный от сервера HTML-код, взять карандаш и блокнот, и нарисовать профайл Ализара — в принципе, именно этим бы на вашем месте браузер сейчас и занялся.
А что с безопасностью?

Сам по себе протокол HTTP не предполагает использование шифрования для передачи информации. Тем не менее, для HTTP есть распространённое расширение, которое реализует упаковку передаваемых данных в криптографический протокол SSL или TLS.
Название этого расширения — HTTPS (HyperText Transfer Protocol Secure). Для HTTPS-соединений обычно используется TCP-порт 443. HTTPS широко используется для защиты информации от перехвата, а также, как правило, обеспечивает защиту от атак вида man-in-the-middle — в том случае, если сертификат проверяется на клиенте, и при этом приватный ключ сертификата не был скомпрометирован, пользователь не подтверждал использование неподписанного сертификата, и на компьютере пользователя не были внедрены сертификаты центра сертификации злоумышленника.
На данный момент HTTPS поддерживается всеми популярными веб-браузерами.
А есть дополнительные возможности?

Протокол HTTP предполагает достаточно большое количество возможностей для расширения. В частности, спецификация HTTP 1.1 предполагает возможность использования заголовка Upgrade для переключения на обмен данными по другому протоколу. Запрос с таким заголовком отправляется клиентом. Если серверу требуется произвести переход на обмен данными по другому протоколу, то он может вернуть клиенту ответ со статусом «426 Upgrade Required», и в этом случае клиент может отправить новый запрос, уже с заголовком Upgrade.
Такая возможность используется, в частности, для организации обмена данными по протоколу WebSocket (протокол, описанный в спецификации RFC 6455, позволяющий обеим сторонам передавать данные в нужный момент, без отправки дополнительных HTTP-запросов): стандартное «рукопожатие» (handshake) сводится к отправке HTTP-запроса с заголовком Upgrade, имеющим значение «websocket», на который сервер возвращает ответ с состоянием «101 Switching Protocols», и далее любая сторона может начать передавать данные уже по протоколу WebSocket.
Что-то ещё, кстати, используют?

На данный момент существуют и другие протоколы, предназначенные для передачи веб-содержимого. В частности, протокол SPDY (произносится как английское слово speedy, не является аббревиатурой) является модификацией протокола HTTP, цель которой — уменьшить задержки при загрузке веб-страниц, а также обеспечить дополнительную безопасность.
Увеличение скорости обеспечивается посредством сжатия, приоритизации и мультиплексирования дополнительных ресурсов, необходимых для веб-страницы, чтобы все данные можно было передать в рамках одного соединения.
Опубликованный в ноябре 2012 года черновик спецификации протокола HTTP 2.0 (следующая версия протокола HTTP после версии 1.1, окончательная спецификация для которой была опубликована в 1999) базируется на спецификации протокола SPDY.
Многие архитектурные решения, используемые в протоколе SPDY, а также в других предложенных реализациях, которые рабочая группа httpbis рассматривала в ходе подготовки черновика спецификации HTTP 2.0, уже ранее были получены в ходе разработки протокола HTTP-NG, однако работы над протоколом HTTP-NG были прекращены в 1998.
На данный момент поддержка протокола SPDY есть в браузерах Firefox, Chromium/Chrome, Opera, Internet Exporer и Amazon Silk.
И что, всё?

В общем-то, да. Можно было бы описать конкретные методы и заголовки, но фактически эти знания нужны скорее в том случае, если вы пишете что-то конкретное (например, веб-сервер или какое-то клиентское программное обеспечение, которое связывается с серверами через HTTP), и для базового понимания принципа работы протокола не требуются. К тому же, всё это вы можете очень легко найти через Google — эта информация есть и в спецификациях, и в Википедии, и много где ещё.
Впрочем, если вы знаете английский и хотите углубиться в изучение не только самого HTTP, но и используемых для передачи пакетов TCP/IP, то рекомендую прочитать вот эту статью.
Ну и, конечно, не забывайте, что любая технология становится намного проще и понятнее тогда, когда вы фактически начинаете ей пользоваться.
Удачи и плодотворного обучения!
habr.com
No related posts.