Czy przekierowywanie http na https jest złe?

247

Właśnie zainstalowałem certyfikat SSL na moim serwerze.

Następnie skonfigurował przekierowanie dla całego ruchu w mojej domenie na porcie 80, aby przekierować go do portu 443.

Innymi słowy, cały mój http://example.comruch jest teraz przekierowywany do odpowiedniej https://example.comwersji strony.

Przekierowanie odbywa się w moim pliku Apache Virtual Hosts za pomocą czegoś takiego ...

RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L] 

Moje pytanie brzmi: czy są jakieś wady korzystania z SSL?

Ponieważ nie jest to przekierowanie 301, czy utracę sok / pozycję linku w wyszukiwarkach, przechodząc na https?

Doceniam pomoc. Zawsze chciałem skonfigurować SSL na serwerze, tylko ze względu na praktykę robienia tego i ostatecznie zdecydowałem się to zrobić dziś wieczorem. Wygląda na to, że do tej pory działało dobrze, ale nie jestem pewien, czy warto używać tego na każdej stronie. Moja strona nie jest eCommerce i nie obsługuje poufnych danych; dotyczy głównie wyglądu i emocji związanych z instalacją go do nauki.


AKTUALIZACJA

Dziwnie Bing tworzy ten zrzut ekranu z mojej strony, teraz, gdy używa HTTPS wszędzie ...

wprowadź opis zdjęcia tutaj

JasonDavis
źródło
12
[WTF - Nie mogę dodać odpowiedzi (choć wydaje się, że mam wystarczającą liczbę powtórzeń).] Moja odpowiedź byłaby (częściowo) taka, że CZASEM JEST ZŁA . Rozważ przekazanie klucza COOKIE lub API w GET przez HTTP. Jeśli witryna przekierowuje żądania HTTP do żądań HTTPS, wywołania te działałyby, ale COOKIE lub klucz API byłyby przesyłane w sposób jawny. Niektóre interfejsy API wyłączają HTTP, bardziej niezawodne podejście - brak HTTP w ogóle, więc nie można go uruchomić, dopóki nie użyje się HTTPS. Przykład: „Wszystkie żądania API muszą być dokonywane za pośrednictwem HTTPS. Połączenia wykonywane przez zwykły HTTP zakończą się niepowodzeniem” z stripe.com/docs/api?lang=php#authentication
codingoutloud
8
@codingoutloud - alternatywą jest to, że wszystko dzieje się przez HTTP bez HTTPS. Jak to jest lepsze?
Mark Henderson
3
@BenCrowell, to dlatego, że portal w niewoli wygląda okropnie jak sslstripatak przekierowujący w stylu (oba są przejmującymi żądanie man-in-the-middle), więc przeglądarki HSTS -aware zablokują je oba.
Jeffrey Hantin
3
pamiętaj, że korzystanie z protokołu https oznacza, że ​​wszystko, co zawierasz, powinno być również protokołem https, w przeciwnym razie może się nie ładować - np. ładować jquery za pomocą src="://example.com/jquery.js"- zwróć uwagę na brak przeglądarki httplub httpstak ładuje odpowiednią. Miałem koszmar, aby niektóre osadzone rzeczy Amazon ładowały się poprawnie, ponieważ API (ładowane przez https) produkowało linki http - co oznacza, że ​​nie działały one poprawnie, dopóki nie znalazłem nieudokumentowanego parametru do przełączania łączy https
Basic
3
Jason; Twoja aktualizacja powinna być nowym pytaniem, prawdopodobnie dla webmasterów, ponieważ nie jest powiązana (technicznie) z pierwotnym pytaniem. Ale prawdopodobnie twoje arkusze stylów pochodzą z niepewnej domeny.
Mark Henderson

Odpowiedzi:

316

[R]Flag na własną rękę jest 302przekierowanie ( Moved Temporarily). Jeśli naprawdę chcesz, aby osoby korzystające z Twojej witryny korzystały z wersji HTTPS (wskazówka: robisz), powinieneś używać [R=301]stałego przekierowania:

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L] 

