Validité d'un an pour les certificats HTTPS : Google et Mozilla suivent Apple

Stéphane Moussie |

Google et Mozilla se sont alignés sur la position d'Apple concernant la validité des certificats HTTPS. En mars, Apple annonçait un changement à venir dans sa gestion des certificats HTTPS : à compter du 1er septembre 2020, Safari n’acceptera plus que les certificats ayant une durée de vie de 389 jours au maximum. Chrome et Firefox vont faire de même, signale ZDNet.

Exemple d'avertissement sur Firefox quand le certificat est invalide.

Les certificats HTTPS sont devenus un élément essentiel du web : ils assurent le chiffrement de la connexion entre votre navigateur et le site visité, et permettent de vérifier l'authenticité du site (quand vous cliquez sur l'icône de cadenas dans la barre d'adresse). Sans certificat valide, les navigateurs affichent une alerte recommandant de ne pas visiter le site.

Alors que la politique en matière de certificats HTTPS est normalement conduite par le CA/B Forum, un groupe rassemblant une trentaine d'autorités de certification et les cinq plus gros éditeurs de navigateurs, Apple a décidé unilatéralement de raccourcir, de fait, la validité des certificats de deux ans à un an environ.

L’objectif est de multiplier les vérifications et de permettre un renouvellement plus rapide pour accélérer les transitions technologiques. La sécurité des certificats se renforce en effet régulièrement et en les renouvelant tous les ans, les nouveautés seront généralisées plus vite.

Certaines autorités de certification étaient opposées à cette mesure, mais elles n'auront d'autres choix que de s'y plier, les trois principaux navigateurs appliquant bientôt le changement. « Nous ne voyons aucun gain de sécurité ou d'autres avantages en réduisant la durée de vie des certificats », déclare D-Trust dans une réponse envoyée au CA/B Forum.

Microsec avertit pour sa part que ses frais annuels pourraient « augmenter significativement » en raison des vérifications plus fréquentes qu'elle devra réaliser. Bien qu'elle soit déjà prête, cette autorité de certification n'a pas encore mis en pratique ce changement par crainte d'être plus chère que ses concurrents.

avatar MarcMame | 

@xDave

Donc c’est bien ce que je dis.
Le certificat n’a pas de rapport avec le chiffrement.

avatar oomu | 

" Le certificat n’a pas de rapport avec le chiffrement."

c'est faux. Le certificat a évidemment un rapport avec le chiffrement: il fournit les clés et algorithmes.

c'est un chiffrement asymétrique.

