Monthly Archives: novembre 2006

Archivage dans SAP ECC

Principales transactions :

SARA : archiver
SARI : restituer les archives
OAAD : consulter des archives
OADR : rechercher listes archives
OAM1 : moniteur d’archivage, documents en transit
Table OADL : liens documents archivés

Quelle version de PGP utiliser ?

1) Versions initiales de PGP
======================

- – Peu de gens sensés mettent en doute l’engagement et les motivations de Phil Zimmermann, ni ses compétences, lors du développement des versions « initiales » de PGP. Je veux parler des versions à interface « ligne de commande » qui ne géraient que des clés RSA, c’est-à-dire les versions <= 2.6.3.
- – On peut donc considérer que le « bébé » est né sous de très bons auspices.
- – Ces versions ont été disponibles dans le monde entier depuis de nombreuses années, et de nombreux experts reconnus les ont décortiquées et les ont reconnues comme sûres.
- – Ce développement a valu a Phil Zimmermann le respect et la reconnaissance de la communauté entière, qui est à la mesure de son engagement et de son dévouement pour la Cause.
- – Le long combat de Phil Zimmermann contre la « justice » des Etats-Unis, et toutes les tentatives faites à son encontre pour empêcher le développement et la diffusion de PGP n’ont fait qu’augmenter son crédit et celui de son programme.
- – Bien que depuis, certaines faiblesses du hash MD5 aient été théoriquement signalées, il n’a jamais (à ma connaissance) été reporté que celui-ci ait été « cassé ».
- – Depuis des années, il n’a *JAMAIS* été rapporté de manière sérieuse aucun défaut majeur de PGP 2.6x, pas plus qu’aucun exemple de cas où les messages codés auraient été « cassés ».
- – La longue durée de vie de ce programme, le « recul », la libre disponibilité de ses sources, le contrôle dont il a fait l’objet, en font le programme de cryptographie le _PLUS_ crédible, sans conteste, de tous les produits disponibles sur le marché.

CONCLUSIONS 1
===============

- – Les versions 2.6x de PGP, bien que d’utilisation peu commode, sont largement considérées comme fiables et crédibles.
- – Il S’agit sans conteste, en tout état de cause, du programme de cryptographie le plus crédible qui ait jamais été mis à disposition du public.
- – Pour un utilisateur habitué à une interface graphique (Windows), ces versions sont pénibles d’emploi. Certains « Shells » optionnels (Aegis Shell, PGPShell…) permettent de les exploiter plus facilement dans un environnement Windows, au détriment d’une sécurité absolue — voir ci-dessous pour les problèmes liés à l’environnement Windows.

N.B. : De nombreux programmes annexes (Jack B. Nymble, Mixmaster…) font aujourd’hui encore appel à PGP 2.6x / 2.6xi, aussi cette version de PGP est-elle indispensable dans la boîte-à-outils de base…

2) Versions internationales de PGP
===========================

- – Depuis plusieurs années, Stale Schumacher (Norvège) s’est investi sans compter dans le développement et la mise à disposition, pour le « reste du monde » (non-U.S.) des versions « internationales » de PGP, dites « versions (i) ».
- – Ces versions sont disponibles sur http://www.pgpi.com
- – Les versions 2.6x(i) étaient obtenues par un travail sur le code source de PGP, visant à remplacer l’usage de certaines bibliothèques sous licence, par des bibliothèques équivalentes libres de droits. Le résultat obtenu était que les versions 2.6x(i) de PGP étaient légèrement _plus_ performantes que les versions U.S. correspondantes, et de surcroît un peu mieux débuggées.
- – Les versions (i) actuelles (5.5.3i, 6.0i…) sont obtenues par re-scannage intégral du code source de PGP, obtenu légalement des Etats-Unis sous forme imprimée — car une bizarrerie des réglements d’exportation U.S. interdit l’exportation de logiciels de cryptographie, mais autorise l’exportation du code source imprimé, qui est alors vu par la loi comme des « livres » (non-soumis à restrictions d’exportation) et non pas comme des « logiciels » soumis à restrictions.
- – Après scannage et vérification, ces « sources » sont recompilés, donnant naissance aux versions (i) de PGP.
- – Aucune personne sensée à ma connaissance ne met en doute la compétence, l’engagement et l’honnêteté de Stale Schumacher, qui a lui-aussi gagné le respect et la reconnaissance de la communauté.

