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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

https требует больше ресурсов, чем обычный http.

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

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

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

Что ж, очевидная причина - производительность: все данные должны быть зашифрованы сервером перед передачей, а затем дешифрованы клиентом при получении, что является пустой тратой времени, если нет конфиденциальных данных. Это также может повлиять на объем кеширования вашего сайта.

Кроме того, это может сбить с толку конечных пользователей, если все адреса используют https://вместо знакомыхhttp:// . Также см. Этот ответ:

Почему бы не всегда использовать https при включении файла js?

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

В дополнение к ответу WhirlWind вы должны учитывать стоимость и применимость сертификатов SSL, проблемы с доступом (возможно, но маловероятно, что клиент не сможет общаться через порт SSL) и т. Д.

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

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

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

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

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

Примечание. Я не уверен, что это связано с конкретным браузером, но это определенно происходит с моим браузером Firefox.

Windows Server 2012 с IIS 8.0 теперь предлагает SNI, который представляет собой указание имени сервера, которое позволяет размещать несколько веб-приложений SSL в IIS на одном IP-адресе.