Я только что установил сертификат SSL на свой сервер.
Затем он настроил перенаправление для всего трафика в моем домене на порт 80, чтобы перенаправить его на порт 443.
Другими словами, все мои http://example.com
трафик теперь перенаправляется на соответствующий https://example.com
версия страницы.
Перенаправление выполняется в моем файле виртуальных хостов Apache примерно так ...
RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L]
У меня вопрос: есть ли недостатки в использовании SSL?
Поскольку это не 301 редирект, потеряю ли я ссылочный вес / рейтинг в поисковых системах, переключившись на 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]
А 301
сохраняет все ваши гугл-фу и с трудом заработанные рейтинги страниц неповрежденный. Удостовериться mod_rewrite
включен:
a2enmod rewrite
Чтобы ответить на ваш точный вопрос:
Это плохо - перенаправлять с http на https?
Конечно нет. Это очень хорошо.
Хотя я поддерживаю идею сайтов только с SSL, я бы сказал, что одним недостатком являются накладные расходы в зависимости от дизайна вашего сайта. Я имею в виду, например, что если вы обслуживаете много отдельных изображений в тегах img, это может привести к тому, что ваш сайт будет работать намного медленнее. Я бы посоветовал всем, кто использует серверы только с SSL, убедиться, что они работают в следующих областях.
<meta property="og:url"
использовать https-версию вашего домена.<base href=
снова обновите, чтобы использовать HTTPS.Если все вышеперечисленное решено, то я сомневаюсь, что у вас будет много проблем.
Если вы настроили 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. Строгая транспортная безопасность (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 из-за отсутствия поддержки криптографии с эллиптической кривой).
Вот Это Да ! перенаправление HTTP на HTTPS - это очень хорошо, и я не вижу в этом никаких недостатков.
Просто убедитесь, что у ваших клиентов правильный ЦС, чтобы избежать неудобных предупреждений о сертификате в браузере.
Кроме того, способ настройки 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, вставляя в поток свой собственный вредоносный скрипт. Если пользователь не заметит, то они считать их сеанс безопасен, хотя на самом деле это не так.
Если ваш сайт требует безопасного входа в систему, тогда весь пользовательский сеанс должен быть защищен. Не аутентифицируйтесь через HTTPS, а затем перенаправляйте пользователя обратно на HTTP. Если вы это сделаете, вы снова сделаете своих пользователей уязвимыми для атак MITM. Стандартный подход к аутентификации в наши дни - аутентифицироваться один раз, а затем передавать токен аутентификации туда и обратно (в файле cookie). Но если вы аутентифицируетесь через HTTPS, а затем перенаправляете на HTTP, тогда посредник может перехватить этот файл cookie и использовать сайт, как если бы он был вашим аутентифицированным пользователем, в обход вашей безопасности.
Проблемы с «производительностью» HTTPS практически ограничиваются рукопожатием при создании нового соединения. Сделайте все возможное, чтобы свести к минимуму необходимость в нескольких HTTPS-соединениях с URL-адреса, и вы будете далеко впереди. И это правда, даже если вы обслуживаете свой контент через HTTP. Если вы прочтете о SPDY, вы поймете, что все, что он делает, ориентировано на попытку обслуживать весь контент с одного URL-адреса через одно соединение. Да, использование HTTPS влияет на кеширование. Но в любом случае, сколько веб-сайтов представляют собой просто статический, кешируемый контент в наши дни? Вы, вероятно, получите больше прибыли, используя кеширование на своем веб-сервере, чтобы свести к минимуму избыточные запросы к базе данных, извлекающие неизмененные данные снова и снова, и предотвратить выполнение дорогостоящих путей кода чаще, чем это необходимо.
Перенаправление на 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>
Технически это не ответ на ваш исходный вопрос, но если вы используете расширение Google Chrome HTTPSEverywhere (я уверен, что аналогичные расширения есть в других браузерах), расширение автоматически перенаправляет сайты с HTTP на тот же сайт с HTTPS. Я использую его некоторое время, и у меня не было никаких проблем (кроме, возможно, замедления, но я это не тестировал). HTTPSEverywhere можно изменить с помощью определенных правил на стороне сервера, но, поскольку я мало что сделал в этой области, я не уверен в точных деталях.
Возвращаясь к вашему фактическому вопросу, если вы используете что-то вроде HTTPSEverywhere, у вас будет еще меньше стимулов использовать только HTTP, хотя я думаю, что трудно установить правильные правила, когда они вам нужны.
Единственный технический недостаток HTTPS поверх HTTP заключается в том, что обработка запросов HTTPS с вычислительной точки зрения обходится дороже, чем простой HTTP.
Однако, учитывая, что большинство современных серверов имеют мощные ЦП, это влияние обычно незначительно, если только вы не находитесь на очень высоком уровне трафика, в этот момент вы, скорее всего, все равно используете балансировщики нагрузки.
С появлением таких протоколов, как SPDY, для работы которых требуется SSL / TLS, это фактически противодействует вышеупомянутым вычислительным накладным расходам, обеспечивая значительное повышение производительности в отношении нескольких запросов и более быструю доставку активов клиенту в целом.