Guide pratique : utiliser PGP pour Windows
Pour un échange d'emails sécurisé et fiable avec PGP, vous avez besoin d'utiliser à la fois ces trois programmes : GnuPG, Mozilla Thunderbird and Enigmail. GnuPG est un logiciel qui en réalité chiffre et déchiffre le contenu de votre courriel. Mozilla Thunderbird est un logiciel de messagerie, qui vous permet de lire et de composer des emails sans recourir à un navigateur. Finalement, Enigmail, est un module complémentaire qui sert de lien entre ces fonctionnalités et agence le tout.
Modification a faire pour gerer gpg-agent
dans C:\Program Files\Git\cmd> start-ssh-pageant
:ssh-pageant-done
gpgconf --launch gpg-agent
:failure
OpenSSH Integration with Pageant
For some users, it may be desirable to tie OpenSSH in to the PuTTY authentication agent (Pageant) using ssh-pageant. This is a drop-in replacement for ssh-agent, which simply builds a connection between OpenSSH and Pageant for key-based authentication. The tool makes it easy to leverage OpenSSH for remote repository access, which tends to be the most reliable choice within the specific context of Git for Windows (Git), without the need to run multiple agents which don't interoperate.
This functionality became available with the release of Git 2.8.2.
Starting ssh-pageant Manually from Git Bash
If you always use Git from within Git Bash, then the most straightforward approach is to have it launch ssh-pageant on your behalf. Simply create/edit your _$HOME/.bashprofile (or $HOME/.profile, if you prefer), and add the following.
# ssh-pageant allows use of the PuTTY authentication agent (Pageant)
SSH_PAGEANT="$(command -v ssh-pageant)"
if [ -x "$SSH_PAGEANT" ]; then
eval $("$SSH_PAGEANT" -qra "${SSH_AUTH_SOCK:-${TEMP:-/tmp}/.ssh-pageant-$USERNAME}")
fi
unset SSH_PAGEANTThe -qra "${TEMP:-/tmp}/.ssh-pageant" construct is equivalent to the -q -r -a filename options. In this context it means:
- -a filename -- Bind to a specific socket file (creating it if necessary)
- -r -- Allow reuse of an existing socket file (exit without error if an existing ssh-pageant/ssh-agent process is using it)
- -q -- Quiet mode (don't echo the PID, if starting a new ssh-pageant process)
By specifying the socket name (defaulting to $SSH_AUTH_SOCK, if set) along with the reuse option, we ensure that only a single running copy of ssh-pageant (per user) is required. Otherwise a separate incarnation would be launched every time Git Bash is invoked.
Verify ssh-pageant Functionality
Now start a new Git Bash session, or source the profile edited just above, and run the ssh-add -l command. If all is well, and Pageant is running (with one or more keys loaded), you should see something similar to the following.
$ ssh-add -l
4096 SHA256:XjN/glikgdBoBclg4EaN8sJ/ibrxTq7zVydpkUwANzk Heinz Doofenshmirtz (RSA)Starting ssh-pageant Automatically at Logon
If you use Git from Git CMD, or directly from the Windows command prompt, then you'll probably want to ensure that ssh-pageant is launched automatically at logon time. The start-ssh-pageant.cmd script is provided for this purpose, which resides in the cmd subdirectory of your Git installation.
Setting the Environment
Unlike the Git Bash case above, this scenario requires the SSH_AUTH_SOCK environment variable to be set before running the script... otherwise it will simply exit without performing any action. This is normally configured as a persistent USER variable, with the value specifying the desired socket file path in Unix/MSYS2 format.
NOTE: Since there can only be a single global variable of a given name, this approach may or may not cause conflicts if you have multiple environments which utilize the SSH_AUTH_SOCK setting. Running Git alongside of Cygwin, or MSYS2, for example. One way to address this is to use a fully-qualified Windows path for the socket instead of an environment-specific Unix/MSYS2 path.
Windows 7
Launch the Control Panel, and then select System followed by Advanced system settings. Click on the Environment Variables button, and finally New... in the User variables (not System variables) section. Enter SSH_AUTH_SOCK for Variable name and /tmp/.ssh-pageant-%USERNAME% for Variable value, then click OK.
Now launch a new Git CMD or Windows command prompt (pre-existing sessions won't see the new variable), and enter the command set SSH_AUTH_SOCK. If all went according to plan, you should see something similar to the following.
C:\Users\heinz.doofenshmirtz> set SSH_AUTH_SOCK
SSH_AUTH_SOCK=/tmp/.ssh-pageant-heinz.doofenshmirtzNOTE: the cross-environment-compatible (git for windows, msys2, and cygwin) equivalent would require a fully qualified windows path like C:\Users\MYUSERNAME\AppData\Local\Temp\.ssh-pageant-MYUSERNAME. The correct value can be determined by running a command like cygpath --windows /tmp/.ssh-pageant-%USERNAME% in a Git Bash window.
Launch ssh-pageant
At this point you should run start-ssh-pageant.cmd manually, in order to verify that the agent starts successfully. Assuming that Git is installed into C:\Program Files\Git, this should look something like:
C:\Program Files\Git\cmd> start-ssh-pageant
Starting ssh-pageant...
SSH_AUTH_SOCK='/tmp/.ssh-pageant-heinz.doofenshmirtz'
SSH_PAGEANT_PID=11444Assuming that the relevant keys have been loaded into Pageant, you should now be able to perform Git operations which rely upon them using OpenSSH without being prompted for the passphrase.
Configure Automatic Startup
The most common approach is to create a shortcut pointing to start-ssh-pageant.cmd, and place it in your startup folder (Start Menu / Programs / Startup). Once in place, it should be launched automatically when you logon to Windows and be available to all Git processes.
Windows 7
- Click the Start button, right click on All Programs, and select Open
- Navigate into the Programs folder, followed by Startup
- Right-click on an empty spot within Startup, and select New / Shortcut
- Click Browse, navigate to the cmd folder underneath your Git installation, and select start-ssh-pageant.cmd. Click OK.
- Click Next
- Enter an alternate name for the shortcut, if desired, and click Finish
Security Considerations
Since ssh-pageant (like ssh-agent) is intended to bypass the requirement to repeatedly enter your private key password, it's imperative that its socket file be private in order to use it safely. In other words, you want to be extremely careful on multi-user systems to ensure that the SSH_AUTH_SOCK file -- and preferably the directory which includes it -- isn't accessible to anyone else. For a normal Git for Windows configuration this shouldn't be an issue, as /tmp is normally mapped to a private location under your Windows user profile.
Pour gérer mes mots de passe, j’utilise l’excellent outil pass du projet password-store. Celui-ci utilise GnuPG pour chiffrer chaque mot de passe. J’ai récemment changé de système d’exploitation (j’y reviendrai probablement en détails dans un prochain article) et je suis tombé sur deux problèmes avec ces deux outils. Comme j’ai mis un certain temps à trouver la cause et la solution à chacun de ces deux problèmes, je les partage ici si cela peut aider quelqu’un. « Pas de clef secrète » Le problème Après avoir migré vers mon nouveau système d’exploitation et après avoir installé password-store, je demande un mot de passe et j’obtiens une erreur inquiétante : $ pass show
echo use-standard-socket >> ~/.gnupg/gpg-agent.conf
echo enable-ssh-support >> ~/.gnupg/gpg-agent.conf
$ echo $SSH_AUTH_SOCK
/run/user/1000/gnupg/S.gpg-agent.ssh
$ gpgconf --list-dirs agent-ssh-socket
/run/user/1000/gnupg/S.gpg-agent.ssh
$ systemctl --user show-environment | grep SSH_AUTH_SOCK
SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh
$ cat << EOF > $GNUPGHOME/gpg.conf
use-agent
personal-cipher-preferences AES256 AES192 AES CAST5
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
cert-digest-algo SHA512
s2k-digest-algo SHA512
s2k-cipher-algo AES256
charset utf-8
fixed-list-mode
no-comments
no-emit-version
keyid-format 0xlong
list-options show-uid-validity
verify-options show-uid-validity
with-fingerprint
EOF
Pour avoir une clé gpg pas cher :) qques € pour 2 stlink sur ali
Bonjour,
Je vous présente mon nouveau projet,
Try To Listen. Me
Ce projet se base sur openPGP.js et cherche à proposer une plateforme de partage de document (uniquement un chat pour le moment) chiffré de bout en bout.
Lors de la création d'un compte, le navigateur créé une paire de clé privé/publique, seul la clé publique est envoyé sur le serveur.
La clé privée est enregistré dans le localStorage du navigateur.
elles sont toutes les deux visible dans la page Account.
Ensuite pour se connecter vous utilisez votre nom et la passphrase choisie lors de l'enregistrement (le mot de passe de la clé en fait)
Et vous devez partager votre nom et votre fingerprint avec vos amis.
ils font de même et vous pouvez les ajouter sur la page Chat.
Ensuite lorsque vous envoyer un message il est chiffré avec la clé publique de votre ami, et envoyé sur le serveur.
Les messages de vos amis sont chiffré coté navigateur avec votre clé publique ce qui vous permet de les déchiffrer.
Je suis à l'écoute si vous avez des questions.
Memiks.
PS: je fais une campagne de don pour pouvoir continuer le développement alors s'il vous plait participez ou parlez en autour de vous:
https://www.indiegogo.com/projects/trytolisten-me-web-site-privacy/x/9871293
A la fin de la récolte je libère les sources sous AGPL.
techno:
- javascript
- openpgp.js
- jquery
- skeleton css
- php
- phalcon framework.
Aucune distribution n'est à l'abri...
Si ce sont les librairies comme OpenSSL / OpenSSH / OpenGPG qui sont corrompu...
Toutes les distributions les utilisent.
Par contre on peut mettre en place un "bruit de fond" en chiffrant TOUTES les données afin de les obliger à acheter en masse des supercalculateurs (et du coup cela se verra sur les factures ;) ).
Et surtout les obliger à "perdre du temps" en déchiffrant tout...
Je pense que la solution vient de la masse critique a atteindre pour que le gain à nous écouter soit plus faible que celui du cout à mettre en place pour cela.
Après un site "sensible" ne devrait être ouvert à ses clients même en HTTPS que via login/mot de passe...
et c'est pas forcément faisable pour une banque ou autre...
du coup c'est aussi pour cela que j'ai eu l'idée du GPG pour remplacer HTTPS.
Par contre il faut vraiment que je teste une implémentation même bardé de bug et de trou de sécurité, le code sera GPL les experts feront ce qu'il faut...
http://sebsauvage.net/paste/?3b0e29b95f7a3b01#lKn5Db6+znQlj7QPmwyuDo2/2NbbsOh46CzoycvA3ds=
Idée d'un nouveau module pour Apache.
mod_gpg_protocol
qui définit une requête / réponse encrypté par GPG.
comment fonctionne le module ?
Création d'un nouveau protocole dans les navigateurs Gpg Over Server: GOS
lorsque vous allez sur l'adresse gos://www.memiks.fr/
le navigateur va crypter votre demande en GPG avec la clé publique que vous avez spécifié sur le serveur (j'en reparlerai).
puis la requête est envoyée au serveur un simple header http qui contient un type d'application text/gpg
et le serveur "sait" qu'il doit décrypter la demande avant de l'interpréter.
la le serveur peux fonctionner comme d'habitude, via les autres modules, php, asp, proxy etc...
quand la réponse est récupérée, alors on la crypte avec la clé publique et une fois reçu le navigateur la décrypte.
Pourquoi ?
- fournir un niveau plus élevé de cryptage (plus que https qui repose sur la confiance des instances)
- permettre l'envoie de données sensible dans des réseaux qui sont publique (notamment wifi, entreprise, proxy)
- rendre impossible le man in the middle (si il n'y a pas eu compromission du client ou du serveur)
- lutter contre les formes d'écoute gouvernementale.
maintenant les points qui fache:
-
comment fournir la clé publique/privé sans passer par internet ? je vois plusieurs possibilités
1) on passe par une clé temporaire qui crypte la clé finale, et qui est fourni par un autre canal, mail, https, ssh, lettre
2) vous êtes maitre du serveur et donc maitre de la publication / génération de la clé (ssh, sftp etc...)
3) l'instance (par exemple la banque) vous fourni les clés par lettre ou physiquement -
comment crypter coté client ?
1) ajout du module directement dans les navigateurs (firefox, chromium)
2) passage par une extension
3) passage par un proxy qui s'occupe de tout crypter suivant les serveurs (via une liste blanche) -
que faire lorsqu'il y a perte de l'intégrité du client et/ou du serveur ?
1) client volé, ou compromis, demandé la dévalidation de la clé au serveur (par tél, mail, chat, etc on s'en moque même en clair, la clé est invalidée POINT!)
2) serveur non fiable, invalidér la clé correspondante sur le client.
3) NE PAS UTILISER DEUX FOIS LA MEME CLE C'EST COMME LES MOTS DE PASSES !!
Qu'en pensez vous ?
J'ai ouvert la discussion sur zerobin
http://sebsauvage.net/paste/?3b0e29b95f7a3b01#lKn5Db6+znQlj7QPmwyuDo2/2NbbsOh46CzoycvA3ds=
Mêmiks