Веб-сайт, который я часто посещаю, наконец-то решил включить TLS для своих серверов, только не для того, чтобы требовать этого, как это делают многие веб-сайты. Сопровождающий утверждает, что TLS должен быть необязательным. Зачем?
На моем собственном веб-сайте я давно настроил обязательные TLS и HSTS с длинными периодами, а более слабые наборы шифров отключены. Доступ к незашифрованному тексту гарантированно будет изолирован с помощью HTTP 301 для версии, защищенной TLS. Это отрицательно влияет на мой сайт?
В наши дни TLS + HSTS являются маркерами того, что вашим сайтом управляют профессионалы, которым можно доверять, знающие, что они делают. Это новый минимальный стандарт надежности, о чем свидетельствует заявление Google, которое обеспечивает положительный рейтинг сайтов, которые это делают.
С другой стороны - максимальная совместимость. Есть еще пожилые клиенты, особенно в тех частях мира, которые не входят в США, Европу или Китай. Обычный HTTP всегда будет работать (хотя не всегда работает хорошо; это отдельная история).
TLS + HSTS: Оптимизировать для ранжирования в поисковых системах
Обычный HTTP: Оптимизировать для совместимости
Зависит от того, что для вас важнее.
Есть одна веская причина для простого только чтение веб-сайты не использовать HTTPS.
Сопровождающий утверждает, что TLS должен быть необязательным. Зачем?
Чтобы по-настоящему узнать ответ на этот вопрос, вы должны их задать. Однако мы можем сделать некоторые предположения.
В корпоративной среде, это общие для того, чтобы установить брандмауэр, который проверяет трафик входящий и исходящий на наличие вредоносных программ, подозрительных CnC-подобную активность, содержание расценены как неуместные для работы (например, порнографии) и т.д. Это становится гораздо сложнее, когда трафик шифруется. По сути, есть три возможных ответа:
Для заинтересованного системного администратора ни один из этих вариантов не особенно привлекателен. Существует множество угроз, которые атакуют корпоративную сеть, и их задача - защитить компанию от них. Однако блокировка большого количества сайтов полностью вызывает гнев пользователей, а установка корневого ЦС может показаться немного неприятной, поскольку она вводит соображения конфиденциальности и безопасности для пользователей. Я помню, как видел (извините, не могу найти ветку) петицию сисадмина на reddit, когда они впервые включали HSTS, потому что он был именно в этой ситуации и не хотел блокировать все reddit просто потому, что он был вынужден бизнесом блокировать порно-ориентированных subreddits.
Колеса технологий продолжают двигаться вперед, и вы найдете многих, кто будет утверждать, что такого рода защита устарела и должна быть прекращена. Но есть еще много тех, кто его практикует, и, возможно, именно они и заботятся о вашем таинственном сопровождающем.
(и лишь несколько маргинальных причин не делать этого).
Даже на статических, просто информационных сайтах использование TLS гарантирует, что никто не подделал данные.
поскольку Google I / O 2014, Google предпринял несколько шагов, чтобы побудить все сайты использовать HTTPS:
В блоге Mozilla Security также сообщается о Отказ от использования незащищенного HTTP делая все новые функции доступны только для защищенных веб-сайтов и постепенное прекращение доступа к функциям браузера для незащищенных веб-сайтов, особенно к функциям, которые представляют опасность для безопасности и конфиденциальности пользователей.
Если у вас уже есть широко известный сертификат, почему бы всегда его не использовать? Практически все современные браузеры поддерживают 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. Этого чрезвычайно сложно достичь с одинаковым контентом на обоих.
Все сводится к вашим требованиям безопасности, выбору пользователя и риску неявного перехода на более раннюю версию. Отключение старых шифров на стороне сервера в значительной степени необходимо, потому что браузеры с радостью откажутся от абсолютно ужасных шифров на стороне клиента во имя пользовательского опыта / удобства. Убедившись, что ничего из твоего смотря как по защищенному каналу к пользователю нельзя добраться небезопасным методом, конечно, тоже очень разумно.
Не позволяя мне явно перейти на небезопасный 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.
Здесь много споров о том, почему 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 году они должны.