Должны ли все сайты использовать SSL по умолчанию?

Ответ 1

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

SSL усложняет использование так называемых "виртуальных доменов". Традиционно для формирования SSL-соединения браузер и сервер должны работать с одним и тем же доменным именем. Это сделало невозможным размещение более одного сертификата SSL на одном IP-адресе, потому что сервер ответил бы с неправильным сертификатом. Реализации Указание имени сервера (расширение для протокола TLS, используемого SSL) устранило многие проблемы с этим.

При чистой производительности симметричное шифрование и проверка целостности туннелированных данных не очень дороги; если ваш сервер не может шифровать и расшифровывать на скорости сети, то либо у вас есть собственное оптическое волокно, либо вы должны подумать о замене этих i486. Однако инициирование SSL-соединения, называемое "рукопожатием", немного дороже и может означать узкое место в производительности при тяжелых нагрузках (когда есть сотни подключений в секунду или более). К счастью, данный экземпляр браузера будет повторно использовать туннели и сеансы SSL, поэтому это не проблема, если у вас всего несколько десятков пользователей.

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

Ответ 2

В ответ на ответ Томаса:

Для каждого сайта сертификат SSL имеет прямую стоимость. У нас есть среда dev, qa и prod и, следовательно, это три сертификата, которые необходимы для каждого сайта.

Вряд ли верно. Вам не нужно, чтобы каждый отдельный dev и qa поддерживал SSL с действующими действующими сертификатами. Вы, возможно, хотите создать один веб-сайт с действующим сертификатом. Но помимо интерфейсов Apache, ваш back-end не должен знать, что там задействован SSL. Вы не тестируете ничего уникального или специального, покупая сертификаты разработчика.

Кроме того, стоимость является номинальной. Вы тратите больше денег на разговор, чем фактически стоят сертификаты.

Для большинства страниц содержимое не является безопасным, и принудительное SSL заставляет запросы страниц занимать больше времени на сервере из-за шифрования и дешифрования

Немного. Вы измерили? Вы можете обнаружить, что это трудно измерить, потому что изменчивость интернет-скорости превосходит стоимость обработки SSL.

Из того, что я понимаю, большинство браузеров не кэшируют страницы, которые SSL'ed и, следовательно, снова, запросы страниц будут занимать больше времени

Опять же, вы это измерили?

У старых браузеров есть проблемы с загрузкой файлов, когда они SSL'ed

Действительно? Какой конкретный "старый браузер" вы планируете поддерживать, у которого есть эта проблема? Если вы не можете найти его и думаете, что у кого-то может возникнуть эта проблема, вы можете быть слишком сложным. Проверьте свои журналы и посмотрите, какие браузеры фактически используют ваши клиенты, а затем определите, есть ли у вас проблемы.

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

Ответ 3

По состоянию на 2012 год сайты должны использовать только SSL, если они имеют личную идентификационную информацию (PII) или коммерчески важную информацию, или если у них есть концепция входа.

Сайты, которые публикуют только низкоуровневую общедоступную информацию с низким уровнем доверия, являются немного спорными, но, вероятно, все же могут с пользой служить всем через HTTPS. Атакующие могут попытаться вставить вредоносное ПО или рекламное ПО или перенаправить в HTTP-контент.

Корпоративная политика "все через SSL, без конкретного исключения" разумна.

Вы также должны взглянуть на развертывание HTTP Strict Transport Security, чтобы убедиться, что даже первый запрос пользователя от ввода example.com отправляется через HTTPS.

Атаки "человек-в-середине" - это реальная проблема, особенно в сетях Wi-Fi, а также на уровне провайдера и страны. Если вы выполняете только фазу входа через SSL, а затем передаете незашифрованный файл cookie сеанса, этот файл cookie сеанса будет украден. См. Firesheep для четкой демонстрации.

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

Правильно реализованные SSL или SPDY могут быть быстрыми: служебные данные сервера невелики и легко перемещаются на отдельный обратный прокси-сервер. Существуют SSL CDN.

Нет необходимости покупать реальные сертификаты для сайтов, которые предназначены только для разработчиков и тестировщиков. Стоимость сертификатов в низких десятках долларов ничтожна даже для некоммерческих сайтов.

Шифрование данных по сети - полезный уровень защиты в глубину. Очевидно, этого недостаточно для обеспечения безопасности сервиса, но он устраняет некоторые проблемы и имеет низкую стоимость.

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

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

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

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

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

Адам Лэнгли из Google написал в 2010 году:

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

В январе этого года (2010) Gmail перешел на использование HTTPS для всего по умолчанию. Раньше он был представлен как вариант, но теперь все наши пользователи используют HTTPS для обеспечения электронной почты между браузерами и Google. Для этого нам не пришлось развертывать дополнительные машины и никаких специальных аппаратных средств. На наших производственных интерфейсных серверах SSL/TLS составляет менее 1% загрузки процессора, менее 10 Кбайт памяти на одно соединение и менее 2% сетевых издержек. Многие люди считают, что SSL занимает много процессорного времени, и мы надеемся, что вышеупомянутые цифры (публичные в первый раз) помогут устранить это.

Ответ 4

Итак, я видел несколько фантастических ответов на этот вопрос, но через несколько дней я увидел, что есть несколько недостающих вещей. Поэтому есть несколько вещей, которые я хочу упомянуть:

Зачем использовать SSL для всех

• Безопасность. Если только несколько страниц зашифрованы SSL, проще "вынюхать", какие страницы содержат конфиденциальные данные. Теперь SSL довольно безопасен, так что это не о чем беспокоиться, но в том случае, если ваш частный ключ становится скомпрометированным, хорошей практикой является наличие этого дополнительного уровня безопасности, так что трудным для плохих парней становится сочные вещи.
• Надежность. Есть люди, которые утверждают, что, когда вы посещаете сайт с проверенным сертификатом, его легче доверять. Поскольку проверенный сертификат стоит денег, легче доверять сайту, зная, что владелец инвестировал в символ доверия.
• Hassle. Ополаскивать все под SSL намного проще. Все, что вам нужно сделать, это отрубить http: в начале каждой ссылки ресурса, и вы хорошо.
• Конфигурация SEO. Вам не придется беспокоиться о настройке SEO. Я слышал, что индексы поисковых систем http:// и https:// являются отдельными записями, поэтому для согласованности (как для SEO, так и для поведения страниц) защита SSL через все и просто настройка 301 перенаправления кажется приятным простым решением.
• Консистенция. У вас будет гораздо более последовательный веб-сайт, если вы просто https:// все. Множество фреймворков ломается, когда вы пытаетесь сделать гибрид SSL и non-SSL. Кроме того, зависящие от URL плагины и код будут действительно иметь значение, если вы попытаетесь отскочить назад и вперед между http и https.
• Это нечеткое безопасное чувство. Вы должны признать, что небольшая зеленая полоса в левом верхнем углу, в которой говорится о "проверенном домене", просто чертовски хорошо.

Почему не SSL все

• Скорость. SSL медленнее. Разумеется, не много, а в большинстве случаев стоимость пренебрежимо мала. Однако неизбежным является тот факт, что SSL всегда будет медленнее.
• Совместимость с браузером. Это, вероятно, незначительно, но если вы хотите поддерживать старые действительно старые браузеры, которые не кэшируют через SSL, вам придется придерживаться порта 80.
• Плагины. Куча плагинов не работает корректно через SSL, поэтому вам нужно быть осторожным. Если вы захотите добавить новый плагин, вам придется перенастроить настройки SSL или искать другой плагин.
• Профессионализм. Теперь, хотя некоторые люди утверждают, что просмотр доверенного домена SSL кажется заслуживающим доверия, другие считают его очень любимым и ленивым решением. На самом деле, это действительно легко и дешево (стоимость мне около $10), чтобы получить проверенный SSL-сертификат, который попадает до 96% браузеров!
• Hassle. Поэтому я сказал, что упростить SSL все, но в то же время вам нужно будет убедиться, что каждый ресурс загружен через https:// (или выполните http:// -> // быстрое решение). Это может быть немного утомительно, если у вас есть куча ссылок или даже несовместимо, если у вас есть контент, отправленный пользователями на сайте, который не поддерживает SSL. В этих случаях ваш браузер будет скулить на вас. Если вы когда-либо видели это уведомление, в котором говорится, что "эта страница имеет небезопасный контент", вы узнаете, насколько это раздражает и как плохо выглядит.

Короче говоря, это действительно ситуативно, но я склонен избегать защитного SSL. Конечно, это требует немного большей настройки, но в итоге вы получаете гораздо более гибкую систему. Я лично считаю, что весь "профессионализм" - это фигня (Twitter и Google SSL все). Однако, если у вас есть внешний контент или контент, размещенный пользователем, обычно это очень плохая идея для SSL. Вы также можете начать SSL-все и столкнуться с кучей неприятностей.

Но это только я.: D

Ответ 5

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

Ответ 6

В другом ответе на ответ Томаса, тем более, что он сверху.

Кроме того, в дальнейшем я связал технический документ с передовыми методами SSL.

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

Только частично верно. SSL предотвратит кэширование прокси, но не кеширование браузера - также см. Ответы на этот вопрос. На мой взгляд, это не большая проблема.

SSL предотвращает использование так называемых "виртуальных доменов". [...]

Это отчасти верно. Тем не менее, виртуальные домены будут работать нормально, пока у вас есть только один сертификат. Даже если вы этого не сделаете, "Имена имени сервера" (SNI) должна стать жизнеспособной альтернативой (или должна быть, как только Windows XP окажется на грани планеты).

[производительность] Однако инициирование SSL-соединения, известного как "рукопожатие", немного дороже, и может означать узкое место производительности при тяжелых нагрузках (когда есть сотни подключений в секунду или более), К счастью, данный экземпляр браузера будет повторно использовать туннели и сеансы SSL, поэтому это не проблема, если у вас всего несколько десятков пользователей.

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

Другими словами: настройка SSL-соединения будет на порядок дешевле, чем рендеринг страницы PHP, которая извлекает данные из базы данных.

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

НЕ ИСТИНА НА ВСЕ. Либо вам не нужен SSL вообще на вашем сайте, потому что он полностью публичный контент. Или вам почему-то нужен SSL (пользовательские логины, защищенные области). В этом случае наилучшей практикой является ее повсеместное распространение.

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

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

В этой безопасности имеется более одного компонента. Но уже первое недоразумение не является хорошим началом.

Ответ 7

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

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