CONCLUSIONS 2
===============

Les versions (i) de PGP disponibles sur http://www.pgpi.com me paraîssent (au moins) aussi fiables et aussi crédibles que les versions U.S. correspondantes.

3) Versions 5.x de PGP
==================

- – Après que Phil Zimmermann eût gagné son procès contre le gouvernement U.S., il a monté sa Société (PGP, Inc.) dont le premier développement fût la série PGP 5.x.
- – Les versions 5.x de PGP sont disponibles sous plusieurs environnements (Windows, Mac, Unix…)
- – Les versions 5.x de PGP implémentent de nouveaux types de clés et de nouveaux algorithmes : Les clés DH/DSS remplacent les clés RSA, le « hash » SHA1 remplace MD5, et l’algorithme CAST remplace IDEA.
- – Le code source continue d’être disponible pour libre contrôle.
- – L’ajout de nouveaux algorithmes, et les fonctions supplémentaires (environnement graphique…) rendent le code source plus complexe, et donc plus difficile à contrôler.
- – L’accroissement de la taille du code source rend peut-être possible le fait (très hautement improbable) qu’une « backdoor » soit cachée quelque part.
- – Le système d’exploitation « Windows » pose des problèmes de sécurité inhérents, qui rendent plus vulnérable une machine tournant sous Windows comparativement à une machine tournant sous DOS. Toutefois ce problème n’est pas spécifique à PGP, mais lié à Windows.
- – Il n’est pas certain que le code source de PGP 5.x ait été contrôlé de manière aussi approfondie, et par autant de spécialistes, que le code des versions 2.6x. Toutefois, de nombreux spécialistes se sont penchés dessus, et n’ont pas détecté de faiblesse criante dans l’implémentation des algorithmes de cryptographie.
- – Un bug a été signalé avec la fonction « Wipe » (effacement sécurisé) des fichiers, avec certaines versions de PGP 5.x. L’effacement sécurisé n’est donc pas considéré comme fiable. Toutefois, ceci n’affecte en rien la sécurité de l’encryptage.
- – Les versions 5.x de PGP¨disposent maintenant de suffisamment de recul (2 ans).
- – Aucun défaut majeur dans le code source n’a été rapporté, pas plus qu’aucun exemple de cas où des messages cryptés auraient été « cassés ».
- – L’environnement graphique, et l’intégration avec les logiciels de messagerie courants, fait des versions 5.x de PGP les première versions d’utilisation facile, même pour un non-spécialiste de l’informatique.

CONCLUSIONS 3
==============

- – Les versions 5.x de PGP sont par nature un peu moins « fiables » que les versions 2.6x. L’environnement Windows y est pour beaucoup.
- – Ces versions sont d’un emploi facile et agréable, très bien intégrées aux logiciels e-mail les plus courants.
- – Je considère cependant ces versions comme largement fiables, et je les utilise sans arrière-pensées. Elles seront le « choix idéal » pour l’utilisateur occasionnel ayant des besoins de sécurité.
- – Un utilisateur ayant de très hauts besoins en matière de sécurité devra également s’assurer de la sécurité physique de son ordinateur, et devra sans doute utiliser des programmes accessoires visant à puger l’espace disque inutile et les fichiers de travail de Windows.
- – Les mêmes remarques s’appliquent aux versions 5.x(i) de PGP.

4) Versions 6.x de PGP
==================

