http должен использоваться для последующих страниц входа в систему https?
Я видел много потоков на ТАК, и они предполагают, что пароль не может быть надежно передан без SSL. Поэтому предположите, что у меня есть https страница входа в систему, но
Я должен переключиться назад на http после того, как пользователь аутентифицировался по https (предполагающий, что никакая уязвимая информация не отправляется после входа в систему)? Поскольку это могло бы загрузить страницу немного быстрее?
Это создало бы дополнительные издержки с точки зрения разработки (с Платформой Зенда)? Как поддержание различных структур каталогов и всего это.
4 ответа
Если данные не являются конфиденциальными вы можете вернуться к http после аутентификации пользователей, чтобы получить небольшое преимущество в скорости. Вы должны помнить, чтобы переключиться на https снова, если любой вид конфиденциальных данных будет отображаться на сайте (например, профиль пользователя и т.д.). На самом деле, может быть проще, чтобы весь сеанс всегда был зашифрован, поэтому вам не придется беспокоиться о включении и выключении шифрования в зависимости от содержимого страницы.
SSL прозрачен для разработчиков, вы создаете свое приложение точно так же, как и для небезопасного сервера. Вам действительно нужно иметь сертификат SSL, который вы можете купить или сгенерировать самостоятельно, и настроить ваш сервер для работы с ним. Тогда в зависимости от протокола (http или https) ваш сеанс будет или не будет зашифрован автоматически. Поэтому необходимо установить правильные ссылки https:// для страниц, где требуется шифрование, и стандартные ссылки http:// для других страниц.
- Да, вы можете переключиться обратно на http после передачи пароля пользователя. Нет необходимости криптовать все содержимое, когда на нем нет конфиденциальных данных. Когда у вас есть зашифрованные ВСЕ сайты: серверу нужно зашифровать все данные и ваш сервер имеет худшую производительность, чем без криптографии.
Время требуется для зашифрованного и расшифрованного соединения SSL (после его инициализации) незначительно по сравнению с тем временем требуется для передачи данных. Так что нет, это не будет загружаться «немного» быстрее.
Дополнительные папки зависят от вашего сервера, а не в вашей структуре. Если вы серверные маршруты все запрашивает все HTTPS через папку A / HTTPSDOCS или что-то, вы можете поставить в него .htaccess, которая перенаправляет его к папке / httpdocs.
Волкерк прав, но его ответ ошибается на стороне осторожности. Сеанс может быть скомпрометирован всевозможными методами. Есть пути вокруг этого (например, с использованием кэшированного JavaScript-клиентской сторон, чтобы генерировать хеши с фиксированной солью задачи, создаваемой с каждой страницей), но они грязны. Безусловное самое простое решение - всегда использовать SSL. Однако вы можете рассмотреть возможность использования версики дайджеста в сочетании с сеансом cookie.
Тор Валамо неверно. Эти дни пропускной способности очень дешевы, однако то, что трудно достичь, - это устранение задержки - и задержка является основным детерминантом скорости передачи HTTP (где большинство контента относительно небольшая). Для HTTP-запроса есть как минимум 2 круглых поездок на сервер - рукопожатие TCP, затем запрос / ответ. Он будет варьироваться в зависимости от размера файлов и других соображений, но, как правило, задержка с круглым путешествием составляет 50-70% от прошедшего времени, необходимого для получения объекта.
Использование ALEM-ALIVES устраняет один из круглых поездок и поэтому значительно улучшает пропускную способность.
С SSL требуется хотя бы одна дополнительная круглая поездка (для возобновления существующего сеанса SSL) и более одного для начальных переговоров SSL. Настоящий убийца состоит в том, что нестандартная реализация Microsoft означает, что вы не можете использовать ALEVE-ALIVES от чего-либо, кроме MSII, когда разговаривать с клиентом MSIE (см. Документы MOD_SSL для получения дополнительной информации).