Journal Généralisation du mode sécurisé dans HTTP 2.0 ?

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
23
13
nov.
2013

On discute en ce moment au W3C de la généralisation du mode "sécurisé" https dans le futur HTTP 2 :
http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0625.html

Cette voie fait certainement consensus, mais quid des problèmes liés à HTTPS ?

  • # Et un autre

    Posté par  (site web personnel) . Évalué à 10.

    Et un problème supplémentaire :

    • peut-on accepter un passage obligatoire par la guilde des autorités de certification, un péage en quelque sorte, pour pouvoir publier sur le web ?

    • [^] # Re: Et un autre

      Posté par  . Évalué à 7.

      Ce n'est pas tant un problème supplémentaire qu'un corollaire (ou une reformulation) du problème n°2. Et les alternatives sont en route, cf. le lien n°3 qui parlait - si j'ai bonne mémoire - de DANE et DNSSEC.

      • [^] # Re: Et un autre

        Posté par  (site web personnel) . Évalué à 2.

        Je crois que le but est aussi de généraliser DNSSEC qui portera aussi la clef public utile à https.

        "La première sécurité est la liberté"

        • [^] # Re: Et un autre

          Posté par  . Évalué à 4.

          Disons que DANE sans DNSSEC, c'est un peu comme une porte blindée sur un mur en carton.

  • # Terrible

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    Si cela est intégré au standard cela serait terrible : une véritable catastrophe pour le web, qui ne verrait alors plus que les sites des entreprises commerciales ayant l'argent de payer des certificats inutiles… Mais bon c'est dans la ligne droite des décisions stupides du W3C ces dernières années, qui se fout bien de l'avis des utilisateurs.

    « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

    • [^] # Re: Terrible

      Posté par  (site web personnel) . Évalué à 4.

      qui se fout bien de l'avis des utilisateurs.

      La plupart des utilisateurs n'ont malheureusement pas d'avis.
      Les autres sont minoritaires.

      Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

    • [^] # Re: Terrible

      Posté par  . Évalué à 4.

      Je suis loin d'être expert dans la technicité de la chose, mais je parierai bien mon sac de carambar que le protocole intégrera tout ce qu'il faut pour que les hébergeurs-registrar puissent proposer le https de manière transparente à leurs clients et pour un prix similaire (et que moyennant un peu de magie noire DNS ça marche aussi pour un hébergeur distinct de son registrar).

      Au final, on aura juste un web plus sur, les publieurs seront plus surs qu'on n'usurpe pas leur identité de parole, et les consommateurs seront plus surs de l'origine du contenu qu'ils consomment.

      Si tu prends le premier lien de ce journal, tu verra qu'un hébergement avec https ne coûte pas grand chose : entre 0€ et 12€/an quand on cherche bien ! Soit un surcoût tout à fait marginal à celui de l'hébergement.

      BeOS le faisait il y a 20 ans !

      • [^] # Re: Terrible

        Posté par  (site web personnel, Mastodon) . Évalué à 4.

        Non car le problème c'est que le TLS passe par des CA qui ne sont pas de confiance et se font de la thune sur ce business de la non-sécurité.

        Croire que ça va améliorer quoi que ce soit c'est se fourrer le doigt dans l'œil jusqu'au trognon et ne pas savoir à quel point le fonctionnement de HTTPS est pourri de par de mauvais choix politiques et commerciaux. Il faudrait que SSL/TLS passe à MonkeySphere pour commencer à améliorer les choses, et qu'on arrête de fournir avec les navigateurs un laisser-passer pour les 600+ CA qui te font croire que l'identité du site en face est la bonne contre un max de $$$. Ça serait déjà un début, et encore ça serait toujours pas ça.

        « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

        • [^] # Re: Terrible

          Posté par  . Évalué à 4.

          C'est quand même un pas en avant par rapport à maintenant, parce que ça réduit le nombre d'intermédiaires qui pourront lire le traffic http. À mon avis, ça rend plus compliqué l'espionnage en masse invisible (même si ça serait toujours possible via des proxy https).

          Le problème des CA est un autre problème, qui peut être résolu via DANE et DNSSEC (comme dit plus haut).

          • [^] # Re: Terrible

            Posté par  (site web personnel) . Évalué à 2.

            C'est pas la seule solution et pour compléter à propos de monkesphere : Les navigateur pourraient surtout commencer à supporter la RFC 6091 … et donc par exemple pour Firefox, utiliser GnuTLS au lieu de la lib nss.
            http://www.gnutls.org/openpgp.html

            Je moinsse, tu moinsses, il moinsse, nos bots moinssent ...

        • [^] # Re: Terrible

          Posté par  . Évalué à 1.

          La proposition pour résoudre un problème politique c'est une techno ?

          BeOS le faisait il y a 20 ans !

          • [^] # Re: Terrible

            Posté par  (site web personnel) . Évalué à 5.

            DANE me semble bien pour ça, pourquoi ? Pitié, pas de « on ne peut pas résoudre un problème politique avec une solution technologique », la dernière fois que j'ai entendu quelque chose de semblable — « ton truc c'est un problème social, on ne peut pas résoudre un problème social par une solution technologique » — ben j'ai ignoré cet avis et simplement résolu le problème en question. Avec un solution technologique.

            • [^] # Re: Terrible

              Posté par  . Évalué à 1.

              ben j'ai ignoré cet avis et simplement résolu le problème en question. Avec un solution technologique.

              Waou!
              T'es trop fort!

              Linuxfr, le portail francais du logiciel libre et du neo nazisme.

          • [^] # Re: Terrible

            Posté par  . Évalué à 10.

            Parce qu'il y a un moyen politique pour résoudre un problème politique ?

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Terrible

          Posté par  . Évalué à 3.

          Il faudrait que SSL/TLS passe à MonkeySphere

          Ben en fait il aurait fallu mettre en place la toile de confiance avant de démocratiser l'Internet.

          Mais ça demandait d'éduquer les gens et tout attends faut pas déconner.

          *splash!*

        • [^] # Re: Terrible

          Posté par  . Évalué à 2.

          Juste pour dire, il existe des CA de confiance.

          Deux modèles par exemple :

          A - la certification ETSI. Les CA de confiance dans un pays de l'UE peuvent demander à être inscrites sur la liste de confiance de l'état membre en question.

          La liste de confiance de l'état membre France :

          http://references.modernisation.gouv.fr/sites/default/files/tsl-fr_xml.pdf

          B - la certification franco-française RGS, dite "qualification des prestataires de confiance de certification électronique"

          Voir là par exemple : http://www.collectivites-locales.gouv.fr/files/files/RGS_ETSI-2.pdf

          Ces deux modèles recourent à l'audit, ce qui permet par exemple de vérifier que les serveurs de PKI ne sont pas administrés en open bar sur internet comme les bouffons de Diginotar.

          Bien sur, c'est plus cher que le certificat moyen de chez GoDaddy.

          • [^] # Re: Terrible

            Posté par  (site web personnel) . Évalué à 1.

            Un certificat, c'est pas pour éviter une alerte au niveau du navigateur quand on navigue en https?

            Pourquoi vouloir faire compliqué (ou sécurisé), alors que l'utilisateur ne voit pas la différence quand c'est en http ou en https (sans alerte).

            Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

            • [^] # Re: Terrible

              Posté par  . Évalué à 3.

              C'est une vision pessimiste.

              Un travail d'éducation a été fait pour expliquer qu'il ne faut communiquer ses infos sensibles (n° de carte de crédit, mot de passe pour consulter son compte bancaire, etc.) que quand il y a le "petit cadenas".
              Il reste du boulot à faire pour d'autres infos hyper-confidentielles lâchées sans vergogne dans des connexions en clair (mot de passe email, mot de passe facebook, etc.).

              A quand un navigateur qui bloquerait les champs de saisie "password" en http ?

              BeOS le faisait il y a 20 ans !

  • # Multi site

    Posté par  (site web personnel) . Évalué à 1.

    On peut avoir une seule IP qui héberge plusieurs sites web en SSL avec des noms de domaines différents et des clés SSL différentes?

    J'avais cru comprendre que l'échange sécurisé se faisait avant même le passage de l'URL au serveur et donc, boum, pas de multi site sur la même IP.

    • [^] # Re: Multi site

      Posté par  . Évalué à 4.

      On peut avoir une seule IP qui héberge plusieurs sites web en SSL avec des noms de domaines différents et des clés SSL différentes?

      Oui, grâce à l'extension Server Name Indication du protocole TLS (SSL). Mais toutes les implémentations ne le supportent pas, en particulier les anciennes.

      • [^] # Re: Multi site

        Posté par  . Évalué à 4.

        Je travaille pour une entreprise qui déploie des sites web et on ne l'utilise pas. Car aucune version d'Internet Explorer sur Windows XP ne supporte cette partie du protocole TLS. On garanti à nos client que nos sites marchent sur les même navigateurs que Google, ce qui inclus internet explorer 8+ sur XP.

        Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »

        • [^] # Re: Multi site

          Posté par  . Évalué à 5.

          De toutes manières, on peut raisonnablement supposer que les navigateurs qui ne supportent pas SNI aujourd'hui ne supporteront pas non plus HTTP 2.0 demain.

        • [^] # Re: Multi site

          Posté par  . Évalué à 1.

          IE9 ne va même plus être supporté dans peu de temps
          http://googleappsupdates.blogspot.in/2013/11/end-of-support-for-internet-explorer-9.html

        • [^] # Re: Multi site

          Posté par  (site web personnel) . Évalué à 2.

          Encore quelques mois et Windows XP ne sera plus supporté par Microsoft :-)

          • [^] # Re: Multi site

            Posté par  . Évalué à 1.

            La part de marché de XP est encore significative, même si Microsoft abodaonnait réellement le support, les utilisateurs resteront et donc il faudra que les entrprises fassent avec

            • [^] # Re: Multi site

              Posté par  . Évalué à 1.

              continuer à supporter un vieux truc non sécurisé, c'est quoi l’intérêt ?

              en plus ce n'est pas "même si microsoft abandonnait", c'est microsoft abandonne. Ils ont même expliqué que même avec de la "grosse caillasse" ils ne ferait plus rien, c'est dire !

            • [^] # Re: Multi site

              Posté par  . Évalué à 2.

              Les entreprises peuvent déployer un navigateur moderne (genre Firefox ou Chrome).

      • [^] # Re: Multi site

        Posté par  (site web personnel) . Évalué à 4.

        Mais toutes les implémentations ne le supportent pas, en particulier les anciennes.

        Pour être plus précis, toutes les implémentations de SSL relativement récentes le prennent en charge, seules les implémentations antiques, de plus de dix ans, ne le prennent pas en charge, notamment celle de Windows XP.

    • [^] # Re: Multi site

      Posté par  . Évalué à 2.

      Une motivation supplémentaire pour passer à IPV6 ?

      BeOS le faisait il y a 20 ans !

  • # La situation est plus compliquée que ça.

    Posté par  (site web personnel) . Évalué à 4.

    Il ne faut pas résumer le débat à ce troll. Le message laisse entendre qu'il y a un consensus sur ce point ce qui est loin d'être le cas. C'est du lobbying, ni plus ni moins.

    Même d'autres gens présent à cette réunion ne sont pas d'accord sur l'interprétation.

    >>> 745 4) Requre secure underlying protocol for HTTP/2.0 (at least in web browsing)