A 301utrzymuje nienaruszone wszystkie twoje google-fu i ciężko zarobione strony . Upewnij się, że mod_rewritejest włączony:

a2enmod rewrite

Aby odpowiedzieć na dokładne pytanie:

Czy przekierowywanie http na https jest złe?

Piekło nie To jest bardzo dobre.

Mark Henderson
źródło
3
Dzięki za informacje, mój szef powiedział mi, że powodem, dla którego uruchamia https tylko na niektórych stronach swojej witryny, jest to, że używa o wiele więcej zasobów serwera, aby uruchomić go na każdej stronie. Wiesz coś na ten temat, czy to prawda?
JasonDavis
9
@jasondavis Tylko jeśli nie poświęcisz kilku minut na jego optymalizację .
Michael Hampton
10
„używa o wiele więcej zasobów serwera, aby uruchomić go na każdej stronie”. Nowoczesne procesory mają funkcje przyspieszania szyfrowania, dzięki czemu protokół SSL jest prawie bezpłatny. Nie martw się o koszty ogólne.
Adam Davis
41
@AdamDavis Algorytm kryptograficzny może być lekki, ale narzut związany z uzgadnianiem nadal istnieje. Ponadto HTTPS zapobiega buforowaniu zawartości przez serwery proxy HTTP. W większości przypadków narzut HTTPS jest minimalny i opłacalny, ale należy zachować ostrożność przy nadmiernym uogólnianiu.
200_success
6
Zabija współdzielone buforowanie, które jest przydatne w przypadku niektórych wzorców użytkowania witryny i często niewiele chroni (czy ważne jest, aby ludzie wiedzieli, że odwiedziłeś witrynę, ale nie szczegóły tego, co zrobiłeś? To jedyna sytuacja, w której protokół SSL jest przydatny). Główną zaletą protokołu SSL dla każdego zasobu nie jest to, że trzeba „zabezpieczyć”, np. Osoby spoglądające na „o nas”, ale że nie można się poślizgnąć i nie skorzystać z niego w przypadku, gdy jest to konieczne.
Jon Hanna
49

Chociaż popieram pomysł witryn tylko z protokołem SSL, powiedziałbym, że jedną wadą są koszty ogólne w zależności od projektu witryny. Mam na przykład na myśli, że jeśli wyświetlasz wiele pojedynczych zdjęć w tagach img, może to spowodować, że Twoja strona będzie działać wolniej. Radzę każdemu, kto korzysta z serwerów obsługujących wyłącznie protokół SSL, aby upewnić się, że działają w następujących przypadkach.

  1. Sprawdź całą witrynę pod kątem wewnętrznych linków i upewnij się, że wszystkie używają HTTPS, jeśli podasz własną nazwę domeny w linkach, abyś nie powodował własnych przekierowań.
  2. Zaktualizuj swój <meta property="og:url"do korzystania z wersji domeny https.
  3. Jeśli użyjesz <base href=ponownie aktualizacji, aby użyć HTTPS.
  4. Zainstaluj protokół SPDY, jeśli to możliwe
  5. Upewnij się, że używasz duszków CSS Image, jeśli to możliwe, aby zmniejszyć liczbę żądań.
  6. Zaktualizuj mapy witryn, aby wskazywały stan https, więc z czasem pająki poznają tę zmianę.
  7. Zmień preferencje wyszukiwarki, takie jak Narzędzia Google dla webmasterów, aby wolały HTTPS
  8. Tam, gdzie to możliwe, należy rozładować wszelkie nośniki statyczne na serwerach CDN HTTPS.

Jeśli powyższe zostanie rozwiązane, wątpię, abyś miał wiele problemów.

