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


126

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

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

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


2
Меня поражает, что компании, оказывающие финансовые услуги, до сих пор используют http.
Том Хотин - tackline

15
@Tom Я бы хотел, чтобы некоторые сайты, которые отправляют мне фишинговые сообщения, использовали https для своих поддельных сайтов, поэтому я знаю, что передаю свои данные правильному фишеру.
WhirlWind

Спасибо, что задали этот вопрос. Я предполагал, что причиной является производительность, и это будет намного хуже, чем http. Глядя на ответы, кажется, что производительность не так уж и плоха, что меня тоже удивляет.
sundar - Reinstate Monica

4
Я думаю, вы выбрали худший ответ на странице, на данный момент 11 голосов против. Выбранный вами ответ полностью игнорирует безопасность и передовой опыт.
ладья

5
Этот вопрос действительно заслуживает современного образованного ответа.
Old Badman Grey

Ответы:


17

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

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

137
Какие браузеры не поддерживают SSL?
Malfist

6
Некоторые компиляции lynx не поддерживают его. Если вы поддерживаете только новые браузеры, все будет в порядке.
WhirlWind

5
Я просматривал это: iweb.tntech.edu/hexb/publications/https-STAR-03122003.pdf «После насыщения сервера производительность системы HTTPS достигает примерно 67% от HTTP с точки зрения пропускной способности».
WhirlWind

16
Я не t buy this explanation. 1) Donиспользую браузер, который не поддерживает SSL в 2013 году. 2) даже Google использует SSL прямо сейчас 3) правильно настроенный, вы можете перенаправить HTTP-трафик на правильную ссылку https.
jfyelle

4
Плохой ответ, почему так много голосов? Какой браузер на земле не поддерживает ssl, и пользователи не должны помнить, что набирали https, можно обрабатывать перенаправления
Санне

25

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

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

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


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


5
Разве наличие подстановочного SSL-сертификата не решило бы эту проблему?
Роб

Сноска противоречит ответу: / вы можете использовать сертификаты с подстановочными знаками и размещать любые домены. en.wikipedia.org/wiki/Wildcard_certificate
Лукаскаро

23
Эта проблема уже давно решена с помощью индикации имени сервера, которая в настоящее время поддерживается всеми основными браузерами. en.wikipedia.org/wiki/Server_Name_Indication
tia

@tia, за исключением того, что не все веб-серверы его поддерживают
meffect

2
@meffect ... Но многие из них, включая apache2, nginx, lighttpd и nodejs. Кроме того, разработчик может выбрать, какой обратный прокси-сервер использовать для туннелирования HTTPS. Если бы это было правдой, заявление «никакие клиенты не поддерживают это» было бы правильным аргументом, потому что разработчик не может это контролировать и должен это учитывать. Однако утверждение «некоторые серверы не поддерживают это» в значительной степени неуместно, именно потому, что это не нужно учитывать. Особенно , когда все серверы мейнстрим делать на самом деле имеют поддержку.
Парфянский выстрел

13

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


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

@Einstein, пожалуйста, прочтите OWASP A3, он очень четко сформулирован. Имейте в виду, что злоумышленнику не нужны имя пользователя / пароль, если у него есть cookie из аутентифицированного сеанса.
ладья

Сайт предоставляет смешанные https / http. Логин https предоставляет отдельные токены сеанса с низким и высоким уровнем безопасности. Токены с низким уровнем безопасности, назначенные только для сеанса http, не будут работать для операций, требующих высокого уровня безопасности. Из того, что я прочитал, OWASP A3 в общих чертах освещает основную проблему возможности доступа с высокой степенью защиты через транспорт с низким уровнем защиты.
Эйнштейн

@Einstein Значит, вы не согласны с тем, что идентификаторы сеанса используются для аутентификации веб-браузеров? Примите во внимание этот шаблон атаки, в атаках xss вы пытаетесь получить значение, document.cookieчтобы злоумышленник мог использовать его для аутентификации. Это значение также можно получить путем сниффинга трафика, который останавливает https. Я не совсем понимаю, о чем вы говорите.
ладья

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

12

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

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

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

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


РЖУНИМАГУ!!! Большой! Бьюсь об заклад, негодяй-почтальон, открывший конверт с надписью «Рад, что ты вышел из тюрьмы», немного
испортит

19
Если бы заказная почта стоила на 1% больше, а не на 300%, я бы использовал ее для всего.
solublefish

3
You authenticate over HTTPS and get cookies that prove your identity, so you don't need HTTPS to read news stories.Это неправильный способ обработки аутентификации сеанса. Файлы cookie должны быть установлены с флагом SECURE. Но если отвлечься от этого ужасного совета по безопасности ... Ваша аналогия с почтой не совсем точна по нескольким причинам. Одна из них заключается в том, что вы обычно не можете внедрить эксплойты в ответную почту, или безнаказанно выдать себя за кого-то другому, или отправить сообщение «Срок действия сеанса истек» в ответное письмо, чтобы они повторно вводили учетные данные, которые они используют для обоих Yahoo! и их банк.
Парфянский выстрел

Среди прочего, повторное использование пароля и фиксация сеанса не являются проблемами в обычной почте.
Парфянский выстрел

Это хорошие моменты, но вы применяете анализ 2016 года к обсуждению в 2010 году.
Дэвид М.

12

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


+1 Его причина , почему Google App Engine не поддерживает протокол HTTPS на пользовательских доменов. Ожидание более широкой поддержки TLS-SNI.
Sripathi Krishnan

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

за исключением того, что в одном сертификате может быть несколько доменов.
лукаскаро

10
Совсем неправда. (Во всяком случае, больше нет.)
Парфянский выстрел

7
Голосование против, поскольку информация в сообщении устарела. SNI теперь поддерживается всеми основными браузерами.
Martin Törnwall

5

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

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

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

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


4

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

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


3

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


Ну, за исключением прокси с завершением SSL или если вы используете CDN с поддержкой HTTPS.
Парфянский выстрел

3

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


0

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

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

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


9
зачем это сбивать с толку пользователей? Сколько на самом деле смотрят протокол uri?
Malfist

Сегодня, 10 лет спустя, https стал более распространенным явлением, и http будет сбивать с толку
madprops

0

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


0

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

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


2
Поскольку пользователь уже защищает часть сайта, стоимость сертификата более или менее спорна.
futureelite7

2
@ futureelite7 хороший замечание, но, вероятно, актуально для других, которые могут исследовать эту тему в будущем.
3ave

Фатуризм - враг безопасности. Большинство слабых мест в моей работе проистекает из какой-то необдуманной особенности, которую я или мой предшественник включили в план продукта. Я считаю, что запуск функции из-за того, что она вызывает уязвимость системы безопасности, не делает вас более популярным, чем отказ от нее в первую очередь. Популярность НЕ ДОЛЖНА иметь значение, но, к сожалению, она может иметь значение. На вашем месте я бы спросил себя, насколько я действительно хочу иметь дело с незащищенными пользователями, и подходит ли приложение даже для пользователей, которые не могут использовать шифрование (подумайте: банковское дело, политика, активизм).
Джейсон

0

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

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

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


1
Дополнительная полоса пропускания мала даже в худшем случае.
Президент Джеймс К. Полк

0

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

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


0

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


1
Какое это имеет отношение к вопросу? Это интересная функция, но я не вижу актуальности.
user1618143
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.