Вопрос: Есть ли причина не применять HTTPS на веб-сайте?


Веб-сайт, на котором я часто встречался, решил, наконец, включить TLS на свои серверы, но не называть его множеством веб-сайтов. Заявитель утверждает, что TLS должен быть необязательным. Зачем?

На моем собственном веб-сайте я долго настраивал TLS и HSTS с длинными периодами, а более слабые шифровые комплекты отключены. Доступ к обычным текстам гарантированно защищен версией HTTP 301 до версии, защищенной TLS. Это влияет на мой сайт отрицательно?


49
2018-04-01 13:46


Источник


Они могут опасаться, что HSTS вызовет у них проблемы, если НИЧЕГО пойдет не так (т. Е. Их свободный CA прекратит выдавать сертификаты или удаляется из хранилищ доверия браузера из-за некоторой проблемы). С текущей экосистемой TLS вы создаете зависимости от доверенных ЦС / поставщиков браузеров. В настоящее время его трудно избежать и стоит того, но вы все еще можете рассматривать это как проблему и не применяете HTTPS в качестве решения оставаться независимым в случае, если что-то произойдет. - allo
любой хочет упомянуть требование tls для h2, которое намного быстрее, чем http1.1. хорошо для вас, делаю hsts, недавно я отправил свой сайт в список предварительной загрузки hsts, надеюсь, я могу просто отключить порт 80 все вместе - Jacob Evans
Видеть это: security.stackexchange.com/questions/53250/... - d33tah
@gerrit Этот аргумент не стоит перед недорогими и бесплатными полномочными органами сертификации, такими как Let's Encrypt. - Maxthon Chan
Let's Encrypt не работает с каждым хостом, и это не так просто, как использование лучшего хоста. Я использую App Engine, который не поддерживается (напрямую) по техническим причинам. - Carl Smith


Ответы:


В этот день и возраст TLS + HSTS - это маркеры, на которых ваш сайт управляется профессионалами, которым можно доверять, чтобы знать, что они делают. Это новый минимальный стандарт доверия, о чем свидетельствует Google, в котором говорится, что они обеспечат позитивный рейтинг для сайтов, которые это делают.

С другой стороны, максимальная совместимость. Есть еще более старые клиенты, особенно в некоторых частях мира, которые не являются Соединенными Штатами, Европой или Китаем. Обычный HTTP всегда будет работать (хотя и не всегда работает Что ж; это еще одна история).

TLS + HSTS: Оптимизация для ранжирования в поисковых системах
Обычный HTTP: Оптимизация совместимости

В зависимости от того, что для вас важнее.


62
2018-04-01 13:59



Возможно, это я придирчивый, но первое предложение кажется немного напряженным: сайт https ничего не говорит о профессионализме или надежности ответственных людей. Сайт может быть https и все еще разрабатываться / управляться людьми, которые не дезактивируют входные данные, что делает сайт уязвимым для SQL-инъекции или XSS; или он может быть https и быть недействительным, недоступным или непригодным для использования. - Alvaro Montoro
Использование HTTPS не является гарантией профессионализма, но его отсутствие, безусловно, говорит об обратном. - Esa Jokinen
Использование TLS и HSTS - это сигналы, являющиеся частью гораздо большего массива, которые сайт может заслуживать чтения. В отличие от других, его тривиально легко проверить на наличие, поэтому Google использует его как прокси для остальных. - sysadmin1138♦
@Braiam Stack Exchange переносится только на https и скоро начнет использовать hsts. Http по-прежнему доступен не из-за совместимости, а потому, что они медленны и осторожны, и технически сложно мигрировать. - captncraig
@esajohnson - отсутствие https не демонстрирует непрофессионализм. Это показывает, что для этого нет необходимости. Например, зеркало CentOS. - warren


Есть одна веская причина для простого только для чтения веб-сайтам не использовать HTTPS.

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

31
2018-04-01 23:30



Содержимое, доступное только для чтения, может быть развернуто на CDN, если вы нацеливаете эти страны. CDN отражает статическое содержимое, используя свои собственные средства, и все еще обслуживает их через HTTPS. CDN можно довольно легко найти и для небольших сайтов, которые не так дороги в использовании. - Maxthon Chan
@MaxthonChan, попробуйте объяснить моей матери, что такое CDN ..... Тем не менее она может настроить веб-сайт со временем местных церковных служб. - Ian Ringrose
@MichaelHampton, как кеш может считывать изображение из потока HTTPS без наличия ключей описания? И доверяете ли вы интернет-провайдеру своими ключами? - Ian Ringrose
Вы должны сделать более понятным, о каких кешах вы говорите. - Michael Hampton♦
@IanRingrose Если ваша мать создает сайт с информацией о местной церковной службе, маловероятно, что поведение кеширования в международных связях вступит в игру, если это не очень популярная церковь. - Jason C


