IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Sécurité Discussion :

Mozilla déclare la guerre contre le HTTP non-sécurisé


Sujet :

Sécurité

  1. #81
    Membre confirmé
    Avatar de vinmar
    Homme Profil pro
    Développeur Web
    Inscrit en
    Août 2012
    Messages
    139
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Service public

    Informations forums :
    Inscription : Août 2012
    Messages : 139
    Points : 516
    Points
    516
    Par défaut
    L'authentification est le processus de confirmation d'une identité. Dans le contexte d'interactions entre les réseaux, l'authentification comporte l'identification confiante d'une partie par une autre. L'authentification sur les réseaux pour avoir plusieurs formes. Les certificats sont un moyen d'authentification.

    Les interactions entre les réseaux se font généralement entre un client, tel que le navigateur d'un ordinateur personnel, et un serveur, tel que le matériel et le logiciel hébergeant un site Web. L'authentification cliente se réfère à l'identification confiante d'un client par un serveur (c'est-à-dire, l'identification de la personne supposée utiliser le logiciel client). L'authentification serveur se réfère à l'identification confiante d'un serveur par le client (c'est-à-dire, l'identification de l'organisation supposée être responsable du serveur à une adresse réseau particulière).
    Source : https://developer.mozilla.org/fr/doc...thentification

    Mozilla est d'accord avec toi, "L'authentification est le processus de confirmation d'une identité". MAIS deuxième paragraphe :

    L'authentification cliente se réfère à l'identification confiante d'un client par un serveur (c'est-à-dire, l'identification de la personne supposée utiliser le logiciel client)
    Ce qui veut dire que tu peux avoir un certificat sur ta machine qui t'identifie.

    ET

    L'authentification serveur se réfère à l'identification confiante d'un serveur par le client (c'est-à-dire, l'identification de l'organisation supposée être responsable du serveur à une adresse réseau particulière)
    Ce qui veut dire que le site peut avoir un certificat sur le serveur qui l'identifie.

    MAIS rien ne dit que l'un ne peut fonctionner sans l'autre ?!?!

    En gros tu à la droit de parler à quelqu'un qui à le visage découvert tout en ayant une cagoule sur ta tête.
    M. Lebowski : Avez-vous un emploi, monsieur ?
    Le Duc : Un emploi ?
    M. Lebowski : Ne me dites pas que vous cherchez un emploi dans cette tenue un jour de semaine ?
    Le Duc : Un jour de… Quel jour on est ?

  2. #82
    Expert éminent
    Avatar de Matthieu Vergne
    Homme Profil pro
    Consultant IT, chercheur IA indépendant
    Inscrit en
    Novembre 2011
    Messages
    2 261
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant IT, chercheur IA indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2011
    Messages : 2 261
    Points : 7 748
    Points
    7 748
    Billets dans le blog
    3
    Par défaut
    Effectivement, Flodelarab tu t'enfonces à chaque fois un peu plus avec tes cookies :

    Citation Envoyé par Flodelarab Voir le message
    Je ne comprends pas. Je croyais que Mozilla était du côté de la liberté. La liberté s'oppose à la sécurité. La sécurité est intrinsèquement relié à l'identité.
    Citation Envoyé par Flodelarab Voir le message
    C'est toujours drôle de voir un scientifique faire des fautes de logique élémentaire.
    T'as déjà navigué en https sans t'enregistrer quelque part ?
    La faute de logique (que je ne qualifierai pas d'élémentaire cependant) est de croire que le fait de n'avoir jamais accédé à un site en HTTPS sans te connecter (ou plutôt sans rester connecté, qui est le rôle usuel des cookies) est une preuve suffisante pour en inférer que le passage en HTTPS nécessite l'utilisation de cookies. En science il suffit d'un seul contre exemple pour prouver l'incohérence d'un argument : installe un navigateur que tu n'as jamais utilisé (ou ouvre une page incognito si tu as cette fonctionnalité) et va sur la page de recherche Google. Tu verras que tu seras sur une page HTTPS mais que tu n'auras nullement besoin de te connecter pour l'utiliser. Pourtant, les cookies étant sauvegarder par le navigateur, tu n'as aucun cookie fournissant tes données de connexion, et tu n'est d'ailleurs pas connecté. Mais tu peux quand même l'utiliser -> argument caduc.

    En général, un article scientifique s'organise sur 4 axes principaux :
    - une revue de l'état de l'art, pour montrer qu'on sait de quoi on parle
    - une question de recherche à répondre, montrant le problème à résoudre
    - la réponse apportée avec son argumentaire
    - la discussion de la réponse et de l'argumentaire, qui pointe les forces et faiblesses et permet d'identifier les futurs travaux potentiels

    Il se trouve que tu ne donnes rien de tout ça, et même pire : tu te moques avec dédain des tes pairs en les faisant passer pour des idiots. Tu ne fais donc que montrer l'étendu de de ton incapacité à argumenter de manière scientifique, en te contentant d'attaquer les arguments donnés via des arguments mal choisis. Si tu veux parler de science, voilà ce à quoi il va falloir t'habituer :

    ETAT DE L'ART

    Le HTTPS est la combinaison du HTTP avec SSL ou TLS. Sur le modèle OSI, le HTTP intervient dans la couche application (la plus haute) alors que TLS/SSL intervient sur les couches session et transport, comme le montre ce tableau. Les données gérées sont donc différentes. Notamment, l'authentification sur un site web, qui consiste par exemple à donner un login et un mot de passe, sont gérés par HTTP. C'est ce même HTTP qui met en place la notion de cookie.

    QUESTION

    Est-ce que le HTTPS est mis en place, comparé au HTTP simple, grâce aux cookies ?

    ARGUMENTS ET REPONSE

    Les différentes couches OSI se superposent, dans le sens où les données d'une couche sont encapsulées dans la couche directement inférieure. Cela permet d'avoir des couches indépendantes, chacune gérant ses propres données : l'ensemble des données d'une couche est prise, par la couche inférieure, comme une simple suite de bits à faire passer. Ce sont les données ajoutées par la couche elle-même qui permettent différentes machines de communiquer au niveau d'une couche donnée.

    Les cookies étant gérés par HTTP, les données de ces cookies interviennent dans la couche OSI application et sont encapsulées dans la couche suivante (présentation) avant d'atteindre les couches dédiées à SSH/TLS (session & transport). Les couches étant indépendantes, SSH/TLS est donc tout à fait ignorant des données envoyées par la couche application, qui ne sont pour lui qu'une suite de bits sans aucun sens (mais à transporter sans erreur et, pour le cas qui nous intéresse, de manière cryptée). Plus précisément, c'est une suite de bits venant de la couche présentation, qui contient une suite de bits venant de la couche application (HTTP) qui contient, potentiellement, une suite de bits relative aux cookies (il n'y a pas toujours des cookies, et ceux-ci ne sont envoyés que sous certaines conditions).

    Par conséquent, la partie cryptage étant gérée par SSH/TLS, celle-ci est indépendante des cookies gérés via HTTP. En effet, passer du HTTP au HTTPS revient à changer la couche de session/transport utilisée, qui ne dépend pas de ce qui se passe au niveau application. Qu'il y ait des cookies ou non n'intervenant donc pas à ce niveau là, le HTTPS ne se différencie pas du HTTP par la notion de cookie, et donc tout comme HTTP peut exister sans cookies, HTTPS le peut aussi. La mise en place de HTTPS ne dépend donc pas des cookies et peut se faire sans eux.

    DISCUSSION

    Je te laisse évaluer les forces de mon argumentaire et je vais me focaliser sur ses faiblesses :
    - mes sources sont principalement Wikipédia, on peut donc lui critiquer un côté "non scientifique", mais la science se fondant sur un principe d'acceptation par les pairs similaire à Wikipédia (malgré des différences notables), et les articles étant déjà fournis et existant depuis longtemps (ils ont donc eu le temps d'être revus), je pars du principe que c'est une source suffisamment fiable dans notre cas.
    - je passe outre certaines subtilités, notamment le fait que l'indépendance entre les couches OSI ne soit pas toujours respectée, par exemple TCP et UDP ne sont pas totalement indépendants de la couche inférieure IP. Cependant, j'estime que c'est suffisamment négligeable pour pouvoir l'ignorer sans impacter de manière significative la qualité de mon raisonnement. Notamment, une telle subtilité n'est pas de mise dans le cadre des cookies.

    Si tu penses que mon argumentaire scientifique est erroné, je t'invite donc à développer un argumentaire scientifique qui le démontre.
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

Discussions similaires

  1. Réponses: 2
    Dernier message: 01/09/2010, 10h36
  2. IIS + SSL, HTTPS non fonctionnel
    Par florianlyon dans le forum IIS
    Réponses: 1
    Dernier message: 02/06/2009, 16h02
  3. [Wamp] Entête HTTP non valide
    Par xunil2003 dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 2
    Dernier message: 23/03/2009, 14h31
  4. Réponses: 1
    Dernier message: 19/08/2008, 01h48
  5. Connexion FTP marche, HTTP non plus
    Par PhiberOptik dans le forum Ubuntu
    Réponses: 5
    Dernier message: 19/05/2008, 15h31

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo