Est-il mauvais de rediriger http vers https?
Je viens d'installer un certificat SSL sur mon serveur.
Il a ensuite mis en place une redirection pour tout le trafic sur mon domaine sur le port 80 pour le rediriger vers le port 443.
En d'autres termes, tous mes http://example.com le trafic est désormais redirigé vers le https://example.com version de la page.
La redirection se fait dans mon fichier Apache Virtual Hosts avec quelque chose comme ça ...
RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_Host}/$1 [NC,R,L]
Ma question est, y a-t-il des inconvénients à utiliser SSL?
Comme il ne s'agit pas d'une redirection 301, vais-je perdre du jus de liens/classement dans les moteurs de recherche en passant à https?
J'apprécie l'aide. J'ai toujours voulu configurer SSL sur un serveur, juste pour la pratique de le faire, et j'ai finalement décidé de le faire ce soir. Cela semble bien fonctionner jusqu'à présent, mais je ne sais pas si c'est une bonne idée de l'utiliser sur chaque page. Mon site n'est pas du commerce électronique et ne gère pas les données sensibles; c'est principalement pour l'apparence et le plaisir de l'installer pour l'apprentissage.
NUMÉRO MIS À JOUR
Étrangement, Bing crée cette capture d'écran à partir de mon site maintenant qu'il utilise HTTPS partout ...
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 (indice: vous le faites), 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 vers https?
Sûrement pas. C'est très bien.
Bien que je soutienne l'idée de sites SSL uniquement, je dirais qu'un inconvénient est les frais généraux en fonction de la conception de votre site. Je veux dire, par exemple, si vous diffusez de nombreuses images individuelles dans des balises img, cela pourrait ralentir votre site. Je conseillerais à toute personne utilisant uniquement des serveurs SSL de s'assurer qu'ils fonctionnent sur les éléments suivants.
- Vérifiez l'ensemble du site pour les liens internes et assurez-vous qu'ils utilisent tous HTTPS si vous spécifiez votre propre nom de domaine dans les liens, afin de ne pas provoquer vos propres redirections.
- Mettez à jour votre
<meta property="og:url"à utiliser la version https de votre domaine. - Si tu utilises
<base href=mise à jour à nouveau pour utiliser HTTPS. - Installer protocole SPDY si possible
- Assurez-vous d'utiliser des sprites d'image CSS dans la mesure du possible, pour réduire le nombre de requêtes.
- Mettez à jour vos plans de site pour indiquer le statut https, afin que les araignées au fil du temps apprennent ce changement.
- Modifiez les préférences du moteur de recherche comme Google Webmaster Tools pour préférer HTTPS
- Dans la mesure du possible, déchargez tous les supports stactiques vers les serveurs HTTPS CDN.
Si ce qui précède est résolu, 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 avez les outils nécessaires en place, pourquoi ne pas sécuriser l'ensemble du site?
En ce qui concerne la redirection de http vers https, la réponse n'est pas aussi simple.
La redirection facilitera beaucoup la tâche de vos utilisateurs, ils tapent simplement whateversite.com et sont redirigés vers https.
Mais. Que faire si l'utilisateur se trouve parfois sur un réseau non sécurisé (ou est proche de Troy Hunt et son ananas )? Ensuite, l'utilisateur demandera http://whateversite.com par vieille habitude. C'est http. Cela peut être compromis. La redirection peut pointer vers https://whateversite.com.some.infrastructure.long.strange.url.hacker.org . Pour un utilisateur ordinaire, cela aurait l'air tout à fait légitime. Mais le trafic peut être intercepté.
Nous avons donc ici deux exigences concurrentes: être convivial et sécurisé. Heureusement, il existe un remède appelé en-tête HSTS . Avec lui, vous pouvez activer la redirection. Le navigateur se déplacera vers le site sécurisé, mais grâce à l'en-tête HSTS, souvenez-vous-en également. Lorsque l'utilisateur tape sur whateversite.com assis sur ce réseau non sécurisé, le navigateur accède immédiatement à https, sans passer par la redirection via http. Sauf si vous traitez des données très sensibles, je pense que c'est un compromis équitable entre la sécurité et la convivialité pour la plupart des sites. (Lorsque j'ai récemment mis en place une application de gestion des dossiers médicaux, je suis allé 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 IE utilisateurs, allez-y et 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 [email protected]
ServerName secure.example.com
RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>
# Insert 10.2.3.40:443 virtual Host here :)
Le 301 le code d'état indique une redirection permanente, indiquant aux clients capables d'utiliser l'URL sécurisée pour les connexions futures (par exemple, mettre à jour le signet).
Si vous ne servez que le site via TLS/SSL, je recommanderais une autre directive pour activer HTTP Strict Transport Security (HSTS) dans votre sécurisé virtuel Hôte:
<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=1234; includeSubdomains"
</IfModule>
Cet en-tête indique aux clients compétents (la plupart d'entre eux de nos jours, je crois) qu'ils doivent utiliser uniquement HTTPS avec le domaine fourni (secure.example.com, dans ce cas) pour le prochain 1234 secondes. Le ; includeSubdomains la partie est facultative et indique que la directive s'applique non seulement au domaine actuel, mais à tout domaine en dessous (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 par rapport aux meilleures pratiques actuelles, une bonne ressource gratuite est Qualys 'SSL Server Test service; Je viserais à obtenir au moins un A- (vous ne pouvez pas obtenir plus que cela avec Apache 2.2 en raison du manque de prise en charge de la cryptographie à courbe elliptique).
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>
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 la bonne autorité de certification pour éviter les avertissements non conviviaux concernant le certificat dans le navigateur.
De plus, la façon dont vous avez configuré Apache pour rediriger vers HTTPS semble correcte.
HTTPS n'est pas exactement infaillible. Bien sûr, forcer normalement HTTPS est une bonne chose. Il empêche les criminels normaux de faire du mal à vos utilisateurs.
Mais n'oubliez pas de vérifier vos paramètres SSL comme le paramètre SSLCiphers. Désactivez des éléments tels que la cryptographie RC4, les protocoles SSLv2 et SSLv3. De plus, vous devriez savoir si les bibliothèques de crypto-système de votre système prennent en charge TLS1.2 (ce que vous voulez avoir;))
Activez SSL, c'est une bonne chose.
Voici quelques-uns des principaux problèmes liés aux coups de pinceau:
MITM/SSLSTRIP: Ceci est une énorme mise en garde. Si vous allez servir votre site via HTTPS, , désactivez HTTP sur le site . Sinon, vous laissez vos utilisateurs ouverts à diverses attaques man-in-the-middle, y compris SSLSTRIP, qui interceptera les demandes et les servira discrètement via HTTP, en insérant leur propre script de malware dans le flux. Si l'utilisateur ne s'en rend pas compte, il pensera que sa session est sécurisée alors qu'elle ne l'est pas.
- Le problème avec cela, cependant, est que si votre site est un site public et que vous désactivez simplement HTTP sans cérémonie, vous risquez de perdre beaucoup de visiteurs. Il ne se produira probablement même pas pour eux d'essayer HTTPS si le site ne se charge pas avec HTTP.
Si votre site nécessite une connexion sécurisée, la session utilisateur entière doit être sécurisée. Ne vous authentifiez pas sur 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 à passer un jeton d'authentification d'avant en arrière (dans un cookie). Mais si vous vous authentifiez sur HTTPS puis redirigez vers HTTP, un homme du milieu peut intercepter ce cookie et utiliser le site comme s'il était votre utilisateur authentifié, contournant votre sécurité.
Les problèmes de "performances" avec HTTPS sont à toutes fins pratiques limités à la prise de contact 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 aurez des kilomètres d'avance. Et c'est franchement vrai même si vous diffusez votre contenu via HTTP. Si vous lisez SPDY, vous vous rendrez compte 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 que du contenu statique et pouvant être mis en cache de nos jours, de toute façon? Il est probable que vous en ayez plus pour votre argent en utilisant la mise en cache sur votre serveur Web pour minimiser les requêtes de base de données redondantes, en récupérant les données inchangées encore et encore, et en empêchant les chemins de code coûteux de s'exécuter plus souvent que nécessaire.
Personnellement, je suis tout à fait favorable à l'utilisation de SSL pour sécuriser les connexions sur le Web, mais je pense qu'un point que toutes les autres réponses ici ont manqué est que tous les appareils et logiciels capables d'une connexion HTTP ne pourront pas utiliser SSL, ainsi je considérerais de fournir un moyen aux utilisateurs de l'éviter s'il n'est pas pris en charge pour eux. Il est également possible que les personnes dans certains pays où la technologie de cryptage est 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 ne choisisse spécifiquement de faire ce que vous avez dit et de simplement les transmettre à la version HTTPS.
le seul inconvénient technique de HTTPS sur HTTP est qu'il est plus coûteux en termes de calcul de traiter les demandes HTTPS que HTTP standard
Cependant, étant donné que la plupart des serveurs modernes ont des processeurs puissants, cet impact est généralement négligeable, sauf si vous êtes à des niveaux de trafic extrêmement élevés, auquel cas vous utilisez plus que probablement des équilibreurs de charge
Avec l'avènement de protocoles tels que SPDY qui nécessitent SSL/TLS pour fonctionner, cela contrebalance en fait la surcharge de calcul susmentionnée en améliorant considérablement les performances en ce qui concerne les demandes multiples et en obtenant des actifs au client plus rapidement dans l'ensemble.
Il est très bon de rediriger vers https, mais j'ai lu 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 sur security.stackexchange.com = semble très intelligent et fermera 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>
Ce n'est pas techniquement une réponse à votre question d'origine, mais si vous utilisez Google Chrome extension HTTPSEverywhere (je suis sûr qu'il existe des extensions similaires sur d'autres navigateurs), l'extension redirige automatiquement les sites avec HTTP vers le même site avec HTTPS. Je l'utilise depuis un certain temps, 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 en revenir à votre question réelle, si vous utilisez quelque chose comme HTTPSEverywhere, il y a encore moins d'incitation à utiliser uniquement HTTP, même si j'imagine qu'il est difficile de définir des règles correctes lorsque vous en avez besoin.