Grmmf... C'est ridicule...

Ah bah voilà, tu le dis dans ton billet :

Certes, ce n'est pas simple. Mais au lieu de dépendre de la sécurité d'un tiers extérieur (l'AC, qui constitue donc une cible d'attaque privilégiée et permet de faire tomber tout le bordel. Le modèle des AC a été critiqué maintes fois ces dernières années précisement sur ce point.), vous dépendez de la sécurité globale du DNS, assurée par DNSSEC de bout en bout, ainsi que de votre propre compétence d'admin, ce qui était déjà necessaire et est améliorée grace à cet outil de gestion des certificats ssl.

ca serait si simple...bien vu Augier.
et Mozilla qui veut rendre obligatoire le passage au https.ou bien Google qui référence mieux les sites qui sont en https.

Augier, je suis critique oui...

Il n'empêche que je vais le faire. Les deux : prendre un certif' avec LE et maintenir sa signature avec dane !

Et pourquoi c'est ridicule? Si ça oblige les webmasters à config' leurs sites mieux?

Nan, parce que l'idée d'introduire un tiers de confiance (l'autorité de certification) dans une transaction entre deux partie est contraire à l'architechture d'internet. Le chiffrement, c'est bien, le HTTPS, c'est mal.

Non mais le tiers de confiance n'intervient pas au cours de la transaction...

Il intervient quans alors ?

LE ?

Il intervient quand tu fabrique ton certif'. C'est pas super, mais pour l'instant c'est le mieux que tu puisse faire, car dnssec/dane est très peu déployé/utilisé/reconnu par les nav' et systèmes d'exploit'

LE = Let's Encrypt, autorité de certification automatisée mise en place par Mozilla, EFF et d'autres...

Il intervient aussi à la requête, hein. C'est pour ça que Mozilla maintient ses listes d'AC et que pas mal de sites étaient inaccessibles pendant la période où StartSSL a été down.

Non, il intervient pas à la requete...

Les listes d'ac sont simplement les AC que Mozilla inclut ipso-facto dans son nav'. Et ce sont des fichiers, statiques.

Concernant ta deuxième remarque, c'est peut-être à cause d'un des protocoles de MàJ des certif' ou de leur validité (oscp ou un truc comme ça, je sais plus...).

voila ! http://fr.wikipedia.org/wiki/Online_Certificate_Status_Protocol

Bref, quoi qu'il arrive, il y a quand-même un tiers qui certifie la confidentialité de ta transaction. Et ça, c'est pas l'avenir d'internet, on me fera pas croire ça. Internet a suffisamment de problèmes comme ça. En premier lieu le refus d'adopter IPv6. D'autant que, si je me plante pas, IPv6 a, dans sa norme, un mécanisme équivalent à SSL pour HTTP, non ? Le plus intelligent serait de déprécier au fur et à mesure les sites en IPv4 au profit de ceux en IPv6, non ?

Bref, quoi qu'il arrive, il y a quand-même un tiers qui certifie la confidentialité de ta transaction.

Non. Le tiers en question a le même rôle que quelqu'un signant une clé gpg. Il n'intervient pas dans la transaction.

Et ça, c'est pas l'avenir d'internet, on me fera pas croire ça. Internet a suffisamment de problèmes comme ça. En premier lieu le refus d'adopter IPv6.

C'est pas la question ici. C'est peut-être pas l'avenir, mais c'est son présent. Je dois, tu dois, nous devons... composer avec.

Si tu veux te raccrocher au problème d'internet concernant ssl, raccroche toi à Dane et donc Dnssec.

D'autant que, si je me plante pas, IPv6 a, dans sa norme, un mécanisme équivalent à SSL pour HTTP, non ?

Non plus. Il y a ipsec, mais c'est absolument pas la même chose (et en plus, tu te trompe de couche du modèle OSI). IPsec s'utilse plutôt pour monter des sortes de vpn ponctuels (entre deux points fixes et configurés en communs). Dans l'absolu on pourrait sûrement l'utiliser pour ça, mais ça demanderait un gros effort pour implémenter la chose !

Le plus intelligent serait de déprécier au fur et à mesure les sites en IPv4 au profit de ceux en IPv6, non ?

La encore, c'est une autre question. Elle est légitime, mais c'est autre chose.

Je sais que c'est pas la même couche OSI, j'ai eu un ou deux cours de réseau quand-même. N'empêche qu'IPsec est un mécanisme de chiffrement comme SSL, non ?

Bon, même s'il intervient pas directement dans la transaction, il n'empêche que t'as besoin d'une AC pour signer tes certifs et ça pose à la fous des problèmes de dépendance et de business... Pousser vers cette voie n'es pas une solution intelligente à mes yeux.

N'empêche qu'IPsec est un mécanisme de chiffrement comme SSL, non ?

Cousin éloigné... De la même façon que Linux et BSD sont des cousins Unix-like...

Bon, même s'il intervient pas directement dans la transaction, il n'empêche que t'as besoin d'une AC pour signer tes certifs et ça pose à la fous des problèmes de dépendance et de business... Pousser vers cette voie n'es pas une solution intelligente à mes yeux.

Oui, sur ça je suis entièrement d'accord. La solution est connue et je l'ai citée trois fois dans le fil : dane. Mais...

• Dnssec pas assez déployé
• Dnssec pas assez reconnu par les OS
• Dane pas assez reconnu par les nav' (par aucun nav' majeur de façon natif).

...et ne le sera probablement jamais. Parce que tout ceci est une question de pognon...

Mais si tu peux faire un article sur Dane, expliquer ce que c'est et comment l'utiliser, ça me serai utile pour mon prope serveur.

Y a pas de raison que ça evolue jamais car c'est les nav' qui bloquent actuellement, lesquels nav' n'ont pas les mêmes intérêts que les ac. Et sur le plan logiciel (bibliotheques/ librairies) tout est prêt. ..

Au plan des bases...

Oh, bah tiens, y'en a un qui dit comme moi.

Les gars, vous prenez de mauvais raccourcis !

C'est pas tout chiffrer que tu n'aimes pas, mais la façon dont le système fonctionne.

En soit donc https-everywhere c'est bien!

Je sais pas comment http ms-everywhere est foutu :p

Https-everywhere c'est une ext firefox et une
initiative lancée par wikipedia qui a mis du https partout sur tout son réseau. L'ext ff bascule la navigation web en chiffré dès que possible.

L'initiative de Mozilla est la suite logique.

Vous tous, vous m'avez décidé : y aura un article sur mon blog...

eclaire nous comme tu l as fait pour GPG.

attends, GPG c'est pas fini…