Champion !
Oui, il s'agit bien de l'option default_sni qui n'était pas utilisée au niveau de caddy. ça fait le café pour avoir une réponse sur Dillo et :
openssl s_client -connect dukeart.netlib.re:443 -tls1_2 -servername 'dukeart.netlib.re'
Je pensais avoir testé l'option au début. Mais je me rends compte que mon service caddy a été modifié par une MAJ, il ne se recharge pas automatiquement quand la conf est modifiée...
Je me suis vite perdu dans le sujet TLS au lieu de faire plus méthodique :). thanks!
Merci pour l'analyse et ton billet (dense mais je peux en tirer des choses) !
Je me suis en effet demandé si Dillo était irréprochable mais je patauge pas mal avec SSL/TLS.
Le coup du SNI c'est assez bizarre en effet, c'est un classique du processus TLS non ?
(En clair : Server Name Indication permet d'affilier plusieurs noms de domaine à une seule IP).
En plus je croyais qu'il y avait un "fallback" vers un certificat unique (ce qui est mon cas) sans SNI...
Dommage pour Dillo et ça me fait relativiser certaines remarques de Bortzmeyer dans son dernier article sur le web compliqué...
Je pense que ça vient quand même de mon serveur (-.-)\
t'as dû mettre EDH avant EECDH.
En TLSv1.3, je peux pas changer l'ordre des //cipher suites// :
https://caddyserver.com/docs/caddyfile/directives/tls
Pour l'instant, avant de vraiment comprendre ou je vais, je dois (ré)viser ^^ :
PSES 2014 : Aeris sur openssl
PSES 2015 : Aeris sur TLS
Ok, j'étais encore avec python3.5 d'un côté et une ancienne version d'openssl. J'ai mis à jour avec python3.7 et on est bon :
2020-12-25 15:42:19,957 DEBUG Starting new HTTP connection (1): ecirtam.net:80
2020-12-25 15:42:20,040 DEBUG http://ecirtam.net:80 "GET / HTTP/1.1" 301 178
2020-12-25 15:42:20,044 DEBUG Incremented Retry for (url='ecirtam.net'): Retry(total=2, connect=None, read=None, redirect=None, status=None)
2020-12-25 15:42:20,044 INFO Redirecting ecirtam.net -> https://ecirtam.net/
2020-12-25 15:42:20,046 DEBUG Starting new HTTPS connection (1): ecirtam.net:443
2020-12-25 15:42:20,351 DEBUG https://ecirtam.net:443 "GET / HTTP/1.1" 200 6628
(Je me demande quand même pourquoi mon client va sur http:80 alors que je lui indique bien du https...)
C'est l'occasion de relire les suggestions de l'IETF, et de jeter sslv3. Du coup (me dis-je) c'est l'ancienne version d'urllib3 qui devrait afficher quelque chose comme "connexion refusée" ou retenter un handshake pour TLS.