- – PGP, Inc. a été racheté par McAfee. La nouvelle société issue de cette fusion s’appelle « Network Associates, Inc. » (NAI)
- – NAI développe et distribue donc les dernières versions (6.x) de PGP
- – NAI ne jouit pas d’une bonne réputation, en particulier parce que cette société a fait partie de la « Key Recovery Alliance », puis a quitté cette organisation, et vient récemment de la réintégrer (Yo-yo !).
- – Rappelons que la « Key Recovery Alliance » vise à permettre au Gouvernement U.S. de pouvoir disposer des clés de cryptage nécessaires au décodage des messages. Cette « Alliance » est donc philosophiquement à l’exact inverse des positions de Phil Zimmermann, créateur de PGP, ainsi que de tous les défenseurs de la cryptographie libre.
- – Auprès de NAI, Phil Zimmermann ne joue plus le rôle que de « Spiritual Advisor », et on peut s’interroger sur la portée de cette fonction, ainsi que sur ses réelles capacités de contrôle sur l’ensemble du logiciel.
- – Cette odeur de soufre rend malheureusement intrinsèquement suspectes toutes les versions de PGP issues de NAI, actuelles et futures.
- – De plus, le support clients de NAI est rapporté comme lamentable, et les dernières versions 6.x ont été distribuées _SANS_AUCUNE_SIGNATURE_ électronique « PGP » permettant de contrôler l’authenticité des programmes fournis.
- – Là encore, les « sources » sont disponibles pour contrôle par la communauté.
- – Toutefois, la « jeunesse » de ce programme, et la grande « enflure » de la tailles des sources (ajout de nouvelles fonctionnalités) en rendent le contrôle beaucoup plus difficile, augmentent les chances que des bugs y demeurent, ou des failles de sécurité, accidentelles ou intentionnelles.
- – Il est extrêmement probable que les sources de ces versions ont été beaucoup moins revues « librement » que les sources des versions antérieures — par manque de temps, et à cause de la complexité croissante de la tâche.
- – J’insiste sur le manque de « recul ».
- – Il faut cependant considérer le fait, important, que toute faiblesse intentionnelle introduite dans PGP, et qui serait ultérieurement découverte, comme toute faille majeure dans la sécurité, aurait un impact absolument désastreux sur la société NAI, qui ne s’en relèverait sans doute jamais. Aussi est-il logique de se demander si cette société, même si elle était animée de mauvaises intentions — ce qui est loin d’être prouvé, pourrait prendre un tel risque… ?

CONCLUSIONS 4
==============

- – Les versions 6.x de PGP sont aujourd’hui les _MOINS_CREDIBLES_ parmi celles disponibles.
- – Ce qui ne veut pas dire que ces versions soient mauvaise, mais simplement que leur fiabilité n’a pas été démontrée.
- – Seuls le temps et le recul, ainsi que la clarification de la position « idéologique » de NAI pourront modifier cet état de choses.
- – Les nouvelles fonctionnalités apportées (par rapport aux versions 5.x) ne me semblent pas compenser le surcroît de risque.
- – Il me semble donc prudent de s’abstenir d’utiliser ces versions jusqu’à plus ample informé.
- – Les mêmes remarques s’appliqueront aux versions 6.x(i) de PGP, qui seront cependant un peu plus « sûres », car on aura au moins les certitudes : – Que les programmes « binaires exécutables » diffusés auront bien été obtenus à partir des sources correspondants ; – De disposer de signatures électroniques « PGP » pour les sources et les exécutables.

5) Versions « améliorées » de PGP
==========================

- – On trouve sur Internet diverses versions « améliorées » de PGP, qui comportent certaines fonctionnalités additionnelles, gèrent des clés plus longues, corrigent certains bugs, etc…
- – On peut s’interroger sur le rapport bénéfice/risque qu’il y a à utiliser de telles versions. En effet, le gain de sécurité n’est pas réellement significatif, alors que les sources ont été modifiés, et qu’il est donc possible que des failles aient été, accidentellement ou intentionnellement introduites.
- – Ces différentes versions n’ont certainement pas bénéficié d’autant de contrôles indépendants que les versions originelles du programme.
- – Je ne dis pas que des failles y _existent_, je dis simplement qu’il n’est pas prouvé qu’elles n’existent pas…
- – L’utilisateur éventuel devra donc vérifier les sources par lui-même, s’il en est capable, ou ferait mieux de s’abstenir de les utiliser.

CONCLUSIONS 5
==============

- – Par mesure de précaution, il me semble qu’il faut éviter toute version de PGP qui ne proviendrait pas de la distribution « principale ».
- – Toute version « fiable » de PGP devra, selon moi, porter la signature électronique de « Phil Zimmermann », de « PGP, Inc. », ou de « Stale Schumacher ».
- – Il importe de s’assurer que les clés de contrôle de signature, si elles sont fournies, sont bien authentiques.
- – Toute autre version me paraît suspecte.

CONCLUSIONS GENERALES
========================

1) PGP est le meilleur programme de cryptographie à clé publique disponible sur le marché, et le plus fiable. Toutefois, les différentes versions disponibles n’offrent pas la même crédibilité.

2) L’utilisateur PARANOIAQUE se restreindra à utiliser une version 2.6.3i, sur un PC sous MS-DOS uniquement, et non relié à Internet. S’il est un tout petit peu moins paranoïaque, il pourra utiliser cette même version sous Windows, en l’accompagnant éventuellement d’un « Shell » additionnel, tel qu’Aegis Shell par exemple. Il devra alors prendre des mesures de sécurité supplémentaires (wipe de l’espace disque libre, et du fichier « swap » de Windows, etc…)

