larlet-fr-david/david/biologeek/archives/20091013-securite-twitter-confiance-habitudes/comments.html

<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Olivier</span> le <span class="comment-date" property="schema:commentTime">13/10/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Le comportement décrit est tout simplement effarant même s&#39;il n&#39;est pas très surprenant. Un ami, la première semaine de son embauche a fait un dump des mots de passe et autres info sensibles de tous les employés de son nouvel employeur puis les a affiché au tableau commun de cette boîte... spécialisé dans la sécurité informatique.</p>

<p>Je ne sais pas si modifier Firefox dans ce sens peut changer quelque chose (même si ça serait sans doute pas mal). Ce sont les mêmes personnes qui ont levé la main pour répondre à la question &quot;avez-vous déjà donné votre login et mot de passe twitter sur un autre service en ligne ?&quot; :)</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Thomas</span> le <span class="comment-date" property="schema:commentTime">13/10/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>D&#39;un coup, je me sens tout nu.</p>

<p>En tout cas, un nouvelle interface pour Firefox basée sur les propositions d&#39;Éric serait la bienvenue.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Clochix</span> le <span class="comment-date" property="schema:commentTime">13/10/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Tes propositions sont en effet intéressantes. Tu en as parlé à des gens de la MoFo ? Tu pourrais peut-être ouvrir un ticket sur Bugzilla.</p>

<p>Un des projets en cours pour les prochaines versions de Firefox est justement de revoir l&#39;ergonomie des pages d&#39;erreur liées au réseau : <a href="https://wiki.mozilla.org/Firefox/Projects/Network_Error_Pages">https://wiki.mozilla.org/Firefox/Projects/Network_Error_Pages</a> Ta proposition me semble tout à fait entrer dans ce cadre. </p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Martin</span> le <span class="comment-date" property="schema:commentTime">13/10/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>On se rapproche d&#39;un problème que l&#39;on retrouve sur les iphone ou androïd ou l&#39;on peut installer une application super jolie pour twitter ou voir ses stats Google Analytic.</p>

<p>C&#39;est très pratique, sauf que l&#39;éditeur de l&#39;application n&#39;est pas l&#39;éditeur du service, et le code source n&#39;étant pas accessible, cela revient à fournir ses identifiants à n&#39;importe qui !</p>

<p>Ca à l&#39;apparence du sécurisé, mais ca n&#39;en est pas...</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">13/10/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Je suis un peu circonspect par rapport à l&#39;utilisation du tiers de confiance.</p>

<p>2.1 pourquoi pas<br />2.2 l&#39;externe ne correspond pas à l&#39;interne<br />2.3 identique à 3.1 ?<br />2.4 faux tiers de confiance<br />2.5 on est dans un jardin </p>

<p>2.1, 2.4 et 2.5 sont juste la gestion du tiers de confiance, 2.3 me semble identique à 3.1. Reste 2.2.</p>

<p>Quels sont les cas possibles ?<br />a. authentification sur SSL à la Chilli Hotspot (Neuf Wifi, Free Wifi, ...) pour la première page<br />b. proxy HTTPS à la petite semaine, qui plutôt que de tunneler interceptent le trafic<br />c. homme dans le milieu</p>

<p>a. est un cas normal et transitoire, une fois l&#39;authentification passée il n&#39;y parait plus.<br />b. et c. sont équivalents, un proxy HTTPS qui fonctionne comme ça est un homme dans le milieu</p>

<p>La stratégie du prestataire de référence est donc de lui demander &quot;toi aussi tu vois le type au milieu ?&quot;, stratégie pertinente surtout si c&#39;est le premier accès à ce service (et il faut toujours faire attention au premier accès), mais déjouée si l&#39;attaque se fait sur un serveur non accessible depuis l&#39;extérieur. Pas très propre au niveau raisonnement, mais je reste non convaincu.</p>

<p>D&#39;un autre côté, une chose qu&#39;il serait intéressant d&#39;exploiter et que je ne vois pas là, est d&#39;élargir ce qu&#39;on connaît des hôtes au niveau des OU des certificats présentés et connus. Et dernier point, dans ce flux je ne vois pas la distinction entre les différentes causes d&#39;invalidité (CRLé, AC inconnue, expirée), mais peut-être est-ce sous-entendu dans &quot;message par défaut&quot; ?</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">DJ Fox</span> le <span class="comment-date" property="schema:commentTime">13/10/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Ça ne change rien de renforcer la sécurité sur FireFox : si les gens veulent quand même contourner la protection ils pourront toujours : passer par Opera, Safari, w3m, etc.</p>

