Come reindirizzare HTTPS su HTTP?


166

Come reindirizzare HTTPS su HTTP ?. Cioè, l'opposto di ciò che (apparentemente) tutti insegnano.

Ho un server su HTTPS per il quale ho pagato una certificazione SSL e un mirror per il quale non ho e tengo in giro solo per le emergenze, quindi non vale la pena ottenere una certificazione.

Sul desktop del mio cliente ho ALCUNE scorciatoie che indicano http://production_servere https://production_server(entrambi funzionano). Tuttavia, so che se il mio server di produzione si interrompe, l'inoltro DNS si avvia e quei client che hanno "https" sul loro collegamento staranno fissando https://mirror_server(che non funziona) e una grande schermata rossa di disagio di Internet Explorer 7 per la mia compagnia.

Sfortunatamente, non posso semplicemente cambiarlo a livello di client. Questi utenti sono molto analfabeti di computer: e molto probabilmente impazziranno nel vedere errori di "insicurezza" HTTPS (specialmente il modo in cui Firefox 3 e Internet Explorer 7 lo gestiscono al giorno d'oggi: FULL STOP, per fortuna, ma non mi aiuta qui LOL).

È molto facile trovare le soluzioni Apache per il reindirizzamento http-> https , ma per la mia vita non posso fare il contrario.

Idee?


2
Non farlo ! I reindirizzamenti HTTPS da HTTP sono estremamente pericolosi (e in effetti saranno presto bloccati da tutti i browser a causa di abusi), soprattutto se questo è nodo tramite stato HTTP silenzioso (ma lo stesso vale se questo è fatto da JavaScript), a meno che: - (1) c'è una pagina di parcheggio HTTPS temporanea che invita gli utenti a svuotare un collegamento facendo clic su di esso; oppure: - (2) HTTPS reindirizza su HTTP esattamente sul dominio SAME E i reindirizzamenti non modificano il tipo di contenuto richiesto. Consentirlo nei browser ha permesso a molti malware di passare l'isolamento. Tali reindirizzamenti sono molto ingannevoli.
verdy_p

4
Sembra un sito interno, dove l'OP sa cosa sta succedendo, e quindi non pericoloso ... Se si trattasse di un server Web, sarei d'accordo con te, ma un server web interno e locale, un reindirizzamento in questa moda non sarebbe un problema.
Stese,

@verdy_p Sto lavorando su reindirizzamenti da HTTPS a HTTP 302, il caso dei portali captive. Potete indicarmi la documentazione a cui vi riferite?
jprusakova,

Per il tuo portale captive, non eseguire mai alcun reindirizzamento da HTTPS a HTTP 302, tranne se si tratta esattamente dello stesso dominio (nemmeno un sottodominio). E poiché esiste un alto rischio di divulgazione di informazioni, fai attenzione ai token di sessione e ai cookie trasmessi in modo trasparente con il reindirizzamento! Dovresti sapere che i target HTTP possono essere modificati e le informazioni acquisite da proxy trasparenti di malware e persino da DNS dannoso: il tuo custoer potrebbe anche non sapere che il tuo target solo HTTP sarà irraggiungibile e andrà effettivamente in blackhat! Quindi non farlo mai sui collegamenti HTTPS che contengono sessioni / cookie / richieste private.
verdy_p,

Tali reindirizzamenti HTTPS 302 sono sempre falle di sicurezza nel tuo sito HTTPS. L'enorme rischio è che vengano rubate le sessioni e che i tuoi utenti autenticati abbiano i loro account privati ​​raccolti. E in ogni caso, MAI effettuare reindirizzamenti per caricare javascript o multimedia attivi: questa è una porta aperta nel regno "sandbox" di HTTPS. Prendi davvero in considerazione l'idea di fare qualcosa al contrario: reindirizza HTTP a HTTPS (in particolare il tuo portale principale o pagine pubbliche statiche che non richiedono dati / sessioni / cookie privati) e usa HTTPS per sempre. Se hai mai bisogno di passare da HTTPS a HTTP, usa i collegamenti standard (in richieste distinte)
verdy_p

Risposte:


128

Questo non è stato testato ma penso che dovrebbe funzionare usando mod_rewrite

RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}

