9. Considérations de sécurité

Considérations de sécurité

Afin de rendre l'ensemble des considérations de sécurité plus accessible, les considérations de sécurité pour les documents de transport, d'authentification et de connexion ont été rassemblées ici.

Le protocole de transport [SSH-TRANS] fournit un canal confidentiel sur un réseau non sécurisé. Il effectue l'authentification de l'hôte serveur, l'échange de clés, le chiffrement et la protection d'intégrité. Il dérive également un identifiant de session unique qui peut être utilisé par les protocoles de niveau supérieur.

Le protocole d'authentification [SSH-USERAUTH] fournit une suite de mécanismes qui peuvent être utilisés pour authentifier l'utilisateur client auprès du serveur. Les mécanismes individuels spécifiés dans le protocole d'authentification utilisent l'identifiant de session fourni par le protocole de transport et/ou dépendent des garanties de sécurité et d'intégrité du protocole de transport.

Le protocole de connexion [SSH-CONNECT] spécifie un mécanisme pour multiplexer plusieurs flux de données (canaux) sur le transport confidentiel et authentifié. Il spécifie également des canaux pour accéder à un shell interactif, pour le proxy-forwarding de divers protocoles externes sur le transport sécurisé (y compris les protocoles TCP/IP arbitraires), et pour accéder aux sous-systèmes sécurisés sur l'hôte serveur.

9.1. Génération de nombres pseudo-aléatoires

Ce protocole lie chaque clé de session à la session en incluant des données aléatoires spécifiques à la session dans le hachage utilisé pour produire les clés de session. Un soin particulier doit être pris pour garantir que tous les nombres aléatoires sont de bonne qualité. Si les données aléatoires ici (par exemple, les paramètres Diffie-Hellman (DH)) sont pseudo-aléatoires, alors le générateur de nombres pseudo-aléatoires doit être cryptographiquement sûr (c'est-à-dire que sa prochaine sortie n'est pas facilement devinable même en connaissant toutes les sorties précédentes) et, en outre, une entropie appropriée doit être ajoutée au générateur de nombres pseudo-aléatoires. [RFC4086] offre des suggestions pour les sources de nombres aléatoires et d'entropie. Les implémenteurs doivent noter l'importance de l'entropie et l'avertissement anecdotique bien intentionné sur la difficulté de mettre en œuvre correctement les fonctions de génération de nombres pseudo-aléatoires.

La quantité d'entropie disponible pour un client ou un serveur donné peut parfois être inférieure à ce qui est requis. Dans ce cas, on doit soit recourir à la génération de nombres pseudo-aléatoires malgré une entropie insuffisante, soit refuser d'exécuter le protocole. Cette dernière option est préférable.

9.2. Filtrage des caractères de contrôle

Lors de l'affichage de texte à un utilisateur, tel que des messages d'erreur ou de débogage, le logiciel client DOIT remplacer tous les caractères de contrôle (sauf la tabulation, le retour chariot et la nouvelle ligne) par des séquences sûres pour éviter les attaques en envoyant des caractères de contrôle de terminal.

9.3. Transport

9.3.1. Confidentialité

Il est au-delà de la portée de ce document et du groupe de travail Secure Shell d'analyser ou de recommander des chiffrements spécifiques autres que ceux qui ont été établis et acceptés dans l'industrie. Au moment de la rédaction de ce document, les chiffrements couramment utilisés incluent 3DES, ARCFOUR, twofish, serpent et blowfish. AES a été publié par les Federal Information Processing Standards des États-Unis sous [FIPS-197], et la communauté cryptographique a également accepté AES. Comme toujours, les implémenteurs et les utilisateurs doivent vérifier la littérature actuelle pour s'assurer qu'aucune vulnérabilité récente n'a été trouvée dans les chiffrements utilisés dans les produits. Les implémenteurs doivent également vérifier quels chiffrements sont considérés comme relativement plus forts que d'autres et doivent recommander leur utilisation aux utilisateurs par rapport aux chiffrements relativement plus faibles. Il serait considéré de bonne forme pour une implémentation d'informer poliment et discrètement un utilisateur qu'un chiffrement plus fort est disponible et devrait être utilisé lorsqu'un chiffrement plus faible est activement choisi.