Vous pourriez vous contenter de signer (c'est à dire chiffrer un petit bout de message) pour garantir votre identité.

Ce n'est pas ce que font les sites web en HTTPS. Toute la communication est chiffrée. Cela via la clé privée du serveur et le certificat publique.

ça sert simultanément à tout chiffrer ET garantir l'identité déclarée du site web (car vous faites confiance à l'autorité de certification, hein ? vous lui faites confiance n'est-ce pas ? hein ?hein ?!)

avatar MarcMame | 

@oomu

"c'est faux. Le certificat a évidemment un rapport avec le chiffrement: il fournit les clés et algorithmes."

D’accord oh grand oomu.
Au temps pour moi donc.

Mais alors comment se fait-il que je puisse quand même chiffrer les connexions externes avec mon NAS même si je n’utilise pas de certificat (avec tous les popups d’alarmes qui font trop peur) ?

avatar Sometime | 

@MarcMame

C’est probablement une question de sémantique. On peut en effet techniquement faire du chiffrement sans certificat, ou sans cryptographie asymétrique. Même si ce n’est pas précisément le cas avec SSL/TLS

A quel protocole faites vous référence dans votre cas?

avatar MarcMame | 

@Sometime

WebDAV

avatar Sometime | 

@MarcMame

Il faudrait vérifier mais il me semble que webdav est basé sur http, et dans le cas classique sécurisé en transit par https.
Vous utilisez peut-être une implémentation propriétaire, ou alors une application spécifique. Peut-être qu’un certificat spécifique a été installé sur votre appareil auquel cas vous n’auriez pas nécessairement les alertes. Vous êtes enfin bien sur que c’est sécurisé?

avatar MarcMame | 

@Sometime

C’est une implémentation Synology.
J’ai bien précisé que j’avais bien les alertes sur le client sans certificat.
Je peux générer un certificat depuis le NAS à installer sur le client et dans ce cas : plus d’alerte.
Dans les 2 cas la connexion est bien chiffrée.

avatar Sometime | 

@MarcMame

Ah je pense que je comprends. Quand vous dites:
« Mais alors comment se fait-il que je puisse quand même chiffrer les connexions externes avec mon NAS même si je n’utilise pas de certificat (avec tous les popups d’alarmes qui font trop peur) ? »

De ce que vous en décrivez vous utilisez en fait dans tous les cas bien un certificat. Ou plutôt votre server vous présente un certificat TLS qui permet de chiffrer des connections. Partant de cette situation vous pouvez ou non l’installer sur votre client (lui faire confiance a lui spécifiquement, ou alors a lui et aux autres certificats généré par Synology ) et cela va vous éviter les alertes - en plus de vous éviter certaines attaques.

Bref de ce que vous en décrivez vous semblait toujours utiliser un certificat, que vous l’installiez ou non est plus lié a la confiance que vous lui accordez localement, pas à l’utilisation ou non du chiffrement.

avatar MarcMame | 

@Sometime

"Bref de ce que vous en décrivez vous semblait toujours utiliser un certificat, que vous l’installiez ou non est plus lié a la confiance que vous lui accordez localement, pas à l’utilisation ou non du chiffrement."

C’est ça 😉

avatar oomu | 

le terme de "certificat auto-signé" ce n'est pas ce que vous pensez.

cela signifie qqu'on chiffre avec un certificat qu'on a créé soit-même de sa propre autorité (pouf : certificat créé par Oomu, avec clé privée Oomu)

Le soucis avec cela c'est que monsieur Mozilla, Microsoft, Apple et tout le reste du monde OSENT ne pas faire confiance à Oomu et sa clé privée. Oui, je suis comme vous : choqué d'une telle impudence.

Mes certificats signés par moi même (qui marchent très bien pour chiffrer donc) ne sont pas "dignes de confiance".

Windows, macOs, votre iphone, etc vont dire "ouais heu c'est chiffré ,oui, mais l'autorité Oomu.. moi.. j'connais po, c'est ptet qu'un chevelu corse qui écrit sur des forums orange: MEFIANCE !", et le navigateur web va faire plein de popup d'alertes pour effrayer son utilisateur.

un certificat auto-signé ce n'est donc pas idéal : ça ne rassure pas les visiteurs d'un site web PUBLIC. C'est par contre très bien pour chiffrer un service privé, entre machines que vous maîtrisez.

Bref, pour un site "public", on doit utiliser un certificat signé par une autorité de CONFIANCE.

Tous les navigateurs du marché sont fournis avec les certificats d'AUTORITE (CA) des principales entreprises de certificats. Elles sont "de confiance". et cette liste évolue tout le temps au grès des rachats, déceptions, piratages de ces entreprises de "confiance" (Ayez Confiance a dit Verisign...)

c'est une question de CONFIANCE.

Mais que le certificat soit "auto-signé" (par moi pour mon usage à moi que j'ai) ou signé par une autorité de confiance, dans les DEUX cas, le certificat et sa clé privée associée servent pour CHIFFRER TOUTE la communication.

avatar oomu | 

"Dites moi si je me trompe."

vous vous trompez.

avatar fte | 

@MarcMame

"Dites moi si je me trompe."

Tu te trompes. Ils servent également à échanger de façon sécurisée une clé de chiffrement symétrique.

avatar Plastivore | 

Qu'est-ce qu'il faut pas lire… Comme indiqué par Oomu, les certificats permettent d'abord de chiffrer la connexion, mais aussi à authentifier le serveur. Ça marche pour le HTTPS, SMTPS et consorts.

Le truc, c'est que c'est bien de chiffrer la connexion, mais ça sert pas à grand chose si on ne peut pas s'assurer que le serveur auquel on se connecte est bien celui qu'il prétend être. Sinon, je monte mon petit proxy, utilise un moyen quelconque (DNS poisoning, ver, etc) pour rediriger le trafic vers le site de votre banque sur mon proxy, et à moi vos identifiants et coordonnées bancaires (ben oui, navigateur ne donnera pas d'avertissement si le protocole ne permet pas l'authentification) !

Et c'est en ça que Let's Encrypt est génial, c'est pas la mort à mettre en place (si on sait installer un serveur Web, c'est pas super difficile de suivre un tuto pour utiliser la commande certbot), hyper facile de renouveler les certificats quand ils arrivent à expiration (certbot renew), et Let's Encrypt joue bien son rôle d'authentification (sinon, ça n'aurait aucun avantage sur les certificats autosignés).

avatar Beaubarre | 

@Plastivore

Oui - en gros tu as juste UNE solution Let's Encrypt, le jour ou cela tombe en rade - ou tout simplement tu ne parles pas anglais, ou tout simplement étant basé aux USA tous les sites sont enregistrés par la NSA et ton pays est blacklisté parce que tu dis du mal de Trump ...

Bref ces décisions ne renforcent que peu la sécurité voire la rend fragile avec des points uniques de vulnérabilité tout en renforçant le pouvoir des mastodontes.

avatar fte | 

@Beaubarre

"Oui - en gros tu as juste UNE solution Let's Encrypt"

Non. Il n’y a pas juste une solution. Il y en a des myriades. Mais des myriades pas nécessairement gratuites et peut-être pas si simples et intégrées.

Le point de fragilité n’est pas Let’s Encrypt, unique ou pas, il est sur le site qui ne prévoit aucune solution alternative en cas de "contrariété".

avatar trouaz | 

Sur le site de ZDNet, Apple et Google il y a marqué 398 jours et pas 389 comme écrit ici ;)

Pages

CONNEXION UTILISATEUR