3) L’utilisateur prudent, qui a de réels besoins de sécurité, mais souhaite un programme fiable et convivial, pourra utiliser sans crainte une version 5.5.3i de PGP. Il devra assurer la sécurité de sa machine, et utiliser des outils de « wipe » additionnels, comme indiqué ci-dessus.

4) Seul un utilisateur ayant des données _PEU_ sensibles, pourra dans l’état actuel des choses, utiliser PGP 6.0x, en attendant que le recul nécessaire permette de juger de la fiabilité de cette version.

Extrait de fr.comp.securite par M.Bouissou, le 1998/11/30

Perçage de firewall à l’aide de SSH

Cet article décrit la manière de passer n’importe quel flux dans n’importe quel sens au travers des firewalls.

Application
Cela s’applique aux réseaux d’entreprise qui ne permettent que la navigation sur internet. Ces réseaux sont filtrés et n’autorisent que le protocole http en sortie.
Le filtre est généralement composé d’un serveur proxy accessible sur le réseau de l’entreprise après s’être authentifié (par exemble en ouvrant une session sur un domaine ou par user/password).
Bien que le réseau d’entreprise soit filtré, il est possible de passer outre le filtrage en faisant passer n’importe quel flux (protocole) dans n’importe quel sens (entreprise->internet ou internet->entreprise), et cela de manière sécurisée.

Prérequis
Evidemment il faut posséder sur le réseau client d’un accès à internet, plus précisement pouvoir surfer avec un navigateur ; ce qui implique qu’on dispose du protocole http en sortie.
Jusqu’à présent je n’ai jamais vu de réseau d’entreprise qui n’autorisait pas le protocole https simultanement à http.
D’un point de vue technique il faudra un point d’accès externe au réseau d’entreprise (une machine accessible depuis internet).

La notion du tunnel
Le protocole https fait transiter http dans une couche ssl. Cette couche ssl assure la sécurisation du flux entre le client et le serveur et c’est ssl qui est à l’initiative de la connexion, ensuite on met ce qu’on veut par dessus ; c’est le tunnel.
Il est possible d’établir ce tunnel (ssl) puisque le réseau d’entreprise permet le protocole https donc le ssl. Ensuite il suffit de relier à chaque extrémité les services souhaités : sur le réseau d’entreprise un client qui permet de faire entrer n’importe quoi dans le tunnel et à l’extérieur sur un autre réseau via internet un serveur qui offrira ses services au client.

Les outils
Afin d’avoir de la flexibilité on va mettre en oeuvre des outils qui permettent de la flexibilité.
Côté client on va utiliser une application qui permettra de 1 à n tunnels et coté serveur une application qui va relayer le flux client vers 1 à n service.

Le protocole utilisé va donc être ssl à l’aide d’applications ssh :
- le client Bitvise Tunnelier (windows)
- le serveur ssh (linux)
Cela va permettre d’établir un tunnel ssl à l’aide de ssh, on l’appellera tunnel ssh. La mise en oeuvre de ces outils se représente de la manière suivante :

Installation et configuration
Serveur
La machine externe au réseau d’entreprise devra héberger le serveur ssh.
Depuis le réseau d’entreprise le protocole ssl est autorisé en sortie, c’est donc sur le port 443 que le service ssh devra être configuré sur le serveur.
Client

- que le deamon SSH écoute sur le port TCP 443

- exécuter une commande ssh qui forwarde le flux client vers le bon service :
ssh -L 53128:monproxylan:3128 root@serveurssh -p 443

Côté client :

- créer une connexion vers le serveur SSH puis configurer un tunnel comme suivant :

- certains proxy necessitent une authentification NTLM (par exemple Microsoft ISA) et celle-ci n’est pas gérée correctement par putty, il faut alors installer ntlmaps ainsi que l’interpréteur Python. L’installation de Python ne nécessite pas d’avoir des droits administrateur sur le poste local

- configurer ntlmaps et l’exécuter, celui-ci par défaut ecoute sur le port 5865

- dans Putty il faut ensuite configurer le proxy de type HTTP avec l’adresse localhost:5865

- et enfin, il faut faire pointer l’application client sur localhost:53128.