Comment redirigez-vous HTTPS vers HTTP?

166

Comment redirigez-vous HTTPS vers HTTP?. Autrement dit, le contraire de ce que tout le monde enseigne (apparemment).

J'ai un serveur sur HTTPS pour lequel j'ai payé une certification SSL et un miroir pour lequel je n'ai pas et que je garde juste pour les urgences, donc cela ne mérite pas d'obtenir une certification.

Sur les bureaux de mon client, j'ai QUELQUES raccourcis qui pointent vers http://production_serveret https://production_server(les deux fonctionnent). Cependant, je sais que si mon serveur de production tombe en panne, le transfert DNS entre en jeu et les clients qui ont "https" sur leur raccourci regarderont https://mirror_server(ce qui ne fonctionne pas) et un gros écran rouge de malaise d'Internet Explorer 7 pour mon entreprise.

Malheureusement, je ne peux pas simplement changer cela au niveau du client. Ces utilisateurs sont très analphabètes en informatique: et sont très susceptibles de paniquer en voyant des erreurs "d'insécurité" HTTPS (en particulier la façon dont Firefox 3 et Internet Explorer 7 le gèrent de nos jours: FULL STOP, heureusement, mais ne m'aide pas ici LOL).

Il est très facile de trouver des solutions Apache pour la redirection http-> https , mais pour la vie de moi, je ne peux pas faire le contraire.

Des idées?

Mauriciopastrana
la source
2
Ne faites pas cela ! Les redirections HTTPS à partir de HTTP sont extrêmement dangereuses (et en fait seront bientôt bloquées par tous les navigateurs en raison d'abus), surtout s'il s'agit d'un nœud via un statut HTTP silencieux (mais il en va de même si cela est fait par javascript), sauf si: - (1) il existe une page de stationnement HTTPS transitoire invitant les utilisateurs à afficher un lien en cliquant dessus activement; ou: - (2) le HTTPS redirige vers HTTP sur exactement le même domaine ET les redirections ne modifient pas le type de contenu demandé. L'autoriser dans les navigateurs a permis à de nombreux malwares de passer l'isolement. De telles redirections sont très trompeuses.
verdy_p
4
Cela ressemble à un site interne, où l'OP sait ce qui se passe, et donc pas dangereux ... S'il s'agissait d'un serveur Web, je serais d'accord avec vous, mais un serveur Web interne, uniquement local, une redirection vers cette mode ne serait pas un problème.
Stese
@verdy_p Je travaille sur des redirections HTTPS vers HTTP 302, le cas des portails captifs. Pouvez-vous m'indiquer la documentation dont vous parlez?
jprusakova
Pour votre portail captif, n'effectuez jamais de redirection HTTPS vers HTTP 302, sauf s'il s'agit exactement du même domaine (pas même d'un sous-domaine). Et comme il existe un risque élevé de divulgation d'informations, méfiez-vous des jetons de session et des cookies transmis de manière transparente avec la redirection! Vous devez savoir que les cibles HTTP peuvent être modifiées et les informations prises par des proxys transparents de logiciels malveillants et même par des DNS malveillants: votre client peut même ne pas savoir que votre cible HTTP uniquement sera inaccessible et ira en fait vers un blackhat! Ne faites donc jamais cela sur les liens HTTPS contenant des sessions / cookies / requêtes privées.
verdy_p
Une telle redirection HTTPS 302 est toujours une faille de sécurité dans votre site HTTPS. Le risque énorme est d'avoir des sessions volées et vos utilisateurs authentifiés ont leurs comptes privés récoltés. Et dans tous les cas, NE JAMAIS faire de telles redirections pour charger des javascripts, ou du multimédia actif: c'est une porte ouverte dans le domaine HTTPS "sandbox". Pensez vraiment à faire quelque chose d'inverse: redirigez HTTP vers HTTPS (notamment votre portail principal ou des pages publiques statiques qui n'ont pas besoin de données / sessions / cookies privés) et utilisez HTTPS pour toujours. Si jamais vous avez besoin de passer de HTTPS à HTTP, utilisez des liens standard (dans des requêtes distinctes)
verdy_p

Réponses:

128

