https (SSL) вместо http для мобильных пользователей
Я создаю себе новый веб-сайт, исходя из соображений конфиденциальности и безопасности, я подумываю о том, чтобы сделать его только https.
Это будет удобно для мобильных устройств с использованием медиа-запросов, но я обеспокоен - особенно для мобильных пользователей - увеличением пропускной способности.
Насколько это увеличит мою пропускную способность или замедлит время загрузки? Для страниц, на которых я не передаю конфиденциальную информацию, следует ли мне оставлять внешние ссылки (на библиотеку jQuery или веб-шрифт для экземпляр) в http?
Проще говоря, я читал статьи о том, что весь Интернет был бы более безопасным, если бы все было SSL, но мои фактические знания о реализации ограничены платежными шлюзами, страницами входа в систему и тому подобным. Я приношу извинения за открытый характер вопроса, но приветствуется все, даже просто простые ответы на конкретные вопросы.
3 answers
(Вас может заинтересовать этот связанный с этим вопрос по SO: Сделать полный сайт HTTPS/SSL? Какие проблемы с производительностью и лучшие практики все еще применяются в 2012?)
Насколько это увеличит мою пропускную способность или замедлит время загрузки?
После завершения рукопожатия шифрование выполняется с использованием симметричных ключей. Для записей SSL/TLS есть небольшие накладные расходы, но на самом деле они довольно малы (по данным инженеров Google, около 2% сети накладные расходы).
Что дорого, так это рукопожатие (как с точки зрения процессора, так и сети). Без возобновления сеанса вам придется получить сертификат сервера (около 1 КБ для сертификата с 2048-битным ключом RSA, это зависит от атрибутов). Поездки туда и обратно также могут увеличить задержку (и могут быть более серьезной проблемой на мобильных устройствах). Я предполагаю, что некоторые мобильные устройства, по крайней мере, поддерживают возобновление сеанса.
Самый большой трафик рукопожатий, который я видел, был связан с длительными сертификационными центрами список в сообщении TLS с запросом сертификата при использовании аутентификации по сертификату клиента. Это было настроено с хранилищем доверия по умолчанию (на сервере Java). Хорошая настройка сервера может избежать этой проблемы (когда вы используете аутентификацию с сертификатом клиента, вы обычно можете ограничиться несколькими центрами сертификации, которые вы готовы принять, с точки зрения сервера, вам не нужен список по умолчанию, в котором в данном случае было более 100 имен). Если вы вообще не используете аутентификацию по сертификату клиента, убедитесь, что вы не включайте его (даже необязательно), чтобы у вас не возникло этой проблемы.
Для страниц, на которых я не передаю конфиденциальную информацию, следует ли мне оставлять внешние ссылки (например, на библиотеку jQuery или веб-шрифт) в http?
Да, никогда не смешивайте контент. Это противоречит цели HTTPS. Проблема со смешанным контентом заключается в том, что вы больше не знаете, какой части страницы вы можете доверять. Это проблема пользовательского интерфейса (и мобильные браузеры уже довольно плохи с точки зрения его создания ясно, в каких условиях безопасности вы находитесь).
При необходимости вы можете использовать CDN, поддерживающие HTTPS ( API библиотек Google предоставляет https:// ссылки, например, в том числе для jQuery).
Современные браузеры должны кэшировать содержимое HTTPS по умолчанию, хотя некоторые могут этого не делать, и в этом случае вы можете использовать заголовок Cache-Control: public. Вы также должны запретить кэширование конфиденциальных страниц.
Пропускная способность не должна увеличиваться настолько сильно. При настройке https-соединения требуется немного дополнительных согласований, и, поскольку шифрование расширяет возможности до определенного размера блока, страницы могут стать немного больше.
Время загрузки может увеличиться из-за накладных расходов на шифрование страницы на вашем конце и расшифровку страницы на конце пользователя. Я не могу сказать, насколько сильно, потому что я не знаю вашего оборудования, и никто из нас не знает, насколько мощны мобильные устройства пользователя являются.
Если у вас есть защищенная страница с незащищенным контентом, браузер пользователя может выдать тревожное сообщение об ошибке.
Я бы зашифровал только страницы с конфиденциальной информацией на них.
HTTPS не обеспечивает никакой надежной защиты, поскольку он уязвим для атаки MiTM. Это просто немного усложняет задачу (совсем немного). Я не вижу преимущества по сравнению с затратами на создание полноценного https-сайта.