1
Come faccio a farlo funzionare (cosa devo cambiare da questo codice al mio dominio per far funzionare questo codice)?
Enve,

1
Enve: basta aggiungere alla configurazione vhost_ssl.conf del tuo sito (o .htaccess alla radice del sito). Non è necessario modificare nulla, utilizzerà in modo dinamico lo stesso nome host e lo stesso percorso URL.
Darren Felton,

1
Penso che potresti voler catturare anche stringhe di query. Non sono sicuro, ma penso che lo snippet sopra riportato non inoltri le stringhe di query da HTTPS a http.
Rustavore,

12
Come indicato da Kieron di seguito, questo non funzionerebbe se il server mirror non ha un certificato valido. Verrà comunque visualizzato un grande avviso rosso a causa del certificato non valido. Una volta che inizi a usare https, sei praticamente bloccato con esso. Preparati a pagare per tutto il resto della tua vita. Se smetti di pagare, le persone che hanno aggiunto i segnalibri ai collegamenti https non saranno in grado di trovare.
Stephen Cheng,

2
Pagare per il resto della tua vita? È ancora possibile utilizzare HTTPS ma modificare il provider PKI e ottenere nuovi certificati più economici. Pagherai ancora qualche soldo sì, ma lo stesso vale per il tuo nome di dominio e il tuo hosting! Un certificato PKI ora NON è costoso rispetto ai nomi di dominio ed è insignificante rispetto ai costi di hosting / larghezza di banda!
verdy_p,

71

Tieni presente che il motore Rewrite si attiva solo dopo aver ricevuto la richiesta HTTP, il che significa che avresti ancora bisogno di un certificato, affinché il client possa impostare la connessione per inviare la richiesta!

Tuttavia, se la macchina di backup sembrerà avere lo stesso nome host (per quanto riguarda il client), non ci dovrebbero essere motivi per cui non è possibile utilizzare lo stesso certificato della macchina di produzione principale.


1
Come si può superare questa limitazione? Sto avendo lo stesso problema. ottenere l'errore certifcate dal browser prima del reindirizzamento.
Sandeep Balagopal,

Sarebbe bello avere un reindirizzamento su HTTP se si verifica un errore del certificato
Jeffrey the Giraffe

Ciò sconfigge completamente lo scopo di avere HTTPS in primo luogo
FluffyBeing

12