TheBritishGeek
źródło
SPDY to dobra sugestia; tam nawet wydaje się być moduł dodawania SPDY wsparcie dla Apache 2.x .
Calrion
18
Używanie „//yourserver.com/some-uri” zamiast „ yourserver.com/some-uri ” rozwiązuje problem (1), ponieważ przeglądarka będzie wybrać odpowiedni schemat (http lub https) w zależności od schematu strona została załadowana .
MauganRa
1
@MauganRa Chyba że, oczywiście, jest to link ze strony artykułu http do strony logowania https.
Mołot
4
Google widzi adres URL, który ktoś odwiedza, za pośrednictwem Referernagłówka. Na przykład ta strona korzysta z jQuery z CDN Google, a moja przeglądarka wysyła do Google żądanie za każdym razem, gdy przeładuję stronę. W ten sposób Referernagłówek jest wysyłany do Google, który jest ustawiony na adres URL tej witryny. Dzięki temu Google może śledzić witryny odwiedzane przeze mnie, gdy mój adres IP się nie zmienia (a jeśli w tym czasie korzystam z usługi Google, Google może również połączyć te informacje z moim kontem Google).
Stephan Kulla
1
Dla 1) Właśnie przeszukałem i zamieniłem w mojej bazie danych MySQL http na https ... używam WordPress, dzięki czemu bardzo łatwo zaktualizowałem setki linków
JasonDavis
38

Mam skonfigurowane https, więc powinieneś używać go wszędzie na stronie. Unikniesz ryzyka problemów z mieszaną treścią, a jeśli masz wymagane narzędzia, dlaczego nie zabezpieczyć całej witryny?

Jeśli chodzi o przekierowanie z http na https, odpowiedź nie jest taka prosta.

Przekierowanie znacznie ułatwi użytkownikom, po prostu wpisują na whateversite.com i zostają przekierowani na https.

Ale. Co się stanie, jeśli użytkownik czasami znajduje się w niezabezpieczonej sieci (lub jest blisko Troy Hunt i jego ananasa )? Następnie użytkownik poprosi http://whateversite.com o stary nawyk. To jest http. To może być zagrożone. Przekierowanie może wskazywać na https://whateversite.com.some.infrastructure.long.strange.url.hacker.org . Dla zwykłego użytkownika wyglądałoby to całkiem legalnie. Ale ruch może zostać przechwycony.

Mamy więc dwa konkurujące ze sobą wymagania: być przyjaznym dla użytkownika i bezpiecznym. Na szczęście istnieje rozwiązanie zwane nagłówkiem HSTS . Za jego pomocą możesz włączyć przekierowanie. Przeglądarka przejdzie do bezpiecznej strony, ale dzięki nagłówkowi HSTS również ją zapamiętaj. Gdy użytkownik wpisze w whateversite.com siedzącą w tej niezabezpieczonej sieci, przeglądarka od razu przejdzie na https, bez przechodzenia przez przekierowanie na http. Chyba że masz do czynienia z bardzo wrażliwymi danymi, uważam, że jest to sprawiedliwy kompromis między bezpieczeństwem a użytecznością w przypadku większości witryn. (Kiedy ostatnio konfigurowałem aplikację do obsługi dokumentacji medycznej, połączyłem wszystkie https bez przekierowania). Niestety Internet Explorer nie obsługuje HSTS ( źródło), więc jeśli twoi odbiorcy najczęściej używają IE, a dane są wrażliwe, możesz chcieć wyłączyć przekierowania.

Więc jeśli nie jesteś kierowany do użytkowników IE, skorzystaj z przekierowania, ale włącz także nagłówek HSTS.

