Почему бы не использовать HTTPS для всего?

Question

Если я настраивал сервер и имел сертификаты SSL, почему бы мне не использовать HTTPS для всего сайта, а не только для покупок / входов в систему? Я думаю, что было бы более разумно просто зашифровать весь сайт и полностью защитить пользователя. Это предотвратит такие проблемы, как принятие решения о том, что должно быть защищено, потому что все будет, и это на самом деле не доставляет неудобств пользователю.

Если я уже использовал HTTPS для части сайта, почему бы мне не использовать его для всего сайта?

Это связанный вопрос: Почему https используется только для входа в систему? , но ответы не являются удовлетворительными. Ответы предполагают, что вы не смогли применить https ко всему сайту.

Answer 1

В дополнение к другим причинам (особенно связанным с производительностью) вы можете использовать только один домен на IP-адрес * при использовании HTTPS.

Один сервер может поддерживать несколько доменов в HTTP, поскольку заголовок HTTP Server позволяет серверу знать, на какой домен отвечать.

При использовании HTTPS сервер должен предлагать свой сертификат клиенту во время первоначального рукопожатия TLS (до запуска HTTP). Это означает, что заголовок Server еще не отправлен, поэтому у сервера нет возможности узнать, какой домен запрашивается и какой сертификат (www.foo.com или www.bar.com) ответить.

---

* Сноска. Технически вы можете разместить несколько доменов, если размещаете их на разных портах, но обычно это не вариант. Вы также можете разместить несколько доменов, если ваш SSL-сертификат имеет подстановочный знак. Например, вы можете разместить как foo.example.com, так и bar.example.com с сертификатом * .example.com

Answer 2

Я могу придумать пару причин.

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

Answer 3

SSL / TLS используется не достаточно часто. HTTPS должен использоваться для всего сеанса , ни при каких условиях идентификатор сеанса не может быть отправлен по HTTP. Если вы используете https только для входа в систему, то вы явно нарушаете Топ-10 OWASP за 2010 год «A3: сломанная аутентификация и управление сеансами».

Answer 4

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

Answer 5

Почему бы не отправлять каждую почту обычной почтой в защищенном от взлома конверте заказным письмом? Кто-то из почтового отделения всегда будет лично его охранять, так что вы можете быть уверены, что никто не отслеживает вашу почту. Очевидно, что ответ заключается в том, что, хотя некоторые письма стоят затрат, большинство писем не стоит. Мне все равно, если кто-то читает мое "Рад, что вы вышли из тюрьмы!" открытка дяде Джо.

Шифрование не является бесплатным и не всегда помогает.

Если сеанс (например, покупки, банковские операции и т. Д.) Будет завершен с использованием HTTPS, нет веской причины не делать весь сеанс HTTPS как можно раньше.

Мое мнение таково, что HTTPS следует использовать только тогда, когда это неизбежно необходимо, потому что запрос или ответ должны быть защищены от промежуточного отслеживания. В качестве примера, посмотрите на Yahoo! домашняя страница. Даже если вы вошли в систему, большая часть вашего взаимодействия будет проходить через HTTP. Вы аутентифицируетесь по протоколу HTTPS и получаете файлы cookie, которые подтверждают вашу личность, поэтому вам не нужен HTTPS для чтения новостей.

Answer 6

Для каналов с высокой задержкой начальное рукопожатие TLS требует дополнительных обходов для проверки цепочки сертификатов (включая отправку любых промежуточных сертификатов), согласования комплектов шифров и установления сеанса. Как только сеанс установлен, последующие запросы могут использовать кэширование сеанса, чтобы уменьшить количество обратных вызовов, но даже в этом лучшем случае все еще существует большее количество обратных вызовов, чем требуется для обычного HTTP-соединения. Даже если операции шифрования были бесплатными, обходные пути не являются и могут быть весьма заметны по более медленным сетевым соединениям, особенно если сайт не использует конвейерную обработку http. Для пользователей широкополосного доступа в хорошо подключенном сегменте сети это не проблема. Если вы ведете бизнес на международном уровне, запрос https может легко вызвать заметные задержки.

Существуют дополнительные соображения, такие как поддержание состояния сеанса на сервере, требующее потенциально значительно больше памяти, и, конечно, операции шифрования данных. Любые небольшие сайты практически не должны беспокоиться о возможностях сервера в сравнении со стоимостью современного оборудования. Любой крупный сайт легко сможет позволить себе разгрузку CPU / w AES или дополнительные карты для обеспечения аналогичной функциональности.

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

Могут быть эксплуатационные соображения, такие как административные ограничения на трафик https (например, фильтры промежуточного содержимого и т. Д.), Возможно, некоторые корпоративные или правительственные нормативные акты. Некоторые корпоративные среды требуют расшифровки данных по периметру, чтобы предотвратить утечку информации ... вмешательство в точки доступа и аналогичные системы доступа через Интернет, не способные вводить сообщения в транзакциях https. В конце дня, на мой взгляд, причины отказа от https по умолчанию, скорее всего, будут весьма незначительными.

Answer 7

https более ресурсоемкий, чем обычный http.

Требуется больше как от серверов, так и от клиентов.

Answer 8

Вы должны использовать HTTPS везде, но вы потеряете следующее:

1. Определенно не следует использовать сжатие SSL или сжатие HTTP поверх SSL из-за атак BREACH и CRIME. Таким образом, нет сжатия, если ваш ответ содержит идентификаторы сеанса или CSRF. Вы можете уменьшить это, поместив ваши статические ресурсы (изображения, js, css) в домен без файлов cookie и использовать там сжатие. Вы также можете использовать минимизацию HTML.

2. Один сертификат SSL, один IP-адрес, если только не используется SNI, который работает не во всех браузерах (старый Android, Blackberry 6 и т. Д.).

3. Вы не должны размещать на своих страницах внешний контент, который не передается по протоколу SSL.

4. Вы теряете заголовок исходящего HTTP Referer, когда браузер переходит на страницу HTTP, что может быть или не быть проблемой для вас.

Answer 9

Если весь сеанс зашифрован, вы не сможете использовать кеширование для статических ресурсов, таких как изображения и js на уровне прокси, например, ISP.

Answer 10

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

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

Если нет, HTTPS не требуется, но вы все равно можете использовать его, если хотите.