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... :/ )
Les versions 1.8.x d'HAProxy (premier représentant de la branche publié fin 2017) supportent le protocole HTTP/2 pour la communication frontale (section frontend). L'utiliser en
frontend ft_ssl
bind 192.168.0.1:443
mode tcp
option tcplog
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }
acl sslvpn req_ssl_sni -i vpn.example.net
use_backend bk_sslvpn if sslvpn
use_backend bk_web if { req_ssl_sni -m found }
default_backend bk_ssh
backend bk_sslvpn
mode tcp
source 0.0.0.0 usesrc clientip
server srvvpn vpnserver:1194
backend bk_web
mode tcp
source 0.0.0.0 usesrc clientip
server srvhttps webserver:443
backend bk_ssh
mode tcp
source 0.0.0.0 usesrc clientip
server srvssh sshserver:22
Je ne suis pas tout à fait d'accord avec toi Seb.
Car tu peux très bien autosigner un certificat, ou te faire délivrer un certificat par une autorité qui elle prone la liberté d'expression (même si il n'y en a pas encore à ma connaissance).
Et puis rien n'empeche d'ajouter une autorité de certification Tor dans le bundle Tor pour que des sites https via tor puisse utilisé un certificat dérivé.
Par contre ce qui me chagrine le plus c'est que cela soit plus de la poudre au yeux pour que les gens se "croient" en sécurité.
En HTTPS TOUTES les connections partagent le même certificat, ce que je veux dire c'est qu'il "suffit" d'enregistrer les flux chiffrés et de mettre la main (avant ou après) sur la clé privé du serveur. et tu peux TOUT déchiffré.
(sauf pour le forward secrecy je crois mais faut que je vérifie)
Cela ne remplacera pas un échange de clés de chiffrement pour chaque connection, en tout cas ce n'est pas aussi sécurisé....
Bref, laissez faire, la NSA n'aura qu'a se contenter des méta donnés, pour faire le tri dans les enregistrements de flux et cibler les attaques vers les serveurs intéressant pour récupérer la clé.
Tiens, je me demande si il ne serait pas possible de générer une négociation avec un flux d'entrée connu afin de pouvoir faire une analyse statistique du résultat afin d'avoir des infos sur la clé (comme l'entropie utilisée...) ?
Effectivement je pouvais faire mieux...
c'est mieux la : https://www.ssllabs.com/ssltest/analyze.html?d=trytolisten.me ?
j'en ai profité pour passer l'application en français et permettre les autres langues.
du coup je vais faire évoluer l'anglais et le français dans un premier temps.
ensuite on verra.
Fréd.
Pas mal cette implémentation de websocket en PHP.
avec Nginx version
et la configuration suivante :
location /hello/ {
proxy_pass http://localhost:5001;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
J'ai juste changé le code pour se connecter à la socket dans front.html comme suit :
var ws, url = 'wss://"domain"/hello/';
et hop ça roule ! ;)
Du coup je fais du websocket en php sous https avec le même port (443) ;) merci nginx.
Il faut juste penser à lancer le "serveur" php via :
php -q ppws_server.php
Testé sous la dernière version de firefox
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=