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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С 2020 года все сайты должны использовать SSL.

• Сертификаты предоставляются Let's Encrypt бесплатно с 2016 года.
• Chrome и Firefox с 2018 года отмечают простые HTTP-сайты как небезопасные.
• Google с 2017 года налагает штрафы на SEO для простых HTTP-сайтов.

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

Рекомендуется корпоративная политика в отношении всего использования SSL без особых исключений. Стандарты безопасности (PCI-DSS, ISO, аудит big4 и т. д.) предполагают шифрование для систем, работающих с конфиденциальной информацией, и отсутствие это считается красным флагом.

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

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

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

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

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

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

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

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

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

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

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

• клиенты - это архаичный IE или встроенные клиенты, которые просто не могут адекватно использовать SSL - в 2020 году такие клиенты будут очень старыми (и, вероятно, опасными)

• на сайте очень много ресурсов, и вы хотите, чтобы роботы индексировали его через HTTPS - Google и, вероятно, другие боты справятся, если вы принудительно установите все на HTTPS

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

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

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

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

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

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

• Безопасность. Если SSL-шифрование зашифровано только на нескольких страницах, легче «вынюхать», какие страницы содержат конфиденциальные данные. Теперь SSL чертовски безопасен, поэтому не о чем беспокоиться, но в случае, если ваш закрытый ключ будет скомпрометирован, рекомендуется иметь этот дополнительный уровень безопасности, чтобы злоумышленникам было труднее добраться до сочная штука.
• Надежность. Есть люди, которые утверждают, что, когда вы посещаете сайт с проверенным сертификатом, ему легче доверять. Поскольку проверенный сертификат стоит денег, сайту проще доверять, зная, что владелец вложил деньги в символ доверия.
• Проблемы. Защитить все, используя 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% браузеров!
• Проблемы. Я сказал, что использовать SSL для всего проще, но в то же время вам нужно будет убедиться, что все ресурсы загружаются через https:// (или использовать быстрое решение http:// -> //). Это может быть немного утомительно, если у вас есть куча ссылок, или даже несовместимое, если у вас есть отправленный пользователем контент, размещенный на сайте, который не поддерживает SSL. В таких случаях ваш браузер будет ныть на вас. Если вы когда-нибудь видели это уведомление, в котором говорится, что «на этой странице небезопасный контент», вы знаете, как это раздражает и как плохо выглядит.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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