| Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente |
| issue95:securite [2015/04/26 13:21] – [10] d52fr | issue95:securite [2015/04/28 14:56] (Version actuelle) – andre_domenech |
|---|
| In the early days, if you wanted to log on to a remote computer to do some work, you would probably use a program called Telnet to do this. Telnet would let you log in to a remote Unix machine if you had an account on it, and, once logged in, you could do anything your account was authorized to do. And if you had root access, it could be just about anything. I recall my first introduction to this in the 1990s when I was managing the website of my university. I was given a shell account on our Red Hat server that also housed the web site, and sternly warned not to do anything to screw it up. I would Telnet into the server from my desktop to do things like chmod the CGI scripts and similar things we needed to do with websites in those days. This worked reasonably well, but the problem with Telnet is that it was never designed to create a secure connection, and since this server had our Website, it was perforce exposed to the whole Internet. If you combine an unsecure connection with a man-in-the-middle attack, or with vulnerabilities in the Telnet program that allowed an attacker to get in, and even escalate their privileges, you can see why this became an issue.** | In the early days, if you wanted to log on to a remote computer to do some work, you would probably use a program called Telnet to do this. Telnet would let you log in to a remote Unix machine if you had an account on it, and, once logged in, you could do anything your account was authorized to do. And if you had root access, it could be just about anything. I recall my first introduction to this in the 1990s when I was managing the website of my university. I was given a shell account on our Red Hat server that also housed the web site, and sternly warned not to do anything to screw it up. I would Telnet into the server from my desktop to do things like chmod the CGI scripts and similar things we needed to do with websites in those days. This worked reasonably well, but the problem with Telnet is that it was never designed to create a secure connection, and since this server had our Website, it was perforce exposed to the whole Internet. If you combine an unsecure connection with a man-in-the-middle attack, or with vulnerabilities in the Telnet program that allowed an attacker to get in, and even escalate their privileges, you can see why this became an issue.** |
| |
| Une des choses les plus intéressantes concernant l'Internet est que ce n'était pas conçu pour la sécurité et que c'est arrivé, pour ainsi dire, presque par accident. Les chercheurs du début, des gens comme JCR Licklider et Vint Cert, voulaient surtout faciliter la communication entre des chercheurs universitaires ; ils supposaient donc que quiconque avec qui ils avaient des contacts était un autre « mec bien ». Ce n'est que quand le développement de l'Internet s'est intensifié dans les années 1980 et 1990 que certains ont commencé à prêter attention à ce genre de choses. Des technologies comme Javascript et SSL furent introduites par Netscape, par exemple, bien que, depuis, ils ont été adoptés par tout le Net. | Une des choses les plus intéressantes concernant l'Internet est que ce n'était pas conçu pour la sécurité et que c'est arrivé, pour ainsi dire, presque par accident. Les chercheurs du début, des gens comme JCR Licklider et Vint Cert, voulaient surtout faciliter la communication entre des chercheurs universitaires ; ils supposaient donc que quiconque avec qui ils avaient des contacts était un autre « mec bien ». Ce n'est que quand le développement de l'Internet s'est intensifié dans les années 1980 et 1990 que certains ont commencé à prêter attention à ce genre de choses. Des technologies comme Javascript et SSL furent introduites par Netscape, par exemple, bien que, depuis, ils aient été adoptés par tout le Net. |
| |
| Intro | Intro |
| |
| Au début, si vous vouliez vous connecter sur un ordinateur distant pour travailler, vous pouviez sans doute utiliser un programme appelé Telnet pour le faire. Telnet vous permettait de vous connecter à une machine Unix distante si vous aviez un compte dessus ; une fois connecté, vous pouviez faire tout ce que votre compte était autorisé à faire. Et, si vous aviez un accès root, cela aurait pu être à peu près n'importe quoi. Je me souviens de la première fois où j'ai participé à une telle chose, dans les années 1990 où je gérais le site Web de mon université. On m'a attribué un compte shell sur notre serveur Red Hat qui hébergeait également le site Web ; on m'a prévenu très sérieusement qu'il ne fallait rien faire qui puisse le bousiller. À partir de mon ordinateur de bureau, jallais sur le serveur via Telnet pour faire des trucs comme chmod les scripts CGI et ce genre de choses qu'il fallait faire avec les sites Web à cette époque. Cela fonctionnait raisonnablement bien, mais le problème avec Telnet est qu'il n'était pas conçu pour créer une connexion sure et, puisque notre site Web était sur ce serveur, il était par la force des choses exposé au Net entier. Si vous mettez ensemble une connexion non protégée et une attaque de type « l'homme au milieu » ou des vulnérabilités dans le programme Telnet, grâce auxquelles un attaquant pouvait entrer et, qui plus est, augmenter ses droits, vous comprendrez pourquoi c'est devenu un problème. | Au début, si vous vouliez vous connecter sur un ordinateur distant pour travailler, vous pouviez sans doute utiliser un programme appelé Telnet pour le faire. Telnet vous permettait de vous connecter à une machine Unix distante si vous aviez un compte dessus ; une fois connecté, vous pouviez faire tout ce que votre compte était autorisé à faire. Et, si vous aviez un accès root, cela aurait pu être à peu près n'importe quoi. Je me souviens de la première fois où j'ai participé à une telle chose, dans les années 1990 où je gérais le site Web de mon université. On m'a attribué un compte shell sur notre serveur Red Hat qui hébergeait également le site Web ; on m'a prévenu très sérieusement qu'il ne fallait rien faire qui puisse le bousiller. À partir de mon ordinateur de bureau, j'allais sur le serveur via Telnet pour faire des trucs comme chmod les scripts CGI et ce genre de choses qu'il fallait faire avec les sites Web à cette époque. Cela fonctionnait raisonnablement bien, mais le problème avec Telnet est qu'il n'était pas conçu pour créer une connexion sûre et, puisque notre site Web était sur ce serveur, il était par la force des choses exposé au Net entier. Si vous mettez ensemble une connexion non protégée et une attaque de type « l'homme au milieu » ou des vulnérabilités dans le programme Telnet, grâce auxquelles un attaquant pouvait entrer et, qui plus est, augmenter ses droits, vous comprendrez pourquoi c'est devenu un problème. |
| ===== 2 ===== | ===== 2 ===== |
| |
| |
| |
| En 1995, il y a eu une attaque à la recherche de mots de passe sur le réseau de l'université d'Helsinki en Finlande et cela a amené un chercheur là-bas, Tatu Ylönen, à créer la première implémentation de SSH. SSH est un acronyme de Secure Shell et exprime l'idée que vous pouvez vous connecter de façon sûre et obtenir un shell sur un serveur distant. Au départ, ce fut publié en tant que Logiciel libre, mais, lors de versions ultérieures, il l'a rendu propriétaire. Toutefois, les développeurs chez OpenBSD ont décidé qu'un Logiciel libre devait être implémenté et ils ont créé OpenSSH, devenu aujourd'hui la base de la plupart des implémentations. Et, alors que, au départ, SSH fut fait pour des environnements comme Unix (ce qui, à la longue, incluait Linux), les développeurs chez OpenBSD ont créé une branche pour la portabilité qui le rendait disponible sur n'importe quel système d'exploitation. Ainsi, si vous êtes sous Windows, vous pouvez utiliser SSH tout aussi facilement. Si vous voulez un peut plus de détails à ce sujet, allez voir Wikipedia. | En 1995, il y a eu une attaque à la recherche de mots de passe sur le réseau de l'université d'Helsinki en Finlande et cela a amené un chercheur là-bas, Tatu Ylönen, à créer la première implémentation de SSH. SSH est un acronyme de Secure Shell et exprime l'idée que vous pouvez vous connecter de façon sûre et obtenir un shell sur un serveur distant. Au départ, ce fut publié en tant que Logiciel libre, mais, lors de versions ultérieures, il l'a rendu propriétaire. Toutefois, les développeurs chez OpenBSD ont décidé qu'un Logiciel libre devait être implémenté et ils ont créé OpenSSH, devenu aujourd'hui la base de la plupart des implémentations. Et, alors qu'au départ, SSH fut fait pour des environnements comme Unix (ce qui, à la longue, incluait Linux), les développeurs chez OpenBSD ont créé une branche pour la portabilité qui le rendait disponible sur n'importe quel système d'exploitation. Ainsi, si vous êtes sous Windows, vous pouvez utiliser SSH tout aussi facilement. Si vous voulez un peu plus de détails à ce sujet, allez voir Wikipedia. |
| |
| Considérations de conception | Considérations de conception |
| |
| SSH fut conçu pour faire plusieurs choses : | SSH fut conçu pour faire plusieurs choses : |
| * Créer une communication privée et sure entre deux machines différentes. Cela veut dire que la connexion doit utiliser le chiffrement. | * Créer une communication privée et sûre entre deux machines différentes. Cela veut dire que la connexion doit utiliser le chiffrement. |
| * Établir l'intégrité des communications pour assurer que les messages n'ont pas été modifiés en chemin. Encore une fois, ceci est possible grâce au chiffrement. | * Établir l'intégrité des communications pour assurer que les messages n'ont pas été modifiés en chemin. Encore une fois, ceci est possible grâce au chiffrement. |
| * Authentifier les deux participants à la conversation pour pouvoir démontrer leur identité. À nouveau, ceci se fait par le biais du chiffrement. | * Authentifier les deux participants à la conversation pour pouvoir démontrer leur identité. À nouveau, ceci se fait par le biais du chiffrement. |
| It is important to understand the mechanisms and how they work if you are going to be secure, since otherwise you might make a mistake and open yourself to an attack.** | It is important to understand the mechanisms and how they work if you are going to be secure, since otherwise you might make a mistake and open yourself to an attack.** |
| |
| Quant à l'authentification, on peut utiliser des mots de passe avec SSH, mais cette forme d'authentification est assez faible. Si la sécurité vous préoccupe beaucoup, vous devrez vous authentifier au moyen d'une clé. Nos vieux copains la paire de clés publique/privée arrivent sur scène à ce stade et, comme vous pourriez le supposer, les grandes lignes de comment faire ressemblent assez à ce que nous avons vu dans, à la fois, les Mails et les Certificats. Bien entendu, ce n'est pas parfait, mais cela réduit de façon très significative les possibilités d'une attaque. Notez que, même si vous utilisez l'authentification par mot de passe, cela implique un chiffrement et un échange de clés. C'est nécessaire pour réaliser les deux premiers objectifs ci-dessus. | Quant à l'authentification, on peut utiliser des mots de passe avec SSH, mais cette forme d'authentification est assez faible. Si la sécurité vous préoccupe beaucoup, vous devrez vous authentifier au moyen d'une clé. Nos vieux copains la paire de clés publique/privée arrivent sur scène à ce stade et, comme vous pourriez le supposer, les grandes lignes de comment faire ressemblent assez à ce que nous avons vu dans, à la fois, les mails et les certificats. Bien entendu, ce n'est pas parfait, mais cela réduit de façon très significative les possibilités d'une attaque. Notez que, même si vous utilisez l'authentification par mot de passe, cela implique un chiffrement et un échange de clés. C'est nécessaire pour réaliser les deux premiers objectifs ci-dessus. |
| |
| Chiffrement et « tunneling » | Chiffrement et « tunneling » |
| |
| L'idée de base dans SSH, tout comme dans les Réseaux privés virtuels (VPN), c'est d'utiliser le chiffrement pour créer des communications sures entre deux systèmes différents. Nous avons pris l'habitude de parler de ce type de connexion en termes de « tunnel ». Ceci est un métaphore et, comme toutes les métaphores, il éclaire des choses tout en en obscurcissant d'autres. L'idée d'un tunnel aide en fait à faire comprendre la sécurité de la connexion, puisque, si c'est bien fait, le monde extérieur ne peut pas voir se qui s'y passe. Le chiffrement fonctionne bien, s'il est fait comme il faut, et, pour reprendre les célèbres paroles de Bruce Schneier après les révélations de Snowden, vous pouvez faire confiance aux mathématiques. Cependant, la métaphore semble laisser entendre que ce trafic coule quelque part ailleurs que le reste du Net et cela est tout simplement faux. Tout le trafic du « tunnel » passe par les mêmes routeurs et hubs que tout le reste du trafic sur le Net et c'est composé de la même sorte de paquets. Si vous êtes sur un réseau où quelqu'un se sert de SSH, vous pouvez « voir » les paquets avec wireshark ou d'autres logiciels similaires. Mais vous ne pourriez pas rien voir dans la charge utile de chaque paquet, autre que du bruit aléatoire, à cause du chiffrement. | L'idée de base dans SSH, tout comme dans les réseaux privés virtuels (VPN), c'est d'utiliser le chiffrement pour créer des communications sûres entre deux systèmes différents. Nous avons pris l'habitude de parler de ce type de connexion en termes de « tunnel ». Ceci est une métaphore et, comme toutes les métaphores, elle éclaire des choses tout en en obscurcissant d'autres. L'idée d'un tunnel aide en fait à faire comprendre la sécurité de la connexion, puisque, si c'est bien fait, le monde extérieur ne peut pas voir se qui s'y passe. Le chiffrement fonctionne bien, s'il est fait comme il faut, et, pour reprendre les célèbres paroles de Bruce Schneier après les révélations de Snowden, vous pouvez faire confiance aux mathématiques. Cependant, la métaphore semble laisser entendre que ce trafic coule quelque part ailleurs que le reste du Net et cela est tout simplement faux. Tout le trafic du « tunnel » passe par les mêmes routeurs et hubs que tout le reste du trafic sur le Net et c'est composé de la même sorte de paquets. Si vous êtes sur un réseau où quelqu'un se sert de SSH, vous pouvez « voir » les paquets avec wireshark ou d'autres logiciels similaires. Mais vous ne pourriez pas rien voir dans la charge utile de chaque paquet, autre que du bruit aléatoire, à cause du chiffrement. |
| |
| Si vous voulez être protégé, il est important de comprendre les mécanismes et leur fonctionnement, puisque, dans le cas contraire, vous pourriez faire une erreur et vous exposer à une attaque. | Si vous voulez être protégé, il est important de comprendre les mécanismes et leur fonctionnement, puisque, dans le cas contraire, vous pourriez faire une erreur et vous exposer à une attaque. |
| Bien que, à l'origine, SSH fut développé pour tout simplement fournir une session shell protégée sur un serveur distant, il a été étendu dans de nombreuses façons intéressantes que nous regarderons dans des tutoriels à venir. Par exemple, SSH peut être utilisé pour : | Bien que, à l'origine, SSH fut développé pour tout simplement fournir une session shell protégée sur un serveur distant, il a été étendu dans de nombreuses façons intéressantes que nous regarderons dans des tutoriels à venir. Par exemple, SSH peut être utilisé pour : |
| |
| * Créer des tunnels | * Créer des tunnels. |
| * Transférer des ports TCP | * Transférer des ports TCP. |
| * Créer des connexions X11 | * Créer des connexions X11. |
| * Transférer des fichiers en toute sécurité (SFTP) | * Transférer des fichiers en toute sécurité (SFTP). |
| * Copier des fichiers en toute sécurité (SCP) | * Copier des fichiers en toute sécurité (SCP). |
| * Monter un système de fichiers distant en toute sécurité (SSHFS) | * Monter un système de fichiers distant en toute sécurité (SSHFS). |
| |
| Où obtenir SSH ? | Où obtenir SSH ? |
| • ssh-keysign – Helper program for hostbased authentication.** | • ssh-keysign – Helper program for hostbased authentication.** |
| |
| Quant aux clients sur ordinateurs de bureau, je me répète, le client SSH est installé par défaut sur tous les systèmes de type Unix. Cela comprend Unix, Linux, MacOS et toutes les variétés de BSD. Pour les utilisateurs de Windows, je recommande l'installation de PuTTY : c'est gratuit, est distribué sous licence MIT et se conforme aux « Debian Free Software Guidelines ». Puisqu'il utilise des applets différents pour chacune de ses fonctionnalités, il y a plusieurs applications PuTTY, une pour Secure Shell, une autre pour SFTP et ainsi de suite. | Quant aux clients sur ordinateurs de bureau, je me répète, le client SSH est installé par défaut sur tous les systèmes de type Unix. Cela comprend Unix, Linux, MacOS et toutes les variétés de BSD. Pour les utilisateurs de Windows, je recommande l'installation de PuTTY : c'est gratuit, distribué sous licence MIT et se conforme aux « Debian Free Software Guidelines ». Puisqu'il utilise des applets différents pour chacune de ses fonctionnalités, il y a plusieurs applications PuTTY, une pour Secure Shell, une autre pour SFTP et ainsi de suite. |
| |
| Un manuel très utile qui couvre Open SSH et les différentes applications qui le composent se trouve à http://www.openssh.com/manual.html. Ici, vous pouvez constater que les applications qui font partie de OpenSSH sont, notamment : | Un manuel très utile qui couvre Open SSH et les différentes applications qui le composent se trouve à http://www.openssh.com/manual.html. Ici, vous pouvez constater que les applications qui font partie de OpenSSH sont, notamment : |
| • ssh-agent – Un agent d'authentification qui peut stocker des clés privées. | • ssh-agent – Un agent d'authentification qui peut stocker des clés privées. |
| • ssh-add – Un outil qui ajoute des clés à l'agent ci-dessus. | • ssh-add – Un outil qui ajoute des clés à l'agent ci-dessus. |
| • sftp – Programme de type FTP qui utilisent les protocoles SSH1 et SSH2. | • sftp – Programme de type FTP qui utilise les protocoles SSH1 et SSH2. |
| • scp – Un programme de copie de fichiers qui agit comme rcp. | • scp – Un programme de copie de fichiers qui agit comme rcp. |
| • ssh-keygen – Outil pour générer des clés. | • ssh-keygen – Outil pour générer des clés. |
| Comment cela fonctionne | Comment cela fonctionne |
| |
| Pour commencer, toutes les connexions SSH sont initialisées par le client. C'est vous, en tant que client, qui allez au serveur demander « S'il vous plaît, monsieur, pourrais-je avoir une connexion shell ? » Et, en général, vous le ferez en utilisant le port 22. Sur le serveur, il y a un démon qui écoute ce port et c'est lui qui doit répondre à votre demande. Si vous avez le même nom de compte sur le client et le serveur, alors il vous suffit de vous connecter au serveur. Si le nom est différent, vous devez saisir votre nom de compte. Ces exemples supposent que vous utilisez un terminal. | Pour commencer, toutes les connexions SSH sont initialisées par le client. C'est vous, en tant que client, qui allez au serveur demander : « S'il vous plaît, monsieur, pourrais-je avoir une connexion shell ? » Et, en général, vous le ferez en utilisant le port 22. Sur le serveur, il y a un démon qui écoute ce port et c'est lui qui doit répondre à votre demande. Si vous avez le même nom de compte sur le client et le serveur, alors il vous suffit de vous connecter au serveur. Si le nom est différent, vous devez saisir votre nom de compte. Ces exemples supposent que vous utilisez un terminal. |
| |
| Premier exemple : | Premier exemple : |
| Et après, le « Binary Packet Protocol » démarre. Il spécifie chacun des champs du paquet envoyé en utilisant SSH. Si vous voulez tous les détails, regardez RFC 4253, mais c'est sans doute quelque chose d'inutile si vous n'allez pas écrire votre propre client. | Et après, le « Binary Packet Protocol » démarre. Il spécifie chacun des champs du paquet envoyé en utilisant SSH. Si vous voulez tous les détails, regardez RFC 4253, mais c'est sans doute quelque chose d'inutile si vous n'allez pas écrire votre propre client. |
| |
| Puis c'est au tour du Serveur de s'identifier en transmettant sa clé publique. Si c'est la première fois que vous essayez de vous connecter à ce serveur, vous verrez quelque chose comme ceci : | Puis c'est au tour du serveur de s'identifier en transmettant sa clé publique. Si c'est la première fois que vous essayez de vous connecter à ce serveur, vous verrez quelque chose comme ceci : |
| |
| The authenticity of host 'myserver.host.com' can't be established. (Impossibilité d'établir l'authenticité du serveur hôte) | The authenticity of host 'myserver.host.com' can't be established. (Impossibilité d'établir l'authenticité du serveur hôte..) |
| |
| RSA key fingerprint is d8:09:f4:42:.... (L'empreinte digitale de la clé RSA est ...) | RSA key fingerprint is d8:09:f4:42:.... (L'empreinte digitale de la clé RSA est ...) |
| Are you sure you want to continue connecting (yes/no)? (Êtes-vous certain de vouloir continuer la connexion (oui/non) ?) | Are you sure you want to continue connecting (yes/no)? (Êtes-vous certain de vouloir continuer la connexion (oui/non) ?) |
| |
| Puisque c'est la première fois que vous essayez de vous connecter, vous ne savez pas avec certitude que c'est vraiment le serveur que vous voulez. C'est ici que pourrait avoir lieu une attaque de l'homme-au-milieu. Par exemple, si vous étiez assis dans un café avec wifi gratuit, quelqu'un à une autre table pourrait intercepter le trafic et répondre avec sa propre clé publique - autrement dit, il piraterait votre session. Cela ne devrait se passer que la première fois que vous vous connectez à cette machine précise, car la clé publique devrait être stockée à titre de référence ultérieure dans un fichier qui s'appelle « known_hosts » (hôtes connus). Sur une machine Linux, on la trouve généralement dans ~/.ssh/known_hosts. Sous Windows 7, il se trouve habituellement dans %USERPROFILE%\ssh ou %USERPROFILE%\.ssh. Mais si vous avez un nouvel ordinateur portable, vous devez passer par cette connexion initiale avec chacun des sites auxquels vous vous connectez. | Puisque c'est la première fois que vous essayez de vous connecter, vous ne savez pas avec certitude que c'est vraiment le serveur que vous voulez. C'est ici que pourrait avoir lieu une attaque de l'homme-au-milieu. Par exemple, si vous étiez assis dans un café avec W ifi gratuit, quelqu'un à une autre table pourrait intercepter le trafic et répondre avec sa propre clé publique - autrement dit, il piraterait votre session. Cela ne devrait se passer que la première fois que vous vous connectez à cette machine précise, car la clé publique devrait être stockée à titre de référence ultérieure dans un fichier qui s'appelle « known_hosts » (hôtes connus). Sur une machine Linux, on la trouve généralement dans ~/.ssh/known_hosts. Sous Windows 7, il se trouve habituellement dans %USERPROFILE%\ssh ou %USERPROFILE%\.ssh. Mais si vous avez un nouvel ordinateur portable, vous devez passer par cette connexion initiale avec chacun des sites auxquels vous vous connectez. |
| ===== 9 ===== | ===== 9 ===== |
| |
| The next step depends on whether you are using SSH v.1 or SSH v.2. Since the vulnerability in SSH v.1 was found long ago in Internet time, you probably should question what is happening if you see it used today. SSH v.2 was adopted in 2006, which makes it comparatively old and stable. As Michael W. Lucas put it in his book SSH Mastery: “SSH-1 permits man-in-the-middle attacks and session hijacking, as discussed in Chapter 1. If someone insists on using SSH-1, practice saying “I told you so.” His book is excellent, and the e-book is only $10, and worth every cent. In particular, if you need to set up an SSH server, which I won’t really cover much of, this book is mandatory reading. Among the changes introduced by SSH v.2 are:** | The next step depends on whether you are using SSH v.1 or SSH v.2. Since the vulnerability in SSH v.1 was found long ago in Internet time, you probably should question what is happening if you see it used today. SSH v.2 was adopted in 2006, which makes it comparatively old and stable. As Michael W. Lucas put it in his book SSH Mastery: “SSH-1 permits man-in-the-middle attacks and session hijacking, as discussed in Chapter 1. If someone insists on using SSH-1, practice saying “I told you so.” His book is excellent, and the e-book is only $10, and worth every cent. In particular, if you need to set up an SSH server, which I won’t really cover much of, this book is mandatory reading. Among the changes introduced by SSH v.2 are:** |
| |
| C'est, sans aucun doute, une faiblesse, alors comment les administrateurs serveurs peuvent-ils l'empêcher ? L'empreinte vous fut rendue lorsque vous avez essayé de vous connecter et c'est donc la clé du problème, si vous voulez bien excuser le double-sens. Vous ne voudriez sans doute pas l'afficher publiquement sur un site Web non sécurisé, par exemple, puisque les méchants pourraient éventuellement trouver un moyen de la contrefaire. Et le courriel engendre les mêmes risques. Dans un environnement d'entreprise, vous pourriez peut-être l'afficher sur un site Web chiffré derrière un pare-feu et exiger que les employés utilisent leurs identifiants pour y accéder. | C'est, sans aucun doute, une faiblesse, alors comment les administrateurs serveurs peuvent-ils l'empêcher ? L'empreinte vous fut rendue lorsque vous avez essayé de vous connecter et c'est donc la clé du problème, si vous voulez bien excuser le double sens. Vous ne voudriez sans doute pas l'afficher publiquement sur un site Web non sécurisé, par exemple, puisque les méchants pourraient éventuellement trouver un moyen de la contrefaire. Et le courriel engendre les mêmes risques. Dans un environnement d'entreprise, vous pourriez peut-être l'afficher sur un site Web chiffré derrière un pare-feu et exiger que les employés utilisent leurs identifiants pour y accéder. |
| |
| La prochaine étape diffère selon que vous utilisez SSH v.1 ou SSH v.2. Puisque la vulnérabilité dans SSH v.1 fut découverte il y a très longtemps (en temps Internet), vous devriez sans doute vous posez des questions sur ce qui se passe, si vous constatez qu'il est utilisé de nos jours. SSH v.2 fut adopté en 2006, ce qui fait qu'il est relativement ancien et stable. Comme Michael W. Lucas l'a dit dans sans livre //SSH Mastery// : « SSH-1 permet des attaques du type homme-au-milieu et le piratage de sessions, comme présenté dans le premier chapitre. Si quelqu'un persiste à vouloir l'utiliser, vous pouvez vous entraîner à dire "Je vous l'avais bien dit." ». Son livre est excellent ; la version électronique ne coûte que $10 et elle les vaut bien. En particulier, si vous avez besoin de créer un serveur SSH, ce dont je ne vais guère parler, lire ce livre est obligatoire. Parmi les modifications introduites par SSH v.2, il y a : | La prochaine étape diffère selon que vous utilisez SSH v.1 ou SSH v.2. Puisque la vulnérabilité dans SSH v.1 fut découverte il y a très longtemps (en temps Internet), vous devriez sans doute vous poser des questions sur ce qui se passe, si vous constatez qu'il est utilisé de nos jours. SSH v.2 fut adopté en 2006, ce qui fait qu'il est relativement ancien et stable. Comme Michael W. Lucas l'a dit dans son livre //SSH Mastery// : « SSH-1 permet des attaques du type homme-au-milieu et le piratage de sessions, comme présenté dans le premier chapitre. Si quelqu'un persiste à vouloir l'utiliser, vous pouvez vous entraîner à dire "Je vous l'avais bien dit." ». Son livre est excellent ; la version électronique ne coûte que 10 $ et elle les vaut bien. En particulier, si vous avez besoin de créer un serveur SSH, ce dont je ne vais guère parler, lire ce livre est obligatoire. Parmi les modifications introduites par SSH v.2, il y a : |
| |
| ===== 10 ===== | ===== 10 ===== |
| Kevin is a geek, Linux enthusiast, a certified Project Manager by day, and in general a tech lover. His blog is at: http://www.zwilnik.com ** | Kevin is a geek, Linux enthusiast, a certified Project Manager by day, and in general a tech lover. His blog is at: http://www.zwilnik.com ** |
| |
| • Des normes de chiffrement améliorées, y compris 3DES et AES | • Des normes de chiffrement améliorées, y compris 3DES et AES. |
| • La certification de clés publiques pour les clients (je vais en parler plus tard) | • La certification de clés publiques pour les clients (je vais en parler plus tard). |
| • L'utilisation d'algorithmes cryptographiques « Message Authentication Code (MAC) » solides pour vérifier l'intégrité | • L'utilisation d'algorithmes cryptographiques « Message Authentication Code (MAC) » solides pour vérifier l'intégrité. |
| • SSH v.1 était monolithique, ce qui veut dire que tous les protocoles nécessaires pour le chiffrement, l'authentification, etc. faisaient partie d'un seul grand protocole incorporé dans SSH v.1. Dans SSH v.2 chaque protocole est distinct et défini dans un RFC séparé, tels que | • SSH v.1 était monolithique, ce qui veut dire que tous les protocoles nécessaires pour le chiffrement, l'authentification, etc. faisaient partie d'un seul grand protocole incorporé dans SSH v.1. Dans SSH v.2 chaque protocole est distinct et défini dans un RFC séparé, tels que : |
| •• Transport Layer Protocol (Le protocole de couche de transport) | •• Transport Layer Protocol (Le protocole de couche de transport). |
| •• Connection Protocol (Le protocole de connexion) | •• Connection Protocol (Le protocole de connexion). |
| •• Authentication Protocol (Le protocole d'authentification) | •• Authentication Protocol (Le protocole d'authentification). |
| |
| Je ne veux pas prendre le temps d'examiner le fonctionnement de SSH v.1, et, puisqu'il y quelques différences, je vais me concentrer ici sur SSH v.2 uniquement. | Je ne veux pas prendre le temps d'examiner le fonctionnement de SSH v.1, et, puisqu'il y quelques différences, je vais me concentrer ici sur SSH v.2 uniquement. |
| |
| Une vois que vous aurez accepté la Clé publique du serveur, c'est à vous, le client de répondre. Vous le faites d'abord en générant une clé symétrique (appelé la clé de la session) qui servira à chiffrer tout le trafic. Souvenez-vous des tutoriels précédents, que des paires de clé asymétriques entraînent de très grands calculs supplémentaires et ne sont donc utilisées habituellement que pour configurer une connexion et échanger la clé symétrique. Le client crée cette clé, puis, en utilisant l'échange de clé Diffie-Hellman-SHA1 la renvoie au serveur. | Une vois que vous aurez accepté la clé publique du serveur, c'est à vous, le client de répondre. Vous le faites d'abord en générant une clé symétrique (appelé la clé de la session) qui servira à chiffrer tout le trafic. Souvenez-vous des tutoriels précédents, que des paires de clé asymétriques entraînent de très grands calculs supplémentaires et ne sont donc utilisées habituellement que pour configurer une connexion et échanger la clé symétrique. Le client crée cette clé, puis, en utilisant l'échange de clé Diffie-Hellman-SHA1 la renvoie au serveur. |
| |
| NOTA : Le protocole contient une disposition pour l'attestation de la validité des clés publiques utilisées par une Autorité de certification. Cela aiderait énormément à empêcher une attaque homme-au-milieu à laquelle vous êtes vulnérables lors de votre première connexion, puisque la CA vous inspirerait confiance dans la validité de la clé publique du serveur. Mais, actuellement, tous les serveurs ne l'utilisent pas, en partie parce que les certificats sont chers. | NOTA : Le protocole contient une disposition pour l'attestation de la validité des clés publiques utilisées par une Autorité de certification. Cela aiderait énormément à empêcher une attaque homme-au-milieu à laquelle vous êtes vulnérables lors de votre première connexion, puisque la CA vous inspirerait confiance dans la validité de la clé publique du serveur. Mais, actuellement, tous les serveurs ne l'utilisent pas, en partie parce que les certificats sont chers. |