Составитель утверждает, что TLS необязательно. Зачем?

Чтобы действительно знать ответ на этот вопрос, вы должны спросить их. Мы можем, однако, сделать некоторые догадки.

В корпоративной среде, это общая для IT, чтобы установить брандмауэр, который проверяет трафик входящим и исходящим на наличии вредоносных программ, подозрительные CnC-подобная активность, содержание считается неподходящим для работы (например, порнография) и т.д. Это становится гораздо сложнее, когда трафик шифруется. Существует по существу три возможных ответа:

  1. Откажитесь от мониторинга этого трафика.
  2. Установите корневой ЦС на компьютеры пользователей, чтобы вы могли выполнять дешифрование и проверку MitM.
  3. Оптовый блок зашифрованного трафика.

Для соответствующего системного администратора ни один из этих вариантов не является особенно привлекательным. Существует множество угроз, которые атакуют корпоративную сеть, и их задача - защитить компанию от них. Тем не менее, блокирование большого количества сайтов полностью приводит к сбою пользователей, а установка корневого ЦС может показаться немного скучной, поскольку она вводит вопросы конфиденциальности и безопасности для пользователей. Я помню, что видел (извините, не могу найти нить) заявление sysadmin reddit, когда они впервые включали HSTS, потому что он был в такой ситуации и не хотел блокировать все reddit просто потому, что он был вынужден бизнесом блокировать порно-ориентированных subreddits.

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


14
2018-04-01 18:16



как насчет завершения ssl на интерфейсном сервере / балансировщике нагрузки / аналогичном и протоколировании трафика после этого? - eis
@eis Предполагается, что компания контролирует каждый сайт, который могут посетить сотрудники, что маловероятно. Сообщение не похоже на TLS на веб-сайте интрасети. - Xiong Chiamiov


Существует несколько веских причин использовать TLS

(и только несколько незначительных причин не делать этого).

  • Если сайт имеет какую-либо аутентификацию, использование HTTP для кражи сеансов и паролей.
  • Даже на статических, просто информационных сайтах, используя TLS, никто не подделывает данные.

  • поскольку Google I / O 2014, Google предпринял несколько шагов, чтобы побудить все сайты использовать HTTPS:

  • Блог безопасности Mozilla также объявил о Устранение неподдерживаемых HTTP-сообщений путем принятия все новые функции доступны только для защиты веб-сайтов а также постепенно прекращая доступ к функциям браузера для незащищенных веб-сайтов, особенно функции, которые создают риск для безопасности и конфиденциальности пользователей,

Есть также несколько веских причин для принудительного применения TLS

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

Если ваш сопровождающий все еще хочет разрешить HTTP-соединения без прямого 301 Moved Permanently, скажем, для обеспечения доступа к некоторым действительно старым браузерам или мобильным устройствам, браузер не знает, что вы даже настроили HTTPS, Кроме того, вы не должны развертывать Строгая транспортная безопасность HTTP (HSTS) без 301 Moved Permanently:

7.2.  HTTP Request Type

   If an HSTS Host receives a HTTP request message over a non-secure
   transport, it SHOULD send a HTTP response message containing a status
   code indicating a permanent redirect, such as status code 301
   (Section 10.3.2 of [RFC2616]), and a Location header field value
   containing either the HTTP request's original Effective Request URI
   (see Section 9 "Constructing an Effective Request URI") altered as
   necessary to have a URI scheme of "https", or a URI generated
   according to local policy with a URI scheme of "https").

Проблема различных сайтов, настроенных для обоих протоколов, распознается Проект Tor и Электронный пограничный фонд и обращается к мультибраузеру HTTPS в любом месте расширение:

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

Смешанный контент также была огромной проблемой из-за возможных атак XSS на сайты HTTPS путем изменения JavaScript или CSS, загружаемых через незащищенное HTTP-соединение. Поэтому в настоящее время все основные браузеры предупреждают пользователей о страницах со смешанным контентом и отказываются автоматически загружать их. Эта затрудняет поддержку сайта без 301 перенаправляет на HTTP: вы должны убедиться, что каждая HTTP-страница загружает только HTTP-комментарий (CSS, JS, изображения и т. д.), и каждая страница HTTPS загружает только контент HTTPS. Чрезвычайно сложно добиться такого же содержания на обоих.


