Вопрос: Неправильно ли перенаправлять 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 везде ...

enter image description here 


243
2018-01-28 00:12


Источник


[WTF - я не могу добавить ответ (хотя кажется, что у меня достаточно репутации).] Я бы ответил (частично), что ИНОГДА ИТОГИ, Рассмотрим передачу ключа COOKIE или API в GET через HTTP. Если ваш сайт перенаправляет HTTP-запросы на HTTPS-запросы, эти вызовы будут работать, но COOKIE или API-ключ будут переданы в прозрачном режиме. Некоторые API-интерфейсы отключают HTTP, более надежный подход - нет HTTP вообще, так что вы даже не можете заставить его работать, если вы не используете HTTPS. Пример: «Все запросы API должны быть выполнены через HTTPS. Вызовы, выполненные поверх простого HTTP, будут сбой» из stripe.com/docs/api?lang=php#authentication - codingoutloud
@codingoutloud - альтернатива заключается в том, что Все это происходит через HTTP без HTTPS. Как это лучше? - Mark Henderson♦
@BenCrowell, это потому, что плененный портал выглядит очень много, как sslstrip-типа перенаправлять атаки (они оба захватчика запроса «человек в середине»), поэтому HSTS-aware будут блокировать их обоих. - Jeffrey Hantin
имейте в виду, что использование https означает, что все, что вы включаете, должно быть https или оно может не загружаться - например, загружать jquery, используя src="://example.com/jquery.js" - отметить отсутствие http или https поэтому браузер загружает соответствующий. У меня был кошмар, пытающийся получить некоторые встроенные материалы Amazon для правильной загрузки, поскольку API (загруженный через https) создал HTTP-ссылки - это значит, что они не работали должным образом, пока я не нашел недокументированный параметр для переключения https-ссылок - Basic
Джейсон; ваше обновление должно быть новым вопросом, возможно, на Веб-мастерапоскольку он не связан (технически) с вашим первоначальным вопросом. Но, вероятно, ваши таблицы стилей происходят из небезопасного домена. - Mark Henderson♦


Ответы:


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

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

301 хранит все ваши google-fu и с трудом заработанные pageranks неповрежденный, Убедиться mod_rewrite включен:

a2enmod rewrite

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

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

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


308
2018-01-28 00:27



Спасибо за информацию, мой босс говорит мне, что он только запускает https на определенных страницах своего сайта, заключается в том, что он использует гораздо больше ресурсов сервера для запуска на каждой странице. Вы знаете что-нибудь об этом, или если это правда? - JasonDavis
@jasondavis Только если вы не потратите несколько минут на оптимизировать его, - Michael Hampton♦
«он использует намного больше ресурсов сервера, чтобы запускать его на каждой странице». Современные процессоры имеют функции ускорения шифрования, которые делают SSL почти бесплатным. Не беспокойтесь о накладных расходах. - Adam Davis
@AdamDavis Крипто-алгоритм может быть легким, но накладные расходы на рукопожатие все еще существуют. Кроме того, HTTPS запрещает HTTP-прокси кэшировать ваш контент. В большинство случаев, накладные расходы на HTTPS минимальны и стоят, но будьте осторожны с чрезмерным обобщением. - 200_success
Он убивает общее кэширование, которое полезно для шаблонов использования некоторых сайтов и часто мало защищает (важно ли, чтобы люди знали, что вы посетили сайт, но не детали того, что вы сделали? Это единственная ситуация, когда SSL полезен). Основным преимуществом SSL на каждом ресурсе является не то, что вам нужно «защищать», например. люди, которые смотрят «о нас», но что вы не можете ускользнуть и не использовать его в том случае, когда вам нужно. - Jon Hanna


Хотя я поддерживаю идею только для 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.

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


49
2018-01-28 02:08



SPDY - хорошее предложение; существует даже модуль добавление поддержки SPDY для Apache 2.x, - Calrion
Используя "//yourserver.com/some-uri" вместо "yourserver.com/some-uri»; разрешает проблему (1), потому что браузер будет выбирать соответствующую схему (http или https) в зависимости от схемы, на которую была загружена страница. - MauganRa
@MauganRa Если, конечно, это ссылка с страницы http статьи на https страницу входа, например. - Mołot
Google видит URL-адрес, который кто-то посещает через Referer заголовок. Например, этот сайт использует jQuery из CDN от Google, и мой браузер отправляет запрос в Google каждый раз, когда я перезагружаю сайт. Таким образом, Referer заголовок также отправляется в Google, который настроен на URL этого сайта. Поэтому Google может отслеживать сайты, которые я посещаю, в то время, когда мой IP-адрес не изменяется (и если я использую сервис Google в течение этого времени, Google также может подключить эту информацию к моей учетной записи Google). - Stephan Kulla
Для 1) я просто выполнил поиск и заменил в моей базе данных MySQL http на https ... я использую WordPress, поэтому он действительно легко обновил сотни ссылок - JasonDavis


Я установил 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.


38
2018-01-28 07:40



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


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

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

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


22
2018-01-28 02:20



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


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

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

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


5
2018-01-28 00:35





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

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

О переадресации:

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

<VirtualHost *:80>
  ServerName domainname.com

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

5
2018-01-28 13:45





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

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

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


4
2018-01-28 07:43



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


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


3
2018-01-28 10:13



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