La Fibre
Télécom => Réseau => 
Protocoles réseaux sécurisés (https) => Discussion démarrée par: Optrolight le 16 novembre 2013 à 21:00:48
-
Modération : titre modifié pour correspondre au contenu "vers un cryptage de tout internet" changé en "vers un chiffrement de tout le Web?"
Voilà un article et un travail en Cour qui devrait faire plaisir a corrector :
Ils veulent chiffrer tout internet
Les répercussions des révélations d'Edward Snowden se font encore sentir. Le groupe de travail HTTPbis, qui prépare le futur standard HTTP 2.0, envisage ainsi de rendre la totalité du trafic chiffré afin de compliquer la tâche aux espions voulant écouter les communications sur le réseau. Mais le débat est encore ouvert à propos des moyens d'implèmenter ce chiffrement par défaut. Trois options sont sur la table aujourd'hui :
- Forcer l'usage du chiffrement sur l'ensemble des URL http:// sans forcer l'authentification du serveur (TLS)
- Forcer l'usage du chiffrement sur l'ensemble des URL http:// et de l'authentification TLS
- Limiter l'usage du chiffrement et du HTTP/2 aux seules URL https://, les adresses http:// restant en HTTP/1
La balance semble pencher pour le moment en faveur de l'option 3. La première donnerait en effet un faux sentiment de sécurité, les pirates éventuels pouvant facilement contrefaire un certificat pour se faire passer pour un serveur légitime et ainsi récupérer le trafic. La seconde serait réellement sûre mais trop contraignante, obligeant tous les sites même les plus mineurs à obtenir un certificat authentique. La troisième option permet favoriser une transition douce entre le système actuel et le futur web à la fois chiffré et passant par des serveurs authentifier.
Bien sûr, cela ne mettra pas le web à l'abri des pirates ou espions : on a vu par le passer des vols de certificats authentiques. Mais il ferait un pas dans la bonne direction. Outre ces améliorations relatives à la sécurité, le HTTP/2 vise également à rendre le HTTP plus efficace et plus rapide. La spécification est ainsi basée sur SPDY, développé par Google. Encore à l'état de brouillon, la spécification HTTP/2.0 commencera à être implèmentée et testée au début de l'année prochaine.
http://www.tomshardware.fr/articles/http-2-chiffrement,1-46228.html (http://www.tomshardware.fr/articles/http-2-chiffrement,1-46228.html) Par Matthieu Lamelot, le 15 novembre 2013 - Source: IETF via Arstechnica
-
Voilà un article et un travail en Cour qui devrait faire plaisir a corrector :
Pas trop vite.
Ils veulent chiffrer tout internet
En fait, cela concerne uniquement le Web!
On est loin d'une couche de chiffrement englobante comme IPsec.
Les répercussions des révélations d'Edward Snowden se font encore sentir.
Mouais. Ce n'est pas en se connectant aux sociétés US en HTTP/S, IMAP/S, SMTP/S qu'on se protège de PRISM, puisque PRISM va directement piocher dans les données stockées!
N'oublions jamais que les données au repos sont plus intéressantes pour la NSA que les données échangées, parce ces services archivent tout par défaut, ce qui donne un profil complet d'un utilisateur.
Intercepter les connexions non chiffrées est un des moyens de renseignement de la NSA, mais ça ne permet pas d'obtenir la totale" concernant un compte Gmail par exemple (sans vouloir mettre à l'index Google puisque M$ n'est pas mieux). La sécurité ne se résume pas à la confidentialité, la confidentialité ne se résume pas à une couche de chiffrement comme TLS.
Le groupe de travail HTTPbis, qui prépare le futur standard HTTP 2.0, envisage ainsi de rendre la totalité du trafic chiffré afin de compliquer la tâche aux espions voulant écouter les communications sur le réseau. Mais le débat est encore ouvert à propos des moyens d'implèmenter ce chiffrement par défaut. Trois options sont sur la table aujourd'hui :
- Forcer l'usage du chiffrement sur l'ensemble des URL http:// sans forcer l'authentification du serveur (TLS)
Forcer le chiffrement des vidéos en ligne, des mises à jour des logiciels, des ISO de linux?
Pardon mais c'est complètement débile!
Oui au chiffrement mais pas le chiffrement pour le chiffrement, juste pour amuser la galerie.
- Forcer l'usage du chiffrement sur l'ensemble des URL http:// et de l'authentification TLS
Ah oui, et pour les URL dont l'autorité pas un FQDN?
http://localhost (http://localhost) => interdit!
http://127.0.0.1 (http://127.0.0.1) => interdit!
http://mabox (http://mabox) => interdit!
http://10.0.0.1 (http://10.0.0.1) => interdit!
Aucune de ces autorités n'est globalement unique, donc aucune ne peut obtenir un certificat signifiant.
Donc c'est encore plus débile!
des serveurs authentifier.
Ouch.
http://www.tomshardware.fr/articles/http-2-chiffrement,1-46228.html (http://www.tomshardware.fr/articles/http-2-chiffrement,1-46228.html) Par Matthieu Lamelot, le 15 novembre 2013 - Source: IETF via Arstechnica
-
C'est étonnant, pour nous faire croire qu'ils vont sécuriser nos échanges, non seulement ils améliore la qualité de collecte mais en plus ils font tomber ce qu'il reste d'anonymat...
-
non seulement ils améliore la qualité de collecte mais en plus ils font tomber ce qu'il reste d'anonymat...
Comment ça ? Ici l'article parle d'une évolution du protocole HTTP qui ajouterait un couche de chiffrement obligatoire ainsi que diverses optimisations, je ne vois le rapport.
-
L'option 3 est visiblement celle qui sera mis en œuvre et c'est du chiffrement uniquement en https.
Cela ne va rien révolutionner.
Je ne serais pas étonné que les améliorations de http version 2 soit porté sur http pour le contenu non sécurisé, car le gros du trafic est et restera non sécurisé (par exemple le contenu d'une vidéo en ligne, même si le portail youtube est en https ou les mises à jour d'un système d'exploitation)
Au passage il n'y a pas de risque de sécurité pour les mises à jour Linux de recevoir une fausse mise à jour car même si les transferts sont réalisés en clair, tous les paquets sont signés => Le système refuse l’installation d'un paquet compromis que cette compromission ait eu lieu sur les serveurs miroirs ou sur le réseau.
J'imagine que Microsoft fait de même pour les mise à jour Windows Update.
-
Les installeurs et les outils de MàJ sérieux vérifient l'intégrité des fichiers.
Je me méfie de la philosophie (ou plutôt absence de philosophie) Windows où chaque logiciel possède son propre système de MàJ en revanche : qu'est-ce qui me dit que chaque outil de MàJ intégré contient un système robuste de vérification d'intégrité?
Un système robuste :
- empêche l'altération d'une MàJ
- empêche de forcer la MàJ vers une version intacte mais plus ancienne
C'est suffisamment subtil pour que des programmeurs incompétents (*) et surtout inconscients de leur incompétence pour ce qui est d'analyser un protocole cryptographique ne se fassent avoir.
(*) incompétence des programmeurs : je pense que ce boulot attire les médiocres, les personnes sans capacité d'abstraction et incapables de raisonner correctement. Je me suis fait bouler plusieurs fois de sites de programmeurs (developpez, stackexchange) parce que ces gens croient tout savoir, sont très souvent incapables de voir leurs erreurs (sauf parfois en expliquant très longtemps) et
refusent la contradiction.
N'oublions pas qu'une certaine version de IE possédait un bug assez gros : la validité du certificat d'un site HTTPS n'était jamais vérifiée.
N'oublions pas que le WEP est un accumulations d'erreurs de débutant.
-
C'est étonnant, pour nous faire croire qu'ils vont sécuriser nos échanges, non seulement ils améliore la qualité de collecte mais en plus ils font tomber ce qu'il reste d'anonymat...
Tu peux préciser ton inquiétude?
-
Pour sécuriser les échanges, il faut bien améliorer l'identification des parties qui échangent.
Et quelquechose me dit qu'on pourrait en profiter pour améliorer l'identification de qui échange.
Pour l'amélioration de la collecte, vu que ça nécessitera de grosses mise à jour logicielle et probablement certaines matérielles, c'est une excellente opportunité pour mettre à jour les redirections vers les grandes oreilles.
-
Pour sécuriser les échanges, il faut bien améliorer l'identification des parties qui échangent.
Et quelquechose me dit qu'on pourrait en profiter pour améliorer l'identification de qui échange.
Le protocole HTTP peut servir à plein de choses très différentes, dont :
- demander une ressource constante, publique, accessible à tous
- demander une ressource personnalisée, privée, accessible à des personnes autorisées
- envoyer un contenu en son nom
Certaines requêtes HTTP supposent que le client s'identifie, d'autres non. Parmi les méthodes d'identification :
- un identifiant dans l'URL
- un identifiant dans un cookie HTTP
- identification HTTP (login + mdp) (rarement utilisé pour le Web, interface utilisateur très médiocre sur 100 % des navigateurs Web)
- en HTTP/S : le certificat TLS client (très rarement utilisé)
Dès que des identifiants personnels sont utilisés, la connexion devrait être sécurisée (que ça soit avec TLS ou sans).
La protection des identifiants personnels n'est pas un luxe, c'est le niveau normal de protection que chacun est en droit d'attendre. Il n'est pas normal qu'on transmette des secrets (dont les mdp) en clair sur des connexions susceptibles d'être écoutées.
-
Pour sécuriser les échanges, il faut bien améliorer l'identification des parties qui échangent.
Tout dépend ce qu'on entend par :
- "sécuriser"
- "échange"
Je crois qu'il faut faire quelques rappels élèmentaires :
La sécurité qu'apporte la connexion sécurisée par TLS, donc HTTPS par rapport à HTTP, tient à ces points :
(1) définition des extrémités :
(1si) identification et authentification du nom du serveur : l'autorité nommée dans l'URL est bien l'extrémité de la connexion sécurisée
(1cp) définition du client
(1ci) identification et authentification du client (très rare)
(2) intégrité : les données ne sont pas altérées en route
(3) confidentialité : un espion n'apprend rien de plus sur la charge utile que la quantité (nombre de messages, sens des messages (client->serveur ou serveur->client) et taille de chaque message)
Définition des extrémités
J'ai mis "authentification du serveur" en (1) parce que c'est cette propriété de base qui donne le sens des autres.
L'identité vérifiée par (1si) est définie par "le.nom.du.serveur" dans https://le.nom.du.serveur/données/envoyées/au/serveur
Le serveur TLS devra prouver qu'il est autorisé pour parler pour "le.nom.du.serveur" (il peut être autorisé pour plusieurs autres noms).
La sécurité de ce point est relative au contenu de l'URL. Si l'URL est quelconque, si l'utilisateur ne choisit pas l'URL et qu'il n'est pas capable de la vérifier, alors le (1) est une garantie vide.
(1c) est le symétrique de (1s) au niveau TLS.
Par définition, le client est "actif" (il appelle, il compose un numéro de téléphone) alors que le serveur est "passif" (il est appelé, il décroche son téléphone), donc le nom du client n'est pas comparé au contenu d'une URL bien sûr. En l'absence de certificat TLS client, le client n'a pas de nom.
(1ci) correspond à l'identification du nom du client dans un registre.
Même quand le client n'est pas identifié par un certificat, le serveur sait qu'il a en face de lui un client donné, qu'il peut associer à un "pseudonyme" (d'où le "p"); seule, cette remarque n'a aucun sens.
- (1si) tout seul ne garantit pas grand chose : se connecter à un serveur HTTPS démontre juste que le serveur en question existe, qu'il accepte les connexions (donc que l'URL nomme bien un serveur HTTPS, qu'elle est valide jusqu'au "/")
- (1cp) tout seul ne garantit rien du tout : recevoir une connexion HTTPS démontre juste qu'il existe un internaute, quelque part.
Intégrité
(2) se définit par rapport au (1) : l'intégrité est garantie jusqu'à l'autre extrémité, qui est authentifiée. On ne peut pas parler d'intégrité si on ne définit pas entre qui et qui.
(2) donne une consistance (un effet tangible) à (1) :
(2s) le client sait que la conversation (séquence des messages envoyées et reçus) a été vue identiquement par le serveur nommé
(2c) le serveur sait que la conversation (séquence des messages envoyées et reçus) a été vue identiquement par un client, désigné par un pseudonyme.
C'est là que la remarque sur le pseudonyme du client prend un sens.
On peut faire une pause à ce point là : les garanties offertes sont effectives, elles sont déjà utiles. Par exemple, un gestionnaire de MàJ peut demander à un serveur "quelle est la version la plus récente d'un paquetage". Il a la garantie que la réponse qu'il reçoit vient du serveur et qu'elle est consécutive à sa demande, donc qu'elle n'est pas moins récente que sa demande. [On voit donc que TLS offre déjà plus que DNSSEC dans l'utilisation habituelle (RR signé), qui garantit que la réponse vient du serveur et qu'elle est la réponse à la question, mais pas qu'elle est consécutive à la question (on pourrait en théorie avoir la même garantie en générant une question nouvelle à chaque fois).] On remarque que la confidentialité n'est pas essentielle dans cette utilisation.
Avec (1)+(2) on peut faire des choses utiles, parce que (1si)+(2s) offre une vraie garantie. (Par symétrie, (1ci)+(2c) aussi.)
En revanche, (2c) qui est l'intégrité du point de vue du serveur est sans consistance : (2c) n'offre aucune garantie réelle (point de vue du serveur) en l'absence d'identification du client (1ci).
Confidentialité
(3) se définit par rapport au (1) : la confidentialité est garantie jusqu'à l'autre extrémité, qui est authentifiée. On ne peut pas parler de confidentialité si on ne définit pas entre qui et qui.
(3) garantit que seuls le C et S connaissent les données secrètes échangées, dont notamment :
- les secrets permanents (validité indéfinie) comme un mdp
- les secrets temporaires (validité courte) comme un identifiant de session (stocké dans un cookie p.ex.)
Le (3) donne une consistance (un effet tangible) à (2c), puisque le serveur peut déduire de la connaissance par le client C d'un secret (comme mdp(i) ou sid(i)) le fait que le pseudonyme p de C est associé à l'identité i. C'est (3) qui donne une consistance à un pseudonyme client.
(1)+(2)+(3) permet de s'identifier sur lafibre et de poster un contenu, de façon sûre. C'est (3) qui garantit qu'un message posté sur lafibre vient bien d'un utilisateur : la confidentialité sert à maintenir l'intégrité au niveau supérieur.
-
C'est étonnant, pour nous faire croire qu'ils vont sécuriser nos échanges, non seulement ils améliore la qualité de collecte mais en plus ils font tomber ce qu'il reste d'anonymat...
Mais déjà, en HTTP, sur le Web, sur la plupart des sites tu n'as pas un anonymat mais un pseudonymat : la plupart des sites vont placer sur ton navigateur/compte un "témoin" (cookie HTTP) globalement unique qui va identifier ton navigateur/compte lors des visites suivantes, même si tu changes d'adresse IP (un changement régulier automatique et non volontaire d'adresse IP est une méthode ridiculement faible d'anonymat sur le Web contre un adversaire décidé, puisque les cookies eux ne seront pas effacés en même temps).
Bien sûr, c'est un pseudonyme sous le contrôle par l'utilisateur, mais beaucoup de personne n'effacent pas les cookies.
Les problématiques d'anonymat lors du surf me semblent donc assez éloignées de HTTP/S vs. HTTP, même s'il y a parfois des recoupements.
-
Pour sécuriser les échanges, il faut bien améliorer l'identification des parties qui échangent.
Et quelquechose me dit qu'on pourrait en profiter pour améliorer l'identification de qui échange.
Tant que 90 % des pages Web contiennent des éléments de Google, FB, TT... je ne vois pas ce que ça change...
Mais effectivement on peut suivre une session TLS après changement d'adresse d'IP : la session n'est pas limitée à une connexion TCP ou plusieurs ayant la même IP source. Avec les "tickets", on peut maintenir une session TLS longtemps : le serveur envoie un "ticket de session" chiffré au client, qui reste utilisable après reboot du serveur ou sur un serveur différent.
Ces témoins ne sont pas sauvegardés donc il suffit de fermer le navigateur pour être sûr de ne plus avoir de sessions TLS en cours.
Attention, les sessions TLS et les tickets ne sont pas forcèment bien isolés entre le mode normal et le mode de navigation privée d'un navigateur.
Référence : RFC 5077 Stateless TLS Session Resumption (http://tools.ietf.org/html/rfc5077)
-
MODÉRATION :
La discussion concernant les contenus vidéos sur les sites vidéos HTTPS a été déplacée :
Vidéo en ligne chiffrée (https://lafibre.info/index.php?topic=13091.msg137712#msg137712)
-
- Forcer l'usage du chiffrement sur l'ensemble des URL http:// sans forcer l'authentification du serveur (TLS)
C'est ce qu'on appelle le chiffrement "opportuniste" : si le client et le serveur sont d'accord, on va chiffrer; sinon, non. Il n'y a rien d'indiqué dans l'URL donc aucune garantie, et l'utilisateur n'est pas informé.
En pratique, je ne vois pas comment on peut faire ça avec un protocole comme HTTP!
-
HTTP/2 est disponible sur Firefox 36
Chrome va proposer HTTP/2 dans la version qui sort dans quelques jour.
Le nouveau navigateur de Microsoft intégré à Windows 10, "Spartan", sera lui aussi compatible http 2.0
Au niveau des serveurs web, pour l'instant seul un petit serveur alternatif "OpenLiteSpeed" supporte HTTP/2 draft 16.
Les prochaines version des serveurs web supporteront HTTP/2. C'est le cas de IIS qui sera livré avec Windows Server 2016 (qui sortira à la fin de l'année 2015).
-
Donc on ne pourra l'utiliser quand 2016 minimum voir 2017 ?
-
Donc on ne pourra l'utiliser quand 2016 minimum voir 2017 ?
Non des maintenant, c'est deja en place dans certains navigateurs (chrome notamment).
Ca dépend principalement du serveur et ca n'est pas global donc il y aura une (tres) longue période de transition.
Il faut changer le code des serveur web ou le mettre a jour ainsi que le code de certaines applications web.
Il y a un site pour tester son navigateur de suite: https://http2.golang.org/ (https://http2.golang.org/) (ca marche avec Chrome 40+ et FF 36+).
-
Chrome c'est pas la version 41 qui supporte HTTP/2 ?
Pour le test https://http2.golang.org/ :
- Chromium 40 (sous Ubuntu 14.10) : Unfortunately, you're not using HTTP/2 right now.
- Firefox 35.0.1 (sous Ubuntu 14.10) : Congratulations, you're using HTTP/2 right now.
- Firefox 36.0 (sous Ubuntu 14.10) : Congratulations, you're using HTTP/2 right now.
- Firefox 35.0.1 (sous Windows 8.1) : Congratulations, you're using HTTP/2 right now.
- Firefox 36.0 (sous Windows 8.1) : Congratulations, you're using HTTP/2 right now.
- Internet explorer 11.0.9600 (sous Windows 8.1) : Unfortunately, you're not using HTTP/2 right now.
- Chrome 40.0.2214.111 64bits (sous Windows 8.1) : Congratulations, you're using HTTP/2 right now.
- Chrome 40.0.2214.115 64bits (sous Windows 8.1) : Congratulations, you're using HTTP/2 right now.
Donc je suis un peu étonné.
-
Effectivement sous Windows ca marche avec chrome mais pas sous Linux ...
Il y un flag pour l'activer: chrome://flags/#enable-spdy4 (ca marche sous Linux).
Sous Windows ca fait rien et reste actif par défaut. Peut-être un bug.
-
J'ai complété mes test, Firefox 35.0.1 dit être ok en HTTP 2 sous Ubuntu comme sous Windows 8.1
-
c'est tout 'frais' tout ca et comme il y a avait pas mal de systèmes qui fonctionnaient avec la version 'draft-x' il se peut qu'il reste ici ou la des oublis ou des retards de bascule en version 'final' (voir : https://github.com/http2/http2-spec/wiki/Implementations (https://github.com/http2/http2-spec/wiki/Implementations) )
Par exemple twitter.com (https://twitter.com/) est en HTTP/2 'final' mais sous chrome ca passe encore en HTTP 1.1 alors que sous FF c'est bien négocier en 2.0 (du moins sur mon PC j'ai pas testé plus).
Twitter avec Firefox:
(http://i.imgur.com/4l1a5dr.png?1)
Il faut laissé un peu de temps que le 'final' se répande un peu partout.
En pratique comme l'exemple de twitter.com le montre c'est complétement transparent pour l'utilisateur.
-
Il y a une extension pour Chrome qui affiche le protocole négocié de la page en cours: SPDY Indicator (https://chrome.google.com/webstore/detail/spdy-indicator/mpbpobfflnpcgagjijhmgnchggcjblin)
Ca gère toutes les versions de SPDY, HTTP/2 et QUIC.
On voit que google.com est en HTTP/2 (draft-14)
mais twitter.com est toujours en spdy 3.1 avec Chrome.
L'extension équivalente pour FF (https://addons.mozilla.org/fr/firefox/addon/spdy-indicator/) ne donne pas le détail de la version (mais est utile quand même).
-
Il semblerait qu'avec Chrome la plupart des services Google dont Youtube soient maintenant basculés en QUIC par défaut (je n'avais pas fait attention a cela avant et j'ai pas vu de news a ce sujet).
Conséquence première c'est de l'UDP crypté qui circule maintenant. Les FAI qui font du throttling vont être contents :)
J'ai pas vérifié si c'étais le cas sur Linux ou Mac et en mobile.
-
Bien sûr, c'est une pseudonyme sous le contrôle par l'utilisateur, mais beaucoup de personne n'effacent pas les cookies.
Les problématiques d'anonymat lors du surf me semblent donc assez éloignées de HTTP/S vs. HTTP, même s'il y a parfois des recoupements.
Presque tous les navigateurs te propose l'option d'effacer les cookies quand tu le ferme.
C'est bien une question d'éducation des gens, et pas de bridage pour te protéger...
-
Presque tous les navigateurs te propose l'option d'effacer les cookies quand tu le ferme.
C'est bien une question d'éducation des gens, et pas de bridage pour te protéger...
Quand tu as une IP fixe, est-ce que ça fait vraiment une différence?