Неправильно ли перенаправлять http на https?

Я только что установил SSL-сертификат на своем сервере.

Затем он настроил перенаправление для всего трафика в моем домене в порту 80, чтобы перенаправить его на порт 443.

Другими словами, весь мой трафик http://example.com теперь перенаправлен на соответствующую версию страницы https://example.com.

Перенаправление выполняется в моем файле Apache Virtual Hosts с чем-то вроде этого ...

RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L] 

Мой вопрос в том, есть ли недостатки в использовании SSL?

Так как это не 301 Redirect, я потеряю сок /рейтинг ссылок в поисковых системах, переключившись на https?

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


ОБНОВЛЕННЫЙ ВЫПУСК

Странно Bing создает этот снимок экрана с моего сайта теперь, когда он использует HTTPS везде ...

введите описание изображения здесь>> </p></body></html>

243 голоса | спросил JasonDavis 28 Jam1000000amTue, 28 Jan 2014 04:12:50 +040014 2014, 04:12:50

12 ответов


308

Флаг [R] сам по себе является перенаправлением 302 (Moved Temporarily)). Если вы действительно хотите, чтобы люди использовали HTTPS-версию вашего сайта (подсказка: вы это делаете), вы должны использовать [R=301] для постоянного перенаправления:

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

A 301 хранит все ваши страницы google-fu и с трудом заработанные нетронутым . Убедитесь, что включен mod_rewrite:

a2enmod rewrite

Чтобы ответить на ваш точный вопрос:

  

Неправильно ли перенаправить http на https?

Ад. Это очень хорошо.

ответил Mark Henderson 28 Jam1000000amTue, 28 Jan 2014 04:27:59 +040014 2014, 04:27:59
49

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

  1. Проверьте весь сайт на наличие внутренних ссылок и убедитесь, что все они используют HTTPS, если вы указываете свое собственное доменное имя в ссылках, поэтому вы не вызываете собственных переадресаций.
  2. Обновите свой <meta property="og:url" с помощью https-версии вашего домена.
  3. Если вы снова используете <base href= обновление для использования HTTPS.
  4. Установите протокол SPDY , если возможно
  5. Обязательно используйте спрайты CSS Image, где это возможно, чтобы уменьшить количество запросов.
  6. Обновите файлы Sitemap, чтобы указать статус https, поэтому пауки со временем узнают об этом изменении.
  7. Измените параметры поисковой системы, такие как Инструменты Google для веб-мастеров, чтобы предпочесть HTTPS
  8. По возможности выгружайте любые статические носители на HTNPS CDN-серверы.

Если вышеупомянутое адресовано, то я сомневаюсь, что у вас будет много проблем.

ответил TheBritishGeek 28 Jam1000000amTue, 28 Jan 2014 06:08:16 +040014 2014, 06:08:16
38

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

Относительно перенаправления с http на https ответ не так прост.

Перенаправление будет намного проще для ваших пользователей, они просто набирают whateversite.com и перенаправляются на https.

Но. Что делать, если пользователь иногда находится в незащищенной сети (или близок к Трой Хант и его ананас )? Затем пользователь будет запрашивать http://whateversite.com из старой привычки. Это http. Это может быть скомпрометировано. Перенаправление может указывать на https: //whateversite.com.some.infrastructure .long.strange.url.hacker.org . Для обычного пользователя это выглядело бы вполне законным. Но трафик может быть перехвачен.

Итак, у нас есть два конкурирующих требования: быть дружелюбным и безопасным. К счастью, есть средство, называемое заголовок HSTS . С его помощью вы можете включить перенаправление. Браузер перейдет на безопасный сайт, но благодаря заголовку HSTS также запомните его. Когда пользователь вводит в whateversite.com сидение в этой незащищенной сети, браузер сразу перейдет на https, не перепрыгивая через перенаправление через http. Если вы не имеете дело с очень чувствительными данными, я считаю, что это справедливый компромисс между безопасностью и удобством использования для большинства сайтов. (Когда я недавно создал приложение, обрабатывающее медицинские записи, я пошел на все https без перенаправления). К сожалению, Internet Explorer не поддерживает HSTS ( источник ), поэтому, если ваша целевая аудитория в основном с использованием IE, и данные чувствительны, вы можете отключить перенаправления.

Итак, если вы не нацеливаете пользователей IE, продолжайте использовать перенаправление, но также включите заголовок HSTS.

ответил Anders Abel 28 Jam1000000amTue, 28 Jan 2014 11:40:50 +040014 2014, 11:40:50
22

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

<VirtualHost 10.2.3.40:80>
  ServerAdmin [email protected]com
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>

# Insert 10.2.3.40:443 virtual host here :)

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

Если вы будете обслуживать сайт только через TLS /SSL, я бы рекомендовал следующую директиву для включения HTTP Строгая транспортная безопасность (HSTS) в виртуальном хосте secure :

<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=1234; includeSubdomains"
</IfModule>

Этот заголовок инструктирует способных клиентов (большинство из них в наши дни, я считаю), что они должны использовать HTTPS с предоставленным доменом (secure.example.com, в этом случае) для следующего 1234 секунд. ; includeSubdomains необязательный и указывает, что директива применяется не только к текущему домену, но и к любому из них (например, alpha.secure.example.com). Обратите внимание, что заголовок HSTS only принят браузерами при обслуживании через соединение SSL /TLS!

Чтобы протестировать конфигурацию вашего сервера в соответствии с текущей лучшей практикой, хороший бесплатный ресурс Тест SSL-сервера Qualys обслуживание; Я бы постарался набрать хотя бы A- (вы не можете получить больше, чем с Apache 2.2 из-за отсутствия поддержки криптографии с эллиптической кривой).

