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

Ответ 1

Я могу думать о нескольких причинах.

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

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

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

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

Ответ 6

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

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

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

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

Ответ 7

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

Он требует больше от серверов и клиентов.

Ответ 8

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

Ответ 9

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

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

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

• Вы не должны размещать на своих страницах какие-либо внешние контенты, не относящиеся к SSL.

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

Ответ 10

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

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

Ответ 11

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

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

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

Ответ 12

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

Ответ 13

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

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

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

Ответ 14

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

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

Ответ 15

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