8
2018-04-01 15:25



If your maintainer still would like to allow HTTP connections without direct 301 Moved Permanently, say for ensuring access from some really old browsers or mobile devices, HSTS is the correct choise as it only enforces HTTPS when it is clear that the browser supports it но в этом случае клиент (даже HTTPS-совместимый) никогда не узнает о версии HTTPS, поскольку они загружают HTTP изначально. - Cthulhu
Повторите свой последний абзац: заголовок HSTS игнорируется во время соединения без HTTPS. - Cthulhu
HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.  If an HTTP response is received over insecure transport, the UA MUST ignore any present STS header field(s).  tools.ietf.org/id/draft-ietf-websec-strict-transport-sec-14.txt - Cthulhu
Спасибо, что указали мой ложный намек, Ктулху! Вдохновленный этим, я значительно улучшил свой ответ. Пожалуйста, также проявляйте критичность к новому контенту. :) - Esa Jokinen


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

Не позволяя мне явно понижать рейтинг до небезопасного HTTP, когда я считаю, что ваше сообщение в блоге о том, почему вам нравится Python больше, чем Ruby (не говоря, что вы делаете, просто общий пример) не то, что я имею в виду призраков или общественное знание Я получил доступ только к моему пути без уважительной причины, исходя из предположения, что HTTPS будет для меня тривиальным.

Сегодня есть встроенные системы, которые не имеют возможности использовать TLS из коробки или те, которые застряли в старых реализациях (я думаю, это ужасно плохо, что это так, но как мощный пользователь [insert embedded устройство здесь], я иногда не могу это изменить).

Вот забавный эксперимент: попробуйте загрузить последнюю версию LibreSSL с сайта OpenBSD выше по HTTPS с достаточно старой реализацией TLS / SSL. Вы не сможете. Я попытался на днях на устройстве со старой версией OpenSSL с 2012 года или около того, потому что я хотел обновить эту встроенную систему до более безопасного, нового материала из исходного кода - у меня нет роскоши готового пакета. Сообщения об ошибках, когда я пытался, были не совсем интуитивными, но я предполагаю, что это было потому, что мой старый OpenSSL не поддерживал правильные вещи.

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

Большинство из нас не являются одной необеспеченной загрузкой от того, чтобы быть владельцем APT (Advanced Persistent Thread: жаргон безопасности для национальных спецслужб и других чрезвычайно ценных ресурсов кибер-угроз). Иногда я просто хочу wget какую-то текстовую документацию или небольшую программу, источник которой я могу быстро проверить (например, мои собственные крошечные утилиты / скрипты на GitHub) на ящик, который не поддерживает самые последние комплекты шифров.

Лично я бы спросил: это ваш контент, чтобы человек мог законным образом решить: «Я в порядке, когда я получаю доступ к публичным знаниям»? Есть ли вероятная вероятность реального риска для нетехнических людей, случайно понижающих уровень HTTP для вашего контента? Соблюдайте требования безопасности, требования соблюдения требований конфиденциальности и ваших пользователей и риск неявных понижений в отношении способности пользователей, которые понимают риски, делающие осознанный выбор, в каждом конкретном случае, без необходимости. Полностью законно говорить, что для вашего сайта нет веских оснований не применять HTTPS, но я считаю справедливым сказать, что есть все еще хорошие варианты использования для простого HTTP.


5
2018-04-02 18:12



