Question Est-il mauvais de rediriger http en https?


Je viens d'installer un certificat SSL sur mon serveur.

Il a ensuite configuré une redirection pour tout le trafic de mon domaine sur le port 80 afin de le rediriger vers le port 443.

En d'autres termes, tous mes http://example.com le trafic est maintenant redirigé vers le approprié https://example.com version de la page.

La redirection est effectuée dans mon fichier Apache Virtual Hosts avec quelque chose comme ceci ...

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

Ma question est la suivante: l'utilisation de SSL présente-t-elle des inconvénients?

Puisqu'il ne s'agit pas d'une redirection 301, vais-je perdre le jus / le classement des liens dans les moteurs de recherche en passant à https?

J'apprécie l'aide. J'ai toujours voulu installer SSL sur un serveur, juste pour la pratique, et j'ai finalement décidé de le faire ce soir. Cela semble bien fonctionner jusqu'à présent, mais je ne suis pas sûr que ce soit une bonne idée de l'utiliser à chaque page. Mon site n'est pas du commerce électronique et ne traite pas de données sensibles. c'est principalement pour les regards et le plaisir de l'installer pour apprendre.


MISE À JOUR

Étrangement, Bing crée cette capture d'écran à partir de mon site maintenant qu'il utilise HTTPS partout ...

enter image description here 


245
2018-01-28 00:12


origine