Anders Abel
źródło
Więcej osób również musi na to zwrócić uwagę. Inną rzeczą jest to, że ludzie zakładają, że są bezpieczne, ponieważ punktem końcowym jest HTTPS, ignorując fakt, że wszystkie informacje wysyłane na stronę w GET lub POST są w postaci zwykłego tekstu.
Velox
3
@Velox - Nie sądzę, że implikacja „ludzie zakładają, że są bezpieczni, ponieważ punktem końcowym jest HTTPS, ignorując fakt, że wszystkie informacje wysyłane na stronę w GETs lub POST są zwykłym tekstem” jest dość dokładne. Chociaż istnieją pewne problemy, parametry zapytań GET nie przemieszczają się w sposób wyraźny podczas transportu przez HTTPS. Patrz na przykład: stackoverflow.com/questions/323200/... Ładunki POST są również chronione, ale nie są również podatne na logowanie i nagłówki stron odsyłających.
codingoutloud
@codingoutloud To jest mój punkt widzenia. W przypadku HTTPS są one szyfrowane, ale w początkowym żądaniu strony HTTP nie były.
Velox
1
@Velox - Jeśli cała witryna przekierowuje do HTTPS, jest mało prawdopodobne, że jakiekolwiek parametry GET zostaną wysłane przed uruchomieniem HTTPS (i po tym czasie wszystko pozostanie HTTPS). Jest jeszcze jedno wstępne żądanie wysłania plików cookie, które można naprawić za pomocą HSTS ... i małe okno ataku dla SSLStrip, które może zostać pokonane przez JavaScript, ale to jest własny wyścig zbrojeń.
Brilliand
@Brilliand Dobry punkt, ale słaby punkt bezpieczeństwa sprawia, że ​​całość jest słaba. Zawsze warto rozważyć.
Velox
22

Nie ma w tym nic złego, a tak naprawdę jest to najlepsza praktyka (w przypadku witryn, które powinny być obsługiwane przez bezpieczne połączenie). W rzeczywistości to, co robisz, jest bardzo podobne do konfiguracji, której używam:

<VirtualHost 10.2.3.40:80>
  ServerAdmin [email protected]
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>

# Insert 10.2.3.40:443 virtual host here :)

301Kod statusu wskazuje na stałe przekierowanie, instruowania klientów zdolnych do korzystania z bezpiecznego adresu URL dla przyszłych połączeń (np zaktualizować zakładkę).

Jeśli witryna będzie obsługiwana tylko przez TLS / SSL, zaleciłbym kolejną dyrektywę, aby włączyć HTTP Strict Transport Security (HSTS) na bezpiecznym hoście wirtualnym:

<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=1234; includeSubdomains"
</IfModule>

Ten nagłówek instruuje zdolnych klientów (większość obecnie, jak sądzę), że powinni używać HTTPS tylko z podaną domeną ( secure.example.comw tym przypadku) przez następne 1234sekundy. Ta ; includeSubdomainsczęść jest opcjonalna i wskazuje, że dyrektywa ma zastosowanie nie tylko do bieżącej domeny, ale do każdej pod nią (np alpha.secure.example.com.). Zauważ, że nagłówek TGV jest tylko akceptowane przez przeglądarki, gdy podawane za pośrednictwem połączenia SSL / TLS!

Aby przetestować konfigurację serwera pod kątem bieżących najlepszych praktyk, dobrym darmowym zasobem jest usługa testowania serwera SSL Qualys ; Chciałbym zdobyć przynajmniej A- (z Apache 2.2 nie można uzyskać więcej niż to z powodu braku wsparcia dla kryptografii krzywej eliptycznej).

Calrion
źródło
Powinienem dodać, że wysłanie nagłówka Strict-Transport-Security: max-age=0neguje każdą poprzednią dyrektywę; jak zawsze, aby je zaakceptować, należy je przesłać przez HTTPS, ale jest to przydatny sposób anulowania rzeczy, jeśli zdecydujesz, że musisz również używać HTTP w domenie.
Calrion
5

Łał ! przekierowanie HTTP na HTTPS jest bardzo dobrą rzeczą i nie widzę w tym żadnych wad.

Upewnij się tylko, że Twoi klienci mają odpowiedni urząd certyfikacji, aby uniknąć nieprzyjaznych ostrzeżeń o certyfikacie w przeglądarce.

Ponadto sposób skonfigurowania Apache do przekierowywania na HTTPS wydaje się być w porządku.

krisFR
źródło
5

Czy przekierowywanie http na https jest złe?

Nie, wcale nie. Właściwie to jest dobra rzecz do zrobienia!

W przekierowaniach:

