Редирект с http на https: Страница не найдена | REG.RU

▷ Как настроить 301 редирект с http на https-версию сайта​

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

Что бы предотвратить ошибки и проверить коректность процедуры настройки http редиректа нужно посмотреть наличие переадресации на всех страницах ресурса (можно использовать краулеры или сервисы, о них дальше). Почему это важно? Один и тот же домен с разными протоколами для поисковых систем абсолютно разные сайты и получается что два одинаковых URL с http и https будут распознаться как дубли, что сделает контент не уникальным и приведет к конкуренции в выдаче между ними. Правильно настроенный редирект с http на https приводит к автоматическому перенаправлению (301 редирект) для всех страниц с протоколом http на аналогичные страницы с протоколом https.

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

Важный момент с внутренней перелинковкой. Приучите себя использовать на сайте относительные ссылки (без префикса протокола и домена, например /page1/), а не абсолютные (с префиксом протокола и домена, например http://domen. com/page1/). Тогда не надо исправлять устаревшие ссылки с не правильным протоколом http, когда настроите редирект с https на http. Если же вы использовали на сайте абсолютные URL — необходимо их все обновить (желательно на относительные), иначе при выгрузке сайта вы увидите массу статических 301 редиректов из за не правильно указанного (старого) протокола сайта, что в какой то мере негативно скажется на ранжировании ресурса (особенно проблемны ссылки в шаблонах элементов сайта — хедер, футер, сйдбары, так как они дублируются на всех страницах сайта в зависимости, конечно, от архитектуры ресурса). Для проверки наличия статических редиректов можете использовать краулеры Netpeak Spider, ScreamingFrog, аудит Serpstat или подобные инструменты. Так вы сможете быстро определить проблемные страницы.

Редирект с http на https с помощью .htaccess — Skyal Team

В обычном состоянии сайт работает по не защищённом протоколу http. Чтобы обеспечить защищённое соединение и доступ сайта по протоколу https необходимо вначале установить SSL-сертификат в хостинг-панели. Но сама по себе установка SSL-сертификата не обеспечит постоянный доступ сайта по безопасному соединению. Нужно ещё настроить перенаправление (редирект) с http на https. После настройки, браузер начнёт автоматически перенаправлять посетителей сайта по защищённому протоколу.

Содержание:

1. Редирект всех страниц с http на https
2. Редирект на https только выбранной страницы
3. Редирект на https всех страниц, кроме одной

Хотим обратить ваше внимание на то, что данный метод перенаправления подходит для Linux-серверов.

Также, если у вас на хостинге используется панель управления ISPmanager 5 или Plesk, переадресацию можно настроить средствами панели управления всего за пару кликов.

Настройка редиректа через .htaccess

1. Войдите в панель управления хостингом.
2. Откройте файл .htaccess, расположенный в корневой папке сайта.
3. Добавьте в конец файла одно из правил, которое больше всего подходит. /test.php RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L]

   Обратите внимание!

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

   Метки записи: #htaccess

   Похожие записи

   Безопасность

   . Является ли перенаправление http на https плохой идеей?

   спросил 11 лет, 11 месяцев назад

   Изменено 4 года, 10 месяцев назад

   Просмотрено 41к раз

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

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

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

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

   • безопасность
   • ssl
   • https

   1

   HTTP-запрос, содержащий файл cookie с идентификатором сеанса, подвергается атакам с перехватом сеанса.

   Важно, что если вы разрешаете HTTP и перенаправляете на HTTPS, эти файлы cookie помечаются как безопасные.

   Я также не вижу никаких технических причин, по которым HTTP должен быть полностью заблокирован, и многие сайты перенаправляют HTTP на HTTPS. При этом настоятельно рекомендуется реализовать HTTP Strict Transport Security (HSTS), который представляет собой механизм веб-безопасности, который объявляет, что браузеры должны использовать только соединения HTTPS.

   HSTS реализуется путем указания заголовка ответа, такого как Strict-Transport-Security: max-age=31536000 . Соответствующие требованиям пользовательские агенты автоматически превращают небезопасные ссылки в безопасные, тем самым снижая риск атак типа «человек посередине». Кроме того, если существует риск того, что сертификат не является безопасным, например. корневой центр не распознается, отображается сообщение об ошибке, а ответ не отображается.

   5

   Переход с HTTP на HTTPS на самом деле не очень хорошая идея.

   Например, злоумышленник может провести атаку «человек посередине», используя такой инструмент, как ssl strip. Для решения этой проблемы следует использовать протокол HSTS. Он поддерживается всеми основными браузерами (Internet Explorer, который является последним пользователем, поддерживает его, начиная с IE12), и используется многими ведущими сайтами (например, Paypal, Google).

   6

   Я не вижу никакого технического риска (кроме того, что в обновлении в конце моего ответа) при перенаправлении с HTTP на HTTPS. Например, gmail и yahoo mail делают это. Вы можете проверить это с помощью инструмента отладки HTTP (например, Fiddler), где вы можете четко указать ответ перенаправления 302, возвращаемый сервером.

   Я считаю, что блокировка — плохая идея с точки зрения удобства использования. Часто пользователи вводят адрес в браузере, не указывая HTTP или HTTPS. Например, я получаю доступ к Gmail, набирая «mail.google. com», который по умолчанию «http://mail.google.com» и который автоматически перенаправляется на «https://mail.google.com». Без автоматического перенаправления мне всегда придется вводить полный адрес.

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

   Обновление @Педро и @Сполто правы. Особое внимание следует уделить чувствительным файлам cookie (таким как файлы cookie сеанса или аутентификации), которые действительно должны быть помечены как безопасные, чтобы они могли передаваться только по протоколу HTTPS. Я пропустил это. +1 вы оба, ребята.

   1

   Я только сейчас заметил этот вопрос, но уже написал пару ответов на похожие вопросы:

   • Webmasters. SE: Как запретить доступ к сайту без SSL-соединения?
   • Принудительно использовать HTTPS для определенного URL-адреса

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

   Пользователь также несет исключительную ответственность за проверку того, что он использует HTTPS (и что сертификат проверен без предупреждения), когда он этого ожидает.

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

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

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

   С технической точки зрения, IMO не имеет никаких побочных эффектов, кроме того, что принимает HTTPS.

   С точки зрения UX/UI рекомендуется использовать перенаправление по клику или отложенное перенаправление, предоставляя визуальную индикацию, чтобы в первую очередь попросить людей ввести URL-адрес HTTPS, поскольку само перенаправление подвергается атаке MITM. Однако не многие веб-сайты HTTPS делают это, потому что они предоставляют визуальные эффекты, предлагающие людям искать значок блокировки в браузере на своих страницах HTTPS.

   Это вполне приемлемый метод «загрузки» — 301 редирект с HTTP на HTTPS, а затем на стороне HTTPS возвращает заголовок Strict-Transport-Security, чтобы заблокировать браузер в HTTPS.

   Было бы серьезной проблемой для удобства использования полностью заблокировать HTTP, так как веб-браузеры будут пытаться использовать протокол HTTP, когда URL-адрес вводится без указателя протокола, если только браузер не поддерживает HSTS, а токен HSTS находится либо в кеше браузера, либо в список предварительной загрузки.

   Зарегистрируйтесь или войдите в систему

   Зарегистрируйтесь с помощью Google

   Зарегистрироваться через Facebook

   Зарегистрируйтесь, используя адрес электронной почты и пароль

   Опубликовать как гость

   Электронная почта

   Требуется, но не отображается

   Опубликовать как гость

   Электронная почта

   Требуется, но не отображается

   Перенаправить HTTP на HTTPS с Windows IIS 10

   В этом руководстве показано, как настроить веб-сайт в IIS 10, чтобы все входящие ссылки http:// на сайт перенаправлялись на их безопасные версии https:// .

   Чтобы получить дополнительные полезные инструкции и последние новости о кибербезопасности, подпишитесь на информационный бюллетень SSL.com здесь:

   1. Загрузите и установите модуль IIS URL Rewrite, затем запустите IIS Manager.
      
   2. Выберите веб-сайт, к которому вы хотите применить перенаправление, затем дважды щелкните URL Rewrite .
      
   3. Нажмите Добавить правило(а)…
      
   4. Выберите Пустое правило в разделе Правила для входящих подключений , затем нажмите кнопку OK .
      
   5. Дайте своему перенаправлению легко запоминающееся имя.
      
   6. В разделе Matched URL :
      • Установить Запрошенный URL: от до Соответствует шаблону .
      • Установить с помощью — регулярных выражений .
      • Введите (.*) в качестве шаблона .
      • Проверить Игнорировать регистр .
   7. Прокрутите вниз до Условия и при необходимости разверните раздел. Выберите Match All для Логическая группировка , затем нажмите кнопку Add… .
      
   8. Откроется диалоговое окно:
      • Введите {HTTPS} в 9OFF$ в поле Pattern.
      • Проверить Игнорировать регистр .
      • Нажмите кнопку OK .
   9. Теперь вы должны увидеть свое состояние в списке.
      
   10. Прокрутите вниз до раздела Действие и введите следующие параметры:
       • Выберите Перенаправление в качестве типа действия .
       • Введите https://{HTTP_HOST}/{REQUEST_URI} в поле Перезаписать URL-адрес .
       • Снимите флажок Добавить строку запроса .
       • Установить Тип перенаправления на Постоянный (301) .
   11. Нажмите Применить в правом меню Действия .
       
   12. Теперь вы можете проверить перенаправление в веб-браузере. Если есть какие-либо проблемы, вы можете проверить файл web.config сайта, чтобы убедиться, что он содержит правильную информацию. В диспетчере IIS щелкните правой кнопкой мыши свой сайт и выберите Исследовать в меню.
       
   13. Убедитесь, что файл web.config существует, затем откройте его в текстовом редакторе.
       
   14. Убедитесь, что web.

       No related posts.