[WTF - Je ne peux pas ajouter de réponse (bien que je semble avoir assez de représentants).] Ma réponse serait (en partie) que PARFOIS C'EST MAUVAIS. Envisagez de passer une clé COOKIE ou API dans un GET sur HTTP. Si votre site redirige les requêtes HTTP vers les requêtes HTTPS, ces appels fonctionneront, mais la clé COOKIE ou la clé API sera transmise en clair. Certaines API désactivent HTTP, une approche plus robuste - pas de HTTP du tout, vous ne pouvez même pas le faire fonctionner à moins d'utiliser HTTPS. Exemple: "Toutes les demandes d'API doivent être effectuées via HTTPS. Les appels passés via HTTP en mode normal échoueront" à partir de stripe.com/docs/api?lang=php#authentication - codingoutloud
@codingoutloud - l'alternative est que le la totalité se passe sur HTTP sans HTTPS du tout. Comment ça va mieux? - Mark Henderson♦
@ BenCrowell, c'est parce qu'un portail captif ressemble énormément à un sslstripstyle attaque de redirection (ils sont deux détournements de demande de l'homme-au-milieu) afin HSTSLes navigateurs avertis les bloqueront tous les deux. - Jeffrey Hantin
Sachez que l'utilisation de https signifie que tout ce que vous incluez doit également être https, sinon il risque de ne pas être chargé - par exemple, charger jquery à l'aide de src="://example.com/jquery.js" - notez le manque de http ou https donc le navigateur charge celui qui convient. J'ai eu un cauchemar en essayant de charger correctement certains éléments d'Amazon intégrés car l'API (chargée via https) générait des liens http - ce qui signifie qu'ils ne fonctionnaient pas correctement tant que je n'avais pas trouvé le paramètre non documenté pour basculer les liens https. - Basic
Jason; votre mise à jour devrait être une nouvelle question, probablement sur Webmasters comme il n’a aucun rapport (technique) avec votre question initiale. Mais il est probable que vos feuilles de style proviennent d'un domaine non sécurisé. - Mark Henderson♦


Réponses:


le [R] le drapeau seul est un 302 redirection (Moved Temporarily). Si vous voulez vraiment que les gens utilisent la version HTTPS de votre site (conseil: c'est votre cas), vous devriez utiliser [R=301] pour une redirection permanente:

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

UNE 301 conserve tous vos pageranks google-fu et durement gagnés intact. Assure-toi mod_rewrite est autorisé:

a2enmod rewrite

Pour répondre à votre question exacte:

Est-il mauvais de rediriger http en https?

Sûrement pas. C'est très bien.


309
2018-01-28 00:27



Merci pour l’information, mon patron me dit que la raison pour laquelle il n’utilise https que sur certaines pages de son site, c’est que le système utilise beaucoup plus de ressources de serveur pour l’exécuter à chaque page. Savez-vous quelque chose à ce sujet ou si c'est vrai? - JasonDavis
@jasondavis Seulement si vous ne passez pas quelques minutes à l'optimiser. - Michael Hampton♦
"Il utilise beaucoup plus de ressources serveur pour l'exécuter sur chaque page." Les processeurs modernes disposent de fonctionnalités d’accélération du chiffrement qui rendent le protocole SSL pratiquement gratuit. Ne vous inquiétez pas des frais généraux. - Adam Davis
@AdamDavis L'algorithme de chiffrement peut être léger, mais le temps système de prise de contact existe toujours. En outre, HTTPS empêche les serveurs proxy HTTP de mettre en cache votre contenu. Dans plus Dans certains cas, la surcharge de HTTPS est minime et utile, mais faites attention de ne pas trop généraliser. - 200_success
Il supprime la mise en cache partagée, ce qui est utile pour les habitudes d'utilisation de certains sites et protège peu (est-il important que les gens sachent que vous avez visité le site, mais pas les détails de ce que vous avez fait? C'est le seul cas où SSL est utile). Le principal avantage de SSL sur chaque ressource n’est pas que vous devez "sécuriser", par exemple. les gens qui regardent "à propos de nous", mais que vous ne pouvez pas vous tromper et ne pas l’utiliser dans les cas où vous devriez le faire. - Jon Hanna


Bien que je soutienne l’idée de sites exclusivement SSL, je dirais qu’un inconvénient est les frais généraux qui dépendent de la conception de votre site. Je veux dire, par exemple, si vous diffusez de nombreuses images individuelles dans des balises img, votre site pourrait s'exécuter beaucoup plus lentement. Je conseillerais à quiconque utilisant des serveurs uniquement SSL de s'assurer qu'ils travaillent sur les éléments suivants.

  1. Recherchez des liens internes sur l'ensemble du site et assurez-vous qu'ils utilisent tous le protocole HTTPS si vous spécifiez votre propre nom de domaine dans les liens, de sorte que vous ne provoquiez pas vos propres redirections.
  2. Mettez à jour votre <meta property="og:url" utiliser la version https de votre domaine.
  3. Si tu utilises <base href= à nouveau mettre à jour pour utiliser HTTPS.
  4. Installer Protocole SPDY si possible
  5. Veillez à utiliser les images-objets CSS Image dans la mesure du possible afin de réduire le nombre de demandes.
  6. Mettez à jour vos plans de site pour indiquer l'état https. Ainsi, les araignées apprennent progressivement ce changement.
  7. Modifier les préférences du moteur de recherche telles que Google Webmaster Tools pour préférer HTTPS
  8. Dans la mesure du possible, déchargez tout support stactique sur les serveurs HTTPS CDN.

Si les solutions ci-dessus sont résolues, je doute que vous ayez de nombreux problèmes.


49
2018-01-28 02:08



SPDY est une bonne suggestion. il semble même y avoir un module ajout du support SPDY à Apache 2.x. - Calrion
Utilisation de "//votreserveur.com/some-uri" au lieu de "votreserveur.com/some-uri"résout le problème (1) car le navigateur choisit le schéma approprié (http ou https) en fonction du schéma avec lequel la page a été chargée. - MauganRa
@MauganRa À moins, bien sûr, que ce soit un lien de la page d'article http à la page de connexion https, par exemple. - Mołot
Google voit l'URL qu'une personne visite via le lien Referer entête. Par exemple, ce site utilise jQuery à partir du CDN de Google et mon navigateur envoie une demande à Google chaque fois que je recharge le site. Ainsi un Referer l'en-tête est également envoyé à Google, qui est défini sur l'URL de ce site. Ainsi, Google peut suivre les sites que je visite pendant que mon adresse IP ne change pas (et si j'utilise un service Google pendant cette période, Google peut également connecter ces informations à mon compte Google). - Stephan Kulla
Pour 1) je viens de faire une recherche et remplacer dans ma base de données MySQL http à https ... J'utilise WordPress afin qu'il soit vraiment facile de mettre à jour des centaines de liens - JasonDavis


Si vous avez configuré https, vous devez l’utiliser partout sur le site. Vous éviterez le risque de problèmes de contenu mixte et si vous disposez des outils requis, pourquoi ne pas sécuriser l'ensemble du site?

En ce qui concerne la redirection de http à https, la réponse n’est pas aussi simple.

La redirection facilitera grandement la tâche de vos utilisateurs. Ils saisissent simplement whateversite.com et sont redirigés vers https.

Mais. Que se passe-t-il si l’utilisateur est parfois sur un réseau non sécurisé (ou proche de Troy Hunt et son ananas)? Ensuite, l'utilisateur demandera http://whateversite.com par habitude. C'est http. Cela peut être compromis. La redirection pourrait pointer vers https://whateversite.com.some.infrastructure.long.strange.url.hacker.org. Pour un utilisateur ordinaire, cela semblerait tout à fait légitime. Mais le trafic peut être intercepté.

Nous avons donc deux exigences concurrentes: être convivial et sécurisé. Heureusement, il existe un remède appelé le En-tête HSTS. Avec cela, vous pouvez activer la redirection. Le navigateur passera sur le site sécurisé mais, grâce à l’en-tête HSTS, rappelez-vous-le également. Lorsque l'utilisateur tape whateversite.com assis sur ce réseau non sécurisé, le navigateur passe immédiatement à https, sans passer par la redirection via http. À moins que vous ne traitiez avec des données très sensibles, je pense que c'est un compromis juste entre sécurité et facilité d'utilisation pour la plupart des sites. (Lorsque j'ai récemment configuré une application gérant les dossiers médicaux, je suis passé à tous les https sans redirection). Malheureusement, Internet Explorer ne prend pas en charge HSTS (la source), donc si votre public cible utilise principalement IE et que les données sont sensibles, vous pouvez désactiver les redirections.