Cela n'a pas été testé mais je pense que cela devrait fonctionner avec mod_rewrite

RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}
ejunker
la source
1
Comment le faire fonctionner (que dois-je changer de ce code à mon domaine pour que ce code fonctionne)?
Enve le
1
Enve: Il suffit d'ajouter à la configuration vhost_ssl.conf de votre site (ou .htaccess à la racine du site). Rien ne doit être changé, il utilisera dynamiquement le même nom d'hôte et le même chemin d'URL.
Darren Felton
1
Je pense que vous voudrez peut-être également attraper les chaînes de requête. Je ne suis pas sûr, mais je pense que l'extrait de code ci-dessus ne transmettra pas les chaînes de requête de https à http.
Rustavore
12
Comme indiqué par Kieron ci-dessous, cela ne fonctionnerait pas si le serveur miroir n'a pas de certificat valide. Vous verriez toujours un gros avertissement rouge en raison d'un certificat invalide. Une fois que vous commencez à utiliser https, vous êtes fondamentalement coincé avec lui. Soyez prêt à payer pour le reste de votre vie. Si vous arrêtez de payer, les personnes qui ont ajouté les liens https ne pourront pas passer.
Stephen Cheng
2
Payer pour le reste de votre vie? Vous pouvez toujours utiliser HTTPS mais changer votre fournisseur PKI et obtenir de nouveaux certificats moins chers. Vous paierez toujours quelques dollars oui, mais il en va de même pour votre nom de domaine et votre hébergement! Un certificat PKI n'est désormais PAS cher par rapport aux noms de domaine, et est insignifiant par rapport aux coûts d'hébergement / de bande passante!
verdy_p
71

Gardez à l'esprit que le moteur de réécriture ne démarre qu'une fois la requête HTTP reçue - ce qui signifie que vous auriez toujours besoin d'un certificat, pour que le client configure la connexion pour envoyer la requête!

Cependant, si la machine de sauvegarde semble avoir le même nom d'hôte (en ce qui concerne le client), il ne devrait y avoir aucune raison pour laquelle vous ne pouvez pas utiliser le même certificat que la machine de production principale.

Kieron
la source
1
Comment surmonter cette limitation? J'ai le même problème. obtenir l'erreur de certificat du navigateur avant la redirection.
Sandeep Balagopal
Ce serait bien d'avoir une redirection vers HTTP s'il y a une erreur de certificat
Jeffrey the Giraffe
Cela va complètement à l'
encontre de
12

