Pourquoi sécuriser son site web avec le protocole HTTPS ?

La question peut sembler saugrenue tant il semble évident qu’il est toujours mieux de sécuriser au maximum son site web. Pourtant, c’est loin d’être aussi simple qu’il n’y paraît. De plus en plus de sites web se mettent au HTTPS en imposant un certificat électronique à leurs visiteurs. Est-ce obligatoire ? Quels sont les avantages ? Comment mettre en place un tel certificat ? Quelle est la différence entre SSL et TLS ? Combien ça coûte ? Voici un petit florilège des questions que nous aborderons dans cet article. Commençons par le commencement :

Le protocole HTTP, c’est quoi ?

Dans notre vie courante, nous utilisons tous le mot HTTP. Mais qui peut réellement prétendre savoir ce qu’il implique et à quoi il sert ? HTTP (pour HyperText Transfer Protocol ou Protocole de Transfert Hypertexte) permet la liaison entre un client et un hôte branché sur le web. Inventé dans les années 1990 au CERN (Conseil Européen pour la Recherche Nucléaire) par le père fondateur du World Wide Web Tim Berners-Lee, HTTP délivre des informations grâce à la communication entre le navigateur (client) et le serveur (hôte) au moyen de ce que l’on appelle une requête. Par l’accumulation de requêtes HTTP, le navigateur interprète toutes les réponses et les retranscrit sur une page HTML (pour HyperText Markup Language). Sans HTTP, vous ne pourriez pas lire cet article. C’est un élément fondamental dans la structure et l’exploitation du réseau Internet.

HTTPS sécurise l’échange d’informations

Comme nous venons de le voir, le navigateur et le serveur se communiquent des informations. Il peut s’agir de textes, d’images, de vidéos… mais aussi des numéros de cartes bancaires ! Pourtant, HTTP ne se préoccupe pas de sécuriser la ligne. Ce n’est pas son but. C’est là qu’intervient HTTPS, dont le S final signifie Secure. En utilisant le protocole HTTPS, le client et l’hôte reçoivent une clé de chiffrement. Si les données venaient à être interceptées à l’aide d’une attaque de type homme du milieu, une personne mal intentionnée qui écouterait la ligne ne pourrait pas déchiffrer son contenu. HTTPS permet donc de dormir tranquille et veille à la sécurisation des informations transitant sur le réseau.

Dans les années 2000, HTTPS a eu le vent en poupe sur les sites marchands et bancaires, qui étaient les principaux vecteurs d’informations sensibles. Mais depuis 2010 et la démocratisation croissante d’Internet, le monde dans sa globalité tend à plus de sécurité dans les échanges. Et ce quelles qu’en soient leurs natures ou leurs substances. Dès lors, HTTPS fait des émules et se propage comme un feu de paille sur tous les sites web du globe. Il faut voir ce changement comme une avancée majeure dans la crédibilité du réseau, lourdement mis à mal à ses débuts par un manque de sensibilisation et par un coût exorbitant des technologies. En quelques années, Internet a évolué dans le bon sens, il faut s’en réjouir.

De l’utilisation des certificats électroniques

HTTPS se base sur l’utilisation d’un certificat électronique, également appelé certificat numérique ou certificat de clé publique. Côté client, ce certificat apparaît sous les traits d’un cadenas vert à côté de l’URL. Il signifie que la connexion passe par le port 443 et qu’elle est cryptée – et non plus par le port 80 qui est utilisé par HTTP. Les certificats permettent de lier conjointement le nom de domaine, le nom de serveur, l’hôte, l’identité de l’organisation ou de l’entreprise ainsi que son lieu. Quant au cryptage, il est plus ou moins fort en fonction de la technologie (SSL ou TLS), de la version et du chiffrement (exprimé en bits). Chaque certificat est unique et permet au client d’identifier son hôte.

Historiquement, la première version du protocole SSL (pour Secure Sockets Layer) est apparue en 1994. Toutefois, SSL ne fut réellement utilisé qu’à partir de sa version 2, sortie en 1995. Fin 1996, SSL 3 voit le jour. Le protocole TLS (pour Transport Layer Security) est une évolution du protocole SSL. La version 1.0 sort en 1999. S’en suivront les versions 1.1 en 2006 et 1.2 en 2008. Si les concepts SSL et TLS sont sensiblement proches, ils ne disposent pas des mêmes capacités de cryptage et donc de sécurisation. Aujourd’hui, il faudrait être inconscient pour utiliser SSL 3, tant il a été démontré que cette technologie est obsolète, cette version ayant été cassée maintes et maintes fois. De fait, si vous souhaitez sécuriser votre site web, nous vous conseillons de toujours utiliser les dernières versions du protocole TLS (1.2 à cette heure).