Donc, si vous ne ciblez pas les utilisateurs d'IE, utilisez la redirection, mais activez également l'en-tête HSTS.


38
2018-01-28 07:40



Plus de gens doivent faire attention à cela aussi. Une autre chose est que les gens supposent qu'ils sont en sécurité car le point final est HTTPS, en ignorant le fait que toutes les informations envoyées à la page dans les GET ou les POST sont en texte brut. - Velox
@Velox - Je ne pense pas que l'implication de "les gens supposent qu'ils sont sécurisés parce que le point final est HTTPS, en ignorant le fait que toutes les informations envoyées à la page dans les GET ou les POST est en texte brut" est assez précise. Bien qu'il y ait des pièges, les paramètres de requête GET ne circulent pas en clair lors du transport via HTTPS. Voir par exemple: stackoverflow.com/questions/323200/… Les charges POST sont également protégées, mais non vulnérables aux en-têtes de journalisation et de référence. - codingoutloud
@ codingoutloud C'est ce que je veux dire. Sur HTTPS, ils sont chiffrés, mais dans la demande initiale de la page HTTP, ils ne l'étaient pas. - Velox
@Velox - Si tout le site redirige vers HTTPS, il est peu probable que des paramètres GET soient envoyés avant que HTTPS ne soit activé (et tout restera HTTPS après ce point). Il reste la seule demande initiale d'envoi de cookies, à laquelle il est possible de remédier avec HSTS ... et d'une petite fenêtre d'attaque pour SSLStrip, qui pourrait éventuellement être vaincue par JavaScript, mais c'est une course aux armements à elle seule. - Brilliand
@Brilliand Fair point, mais un point faible en matière de sécurité rend l'ensemble faible. Toujours à considérer. - Velox


Il n’ya rien de mal à cela, et c’est en fait une meilleure pratique (pour les sites qui devrait être servi sur une connexion sécurisée). En fait, ce que vous faites est assez similaire à la configuration que j'utilise:

<VirtualHost 10.2.3.40:80>
  ServerAdmin me@example.com
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>

# Insert 10.2.3.40:443 virtual host here :)

le 301 code d'état indique un permanent redirection, en demandant aux clients capables d’utiliser l’URL sécurisée pour les connexions futures (par exemple, mettre à jour le signet).

Si vous ne servez le site que via TLS / SSL, je recommanderais une directive supplémentaire pour activer HTTP. Sécurité de transport stricte (HSTS) dans votre garantir hôte virtuel:

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

Cet en-tête indique aux clients capables (la plupart d’entre eux de nos jours, je crois) qu’ils devraient utilisez uniquement HTTPS avec le domaine fourni (secure.example.com, dans ce cas) pour le prochain 1234 secondes. le ; includeSubdomains partie est optionnel et indique que la directive s’applique non seulement au domaine actuel, mais également à ses domaines inférieurs (par exemple, alpha.secure.example.com). Notez que l'en-tête HSTS est seulement accepté par les navigateurs lorsqu'il est servi via une connexion SSL / TLS!

Pour tester la configuration de votre serveur avec les meilleures pratiques actuelles, une bonne ressource gratuite est Test du serveur SSL de Qualys un service; Je voudrais viser au moins un A- (vous ne pouvez pas obtenir plus que cela avec Apache 2.2 en raison du manque de support pour la cryptographie à courbe elliptique).


22
2018-01-28 02:20



Je devrais ajouter, en envoyant l'en-tête Strict-Transport-Security: max-age=0 annulera toute directive précédente; comme toujours doit être envoyé via HTTPS pour être accepté, mais c’est un moyen pratique d’annuler certaines choses si vous décidez que vous devez également utiliser HTTP sur le domaine. - Calrion


