Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

Aujourd’hui, un site qui n’est pas en HTTPS est considéré comme n’étant pas sécurisé, il finit par avoir mauvaise réputation (même s’il n’expose pas de données sensibles). On finit donc par voir beaucoup de sites en HTTPS, presque trop …

Si bien que la demande de certificats pour faire du SSL/TLS a explosée. Pour répondre à la demande, et offrir toujours plus de sécurité à tous, plusieurs autorités délivrent des certificats gratuitement (la durée de vie des certificats est juste réduite, et le niveau de cryptage est parfois limité). Les autorités qui délivrent ces certificats vérifient juste que le demandeur du certificat est propriétaire du nom de domaine qui sera utilisé. Pour un certificat payant, les vérifications sont plus poussées (documents liés à l’entreprise demandeuse ou la personne physique, justificatifs de domiciliation …).

Tout cela est bien compliqué pour l’utilisateur lambda. Que devons-nous lui faire comprendre ?

On déjà tellement fait circuler l’information que la sécurité était matérialisée par un cadenas accolé à l’URL. Maintenant, il faudrait expliquer comment faire la différence entre deux certificats ?

Est-ce bien utile, ne pourrait-on pas juste répondre à la question suivante :

Est-on toujours en sécurité quand on navigue sur un site en HTTPS ?

Faisons un petit tour du SSL/TLS pour mieux comprendre, et vulgarisons la chose :

Quand on parle de site en HTTPS, on parle en fait d’un site qui utilise SSL. Actuellement on est censé utiliser TLS. Il s’agit de la version la plus récente du protocole utilisé pour notre HTTPS, mais par habitude, on parle toujours de SSL.

SSL est un protocole qui sert à protéger les échanges des regards indiscrets. Techniquement, il permet de créer une session sécurisée entre un client et un serveur. Si on image la chose, on pourrait considérer le SSL comme un tuyau dans lequel circulent les informations échangées entre le client et l'application web.

Contrairement à ce que beaucoup de personnes croient, il n'y a pour autant pas de notion d'authentification. Il existe bien dans le standard, une authentification client par le serveur. Mais en pratique, le client n'a que très rarement un certificat à fournir au serveur. On peut voir ce genre de scénarios pour des changes entre machines (souvent avec du SOAP et du WebSecured).

Le client a bien vocation à vérifier qu'il fait confiance à l'autorité de certificat qui a délivré le certificat qui sert au SSL. Pour cela, il utilise la liste des autorités de confiance (CA = Certificate Authority) dont il dispose (liste disponible via le navigateur et l’OS). Mais ce n'est pas pour autant qu'il vérifie l'identité du serveur qui utilise le certificat. Un certificat qui a été compromis (dérobé, ou diffusé par erreur avec sa clé privée) peut être utilisé sur un serveur qui n'appartient pas à l'entreprise qui en a fait l'acquisition. Il est donc un danger autant pour la société qui fournit le service, que pour le client.

Concernant la sécurité des échanges, SSL utilise une logique de cryptages et de hachage très robustes qui vous protège de nombreuses attaques. On est bien loin de l’époque ou le plus haut niveau de cryptage ne se faisait que sur 40bits (à minima, on est le plus souvent sur du 128 voir 256bits; en entreprise, on exploite du 4096bits). De ce côté, la sécurité ne pose pas de problèmes.

Les vulnérabilités sont donc plus souvent liées à une erreur humaine, ou à une action malveillante très ciblée :

• Attaque de type de "man in the middle". Un routeur, un proxy, ou une application locale peuvent faire office d'intermédiaire entre le client et le serveur (il devient serveur du client, et client du vrai serveur). Cet intermédiaire entre le site et l'utilisateur peut donc avoir connaissance de l'intégralité des messages. Si votre liste d’autorité de confiances est fiable, et que les certificats utilisés ne sont pas acceptés, votre navigateur affichera un avertissement concernant le site. Dans le cas contraire, vos données sont en danger.
• Les certificats des autorités de confiances qui ne sont pas à jour sur le client. Si de fausses autorités de confiances sont configurées sur le client, celui-ci et potentiellement en danger (attention donc à ne pas installer n'importe quoi).
• Tous les navigateurs ne vérifient pas forcément le fait qu'un certificat ne soit pas révoqué par son autorité. Toutes les autorités ne permettent pas forcément de savoir si un certificat a été révoqué. Un certificat compromis peut donc être utilisé sur un faux serveur.
• L’administrateur n’a pas désactivé SSL au profit de TLS. Le serveur utilise donc encore de vieilles versions de SSL au lieu d’utiliser TLS. Des vulnérabilités de SSL sont donc exploitables..

Ces dernières années plusieurs autorités de certificats ont été montrées du doigt pour leur laxisme concernant la diffusion de leurs certificats. La plupart des navigateurs ont agi en bannissant ces autorités douteuses de leurs listes. Aujourd’hui, il convient donc d’utiliser un navigateur à jour.

Alors ?

Non, le SSL ne signifie pas forcément sécurité et confiance aveugle. Si votre navigateur affiche un avertissement concernant un site, n’utilisez pas ce site pour vous authentifier ou échanger des informations sensibles.

En tant qu'utilisateur, on peut se protéger :

• En utilisant un PC et un navigateur à jour (liste d’autorité de certificats à jour)
• En maitrisant la liste des applications installées sur le PC client (une application peut installer de fausses autorités de certificats).
• Sur des réseaux peu sécurisés, publics, ou dont on ne sait pas si l'on peut avoir confiance, ne pas aller sur un site si votre navigateur affiche un avertissement ou une erreur au sujet du certificat d'un site.

En tant que développeur, pour assurer une sécurité très forte :

• Toujours être vigilant lors de l’acquisition et du déploiement de ses certificats.
• Désactiver SSL sur les serveurs, au profit de TLS.
• Ne pas installer un certificat en autorisant l’extraction de sa clé privée.
• Ne pas créer/acheter des certificats avec une trop longue durée de vie. Il serait fâcheux qu’un certificat compromis soit valable durant 3 ans (les listes de révocation n’étant pas toujours utilisées par les clients).
• Implémenter une logique d'authentification pour les services sensibles.
• Ne pas utiliser d'authentification qui implique l'envoi des credentials (login, password) à chaque transaction. Cela permet de réduire les risques (utiliser WS pour du SOAP, Owin avec des Tokens pour du REST)

Conclusion

SSL est certes un très bon protocole pour la sécurité, mais comme démontré ici, il est peut-être compromis. Donc, oui avec SSL on est en sécurité. Mais soyez vigilants et ne contournez pas les avertissements de vos navigateurs.