Нужно ли использовать http для входа на https на следующих страницах? - PullRequest
5 голосов
/ 01 февраля 2010

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

  1. Должен ли я переключиться обратно на http после аутентификации пользователя по https (при условии, что конфиденциальная информация не передается после входа в систему)? Потому что это может загрузить страницу немного быстрее?

  2. Будет ли это создавать дополнительные издержки с точки зрения разработки (с Zend Framework)? Как поддержка различных структур каталогов и все такое.

Ответы [ 4 ]

5 голосов
/ 01 февраля 2010
  1. Если данные не являются конфиденциальными, вы можете переключиться обратно на http после аутентификации пользователей, чтобы получить небольшое преимущество в скорости. Вам не забудьте снова переключиться на https, если на сайте появятся какие-либо конфиденциальные данные (например, профиль пользователя или тому подобное). На самом деле может быть проще иметь весь сеанс всегда зашифрованным, поэтому вам не придется беспокоиться о включении и выключении шифрования в зависимости от содержимого страницы.

  2. SSL прозрачен для разработчиков, вы создаете свое приложение точно так же, как и для незащищенного сервера. Вам необходимо иметь сертификат SSL, который вы можете купить или сгенерировать самостоятельно, и настроить свой сервер для его обработки. Тогда в зависимости от протокола (http или https) ваш сеанс будет или не будет зашифрован автоматически. Поэтому необходимо установить правильные ссылки https: // для страниц, для которых требуется шифрование, и стандартные ссылки http: // для других страниц.

2 голосов
/ 01 февраля 2010

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

Дополнительные папки зависят от вашего сервера, а не от вашей платформы. Если ваш сервер направляет все запросы https через папку / httpsdocs или что-то еще, вы можете добавить туда файл .htaccess, который перенаправит его в папку / httpdocs.

1 голос
/ 01 февраля 2010

VolkerK прав, но его ответ ошибочен. Сеанс может быть скомпрометирован всеми видами методов. Есть способы обойти это (например, использовать кэшированную клиентскую часть javascript для генерации хешей против фиксированной соли запроса, генерируемого на каждой странице), но они беспорядочные. Безусловно, самое простое решение - всегда использовать SSL. Однако вы можете рассмотреть возможность использования дайджест-аутентификации в сочетании с файлом cookie сеанса.

Тор Валамо не прав. В наши дни пропускная способность очень дешевая, однако трудно добиться устранения задержки - а задержка является основным фактором, определяющим скорость передачи HTTP (где большая часть контента относительно мала). Для HTTP-запроса к серверу необходимо выполнить не менее двух циклов - квитирование TCP, а затем запрос / ответ. Он будет варьироваться в зависимости от размера файлов и других факторов, но обычно задержка прохождения туда и обратно составляет 50-70% от времени, затраченного на выборку объекта.

Использование Keep-alives исключает одно из обращений и, следовательно, значительно повышает пропускную способность.

При использовании SSL требуется как минимум одна дополнительная передача в оба конца (для возобновления существующего сеанса SSL) и более одной для первоначального согласования SSL. Настоящим убийцей является то, что нестандартная реализация SSL в Microsoft означает, что вы не можете использовать keep-alives для чего-либо кроме MSIIS при общении с клиентом MSIE (дополнительную информацию см. В документации mod_ssl).

0 голосов
/ 01 февраля 2010
  1. Да, вы можете переключиться обратно на http после передачи пароля пользователя. Нет необходимости шифровать весь контент, если на нем нет конфиденциальных данных. Если вы зашифровали ВСЕ сайты: сервер должен зашифровать все данные, а производительность вашего сервера ниже, чем без шифрования.
...