Hou la la ! rediriger HTTP vers HTTPS est une très bonne chose et je ne vois aucun inconvénient à cela.

Assurez-vous simplement que vos clients disposent de l'autorité de certification appropriée pour éviter les avertissements non conviviaux concernant le certificat dans le navigateur.

En outre, la manière dont vous avez configuré Apache pour rediriger vers HTTPS semble correcte.


5
2018-01-28 00:35





Est-il mauvais de rediriger http en https?

Non pas du tout. En fait, c'est une bonne chose à faire!

Sur les redirections:

Il pourrait être plus efficace, par éliminant complètement les réécritures. Voici ma config sur une situation similaire ...

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>

5
2018-01-28 13:45





HTTPS n'est pas vraiment infaillible. Bien sûr, forcer HTTPS est une bonne chose. Il empêche les criminels normaux de faire quelque chose de mal à vos utilisateurs.

Mais n'oubliez pas de vérifier vos paramètres SSL, comme le paramètre SSLCiphers. Désactivez des fonctions telles que le cryptage RC4, les protocoles SSLv2 et SSLv3. En outre, vous devriez savoir si les bibliothèques de crypto-système de votre système prennent en charge TLS1.2 (qui est ce que vous voulez avoir;))

Activer SSL, c'est une bonne chose.


4
2018-01-28 07:43



L’entropie n’est pas épuisée (au moins si vous vous défendez contre des attaquants basés sur la Terre plutôt que faire du vaudou). Soit vous commencez avec une entropie insuffisante et vous ne pouvez rien faire qui nécessite un caractère aléatoire, soit vous commencez avec une entropie suffisante et vous continuez à avoir une entropie suffisante quel que soit le degré d’aléatoire que vous générez. - Gilles
Pardon, quoi? Un certain nombre d'opérations sur Linux insistent sur une entropie forte dérivée du matériel plutôt que sur une entropie probablement assez bonne basée sur PRNG. Celles-ci peuvent en effet bloquer si la profondeur du pool est faible. Il est certainement possible de commencer avec une entropie suffisante sur un système Linux, mais par surutilisation pour vider le pool, provoquant le blocage de certaines opérations. - MadHatter


Personnellement, je suis tout à fait en faveur de l’utilisation de SSL pour sécuriser les connexions sur le Web. Cependant, j’ai le sentiment que toutes les réponses manquantes sont les suivantes: tous les appareils et logiciels capables d’une connexion HTTP ne peuvent pas utiliser SSL, Je proposerais donc aux utilisateurs de l’éviter s’il n’est pas pris en charge. Il est également possible que les personnes dans certains pays où la technologie de cryptage soit illégale ne soient pas autorisées à accéder à votre site. J'envisagerais d'ajouter une page de destination non chiffrée avec un lien pour forcer la version non sécurisée du site, mais à moins qu'un utilisateur n'en décide spécifiquement de le faire et de simplement le transférer vers la version HTTPS.


3
2018-01-28 10:13



Un problème avec des solutions comme avoir une page de destination HTTP simple, même correctement séparée, est que cette page est laissée ouverte à la manipulation. En d'autres termes, il n'existe aucune garantie réelle que le lien de la version HTTPS du site soit livré intact aux visiteurs. - Håkan Lindqvist


Voici quelques-uns des grands problèmes de coups de pinceau:

  • MITM / SSLSTRIP: Ceci est une mise en garde énorme. Si vous allez desservir votre site via HTTPS, puis désactivez HTTP sur le site. Sinon, vous laissez vos utilisateurs ouverts à diverses attaques de type man-in-the-middle, y compris SSLSTRIP, qui intercepteront les demandes et les serviront en mode silencieux via HTTP, en insérant leur propre script de programme malveillant dans le flux. Si l'utilisateur ne remarque pas, alors ils vont pense leur session est sécurisée alors qu'elle ne l'est pas.

    • Le problème avec ceci, cependant, est que si votre site est un site public et que vous ne désactivez pas HTTP sans cérémonie, vous risquez de perdre beaucoup de visiteurs. Il ne sera probablement même pas se produire à eux d'essayer HTTPS si le site ne se charge pas avec HTTP.
  • Si votre site nécessite une connexion sécurisée, l'intégralité de la session d'utilisateur doit être sécurisée. Ne vous authentifiez pas via HTTPS, puis redirigez l'utilisateur vers HTTP. Si vous le faites, encore une fois, vous laissez vos utilisateurs vulnérables aux attaques MITM. L’approche standard de l’authentification de nos jours consiste à s’authentifier une fois, puis à transmettre un jeton d’authentification (dans un cookie). Mais si vous vous authentifiez via HTTPS puis redirigez vers HTTP, un agent intermédiaire pourra alors intercepter ce cookie et utiliser le site comme s'il s'agissait de votre utilisateur authentifié, en contournant votre sécurité.

  • Les problèmes de "performance" avec HTTPS sont, à toutes fins pratiques, limités à la poignée de main impliquée dans la création d'une nouvelle connexion. Faites ce que vous pouvez pour minimiser le besoin de plusieurs connexions HTTPS à partir d'une URL et vous serez loin devant. Et c’est franchement vrai, même si vous diffusez votre contenu via HTTP. Si vous lisez sur SPDY, vous réaliserez que tout ce qu'il fait est orienté vers la tentative de servir tout le contenu à partir d'une URL unique sur une seule connexion. Oui, l'utilisation de HTTPS affecte la mise en cache. Mais combien de sites Web ne sont-ils que du contenu statique pouvant être mis en cache de nos jours? Vous obtiendrez probablement plus pour votre argent en utilisant la mise en cache sur votre serveur Web afin de minimiser les requêtes redondantes dans la base de données, en récupérant les données inchangées à maintes reprises et en empêchant les chemins de code coûteux de s'exécuter plus souvent que nécessaire.


