Jak przekierować HTTPS na HTTP?

166

Jak przekierowujesz HTTPS na HTTP? Oznacza to, że jest przeciwieństwem tego, czego (pozornie) wszyscy uczą.

Mam serwer na HTTPS, za który zapłaciłem certyfikat SSL i serwer lustrzany, za który nie mam i trzymam się w pobliżu tylko w sytuacjach awaryjnych, więc nie zasługuje na uzyskanie certyfikatu.

Na komputerach mojego klienta mam NIEKTÓRE skróty, które wskazują na http://production_serveri https://production_server(oba działają). Wiem jednak, że jeśli mój serwer produkcyjny ulegnie awarii, włącza się przekierowanie DNS i klienci, którzy mają „https” w swoim skrócie, będą się gapić https://mirror_server(co nie działa) i duży, gruby czerwony ekran Internet Explorera 7 z niepokojem dla mojej firmy.

Niestety nie mogę po prostu zmienić tego na poziomie klienta. Ci użytkownicy są niepiśmienni na komputerach: i jest bardzo prawdopodobne, że wystraszy się, widząc błędy związane z "brakiem bezpieczeństwa" HTTPS (szczególnie sposób, w jaki Firefox 3 i Internet Explorer 7 radzą sobie z tym obecnie: FULL STOP, na szczęście, ale nie pomaga mi tutaj LOL).

Jest to bardzo łatwe do znalezienia rozwiązania Apache na protokole HTTP> https przekierowanie , ale dla życia mnie nie mogę zrobić odwrotnie.

Pomysły?

mauriciopastrana
źródło
2
Nie rób tego ! Przekierowania HTTPS z HTTP są niezwykle niebezpieczne (i w rzeczywistości zostaną wkrótce zablokowane przez wszystkie przeglądarki z powodu nadużyć), szczególnie jeśli jest to węzeł za pośrednictwem cichego statusu HTTP (ale to samo jest prawdą, jeśli jest to wykonywane przez javascript), chyba że: - (1) istnieje przejściowa strona parkingowa HTTPS, która zaprasza użytkowników do przepłynięcia łącza przez aktywne kliknięcie; lub: - (2) HTTPS przekierowuje do HTTP dokładnie w TEJ SAMEJ domenie ORAZ przekierowania nie zmieniają żądanego typu treści. Zezwolenie na to w przeglądarkach pozwoliło wielu złośliwym programom przejść izolację. Takie przekierowania są bardzo zwodnicze.
verdy_p
4
Wygląda to na wewnętrzną stronę, na której OP wie, co się z nią dzieje, a zatem nie jest niebezpieczny ... Gdyby to był serwer internetowy, zgodziłbym się z tobą, ale wewnętrzny, tylko lokalny serwer sieciowy, przekierowanie ta moda nie byłaby problemem.
Stese
@verdy_p Pracuję nad przekierowaniami HTTPS do HTTP 302, w przypadku portali przechwytujących. Czy możesz wskazać mi dokumentację, do której się odnosisz?
jprusakova
W przypadku portalu przechwytującego nigdy nie wykonuj przekierowania HTTPS do HTTP 302, chyba że jest to dokładnie ta sama domena (nawet nie subdomena). A ponieważ istnieje wysokie ryzyko ujawnienia informacji, uważaj na tokeny sesji i pliki cookie przekazywane w sposób przejrzysty wraz z przekierowaniem! Powinieneś wiedzieć, że cele HTTP mogą być modyfikowane, a informacje pobierane przez przezroczyste proxy dla złośliwego oprogramowania, a nawet przez złośliwy DNS: Twój klient może nawet nie wiedzieć, że twój cel HTTP będzie nieosiągalny i faktycznie trafi w szał! Dlatego nigdy nie rób tego na linkach HTTPS, które zawierają prywatną sesję / pliki cookie / żądania.
verdy_p,
Takie przekierowanie HTTPS 302 jest zawsze luką bezpieczeństwa w Twojej witrynie HTTPS. Ogromnym ryzykiem jest kradzież sesji, a uwierzytelnionym użytkownikom zbieranie ich prywatnych kont. W każdym razie NIGDY nie rób takich przekierowań w celu załadowania skryptów JavaScript lub aktywnych multimediów: to otwarte drzwi w dziedzinie „piaskownicy” HTTPS. Naprawdę rozważ zrobienie czegoś odwrotnego: przekierowanie HTTP do HTTPS (w szczególności do głównego portalu lub statycznych stron publicznych, które nie potrzebują prywatnych danych / sesji / plików cookie) i używaj HTTPS do everelse. Jeśli kiedykolwiek będziesz musiał przejść z HTTPS na HTTP, użyj standardowych linków (w różnych żądaniach)
verdy_p

Odpowiedzi:

128

