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

247

Я только что установил сертификат 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 ...

введите описание изображения здесь

JasonDavis
источник
12
[WTF - я не могу добавить ответ (хотя, кажется, у меня достаточно репутации).] Мой ответ будет (частично), что ИНОГДА ЭТО ПЛОХО . Подумайте о передаче ключа COOKIE или API в GET через HTTP. Если ваш сайт перенаправляет HTTP-запросы на HTTPS-запросы, эти вызовы будут работать, но ключ COOKIE или API будет передаваться в открытом виде. Некоторые API отключают HTTP, более надежный подход - вообще нет HTTP, поэтому вы не сможете даже заставить его работать, если не используете HTTPS. Пример: «Все запросы API должны быть сделаны через HTTPS. Вызовы, сделанные по обычному
codingoutloud
8
@codingoutloud - альтернатива в том, что все это происходит через HTTP без HTTPS вообще. Чем это лучше?
Марк Хендерсон
3
@BenCrowell, это потому, что захваченный портал очень похож на sslstripатаку с перенаправлением в стиле (они оба перехватывают запросы типа « человек посередине»), поэтому браузеры, защищенные HSTS , блокируют их оба.
Джеффри Хантин
3
Имейте в виду, что использование https означает, что все, что вы включаете, также должно быть https, иначе он может не загружаться - например, загружать с помощью jquery src="://example.com/jquery.js"- обратите внимание на отсутствие httpили httpsпоэтому браузер загружает соответствующий. У меня был кошмар, когда я пытался заставить некоторые встроенные вещи Amazon загружаться должным образом, поскольку API (загруженный через https) создавал ссылки http - это означало, что они не работали должным образом, пока я не нашел недокументированный параметр для переключения ссылок https
Basic
3
Джейсон; Ваше обновление должно быть новым вопросом, вероятно, для веб-мастеров, поскольку оно не связано (технически) с вашим первоначальным вопросом. Но, вероятно, ваши таблицы стилей происходят из небезопасного домена.
Марк Хендерсон

Ответы:

316

[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?

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

Марк Хендерсон
источник
3
Спасибо за информацию, мой босс говорит мне, что он запускает https только на определенных страницах своего сайта, потому что он использует гораздо больше ресурсов сервера для запуска на каждой странице. Вы знаете что-нибудь об этом или это правда?
JasonDavis
9
@jasondavis Только если вы не потратите несколько минут на его оптимизацию .
Майкл Хэмптон
10
«он использует гораздо больше ресурсов сервера для запуска на каждой странице». Современные процессоры имеют функции ускорения шифрования, которые делают SSL практически бесплатным. Не беспокойся о накладных расходах.
Адам Дэвис
41
@AdamDavis Криптоалгоритм может быть легковесным, но издержки рукопожатия все еще существуют. Кроме того, HTTPS не позволяет HTTP-прокси кэшировать ваш контент. В большинстве случаев издержки HTTPS минимальны и целесообразны, но будьте осторожны с чрезмерным обобщением.
200_success
6
Он убивает общее кэширование, что полезно для некоторых шаблонов использования сайта и часто мало защищает (важно, чтобы люди знали, что вы посетили сайт, но не детали того, что вы делали? Это единственная ситуация, когда SSL полезен). Основное преимущество SSL на каждом ресурсе состоит не в том, что вам нужно «защищать», например, люди, которые смотрят «о нас», а в том, что вы не можете уклониться и не использовать его в том случае, когда вам это нужно.
Джон Ханна
49

Хотя я поддерживаю идею сайтов, использующих только 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.

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

TheBritishGeek
источник
SPDY - хорошее предложение; там даже , кажется, модуль добавления поддержки SPDY в Apache 2.x .
Калрион
18
Использование «//yourserver.com/some-uri» вместо « yourserver.com/some-uri » решает проблему (1), поскольку браузер выберет соответствующую схему (http или https) в зависимости от схемы, с которой страница была загружена ,
MauganRa
1
@MauganRa Если, конечно, это не ссылка со страницы статьи http на страницу входа https, например.
Молот
4
Google видит URL, который кто-то посещает, через Refererзаголовок. Например, этот сайт использует jQuery из CDN Google, и мой браузер отправляет запрос в Google каждый раз, когда я перезагружаю сайт. Тем самым Refererв Google также отправляется заголовок, в котором указан URL этого сайта. Таким образом, Google может отслеживать сайты, которые я посещаю в то время, когда мой IP-адрес не меняется (и если я использую службу Google в течение этого времени, Google также может связать эту информацию с моей учетной записью Google).
Стефан Кулла
1
1) Я только что выполнил поиск и заменил в своей базе данных MySQL http на https ... я использую WordPress, так что стало очень легко обновлять сотни ссылок
JasonDavis
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.

