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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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