Nie zostało to przetestowane, ale myślę, że powinno to działać przy użyciu mod_rewrite

RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}
ejunker
źródło
1
Jak to działa (co muszę zmienić z tego kodu w mojej domenie, aby ten kod działał)?
Enve
1
Enve: Po prostu dodaj do konfiguracji vhost_ssl.conf swojej witryny (lub .htaccess w katalogu głównym witryny). Nic nie trzeba zmieniać, będzie dynamicznie używać tej samej nazwy hosta i ścieżki URL.
Darren Felton
1
Myślę, że możesz również chcieć złapać ciągi zapytań. Nie jestem pewien, ale myślę, że powyższy fragment kodu nie przekaże ciągów zapytań z https do http.
Rustavore
12
Jak wskazał Kieron poniżej, to nie zadziała, jeśli serwer lustrzany nie ma ważnego certyfikatu. Nadal zobaczysz duże czerwone ostrzeżenie z powodu nieważnego certyfikatu. Kiedy zaczniesz używać https, po prostu utkniesz z nim. Bądź gotów za to zapłacić przez resztę swojego życia. Jeśli przestaniesz płacić, osoby, które dodały linki https do zakładek, nie będą mogły przejść.
Stephen Cheng
2
Płacisz za resztę swojego życia? Nadal możesz używać HTTPS, ale zmień dostawcę PKI i uzyskaj nowe tańsze certyfikaty. Nadal zapłacisz kilka dolców tak, ale to samo dotyczy nazwy domeny i hostingu! Certyfikat PKI NIE jest teraz drogi w porównaniu z nazwami domen i jest nieistotny w porównaniu z kosztami hostingu / przepustowości!
verdy_p
71

Pamiętaj, że silnik Rewrite uruchamia się dopiero po odebraniu żądania HTTP - co oznacza, że ​​nadal będziesz potrzebować certyfikatu, aby klient mógł skonfigurować połączenie i wysłać żądanie!

Jeśli jednak okaże się, że maszyna zapasowa ma tę samą nazwę hosta (jeśli chodzi o klienta), nie powinno być powodu, dla którego nie można używać tego samego certyfikatu, co główna maszyna produkcyjna.

Kieron
źródło
1
Jak można pokonać to ograniczenie? Mam ten sam problem. pobieranie z przeglądarki błędu certifcate przed przekierowaniem.
Sandeep Balagopal
Byłoby miło mieć przekierowanie z powrotem do HTTP, jeśli wystąpi błąd certyfikatu
Jeffrey the Giraffe
To całkowicie
przeczy
12

