Le HTTPS est-il réellement utile?

Salut à tous !

J’ouvre ce sujet qui va faire un vrai débat :slight_smile: et j’aimerai qu’il y ai des échanges constructif :slight_smile:

Aller c’est partit !
Tout d’abord revenons sur les bases, même si ceux qui vont participer à ce sujet doivent s’y connaitre dans le domaine, cela fera une petite introduction pour les autres.

Le HTTPS est le protocole web, qui sécurise et crypte les données entre le navigateur web, et le serveur web.
De ce fait si nous sommes en http les données qui circule entre le navigateur et le serveur sont transmise en clair, si nous sommes en https les donnés sont crypté dès la sortie du navigateur.

Le https est devenu aujourd’hui un standard en sécurité informatique, a t’elle point que les sites sans https ont énormément de mal à être référencé sur google.

Dans le cas de l’utilisation de jeedom, nous voyons souvent qu’il faut mettre le https en place pour sécurisé son serveur domotique au même titre qu’un serveur web (en même temps c’est un peu un serveur web …) mais j’aimerai débattre intelligement sur ce point :slight_smile:

Je vais donc proposé plusieurs cas de figure, je n’ai pas la science infuse et c’est tout le but d’un débat constructif.

Cas numéro 1 :
Nous utilisons un PC personnel, une connexion réseau privé (nos parents, amis …) et notre serveur
Dans ce cas j’ai du mal à voir l’intérêt de l’https tout le circuit est de confiance.

Cas numéro 2 :
Nous utilisons un PC personnel, une connexion publique, et notre serveur
Dans ce cas je recommande l’utilisation d’un VPN hébergé sur notre serveur qui va sécurisé le réseau publique, pas seulement pour jeedom, mais pour toute l’utilisation du réseau publique. Donc je ne vois pas l’intéret du https derrière un VPN personnel.

Cas numéro 3 :
Nous utilisons un téléphone portable personnel, notre forfait mobile, et notre serveur
Dans ce cas je n’ai pas de position particulière, le réseau mobile est un réseau partagé mais privé quand même.

Cas numéro 4 :
Nous utilisons un PC professionnel le réseau d’entreprise, et notre serveur
Dans ce cas je vois un intéret à l’https, d’ailleurs même derrière un https je ne recommande pas l’utilisation de la domotique sur un ordinateur ou nous ne sommes pas l’unique administrateur (PC personnel) car même en SSL derrière un https sur du pc publique (professionnel) la clé de cryptage pourra être récupéré.

Cas numéro 5 :
J’utilise un PC publique sur une connexion publique et notre serveur
https ou non faut pas faire ça … la clé https c’est toujours mieux que rien d’un point de vu du réseau publique, mais d’un point de vu du PC la clé sera récupérable … Ne jamais faire ça …

Je suis d’accord beaucoup vont répondre que la mise en place du https n’est pas compliqué et qu’elle n’apporte pas d’inconvénient alors autant le faire … je suis d’accord avec ça :slight_smile: et encore dans mon cas avec docker faire un reverse proxy est un poil plus compliqué qu’un simple ssl, mais au delà de cela le débat peu quand même intéressant, je trouve que c’est sympa de s’interroger sur ce que nous faisons plutôt que de le faire par habitude simplement car c’est la norme et c’est mieux …

1 « J'aime »

Salut,