Андерс Абель
источник
Больше людей должны обратить на это внимание. Другое дело, что люди предполагают, что они безопасны, потому что конечной точкой является HTTPS, игнорируя тот факт, что вся информация, отправляемая на страницу в GET или POST, представлена ​​в виде простого текста.
Velox
3
@Velox - я не думаю, что значение «люди предполагают, что они безопасны, потому что конечной точкой является HTTPS, игнорируя тот факт, что вся информация, отправляемая на страницу в GET или POST, находится в простом тексте», довольно точно. Хотя есть некоторые ошибки, параметры запроса GET не передаются в открытом виде во время передачи по HTTPS. См. Например: stackoverflow.com/questions/323200/… Полезные нагрузки POST также защищены, но также не уязвимы для журналирования и заголовков реферера.
codingoutloud
@codingoutloud Это моя точка зрения. По HTTPS они шифруются, но при первоначальном запросе к странице HTTP их не было.
Velox
1
@Velox - если весь сайт перенаправляется на HTTPS, маловероятно, что какие-либо параметры GET будут отправлены до того, как HTTPS включится (и после этого все останется HTTPS). По-прежнему существует один первоначальный запрос, по которому будут отправляться файлы cookie, которые можно исправить с помощью HSTS ... и небольшое окно атаки на SSLStrip, которое может быть побеждено JavaScript, но это отдельная гонка вооружений.
Brilliand
@ Brilliand Справедливое замечание, но слабость в безопасности делает все это слабым. Всегда стоит задуматься.
Velox
22

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

<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 из-за отсутствия поддержки криптографии на эллиптических кривых).

Calrion
источник
Я должен добавить, что отправка заголовка Strict-Transport-Security: max-age=0сведет на нет все предыдущие директивы; как всегда, это должно быть отправлено через HTTPS, чтобы быть принятым, но это удобный способ отменить все, если вы решите, что вам также нужно использовать HTTP в домене.
Калрион
5

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

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

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

krisFR
источник
5

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

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

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

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

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>
Поти Калимуту
источник
4

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

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

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

Тобиас Медель
источник
Энтропия не израсходована ( по крайней мере, если вы защищаетесь от атакующих с Земли, а не делаете вуду ). Либо вы начинаете с недостаточной энтропии, и вы не можете делать ничего, что требует случайности, либо вы начинаете с достаточной энтропии, и у вас остается достаточная энтропия, независимо от того, сколько случайности вы генерируете.
Жиль
Простите что ? Есть ряд операций в Linux, которые настаивают на сильной энтропии, основанной на аппаратном обеспечении, а не на, вероятно, достаточно хорошей энтропии на основе PRNG, и они действительно могут блокироваться, если глубина пула мала. Скорее всего, можно начать с достаточной энтропии в системе Linux, но при чрезмерном использовании, чтобы истощить пул, что приведет к блокировке некоторых операций.
MadHatter
3

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

Vality
источник
Проблема с решениями, такими как наличие простой целевой страницы HTTP, даже если она правильно отделена, состоит в том, что эта страница остается открытой для манипуляций. То есть, нет реальной гарантии, что ссылка на HTTPS-версию сайта будет доставлена ​​посетителям в целости и сохранности.
Хокан Линдквист
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
источник
Что вы можете сделать, чтобы фактически обратиться к sslstrip, так это использовать HSTS ( желательно предварительно загрузить ваши настройки HSTS ). Вне зависимости от того, принимаете ли вы запросы по обычному HTTP или нет, MITM может ответить по обычному HTTP (возможно, через прокси-сервер на ваш HTTPS-сайт), даже если вы принимаете только HTTPS-запросы.
Хокан Линдквист
@ HåkanLindqvist Я действительно получил от тебя отрицательный голос? Я дал плохой совет или хороший совет относительно того, чтобы не проходить аутентификацию через HTTPS, а затем переключаться на HTTP до конца сеанса? Я дал плохой совет относительно мифов о производительности HTTPS? Кроме того, если клиент изначально пытается подключиться с использованием HTTPS, MITM не может перехватить и ответить, не вызвав оповещения в браузере, потому что его сертификат не будет совпадать, если у него нет украденного или успешно поддельного сертификата. С другой стороны, если сайт принимает HTTP-соединение, перехват проще. В любом случае, HTTPS поднимает планку.
Крейг
... и, конечно, я полностью согласен с использованием HSTS.
Крейг
Моя проблема с ответом - первый элемент в списке, утверждающий, что он обращается к sslstrip, хотя на самом деле это не так (говоря о мифах). В своем первоначальном комментарии я пытался понять, что если у вас есть активный MITM (что, в первую очередь, нужно для sslstrip), злоумышленник, по сути, может быть «сайтом» с точки зрения клиента; злоумышленник решает, хотят ли они принимать простые HTTP-соединения от клиента, то, как ваш реальный веб-сервер ведет себя в этом отношении, не влияет на то, что злоумышленник может или будет делать.
Хокан Линдквист
@ HåkanLindqvist За исключением того, что если посетитель намеренно пытается соединиться с HTTPS, злоумышленник не может удовлетворить этот запрос, не выбрасывая флаги в браузере, если ему не удастся украсть сертификат сервера или каким-либо образом успешно подделать его, что ему и придется сделать для того, чтобы переключить соединение на HTTP. HTTPS все еще поднимает планку. Конечно, если посетитель делает первоначальную попытку подключения через HTTP, все ставки полностью отключены.
Крейг
1

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

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

trysis
источник
1

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

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

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

anthonysomerset
источник
Проблема с производительностью HTTPS заключается в том, что установление нового соединения обходится дороже, потому что здесь задействовано больше циклов, а асимметричное шифрование / дешифрование намного дороже, чем симметричное шифрование / дешифрование. Как только в результате установления соединения устанавливается общий симметричный ключ шифрования, текущие издержки практически не имеют значения (очень малы). Если вы прочтете SPDY, то увидите, что цель всего того, что он делает, по сути, состоит в том, чтобы обслуживать весь контент с URL-адреса по одному соединению, уменьшая накладные расходы на установление соединения.
Крейг,
1

Перенаправление на 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>
Уилт
источник