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

Question

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

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

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

Answer 1

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

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

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

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

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

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

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

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

В старых браузерах возникают проблемы с загрузкой файлов, когда они защищены SSL

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

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

Answer 2

Начиная с 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 занимает много процессорного времени, и мы надеемся, что приведенные выше цифры (впервые опубликованные) помогут развеять это.

Answer 3

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

Зачем использовать SSL на всем

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 6

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

Answer 7

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

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