Это плохо, чтобы перенаправить 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 ...

[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-фу и с трудом заработанные постраничные ранги без изменений . Убедитесь, что mod_rewriteвключен:

a2enmod rewrite

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

Это плохо, чтобы перенаправить http на https?

Конечно нет. Это очень хорошо.

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

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

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

Если вы настроили 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.

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

<VirtualHost 10.2.3.40:80>
  ServerAdmin me@example.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 Strict Transport Security (HSTS) на вашем защищенном виртуальном хосте:

<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 будет только принят браузерами , когда подается через / TLS соединение SSL!

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

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

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

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

Это плохо, чтобы перенаправить http на https?

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

На перенаправлениях:

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

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создание выделенного виртуального сервера для перенаправления входящих http-запросов на ваше соединение https, как предлагается в ответе на security.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>