Może być bardziej wydajny, całkowicie eliminując przepisywanie . Oto moja konfiguracja w podobnej sytuacji ...

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>
Pothi Kalimuthu
źródło
4

HTTPS nie jest całkowicie niezawodny. Oczywiście normalne wymuszanie HTTPS jest dobrą rzeczą. Zapobiega to, by normalni przestępcy nie robili nic złego użytkownikom.

Pamiętaj jednak, aby sprawdzić ustawienia SSL, takie jak ustawienie SSLCiphers. Wyłącz takie rzeczy, jak krypto RC4, protokół SSLv2 i SSLv3. Ponadto powinieneś dowiedzieć się, czy biblioteki kryptosystemowe twojego systemu obsługują TLS1.2 (co jest tym, co chcesz mieć;))

Włącz SSL, to dobra rzecz.

Tobias Mädel
źródło
Entropia nie zużywa się ( przynajmniej jeśli bronisz się przed atakami z Ziemi, zamiast robić voodoo ). Albo zaczniesz od niewystarczającej entropii i nie możesz zrobić niczego, co wymaga losowości, albo zaczniesz od wystarczającej entropii i nadal będziesz mieć wystarczającą entropię bez względu na to, ile losowości wygenerujesz.
Gilles
Niestety, co ? W Linuksie jest wiele operacji, które domagają się silnej entropii wynikającej ze sprzętu, a nie prawdopodobnie wystarczająco dobrej entropii opartej na PRNG, i mogą one rzeczywiście blokować, jeśli głębokość puli jest niska. Z pewnością możliwe jest rozpoczęcie od wystarczającej entropii w systemie Linux, ale przez nadmierne użycie w celu opróżnienia puli, powodując blokowanie niektórych operacji.
MadHatter
3

Osobiście jestem za używaniem SSL do zabezpieczania połączeń w sieci, ale uważam, że wszystkie inne odpowiedzi tutaj pominięte to to, że nie każde urządzenie i oprogramowanie zdolne do połączenia HTTP będzie mogło używać SSL, dlatego zastanowiłbym się nad zapewnieniem użytkownikom sposobu, aby tego uniknąć, jeśli nie jest dla nich obsługiwany. Możliwe jest również, że osoby w niektórych krajach, w których technologia szyfrowania jest nielegalna, nie będą miały dostępu do Twojej witryny. Rozważę dodanie niezaszyfrowanej strony docelowej z linkiem, aby wymusić niezabezpieczoną wersję witryny, ale chyba że użytkownik specjalnie wybierze takie postępowanie, jak powiedziałeś, i po prostu przekaże je do wersji HTTPS.

Rzeczywistość
źródło
Problem z rozwiązaniami takimi jak zwykła strona docelowa HTTP, nawet jeśli jest odpowiednio oddzielona, ​​polega na tym, że strona ta jest otwarta na manipulację. Tj. Nie ma rzeczywistej gwarancji, że link do wersji HTTPS witryny zostanie dostarczony odwiedzającym w nienaruszonym stanie.
Håkan Lindqvist
3