https comme tu l’as dit chiffre et non pas crypte … la transmission par contre pour tes différents cas dans tous les cas c’est utile mais :

  • cas 1 : nos parents nos amis ne sont pas dans le même réseau que là où se trouve le jeedom donc par principe ça passe à un moment où l’autre sur un reseau dit public en l’occurrence internet
  • cas 2 : le vpn ne sécurise en rien le réseau il ne fait qu’établir un canal dédié entre le pc et le réseau distant afin de faire comme si l’ordinateur était dans le même réseau que le jeedom ça chiffre donc entre toi et le réseau distant pour simuler le même réseau VPN (Virtual Private Network)
  • cas 3 : un téléphone est dans le réseau dit public ou alors dans le meilleur des cas est « natté » donc passe par une gateway géré par l’opérateur mais dans tous les cas sortira sur internet donc aura ses communications transitant sur internet donc un réseau public
  • cas 4 : le principe https étant de la clé publique/clé privée ton client chiffre avec la clé publique et le serveur déchiffre avec la clé privée et dans le pire des cas tu verras le proxy de la société vouloir se mettre entre toi et ton jeedom via un proxy filtrant mais normalement ton navigateur te le diras car pour filtrer du https tu es obligé d’intercepter la communication donc tu le sauras. Quand à la clé de chiffrement elle est liée au certificat https utilisé par le serveur. La clé n’est récupérable que pour le côté client ou serveur qu’en pénétrant le client ou le serveur et là tu n’auras que la moitié de l’échange.
  • cas 5 : cf cas 4

Quant au fait d’utiliser un proxy dans tous les cas le https commencera TOUJOURS par un http connect ne serait-ce que pour établir le contact afin de pouvoir échanger les clés permettant le chiffrement plus communément appelé la poignée de main en français ou le SSL handshake en anglais …

Bonjour,

Je vais reprendre tes différents cas et commenter leur faiblesses.
Le premier point est cependant https. Il ne sert pas à sécuriser le serveur mais à rendre le trafic entre le client et le serveur non lisible.

Cas 1:
Tu parles de réseau privé. Je suis d’accord si tout est sur le même site.
Par contre, si le réseau privé des parents est sur un autre site. Donc sur une autre connexion WAN, tu as une partie du chemin qui passe par Internet. Donc, il faut sécuriser, soit par VPN soit par https.

Cas 2:
Si je comprends bien, tu va utiliser ton serveur comme serveur VPN pour tout accès à ton serveur mais également à l’Internet.
Tu sécurises tout ton traffic.

Cas 3:
Ton analyse est simpliste.
Chez un ISP, les connexions WAN et les connexions mobile ne sont pas sur le même réseau. Ton traffic passera par une partie de réseau semi-public interne à ton ISP.
Maintenant, si tu voyage à l’étranger, tu passera par des liens Internet entre les différents opérateurs.
Il faut donc sécuriser, soit VPN , soit https.

Cas 4:
Il faut du https. la liaison entre ton réseau d’entreprise et ton serveur passe forcément par Internet. Il faut sécuriser cette connexion.
La partie entreprise est d’ailleurs la partie la plus faible du trajet. Il n’est pas rare que les entreprises installent des solutions avec décryptage du https, analyse et réencryptage.
Le VPN est rarement possible car bloqué par les entreprises.

Cas 5:
A ne pas faire.

Mon conseil, est donc d’utiliser https pour protéger le contenu du trafic entre le client et le serveur.
Cela permet d’être protégé dans tous les cas et avec une seule configuration DNS publique.
Pour certains cas, l’utilisation supplémentaire du VPN augmente la sécurité.

Bonjour,

Je pense que le débat est déjà clôt, il suffit de voir les conclusions de tous les experts de la planète.
De plus, pourquoi s’en priver? c’est tellement simple de nos jours d’être en https, mais soit, je vais tout de même répondre car vous avez fait de grosses impasses dans vos hypothèses.

Ah oui? vous avez une ligne privé entre chez vous et vos parents ainsi que tout vos amis? vous ne passez jamais par internet?
Alors ok vous pouvez vous passer du https (et encore) mais en fait ce n’est pas le cas, vous utilisez toujours internet.

un vpn est largement plus compliqué à mettre en place!
et si on n’a besoin que de sites en https, ouvrir un vpn va à l’encontre de la sécurité de base qui est d’ouvrir le moins de portes possibles;
et prendre le controle d’une machine au travers de http (même en connaissant les identifiants) est nettement moins facile que de prendre le contrôle au travers d’un vpn, si le vpn est cassé, tout est compromis, si https est cassé, il n’y a que le site de compromis