<p>Et il ne faut jamais empêcher COMPLÈTEMENT un utilisateur de rentrer quand même sur un site même si le certificat n&#39;est pas valide.</p>

<p>Je prends un exemple : j&#39;ai moi-même un serveur, et un des sites hébergés dessus n&#39;est accessible que par HTTPS. Seulement, je n&#39;ai pas d&#39;argent à dépenser pour faire un vrai certificat SSL. J&#39;utilise donc un certificat auto-signé.<br />Et si on m&#39;empêchait d&#39;aller sur ce site, mon propre site alors que je suis sûr que ça n&#39;est pas malveillant puisque c&#39;est mon site ?</p>

<p>Cela dit je suis d&#39;accord que compliquer fortement la tâche d&#39;accepter un certificat SSL jugé non valide, c&#39;est bien. Mais il faut toujours laisser une possibilité de passer outre !</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">bleno</span> le <span class="comment-date" property="schema:commentTime">13/10/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Ça ne m&#39;étonne pas.</p>

<p>On prend l&#39;habitude d&#39;ajouter ces exceptions, et les informaticiens aident parfois ce processus.</p>

<p>Par exemple, dans mon école d&#39;ingénieurs, le service informatique a récemment passé l&#39;intranet et le webmail en https, mais ils ne veulent apparemment pas payer le certificat.<br />Donc ils ont expliqué à tous les élèves et profs comment ajouter une exception dans firefox.</p>

<p>Du coup, tous les élèves, profs et administratifs, pour la plupart non geek, sont familiers avec l&#39;ajout d&#39;exception dans firefox ; d&#39;autant qu&#39;il faut répéter l&#39;opération à chaque session sur les ordinateurs publics (dans l&#39;école).</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Eric</span> le <span class="comment-date" property="schema:commentTime">14/10/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>&gt; 2.1, 2.4 et 2.5 sont juste la gestion du tiers de confiance</p>

<p>Pas tout à fait pour 2.1, puisqu&#39;il peut être tout à fait légitime qu&#39;un site réponde en interne et pas en externe, mais oui, ces trois points sont là pour gérer les différents cas potentiels. J&#39;ai tenté justement de faire une procédure complète et pas juste les deux cas différent de d&#39;ordinaire.  <br />    <br />&gt; 2.2 l&#39;externe ne correspond pas à l&#39;interne    </p>

<p>Je ne vois pas de cas concret où pour une même URL un site aurait utilité à avoir des certificat différent en interne et en externe. Le cas ne s&#39;est jamais présenté à moi. Un exemple ?</p>

<p>&gt; 2.3 identique à 3.1 ?</p>

<p>Oui, sauf que si moi je ne suis pas passé (cas 3.1), peut être que quelqu&#39;un est lui déjà passé (2.3), et avec un peu de chances il sont suffisamment nombreux pour que si le résultat du test soit négatif, j&#39;ai à m&#39;inquiéter. Les deux sont intéressants</p>

<p>&gt; a. est un cas normal et transitoire, une fois l&#39;authentification passée il n&#39;y parait plus.</p>

<p>C&#39;est le cas le pire en fait, puisqu&#39;il incite à ajouter une exception qui est clairement inutile et dommageable (à ce moment là on ne sait pas encore si on est sur un spot wifi falsifié ou pas).<br />Clairement la page d&#39;erreur *doit* préciser cette éventualité et inciter à visiter un site http sans SSL pour vérifier (et là la redirection ne nécessitera pas d&#39;exception SSL). Dans l&#39;idéal Mozilla pourrait même le faire tout seul (tenter <a href="http://google.com/">http://google.com/</a> et regarder s&#39;il y a une redirection, si oui on renvoie vers la page en question, sinon on fait une erreur SSL)</p>

<p>Sinon oui, le prestataire de confiance est totalement déjoué s&#39;il s&#39;agit d&#39;un premier accès sur un site intranet non disponible depuis l&#39;extérieur. Le cas me semble suffisamment limité pour que le défaut ne soit pas important. Surtout que le prestataire de confiance n&#39;est pas là pour te dire &quot;là l&#39;exception est sûre&quot;, mais plutot &quot;là l&#39;exception est certainement une mauvaise idée&quot;. Bref, si le prestataire de confiance n&#39;est pas vraiment &quot;de confiance&quot; ou s&#39;il n&#39;est pas utile, tu ne perds rien. Tu ne peux que y gagner.</p>

