« `html
Hier, Apple a déployé une mise à jour de sécurité inquiétante pour iOS, indiquant un problème sérieux avec SSL/TLS, sans fournir de détails spécifiques.

Cela a rapidement suscité des préoccupations parmi les experts en cybersécurité et les usagers.

Compréhension de la faille SSL chez Apple

Le problème réside dans le code source publié d’Apple pour la fonction SSLVerifySignedServerKeyExchange.

En y regardant de plus près, on remarque deux lignes « goto fail » placées consécutivement.

La première ligne est correctement liée à une condition, mais la seconde, bien que visuellement indentée, n’a pas de condition associée.

En conséquence, le code plonge toujours dans la condition d’échec après cette seconde ligne « goto fail », empêchant ainsi la validation de la signature échouée.

Cette validation de signature est cruciale dans le message ServerKeyExchange, utilisé dans les suites de chiffrement DHE et ECDHE pour établir une clé éphémère pour la connexion.

En essence, le serveur dit : « Voici la clé éphémère et voici une signature de mon certificat, pour que vous sachiez qu’elle vient de moi ».

Si ce lien entre la clé éphémère et la chaîne de certificats est brisé, la confiance s’effondre, permettant à un attaquant de signer le protocole d’échange avec une clé privée incorrecte, ou de ne pas le signer du tout.

Pour plus d’informations sur cette vulnérabilité et ses implications, vous pouvez consulter l’analyse détaillée de l’incident.

Impact sur iOS et OS X

Ce bug affecte principalement les versions iOS antérieures à 7.0.6 et les versions OS X antérieures à 10.9.2.

Tout logiciel utilisant SecureTransport sur ces plateformes est potentiellement vulnérable.

Cependant, Chrome et Firefox échappent à ce problème car ils utilisent NSS pour SSL/TLS plutôt que SecureTransport.

L’ampleur du problème se mesure à la diversité des applications potentiellement vulnérables, y compris le système de mise à jour logicielle de votre appareil.

Pour tester cette vulnérabilité, un site web spécifique a été mis en place (https://www.imperialviolet.org:1266).

Si un utilisateur peut charger un site HTTPS sur le port 1266, cela indique qu’il est affecté par ce bug, car le serveur y envoie les mêmes certificats mais signe avec une clé différente.

La chaîne de certificats étant correcte, le pinning de certificat n’aurait pas empêché cette vulnérabilité.

De plus, cette faille n’affecte pas seulement les sites utilisant les suites de chiffrement DHE ou ECDHE, car l’attaquant peut choisir la suite de chiffrement optimale pour son attaque.

Si TLS 1.2 n’est pas affecté par ce bug, l’attaquant peut choisir la version que le client accepte.

Si le client n’autorise que TLS 1.2 ou les suites de chiffrement RSA simples, ces configurations pourraient contourner le bug.

Par conséquent, privilégier TLS 1.2 est une solution plus robuste.

Les mises à jour iOS 7.0.6 et OS X 10.9.2 corrigent ce problème.

Il semble que ce bug ait été introduit avec OS X 10.9 mais était présent dans certaines versions d’iOS 6, corrigé par la mise à jour iOS 6.1.6.

Analyse et réflexion sur la gestion des erreurs dans le code

Un bug aussi subtil dans le code est cauchemardesque.

Il semble être simplement une erreur humaine, introduite par inadvertance.

En compilant avec -Wall (activer tous les avertissements), ni GCC ni Clang ne signalent le code mort, ce qui est surprenant.

Un meilleur avertissement aurait pu prévenir cette situation, mais le taux de faux positifs est peut-être trop élevé ?

Bien que certains prétendent que le style de codage a contribué à cette erreur, même avec des accolades, une mauvaise indentation peut survenir.

L’écriture de tests aurait détecté ce genre de bug, mais c’est difficile parce cela implique de simuler des échanges invalides dans TLS.

Les revues de code sont essentielles pour prévenir de tels bugs.

Une inspection minutieuse de chaque modification est cruciale.

Bien que nous ignorions la culture de revue de code chez Apple, une vigilance accrue aurait pu capturer cette anomalie.

Pour conclure, bien que certains aient suggéré qu’Apple aurait omis de vérifier le nom d’hôte dans le certificat, cela ne semble pas être le problème principal.

Safari ne montre pas ce problème, bien que l’outil curl sous OS X accepte des connexions HTTPS avec des adresses IP ne figurant pas dans le certificat.

Un risque réel pour les utilisateurs et entreprises

Cette vulnérabilité dans le code SSL/TLS d’Apple présente un risque significatif.

Un attaquant peut profiter de cette faille pour effectuer des attaques de type « Man-in-the-Middle » (MitM), interceptant et potentiellement altérant les communications sécurisées entre un utilisateur et un serveur.

L’impact pour les entreprises inclut le vol de données sensibles, la compromission de systèmes internes et la perte de confiance des clients, tandis que pour les utilisateurs individuels, cela pourrait conduire à des violations de la vie privée, des fraudes financières et l’exposition de données personnelles.

Mesures de protection essentielles

Pour se prémunir contre ce type de risque, il est impératif de maintenir tous les appareils à jour en installant immédiatement les correctifs déployés par Apple (iOS 7.0.6 et OS X 10.9.2).

Les entreprises devraient également effectuer des révisions de code régulières et renforcer les tests de sécurité.

Enfin, il est recommandé d’adopter des protocoles de sécurité robustes comme TLS 1.2 et d’utiliser des navigateurs et des logiciels qui intègrent des mécanismes de sécurité alternatifs tels que NSS pour SSL/TLS.
« `