Oto niektóre z szerokich problemów związanych z pociągnięciem pędzla:

  • MITM / SSLSTRIP : To ogromne zastrzeżenie. Jeśli chcesz wyświetlać swoją witrynę przez HTTPS, wyłącz HTTP na stronie . W przeciwnym razie pozostawiasz użytkowników otwartych na różne ataki typu man-in-the-middle, w tym SSLSTRIP, który przechwytuje żądania i po cichu obsługuje je przez HTTP, wstawiając własny skrypt złośliwego oprogramowania do strumienia. Jeśli użytkownik tego nie zauważy, pomyśli , że jego sesja jest bezpieczna, a tak naprawdę nie jest.

    • Problem polega jednak na tym, że jeśli Twoja witryna jest witryną publiczną i po prostu bezceremonialnie wyłączysz HTTP, możesz stracić wielu odwiedzających. To prawdopodobnie nie będzie nawet wystąpić do nich, aby spróbować HTTPS jeżeli strona nie załaduje z HTTP.
  • Jeśli witryna wymaga bezpiecznego logowania, należy zabezpieczyć całą sesję użytkownika. Nie uwierzytelniaj przez HTTPS, a następnie przekieruj użytkownika z powrotem do HTTP. Jeśli to zrobisz, ponownie narażasz użytkowników na ataki MITM. Standardowe podejście do uwierzytelniania w tych dniach polega na jednokrotnym uwierzytelnieniu, a następnie przekazaniu tokena uwierzytelniającego w obie strony (w pliku cookie). Ale jeśli uwierzytelniasz się przez HTTPS, a następnie przekierowujesz na HTTP, wówczas man-in-the-middle może przechwycić ten plik cookie i korzystać z witryny tak, jakby był uwierzytelnionym użytkownikiem, omijając Twoje bezpieczeństwo.

  • Problemy z wydajnością HTTPS są praktycznie ograniczone do uzgadniania związanego z tworzeniem nowego połączenia. Zrób, co możesz, aby zminimalizować potrzebę wielu połączeń HTTPS z adresu URL, a będziesz mil dalej. I to szczerze mówiąc, nawet jeśli udostępniasz swoje treści przez HTTP. Jeśli czytasz na SPDY, zdasz sobie sprawę, że wszystko, co robi, ma na celu dostarczenie całej zawartości z jednego adresu URL za pomocą jednego połączenia. Tak, użycie HTTPS wpływa na buforowanie. Ale w każdym razie, ile stron internetowych to po prostu statyczna zawartość, którą można buforować? Prawdopodobnie zyskasz więcej za grosze, używając buforowania na serwerze sieciowym, aby zminimalizować nadmiarowe zapytania do bazy danych, które nieustannie odtwarzają niezmienione dane i zapobiegają wykonywaniu kosztownych ścieżek kodu częściej niż to konieczne.

Craig
źródło
Rzeczą, którą możesz zrobić, aby rozwiązać adres sslstrip, jest użycie HSTS ( najlepiej, aby twoje ustawienia HSTS były wstępnie załadowane ). Niezależnie od tego, czy akceptujesz żądania za pośrednictwem zwykłego protokołu HTTP, czy nie, MITM może odpowiadać za pośrednictwem zwykłego protokołu HTTP (ewentualnie pośrednicząc w witrynie HTTPS), nawet jeśli akceptujesz tylko żądania HTTPS.
Håkan Lindqvist
@ HåkanLindqvist Naprawdę zasłużyłem na Twoją opinię? Czy udzieliłem złych porad lub dobrych porad dotyczących nie uwierzytelniania przez HTTPS, a następnie przejścia na HTTP przez resztę sesji? Czy udzieliłem złych rad dotyczących mitów dotyczących wydajności HTTPS? Ponadto, jeśli klient początkowo próbuje połączyć się przy użyciu HTTPS, MITM nie może przechwycić i odpowiedzieć bez wywołania alertu w przeglądarce, ponieważ jego certyfikat nie będzie pasował, chyba że ma skradziony lub sfałszowany certyfikat. Z drugiej strony, jeśli witryna akceptuje połączenie HTTP, przechwytywanie jest łatwiejsze. Tak czy inaczej HTTPS podnosi poprzeczkę.
Craig,
..i oczywiście z całego serca zgadzam się na używanie HSTS.
Craig,
Mój problem z odpowiedzią to pierwszy element na liście, który twierdzi, że adresuje sslstrip, podczas gdy tak naprawdę nie jest (mówiąc o mitach). W moim pierwszym komentarzu starałem się uzyskać, że jeśli masz aktywny MITM (który jest przede wszystkim potrzebny do sslstrip), osoba atakująca może być zasadniczo „witryną” z perspektywy klienta; to atakujący decyduje, czy chce zaakceptować zwykłe połączenia HTTP od klienta, a sposób, w jaki zachowuje się twój rzeczywisty serwer sieciowy, nie wpływa na to, co atakujący może zrobić.
Håkan Lindqvist
@ HåkanLindqvist Tyle, że jeśli gość celowo próbuje połączyć się z HTTPS, osoba atakująca nie może spełnić tego żądania bez rzucania flag w przeglądarce, chyba że udało mu się ukraść certyfikat serwera lub w jakiś sposób skutecznie go sfałszować, który musiałby zrobić, aby przełączyć połączenie na HTTP. HTTPS wciąż podnosi poprzeczkę. Oczywiście, jeśli użytkownik podejmie pierwszą próbę połączenia przez HTTP, wszystkie zakłady są całkowicie wyłączone.
Craig,
1

