Apache: valider la chaîne de confiance SSL pour empêcher les attaques MITM?

11

Je viens de réaliser que les attaques SSL man-in-the-middle sont beaucoup plus courantes que je ne le pensais, en particulier dans les environnements d'entreprise. J'ai entendu parler et je me suis vu plusieurs entreprises qui ont un serveur proxy SSL transparent en place. Tous les clients sont configurés pour faire confiance au certificat de ce proxy. Cela signifie essentiellement que l'employeur peut théoriquement intercepter même le trafic crypté SSL sans qu'aucun avertissement n'apparaisse dans le navigateur. Comme mentionné ci-dessus, les clients sont livrés avec le certificat de confiance. Cela ne peut être révélé qu'en validant manuellement le certificat utilisé.

Pour moi, il semble que l'employeur utilise sa position supérieure pour espionner le trafic SSL de l'employé. Pour moi, cela rend le concept de SSL indigne de confiance. J'ai moi-même testé avec succès une configuration similaire à l'aide de mitmproxy et j'ai pu lire la communication entre le client et mon serveur de banque électronique. Ce sont des informations qui ne doivent être révélées à personne.

Ainsi, ma question est plutôt simple: comment puis-je valider la chaîne de confiance côté serveur? Je veux m'assurer que le client utilise le certificat de mon serveur et une seule chaîne de confiance. Je me demande si cela peut être réalisé par la configuration SSL d'Apache? Cela serait pratique car il pourrait être facilement appliqué à de nombreuses applications. Si ce n'est pas possible, quelqu'un connaît-il un moyen de le faire en PHP? Ou avez-vous d'autres suggestions?

— Aileron79
source

1

C'est correct si l'employeur voit le trafic des employés. Vous utilisez les ressources de l'employeur (PC, connexions réseau, etc.), ce ne sont pas les vôtres. Et si vous craignez qu'un employé puisse voir les données que vous transmettez à votre compte bancaire - faites-le à la maison, pas au travail. Et les tentatives de violation de la politique de sécurité de l'entreprise peuvent faire l'objet d'un procès contre vous.

— Crypt32

2

Dans de nombreuses entreprises européennes, l'utilisation privée des équipements de bureau est réglementée dans le contrat de travail. Dans l'entreprise où je travaille, je peux surfer en privé, ce n'est pas un problème. Il existe des exceptions comme le porno, le partage de fichiers, etc. En même temps, il existe des lois qui interdisent aux entreprises d'espionner leurs employés. Ainsi, pour moi - et bien d'autres - ce n'est PAS correct lorsque les employeurs interceptent le trafic des employés car cela est clairement interdit alors que le surf privé est toléré dans de nombreuses entreprises.

— Aileron79

2

La plupart (selon mon expérience) des postes de travail appartenant au gouvernement américain incluent ces deux avis à chaque connexion: "Les communications utilisant ou les données stockées sur ce SI ne sont pas privées, sont soumises à une surveillance, une interception et une recherche de routine et peuvent être divulguées ou utilisées pour tout usage autorisé par le gouvernement américain. Ce SI comprend des mesures de sécurité (par exemple, l'authentification et les contrôles d'accès) pour protéger les intérêts du gouvernement américain - pas pour votre avantage personnel ou votre confidentialité. L'utilisation de ces systèmes est souvent couverte par un accord signé le stipulant. Le détail clé est que le propriétaire du système se protège contre vous.

— Randall

C'est l'une des nombreuses différences entre les États-Unis et l'Europe. Les termes @Randall cités ci-dessus sont illégaux dans la plupart des pays européens.

— Aileron79

Les termes que j'ai cités sont incomplets, d'autres termes énumèrent des activités qui ne doivent explicitement pas être surveillées. Je ne trouve aucune référence indiquant que les employeurs européens ne peuvent pas faire de ces conditions préalables une condition d'utilisation de leurs ordinateurs (je travaille pour une entreprise qui opère en Europe, mettant en place de tels processus de surveillance, bien que je travaille pour une division qui ne fait pas d'affaires en Europe), mais peut trouver des références qui suggèrent que de tels termes ne sont pas illégaux tant qu'ils sont explicites et transparents.

— Randall

9

Je pense que cette question serait plus appropriée pour security.stackexchange.com où le sujet du MITM est abordé dans de nombreuses questions. Mais peu importe:

La validation du certificat de serveur ne se fait que sur le client et ne peut pas être déplacée d'une manière ou d'une autre sur le serveur car le point de validation du certificat sur le client est que les clients doivent s'assurer qu'ils parlent au bon serveur et ne peuvent pas faire confiance au serveur (non approuvé) pour prendre cette décision pour le client.

En cas d'interception SSL, le client TLS du point de vue du serveur est le pare-feu / AV d'interception SSL. Ainsi le problème côté serveur est de détecter s'il parle au client attendu (le navigateur) ou non (le pare-feu / AV). La façon la plus sûre de le faire est d'utiliser des certificats clients pour authentifier le client - et en fait, l'interception SSL ne fonctionnera pas si l'authentification client est utilisée, c'est-à-dire que la négociation TLS échouera car le MITM n'est pas en mesure de fournir le certificat client attendu.

Seuls, les certificats clients sont rarement utilisés. En outre, une négociation TLS échouée ne signifie pas que le client peut communiquer avec le serveur sans interception SSL, mais que le client ne peut pas du tout communiquer avec le serveur. Une autre façon serait d'utiliser certaines heuristiques pour détecter le type de client TLS basé sur l'empreinte digitale de la négociation TLS, c'est-à-dire le type et l'ordre des chiffres, l'utilisation d'extensions spécifiques ... Alors qu'un proxy d'interception SSL pourrait en théorie émuler l'original ClientHello parfaitement la plupart ne le font pas. Voir aussi Détecter l'homme du milieu côté serveur pour HTTPS ou la section III Heuristique d'implémentation TLS dans L'impact sur la sécurité de l'interception HTTPS .

— Steffen Ullrich
source

14

Pour moi, il semble que l'employeur utilise sa position supérieure pour espionner le trafic SSL de l'employé. Pour moi, cela rend le concept de SSL indigne de confiance

Le problème ne réside pas dans le concept de SSL ni dans la mise en œuvre technique, mais plutôt que quelqu'un d'autre a le contrôle total sur un point final de la connexion, c'est-à-dire votre poste de travail.
C'est la racine du risque de sécurité réel ...

Du point de vue de la sécurité, c'est votre poste de travail qui est compromis, ce qui rompt la chaîne de confiance qui, dans des circonstances normales, empêche un MITM de réussir.

Comment puis-je valider la chaîne de confiance côté serveur?

Tu ne peux pas. Cela se fait côté client.

Selon votre cas d'utilisation, ce que vous pouvez faire est l' épinglage de clé publique HTTP RFC 7469 dans lequel vous avez envoyé un en-tête supplémentaire au client avec une liste (hachage) de vos certificats SSL réels ou des autorités de certification que vous utilisez.

— HBruijn
source

4