Opierając się na odpowiedzi ejunkera, jest to rozwiązanie działające dla mnie nie na pojedynczym serwerze, ale w środowisku chmurowym

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{ENV:HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
antoniom
źródło
Używanie 301 może być mało niebezpieczne. 301 oznacza trwale usunięte i myślę, że przejście z https na http jest tymczasowe. Zobacz tę zaakceptowaną odpowiedź, aby dowiedzieć się, jakie wady będą dla użytkowników stackoverflow.com/questions/1393280/ ...
yusuf tezel
Rozróżnienie 301/302 stałe / tymczasowe dotyczy tylko wyszukiwarek.
matthewv789
9

Dla tych, którzy używają .confpliku.

<VirtualHost *:443>
    ServerName domain.com
    RewriteEngine On
    RewriteCond %{HTTPS} on
    RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/domain.crt
    SSLCertificateKeyFile /etc/apache2/ssl/domain.key
    SSLCACertificateFile /etc/apache2/ssl/domain.crt

</VirtualHost>
Stóg
źródło
8

Jeśli żadne z powyższych rozwiązań nie działa dla Ciebie (nie dla mnie), oto co zadziałało na moim serwerze:

RewriteCond %{HTTPS} =on
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1 [L,R=301]
rg88
źródło
6
Często nie chcesz L,(co oznacza „Ostatnia reguła”). Jeśli korzystasz z wordpress lub innego CMS, Lflaga może uniemożliwić prawidłowe kierowanie żądania strony. Zamiast tego użyj:RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1 [R=301]
Rustavore
5

wszystkie powyższe nie działały, gdy korzystałem z Cloudflare, ten działał dla mnie:

RewriteCond %{HTTP:X-Forwarded-Proto} =https
RewriteRule ^(.*)$ http://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

a ten zdecydowanie działa bez proxy na drodze:

RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
mikulabc
źródło
3

Lepiej unikać korzystania z mod_rewrite, kiedy tylko możesz.

W twoim przypadku zastąpiłbym Rewrite tym:

    <If "%{HTTPS} == 'on'" >
            Redirect permanent / http://production_server/
    </If>

<If>Dyrektywa jest dostępny tylko w wersji 2.4+, jak na tym blogu tutaj .

sys0dm1n
źródło
W środowisku hostowanym wersję Apache można sprawdzić za pomocą/usr/sbin/httpd -v
Serge Stroobandt
1

to działa dla mnie.

<VirtualHost *:443>
    ServerName www.example.com
    # ... SSL configuration goes here
    Redirect "https://www.example.com/" "http://www.example.com/"
</VirtualHost>

<VirtualHost *:80>
    ServerName www.example.com
    # ... 
</VirtualHost>

pamiętaj, aby słuchać obu portów 80 i 443.

jaxarroyo
źródło
0

Żadna z odpowiedzi nie działa dla mnie na stronie Wordpress, ale poniższe działa (jest podobna do innych odpowiedzi, ale ma małą zmianę)

RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Yuseferi
źródło
Nie używaj takich reguł na ślepo ze wszystkimi REQUEST_URI (nie należy tego używać, jeśli w identyfikatorze URI znajdują się jakiekolwiek dane formularza lub identyfikatory plików cookie / sesji w metadanych żądania). Używaj go tylko dla statycznych publicznych stron / obrazów. Unikaj tego całkowicie w przypadku skryptów JavaScript lub aktywnych składników (w szczególności strumieni wideo z możliwością skryptowania lub aktywnych plików PDF, chyba że są one podpisane cyfrowo przez Ciebie! Nadal nie jest możliwe cyfrowe podpisywanie skryptów JavaScript, przechowywanie ich tylko w bezpiecznej domenie).
verdy_p,
Uwaga: niektóre formaty obrazów są aktywne i można je obsługiwać skryptami: na przykład strzeż się formatu SVG. Widzieliśmy ataki na niektóre witryny HTTPS ładujące obrazy SVG z HTTP (z przekierowaniami 302 witryny) i zbierane przez złośliwe oprogramowanie wstawiające skrypty do zawartości SVG ... Idealnie przeglądarki powinny izolować podkategorie HTTP od HTTPS i umieszczać je w piaskownicy (więc CORS ograniczenia bezpieczeństwa również powinny obowiązywać, nawet jeśli znajduje się w tej samej nazwie domeny ...), więc „http: // (domena) / ...” i „https: // (domena) /” należy traktować jako odrębne domeny dla CORS (nie to samo źródło), nawet jeśli znajdują się na tym samym numerze portu TCP.
verdy_p
@verdy_p, co dokładnie masz na myśli mówiąc „z przekierowaniami 302 witryny”? Musisz najpierw być właścicielem witryny serwerowej (lub węzłów uczestniczących na poziomie TCP / IP, takich jak serwery DNS, routery), aby wykorzystać te żądania zasobów HTTP, prawda?
Sz.
Niekoniecznie. HTTPS w domenie będzie bezpieczny, podczas gdy HTTP w tej samej domenie nie będzie (exploity nie wymagają kontrolowania adresu IP, routerów lub serwerów DNS nawet przy użyciu DNSSEC; exploity mogą po prostu używać spoofingu IP, którego nie można bezpiecznie wykryć bez HTTPS na bezpieczne sesje). Dlatego uważam, że witryna HTTPS musi hostować obrazy (nawet w tej samej domenie), nie udostępniając ich za pomocą protokołu HTTP (jest to nawet domyślnie zabronione w niektórych przeglądarkach, które wymagają kliknięcia aktywacyjnego lub maskują te niebezpieczne obrazy). Mieszane HTTPS / HTTP muszą zostać zbanowane: witryna może być atakowana na jej częściach HTTP (np. Piksele śledzenia).
verdy_p
-6

O ile wiem, proste odświeżanie meta działa również bez powodowania błędów:

<meta http-equiv="refresh" content="0;URL='http://www.yourdomain.com/path'">
RobinUS2
źródło
12
Chciałbym, żeby wyborcy negatywni byli zobowiązani do pozostawienia komentarzy wyjaśniających powody odrzucenia głosów. Osobiście nie wybrałbym tej odpowiedzi, chyba że jako programista nie miałbyś dostępu do serwera, dla którego tworzyłeś, ale miałeś dostęp do strony. Jednym z problemów jest to, że musisz zakodować na stałe każdą ścieżkę na każdej stronie, aby to zadziałało. Jeśli możesz założyć, że JavaScript jest włączony w ważnych przypadkach, lepiej byłoby użyć JavaScript do zmiany na http. Powyższe odpowiedzi są lepsze, ponieważ nie wymagają javascript, ponieważ występują na serwerze.
Rustavore
2
Po prostu: ponieważ htaccess jest znacznie lepszą opcją niż to. Ponadto nie rozwiązuje problemu przekierowania protokołu https na http, jeśli nie masz certyfikatu.
midudev
1
Akcja powinna zostać przetworzona przez serwer, a nie dokument, który może służyć.
albal