Le 15 septembre 2026, GitHub a coupé le SHA-1 dans ses connexions HTTPS et TLS. Neuf ans après la publication de SHAttered, la première collision pratique jamais produite contre cette fonction de hachage, la plus grande plateforme d’hébergement de code au monde a fermé une porte qu’elle avait laissée entrouverte depuis longtemps. Le changement touche github.com, ses CDN partenaires, GitHub Enterprise Cloud et GitHub Enterprise Cloud with Data Residency. Il s’inscrit dans un mouvement plus large : le CA/Browser Forum a voté fin janvier 2026 l’interdiction totale du SHA-1 dans les certificats TLS publics, avec un score sans appel de 26 voix pour et zéro contre chez les autorités de certification, et 4 voix pour et zéro contre chez Apple, Google, Microsoft et Mozilla. Pour les équipes techniques françaises et européennes qui utilisent encore de vieux clients Git, des proxys d’entreprise anciens ou des pipelines CI/CD figés depuis des années, la fenêtre pour s’adapter s’est refermée.
Ce qui a changé le 15 septembre 2026
Selon l’annonce officielle publiée sur le changelog de GitHub, la désactivation du SHA-1 dans les connexions HTTPS et TLS est désormais effective pour github.com et pour les CDN partenaires de la plateforme. Le message est sobre mais sans ambiguïté : “Following the planned schedule, GitHub has disabled SHA-1 in HTTPS for github.com and partner CDNs, including GitHub Enterprise Cloud and GitHub Enterprise Cloud with Data Residency.” Concrètement, tout logiciel, navigateur ou client Git qui ne sait négocier qu’un algorithme de hachage SHA-1 pendant la poignée de main TLS ne peut plus se connecter à GitHub en HTTPS.
Ce changement ne concerne pas les objets internes d’un dépôt Git, ni les commits, ni les hachages qui identifient chaque fichier versionné. Il vise uniquement la couche de transport, c’est-à-dire les algorithmes cryptographiques utilisés pour établir une connexion chiffrée entre un client (navigateur, client Git, script utilisant l’API GitHub) et les serveurs de la plateforme. GitHub Enterprise Server, la version auto-hébergée du produit, n’est pas affecté par cette bascule : les entreprises qui font tourner leur propre instance restent sur leur calendrier de mise à jour.
SHAttered, la faille qui a condamné SHA-1 il y a neuf ans
Pour comprendre pourquoi GitHub ferme ce dossier en 2026 seulement, il faut remonter à février 2017. Des chercheurs de Google et du CWI Amsterdam avaient alors publié la première collision SHA-1 pratique, baptisée SHAttered : deux fichiers PDF au contenu visuellement différent, mais partageant exactement la même empreinte SHA-1. L’annonce, détaillée sur le blog sécurité de Google, avait démontré que la résistance aux collisions de SHA-1, une propriété censée garantir qu’aucune donnée frauduleuse ne puisse porter la même signature qu’une donnée légitime, n’existait plus en pratique.
Neuf ans plus tard, l’écosystème technique en tire encore les conséquences. Les navigateurs avaient cessé de faire confiance aux certificats signés en SHA-1 dès les années qui ont suivi SHAttered. Mais l’algorithme est resté présent ailleurs, notamment dans certaines suites de chiffrement TLS plus anciennes et dans des configurations SSH historiques, par simple inertie technique. Le calendrier 2026 de GitHub illustre ce phénomène : il aura fallu près d’une décennie complète pour que le dernier vestige de SHA-1 disparaisse totalement de l’infrastructure HTTPS de la plus grande plateforme de code du monde.
Le calendrier complet, d’avril à décembre 2026
GitHub avait annoncé la mesure dès le 20 avril 2026. L’entreprise a ensuite suivi un calendrier en plusieurs étapes, conçu pour laisser aux équipes techniques le temps de détecter et corriger leurs configurations obsolètes avant la coupure définitive.
| Date | Événement | Portée |
|---|---|---|
| 20 avril 2026 | Annonce officielle de la suppression du SHA-1 en HTTPS/TLS | github.com, CDN partenaires, GitHub Enterprise Cloud |
| 14 juillet 2026 | Brownout de test, SHA-1 désactivé de 00h00 à 18h00 UTC | github.com uniquement, pas les CDN |
| 15 septembre 2026 | Désactivation définitive du SHA-1 en HTTPS/TLS | github.com et CDN partenaires |
| 14 octobre 2026 | Taille minimale des clés RSA SSH portée à 3072 bits, activation de mlkem768x25519-sha256 | github.com, GitHub Enterprise Cloud with Data Residency (hors région US) |
| 4 novembre 2026 | Premier brownout SSH, suppression temporaire de ssh-rsa et de diffie-hellman-group-exchange-sha256 | Connexions SSH et protocole Git non authentifié |
| 9 décembre 2026 | Second brownout SSH | Connexions SSH et protocole Git non authentifié |
| Début 2027 | Suppression définitive de ssh-rsa et de diffie-hellman-group-exchange-sha256 | github.com, GitHub Enterprise Server (version 3.25) |
Ce tableau montre que la coupure HTTPS du 15 septembre n’est que la première moitié d’un chantier plus vaste. GitHub traite le SHA-1 comme un problème à deux têtes : d’un côté le protocole HTTPS utilisé par les navigateurs, l’API et les clients Git en HTTPS, de l’autre le protocole SSH utilisé par une bonne partie des développeurs professionnels pour cloner et pousser du code au quotidien.
HTTPS n’est pas le seul front : SSH et les clés RSA aussi visées
Le 22 septembre 2026, soit une semaine après la coupure HTTPS, GitHub a publié une seconde annonce sur les améliorations de sécurité pour SSH. Le texte est direct sur les motivations : “For RSA, we’re removing the use of SHA-1 since it’s known to be weak, as well as increasing key sizes to align with 128-bit security requirements.” Trois changements sont prévus. D’abord, la suppression du type de signature ssh-rsa, c’est-à-dire les clés RSA qui utilisent encore SHA-1 pour signer, y compris les certificats [email protected]. Ensuite, le retrait de l’algorithme d’échange de clés diffie-hellman-group-exchange-sha256, jugé lent et peu utilisé. Enfin, une exigence de taille minimale de 3072 bits pour toute nouvelle clé RSA SSH téléversée après le 14 octobre 2026.
Le mécanisme retenu reproduit celui de la coupure HTTPS : deux brownouts de sensibilisation, prévus les 4 novembre et 9 décembre 2026, précèdent la suppression définitive début 2027. GitHub précise que seuls les utilisateurs qui se connectent en SSH, ou qui utilisent le protocole Git non authentifié sur GitHub Enterprise Server, sont concernés. Toute équipe qui travaille exclusivement en HTTPS n’a, cette fois, rien à changer.
Ce qui ne change pas : SHA-1 reste dans les objets Git eux-mêmes
Il existe une confusion fréquente qu’il vaut la peine de dissiper. Git, l’outil de contrôle de version créé par Linus Torvalds, utilise depuis toujours SHA-1 pour identifier chaque commit, chaque arbre de fichiers et chaque blob de contenu. C’est ce hachage à 40 caractères hexadécimaux qui sert d’identifiant unique à chaque objet du dépôt. La bascule du 15 septembre 2026 ne touche absolument pas à ce mécanisme : elle concerne uniquement le canal de transport (HTTPS/TLS), pas le format interne des dépôts.
Cette distinction rejoint un sujet que nous avions déjà traité sur ce site : la question des signatures Git malléables, où GitHub était resté silencieux pendant six mois après une alerte sur une faiblesse touchant la vérification cryptographique des commits signés. Le projet Git travaille depuis plusieurs années sur une transition progressive vers SHA-256 pour l’identification des objets, mais ce chantier est distinct, plus lent, et bien plus complexe à mener sans casser la compatibilité de millions de dépôts existants. La coupure HTTPS de septembre 2026 ne doit donc pas être confondue avec une résolution complète du problème SHA-1 dans Git.
Le Ballot SC097 : l’industrie entière ferme la porte aux certificats SHA-1
La décision de GitHub ne sort pas de nulle part. Elle s’inscrit dans un mouvement de fond porté par le CA/Browser Forum, l’organisme qui réunit autorités de certification et éditeurs de navigateurs pour fixer les règles des certificats TLS publics. Le 24 janvier 2026, le Ballot SC097, intitulé “Sunset all remaining use of SHA-1 signatures in Certificates and CRLs”, a été adopté à l’unanimité. Chez les autorités de certification, 26 voix pour et zéro contre, avec des noms connus en France comme Certigna, filiale de Dhimyotis, aux côtés de DigiCert, Sectigo, GoDaddy, SSL.com ou encore HARICA. Chez les éditeurs de navigateurs, quatre voix pour et zéro contre : Apple, Google, Microsoft et Mozilla ont voté dans le même sens.
Ce vote met à jour les Baseline Requirements, le texte de référence qui encadre l’émission et la gestion des certificats TLS publics, pour éliminer toute utilisation résiduelle de signatures SHA-1 dans les certificats et dans les listes de révocation (CRL). La période de revue s’est étendue du 26 janvier au 25 février 2026. Ce niveau de consensus, un score parfait dans les deux collèges de vote, montre que la décision de GitHub n’est pas un choix isolé mais l’application d’une norme désormais partagée par l’ensemble de l’écosystème de confiance du web.
Qui est concerné en France et en Europe
La plupart des développeurs qui travaillent avec des navigateurs et des systèmes d’exploitation à jour ne remarqueront probablement rien. Les cas à risque se trouvent ailleurs : postes de travail figés sous des versions anciennes de Windows ou de distributions Linux d’entreprise, proxys d’inspection TLS déployés par des directions informatiques et jamais mis à jour, runners CI/CD auto-hébergés qui tournent sur des images Docker vieilles de plusieurs années, ou bibliothèques clientes obsolètes intégrées dans des scripts d’automatisation internes.
Le secteur bancaire, les administrations et les grandes entreprises industrielles françaises, souvent soumis à des cycles de validation de sécurité longs avant toute mise à jour de poste, figurent parmi les organisations les plus exposées à ce type de rupture silencieuse. Un pipeline de déploiement qui échoue soudainement sans message d’erreur clair, parce qu’un vieux client Git ou un ancien proxy d’entreprise ne sait plus négocier une connexion TLS moderne, reste l’un des scénarios d’incident les plus frustrants à diagnostiquer pour une équipe technique.
Le brownout du 14 juillet, un galop d’essai grandeur nature
Avant de couper définitivement le SHA-1, GitHub a organisé une répétition générale. Le 14 juillet 2026, de 00h00 à 18h00 UTC, l’entreprise a désactivé temporairement le SHA-1 sur github.com, sans toucher à ses CDN. L’objectif d’un brownout est simple : provoquer volontairement une panne limitée dans le temps pour forcer les équipes concernées à découvrir leurs dépendances cassées avant que la coupure ne devienne permanente et sans retour arrière possible.
GitHub avait accompagné cet exercice de conseils pratiques : tester la compatibilité d’un navigateur en visitant github.dev, où le SHA-1 était déjà désactivé en permanence, vérifier que les bibliothèques utilisées pour appeler l’API restent à jour, et s’assurer que le client Git local repose sur une version récente avec un système d’exploitation et des composants TLS également à jour. Cette approche en deux temps, un brownout de sensibilisation suivi d’une coupure définitive deux mois plus tard, est la même que GitHub réutilise actuellement pour la suppression de ssh-rsa, prévue en deux brownouts en novembre et décembre 2026.
SHA-1 face à SHA-256 et SHA-3 : ce qui a réellement changé
Pour mesurer l’écart entre l’algorithme retiré et ceux qui le remplacent dans les suites TLS modernes, il faut revenir aux caractéristiques structurelles de chaque fonction de hachage. SHA-1 produit une empreinte de 160 bits, une taille jugée insuffisante depuis longtemps face à la puissance de calcul disponible aujourd’hui. SHA-256, normalisé par le NIST dans la famille SHA-2, et SHA-3, standardisé plus récemment selon une construction mathématique différente (éponge Keccak plutôt que Merkle-Damgård), produisent tous deux des empreintes de 256 bits, sans collision pratique connue à ce jour.
| Fonction | Taille d’empreinte | Construction | Statut face aux collisions |
|---|---|---|---|
| SHA-1 | 160 bits | Merkle-Damgård | Collision pratique démontrée (SHAttered, février 2017) |
| SHA-256 (SHA-2) | 256 bits | Merkle-Damgård | Aucune collision pratique connue |
| SHA-3-256 | 256 bits | Éponge Keccak | Aucune collision pratique connue |
| BLAKE3 | 256 bits (extensible) | Arbre Merkle parallélisable | Aucune collision pratique connue |
Nous avions déjà détaillé les différences de performance entre SHA-256 et SHA-3 pour vérifier l’intégrité de fichiers, ainsi que la comparaison entre BLAKE3 et SHA-3. Dans le cas précis de GitHub, ce n’est pas le choix d’une fonction de hachage de nouvelle génération comme BLAKE3 qui est en jeu, mais simplement l’élimination d’un algorithme obsolète des suites de chiffrement TLS, au profit des variantes SHA-2 déjà largement déployées dans l’écosystème HTTPS moderne.
GitHub face au reste de l’industrie
Le retrait du SHA-1 chez GitHub ne représente pas un geste isolé. Il s’inscrit dans une convergence portée par l’ensemble des acteurs qui délivrent ou consomment des certificats TLS publics. Le vote unanime du Ballot SC097 illustre ce point avec une clarté rare dans un secteur où les désaccords techniques sont fréquents : aucune autorité de certification, aucun éditeur de navigateur n’a voté contre la suppression du SHA-1 dans les certificats et les listes de révocation. Cette unanimité contraste avec d’autres transitions cryptographiques en cours, comme le passage aux algorithmes post-quantiques, où les calendriers et les choix d’algorithmes varient encore sensiblement d’une juridiction à l’autre.
Pour une entreprise comme GitHub, qui héberge le code source d’une part considérable des projets open source et privés dans le monde, agir en cohérence avec ce consensus limite le risque de devenir, à terme, le dernier service majeur encore compatible avec un algorithme que plus aucun navigateur moderne ne considère fiable. Un fournisseur de forge Git qui traînerait sur ce sujet s’exposerait à des audits de sécurité négatifs chez ses clients entreprise, en particulier dans les secteurs régulés où la conformité aux référentiels de sécurité impose déjà l’abandon de SHA-1.
Impact sur le marché du développement logiciel
L’impact immédiat de ce type de bascule se mesure rarement en argent, mais plutôt en heures d’ingénierie détournées vers du travail de maintenance non planifié. Chaque coupure de ce genre génère une vague prévisible de tickets de support : connexions qui échouent sans message clair, pipelines CI/CD qui plantent au moment du clone, scripts d’intégration continue écrits il y a plusieurs années et jamais revus. Pour les équipes de sécurité, cette bascule est aussi une opportunité de cartographier précisément où se cachent encore les dépendances à des algorithmes obsolètes dans leur chaîne d’outils.
Le choix de GitHub de doubler la peine avec la suppression de ssh-rsa et l’exigence de clés RSA d’au moins 3072 bits ajoute une seconde vague de travail à anticiper d’ici la fin 2026 et le début 2027. Les équipes qui gèrent des flottes de serveurs de build, de clés de déploiement automatisées ou de comptes de service utilisant des clés RSA anciennes ont tout intérêt à auditer leurs identifiants SSH dès maintenant, plutôt que d’attendre les brownouts de novembre et décembre.
Ce que dit GitHub
Les annonces officielles de GitHub restent factuelles, mais elles justifient explicitement la démarche par la faiblesse cryptographique de SHA-1. Dans son annonce du 20 avril 2026, l’entreprise écrit : “We’re going to remove the use of SHA-1 in HTTPS for GitHub and our CDNs.” Elle précise la méthode retenue pour limiter les mauvaises surprises : “We will conduct a brownout, where we temporarily disable SHA-1 to raise awareness around the deprecation,” source disponible sur le changelog officiel.
Sur le volet SSH, l’entreprise assume clairement le lien avec la faiblesse structurelle de l’algorithme : “For RSA, we’re removing the use of SHA-1 since it’s known to be weak, as well as increasing key sizes to align with 128-bit security requirements,” peut-on lire dans l’annonce du 22 septembre 2026. Plus tôt, dans ses recommandations de préparation, GitHub avait déjà résumé sa position de fond sur ce type de signature faible : “SHA-1 is weak, so we’ll stop allowing new RSA client keys to use SHA-1 signatures and require them to use SHA-2 signatures instead,” une orientation détaillée sur son blog sécurité, qui documente la stratégie de long terme de l’entreprise contre les algorithmes de hachage jugés fragiles.
Le chapitre post-quantique s’ouvre déjà côté SSH
Un détail de l’annonce du 22 septembre 2026 mérite une attention particulière. En parallèle du retrait des algorithmes SHA-1 et Diffie-Hellman jugés obsolètes, GitHub introduit un nouvel échange de clés pour les sessions SSH : mlkem768x25519-sha256, une construction hybride qui combine ML-KEM, l’algorithme d’encapsulation de clés post-quantique standardisé par le NIST, avec la courbe elliptique X25519. Ce mécanisme sera activé sur github.com et sur GitHub Enterprise Cloud with Data Residency, à l’exception de la région américaine, à partir du 14 octobre 2026.
C’est un détail technique en apparence secondaire, mais il illustre une tendance de fond : la résistance quantique ne s’implante pas uniquement dans les grands travaux médiatisés autour de TLS et des certificats, elle progresse aussi discrètement dans des protocoles du quotidien comme SSH, utilisés des dizaines de fois par jour par chaque développeur. GitHub justifie ce choix par la nécessité de remplacer un mécanisme jugé lent et vulnérable aux progrès de l’informatique quantique par une alternative plus performante et sécurisée face aux ordinateurs quantiques, selon les termes de l’annonce.
Comment vérifier et corriger votre configuration
GitHub recommande une méthode de test simple pour valider la compatibilité d’un navigateur : se rendre sur github.dev, où le SHA-1 est désactivé en permanence depuis plus longtemps que sur le reste de la plateforme. Si la page se charge normalement, le navigateur supporte déjà les configurations HTTPS modernes exigées. Pour les intégrations utilisant l’API ou les clients Git en ligne de commande, la vérification passe par la version des bibliothèques et du client installé.
# Vérifier la version de Git installée
git --version
# Tester une connexion HTTPS vers GitHub en mode verbeux
GIT_CURL_VERBOSE=1 git ls-remote https://github.com/git/git.git
# Vérifier la version d'OpenSSL utilisée comme backend TLS (Linux)
openssl version
# Lister les algorithmes de signature supportés par une clé SSH RSA
ssh-keygen -lf ~/.ssh/id_rsa.pubPour les équipes qui gèrent des runners CI/CD auto-hébergés, la priorité consiste à s’assurer que les images de build reposent sur un système d’exploitation à jour, avec une bibliothèque TLS récente. Sur les clés SSH, l’anticipation est encore plus critique : toute clé RSA générée ou téléversée après le 14 octobre 2026 devra respecter la taille minimale de 3072 bits, et les clés RSA existantes signées en SHA-1 cesseront de fonctionner après les brownouts de novembre et décembre 2026. Il est également utile de revoir la configuration des anciens routeurs et pare-feux d’entreprise, un sujet que nous avions abordé à propos d’une signature SSH cassée chez RouterOS, ainsi que les correctifs récents touchant les bibliothèques TLS sous-jacentes, comme ceux détaillés dans notre couverture des failles TLS de curl 8.22.0.
Nos prédictions pour la suite
- D’autres grandes forges de code, en particulier celles qui hébergent des projets open source à fort trafic, devraient annoncer des calendriers de retrait du SHA-1 comparables dans les douze à dix-huit mois qui viennent, portées par le même consensus du CA/Browser Forum.
- La suppression de ssh-rsa et l’exigence de clés RSA à 3072 bits, prévue début 2027, provoquera probablement plus de frictions opérationnelles que la coupure HTTPS de septembre, car les clés de déploiement automatisées sont souvent oubliées dans de vieux scripts.
- Le support de mlkem768x25519-sha256 en SSH pourrait devenir, pour beaucoup de développeurs, leur premier contact concret avec un algorithme post-quantique en production, avant même l’adoption généralisée de ML-KEM côté navigateur.
- La pression pour accélérer la transition de Git vers SHA-256 pour l’identification des objets va probablement se renforcer à l’approche du dixième anniversaire de SHAttered, en février 2027.
- Les entreprises régulées, notamment dans la banque et les administrations françaises, devraient inscrire ce type de bascule dans leurs prochains audits de conformité, au même titre que les exigences post-quantiques déjà recommandées par l’ANSSI.
Questions fréquentes
Le SHA-1 est-il complètement supprimé de GitHub ?
Non. Seul l’usage de SHA-1 dans les connexions HTTPS et TLS est désactivé depuis le 15 septembre 2026. Git continue d’utiliser SHA-1 pour identifier les commits, les arbres de fichiers et les blobs à l’intérieur des dépôts. La suppression de ssh-rsa côté SSH, qui touche un usage différent de SHA-1, est prévue pour début 2027.
Pourquoi GitHub a-t-il attendu 2026 pour agir, alors que SHAttered date de 2017 ?
La suppression complète d’un algorithme d’un service utilisé par des millions de développeurs prend du temps, car elle risque de casser des connexions encore actives chez des clients anciens. GitHub a choisi une approche progressive, avec une annonce préalable, un brownout de test, puis une coupure définitive, pour limiter les interruptions imprévues.
Mon utilisation de GitHub Enterprise Server est-elle concernée ?
La coupure HTTPS du 15 septembre 2026 ne concerne pas GitHub Enterprise Server, la version auto-hébergée. Les changements liés à SSH et à ssh-rsa arriveront en revanche dans la version 3.25 de GitHub Enterprise Server, et le support de mlkem768x25519-sha256 dans la version 3.24.
Comment savoir si mon navigateur ou mon client Git est compatible ?
GitHub recommande de visiter github.dev pour tester un navigateur, ce site ayant désactivé le SHA-1 plus tôt que le reste de la plateforme. Pour un client Git, il suffit de vérifier que la version installée et le système d’exploitation sous-jacent sont à jour, notamment la bibliothèque TLS utilisée comme backend.
Qu’est-ce que le Ballot SC097 du CA/Browser Forum ?
C’est un vote adopté le 24 janvier 2026 par le CA/Browser Forum, qui met à jour les règles encadrant les certificats TLS publics pour interdire toute utilisation résiduelle de signatures SHA-1, aussi bien dans les certificats que dans les listes de révocation. Il a été approuvé à l’unanimité par les autorités de certification et par les éditeurs de navigateurs Apple, Google, Microsoft et Mozilla.
Quelle est la différence entre SHA-1 et les algorithmes qui le remplacent ?
SHA-1 produit une empreinte de 160 bits et sa résistance aux collisions a été cassée en pratique en 2017. SHA-256, utilisé dans la plupart des suites TLS modernes, produit une empreinte de 256 bits et ne possède à ce jour aucune collision pratique connue, tout comme SHA-3, qui repose sur une construction mathématique différente.
Mes clés SSH RSA vont-elles cesser de fonctionner ?
Pas immédiatement. Les clés RSA existantes signées en SHA-1 resteront fonctionnelles jusqu’aux brownouts prévus les 4 novembre et 9 décembre 2026, avant une suppression définitive début 2027. Toute nouvelle clé RSA téléversée après le 14 octobre 2026 devra en revanche respecter une taille minimale de 3072 bits.
Ce changement a-t-il un lien avec la cryptographie post-quantique ?
Indirectement. En parallèle du retrait de SHA-1, GitHub introduit sur SSH un nouvel échange de clés hybride, mlkem768x25519-sha256, qui combine l’algorithme post-quantique ML-KEM avec la courbe elliptique X25519. Les deux chantiers, retrait des algorithmes faibles et introduction d’algorithmes résistants au calcul quantique, avancent en parallèle chez GitHub.