Sur la base de la réponse d'ejunker, c'est la solution qui fonctionne pour moi, pas sur un seul serveur mais sur un environnement cloud

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{ENV:HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Antoniom
la source
Utiliser 301 peut être peu dangereux. 301 signifie définitivement supprimé et je suppose que passer de https à http est temporaire. Voir cette réponse acceptée pour ce que les inconvénients seront pour les utilisateurs stackoverflow.com/questions/1393280/…
yusuf tezel
La distinction 301/302 permanent / temporaire ne concerne que les moteurs de recherche.
matthewv789
9

Pour ceux qui utilisent un .conffichier.

<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>
Meule
la source
8

Si aucune des solutions ci-dessus ne fonctionne pour vous (ce n'est pas le cas pour moi), voici ce qui a fonctionné sur mon serveur:

RewriteCond %{HTTPS} =on
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1 [L,R=301]
rg88
la source
6
Souvent, vous ne voudrez pas du L,(qui signifie "Dernière règle"). Si vous utilisez wordpress ou un autre CMS, l' Lindicateur peut empêcher la demande de page d'être correctement acheminée. À la place, utilisez:RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1 [R=301]
Rustavore
5

tout ce qui précède n'a pas fonctionné lorsque j'ai utilisé cloudflare, celui-ci a fonctionné pour moi:

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

et celui-ci fonctionne définitivement sans proxy de la manière:

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

Il vaut mieux éviter d'utiliser mod_rewrite lorsque vous le pouvez.

Dans votre cas, je remplacerais la réécriture par ceci:

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

La <If>directive n'est disponible que dans Apache 2.4+ selon ce blog ici .

sys0dm1n
la source
Dans un environnement hébergé, on peut vérifier la version d'Apache en utilisant/usr/sbin/httpd -v
Serge Stroobandt
1

cela fonctionne pour moi.

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

assurez-vous d'écouter les deux ports 80 et 443.

Jaxarroyo
la source
0

Aucune des réponses ne fonctionne pour moi sur le site Web Wordpress mais les travaux suivants (c'est similaire à d'autres réponses mais ont un petit changement)

RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Yuseferi
la source
N'utilisez pas de telles règles à l'aveuglette avec tous les REQUEST_URI (cela ne doit pas être utilisé s'il y a des données de formulaire dans l'URI ou des ID de cookies / sessions dans les métadonnées de la demande). Utilisez-le uniquement pour les pages / images publiques statiques. Évitez-le complètement pour les javascripts ou les composants actifs (notamment les flux vidéo scriptables ou les PDF actifs à moins qu'ils ne soient signés numériquement par vous! Il n'est toujours pas possible de signer numériquement les javascripts, conservez-les uniquement sur votre domaine sécurisé).
verdy_p
Remarque: certains formats d'image sont actifs et scriptables: attention au SVG par exemple. Nous avons vu des attaques sur certains sites Web HTTPS chargeant des images SVG à partir de HTTP (avec les redirections 302 du site), et récoltées par des malwares insérant des scripts dans le contenu SVG ... Idéalement, les navigateurs devraient isoler les sous-contenus HTTP de HTTPS et les placer dans un bac à sable (donc CORS des restrictions de sécurité doivent également s'appliquer, même s'il s'agit du même nom de domaine ...) donc "http: // (domaine) / ..." et "https: // (domaine) /" doivent être considérés comme des domaines distincts pour CORS (pas la même origine) même s'ils sont sur le même numéro de port TCP.
verdy_p
@verdy_p, qu'entendez-vous exactement par "avec les 302 redirections du site"? Vous devez d'abord posséder le site serveur (ou les nœuds participants au niveau TCP / IP, comme les serveurs DNS, les routeurs), pour exploiter ces demandes de ressources HTTP, n'est-ce pas?
Sz.
Pas nécessairement. HTTPS sur un domaine sera sécurisé tandis que HTTP sur le même domaine ne le sera pas (les exploits ne nécessitent pas de contrôler une adresse IP ou des routeurs, ou des serveurs DNS même lors de l'utilisation de DNSSEC; les exploits peuvent simplement utiliser l'usurpation d'adresse IP, qui ne peut pas être détectée en toute sécurité sans HTTPS sur sessions sécurisées). Je maintiens donc qu'un site HTTPS doit héberger des images (même sur le même domaine) en ne les servant pas avec HTTP (cela est même refusé par défaut dans certains navigateurs qui nécessitent un clic d'activation ou masquent ces images non sécurisées). Les mixtes HTTPS / HTTP doivent être bannis: le site est attaquable sur ses parties HTTP (par exemple les pixels de piste).
verdy_p
-6

Pour autant que je sache, une simple méta-actualisation fonctionne également sans provoquer d'erreurs:

<meta http-equiv="refresh" content="0;URL='http://www.yourdomain.com/path'">
RobinUS2
la source
12
Je souhaite que les électeurs à la baisse soient tenus de laisser des commentaires expliquant les raisons des votes à la baisse. Personnellement, je ne choisirais pas cette réponse à moins que vous, en tant que développeur, n'ayez pas accès au serveur pour lequel vous développiez mais que vous ayez accès à la page. Un problème, c'est que vous devrez coder en dur chaque chemin sur chaque page pour que cela fonctionne. Si vous pouvez supposer que JavaScript est activé pour vos cas d'utilisation importants, vous feriez mieux d'utiliser JavaScript pour passer à http. Les réponses ci-dessus sont meilleures car elles ne nécessitent pas de javascript puisqu'elles se produisent sur le serveur.
Rustavore
2
Simplement: parce que htaccess est une bien meilleure option que cela. En outre, cela ne résoudra pas le problème de rediriger le protocole https vers http si vous n'avez pas de certificat.
midudev
1
L'action doit être traitée par le serveur et non par «un» document qu'elle peut servir.
albal