La quasi-totalité des services et des protocoles utilisés aujourd'hui ont été spécifiés il y a un quart de siècle. A l'époque, Internet ne concernait que quelques milliers de chercheurs. On était alors assez peu concerné par des problèmes de confidentialité sur le réseau. Le résultat est que les protocoles conçus dans ce contexte sont en texte clair : tout ce qu'ils transportent est visibile pour peu que l'on puisse capturer des trames réseau contenant ce protocole.

Parmi les remèdes à cette situation, on a vu des protocoles être remisés au rang d'antiquités et remplacés par de nouveaux plus sûrs. C'est le cas de telnet par exemple. Mais la solution la plus courante consiste à chiffrer le canal de communication sous-jacent au protocole. HTTPS, par exemple, n'est rien d'autre que du HTTP circulant sur une couche chiffrée SSL (Secure Socket Layer) et sur un port différent ^[26].

Grâce à cette technique, il suffit de modifier « légèrement » les clients et les serveurs pour qu'ils utilisent une couche SSL.

La couche SSL utilise souvent des certificats pour s'assurer de l'identité de chacun et pour chiffrer les communications. Nous devrons donc créér ces certificats afin de sécuriser nos différents services en déployant une PKI : Public Key Infrastructure.

Le principe est le suivant. Le client qui veut se connecter à un serveur de manière sécurisée cherche essentiellement à :

De son coté, le serveur peut aussi avoir besoin de vérifier l'identité du client (bien que ce soit rare en pratique).

Pour parvenir à ce résultat, le serveur devra prouver son identité au client avec un certificat. Ce certificat sera signé par une autorité de certification qui se porte garante de l'identité du serveur. Par exemple, lorsque l'on se connecte au site https://www.nsa.gov, le certificat renvoyé est signé par la société Verisign, qui est une autorité de certification (CA) ou tiers de confiance. Comme nous savons que Verisign est « sérieux » dans son processus de vérification d'identité, nous pouvons être sûr que le site est bien celui de la NSA. Cela n'implique pas que le site est de confiance; cela indique seulement que le site est bien celui qu'il prétend être.

Comme le certificat contient une clef publique, toutes nos communications avec ce site pourront être chiffrées avec un algorithme négocié à l'établissement de la connexion SSL.

Pour déployer un serveur, il n'est cependant pas nécessaire de demander un certificat (plus exactement de demander à un tiers de confiance de signer notre certificat) : nous pouvons créér notre propre CA (Certificate Authority, autorité de certification). Bien sûr, dans ce cas, nous n'apportons plus la preuve au client que nous sommes bien qui nous prétendons être. En revanche, si seul le chiffrement nous interesse, c'est tout à fait acceptable.

Une autre poossibilité consiste à créér un certificat auto-signé (self-signed certificate) : aucune autorité de certification ne confirme l'authenticité du certificat. Nous n'utiliserons cependant pas cette méthode car la mise en place de SSL pour MySQL requiert l'utilisation du certificat de l'autorité ayant signé le certificat serveur

On aura remarqué que l'accès au site web de la NSA en HTTPS ne provoque l'apparition d'aucun message dans le navigateur. La raison est que par défaut, la plupart des navigateurs connaissent le certificat de Verisign. Voyant que le certificat de la NSA est signé par Vérisign, et faisant par défaut confiance à Vérisign, le navigateur fait confiance au site distant et n'affiche aucun message. En revanche, si nous signons nous même nos certificats, les navigateurs afficheront un avertissement car le signataire ne sera pas connu, donc pas de confiance. Il faudra « faire avec », ou importer le certificat de notre propre autorité de certification dans le navigateur.