>>> 746 
>>> 747 [ weaker for can't live with ]
>>
>> Are you saying that 4) == C), and that 4) was about using https only?
>
> In a nutshell, yes.

I'm still confused. What you say implies that http: URIs will not use 
HTTP/2. We did *not* discuss this as option 4.

    Pour l'heure on peut dire que les gens qui font des navigateurs sont plutôt pour utiliser TLS systématiquement et que les gens qui font des proxys sont carrément contre.

    > To be clear - we will still define how to use HTTP/2.0 with http:// URIs, because in some use cases, an implementer may make an informed choice to use the protocol without encryption. However, for the common case -- browsing the open Web -- you'll need to use https:// URIs and if you want to use the newest version of HTTP.

For the record, I strongly believe that support for unencrypted HTTP/2.0 is still needed and useful, particularly when you are routing it over an already “secure" channel to a resource-constrained device.  And there will likely be practical real-life limitations of what browser vendors choose to implement, i.e., no HTTP/2.0 support for http:// URIs.  However,  I honestly don’t see how this WG can actually enforce/mandate https:// and still allow http:// URIs.  So long as unencrypted URIs are supported by HTTP/2.0, the best you can do is make security recommendations since TLS is not REQUIRED (in the RFC 2119 sense) for the open web.

I also believe that HTTP/1.x has been so successful because of its ease (and freedom) of implementation. But IMHO restricting its use to https:// will only limit its use/deployment to sites/providers that can afford to deploy it and prevent HTTP/2.0 from replacing HTTP/1.1 in the long run.

    Bref s'il y a un consensus qui se dessine, il serait plutôt contre.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.