Geek Mexicain

Vous avez entendu parler du .app ? Vous pouvez dès aujourd'hui vous en procurer un pour environ 1€ par mois.

L'aspect "Sécurité" est le premier point avancé lorsque l'on parle du .app, mais avez-vous vraiment cherché pourquoi ?

Petite remise à niveau

Mais tout d'abord qu'est-ce qu'un "TLD" vous allez me dire ?

TLD signifie "Top Level Domain".
Vous en connaissez une pléthore, notamment les .com, .fr & .net, mais aussi certains plus exotiques en .onion ou .blog !

Leur acquisition se fait (moyennant un très gros chèque) auprès de l'autorité régulatrice : l'ICANN.
Par la suite, le nouveau propriétaire donne le droit sous certaines conditions à des registraires de "vendre" des noms de domaine associés (comme geek-mexicain.net par exemple).
Ainsi les clients comme vous et moi peuvent les réserver de manière à avoir totalement la main dessus, comme par exemple créer des sous-domaines et y associer des adresses IP ou bien effectuer des redirections vers d'autres adresses.

Google a acquis de cette manière le .app, pour la modique somme de 25 Millions de dollars, et a récemment donné droit aux registraires les plus connus de proposer des noms de domaine à la vente.

Et l'actualité dans tout ça ?

La plupart des sites d'actualité numérique qui prétendent y comprendre quelque chose relatent cette information en parlant d'un "nom de domaine avec HTTPS intégré".
Bien entendu cela est faux, faux et... faux.

Jamais l'utilisation d'un TLD en particulier ne pourra servir à l'authentification d'un serveur.
En effet, il est vrai qu'HTTPS permet le chiffrement des communications, mais surtout il propose des mécanismes autorisant les clients à vérifier l'identité d'un serveur, grâce à une clef privée qu'il est nécessaire de garder secrète.
Si vous ne voyez pas quel intérêt il peut y avoir à prouver l'identité d'une machine, je vous invite fortement à lire un précédent article au sujet de MyEtherWallet.com ;)

OK... Comment ça marche alors ?

Voilà voilà nous y arrivons !

En gros Google a fait le choix de se baser sur la RFC6797, soit celle qui décrit le fonctionnement d'un mécanisme dont nous vous avons déjà parlé : HSTS.

HTTP Strict Transport Security permet à un site d'indiquer qu'il ne peut doit être consulté uniquement de manière sécurisée (HTTPS donc).

Là ou cela est très fort, c'est que les directives HSTS permettent de préciser si les sous-domaines du domaine couramment consulté doivent être également concernés !
Exemple : Vous vous baladez sur geek-mexicain.net, votre navigateur reçoit et interprète la directive HSTS stipulant que cela concerne également les sous-domaines, et lorsque vous tenterez d'accéder à analytics.geek-mexicain.net par exemple, votre navigateur gardera en mémoire la directive et l'appliquera également (TL;DR vous ne pourrez pas accéder à ce site en HTTP non plus).

L'intérêt dans tout ça ?
Le voilà :

1. Vous vous connectez à Internet depuis un point d'accès Wifi dans un établissement de restauration rapide dont on ne citera pas le nom.
2. Manque de bol, vous êtes victime d'une attaque du type "L'Homme du Milieu" car le Wifi n'est pas sécurisé et l'attaquant a simulé un point d'accès ayant le même nom que celui officiel.
3. Votre navigateur est connecté sur un site où vous disposez d'un compte, et vous tentez d'y accéder en tapant directement l'adresse sans stipuler le protocole (HTTP par défaut donc).
   • Dans un cas "classique", la requête (contenant votre jeton de session) serait partie sans broncher vers le serveur, et donc interceptée par l'attaquant qui pourra y extraire votre jeton en clair !
   • Avec HSTS implémenté sur le site en question, et comme vous l'aviez déjà visité auparavant, votre navigateur "sait" en amont qu'il ne faut dialoguer uniquement de manière sécurisée avec ce site, et commencera par ré-écrire votre adresse de manière à effectuer une requête en utilisant HTTPS.
     Si pour une raison ou pour une autre HTTPS n'est pas disponible, votre navigateur vous bloquera l'accès.

Si vous êtes prêt(e) à lire un court diagramme comparatif par rapport aux deux cas précédents, voici celui proposé par le Gouvernement Australien sur une page de sensibilisation :

Cependant HSTS contient un cas particulier où il ne sert à rien : Lorsque vous visitez pour la première fois un site Internet (votre navigateur ne "sait" pas que ce site dispose d'une directive HSTS, et donc une première connexion en HTTP pourra être effectuée).

La solution de contournement est une liste appelée "HSTS preload list", maintenue par l'organisation Chromium et embarquée directement au sein des navigateurs, qui contient les noms de domaine désirant être consultés uniquement en HTTPS.
Bien entendu cette liste est gigantesque, évitez d'ouvrir le fichier en question sur un appareil mobile.

Cela commence à être plutôt bien supporté par la plupart des navigateurs (voir ici).

Mais quel est le lien avec Google et son (petit) achat... ?

Google "vend" son nouveau TLD comme sécurisé. Cela est inexact dans la mesure où il sera toujours nécessaire que les webmasters mettent en place l'aspect sécurisé de leur côté (avec le Certbot de la EFF par exemple).

Ainsi, et pour revenir à nos moutons, la seule différence avec un TLD lambda est que le .app est renseigné dans la liste de preloading HSTS avec un include_subdomains à true !

Nous remarquerons d'ailleurs qu'il ne s'agit ni du seul, ni du premier, mais que le plupart appartiennent à... Google :D

Conclusion

Donc pour résumer :

• Google n'a pas implémenté de protocole ou système révolutionnaire à destination du grand public
• Il s'agit "juste" d'un nouveau TLD court (uniquement 3 lettres) et intéressant pour certains domaines (notamment les application mobiles)
• Il est inclu par défaut dans la preload list d'HSTS, avec la particularité de concerner tous les futurs sous-domaines existants

Attention : Si vous faites l'acquisition d'un tel nom de domaine, veillez à ce que vous soyez en mesure de proposer des accès sécurisés (HTTPS donc), sinon aucun navigateur ne pourra y accéder.

Le coup de com' effectué à ce sujet est simplement là dans le but de faire passer cela comme la prochaine "norme" dans le domaine sur fond de sécurité et simplicité.

Pour Google, la promotion d'un produit, d'un projet ou même d'une application passe donc par le fait d'avoir une URL "qui pète", et un gros cadenas vert sur la page offficielle... Why not ?

Attendez-vous à avoir, à nouveau, un phénomène équivalent avec le futur .dev, qui lui touchera une communauté et des cas d'utilisation bien particuliers ;)