Le chiffrement "none" est fourni pour le débogage et NE DOIT PAS être utilisé sauf à cette fin. Ses propriétés cryptographiques sont suffisamment décrites dans [RFC2410], qui montrera que son utilisation ne répond pas à l'intention de ce protocole.

Les mérites relatifs de ces chiffrements et d'autres peuvent également être trouvés dans la littérature actuelle. Deux références qui peuvent fournir des informations sur le sujet sont [SCHNEIER] et [KAUFMAN]. Les deux décrivent le mode d'opération CBC de certains chiffrements et la faiblesse de ce schéma. Essentiellement, ce mode est théoriquement vulnérable aux attaques par texte chiffré choisi en raison de la haute prévisibilité du début de la séquence de paquets. Cependant, cette attaque est jugée difficile et non considérée comme entièrement praticable, surtout si des tailles de bloc relativement grandes sont utilisées.

De plus, une autre attaque du mode CBC peut être atténuée par l'insertion de paquets contenant SSH_MSG_IGNORE. Sans cette technique, une attaque spécifique peut réussir. Pour que cette attaque (communément appelée attaque Rogaway [ROGAWAY], [DAI], [BELLARE]) fonctionne, l'attaquant devrait connaître le vecteur d'initialisation (IV) du bloc suivant qui va être chiffré. En mode CBC, c'est la sortie du chiffrement du bloc précédent. Si l'attaquant n'a aucun moyen de voir le paquet encore (c'est-à-dire qu'il est dans les tampons internes de l'implémentation SSH ou même dans le noyau), alors cette attaque ne fonctionnera pas. Si le dernier paquet a été envoyé sur le réseau (c'est-à-dire que l'attaquant y a accès), alors il peut utiliser l'attaque.

Dans le cas optimal, un implémenteur n'aurait besoin d'ajouter un paquet supplémentaire que si le paquet a été envoyé sur le réseau et qu'il n'y a pas d'autres paquets en attente de transmission. Les implémenteurs peuvent souhaiter vérifier s'il y a des paquets non envoyés en attente de transmission; malheureusement, il n'est normalement pas facile d'obtenir cette information du noyau ou des tampons. S'il n'y a pas de paquets non envoyés, alors un paquet contenant SSH_MSG_IGNORE DOIT être envoyé. Si un nouveau paquet est ajouté au flux chaque fois que l'attaquant connaît l'IV qui est censé être utilisé pour le paquet suivant, alors l'attaquant ne pourra pas deviner le bon IV, donc l'attaque ne réussira jamais.

À titre d'exemple, considérez le cas suivant:

Client Serveur

TCP(seq=x, len=500) ----> contient Record 1

[500 ms passent, pas d'ACK]

TCP(seq=x, len=1000) ----> contient Records 1,2

ACK

L'algorithme de Nagle + les retransmissions TCP signifient que les deux enregistrements sont fusionnés en un seul segment TCP.
Record 2 n'est pas au début du segment TCP et ne le sera jamais parce qu'il reçoit un ACK.
Pourtant, l'attaque est possible parce que Record 1 a déjà été vu.

Comme cet exemple l'indique, il est dangereux d'utiliser l'existence de données non vidées dans les tampons TCP proprement dits comme guide pour savoir si un paquet vide est nécessaire, car lorsque le deuxième write() est effectué, les tampons contiendront le Record 1 non-ACKé.

D'autre part, il est parfaitement sûr d'avoir la situation suivante:

Client Serveur

TCP(seq=x, len=500) ----> contient SSH_MSG_IGNORE

TCP(seq=y, len=500) ----> contient Data

À condition que l'IV pour le deuxième enregistrement SSH soit fixé après que les données pour le paquet Data sont déterminées, alors les opérations suivantes doivent être effectuées:

lire depuis l'utilisateur chiffrer le paquet nul chiffrer le paquet de données

9.3.2. Intégrité des données

Ce protocole permet de désactiver le mécanisme d'intégrité des données. Les implémenteurs DOIVENT se méfier d'exposer cette fonctionnalité à toute fin autre que le débogage. Les utilisateurs et les administrateurs DOIVENT être explicitement avertis chaque fois que le MAC "none" est activé.

Tant que le MAC "none" n'est pas utilisé, ce protocole fournit l'intégrité des données.

Parce que les MAC utilisent un numéro de séquence 32 bits, ils pourraient commencer à fuir des informations après l'envoi de 232 paquets. Cependant, suivre les recommandations de renouvellement de clés devrait empêcher cette attaque. Le protocole de transport [SSH-TRANS] recommande le renouvellement de clés après un gigaoctet de données, et le plus petit paquet possible est de 16 octets. Par conséquent, le renouvellement de clés DOIT se produire après 228 paquets au maximum.

9.3.3. Rejeu

L'utilisation d'un MAC autre que "none" fournit l'intégrité et l'authentification. De plus, le protocole de transport fournit un identifiant de session unique (lié en partie à des données pseudo-aléatoires qui font partie du processus d'algorithme et d'échange de clés) qui peut être utilisé par les protocoles de niveau supérieur pour lier les données à une session donnée et empêcher le rejeu de données de sessions antérieures. Par exemple, le protocole d'authentification ([SSH-USERAUTH]) utilise cela pour empêcher le rejeu de signatures de sessions précédentes. Parce que les échanges d'authentification par clé publique sont cryptographiquement liés à la session (c'est-à-dire à l'échange de clés initial), ils ne peuvent pas être rejoués avec succès dans d'autres sessions. Notez que l'identifiant de session peut être rendu public sans nuire à la sécurité du protocole.

Si deux sessions ont le même identifiant de session (hachage des échanges de clés), alors les paquets de l'une peuvent être rejoués contre l'autre. Il faut souligner que les chances d'une telle occurrence sont, inutile de le dire, minimales lors de l'utilisation de méthodes cryptographiques modernes. Cela est d'autant plus vrai lors de la spécification de sorties de fonction de hachage plus grandes et de paramètres DH.

La détection de rejeu utilisant des numéros de séquence monotones croissants comme entrée du MAC, ou HMAC dans certains cas, est décrite dans [RFC2085], [RFC2246], [RFC2743], [RFC1964], [RFC2025] et [RFC4120]. La construction sous-jacente est discutée dans [RFC2104]. Essentiellement, un numéro de séquence différent dans chaque paquet garantit qu'au moins cette entrée de la fonction MAC sera unique et fournira une sortie MAC non récurrente qui n'est pas prévisible par un attaquant. Si la session reste active assez longtemps, cependant, ce numéro de séquence bouclera. Cet événement peut fournir à un attaquant une opportunité de rejouer un paquet précédemment enregistré avec un numéro de séquence identique, mais seulement si les pairs n'ont pas renouvelé leurs clés depuis la transmission du premier paquet avec ce numéro de séquence. Si les pairs ont renouvelé leurs clés, alors le rejeu sera détecté car la vérification MAC échouera. Pour cette raison, il faut souligner que les pairs DOIVENT renouveler leurs clés avant un bouclage des numéros de séquence. Naturellement, si un attaquant tente de rejouer un paquet capturé avant que les pairs n'aient renouvelé leurs clés, alors le destinataire du paquet en double ne pourra pas valider le MAC et il sera rejeté. La raison pour laquelle le MAC échouera est que le destinataire formulera un MAC basé sur le contenu du paquet, le secret partagé et le numéro de séquence attendu. Puisque le paquet rejoué n'utilisera pas ce numéro de séquence attendu (le numéro de séquence du paquet rejoué aura déjà été passé par le destinataire), le MAC calculé ne correspondra pas au MAC reçu avec le paquet.

9.3.4. Homme du milieu

Ce protocole ne fait aucune hypothèse ni ne prévoit d'infrastructure ou de moyen pour distribuer les clés publiques des hôtes. On s'attend à ce que ce protocole soit parfois utilisé sans vérifier d'abord l'association entre la clé d'hôte du serveur et le nom d'hôte du serveur. Une telle utilisation est vulnérable aux attaques de l'homme du milieu. Cette section décrit cela et encourage les administrateurs et les utilisateurs à comprendre l'importance de vérifier cette association avant le démarrage de toute session.

Il y a trois cas d'attaques de l'homme du milieu à considérer. Le premier est celui où un attaquant place un dispositif entre le client et le serveur avant le démarrage de la session. Dans ce cas, le dispositif d'attaque tente de se faire passer pour le serveur légitime et offrira sa clé publique au client lorsque le client démarre une session. S'il devait offrir la clé publique du serveur, alors il ne pourrait pas déchiffrer ou signer les transmissions entre le serveur légitime et le client à moins qu'il n'ait également accès à la clé privée de l'hôte. Le dispositif d'attaque lancera également, simultanément à cela, une session vers le serveur légitime, se faisant passer pour le client. Si la clé publique du serveur avait été distribuée en toute sécurité au client avant le démarrage de cette session, la clé offerte au client par le dispositif d'attaque ne correspondra pas à la clé stockée sur le client. Dans ce cas, l'utilisateur DOIT recevoir un avertissement que la clé d'hôte offerte ne correspond pas à la clé d'hôte mise en cache sur le client. Comme décrit dans la section 4.1, l'utilisateur peut être libre d'accepter la nouvelle clé et de continuer la session. Il est RECOMMANDÉ que l'avertissement fournisse suffisamment d'informations à l'utilisateur du dispositif client pour que l'utilisateur puisse prendre une décision éclairée. Si l'utilisateur choisit de continuer la session avec la clé publique stockée du serveur (et non la clé publique offerte au début de la session), alors les données spécifiques à la session entre l'attaquant et le serveur seront différentes entre la session client-attaquant et les sessions attaquant-serveur en raison de l'aléatoire discuté ci-dessus. De ce fait, l'attaquant ne pourra pas faire fonctionner cette attaque car l'attaquant ne pourra pas signer correctement les paquets contenant ces données spécifiques à la session du serveur, car il n'a pas la clé privée de ce serveur.

Le deuxième cas qui devrait être considéré est similaire au premier cas en ce sens qu'il se produit également au moment de la connexion, mais ce cas souligne la nécessité d'une distribution sécurisée des clés publiques du serveur. Si les clés publiques du serveur ne sont pas distribuées en toute sécurité, alors le client ne peut pas savoir s'il parle au serveur prévu. Un attaquant peut utiliser des techniques d'ingénierie sociale pour transmettre des clés de serveur à des utilisateurs sans méfiance et peut ensuite placer un dispositif d'attaque de l'homme du milieu entre le serveur légitime et les clients. Si cela est autorisé, alors les clients formeront des sessions client-attaquant, et l'attaquant formera des sessions attaquant-serveur et pourra surveiller et manipuler tout le trafic entre les clients et les serveurs légitimes. Les administrateurs de serveur sont encouragés à rendre disponibles les empreintes de clé d'hôte pour vérification par des moyens dont la sécurité ne dépend pas de l'intégrité des clés d'hôte réelles. Les mécanismes possibles sont discutés dans la section 4.1 et peuvent également inclure des pages Web sécurisées, des morceaux de papier physiques, etc. Les implémenteurs DOIVENT fournir des recommandations sur la meilleure façon de le faire avec leur implémentation. Parce que le protocole est extensible, les extensions futures du protocole peuvent fournir de meilleurs mécanismes pour gérer la nécessité de connaître la clé d'hôte du serveur avant la connexion. Par exemple, rendre l'empreinte de la clé d'hôte disponible via une recherche DNS sécurisée, ou utiliser Kerberos ([RFC4120]) sur GSS-API ([RFC1964]) pendant l'échange de clés pour authentifier le serveur sont des possibilités.

Dans le troisième cas d'homme du milieu, les attaquants peuvent tenter de manipuler les paquets en transit entre pairs après que la session ait été établie. Comme décrit dans la section 9.3.3, une attaque réussie de cette nature est très improbable. Comme dans la section 9.3.3, ce raisonnement suppose que le MAC est sûr et qu'il est infaisable de construire des entrées à un algorithme MAC pour donner une sortie connue. Ceci est discuté en beaucoup plus de détails dans la section 6 de [RFC2104]. Si l'algorithme MAC a une vulnérabilité ou est assez faible, alors l'attaquant peut être capable de spécifier certaines entrées pour produire un MAC connu. Avec cela, ils peuvent être capables d'altérer le contenu d'un paquet en transit. Alternativement, l'attaquant peut être capable d'exploiter la vulnérabilité ou la faiblesse de l'algorithme pour trouver le secret partagé en examinant les MAC des paquets capturés. Dans l'un ou l'autre de ces cas, un attaquant pourrait construire un ou plusieurs paquets qui pourraient être insérés dans un flux SSH. Pour empêcher cela, les implémenteurs sont encouragés à utiliser des algorithmes MAC couramment acceptés, et les administrateurs sont encouragés à surveiller la littérature actuelle et les discussions sur la cryptographie pour s'assurer qu'ils n'utilisent pas un algorithme MAC qui a une vulnérabilité ou une faiblesse récemment découverte.

En résumé, l'utilisation de ce protocole sans une association fiable de la liaison entre un hôte et ses clés d'hôte est intrinsèquement non sécurisée et N'EST PAS RECOMMANDÉE. Cependant, cela peut être nécessaire dans des environnements non critiques pour la sécurité, et fournira toujours une protection contre les attaques passives. Les implémenteurs de protocoles et d'applications fonctionnant au-dessus de ce protocole devraient garder cette possibilité à l'esprit.

9.3.5. Déni de service

Ce protocole est conçu pour être utilisé sur un transport fiable. Si des erreurs de transmission ou une manipulation de messages se produisent, la connexion est fermée. La connexion DOIT être rétablie si cela se produit. Les attaques par déni de service de ce type (coupeur de fil) sont presque impossibles à éviter.

De plus, ce protocole est vulnérable aux attaques par déni de service car un attaquant peut forcer le serveur à effectuer les tâches intensives en CPU et en mémoire de l'établissement de connexion et de l'échange de clés sans authentification. Les implémenteurs DOIVENT fournir des fonctionnalités qui rendent cela plus difficile, par exemple, en permettant uniquement les connexions d'un sous-ensemble de clients connus pour avoir des utilisateurs valides.

9.3.6. Canaux cachés

Le protocole n'a pas été conçu pour éliminer les canaux cachés. Par exemple, le remplissage, les messages SSH_MSG_IGNORE et plusieurs autres endroits dans le protocole peuvent être utilisés pour passer des informations cachées, et le destinataire n'a aucun moyen fiable de vérifier si de telles informations sont envoyées.

9.3.7. Confidentialité persistante

Il convient de noter que les échanges de clés Diffie-Hellman peuvent fournir une confidentialité persistante parfaite (PFS). Le PFS est essentiellement défini comme la propriété cryptographique d'un protocole d'établissement de clé dans lequel le compromis d'une clé de session ou d'une clé privée à long terme après une session donnée ne cause pas le compromis d'aucune session antérieure [ANSI-T1.523-2001]. Les sessions SSH résultant d'un échange de clés utilisant les méthodes diffie-hellman décrites dans la section Échange de clés Diffie-Hellman de [SSH-TRANS] (y compris "diffie-hellman-group1-sha1" et "diffie-hellman-group14-sha1") sont sécurisées même si le matériel de chiffrement/authentification privé est révélé ultérieurement, mais pas si les clés de session sont révélées. Donc, compte tenu de cette définition de PFS, SSH a PFS. Cependant, cette propriété n'est pas transmise à aucune des applications ou protocoles utilisant SSH comme transport. La couche de transport de SSH fournit la confidentialité pour l'authentification par mot de passe et d'autres méthodes qui reposent sur des données secrètes.

Bien sûr, si les paramètres privés DH pour le client et le serveur sont révélés, alors la clé de session est révélée, mais ces éléments peuvent être jetés après la fin de l'échange de clés. Il vaut la peine de souligner que ces éléments ne doivent pas être autorisés à se retrouver dans l'espace d'échange et qu'ils doivent être effacés de la mémoire dès que l'échange de clés est terminé.

9.3.8. Ordre des méthodes d'échange de clés

Comme indiqué dans la section sur la négociation d'algorithmes de [SSH-TRANS], chaque dispositif enverra une liste de méthodes d'échange de clés préférées. La méthode la plus préférée est la première de la liste. Il est RECOMMANDÉ que les algorithmes soient triés par force cryptographique, le plus fort en premier. Des conseils supplémentaires à ce sujet sont donnés dans [RFC3766].

9.3.9. Analyse du trafic

La surveillance passive de tout protocole peut donner à un attaquant des informations sur la session, l'utilisateur ou des informations spécifiques au protocole qu'il ne pourrait pas obtenir autrement. Par exemple, il a été démontré que l'analyse du trafic d'une session SSH peut donner des informations sur la longueur du mot de passe - [Openwall] et [USENIX]. Les implémenteurs doivent utiliser le paquet SSH_MSG_IGNORE, ainsi que l'inclusion de longueurs aléatoires de remplissage, pour contrecarrer les tentatives d'analyse du trafic. D'autres méthodes peuvent également être trouvées et mises en œuvre.

9.4. Protocole d'authentification

Le but de ce protocole est d'effectuer l'authentification de l'utilisateur client. Il suppose que cela fonctionne sur un protocole de couche de transport sécurisé, qui a déjà authentifié la machine serveur, établi un canal de communication chiffré et calculé un identifiant de session unique pour cette session.

Plusieurs méthodes d'authentification avec des caractéristiques de sécurité différentes sont autorisées. C'est à la politique locale du serveur de décider quelles méthodes (ou combinaisons de méthodes) il est disposé à accepter pour chaque utilisateur. L'authentification n'est pas plus forte que la combinaison la plus faible autorisée.

Le serveur peut entrer dans une période de sommeil après des tentatives d'authentification infructueuses répétées pour rendre la recherche de clés plus difficile pour les attaquants. Il faut veiller à ce que cela ne devienne pas un vecteur d'auto-déni de service.

9.4.1. Transport faible

Si la couche de transport ne fournit pas de confidentialité, les méthodes d'authentification qui reposent sur des données secrètes DOIVENT être désactivées. Si elle ne fournit pas une protection d'intégrité forte, les demandes de modification des données d'authentification (par exemple, un changement de mot de passe) DOIVENT être désactivées pour empêcher un attaquant de modifier le texte chiffré sans être remarqué, ou de rendre les nouvelles données d'authentification inutilisables (déni de service).

L'hypothèse énoncée ci-dessus, selon laquelle le protocole d'authentification ne s'exécute que sur un transport sécurisé qui a préalablement authentifié le serveur, est très importante à noter. Les personnes déployant SSH sont rappelées des conséquences des attaques de l'homme du milieu si le client n'a pas une très forte association a priori du serveur avec la clé d'hôte de ce serveur. Spécifiquement, pour le cas du protocole d'authentification, le client peut former une session avec un dispositif d'attaque de l'homme du milieu et divulguer des informations d'identification utilisateur telles que leur nom d'utilisateur et mot de passe. Même dans les cas d'authentification où aucune information d'identification utilisateur n'est divulguée, un attaquant peut toujours obtenir des informations qu'il ne devrait pas avoir en capturant des frappes de touches de la même manière qu'un pot de miel fonctionne.

9.4.2. Messages de débogage

Un soin particulier doit être pris lors de la conception des messages de débogage. Ces messages peuvent révéler des quantités surprenantes d'informations sur l'hôte s'ils ne sont pas correctement conçus. Les messages de débogage peuvent être désactivés (pendant la phase d'authentification de l'utilisateur) si une sécurité élevée est requise. Les administrateurs de machines hôtes devraient faire tout leur possible pour compartimenter tous les messages de notification d'événements et les protéger d'une observation non justifiée. Les développeurs doivent être conscients de la nature sensible de certains messages d'événement et de débogage normaux, et peuvent vouloir fournir des conseils aux administrateurs sur les moyens de garder ces informations loin des personnes non autorisées. Les développeurs doivent envisager de minimiser la quantité d'informations sensibles obtenues par les utilisateurs pendant la phase d'authentification, conformément aux politiques locales. Pour cette raison, il est RECOMMANDÉ que les messages de débogage soient initialement désactivés au moment du déploiement et nécessitent une décision active d'un administrateur pour permettre leur activation. Il est également RECOMMANDÉ qu'un message exprimant cette préoccupation soit présenté à l'administrateur d'un système lorsque l'action est prise pour activer les messages de débogage.

9.4.3. Politique de sécurité locale

L'implémenteur DOIT s'assurer que les informations d'identification fournies valident l'utilisateur professé et DOIT également s'assurer que la politique locale du serveur permet à l'utilisateur l'accès demandé. En particulier, en raison de la nature flexible du protocole de connexion SSH, il peut ne pas être possible de déterminer la politique de sécurité locale, le cas échéant, qui devrait s'appliquer au moment de l'authentification car le type de service demandé n'est pas clair à ce moment. Par exemple, la politique locale peut permettre à un utilisateur d'accéder aux fichiers sur le serveur, mais pas de démarrer un shell interactif. Cependant, pendant le protocole d'authentification, on ne sait pas si l'utilisateur accédera aux fichiers, tentera d'utiliser un shell interactif, ou même les deux. En tout état de cause, lorsqu'une politique de sécurité locale pour l'hôte serveur existe, elle DOIT être appliquée et mise en œuvre correctement.

Les implémenteurs sont encouragés à fournir une politique locale par défaut et à faire connaître ses paramètres aux administrateurs et aux utilisateurs. À la discrétion des implémenteurs, cette politique par défaut peut être dans le sens de tout est permis où il n'y a pas de restrictions placées sur les utilisateurs, ou elle peut être dans le sens d'excessivement-restrictive, auquel cas, les administrateurs devront activement apporter des modifications aux paramètres par défaut initiaux pour répondre à leurs besoins. Alternativement, elle peut être une tentative de fournir quelque chose de pratique et immédiatement utile aux administrateurs du système afin qu'ils n'aient pas à mettre beaucoup d'efforts pour faire fonctionner SSH. Quel que soit le choix fait, il doit être appliqué et mis en œuvre comme requis ci-dessus.

9.4.4 Authentification par clé publique

L'utilisation de l'authentification par clé publique suppose que l'hôte client n'a pas été compromis. Elle suppose également que la clé privée de l'hôte serveur n'a pas été compromise.

Ce risque peut être atténué par l'utilisation de phrases de passe sur les clés privées; cependant, ce n'est pas une politique exécutoire. L'utilisation de cartes à puce, ou d'autre technologie pour rendre les phrases de passe une politique exécutoire est suggérée.

Le serveur pourrait exiger à la fois l'authentification par mot de passe et par clé publique; cependant, cela nécessite que le client expose son mot de passe au serveur (voir la section sur l'authentification par mot de passe ci-dessous.)

9.4.5. Authentification par mot de passe

Le mécanisme de mot de passe, tel que spécifié dans le protocole d'authentification, suppose que le serveur n'a pas été compromis. Si le serveur a été compromis, l'utilisation de l'authentification par mot de passe révélera une combinaison nom d'utilisateur/mot de passe valide à l'attaquant, ce qui peut conduire à d'autres compromissions.

Cette vulnérabilité peut être atténuée en utilisant une forme alternative d'authentification. Par exemple, l'authentification par clé publique ne fait aucune hypothèse sur la sécurité du serveur.

9.4.6. Authentification basée sur l'hôte

L'authentification basée sur l'hôte suppose que le client n'a pas été compromis. Il n'y a pas de stratégies d'atténuation, autres que d'utiliser l'authentification basée sur l'hôte en combinaison avec une autre méthode d'authentification.

9.5. Protocole de connexion

9.5.1. Sécurité des points d'extrémité

La sécurité des points d'extrémité est supposée par le protocole de connexion. Si le serveur a été compromis, toutes les sessions terminales, le forwarding de ports ou les systèmes accédés sur l'hôte sont compromis. Il n'y a pas de facteurs atténuants pour cela.

Si le client a été compromis, et que le serveur ne parvient pas à arrêter l'attaquant au niveau du protocole d'authentification, tous les services exposés (soit en tant que sous-systèmes ou par forwarding) seront vulnérables à l'attaque. Les implémenteurs DOIVENT fournir des mécanismes permettant aux administrateurs de contrôler quels services sont exposés pour limiter la vulnérabilité des autres services. Ces contrôles pourraient inclure le contrôle des machines et des ports qui peuvent être ciblés dans les opérations de forwarding de ports, quels utilisateurs sont autorisés à utiliser les facilités de shell interactif, ou quels utilisateurs sont autorisés à utiliser les sous-systèmes exposés.

9.5.2. Forwarding de proxy

Le protocole de connexion SSH permet le forwarding de proxy d'autres protocoles tels que SMTP, POP3 et HTTP. Cela peut être une préoccupation pour les administrateurs réseau qui souhaitent contrôler l'accès de certaines applications par les utilisateurs situés en dehors de leur emplacement physique. Essentiellement, le forwarding de ces protocoles peut violer les politiques de sécurité spécifiques au site, car ils peuvent être tunnelés de manière indétectable à travers un pare-feu. Les implémenteurs DOIVENT fournir un mécanisme administratif pour contrôler la fonctionnalité de forwarding de proxy afin que les politiques de sécurité spécifiques au site puissent être respectées.

De plus, une fonctionnalité de forwarding de proxy inverse est disponible, qui, encore une fois, peut être utilisée pour contourner les contrôles de pare-feu.

Comme indiqué ci-dessus, la sécurité des points d'extrémité est supposée pendant les opérations de forwarding de proxy. L'échec de la sécurité des points d'extrémité compromettra toutes les données passées par le forwarding de proxy.

9.5.3. Forwarding X11

Une autre forme de forwarding de proxy fournie par le protocole de connexion SSH est le forwarding du protocole X11. Si la sécurité des points d'extrémité a été compromise, le forwarding X11 peut permettre des attaques contre le serveur X11. Les utilisateurs et les administrateurs devraient, par habitude, utiliser les mécanismes de sécurité X11 appropriés pour empêcher l'utilisation non autorisée du serveur X11. Les implémenteurs, administrateurs et utilisateurs qui souhaitent explorer davantage les mécanismes de sécurité de X11 sont invités à lire [SCHEIFLER] et à analyser les problèmes précédemment signalés avec les interactions entre le forwarding SSH et X11 dans les vulnérabilités CERT VU#363181 et VU#118892 [CERT].

Le forwarding d'affichage X11 avec SSH, en soi, n'est pas suffisant pour corriger les problèmes bien connus avec la sécurité X11 [VENEMA]. Cependant, le forwarding d'affichage X11 dans SSH (ou d'autres protocoles sécurisés), combiné avec des affichages réels et pseudo qui n'acceptent les connexions que sur des mécanismes IPC locaux autorisés par des permissions ou des listes de contrôle d'accès (ACL), corrige effectivement de nombreux problèmes de sécurité X11, tant que le MAC "none" n'est pas utilisé. Il est RECOMMANDÉ que les implémentations d'affichage X11 permettent par défaut à l'affichage de s'ouvrir uniquement sur IPC local. Il est RECOMMANDÉ que les implémentations de serveur SSH qui prennent en charge le forwarding X11 permettent par défaut à l'affichage de s'ouvrir uniquement sur IPC local. Sur les systèmes mono-utilisateur, il peut être raisonnable de permettre par défaut à l'affichage local de s'ouvrir sur TCP/IP.

Les implémenteurs du protocole de forwarding X11 DOIVENT implémenter le mécanisme de spoofing de vérification d'accès par cookie magique, tel que décrit dans [SSH-CONNECT], comme mécanisme supplémentaire pour empêcher l'utilisation non autorisée du proxy.