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

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

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

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

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

• Если на сайте есть какая-либо аутентификация, используйте HTTP-экспозицию для кражи сессий и паролей.

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

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

  • Google помогает веб-мастерам настраивать свои серверы более безопасно, но также использует HTTPS в качестве сигнала ранжирования .
  • Совсем недавно Google Chrome начал помечать HTTP-сайты как небезопасные , как часть долгосрочного плана помечать все HTTP-сайты как незащищенные .
  • В лекции Mytbusting HTTPS команды разработчиков Google Chrome четко изложено их отношение.

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

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

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

Если ваш сопровождающий по-прежнему хотел бы разрешить HTTP-соединения без прямого 301 Moved Permanentlyдоступа, например, для обеспечения доступа с некоторых действительно старых браузеров или мобильных устройств, у браузера нет возможности узнать, что у вас даже настроен HTTPS . Кроме того, вы не должны развертывать HTTP Strict Transport Security (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 и Electronic Frontier Foundation и решена с помощью многоброузерного расширения HTTPS Everywhere :

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

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

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

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

TLS + HSTS: оптимизировать для рейтинга в поисковых системах
Простой HTTP: оптимизировать для совместимости

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

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

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

Сопровождающий утверждает, что TLS должен быть необязательным. Почему?

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

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

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

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

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

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

Не позволяя мне явно понижать рейтинг до небезопасного 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.

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

Maxthon задал 2 вопроса:

1) почему на случайном, неназванном сайте решили сохранить и http, и https присутствия

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

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

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

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

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

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

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

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