En effet, la cryptanalyse est une science en perpétuelle évolution. Chaque jour, de nouvelles failles sont découvertes, qu’il faut colmater au plus vite à l’aide de patch et de mises à jour. La version 1.3 de TLS est d’ailleurs dans les starting-blocks. Deux moutures au stade du brouillon sont sorties en avril 2014 et octobre 2015. Nul doute que la version finalisée devrait pointer le bout de son nez d’ici quelques mois.

Certificats et autorités de certification

Tous les certificats sont délivrés par une autorité de certification, à savoir des tiers de confiance qui ont les pleins pouvoirs décisionnels. Ils vérifient les informations soumises et décident par la suite de vous faire confiance ou non. Attention, l’utilisation de HTTPS en lui-même ne nécessite pas d’avoir une accréditation. Tout le monde peut utiliser les protocoles SSL ou TLS, à la seule exception près que votre client aura une annonce que la connexion n’est pas entièrement sécurisée. Si vous souhaitez être en conformité totale, il vous faudra montrer patte blanche.

Jusqu’à il y a peu, ce processus était long et coûteux. Plusieurs prestataires proposaient leurs services, comme GlobalSign ou Comodo pour n’en citer que deux. Puis en 2014 est arrivé Let’s Encrypt. Cette autorité de certification est en fait un projet commun de plusieurs organisations et mouvements (dont l’Université du Michigan, la Fondation Mozilla, etc.). À la fois simple, gratuit et rapide, le but avoué de Let’s Encrypt est d’évangéliser le web en matière de sécurisation des échanges de l’information. En à peine deux ans, c’est plus de 10 millions de certifications qui ont été créées (dont 6 millions de certificats actifs).

Quels sont les avantages et les inconvénients de HTTPS ?

HTTPS a beau sécuriser les échanges et promettre monts et merveilles, il ne faut pas se leurrer : beaucoup de sites n’en sont toujours pas équipés. Et ce n’est pas une allusion voilée aux petits sites qui n’auraient ni les moyens, ni les connaissances, ni l’infrastructure pour, mais bien aux plus gros sites de la planète qui brassent chaque jour des millions de visiteurs. Pour quelles raisons ?

Une technologie d’une lenteur accrue…

Sécuriser une connexion, ça prend du temps. Pour que les deux parties puissent s’identifier l’une à l’autre, il se passe ce que l’on appelle communément un SSL handshake (poignée de main SSL) :

1. Le client dit bonjour
   1. Le client envoie des informations au serveur pour lui dire comment communiquer avec lui en utilisant SSL (ou TLS).
   2. Cela inclut le numéro de version, les paramètres de chiffrement et les données de la session courante.
2. L’hôte dit bonjour
   1. L’hôte envoie des informations au client pour lui dire comment communiquer avec lui en utilisant SSL (ou TLS).
   2. Cela inclut le numéro de version, les paramètres de chiffrement et les données de la session courante.
   3. Cela inclut également le certificat électronique (et donc sa clé publique).
3. Authentification et génération d’une sous-clé maître
   1. Le client authentifie le certificat de l’hôte (Nom, date et émetteur).
   2. Le client (en fonction du meilleur chiffrement trouvé) créait une sous-clé maître pour la session courante.
   3. Le client crypte la sous-clé maître avec la clé publique et l’envoie à l’hôte.
4. Décryptage et clé maître
   1. Le serveur utilise sa clé privée pour décrypter la sous-clé maître.
   2. Client et hôte génèrent la clé maître avec le chiffrement convenu.
5. Génération des clés de session
   1. Le client et l’hôte utilisent la clé maître pour générer des clés de session en se servant de la cryptographie symétrique. Elles permettront de crypter puis décrypter l’information de part et d’autre pour communiquer en toute sécurité le temps de la session courante.
6. Chiffrement avec clé de session
   1. Client et hôte s’informent conjointement que les prochains messages seront désormais cryptés.