«попробуйте загрузить последнюю версию LibreSSL с восходящего сайта OpenBSD через HTTPS с достаточно старой реализацией TLS / SSL» Разумеется, это означает: попробуйте загрузить недавний браузер с достаточно старым браузером, например, тот, который реализует только HTTP / 1.0 без поддержки Host: заголовок. Или попробуйте заняться серфингом на современных сайтах с помощью веб-браузера, который поддерживает только Javascript 2001 года. В какой-то момент мы, как сообщество, должны двигаться дальше, что, к сожалению, кое-что нарушает. Тогда возникает вопрос: является ли добавленная стоимость стоимостью поломки? - Michael Kjörling
@ MichaelKjörling Это также проблемы, имеющие различную степень тяжести. Я добавлю последние версии компилятора в список. Некоторые из них более защитимы, чем другие. Я не уверен, утверждаете ли вы несогласие или почему, если вы: во втором предложении моего поста, я согласен, что это является оправданным, чтобы предотвратить использование старых шифров в HTTPS-соединении, поскольку он защищает большинство пользователей от атак с понижением, которые в противном случае они не имели бы значимой видимости или защиты против. (Я не думаю, что большинство современных веб-сайтов, которые не могут грациозно деградировать, отдаленно оправданы, но это не относится к делу). - mtraceur
@ MichaelKjörling Чтобы прояснить ситуацию, это было связано с тем, что это пример того, где предоставление простого HTTP-протокола пользователю была ясная выгода, и это было основной точкой ответа на вопрос. Ни в коем случае нельзя отрицательно относиться к проектам OpenBSD / LibreSSL, для которых я очень уважаю. Я думал, что второе предложение первого абзаца исключало бы такую ​​негативную интерпретацию. Если вы считаете, что это неясно или может быть сформулировано лучше, не стесняйтесь редактировать мой ответ или предлагать улучшения. - mtraceur


Здесь много дискуссий о том, почему tls - это хорошо, но об этом никогда не спрашивали, как в оригинальном посте.

Макстон задал два вопроса:

1) почему у него есть случайный, неименованный сайт, который решил поддерживать как присутствие http, так и https

2) Существует ли негативное влияние на Maxthon, обслуживающий только 301 ответ на HTTP-запросы

Что касается первого вопроса, мы не знаем, почему провайдеры решили сохранить сайты http и https. Могут быть много причин. В дополнение к точкам совместимости, распределенного кэширования и некоторым подсказкам о геополитической доступности, также учитывается интеграция контента и исключение уродливых сообщений браузера о незащищенном содержании. Как отметил Альваро, TLS - это лишь верхушка айсберга в отношении безопасности.

Второй вопрос, однако, подотчетен. Предоставление любой части вашего сайта вашего веб-сайта через http, когда на самом деле требуется https для безопасной работы, представляет собой пригодный для использования вектор для атак. Однако имеет смысл поддерживать это, чтобы определить, где трафик некорректно направлен на порт 80 на вашем сайте и устранение причины. То есть есть и негативное воздействие, и возможность для положительного воздействия, чистый результат зависит от того, выполняете ли вы свою работу в качестве администратора.

Sysadmin1138 говорит, что https влияет на ранжирование seo. Хотя Google заявила, что она влияет на ранжирование, надежные исследования Я видел, что разница небольшая. Этому не помогают люди кто должен знать лучше утверждая, что, поскольку сайты с наивысшим рейтингом, скорее всего, имеют присутствие https, присутствие https следовательно улучшает рейтинги.


3
2018-04-03 22:52





Раньше мне приходилось использовать HTTP, а не HTTPS, потому что я хотел <embed> страниц из других источников, которые сами были переданы через HTTP, и они не будут работать иначе.


1
2018-04-04 11:52



Вы можете использовать свой сервер, чтобы отменить прокси версию SSL'd. - Maxthon Chan


Это не хорошо потому что это означает, что у вас есть плохие / сломанные / небезопасные клиенты, но если есть автоматизированные процессы, обращающиеся к ресурсам через существующие http:// urls, возможно, что некоторые из них даже не поддерживают https (например, BusyBox wget, который не имеет внутренней поддержки TLS и только недавно добавил его с помощью дочернего процесса openssl) и сломается, если им будет перенаправлен URL-адрес https, за которым они не смогут следовать.

У меня возникнет соблазн разобраться с этой возможностью, написав правило перенаправления, чтобы исключить перенаправление неизвестных (или известных ранее) строк User-Agent и позволить им получить доступ к контенту через http, если они этого захотят, чтобы фактические браузеры могли извлечь выгоду из принудительный https / hsts.


1
2018-04-03 16:08



Напомните мне, сколько десятилетий назад какой-либо хорошо поддерживаемый инструмент (например, wget) не поддерживал HTTPS? - Oleg V. Volkov
@ OlegV.Volkov: Я думаю, вы пропустили слово busybox в своем ответе. - R..
Проверено - ну, теперь я вижу. Я действительно не понимаю, почему тогда не может просто построить чертову вещь, а затем не создавать инструменты сборки, но что угодно. Думаю, что я также вспомнил еще несколько случаев, когда люди были ограничены урезанными или устаревшими инструментами, и было бы неплохо иметь простой HTTP. Не могли бы вы исправить колпачки, чтобы я мог отменить голосование после редактирования? - Oleg V. Volkov


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


1
2018-04-07 16:25