Czy http powinien być używany do kolejnych stron https?

Question

Widziałem wiele wątków na SO i sugerują, że hasła nie można bezpiecznie przenieść bez protokołu SSL. Więc załóżmy mam https strona logowania ale

1. powinienem wrócić do http po użytkownik został uwierzytelniony przez HTTPS (zakładając, że nie jest wrażliwy na informacje przesyłane po zalogowaniu)? Ponieważ może załadować stronę nieco szybciej?

2. Czy spowodowałoby dodatkowe obciążenie w zakresie rozwoju (z Zend Framework)? Jak utrzymanie różnych struktur katalogów i tak dalej.

Answer 1

1. Jeśli dane nie jest wrażliwy można przełączyć z powrotem do http po uwierzytelniania użytkowników, aby uzyskać niewielką korzyść prędkości. Musisz pamiętać, aby ponownie przejść na https, jeśli w witrynie pojawią się jakieś poufne dane (np. Profil użytkownika lub inne). W rzeczywistości może być łatwiejsze zaszyfrowanie całej sesji, dzięki czemu nie będziesz musiał się martwić o włączanie i wyłączanie szyfrowania w zależności od zawartości strony.

2. SSL jest przezroczysty dla programistów, tworzysz aplikację dokładnie tak samo jak na niezabezpieczonym serwerze. Musisz mieć certyfikat SSL, który możesz kupić lub wygenerować samodzielnie, i skonfigurować serwer, aby sobie z nim poradził. Następnie w zależności od protokołu (http lub https) twoja sesja będzie lub nie będzie szyfrowana automatycznie. Jest więc kwestia ustawienia poprawnych linków https: // dla stron, na których potrzebujesz szyfrowania i standardowych linków http: // dla innych stron.

Answer 2

1. Tak, można powrócić do http po przekazanie hasła użytkownika. Nie ma potrzeby przerywania całej zawartości, gdy nie ma na niej żadnych poufnych danych. Kiedy masz zaszyfrowane WSZYSTKIE witryny: serwer musi kryptować wszystkie dane, a twój serwer ma najgorszą wydajność, niż bez szyfrowania.

Answer 3

Czas potrzebny do zaszyfrowania i odszyfrowania połączenia SSL (po jego zainicjowaniu) jest nieistotny w porównaniu do czasu potrzebnego na przesłanie danych. Więc nie, to nie załaduje "trochę" nawet szybciej.

Dodatkowe foldery zależą od serwera, a nie od frameworka. Jeśli serwer kieruje wszystkie żądania https przez folder/httpsdocs lub coś podobnego, można umieścić w nim .htaccess, który przekieruje go do folderu/httpdocs.

Answer 4

VolkerK ma rację, ale jego odpowiedź jest po stronie ostrożności. Sesja może być zagrożona przez różnego rodzaju metody. Istnieją sposoby obejścia tego problemu (na przykład użycie buforowanej strony klienta javascript do generowania skrótów w stosunku do ustalonej soli wyzwania wygenerowanego na każdej stronie), ale są one niechlujne. Zdecydowanie najprostszym rozwiązaniem jest zawsze używać SSL. Możesz jednak rozważyć użycie uwierzytelniania digest połączonego z plikiem cookie sesji.

Tor Valamo jest błędny. Obecnie przepustowość jest bardzo niska, jednak trudno jest uzyskać opóźnienie - opóźnienie jest podstawowym wyznacznikiem prędkości przesyłania HTTP (gdzie większość treści jest stosunkowo niewielka). W przypadku żądania HTTP są co najmniej 2 rundy wycieczki do serwera - uzgadnianie TCP, a następnie żądanie/odpowiedź. Będzie on różnił się w zależności od wielkości plików i innych czynników, ale zazwyczaj opóźnienia w obiegu wynoszą 50-70% czasu, jaki upłynął do pobrania obiektu.

Użycie Keep-alive eliminuje jedno z podróży w obie strony, a zatem znacznie zwiększa przepustowość.

W przypadku protokołu SSL jest wymagana co najmniej jedna dodatkowa podróż w obie strony (aby wznowić istniejącą sesję SSL) i więcej niż jedną dla wstępnej negocjacji protokołu SSL. Prawdziwym zabójcą jest to, że niestandardowa implementacja protokołu SSL przez Microsoft oznacza, że ​​nie można używać aliasów keep-alives z niczego innego niż MSIIS podczas rozmowy z klientem MSIE (zobacz dokumentację mod_ssl, aby uzyskać więcej informacji).