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 lesurfeurfou | 

Je note que les url ne s’affichent plus en vert, normal ?

avatar free00 | 

Tu parles des certificats DV ou EV ?

avatar Mrleblanc101 | 

@lesurfeurfou

Ca fait longtemps... Il était facile de faire un site mal intentionné et d'y ajouter un certificat HTTPS pour avoir une URL verte qui faisait croire que le site était légitime.

Maintenant, les URLs HTTPS ne sont plus considéré comme "sécurisé" et HTTP "normal". Le HTTPS est considéré comme "normal" et le HTTP comme "non sécurisé".

avatar melaure | 

@Mrleblanc101

Ca risque d’etre compliqué a gérer pour les gens non techniques qui se font un petit site perso avec des générateurs de site comme RapidWeaver ou plus anciennement iweb ...

avatar pocketjpaul | 

@melaure

Non du tout.

La plupart des hébergeurs offrent un certificat https de nos jours (mis en place automatiquement).

Pour les gens qui ont leurs propres serveurs, une petite installation de let’s encrypt et c’est réglé. C’est très simple à faire, installation et renouvellement automatique gratuits.

Ce sont des certificats qui n’apportent que le chiffrement de la connexion et aucune autre assurance, mais c’est l’argent suffisant pour qui ne souhaite pas assurer les données qui transitent par son site web (en gros si tu traites pas de données sensibles).

avatar oomu | 

"Pour les gens qui ont leurs propres serveurs, une petite installation de let’s encrypt et c’est réglé. C’est très simple à faire, installation et renouvellement automatique gratuits."

non, ce n'est pas "très simple à faire".

et certainement PAS pour des personnes non techniques (artistes, artisan, hobbyistes, petite asso) qui voulaient juste un site web perso et auto-hebergé.

avatar heu | 

@oomu

L’artisan n’héberge pas son site sur son serveur. Il passe par un prestataire qui lui, va lui générer un certificat avec let’s encrypt.

avatar Mrleblanc101 | 

@melaure

Quel est le rapport ? Absolument rien n'as changer par rapport à avant. Simplement l'URL n'est plus verte en HTTPS. Et seul les sites avec un formulaire sont marqué non-sécurisé en HTTP

avatar lesurfeurfou | 

@Mrleblanc101

👍

avatar free00 | 

L’article ne précise pas les certificats issues des autorités d’entreprise (par exemple .corp), y-a-t-il aussi des changements de ce côté ?

avatar koko256 | 

Les certificats ne servent plus à chiffrer les connexions. Seulement à signer.

avatar dodomu | 

@koko256

Heu... Si en fait ?
Édit: voir la réponse de xDave, plus complète que la mienne 😇

avatar koko256 | 

@dodomu

Sa réponse confirme ce que je dis. Le certificat permet d'authentifier (j'ai écrit signé car c'est un algo de signature qui est utilisé mais authentifier est un meilleur terme). Le chiffrement se fait avec un algo de génération de secret partagé (en général ECDHE ou RSA voire DH mais comme il est un peu cassé c'est une mauvaise idée) et de l'AES/GCM et autre AEAD.

avatar koko256 | 

@dodomu

Pour préciser, on pourrait chiffrer avec un certificat mais ce n'est pas utilisé sur le web. C'est une mauvaise idée car il faut utiliser sa clé privée le moins possible pour réduire les chances de compromission.

avatar dodomu | 

@koko256

Sauf que c’est le dit certificat qui contient les informations permettant d’établir la connexion sécurisée (les algorithmes supportés par exemple), il est donc utile et utilisé pour le chiffrement de la connexion.

avatar koko256 | 

@dodomu

Non. Le certificat ne mentionne que les algos compatibles avec les clés publiques qu'il contient mais rien pour le chiffrement de la connexion TLS. C'est d'ailleurs la base de la forward secrecy.

avatar dodomu | 

@koko256

Il contient aussi accessoirement la clé publique à utiliser dans le cadres du chiffrement RSA, difficile d’établir une connexion chiffrée sans 😉

avatar Iounmoutef | 

@Melaure. J’ai été confronté au problème pour les dizaines de sites réalisés pour mes clients (ou pour moi-même). Heureusement un ami m’a donné les bons renseignements (désolé mais je suis en déplacement et je n’ai pas ces éléments avec moi) : émetteur de certificats gratuits, procédures d’installation... et renouvellement automatique. Tout ceci complique pas mal la vie des animateurs des « petits » sites. Le net est de plus en plus entre les mains des « gros »... contrairement aux promesses de ses débuts.

avatar oomu | 

"Le net est de plus en plus entre les mains des « gros »... "

oui

on le rend "administrativement" lourdingue, pour que vous jetiez l'éponge et payiez le Oomu. (y a bon sousous dans popoche oomu)

"contrairement aux promesses de ses débuts."

ce ne fut jamais une promesse du web.

Par contre ses "promesses" étaient :
- universel (marche sur toute machine)
- ouvert (pas un éditeur en particulier à contacter pour avoir le sésame)
- académique, partage de la connaissance, hypertexte tout ça
- SIMPLE

avatar abioninho | 

‘Risque probable de sécurité’

C’est quelle Langue ?

avatar pagaupa | 

La loi du plus fort ...

avatar pacou | 

Let’s encrypt : 90 jours
Tout est dit.

avatar Link1993 | 

Y'a Darknet Diares qui avait fait un super épisode sur un hacking de CA en 2011. Ça va bien avec le sujet ! 😉

https://podcasts.apple.com/fr/podcast/darknet-diaries/id1296350485?i=1000393471755

avatar Lightman | 

@Link1993

Malgré le fr dans le lien de Link (😛), ce podcast est en anglais. Déception.

avatar MarcMame | 

« 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é »

——————
A ma connaissance, les certificats n’ont aucun rôle actif dans le chiffrement des connexions. Ils ne servent qu’à s’assurer de la légitimité de cette connexion et à rien d’autre.
Sans certificat le chiffrement reste valable. On a juste un message flippant du navigateur.

Dites moi si je me trompe.

avatar xDave | 

Les certificats servent à authentifier / certifier de l'identité (ici du site).
Ils contiennent plusieurs bouts de données comme (numéro de série du certif, algorithme de chiffrement utilisé, nom de l'autorité de certif, dates début/fin de validité, clé publique, …)

On peut avoir un certificat auto-signé (pour un usage perso/privé mais qui n'empêchera pas l'affichage du message "flippant" à la première connexion sauf si le poste client est configuré au préalable*) ou un certificat délivré par une autorité de certification (CA), ce dont on parle dans l'article.

*Dans le cas d'un intranet ou d'un site de test, on connait les utilisateurs doc on peut gérer "facilement" le certificat et le distribuer, alors que sur un site public les utilisateurs sont inconnus (anonymes) d'où le fait de passer par un tiers (l'autorité de Certification) pour "garantir" l'authenticité du site

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 ;)

CONNEXION UTILISATEUR