3
2018-04-19 10:43



Ce que vous pouvez faire pour vous attaquer bandeau est d'utiliser HSTS (de préférence obtenez vos paramètres HSTS préchargés). Que vous acceptiez des requêtes via un protocole HTTP simple ou non importe peu à cet égard, un MITM peut répondre via un protocole HTTP simple (éventuellement par proxy vers votre site HTTPS) même si vous n'acceptez que des requêtes HTTPS. - Håkan Lindqvist
@ HåkanLindqvist J'ai vraiment obtenu un vote négatif de votre part? Ai-je donné un mauvais conseil ou un bon conseil en ce qui concerne la non-authentification via HTTPS, puis le passage à HTTP pour le reste de la session? Ai-je donné un mauvais conseil en ce qui concerne les mythes sur les performances HTTPS? De plus, si le client tente initialement de se connecter à l'aide du protocole HTTPS, le MITM ne peut pas intercepter et répondre sans déclencher une alerte dans le navigateur, car son certificat ne correspond pas à moins qu'un certificat ait été volé ou falsifié avec succès. D'autre part, si le site accepte une connexion HTTP, l'interception est plus facile. De toute façon, HTTPS soulève la barre. - Craig
..et bien sûr, je suis tout à fait d'accord avec l'utilisation de HSTS. - Craig
Mon problème avec la réponse est le premier élément de la liste prétendant s’adresser à sslstrip alors qu’il ne le fait pas (en parlant de mythes). Ce que j'essayais de comprendre dans mon commentaire initial est que si vous avez un MITM actif (ce dont vous avez besoin pour sslstrip en premier lieu), l'attaquant peut être essentiellement "le site" du point de vue du client; C'est l'attaquant qui décide s'il souhaite accepter les connexions HTTP en clair du client. La manière dont votre serveur Web se comporte à cet égard n'affecte pas ce que l'attaquant peut ou va faire. - Håkan Lindqvist
@ HåkanLindqvist Sauf que si le visiteur tente intentionnellement de se connecter avec HTTPS, l'attaquant ne peut pas satisfaire cette demande sans lancer d'indicateurs dans le navigateur, à moins d'avoir réussi à voler un certificat de serveur ou à en forger avec succès, ce qu'il devrait faire afin de basculer la connexion vers HTTP. HTTPS encore lève la barre. Bien sûr, si le visiteur effectue la tentative de connexion initiale via HTTP, tous les paris sont complètement désactivés. - Craig


Ce n'est pas techniquement une réponse à votre question initiale, mais si vous utilisez l'extension HTTPSEverywhere de Google Chrome (des extensions similaires existent déjà sur d'autres navigateurs), l'extension redirige automatiquement les sites avec HTTP vers le même site avec HTTPS. Je l'utilise depuis un moment et je n'ai pas eu de problèmes (sauf peut-être un ralentissement, mais je n'ai pas testé cela). HTTPSEverywhere peut être modifié par certaines règles côté serveur, mais comme je n'ai pas fait grand chose dans ce domaine, je ne suis pas sûr des détails exacts.

Pour revenir à votre question actuelle, si vous utilisez quelque chose comme HTTPSEverywhere, l'incitation à utiliser uniquement HTTP est encore moins encourageante, même si j'imagine qu'il est difficile de définir des règles correctes pour les cas où vous en avez besoin.


1
2018-01-28 04:27