Technicznie nie jest to odpowiedź na twoje pierwotne pytanie, ale jeśli używasz rozszerzenia Google Chrome HTTPS Gdziekolwiek (jestem pewien, że istnieją podobne rozszerzenia w innych przeglądarkach), rozszerzenie automatycznie przekierowuje strony z HTTP do tej samej strony z HTTPS. Używam go przez jakiś czas i nie miałem żadnych problemów (może poza spowolnieniem, ale tego nie testowałem). HTTPS: Wszędzie można zmienić niektóre reguły po stronie serwera, ale ponieważ nie zrobiłem wiele w tym obszarze, nie jestem pewien dokładnych szczegółów.

Wracając do twojego rzeczywistego pytania, jeśli używasz czegoś takiego jak HTTPS, gdziekolwiek indziej, jest jeszcze mniej motywacji do korzystania tylko z HTTP, chociaż wyobrażam sobie, że trudno jest ustawić prawidłowe reguły, kiedy będziesz ich potrzebować.

trysis
źródło
1

jedyną techniczną wadą HTTPS przez HTTP jest to, że przetwarzanie żądań HTTPS jest obliczeniowo droższe niż zwykły HTTP

Jednak biorąc pod uwagę, że większość współczesnych serwerów ma procesory o dużej mocy, wpływ ten jest zwykle nieistotny, chyba że masz bardzo wysoki poziom ruchu, w którym to momencie bardziej niż prawdopodobne jest użycie równoważenia obciążenia

Wraz z pojawieniem się protokołów takich jak SPDY, które wymagają do działania protokołu SSL / TLS, w rzeczywistości przeciwdziała to wspomnianemu narzutowi obliczeniowemu, zapewniając znaczną poprawę wydajności w odniesieniu do wielu żądań i ogólnie szybsze przekazywanie zasobów do klienta.

anthonysomerset
źródło
Problem z wydajnością HTTPS polega na tym, że ustanowienie nowego połączenia jest droższe, ponieważ wiąże się to z większą liczbą podróży w obie strony i ponieważ asymetryczne szyfrowanie / deszyfrowanie jest znacznie droższe niż symetryczne szyfrowanie / deszyfrowanie. Gdy uzgadnianie połączenia ustanowi współdzielony symetryczny klucz szyfrowania, bieżący narzut jest praktycznie nieistotny (bardzo mały). Jeśli przeczytasz na temat SPDY, zobaczysz, że celem wszystkich tych wymyślnych rzeczy jest zasadniczo dostarczanie całej zawartości z adresu URL za pośrednictwem jednego połączenia, co zmniejsza obciążenie związane z uzgadnianiem połączenia.
Craig
1

Przekierowanie na https jest bardzo dobre, ale czytam, że zależy to również od tego, jak zorganizujesz przekierowanie.

Stworzenie dedykowanego wirtualnego serwera do przekierowywania przychodzących żądań HTTP do połączenia https, jak sugeruje odpowiedź na security.stackexchange.com, brzmi bardzo inteligentnie i zamknie niektóre dodatkowe zagrożenia bezpieczeństwa. Konfiguracja w Apache wyglądałaby mniej więcej tak:

# Virtual host for rerouting
<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent / https://www.example.com/
</VirtualHost>

# Virtual host for secure hosting on https
<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    Header set Strict-Transport-Security "max-age=8640000;includeSubdomains"

    ...site settings...

</VirtualHost>
Więdnąć
źródło