HPKP n'aidera pas car il sera ignoré par les navigateurs si le certificat est signé par une autorité de certification explicitement ajoutée. Ceci est spécifiquement fait pour permettre l'interception SSL par une partie de confiance, c'est-à-dire un pare-feu d'entreprise ou un AV de bureau local (beaucoup le font pour l'interception SSL).

— Steffen Ullrich

2

Vous avez absolument raison: §2.6 du RFC: "Il est acceptable d'autoriser la désactivation de la validation des broches pour certains hôtes conformément à la politique locale. Par exemple, un agent d'utilisateur peut désactiver la validation des broches pour les hôtes épinglés dont la chaîne de certificats validée se termine à une ancre de confiance définie par l'utilisateur, plutôt qu'une ancre de confiance intégrée à l'UA (ou à la plate-forme sous-jacente). "

— HBruijn

3

C'est la mauvaise façon. Pas le serveur vérifie la chaîne de confiance. C'est le client. Ainsi, la raison pour laquelle l'entreprise utilise cette méthode est de sécuriser l'environnement de l'entreprise et de vérifier ce que l'employé fait pendant son temps de travail.

— beli3ver
source

Eh bien, oui, je suis conscient que cela ne peut probablement pas être évité uniquement côté serveur. Cependant, certains JS côté client peuvent également être trompés. BTW, Espionner les employés est illégal dans la plupart des pays européens. En tant qu'opérateur de site Web, je veux éviter que mes clients ne soient dupes, je me demande donc s'il existe un moyen de valider la chaîne de confiance de manière sûre.

— Aileron79

Peut-être que ce n'est pas permis. Mais la plupart des entreprises n'espionnent pas les employés qui souhaitent uniquement sécuriser le réseau de leur entreprise, et la plupart des filtres Web ou des scanners doivent interrompre la connexion SSL pour vérifier cela. C'est donc un homme légal dans l'attaque du milieu

— beli3ver

Je comprends votre point. Cependant, cette question concerne la façon dont je peux m'assurer qu'une connexion HTTPS est chiffrée de bout en bout. La configuration que j'ai décrite ci-dessus est très courante dans les environnements d'entreprise, mais le même type d'attaque peut être utilisé par des garçons jaloux pour espionner leurs copines ou par des propriétaires interceptant le trafic de leurs locataires. Ces personnes doivent encore être incitées à installer un certificat, mais c'est la partie facile. Cependant, c'est illégal - et je me demande toujours s'il existe un moyen de garantir qu'une connexion HTTPS est vraiment cryptée e2e.

— Aileron79

3

Ce n'est pas possible. Lorsque le certificat racine a été modifié sur le client, vous n'avez aucun moyen de le vérifier. Le serveur n'effectue pas la vérification, le client effectue la vérification.

— beli3ver

3

Vous POURRIEZ (en quelque sorte), mais la vraie question est de savoir si vous DEVEZ .

Mais attention, ce n'est nulle part aussi simple que de changer un drapeau dans apache.conf.

De plus, comme «l'attaquant» (par exemple, l'employeur) contrôle l'ordinateur client, il peut toujours déjouer vos tentatives s'il est enclin à investir suffisamment d'efforts (du bon côté, à moins que vous ne soyez de très gros poissons, ils ne le sont probablement pas incliné, de sorte que vous atteindrez votre objectif que vos utilisateurs ne pourront pas vous connecter à moins qu'il ne soit sécurisé))

vous pouvez réimplémenter TLS en javascript , et vérifier si le certificat auquel le client est connecté est le certificat de votre site Web.
si vous êtes chanceux , l'utilisateur peut utiliser un navigateur où Javascript côté client peut obtenir des informations sur le certificat distant utilisé (et ainsi le vérifier facilement par rapport à la valeur codée en dur du certificat de votre serveur).
vous pouvez utiliser JavaScript pour exécuter votre cryptage personnalisé . Ainsi, même lorsque le mal TLS MiTM de l'entreprise a réussi, il ne lui donnerait toujours pas accès à vos données. Bien sûr, s'ils sont suffisamment intéressés (et comme ils contrôlent le client), ils pourraient simplement remplacer à la volée votre javascript sécurisé par le leur qui enregistre (ou modifie) également toutes les informations en transit.

De plus, étant donné que les entreprises qui utilisent des proxys TLS MiTM contrôlent également complètement l'ordinateur client, elles pourraient tout aussi facilement installer l'écran et le keylogger pour enregistrer simplement la vidéo de tout ce que l'utilisateur voit et enregistrer toutes les frappes (et mouvements de souris) que l'utilisateur tape. Comme vous pouvez le voir, lorsque l'attaquant EST le client, il n'y a aucun moyen absolument sûr de le tromper. C'est vraiment juste une question combien vont-ils déranger ... Et certaines des solutions ci-dessus pourraient être assez bonnes pour vous.

— Matija Nalis
source

" vous pouvez réimplémenter TLS en javascript " Comment? Où?

— curiousguy

@curiousguy que le texte qouted est un lien - cliquez dessus, et il vous mènera à une autre question et réponse, et enfin au projet digitalbazaar / Forge

— Matija Nalis

Alors, quand est-il utilisable? Dans quel but?

— curiousguy

@curiousguy parmi beaucoup d'autres choses, en particulier aux fins posées dans cette question Serverfault. Lorsque vous avez votre propre JS TLS en cours d'exécution sur le client, ce client JS saura exactement à quel serveur TLS le client a été connecté (et sa clé publique). Ensuite, vous pouvez comparer cette clé publique avec la clé publique du serveur autorisé (également codée en dur dans votre JS), et si vous saurez si elles sont identiques. S'ils ne sont pas identiques, votre connexion a été détournée par MiTM.

— Matija Nalis