Est-il mauvais de rediriger http vers 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, tout mon http://example.comtrafic est maintenant redirigé vers la https://example.comversion appropriée de la page.

La redirection est effectuée dans mon fichier d’hôtes virtuels Apache avec quelque chose comme cela ...

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 sur toutes les pages. 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 ...

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

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

Un 301garde tout votre google-fu et pageranks durement gagné intact . Assurez-vous que mod_rewriteest activé:

a2enmod rewrite

Pour répondre à votre question exacte:

Est-il mauvais de rediriger http vers https?

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

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 <meta property="og:url"à jour votre en utilisant la version https de votre domaine.
3. Si vous utilisez à <base href=nouveau la mise à jour pour utiliser HTTPS.
4. Installer le 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 ce qui précède est abordé, je doute que vous ayez de nombreux problèmes.

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 nécessaires, 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 se trouve parfois sur un réseau non sécurisé (ou est proche de Troy Hunt et de son ananas )? Ensuite, l'utilisateur demandera http://whateversite.com par vieilles habitudes. 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é l’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 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 ( 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.

Il n'y a rien de mal à cela, et en fait c'est la meilleure pratique (pour les sites qui devraient être servis via 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 301code d'état indique une redirection permanente , invitant les clients capables à utiliser l'URL sécurisée lors de futures connexions (par exemple, mettre à jour le signet).

Si vous ne servez le site que via TLS / SSL, je vous recommanderais une directive supplémentaire pour activer la sécurité du transport HTTP strict (HSTS) dans votre hôte virtuel sécurisé :

<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 ne doivent utiliser HTTPS qu’avec le domaine fourni ( secure.example.comdans ce cas) pendant les prochaines 1234secondes. La ; includeSubdomainspartie est facultative 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 de HSTS est uniquement acceptée par les navigateurs servi via une connexion SSL / TLS!

Pour tester la configuration de votre serveur par rapport aux meilleures pratiques actuelles, le service Test du serveur SSL de Qualys est une bonne ressource gratuite . 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).

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.

Est-il mauvais de rediriger http vers https?

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

Sur les redirections:

Cela pourrait être plus efficace, en é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>

HTTPS n'est pas vraiment infaillible. Bien sûr, forcer le protocole 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, le protocole SSLv2 et SSLv3. En outre, vous devriez savoir si les bibliothèques de votre système cryptographique prennent en charge TLS1.2 (qui est ce que vous voulez avoir;))

Activer SSL, c'est une bonne chose.

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 les 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, dans certains pays, les technologies de cryptage illégales 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.

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

• MITM / SSLSTRIP : C’est un énorme bémol. Si vous envisagez de desservir votre site via HTTPS, 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 le remarque pas, il pensera que sa session est sécurisée alors qu'elle ne l'est pas en réalité.

  • 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 pour 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 actuelle 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 homme au milieu 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 pratiquement 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 tout à fait 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 des données inchangées, et en empêchant les chemins de code coûteux de s'exécuter plus souvent que nécessaire.

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 sur le même site avec HTTPS. Je l'utilise depuis un moment et je n'ai eu aucun problème (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.

Le seul inconvénient technique de HTTPS sur HTTP est qu’il est beaucoup plus coûteux de traiter des demandes HTTPS que de simples HTTP.

Cependant, étant donné que la plupart des serveurs modernes ont des processeurs très puissants, cet impact est généralement négligeable, sauf si vous êtes à des niveaux de trafic extrêmement élevés, auquel cas vous utiliserez probablement des équilibreurs de charge.

Avec l’apparition de protocoles tels que SPDY qui requièrent le protocole SSL / TLS, cette méthode compense en réalité les coûts informatiques susmentionnés en améliorant considérablement les performances en ce qui concerne les demandes multiples et en transférant plus rapidement les actifs au client.

Il est très bon de rediriger vers https, mais je lis que cela dépend aussi de la façon dont vous organisez la redirection.

Créer un serveur virtuel dédié pour rediriger les requêtes http entrantes vers votre connexion https comme suggéré dans la réponse à security.stackexchange.com semble très intelligent et permettra de fermer certaines menaces de sécurité supplémentaires. Une configuration dans Apache ressemblerait à ceci:

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