Comment exécuter le HTTPS approprié sur un réseau interne?
Cette question a été posée plusieurs fois, je vais en relier quelques-unes:
- https://superuser.com/questions/791015/https-over-private-network
- https://stackoverflow.com/questions/616055/https-certificate-for-internal-use
- https://stackoverflow.com/questions/2676238/ssl-signed-certificates-for-internal-use
- Puis-je acheter un certificat valide pour la signature pour un usage interne?
Cependant, ce sont de vieilles questions et je sais que, du moins à certains égards, les réponses fournies sont obsolètes. Je fais mes recherches dans l'espoir de découvrir quelles parties de celles-ci sont obsolètes et quelles sont toujours bonnes. Je cherche des réponses modernes.
La question est simple, mais voici la situation. J'ai des services Web qui accèdent à des informations sensibles (pour la perspective: ce serait mauvais pour notre entreprise et nos clients, mais probablement pas mortel non plus). Je veux fournir un accès facile à ces systèmes, mais la sécurité est évidemment importante. (Certains de ces services sont accessibles via des clients sans navigateur, en tant que services Web. Certains sont simplement des pages Web que les humains utilisent à partir de navigateurs modernes.)
À cette fin, nous gardons les services les plus importants accessibles uniquement en interne. De cette façon, un attaquant a) est peu susceptible de les trouver accidentellement, et b) a un obstacle supplémentaire à surmonter.
Une "sécurité approfondie", cependant, suggérerait que nous cryptions également le trafic en interne également. Cela rend encore plus difficile pour quelqu'un à l'intérieur du réseau de renifler nonchalamment les mots de passe du fil.
Dans l'esprit de "faire mes devoirs", j'ai rassemblé plusieurs options, certaines moins agréables que d'autres. Je ne suis pas tout à fait certain de celles qui sont même réalisables maintenant, car je sais que certaines règles ont changé.
Cert auto-signé
Cela semble être la réponse "incontournable" à cette question la plupart du temps. Cela résiste au problème de reniflement occasionnel, mais je devrais dire à tous les employés "la grande page d'avertissement désagréable est très bien, il suffit de cliquer dessus". J'ai travaillé dur pour les former à ne jamais ignorer cette page, et la plupart d'entre eux ne comprendraient pas les nuances de "la page est parfois correcte, quand vous savez et vous attendez à ce que le site utilise un certificat auto-signé" ( ils ont tendance à arrêter d'écouter la virgule :)).
Cert auto-signé, mais installé et approuvé sur chaque système
Cela corrige la mauvaise page, je pense, mais je devrais la configurer pour qu'elle soit approuvée sur chaque ordinateur qui y a accédé. C'est possible, mais indésirable.
De plus, je ne suis pas certain à 100% que cela soit même possible pour les adresses internes. Je crois comprendre que les navigateurs modernes sont censés refuser tout certificat qui prétend certifier une machine qui résout une adresse IP non publique ou qui n'est pas entièrement qualifiée.
De plus, le processus d'installation des certificats racine du système sur les appareils mobiles est ... fondamentalement impossible. Il nécessite un Android Android enraciné et un processus relativement mystérieux pour les appareils iOS.
Configurer ma propre autorité de certification
Fondamentalement, le même problème avec les certificats installés et approuvés, mais je n'ai qu'à installer le certificat racine, pas un certificat pour chaque système sur lequel je me tiens. Éteint toujours tous les appareils mobiles, y compris les tablettes que les gestionnaires aiment utiliser lors des réunions.
Je suis encore moins convaincu que cela fonctionnerait, car les adresses IP seront internes et le DNS ne sera pas entièrement qualifié.
Utilisez des certificats publics, mais pour les adresses internes.
Nous pourrions configurer des adresses complètes (comme "secret.private.example.com") pour les résoudre en adresses internes (comme "192.168.0.13"). Ensuite, nous pourrions utiliser des certificats pour ces noms DNS publics (peut-être même des certificats génériques pour "* .private.example.com").
Cela pourrait ou ne pourrait pas fonctionner, et ce pourrait même ne pas être une bonne idée. Les navigateurs peuvent rejeter le certificat pour avoir tenté de résoudre une adresse locale.
Si cela fonctionne, ce n'est peut-être pas une bonne idée. Un ordinateur portable transféré de notre système interne vers un autre réseau (éventuellement très rapidement, via une déconnexion VPN) pourrait tenter d'accéder à des choses secrètes à des adresses IP locales sur d'autres réseaux. Tant que HSTS est en vigueur, cela ne devrait pas être un gros problème, car sans notre clé privée, ils ne pourront pas convaincre le client pour accepter le site falsifié et ne pourra pas forcer une rétrogradation vers HTTP. Mais cela semble indésirable, et cela brise la règle "pas d'adresses privées dans le DNS public" qui (peut-être?) Est entrée en vigueur récemment?
Donc, tout cela pour dire ... quelle est la bonne réponse? Je pourrais simplement "abandonner" et exposer publiquement les services privés, en espérant que les exigences de chiffrement et d'authentification spécifiques à l'application assureront la sécurité. En effet, pour certaines choses moins sensibles, c'est un bon cours. Mais je crains que l'authentification spécifique à l'application ne soit boguée ou que les informations d'identification soient compromises par d'autres moyens (les gens sont toujours le maillon le plus faible), et je préférerais qu'il y ait un obstacle supplémentaire, s'il est raisonnable.
La validation du certificat est effectuée pour vous assurer que l'homologue est celui que vous attendez. La validation d'un certificat de serveur dans le navigateur se fait principalement en vérifiant que le nom d'hôte de l'URL correspond au (x) nom (s) dans le certificat et que vous pouvez créer une chaîne de confiance vers un certificat CA approuvé localement (c'est-à-dire les certificats racine stockés dans le navigateur ou OS). De plus, il existe des contrôles d'expiration et de révocation.
Pour vous assurer que ce processus fonctionne comme prévu, il est essentiel que l'émetteur du certificat valide que vous possédez réellement le ou les noms d'hôte dans le certificat. Cela signifie que vous ne pouvez obtenir un certificat émis par une autorité de certification publique que si vous pouvez prouver que vous êtes propriétaire de ce nom, ce qui implique généralement que l'hôte portant ce nom est publiquement visible - au moins pour les certificats bon marché où la validation automatique est effectuée. Bien sûr, vous pouvez contourner ce problème en ayant réellement le nom d'hôte disponible en public (c'est-à-dire un seul serveur accessible avec *.example.com), puis utilisez les certificats émis pour votre système interne.
(Mis) l'utilisation d'une autorité de certification publique pour les systèmes internes de cette façon est un peu moche mais devrait surtout fonctionner. Vous avez toujours besoin d'une connectivité Internet, car les vérifications de révocation seront effectuées à l'aide des informations de l'autorité de certification, c'est-à-dire de l'extérieur de votre réseau local. Cela peut être en quelque sorte limité en utilisant l'agrafage OCSP, mais tous les clients et serveurs ne le prennent pas en charge. Si vous n'autorisez pas vos clients à demander à l'autorité de certification externe des informations de révocation, la configuration de la connexion peut parfois être lente car le client essaie sans succès d'obtenir les informations de révocation.
Ainsi, l'utilisation d'une autorité de certification publique devrait être possible, mais avec des inconvénients et cela ressemble à jouer avec le système de l'autorité de certification de manière incorrecte - donc je ne le recommande pas. La seule autre alternative lorsque vous traitez de nombreux certificats est d'utiliser votre propre autorité de certification locale. Mais comme vous vous en êtes rendu compte, cela signifie installer et faire confiance au certificat racine sur tous vos systèmes locaux (cela peut être automatisé pour certains systèmes). Cela signifie également que vous devez vraiment protéger cette autorité de certification locale contre les abus, car elle ne se limite pas à émettre uniquement des certificats locaux, mais pourrait en théorie également émettre des certificats pour tous les domaines publics tels que google.com. Et puisque tous vos systèmes locaux font confiance à cette autorité de certification, ils feront également confiance à ces certificats. En outre, l'épinglage de certificat ne sera pas vérifié dans la plupart des systèmes lorsque l'autorité de certification émettrice a été explicitement ajoutée comme approuvée. Cela facilite l'utilisation abusive de l'AC pour l'interception SSL légale ou illégale (c'est-à-dire l'attaque de l'homme au milieu).
Ce qui signifie qu'il n'y a pas vraiment de bonne option: abusez d'une autorité de certification publique pour les hôtes internes avec tous les inconvénients ou créez votre propre autorité de certification avec tous les inconvénients. Je suis sûr qu'il y aura également une autorité de certification publique qui vous aidera à résoudre ce problème, mais cela sera probablement plus coûteux que vous le souhaitez.
"Utilisez des certificats publics, mais pour les adresses internes."
Cette option fonctionne assez bien, c'est ce que nous faisons.
Vous pouvez réellement faire une validation HTTP, le certificat n'inclut pas l'adresse IP, juste le nom DNS. Vous pouvez donc pointer votre DNS vers un service externe, valider, puis le pointer vers une IP interne.
Mais la validation DNS fonctionne mieux si votre autorité de certification la prend en charge, car vous n'avez pas à modifier l'entrée à chaque fois que vous devez effectuer un renouvellement. Tout ce qu'un certificat SSL fait est de valider que vous contrôlez le nom, donc si vous pouvez créer des entrées de sous-domaine, vous contrôlez évidemment le nom.
Instructions pour letsencrypt: https://serverfault.com/questions/750902/how-to-use-lets-encrypt-dns-challenge-validation
Je crois que les adresses IP publiques et les noms de domaine complets sont requis par l'autorité de certification, et non par les navigateurs, vous devriez donc être d'accord (au moins, sauf si quelqu'un a mieux informations, vous pouvez configurer un test dans un après-midi et confirmer dans un sens ou dans l'autre).
Cela exclut au minimum les certificats publics. De vos trois options restantes, la meilleure expérience utilisateur est apportée par la création de votre propre autorité de certification, et c'est également l'option la plus fiable car elle offre tous les avantages de l'authentification qui manque aux autres options.
Pour ce que ça vaut, vous pouvez installer des certificats racine sur Android ( v4.x et versions ultérieures ) et sur iOS ( comme vous le dites, un processus relativement mystérieux ), bien que cela soit sans aucun doute une douleur.
La seule autre véritable option consiste à obtenir une adresse IP publique et à configurer un DNS avec un nom de domaine public, et à limiter l'accès à celui-ci, peut-être par le biais de VPN ou similaires.
L'utilisation d'un certificat auto-signé que les utilisateurs acceptent à chaque utilisation devrait être le dernier recours absolu, comme vous l'avez noté, il s'agit simplement de les former à faire la mauvaise chose.
La meilleure solution que j'ai découverte jusqu'à présent est d'utiliser un proxy inverse tel que Caddy pour gérer les certificats (émission et renouvellement), configurer un serveur DNS pour pointer tous les noms d'hôte internes vers le serveur Caddy et tout fonctionne automatiquement. Si vous souhaitez limiter l'accès à l'interne uniquement, vous pouvez fermer le port 80 jusqu'à ce que vos certificats nécessitent un renouvellement.
J'ai également travaillé sur cela et j'ai juste implémenté https sur certaines applications Web internes.
D'abord sur notre serveur DNS interne, j'ai configuré une nouvelle zone de recherche directe, corp.domain.com Et puis configuré quelques enregistrements A/Cname à l'intérieur de cela, webapp1.corp.domain.com pointant vers notre IP LAN interne
Maintenant, nous possédons déjà un certificat SSL générique pour * .domain.com, donc avec ma demande de certificat, j'ai créé un certificat SSL en double pour webapp1.corp.domain.com
Installé cela dans notre IIS et dans le navigateur, il s'affiche comme SECURE :)