ответил Calrion 28 Jam1000000amTue, 28 Jan 2014 06:20:53 +040014 2014, 06:20:53
5

Ничего себе! перенаправление HTTP на HTTPS - очень хорошая вещь, и я не вижу никаких недостатков для этого.

Просто убедитесь, что у ваших клиентов есть правильный ЦС, чтобы избежать нежелательных предупреждений о сертификате в браузере.

Кроме того, способ, которым вы настроили Apache для перенаправления на HTTPS, выглядит нормально.

ответил krisFR 28 Jam1000000amTue, 28 Jan 2014 04:35:44 +040014 2014, 04:35:44
5
  
    

Неправильно ли перенаправить http на https?

  

Нет, совсем нет. На самом деле, это хорошо!

В переадресациях:

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

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>
ответил Pothi Kalimuthu 28 Jpm1000000pmTue, 28 Jan 2014 17:45:39 +040014 2014, 17:45:39
4

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

Но, пожалуйста, не забудьте проверить настройки SSL, такие как настройка SSLCiphers. Отключите такие вещи, как криптозащита RC4, протокол SSLv2 и протокол SSLv3. Кроме того, вы должны выяснить, поддерживают ли криптосистемные библиотеки вашей системы TLS1.2 (это то, что вы хотите иметь;))

Включите SSL, это хорошо.

ответил Tobias Mädel 28 Jam1000000amTue, 28 Jan 2014 11:43:34 +040014 2014, 11:43:34
3

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

ответил Vality 28 Jpm1000000pmTue, 28 Jan 2014 14:13:50 +040014 2014, 14:13:50
3

Вот некоторые из широких проблем с мазками:

  • MITM /SSLSTRIP . Это огромное предостережение. Если вы собираетесь обслуживать свой сайт через HTTPS, , то отключите HTTP на сайте . В противном случае вы оставите своих пользователей открытыми для различных атак типа «человек-в-середине», включая SSLSTRIP, который будет перехватывать запросы и спокойно обслуживать их через HTTP, вставляя свой собственный скрипт вредоносного ПО в поток. Если пользователь не заметит, то они будут думать , что их сеанс защищен, когда это не так.

    • Проблема с этим заключается в том, что если ваш сайт является общедоступным сайтом, и вы просто бесцеремонно отключите HTTP, вы можете потерять много посетителей. Вероятно, даже им не будет , чтобы попробовать HTTPS, если сайт не загружается с помощью HTTP.
  • Если вашему сайту требуется безопасный вход в систему, необходимо защитить весь сеанс пользователя. Не проверяйте подлинность через HTTPS, а затем перенаправляйте пользователя обратно на HTTP. Если вы это сделаете, опять же, вы оставите своих пользователей уязвимыми для атак MITM. Стандартным подходом к аутентификации в эти дни является проверка подлинности один раз, затем передача токена аутентификации взад и вперед (в файле cookie). Но если вы выполняете аутентификацию по HTTPS, то перенаправляете на HTTP, тогда человек-в-середине может перехватить этот файл cookie и использовать сайт, как если бы он был вашим аутентифицированным пользователем, минуя вашу безопасность.

  • Проблемы с производительностью с HTTPS для всех практических целей ограничиваются рукопожатием, связанным с созданием нового соединения. Сделайте все возможное, чтобы свести к минимуму необходимость использования нескольких HTTPS-соединений из URL-адреса, и вы пройдете много миль. И это откровенно верно, даже если вы обслуживаете свой контент через HTTP. Если вы читаете SPDY, вы поймете, что все, что он делает, ориентировано на попытку обслуживать весь контент с одного URL-адреса по одному соединению. Да, использование HTTPS влияет на кеширование. Но сколько веб-сайтов - это просто статический, кэшируемый контент в наши дни? Вероятнее всего, вы получите больше шансов для вашего доллара, используя кеширование на своем веб-сервере, чтобы минимизировать избыточные запросы к базе данных, которые снова и снова восстанавливали неизменные данные и предотвращали выполнение дорогих кодовых путей чаще, чем необходимо.

ответил Craig 19 PMpSat, 19 Apr 2014 14:43:59 +040043Saturday 2014, 14:43:59
1

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

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

ответил trysis 28 Jam1000000amTue, 28 Jan 2014 08:27:33 +040014 2014, 08:27:33
1

единственная техническая обратная связь с HTTPS через HTTP заключается в том, что вычислить более дорогостоящие процессы обработки HTTPS-запросов, чем простой HTTP

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

С появлением таких протоколов, как SPDY, для которых требуется SSL /TLS, это фактически противодействует вышеупомянутым вычислительным накладным расходам, давая значительные улучшения производительности в отношении нескольких запросов и получения активов клиенту в целом.

ответил anthonysomerset 29 Jpm1000000pmWed, 29 Jan 2014 15:55:12 +040014 2014, 15:55:12
1

Очень хорошо переадресовывать на https, но я читаю, это также зависит от того, как вы организуете перенаправление.

Создание выделенного виртуального сервера для перенаправления входящих HTTP-запросов на ваше https-соединение, как предлагается в ответе на безопасность .stackexchange.com звучит очень умно и закроет некоторые дополнительные угрозы безопасности. Конфигурация в Apache будет выглядеть примерно так:

# Virtual host for rerouting
<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent / https://www.example.com/
</VirtualHost>

# Virtual host for secure hosting on https
<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    Header set Strict-Transport-Security "max-age=8640000;includeSubdomains"

    ...site settings...

</VirtualHost>
ответил Wilt 5 42015vEurope/Moscow11bEurope/MoscowThu, 05 Nov 2015 12:39:42 +0300 2015, 12:39:42

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132