Puisque tous les navigateurs (américains) sont paramétrés par défaut en mode "DEFCON 1", qui produit un effet de "sauve qui peut" sur l'utilisateur non averti, et que le cumulonimbus qui s'ensuit est aussi un business juteux pour les fournisseurs de certificats SSL, j'ai décidé d'apporter ma petite contribution à la dissipation du nuage toxique global en abordant la question sous l'angle conceptuel, façon NetPlusUltra®.
Guide d’introduction au SSL:
Si la plupart des guides d'introduction au SSL vous confirmeront qu'un simple site d'information ne nécessite pas de certification SSL, l'approche par le droit d'auteur conceptualisé que je préconise force à préciser ce premier point en interdisant tout simplement l'anonymat, dans la mesure où il ne peut pas être question de reconnaissance morale de l'auteur sans identification, et que sans droit moral, le droit patrimonial ne peut pas s'appliquer non plus. Ce qui veut dire que le site doit non seulement être signé par son auteur, mais aussi et surtout que la signature doit pouvoir faire l'objet d'une vérification, par le visiteur, du serveur d'hébergement.
Différence entre SSL mutualisé et SSL privé:
C'est donc ici qu'intervient le second critère d'authentification, celui de la localisation de ce serveur d'hébergement. Un auteur qui se respecte ira donc au-delà de la simple question de l'identification, et publiera de sa propre initiative, car c'est dans son double intérêt moral et patrimonial, une page "Conception" apportant un minimum d'informations sur la configuration de son site pour pouvoir se passer de SSL payant jusqu'à ce qu'il soit question de sécuriser des accès à des espaces privés et/ou à des procédures de paiement par l'intermédiaire de formulaires contractuels.
Le SSL mutualisé chez OVH, guides 1 et 2:
Si la vérification que je vous invite à faire sur la page "Scanneurs SSL" de ce site suffit déjà à valider tout ce qui précède, elle a aussi et surtout pour objectifs de permettre aux visiteurs d'interpréter correctement les messages d'alertes de leurs navigateurs, et de rappeler à ces derniers qu'un auteur est en droit d'exiger un minimum de réciprocité de la part de son public en termes de transparence des échanges: l'activation de l'option SSL Mutualisé sur mon hébergement mutualisé sert donc non seulement à (provoquer l'alerte pour) sensibiliser le public à la question, mais aussi à donner à ce dernier l'occasion de prouver à son tour qu'il saura se montrer digne du service de franchise web que je développe.
Conclusion: les guides sur le SSL mutualisé d'OVH ci-dessus confirment (autant que le support technique, auprès duquel j'ai validé mon interprétation) que ce type de certification chiffre les données potentiellement sensibles transitant par les formulaires, tout en constituant un niveau de garantie suffisant pour la sécurisation de certaines transactions bancaires. En termes de confiance entre les différentes parties à l'interaction (l'auteur-prestataire, le visiteur-client, et l'hébergeur tiers-intervenant), la nécessité de passer par la certification d'un auditeur SSL quart-observateur dépendra donc de la rigueur des uns et des autres dans l'ingénierie de leur expérience utilisateur respective. Face à la confusion qui semble régner sur la question, on est ainsi largement en droit de déplorer que la négligence des uns produise une taxe sur la valeur ajoutée des autres - dont elle impacte négativement le prix de revient du service en doublant celui de l'hébergement web-, et d'exiger de la part de chacun un peu plus de transparence préventive en amont.