Basato sulla risposta di ejunker, questa è la soluzione che funziona per me, non su un singolo server ma su un ambiente cloud

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{ENV:HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

L'uso di 301 può essere poco pericoloso. 301 significa che è stato permanentemente rimosso e immagino che passare da https a http sia temporaneamente. Vedere questa risposta accettata per quello che gli svantaggi saranno per gli utenti stackoverflow.com/questions/1393280/...
Yusuf Tezel

La distinzione permanente / temporanea 301/302 è rilevante solo per i motori di ricerca.
matthewv789,

9

Per quelli che stanno usando un .conffile.

<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>

8

Se nessuna delle soluzioni di cui sopra funziona per te (non hanno funzionato per me) ecco cosa ha funzionato sul mio server:

RewriteCond %{HTTPS} =on
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1 [L,R=301]

6
Spesso, non vorrai il L,(che significa "Ultima regola"). Se si utilizza wordpress o un altro CMS, il Lflag potrebbe impedire il corretto routing della richiesta di pagina. Invece usa:RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1 [R=301]
Rustavore

5

tutto quanto sopra non ha funzionato quando ho usato cloudflare, questo ha funzionato per me:

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

e questo sicuramente funziona senza proxy in questo modo:

RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

3

È meglio evitare di utilizzare mod_rewrite quando è possibile.

Nel tuo caso, sostituirei Riscrivi con questo:

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

La <If>direttiva è disponibile solo in Apache 2.4+ come da questo blog qui .


In un ambiente hosted, si può controllare la versione di Apache usando/usr/sbin/httpd -v
Serge Stroobandt

1

questo funziona per me.

<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>

assicurarsi di ascoltare entrambe le porte 80 e 443.


0

Nessuna delle risposte funziona per me sul sito Web di Wordpress ma le seguenti funzionano (è simile ad altre risposte ma hanno un piccolo cambiamento)

RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Non utilizzare tali regole alla cieca con tutti i REQUEST_URI (questo non dovrebbe essere usato se ci sono dati del modulo nell'URI o ID cookie / sessioni nei metadati della richiesta). Usalo solo per pagine / immagini pubbliche statiche. Evitatelo completamente per javascript o componenti attivi (in particolare flussi video di cui è possibile lo script o PDF attivi a meno che non siano firmati digitalmente da voi! Non è ancora possibile firmare digitalmente javascript, tenerli solo nel vostro dominio sicuro).
verdy_p,

Nota: alcuni formati di immagine sono attivi e gestibili da script: ad esempio, fai attenzione a SVG. Abbiamo visto attacchi su alcuni siti Web HTTPS che caricano immagini SVG da HTTP (con i reindirizzamenti 302 del sito) e raccolti da malware che inseriscono script nei contenuti SVG ... Idealmente i browser dovrebbero isolare i contenuti secondari HTTP da HTTPS e metterli in una sandbox (quindi CORS si dovrebbero applicare anche restrizioni di sicurezza, anche se si trova nello stesso nome di dominio ...), pertanto "http: // (dominio) / ..." e "https: // (dominio) /" devono essere considerati domini distinti per CORS (non della stessa origine) anche se si trovano sullo stesso numero di porta TCP.
verdy_p,

@verdy_p, cosa intendi esattamente con "con i reindirizzamenti 302 del sito"? Devi prima possedere il sito del server (o nodi partecipanti a livello TCP / IP, come server DNS, router), per sfruttare quelle richieste di risorse HTTP, giusto?
Sz.

Non necessariamente. L'HTTPS su un dominio sarà sicuro mentre l'HTTP sullo stesso dominio non lo sarà (gli exploit non richiedono il controllo di un IP o router o server DNS anche quando si utilizza DNSSEC; gli exploit possono semplicemente usare lo spoofing IP, che non può essere rilevato in modo sicuro senza HTTPS su sessioni sicure). Quindi sostengo che un sito HTTPS deve ospitare immagini (anche sullo stesso dominio) non servendole con HTTP (è addirittura negato per impostazione predefinita in alcuni browser che richiedono un clic di attivazione o mascherano quelle immagini non sicure). HTTPS / HTTP misti devono essere vietati: il sito è attaccabile dalle sue parti HTTP (ad es. Pixel di traccia).
verdy_p

-6

Per quanto ne so di un semplice meta refresh funziona anche senza causare errori:

<meta http-equiv="refresh" content="0;URL='http://www.yourdomain.com/path'">

12
Vorrei che ai votanti in ribasso fosse richiesto di lasciare commenti che spiegassero i motivi dei voti negativi. Personalmente, non sceglierei questa risposta se non come sviluppatore non avessi accesso al server per il quale stavi sviluppando ma non avessi accesso alla pagina. Un problema è che dovrai far decodificare ogni percorso su ogni pagina per farlo funzionare. Se puoi supporre che JavaScript sia abilitato per i tuoi casi d'uso importanti, sarebbe meglio usare JavaScript per passare a http. Le risposte di cui sopra sono migliori perché non richiedono JavaScript poiché si verificano sul server.
Rustavore,

2
Semplicemente: perché htaccess è un'opzione di gran lunga migliore di quella. Inoltre, non risolverà il problema per reindirizzare il protocollo https su http se non si dispone di un certificato.
midudev,

1
L'azione dovrebbe essere elaborata dal server, non da un "documento" che può essere pubblicato.
albal
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.