Voyez tout ce qu’il aura fallu faire pour simplement se dire “Bonjour, comment ça va ?”, “Ça va bien, merci !”.

Dans le cas de HTTP, cela se serait résumé ainsi : le client demande à l’hôte, l’hôte répond au client. Fin de la communication en deux actions. Simple, rapide, concis. Mais non sécurisé ! Alors bien sûr, tous les sites web ne nécessitent pas de sécuriser leurs informations, surtout si vous n’utilisez pas de coordonnées sensibles comme des identifiants et autres numéros de cartes bancaires. Pourtant, Google n’est pas de cet avis. En effet, depuis peu, ce dernier entend privilégier les sites web sécurisés dans ses résultats et ce quelle qu’en soit la nature de leurs activités.

(Une technologie d’une lenteur accrue…) mais ce temps-là est révolu !

Ne prêtez pas trop attention à ce que vous venez de lire. Aujourd’hui en 2016, HTTPS a emboîté le pas et il est désormais plus rapide que HTTP. Attendez… Comment cela est-il possible ? Remontons un peu dans le temps. En 2009, Google décide de concentrer ses efforts sur la réduction du temps de chargement des pages web et de leurs mises en cache. Pour cela, la firme américaine créait un nouveau protocole expérimental baptisé SPDY (prononcé Speedy). Son but n’est pas de supplanter HTTP mais de proposer des modifications majeures dans son mode de fonctionnement. Le projet marche tellement bien qu’il devient en 2012 le fer de lance d’une mise à jour de plus grande ampleur : HTTP/2. HTTP/2 entend quant à lui déclasser HTTP 1.1 tout en promettant une rétro-compatibilité technologique.

Comme expliqué dans cet article (point 3 et 4), HTTP créait une requête pour chaque nouvel élément. Cela oblige à des allers-retours incessants. Avec HTTP/2, c’est du passé. Grâce au multiplexage, il est possible de prioriser les requêtes et de les envoyer toutes d’un coup ! Autre bonne nouvelle, les en-têtes HTTP jouissent d’une meilleure compression améliorant de facto leurs transmissions. Enfin, HTTP/2 met en place la technique du server push, soit l’anticipation du besoin de l’utilisateur en envoyant directement une ressource dans le cache de son navigateur. Ainsi, le client n’a plus besoin de demander certains fichiers, le serveur sait à l’avance s’il doit les envoyer ou non et s’exécute.

L’émergence de cette technologie a obligé les navigateurs à se mettre en conformité. Tous (ou presque) implémentent aujourd’hui HTTP/2.

• Vous êtes encore sceptique ? Faites le test HTTP vs HTTPS !

Deux petites minutes… À aucun moment, il est fait mention que HTTP/2 améliore HTTPS ! Effectivement… Tandis que SPDY nécessitait de passer par une connexion sécurisée, cette obligation a été levée lors du développement de HTTP/2. Pour autant, tous les navigateurs actuels vous obligent à utiliser une connexion sécurisée (TLS) pour jouir de HTTP/2. Autrement dit, ces derniers vous forcent la main. Comme l’un ne va pas sans l’autre, vous comprendrez bien que HTTPS n’est en soit pas plus rapide qu’avant, mais que conjugué à HTTP/2, tous ses inconvénients prennent le large. Si vous souhaitez améliorer la vitesse d’affichage de votre site, il vous faudra donc obligatoirement passer par HTTPS.

Une architecture complexe

Cela paraît évident, mais il est important de le rappeler : plus un site est volumineux, plus il est complexe. Une connexion HTTPS nécessite que tous les liens internes soient sécurisés. Pour un nouveau site qui vient de se lancer ou un site de petite envergure, ce procédé est simple à mettre en place. C’est une autre paire de manche pour des sites disposant de milliers d’articles dans plusieurs sections, ayant évoluées au fil du temps et détenant des archives de plusieurs années (voire pour certaines d’une vingtaine d’années si le site existe depuis 1996).

De l’utilisation de certificats Wildcard

