Le pinning SSL : comment on fait ?

Le pinning SSL permet de s’assurer, lors d’une connexion HTTPS, que celui qui utilise un certificat SSL est bien celui qu’il prétend être. Sinon, on lui coupe le sifflet !

Le pinning SSL et ses outils

Pour faire du pinning SSL, il y a diverses stratégies. Inutile de s’étendre sur le sujet. OWASP a déjà rédigé un article bien complet là-dessus.

Même plusieurs articles.

Mais comment ils font les autres ?

C’est bien le coeur du problème. Connaître la technique est une chose. Savoir mettre en place la technique en est une autre.

Le pinning de clé publique, c’est assez cool, mais c’est un peu trickie comme approche et parfois complexe.

Le plus simple est certainement le pinning du certificat en lui-même.

Ha oui, mais si le certificat change ?

Une faille comme Heartbleed peut en effet forcer à révoquer les certificats.

Qui dit certificat changé dit pinning cassé.

Donc autant ne pas faire de pinning SSL ?

Chiffrer les données au-delà du HTTPS

L’avantage des technologies modernes, c’est qu’on peut chiffrer certaines données. Sans nécessairement passer par HTTPS.

Par exemple, on peut imaginer un serveur utilisé uniquement en cas d’incident. Par exemple, quand la clé enregistrée dans l’app ne fonctionne plus et qu’il faut en enregistrer une autre.

On effectue alors une requête précise sans pinning sur le service web. Avec un système de jeton unique qui ne peut être généré quand connaissant un algorithme particulier. Ce jeton inclue une clé valable temporairement partagée entre le client et le serveur. Cette clé permet d’obtenir une autre clé qui servira à chiffrer l’information avec encore une autre clé, également partagée entre client et serveur et d’une durée temporaire.

Le client reçoit l’information. La déchiffre avec la clé aléatoire qu’il a généré + la clé partagée. Là, il a la nouvelle empreinte permettant d’effectuer le pinning sur le nouveau certificat.

La clé partagée entre le client et le serveur sera chiffrée sur iOS. Aucun soucis.

Sur Android, la mauvaise idée est de la mettre dans les préférences. Ou de la mettre en dur dans le code. Heureusement, il y a le NDK qui permet de compiler des informations. Evidemment, ce code peut-être décompilé. Mais on peut aussi obfusquer le code du NDK. Et là, c’est moins cool à décompiler et comprendre. Surtout s’il y a en plus du fake code avec une bonne obfuscation du code Java en lui-même.

Bref. En attendant la mise à jour de l’app, c’est une solution de secours qui évite l’interruption de service.

Ça peut aussi être utile pour les identifiants d’accès aux services web externes (Facebook, Google, Cloudinary, etc).

Ha ouais, c’est cool

Bah ouais. Maintenant, faut s’y mettre. Avec un peu de bonne volonté, tout est possible.

 

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s