Вместо того, чтобы иметь только несколько страниц для доступа к HTTPS, я думал только об использовании SSL для всего моего сайта.
Какими были бы недостатки?
Редактировать 7 августа 2014 года
Google теперь влияет на HTTPS для ранжирования, поэтому вы абсолютно должны использовать SSL на всем своем сайте:
http://googleonlinesecurity.blogspot.com/2014/08/https-as-ranking-signal_6.html
Настоятельно рекомендуется в эти дни запускать весь сайт на TLS (https, если есть), если это возможно.
Накладная забота ушла в прошлое, она больше не является проблемой для новых протоколов TLS, поскольку теперь она поддерживает сеансы и даже кэширует их для повторного использования, если клиент отключает соединение. В прежние времена это было не так. Это означает, что сегодня, когда вы устанавливаете соединение, вы должны использовать криптовый ключ с открытым ключом (тип, тяжелый процессор). Таким образом, на самом деле нет никаких недостатков, когда у вас есть сертификат. Это означает, что вам не придется отправлять людей туда и обратно между http и https, и клиенты всегда будут видеть знак блокировки в своем браузере.
Дополнительное внимание было уделено этому вопросу после выпуска Firesheep. Как вы, возможно, слышали, что Firesheep - это аддон Firefox, который позволяет вам легко (если вы используете одну и ту же открытую сеть Wi-Fi), занимаетесь игрой на других сайтах на таких сайтах, как Facebook, Twitter и т.д. Это работает, потому что эти сайты используют TLS выборочно и это не было бы проблемой для них, если бы TLS был включен на весь сайт.
Итак, в заключение, минусы (например, добавленное использование ЦП) незначительны с состоянием текущей технологии, а профи понятны, поэтому обслуживают весь контент через SSL/TLS! Это путь в эти дни.
Изменить: Как упоминалось в других ответах, другая проблема с обслуживанием содержимого сайта (например, изображений) без SSL/TLS заключается в том, что клиенты/пользователи получат очень раздражающий "небезопасный контент на безопасная страница".
Кроме того, как указанном в тридцать раз, вы должны перенаправить людей на сайт https. И вы даже можете включить флаг, который заставляет сервер отказывать в соединениях, отличных от ssl.
Другое изменение: Как указано в комментарии ниже, помните, что SSL/TLS - это не единственное решение для всего вашего сайта потребности в безопасности, есть еще много других соображений, но он решает несколько проблем безопасности для пользователей и решает их хорошо (даже если есть способы сделать "человек в середине", даже с помощью SSL/TLS )
Это хорошая идея сделать это, если это возможно, однако вы должны:
Недостатки включают:
Алгоритмы на стороне сервера для установления соединения SSL дороги, поэтому для обслуживания всего содержимого через SSL требуется больше мощности процессора на задней панели. Насколько я знаю, это единственный недостаток.
SSL не был предназначен для виртуального хостинга, особенно для типа эластичного облака. Вы можете столкнуться с некоторыми трудностями, если не можете управлять именами хостов веб-серверов и как они разрешают IP-адреса.
Но в целом, это отличная идея, и если вы разрешаете пользователям входить на ваш сайт, почти необходимо (как показано Firesheep).
Я также должен добавить то, что я пытаюсь сделать. Я хотел бы разрешить использование социальных сервисов (например, FaceBook), но мы также будем хранить информацию о кредитной карте.
Для страниц, на которых пользователь может просматривать информацию о своей кредитной карте или совершать финансовые транзакции, лучше перейти на более безопасный режим аутентификации. Facebook - большая цель и привлекает хакеров. Если кто-то Facebook-аккаунт взломается, и они могут потратить деньги или собрать информацию о кредитных картах с вашего сайта, это не будет хорошо. Принятие логинов социальных сервисов для некритичных материалов прекрасно, но для более серьезных частей вашего сайта лучше использовать дополнительные пароли.
Настоятельно рекомендуется в эти дни запустить всю сторону на TLS
Он очень рекомендуется некоторыми людьми.
В некоторых случаях (например, много денег на кону) имеет смысл просто укусить пулю и зашифровать все; в других случаях шансы атакующего, перехватывающего пакет в полете и принятие решения о захвате сеанса, настолько низки, и количество урона, которое может быть сделано, настолько мало, вы можете просто пойти набок, так как он работает. (Например, этот сеанс, который я использую для публикации этого ответа, незашифрован, и мне действительно все равно.)
В других случаях вы можете предложить своему пользователю выбор. Кто-то, использующий проводное соединение в своем собственном подвале, может сделать другую ситуацию, чем кто-либо, использующий WiFi в Starbucks через соглашение Black Hat.
Я работаю над протоколом и библиотекой, чтобы вы могли подписывать XHR-запросы. Идея заключается в том, что весь сайт будет настроен как статические файлы HTML, CSS и JavaScript, которые будут загружены из CDN. Фактическое приложение было бы полностью выполнено с помощью JavaScript, выполняющего запросы AJAX и COMET. Любой запрос, который должен быть аутентифицирован, но, как практический вопрос, большинство запросов этого не делают. Я сделал несколько сайтов таким образом - они очень, очень масштабируемые.
Мы запускаем полностью принудительный, защищенный сайт и магазин. Я сделал это по совету друга, который знает кое-что о безопасности веб-сайта.
Положительным является то, что наш сайт не выглядит заметно медленнее. Также работает Google Analytics, хотя я не могу заставить электронную коммерцию работать. Если бы он защищал нас от атак, я не могу сказать ни слова, но до сегодняшнего дня никаких проблем.
Плохая вещь, однако, заключается в том, что вам будет очень сложно использовать Youtube и Social ( "Like" ) на защищенном веб-сайте.
Советы по обеспечению безопасности:
* 2 Я знаю, что это не пойдет на множество сайтов, но "то, что у вас нет, нельзя украсть". Мы продаем на нашем интернет-магазине без входа в систему уже 2 года, и он отлично работает, пока Checkout Mega просто и молниеносно.