Dois-je utiliser un SSL dans mes domaines de test?

Philip Rowlands

2017-03-13 19:05:31 UTC

view on stackexchange narkive permalink

Oui, tu devrais. Vous devrez peut-être tester si par exemple une requête particulière fonctionne sur HTTPS, mais tester sur un système de production est une mauvaise idée (le système de production doit rester stable), et votre système de test doit correspondre le plus possible au système de production. Deuxièmement, si vous partagez les informations de connexion entre domaines, pourquoi le domaine de test ne devrait-il pas également être sécurisé?

Si le prix du certificat pose un problème, vous pouvez:

Obtenez un certificat gratuit de Let's Encrypt.
Utilisez un certificat auto-signé.
Configurez votre propre certificat interne autorité pour le domaine de test (probablement la meilleure option).

Le système de test doit être aussi proche que possible du système en direct, à l'exception des données utilisées (qui doivent être étroitement modélisées d'après des données en direct mais fictives).Sinon, vous * ne testez pas *.Le nombre de fois où j'ai vu des systèmes échouer lorsqu'ils sont déployés en raison de différences entre la plate-forme live et QA .......

Bonne prise, @pwdst.Je vais reformuler cette phrase un peu (mon point non dit était que le système de production devrait rester stable).

Deuxièmement: configurez votre propre autorité de certification interne pour le domaine de test (probablement la meilleure option).

Quelqu'un peut-il expliquer pourquoi la dernière option est la meilleure?Quel avantage y a-t-il par rapport à l'utilisation d'un certificat de Let's Encrypt?(Je ne doute pas de vous, juste curieux car ce n'est pas mon domaine d'expertise.)

@Josh1billion la configuration d'une autorité de certification interne signifie que vous disposez d'un certificat racine de confiance qui peut émettre des certificats pour vos serveurs internes.Si tous vos clients de test font confiance à cette autorité de certification, vous pouvez émettre un nouveau certificat pour un serveur particulier, et vos clients lui feront automatiquement confiance.Ce serait probablement plus rapide que d'attendre une autorité de certification externe, et vous n'auriez pas à propager manuellement un nouveau certificat auto-signé à tous vos clients de test.

@Josh1billion: Vous n'avez pas besoin de connexion Internet pour obtenir un nouveau certificat si vous êtes l'autorité (permettant de travailler hors ligne, ...);vous pouvez générer des certificats avec de nombreuses bizarreries (pour valider votre pile / application SSL) si vous êtes l'autorité;vous pouvez générer de nombreux certificats différents sans limitation de taux (pas sûr que cela s'applique);... liberté et contrôle, en bref.Bien entendu, pour un domaine auquel les utilisateurs externes devront accéder, vous avez besoin d'une autorité de certification de confiance.

Il convient également de noter que de plus en plus de nouvelles fonctionnalités ne fonctionneront pas sur http classique (comme la géolocalisation, les techniciens de service et même l'encodage brotli), il ne s'agit donc plus uniquement de cryptage et de confidentialité.

Steffen Ullrich

2017-03-13 19:00:09 UTC

view on stackexchange narkive permalink

J'ai un deuxième domaine avec le même contenu (y compris les identifiants de connexion) que j'utilise uniquement pour les tests et le développement.

Si le deuxième domaine fournit le même contenu et a les mêmes identifiants de connexion et est également accessible depuis Internet, il n'y a aucune raison pour qu'il ne bénéficie pas de la même protection (c'est-à-dire SSL) que le premier domaine.

nasukkin

2017-03-13 21:57:03 UTC

view on stackexchange narkive permalink

Vous devez non seulement utiliser SSL pour vos domaines de test, mais vous en avez besoin si vous souhaitez activer des fonctionnalités de sécurité telles que le Préchargement HSTS.

Je pense que le préchargement HSTS n'est pas vraiment un problème ici;le serveur de test verra probablement ces détails changer régulièrement de toute façon.

Le préchargement HSTS oblige tous les sous-domaines à se charger également avec HTTPS, et je pense que cet auteur de réponse a supposé que les sites de test étaient des sous-domaines du principal.

@AyeshK C'est correct.

Shibasis Sengupta

2017-03-15 12:03:05 UTC

view on stackexchange narkive permalink

Vous devriez. C'est la réponse courte.

Dans la réponse plus longue, vous seriez surpris de savoir combien de fois des vulnérabilités de sécurité se produisent des utilisateurs internes d'une organisation. Par exemple, si votre environnement de test a des informations d'identification d'administrateur, une couche de transport non protégée signifie qu'une personne de votre organisation (qui n'est pas un administrateur autorisé) peut potentiellement renifler et obtenir les informations d'identification d'administrateur - ce que vous ne voulez pas.

Si le coût du certificat est un problème, vous pouvez toujours faire émettre un certificat auto-signé. Mais vous devez vous assurer que cette autorité de signature (celui qui génère ce certificat interne pour vous) est installée en tant qu'autorité de certification de confiance sur les bureaux de test. Sinon, votre navigateur peut générer une erreur indiquant que ce certificat est signé par une personne non approuvée. Si vous exécutez 'certmgr.msc' dans Windows, vous pouvez voir les autorités de certification de confiance pour n'importe quelle machine particulière.

Stan Quinn

2017-03-15 09:04:47 UTC

view on stackexchange narkive permalink

Oui ... le test n'est valide que s'il simule l'environnement de production, y compris comment il fonctionne sur https. Les certificats génériques sont assez bon marché, il suffit donc de placer le domaine de test sous un sous-domaine. Votre domaine de test ne devrait probablement pas être accessible au public, sauf si le client a besoin d'y accéder à partir d'adresses IP aléatoires, sinon verrouillez-le sur votre propre plage IP dans l'hôte virtuel ou le pare-feu. De plus, c'est un bon moyen de vous assurer que tout le contenu de votre site Web est disponible sur https.

Anton

2017-03-14 16:16:50 UTC

view on stackexchange narkive permalink

Vous en avez certainement besoin à des fins de test. Nous avons eu des situations où le comportement de notre système était différent sur SSL d'une connexion non sécurisée.

Pour des raisons de sécurité, ce n'est pas nécessaire, car vous pouvez déplacer vos environnements de test derrière VPN.

Votre première ligne est couverte par les autres réponses, votre dernière ligne est très mal formulée - Ce que vous voulez dire, c'est que, oui, vous devez toujours sécuriser le site, mais vous pouvez le faire avec un VPN et non une connexion SSL.Mais cette suggestion fait beaucoup d'hypothèses sur la conception, les capacités et l'intention de développement de la situation du PO.