et bien non, le réseau mobil n’est pas privé…

en fait non, la « clé » ne pourra jamais être récupérée!
mais bon ca revient au même: la terminaison ssl peut être faite sur un proxy de l’entreprise et une nouvelle connexion ssl sera établie entre ce proxy et le pc; c’est juste crapuleux de faire des choses pareil (avis personnel) mais ca se fait, c’est juste un « man in the middle » organisé.

de nouveau non, la « clé » n’est jamais récupérable…
le risque d’utiliser un pc publique c’est soit le même que le cas 4: il y a un man in the middle organisé (mais ca peut se vérifier en vérifiant le certificat reçu sur le navigateur) et d’autres part on ne sait pas quel keylogger (officiel ou officieux) se trouve (ou pas) sur la machine; donc même conclusion que vous.

1 « J'aime »

Merci pour vos réponses constructive :slight_smile:

La ou j’ai vraiment appris quelque chose, enfin je n’avais pas ce point de vu mais quand on y réfléchi 5min c’est pas bête du tout … c’est qu’un VPN est moins sécurisé qu’un https car si on fini par le péter alors les conséquences ne sont pas les mêmes …

Bonsoir,
Je profite de ce sujet pour adresser également mes questions à votre expertise :
Le risque en http est il que le flux soit récupéré par un tiers ?
Et/ou qu’il soit rerouté vers un autre site malveillant ?

Bonjour,
En https le chiffrement/déchiffrement des données est réalisé avec un algorithme symétrique et une clé partagée.

akenad :slight_smile:

1 « J'aime »

Oui mais d’autres parties sont assurées par une clé asymetrique, comme assurer l’identité du server (le certificat).
Et les clés symétriques sont générées et donc différentes pour chaque session et signées par les clés asymétriques.

Mais on dévie.

1 « J'aime »

Bonjour à tous,

Je me faufile par ici pour détailler un peu ce point particulier :

En effet, les salariés voient souvent d’un mauvais œil l’utilisation du déchiffrement par leur entreprise sur leurs communications.
Or les concepteurs de logiciels malveillants ont eux aussi bien compris l’intérêt du https : le chiffrement de leurs canaux de communication leurs garanti une invisibilité complète et fait passer leurs flux sur le réseau des victimes pour du vulgaire trafic web utilisateur.

A date 95% des flux web sur Internet sont chiffrés, la barre des 90% est passée a été franchie début novembre 2017. Est-il prudent de renoncer à analyser la majorité des flux ?

Les solutions de sécurité modernes ont des BdD des destinations réputées sûr ou malveillantes :

  • IP connues comme étant sûr (Gouv fr, Google, etc) et malveillantes (leethakz ru, botnet com, etc)
  • Signatures des certificats publiques utilisés par les différents sites et des Autorités de Certification
  • Noms de domaines, voir url complètes, triées par catégories et réputation

L’analyse de ces informations est réalisée sans regarder le contenu dans un premier temps, juste l’enveloppe. Selon le signataire/émetteur du certificat, le CN/SAN/SNI (domaine) pour lequel il est valide, il est possible de se faire une idée de la nature des flux (zones blanche et noire).

Mais souvent, les attaquants utilisent des plateformes mutualisées (AWS, Google, dropbox, etc) rendant cette première analyse peu pertinente (zone grise), il convient alors d’utiliser le déchiffrement des flux SSL pour valider la nature de la destination et le contenu.

Bref, c’est un outil comme un autre, dont il convient d’encadrer et border l’utilisation à travers la charte informatique de la structure (pas de déchiffrement des flux vers les sites bancaires, etc). C’est le travail conjoint des RH, des syndicats et de la DSI, qui se modèrent mutuellement pour avoir un filtrage raisonnable mais efficace.

Bad

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.