use_backend main-ssl if { req.ssl_hello_type 1 }
#use_backend openvpn if !{ req.ssl_hello_type 1 } !{ req.len 0 } // j'ai pas de VPN sur mon serveur.
use_backend xmpp if { payload(0,5) 3c3f786d6c } !{ req.ssl_hello_type 1 } !{ req.len 0 }
use_backend xmpp if { payload(0,5) 3c3f20786d6c } !{ req.ssl_hello_type 1 } !{ req.len 0 }
3c3f786d6c pour <?xml
3c3féà786d6c pour <? xml (en fonction des logiciels... :/ )
Pour faire en sorte que Dovecot communique en SSL avec le client gmail android (par exemple) il faut spécifier la fullchain dans la configuration (pour que le certificat puisse être validé)
ssl_cert = </etc/letsencrypt/live/YOURSITE/fullchain.pem ssl_key = </etc/letsencrypt/live/YOURSITE/privkey.pem
Pas mal cet article ;)
j'ai chécké le site de ma femme je suis déjà bon:
https://www.ssllabs.com/ssltest/analyze.html?d=votreshihtzu.com
merci ;)
Alors comme je l'ai dit, oui tu as raison je dois mettre en place https.
dans le cas1 je pense pas que ça change grand chose... les gouvernements vont "simplement" enregistrer le flux chiffré https et le déchiffrer avec la clé du serveur (ils auront bien trouvé comment récupéré les clés)
par contre pour le cas 2 je ne vois pas comment le MITM va etre mis en place... c'est TOI qui fourni le fingerprint à tes amis.
et il est récupéré de la clé publique du serveur.
du coup si la clé de chiffrement/déchiffrement n'est pas la même que le fingerprint, openPGP et trytolisten vont refusés de décrypter le message.
mais effectivement, c'est un bon moyen pour trouver les failles dans l'application.
donc je résume seul la clé public est envoyé avec le fingerprint et le nom de l'utilisateur. avec une seul parti tu ne peux pas faire de MITM à moins d'avoir enregistré les clés des deux protagoniste au moment de la création du compte et de les remplacer (et encore les fingerprint rentré dans l'interface ne seront pas les bons du coup).
Mais oui de toute façon je dois mettre en place HTTPS.
Je suis d'accord avec toi... et en même temps pas trop...
je m'explique, lorsque tu envoie les données, la seule clé qui passe en clair est celle publique, ensuite elle est enregistré sur la base en rapport avec le fingerprint.
meme si quelqu'un écoute le réseau et remplace la clé par une autre, cela se verra de suite car le receveur ne pourra pas déchiffrer le message.
mais oui je pourrais ajouter le ssl avec startssl pour chiffrer aussi les envoies ;)
bonne idée, je vais le faire.
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.
Resume, Java, Servlet, JSP, XML, XSL, Wireless, Palm, WML, WAP, Perl, Online Trading, Financial Applications, C/C++, JavaScript, Unix, Solaris, Linux, Sybase, Oracle, DB2, MySQL, CGI, Apache, mod_perl, HTML, DHTML, CSS, SSL, CORBA, RMI, WebLogic, WebSphere, Apache/Stronghold, Netscape Enterprise Server, Dreamweaver, Adobe Photoshop