Il peut arriver que votre site web ait de nombreux sous-domaines. De fait, vous devrez utiliser ce que l’on appelle un certificat Wildcard (pour Wildcard certificate, wildcard signifiant joker). Il en faudra un pour chaque niveau de profondeur. Par exemple, pour une profondeur de niveau 1, un seul joker suffit (le joker * permettra de couvrir *.mondomaine.com, soit blog.mondomaine.com, forum.mondomaine.com, etc.). En revanche, pour une profondeur de niveau 2, il faudra mettre en place un second joker (*.*.mondomaine.com, pour jean.blog.mondomaine.com, tv.forum.mondomaine.com, etc.) et ainsi de suite pour autant de niveau que compte votre architecture.

Un meilleur référencement sur Google

Au-delà même de l’aspect sécuritaire qui est un avantage indéniable, Google a pris position depuis plusieurs mois en faisant le pari d’une utilisation systématique de HTTPS. Ainsi, la firme américaine utilise les leviers qui sont les siens pour prêcher la bonne parole et mettre la pression sur les administrateurs réseaux. Dernières annonces en date, tout comme l’utilisation du RWD (pour Responsive Web Design ou Site web adaptatif), la mise en place de HTTPS sera un critère de plus dans le positionnement sur les résultats de recherche. Il se pourrait même que Google ajoute une icône signalant qu’un site n’est pas sécurisé. Ces décisions font mouche et sèment la zizanie au sein de la communauté.

Faut-il absolument passer son site en HTTPS ?

La réponse n’est pas si simple et diffère selon les cas :

Vous venez de créer votre site web

Il est dommage que vous n’ayez pas pensé à mettre en place HTTPS plus tôt. Toutefois, il n’est pas trop tard. Que votre site web propose ou non des informations sensibles, vos positions sur les moteurs de recherche et votre infrastructure ne risquent pas grand-chose. En effet, vous êtes encore trop jeune pour avoir des positions claires et franches sur Google et votre site n’a pas eu le temps de beaucoup évoluer. Vous pouvez envisager le fait de rattraper le coup et d’effectuer ce changement de protocole.

Votre site existe depuis plus d’un an

Encore une fois, sauf à proposer des fonctionnalités obligeant la communication de données sensibles – auquel cas la question ne se pose même pas, vous passez en HTTPS !, la mise en place de ce protocole sécuritaire sur un site de plus d’un an pose plusieurs questions. D’abord, l’infrastructure de votre site web a pu changer. La procédure est-elle complexe ? Ensuite, le référencement a eu le temps de se faire. Et un changement vers HTTPS n’est pas sans conséquence et peut rebattre les cartes. Le jeu en vaut-il la chandelle ? Ce qu’il faut bien comprendre, c’est qu’en basculant de protocole, vous risquez de perdre – momentanément – des places sur les résultats de recherche. Pour la simple et bonne raison que la mise à jour chez Google n’est pas instantanée. Pour des entreprises dont les principaux vecteurs économiques proviennent de Google, cela peut poser de sérieux problèmes. En sachant que le gain de référencement en basculant vers HTTPS n’est pas faramineux.

Votre site existe depuis plus de 5 ans

Des sites qui durent plus de 5 ans, c’est déjà rare, mais sans refonte, sans bouger, sans nouvelles fonctionnalités, ça n’existe pas. En 5 ans ou plus, votre site a forcément gagné en référencement et ses URLs jouissent d’une ancienneté qu’il vous sera difficile de retrouver. Encore une fois, rien empêche de passer en HTTPS et de basculer la majorité de celles-ci en redirection 301. Mais en avez-vous les moyens et les possibilités ? Le gain est-il aussi net qu’on voudrait bien vous le faire croire ? Rien n’est moins sûr. En plusieurs années, vos liens internes ont gagnés en force et, paradoxalement, les faire basculer en HTTPS pourrait faire plus de mal que de bien. Et c’est bien ça la triste vérité : la raison pour laquelle encore beaucoup de sites rechignent à passer le cap est à trouver dans l’analyse coût-avantage d’une telle procédure.

Conclusion

Nous espérons que cet article aura répondu à vos questions et vous aura permis de mieux appréhender les protocoles HTTP, HTTPS, SSL et TLS. De nombreux termes ont été utilisés et nous vous invitons à vous renseigner un maximum sur tous ces sujets passionnants. Choisir de sécuriser votre site web avec HTTPS doit être une décision mûrement réfléchie, car elle impactera durablement votre architecture, votre relation avec vos visiteurs et Google. Ce n’est pas quelque-chose à prendre à la légère et nous espérons vous avoir donné quelques pistes de réflexion.