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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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