<p>@DJFox: Nous sommes d&#39;accord. D&#39;ailleurs Mozilla est arrivé à la même conclusion. Maintenant le jeu c&#39;est justement de tenter de savoir si on est potentiellement dans ton cas, ou si on est certainement dans un cas de &quot;man in the middle&quot;. Si ton site a ou a eu un certificat SSL valide et certifié, et que ce n&#39;est pas le cas sur le WIFI auquel je viens de me connecter, là il y a problème. C&#39;est uniquement de ça que je parle, et dans ce cas où proposer une exception a peu de sens. Ca ne concerne donc absolument pas ton site en https auto-signé.</p>

<p>@bleno: qu&#39;ils aient un certificat ssl auto-signé pour leur webmail ne me choque pas. Qu&#39;ils n&#39;aient pas créé une fausse autorité de certification et qu&#39;ils n&#39;en aient pas installé le certificat racine sur tous les postes et portables de l&#39;école, pour une école d&#39;ingénieurs ce n&#39;est pas très malin.<br />Maintenant ces cas légitimes existent, c&#39;est bien dans cette optique que ça faudrait le coup d&#39;améliorer un peu les erreurs et leurs contextes.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">14/10/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Eric: en fait, je m&#39;interroge plus sur la probabilité réelle d&#39;être en face de 2.2 sans que ce soit visible d&#39;une autre manière. C&#39;est sur ces cas là aussi que je trouve qu&#39;on n&#39;exploite pas assez les OU.</p>

<p>Sinon pour (a), une méthode est effectivement de chercher un serveur connu (pas forcément Google qui bidouille et au niveau DNS et au niveau redirection) et de voir si on arrive vers la même redirection foireuse.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">14/10/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Eric: dans la réponse à bleno, pourquoi qualifier l&#39;autorité de certification de &quot;fausse&quot; ? Elle est aussi vrai que celle de Verisign et consorts :-)</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Eric</span> le <span class="comment-date" property="schema:commentTime">15/10/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Effectivement, qualifier une autorité de confiance crée pour l&#39;occasion de &quot;fausse&quot; n&#39;est pas malin de ma part. C&#39;est à défaut d&#39;avoir trouvé un terme approprié. Peut être que &quot;locale&quot; aurait été moins péjoratif.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Ariane</span> le <span class="comment-date" property="schema:commentTime">31/05/2010</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Dans tous les cas, contre le hacking et autres problèmes, le bon sens est de mise. Bon il ne protège pas de tout car il faut bien sortir de chez soi mais c&#39;est ce que la premire partie de votre article illustre parfaitement. <br />Faire attention, c&#39;est une regle de base, surtout quand on est entouré de geek!</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">cam</span> le <span class="comment-date" property="schema:commentTime">04/08/2010</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Eh bien, je suis d&#39;accord le sens commun est très important dans cette situation, mais il ne prévient pas toujours ces questions Arianne.I pense que Eric a fait du mieux qu&#39;il pouvait dans les circonstances.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">bruno bichet</span> le <span class="comment-date" property="schema:commentTime">27/09/2010</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Les geeks en question sont coupables de négligence, certes, mais en même temps tout repose sur la perception de ce qu&#39;est un environnement hostile. </p>

<p>Je discutait justement de ce sujet à Paris-Web l&#39;année dernière (je ne sais plus avec qui) et mon sentiment était que l’évènement étant organisé par des gens de confiance (à priori), la question de l&#39;hostilité des lieux ne se posait plus pour la majorité des gens.<br /></p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Austin lawyers</span> le <span class="comment-date" property="schema:commentTime">22/12/2010</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>M&#39;a fallu du temps pour lire tous les commentaires, mais j&#39;ai vraiment apprécié l&#39;article. Il s&#39;est avéré être très utile pour moi et je suis sûr à tous les intervenant ici! Il est toujours agréable quand on peut non seulement être informés, mais aussi divertir! Je suis sûr que vous vous êtes amusés rédaction de cet article.</p>
    </div>
</div>