Ce matin je suis tombé sur cet excellent article de silicon.fr, qui explique que le traffic chiffré, c'est pas bien du tout:
http://www.silicon.fr/dominique-loiselet-blue-coat-generaliser-https-securite-aveugle-96379.html
Le Gorafi pourrait en faire un copier coller, ils n'auraient rien à modifier.
# Publi-reportage...
Posté par redo_fr . Évalué à 10.
Hem…
Une sorte de publi-reportage sans intérêt, où "l'expert" utilise à deux reprises le mot "crypter" à la place de chiffrer, et qui ne comprend "pas vraiment [l']argument" d'utilisation du SSL…
Poubelle :-)
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Publi-reportage...
Posté par dinomasque . Évalué à 10.
Vous avez vraiment lu l'article ???
Il se contente d'expliquer pourquoi la généralisation de HTTPS va compliquer la vie du RSSI et du DSI dans les entreprises pour leur activité de flicage du traffic web des salariés.
C'est une vraie problématique, sujette à débat d'ailleurs, et pas du tout un avis général et péremptoire comme le sont ce journal et ce commentaire …
BeOS le faisait il y a 20 ans !
[^] # Re: Publi-reportage...
Posté par coid . Évalué à 10. Dernière modification le 02 septembre 2014 à 10:04.
C’est leur problème, pas le nôtre.
C’est un peu pénible à la longue ces entreprises toujours à pleurer pour un oui pour un non.
Il faudrait que tout le monde soit à poil pour leur faire plaisir ?
Par ailleurs, vu l’argument utilisé, s’il y a déjà tant de flux https, ça fait un bail que le problème se pose. La quantité ne change pas tellement de choses à l’affaire, me semble-t-il.
[^] # Re: Publi-reportage...
Posté par GnunuX (site web personnel) . Évalué à -1.
Tu n'oublirais pas que l'employeur à des responsabilités ? Pourquoi un RSSI devrait payé pour les conneries d'un employé ?
[^] # Re: Publi-reportage...
Posté par redo_fr . Évalué à 4.
Si le RSSI a fait une bonne communication expliquant les choses interdites, et qu'il a pris toutes les mesures "raisonnables" pour protéger son SI, je ne crois pas qu'il puisse être tenu pour responsable.
Ceci dit, il doit y avoir des jurisprudences à ce niveau. Un(des) juriste(s) pour confirmer (ou pas) ?
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Publi-reportage...
Posté par Anonyme . Évalué à 7.
Et l'employé aussi. Si l'employé fait des conneries en utilisant la connexion de son entreprise, c'est lui le résponsable.
[^] # Re: Publi-reportage...
Posté par kowalsky . Évalué à -1.
Une fois que des données de l'entreprise auront fuitées ou que l'on apprend dans les médias qu'un employé de la prestigieuse entreprise "gentille corporation" passait ces journées sur des sites pédo-islmo-nazi (ou pire, linuxfr !!), le RSSI/DSI ira voir le PDG pour lui expliquer :
lol, c'est la faute des employés, mdr !
Si la sécurité en entreprise pouvait se résoudre à coup de charte informatique que personne ne lit, ça se saurait !
[^] # Re: Publi-reportage...
Posté par Anonyme . Évalué à 10.
Si un employé veut fuiter des données, c'est pas un proxy qui va l'en empecher …
Si l'employé est arreté pour avoir fait des trucs pas bien depuis sa connexion personnelle, ca va pas empecher les médias de savoir qu'il était employé par "gentille corporation". Le propriétaire de la connexion utilisée pour le faire n'a pas d'importance.
Mais bon, comme d'habitude il suffit d'évoquer des sites pédo-islmo-nazi pour justifier n'importe quel flicage.
[^] # Re: Publi-reportage...
Posté par kowalsky . Évalué à -5.
Le propriétaire de la connexion utilisée pour le faire n'a pas d'importance.
Si !
[^] # Re: Publi-reportage...
Posté par barmic . Évalué à -1.
N'importe quoi.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Publi-reportage...
Posté par kowalsky . Évalué à 1.
Tu n'a donc jamais travaillé dans une banque par exemple ?
C'est clair. J'ai l'impression de débattre avec des gens qui n'ont jamais travaillé dans des environnements de plus de 20 utilisateurs. Je me fais moinsser (je m'en fiche, je constate juste) pour des évidences dans le milieu de l'IT professionnel (grosse boites quoi).
[^] # Re: Publi-reportage...
Posté par Anonyme . Évalué à 6.
Des évidences dans le milieu de l'IT professionnel peu etre, c'est pas pour ca que c'est intelligent et qu'on doit forcement trouver ca bien.
Par exemple c'est aussi une évidence qu'il faut rajouter en bas de chaque mail une signature de 50 lignes avec un texte en 3 langues differentes pour dire que "ce mail est destiné à qui il est destiné et pas aux gens à qui il n'est pas destiné blablabla" …
[^] # Re: Publi-reportage...
Posté par Firwen (site web personnel) . Évalué à 10.
Rien à voir.
Je travaille dans une entreprise de plus de 8000 personnes, ma connexion n'est ni proxyfié ni filtré.
Je travaillais dans une entreprise de moins de 400 personnes, où le sys admin se paluchait sur bluecoat avec un résultat déplorable. (tout en ayant 1/4 des postes sous IE6, cherchez l'erreur).
Je maintiens, comme beaucoup ici que le filtrage réseau, même en entreprise EST une mauvaise idée.
1- ça a des conséquences TRES néfastes en terme de stabilité réseau (bottleneck) et de diversité protocolaire ( tout HTTP pour n'importe quoi, on ne controle absoluement plus le flux ).
2- ça a des conséquences évidente sur la productivité ( faux positifs, interruption de services, blocage logiciels )
3- ça crée des immondices comme ça, et généralise les tunnels / VPN de toute sorte.
4- ça crée sur le long terme exactement l'inverse ce que c'est censé produire: ça rend le traffic obscure et incompréhensible en faisant passer tout par HTTP(S).
Un analyseur de flux réseau + reporting est amplement suffisant, même en grande entreprise.
Et un suivi utilisateur correctement fait probablement bien plus efficace qu'un filtrage systématique.
```
[^] # Re: Publi-reportage...
Posté par barmic . Évalué à 2.
Note, je n'ai pas dis que ce n'était pas une mauvaise idée ou que généralement ce n'est pas mal fait1. Ce qui me gênait c'est que certains parlent comme si il y avait une règle qui dis « si tu as un ordinateur au boulot, tu dois avoir un internet de qualité avec », comme si il s'agissait d'un droit opposable.
Pour l'allusion des des banques, ce n'est pas une question de tailles des entreprise, mais de sécurité voulue : les banques sont connues pour avoir des réseau non connecté à internet (en plus de réseau connecté). Justement parce que :
C'est bien, mais il y a des fois où tu ne peux pas te permettre de laisser les choses se faire et te contenter de sévir après coup (cas du vidage de ton coffre fort, de la fusion de ton réacteur atomique,…) c'est des cas particuliers mais qui existent.
j'ai travaillé jusqu'à il y a peu dans une entreprise où c'était particulièrement mal fait : tout le réseau et la gestion du proxy est laissé à un prestataire (l'entreprise paie le changement de config du proxy, à chaque whitelistage), le proxy bride énormément le débit (300k/s max avec 2M sans), blocage de ce vers l’extérieur mais pas du port 22…). ↩
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Publi-reportage...
Posté par kupka . Évalué à 1.
Mais ça veut dire quoi ça ?
« les banques sont connues » ah bon ?
Quelles banques déjà ?
Banques de détail ?
Banques d'investissement ?
Banques d'affaire ?
Banques de dépôts ?
Établissements de crédit ?
Autre ?
Je ne nie pas qu'il doit y avoir des métiers dans lesquels on isole certaines machines du réseau, histoire de réduire la surface d'attaque sur des données sensibles. J'imagine que certaines agences (ANSSI, DCRI, DGSE, etc.) ont ce type de problématique. Mais je ne suis pas persuadé que les banques soient le meilleur exemple. Surtout amené avec l'argument d'autorité "les banques sont connues pour…".
Ceci dit, à titre personnel, je trouverai ça marrant qu'on isole les serveurs de trading. Comme ça toutes les banques feront des affaires avec elles-même. Ça résoudrait beaucoup de problèmes dans le monde (et ça en créerait plein d'autres).
[^] # Re: Publi-reportage...
Posté par barmic . Évalué à 6.
Bon pour parler d'un exemple que je connais tous les établissements de la Banque de France ont un réseau local non relié à internet. Mais je peux aussi te parler des Douanes françaises qui appliquent ce genre de sécurité seuls les machines qui en ont vraiment besoin sont connectées à internet (pour l'anecdote va faire du SSL avec vérification des CRL dans ce type de réseaux). Je crois que c'est aussi le cas du SGMAP fait de même.
C'est pas parce que tu n'a jamais rencontré que c'est rarissime et AMHA ça se répand avec l'amélioration de la sécurité des entreprises.
Tu vois c'est cette manière de raisonner que je contre-dis. Tu parle du besoin de déconnecter des machines, alors que, quand tu t'intéresse un minimum à la sécurité, je pense que tu réfléchis dans le sens inverse et tu te demande si une machine vraiment besoin d'accéder à internet.
Je n'ai jamais dis que les banques n'ont pas de connexion à internet, j'ai dis qu'elles ont des réseaux non-connectés à internet. Évite de détourner ce que je dis pour me contredire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Publi-reportage...
Posté par Zenitram (site web personnel) . Évalué à -2. Dernière modification le 04 septembre 2014 à 07:42.
Justement, non : imagine la loi "tout ce qui n'est pas explicetement autorisé et interdit"! Ca va te faire bondir, mais la loi, qui fait vivre des millions/milliards de personnes ensemble, fait le contraire de ce que tu aimes, sans doute pour une raison…
Bref, vaut mieux réfléchir à tout connecté par défaut, puis au besoin de déconnecter des machines.
sinon, on va se retrouver comme au début des années 2000, avec les virus qui sont quand même sur le réseau "sécurisé" car un gus en aura eu marre d'être bloqué et aura connecté le réseau "sécurisé" à Internet via une connection RTC à la mano et donc sans aucun contrôle plutôt qu'un peu de contrôle (tout lien avec un cas réel est fortuit tout ça… Ok : ou pas. Remplacer RTC par 4G 10 plus tard)
Quand on fait trop chier les gens, ils se débrouillent pour que ça marche malgré l'emmerdeur d'admin nazi de la sécu, mais sans aucune partie sécurité. A choisir…
[^] # Re: Publi-reportage...
Posté par barmic . Évalué à 5.
C'est n'importe quoi comme comparaison. Imagine qu'Android accepte tout par défaut et n'ai pas de système de gestion des droits, imagine que le noyau linux accepte tout par défaut et te permettent d'accéder à n'importe quelle adresse physique,…
Les lois qui nous contrôle nous doivent prendre en compte la liberté, ça n'a rien avoir avec la sécurité informatique.
Et tu nous parle pas du gars qui en a marre d'être bloqué et qui fait un
chmod -R 777 /? Le problème dont tu parle c'est éventuellement de sécurité mal faite.Non c'est juste que c'est souvent très mal foutu. Premièrement ce n'est JAMAIS à l'admin réseau de choisir quoi que ce soit dans ce domaine. C'est l'inverse, c'est aux utilisateurs des machines de décrire leur besoin et il faut pouvoir réagir vite aux changement (passer 4 mois pour rendre quelque chose accessible n'est pas acceptable). Mais ces besoins doivent être décris. On est pas obligé de fonctionner par machine, on peut parler de profile de machine et ainsi facilité les choses. Mais tant que l'on ne passera pas par des étapes de spécifications des besoins autant exporter tout ton SI sur facebook ou google+ ce sera plus ou prou la même chose.
Sincèrement mettre en place 3 réseaux, un pour ce qui est accessible depuis internet (une DMZ), un pour ce qui accède à internet et un pour ce qui n'est accessible et n'accède qu'au réseau interne, ce n'est pas la mère à boire, ce n'est pas bien compliqué.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Publi-reportage...
Posté par totof2000 . Évalué à 6.
Avec ta méthode, il n'y a jamais de sécurité mise en place : quand tu coupes au fur et à mesure, ben … tu coupes jamais, parce que tu trouveras toujours qqn pour te dire "si tu coupes, tu mets en péril la prod".
La sécurité se pense au début d'un projet, et autoriser tout le monde à se connecter incite à reporter la réflexion sur la sécurité à plus tard.
[^] # Re: Publi-reportage...
Posté par root_rtfm . Évalué à 1.
Justement, ils sont isolés sur un réseau dédié qui n'est pas lié à internet !
[^] # Re: Publi-reportage...
Posté par gUI (Mastodon) . Évalué à 4.
Pour rajouter de l'eau à ton moulin.
Je travaille dans une petite startup de… 100,000 employés. Un truc Américain. Ah oui : Intel.
C'est bien simple, il y a zéro filtrage (enfin si, on peut pas aller sur YouPorn), on est admin sur nos machine Windows comme Linux, et je peux même faire du SSH vers chez moi (liste de serveur socks un peu partout dans le monde, c'est à disposition).
Comme quoi le bridage pénible n'est pas une règle absolue.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Publi-reportage...
Posté par barmic . Évalué à 1.
Qui a dis que c'est la taille qui compte ?
Qui l'a dis ? Je dis que l'accès à internet n'est pas une règles absolue.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Publi-reportage...
Posté par gUI (Mastodon) . Évalué à 5.
Kowalski (oui, je dénonce moi).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Publi-reportage...
Posté par kowalsky . Évalué à 4.
Tu paiera cette dénonciation ! :)
Je n'ai pas relu mes commentaires, mais ce que je veux dire c'est que je ne trouve pas déconnant la présence d'un proxy pour raison de sécurité. L'argument du "Internet comme à la maison" pour TOUS les postes dans une entreprise qui fait attention à sa sécurité, je n'y crois pas trop (même si je sais que ça existe). Je ne redévelopperais pas plus, je n'ai pas le temps aujourd'hui (je dois installer des proxys qui blacklist /) :) !
Le pire, c'est que je ne suis pas partisan du flicage, des proxys "agressif", etc. Mais dire que "ça ne sert rien/c'est une aberration", je ne suis pas d'accord.
[^] # Re: Publi-reportage...
Posté par gUI (Mastodon) . Évalué à 3.
Alors attention : on est sous proxy (il y a toute une hiérarchie de proxy assez bien foutu d'ailleurs). On n'a pas non plus d'IP ouverte sur Internet.
Par contre on ne sent aucun filtrage (sauf encore une fois les pr0n et autres war3z). Par contre on ne ressent aucun filtrage, pas de limites HTTPS ou SSH.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Publi-reportage...
Posté par fearan . Évalué à 5.
Comme je l'ai dit ailleurs, j'ose espérer que là où les proxy nazi sont mis en place, l'utilisation de clé USB est bloqué par les machines générales, et autorisée que sur des machines spécifique dédiées à ça. Sinon mettre des proxy pour éviter la fuite de données c'est comme mettre une porte blindé sans les murs qui vont avec.
Pour le moment les seuls proxy que j'ai eu empêchaient surtout de bosser, se contournent aujourd'hui facilement (très depuis que des sites de traductions de page web existent en https). Ensuite pour avoir bossé sur des projets décrété sensible, internet n'était tout simplement pas accessible depuis les machines de travail.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Publi-reportage...
Posté par kupka . Évalué à 6.
J'ai travaillé dans 4 différentes banques ces 6 dernières années en tant que sysadmin.
Évidemment qu'on a pas un accès total à Internet. Par contre, j'ai toujours eu un accès à un gros sous ensemble du Web, modulo quelques blacklist plus ou moins débiles.
Mais j'incite tous les employeurs d'adminsys de couper l'accès Web à leurs employés. Ça pourrait être rigolo. Après il faut regarder le taux d'incidents, le niveau de veille technologique offert, la productivité et la qualité du travail qui en résultent.
On va bien se marrer.
[^] # Re: Publi-reportage...
Posté par fearan . Évalué à 4.
j'ai déjà bossé dans ce genre de condition, et vu la qualité du code que j'ai du déverminer, c'est clairement pas une bonne idée.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Publi-reportage...
Posté par claudex . Évalué à 6.
Tu oublie la deuxième partie de la phrase, ça fait longtemps que le problème se pose (Facebook ou Twitter sont en HTTPS depuis longtemps), ce n'est pas la décision de Google qui y change quoi que ce soit.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Publi-reportage...
Posté par vjm . Évalué à -1. Dernière modification le 02 septembre 2014 à 15:32.
La quantité change quelque chose par exemple parce que ça devient du trafic non cachable et non optimisable. Dans mon environnement de travail (liens satellites dans tous les sens) ça signifie une dégradation significative des performances globales. Ca peut paraître anecdotique mais les technologies que j'utilise seront celles qui seront nécessaires pour pousser Internet jusque dans les coins les plus réculés de la terre (genre Google Project Loon) et les problèmatiques sont aussi proche de celles des réseaux mobiles.
Jusqu'à présent ça se résout par de l'interception SSL. C'est assez pénible à mettre en place et ça a un effet important sur les performances des équipements qui doivent l'appliquer et donc in fine sur les coûts pour l'entreprise.
En plus, entre le certificate/key pinning qui se généralise, le développement du BYOD et les réactions ultra-violentes à des propositions raisonnables comme les Explicit Trusted Proxy, il semblerait que personne ne s'intéresse vraiment aux éventuels problèmes introduits par la généralisation accélérée du chiffrement.
[^] # Re: Publi-reportage...
Posté par Firwen (site web personnel) . Évalué à 10.
Mais bien sur.
L'interception SSL est une connerie phénoménale qui n'a pas lieu d'être.
Le but premier d'SSL est d'avoir un tunnel sécurisé de point à point, il serait bon de ne pas l'oublier.
Ouvrir la voie à l'introspection des flux sécurisés en trichant sur les autorités de certifications est le meilleur moyen de foutre tout la système en l'air.
Sincèrement, les admin déployant ce genre de technique mérite un coup de batte de base ball et je pèse mes mots.
Le jour où vous réaliserez que votre "trusted proxy" a été compromis et que l'intégralités des mots de passes et échanges sécurisés de votre entreprises sont dans la nature, vous n'aurez que vos yeux pour pleurer.
Le caching et l'optimisation de performance NE doit PAS autoriser n'importe quoi.
[^] # Re: Publi-reportage...
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 04 septembre 2014 à 07:30.
Enlève "raisonnables" de ta phrase.
Ce que tu dis, c'est que le seul moyen que pour les gens ne volent pas, c'est de les mettre tous dans une cellule individuelle de prison. Vraiment, ça résout le problème et pas grave pour les effets collatéraux.
Bref, ton problème ne légitime pas de violer la sécurité des utilisateurs. Il y a un problème, mais les Trusted Proxy sont comme les cellules de prison pour éviter que les gens ne volent pas : une mauvaise réponse à un vrai problème. Personne ne nie ton problème, mais pour le moment le problème d'autres personnes (la sécurité) est plus important quand il faut choisir, c'est tout. Propose une solution moins problématique plutôt que de faire ton Caliméro.
[^] # Re: Publi-reportage...
Posté par groumly . Évalué à 4.
Oui, c'est d'ailleurs pour ca pour ca qu'ils en discutent sur silicon.fr, le site des decideurs IT, et pas sur linuxfr, le site des trolleurs.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Publi-reportage...
Posté par fearan . Évalué à 10.
C'est surtout un commercial cherchant a vendre son produit en jouant sur la peur. Il cherche l'argument du vol d'information, mais ça ne tiens pas la route, si c'est un employé, une clé USB, voire une carte microsd sous dans la doublure de la veste via un trou dans la poche, et les informations sont dehors. (on peut aussi la mettre dans un téléphone mais ça devient hautement technique ;) ), si c'est un logiciel malveillant un zip avec mot de passe via un mail suffira amplement.
En fait la vraie utilisation de son logiciel c'est le flicage de ce que font les employés en bloquant les pages via mots clé (typiquement toutes les pages correspondant à s.?e.? dans l'url ou le contenu, comme strings_example.html. Bref il vends un logiciel perturbant le travail des employé en le faisant passer pour de la sécurité, et la perte de productivité comme un mal nécessaire, un parasite quoi.
Personnellement si j'ai a faire sortir des données d'une boite c'est sûrement pas en clair, et pas par le réseau. Ensuite si les machines n'autorisent pas les clés USB, j'ose espérer qu'elles ne sont pas connectées à internet.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Publi-reportage...
Posté par kowalsky . Évalué à 2.
Personnellement si j'ai a faire sortir des données d'une boite c'est sûrement pas en clair, et pas par le réseau. Ensuite si les machines n'autorisent pas les clés USB, j'ose espérer qu'elles ne sont pas connectées à internet.
Oui mais la tu parle du cas d'un utilisateur malveillant, c'est autre choses. Il y a des cas de fuite de données involontaire. Un exemple réel, des utilisateurs trop bavard sur le code de l'entreprise sur des réseaux sociaux liés au développement. Bien sur, dans ce cas, le proxy est une demi-solution, l'utilisateur peux toujours le faire depuis son smartphone ou autre.
Ensuite pour éviter la fuite de donnée à 100%, il y a des solutions, mais elles sont très très lourde, tellement que même l'armée US n'y arrive pas (Bradley_Manning).
[^] # Re: Publi-reportage...
Posté par Firwen (site web personnel) . Évalué à 1.
Car l'utilisateur ne peut pas utilisé son smartphone personnel pour faire ce genre de chose depuis le bureau ? Où il faut interdire le smartphone au bureau aussi ? et peut⁻être filtrer la 3G également ?
[^] # Re: Publi-reportage...
Posté par groumly . Évalué à 2.
Google s'etait prit un 0-day sous windows en 2008-2009.
C'est plus ce genre de choses qu'ils cherchent a eviter je pense. Si t'as un employe malveillant, t'es un peu baise de toutes facons.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Publi-reportage...
Posté par kowalsky . Évalué à 2.
C'est ce que je dis, le proxy ne règle pas le problème ici. Tu peux utiliser ton smartphone pour poser des questions sur des forums qui en disent long sur ton code.
Je pense que la solution ici est plutôt la sensibilisation des développeurs.
[^] # Re: Publi-reportage...
Posté par ckiller . Évalué à 7.
j'en ai une autre de problématique pour ces nazis. aujourd'hui, avec une connexion 4G sur un téléphone android, je peux balancer une bonne partie des informations d'un réseau entreprise au nez et à la barbe des admins.
[^] # Re: Publi-reportage...
Posté par Ramón Perez (site web personnel) . Évalué à 2.
Tu te crois dans les années 80, quand les entreprises avaient peur d'internet ?
Ou alors tu vis dans un pays où on fait une fouille anale tous les matins à chaque employé ?
Sinon tu es au courant pour les téléphones portables ? qui ont un accès 4G ?
[^] # Re: Publi-reportage...
Posté par totof2000 . Évalué à 6.
Hum … Je suppose que tu as une serrure sur la porte de ton domicile ? Parce que ta serrure ne sert à rien … une serrure ça se force.
# petite phrase
Posté par Adrien . Évalué à 10.
« Et maintenir le niveau de confiance offert aux utilisateurs sur les flux non cryptés sera difficile. »
Si je comprend bien, avant les internautes étaient de bon gros pigeons, mais maintant il vont se dépigeonner un peu en faisant moins confiance aux flux non chiffrés… un scandale !
# C'est bien le but du HTTPS "d'aveugler" les communications non ?
Posté par denxp . Évalué à 9.
On ne doit pas lire la même chose parce que le M. en question ne dit rien d'insensé. OK, il vend sa soupe mais l'analyse me semble correct. L'extension de l'usage du HTTPS va poser des problèmes à certaines entreprises. Celles qui, pour des raisons X ou Y, contrôlent absolument tout ce qui passe sur le réseau.
[^] # Re: C'est bien le but du HTTPS "d'aveugler" les communications non ?
Posté par 2PetitsVerres . Évalué à 7.
Si le fait de ne pas voir ce qui passe sur le réseau est un problème, il suffit de ne pas autoriser ce qui passe en chiffrer (par défaut) puis d'autoriser ce qui est permis par l'entreprise, en liste blanche.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: C'est bien le but du HTTPS "d'aveugler" les communications non ?
Posté par denxp . Évalué à 3.
Je suis d'accord. En fait pour moi ce genre de contrôle global c'est peine perdue.
Mon commentaire était plutôt dirigé vers ce journal qui semble tourné en ridicule la déclaration du gars.
Alors que dans le contexte des entreprises qui mettent en place ce genre de solution l'analyse est pertinente.
Après, je le répète il vend son machin mais c'est un peu le but de ce genre d'interview.
[^] # Re: C'est bien le but du HTTPS "d'aveugler" les communications non ?
Posté par Zenitram (site web personnel) . Évalué à 10.
Ca tombe bien, la personne interviewée à quelque chose à leur vendre pour résoudre le problème. Elle n'est pas belle la vie? ;-)
[^] # Re: C'est bien le but du HTTPS "d'aveugler" les communications non ?
Posté par ZeroHeure . Évalué à 4. Dernière modification le 02 septembre 2014 à 10:20.
Méfiez vous Z. fait une très fine allusion à la page d'accueil !
Enfin peut-être pas, mais c'est plus drôle comme ça.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: C'est bien le but du HTTPS "d'aveugler" les communications non ?
Posté par kupka . Évalué à 2.
Man in the middle?
[^] # Re: C'est bien le but du HTTPS "d'aveugler" les communications non ?
Posté par oinkoink_daotter . Évalué à 2. Dernière modification le 02 septembre 2014 à 21:17.
Oui, évidemment, avec le certificat de la CA utilisée dans le brouteur.
[^] # Re: C'est bien le but du HTTPS "d'aveugler" les communications non ?
Posté par arnaudus . Évalué à 10. Dernière modification le 02 septembre 2014 à 16:11.
Ça me semble totalement paradoxal ce truc. Soit sa technique de vente est le FUD, il raconte aux entreprises qu'elles sont entièrement responsables des conneries des employés, et que la surveillance à la mode Allemagne de l'Est est imposée par la loi. Soit il admet que la loi protège les salariés, et que l'entreprise ne peut être mise en cause en cas de problème. Mais utiliser les deux arguments, c'est se tirer une balle dans le pied.
D'une manière générale, je pense que la situation n'est pas si complexe que ça.
1) on ne peut pas se prémunir des fautes lourdes des employés. Si quelqu'un veut faire sortir un truc critique de l'entreprise, il le fera, quoi qu'on fasse. Les mesures réseau ne vont que gêner les 99.99% d'employés honnêtes.
2) on ne peut pas empêcher les employés de glander. C'est juste impossible. Si on leur coupe Internet, ils vont consulter Facebook de leur smartphone. Si on leur coupe de smartphone ils vont glander à la machine à café. Si on leur retire la machine à café ils vont planter la tête du DRH sur une pique, et c'est bien fait.
3) si on est un patron réac, et que les employés n'ont pas besoin d'internet, bah on ne leur donne pas internet. C'est aussi con que ça.
4) si les employés ont besoin d'internet, bah on leur donne et on les laisse bosser.
Je pense qu'il est important de réaliser que les "décideurs" sont souvent sous l'influence de crétins qui les baratinent, dans tous les sens. Un gusse du service info va venir expliquer que c'est très très grave d'avoir un wifi d'accès souple, ou qu'il faut à tout prix bloquer le https ; un juriste va venir expliquer que le patron va aller en prison si quelqu'un de la boite télécharge des films, etc. Mais sérieusement, pourquoi faut-il toujours faire chier tout le monde avec certitude pour éviter un risque purement virtuel et hypothétique avec des mesures totalement inefficaces?
# Heureusement, il y a des solutions
Posté par 2PetitsVerres . Évalué à 10.
Heureusement pour la sécurité, des bienfaiteurs de l'humanité (tels que Blue Coat, par exemple) peuvent fournir à ton entreprise (ou ton dictateur, aussi) des solutions de proxy-man-in-the-middle ssl. Ouf, on est sauvé.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Heureusement, il y a des solutions
Posté par Moonz . Évalué à 3.
Comment ils font pour que le navigateur ne hurle pas ?
[^] # Re: Heureusement, il y a des solutions
Posté par kowalsky . Évalué à 6.
Il faut ajouter une autorité dans le navigateur.
C'est faisable par GPO(pas sur) ou au pire en modifiant les masters.
[^] # Re: Heureusement, il y a des solutions
Posté par 2PetitsVerres . Évalué à 3.
Si les employés utilisent des PC installés par la boite, c'est assez simple. Il suffit de créer une autorité de certification (enfin sa paire de clé, signature, toussa), de mettre dans les PC de la boîte que c'est une autorité reconnue, et donner la clé à leur logiciel de man in the middle. Ça n'empêche pas l'employé curieux de jeter un oeil à la chaîne de certification et voir que c'est l'autorité MaBoite SA qui avalise le tout (quoique l'employeur voulant être discret peut tout à fait donner un autre nom que MaBoite SA.) L'autre solution c'est de se dire que de toute façon les employés accepteront le certificat.
Pour les dictateurs, c'est un peu plus compliqué, soit ils peuvent faire de façon à ce que le dictateur gueule, soit ils essayent d'obtenir un certificat reconnu par les navigateurs (deux façons, soit demander à ce que son autorité soit reconnue, soit piquer les clés à quelqu'un déjà reconnu.)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Heureusement, il y a des solutions
Posté par Parleur . Évalué à 1.
C'est le systeme technique mis en place par les bibliotheques en Tasmanie.
A part ca, le pare-feu le plus restrictif auquel j'ai jamais eu a faire directement.
Meme pour les connexions en WiFi, il fallait reaccepter a la main tous leurs certificats maisons. Et avec une extension comme Control Patrol, c'etait encore pire.
Par defaut, je n'avais plus acces a la moitie de mes activites, meme legitimes. Meme avec un VPN en TCP sur le port 80 n'etait plus possible. J'ai reussi a contourner certaines restrictions du reseau (entre autre avec un Webproxy herberge sur mon serveur en France), mais pas toutes.
D'ailleurs, si des gens peuvent me donner des idees pour tenter de contourner autrement ce genre de restrictions, je suis bien preneur. :)
[^] # Re: Heureusement, il y a des solutions
Posté par BAud (site web personnel) . Évalué à 1.
Indiquer sympathiquement à l'admin réseau chacun des protocoles et sites dont tu as besoin pour travailler efficacement, avec l'appui de ta hiérarchie au besoin.
[^] # Re: Heureusement, il y a des solutions
Posté par jyes . Évalué à 6. Dernière modification le 02 septembre 2014 à 15:31.
Et au final, comme ça ennuie tout le monde, on fourre tout sur le port 80 par facilité, et on se retrouve avec une version de TCP/IP à un seul port par adresse sur Internet.
[^] # Re: Heureusement, il y a des solutions
Posté par fearan . Évalué à 2.
alors autant je peux en indiquer deux trois de tête (stackoverflow, oracle, ibm, par exemple), autant te citer la liste des résultats google suite à une recherche me semble légèrement compliqué, surtout que tu n'es pas certains que le forum pointé te donnera la bonne réponse.
Car il est peu de problèmes qu'on se pose en informatique qui n'ont pas déjà été posées, mais elles sont sur pleins de forums différents, et emmerder son N+1 + l'admin réseau a chaque résultat potentiellement intéressant, tu risques d'avoir rapidement une fin de non recevoir des deux.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Heureusement, il y a des solutions
Posté par BAud (site web personnel) . Évalué à 2.
Je me suis effectivement mal exprimé, je supposais qu'il n'y avait que quelques restrictions (du blacklistage) et non pas un fonctionnement en liste blanche (qui peut se justifier, mais difficilement dans le cas général…).
Avec quelques restrictions identifiées, indiquer ce qui s'est retrouvé malencontreusement bloqué devrait prendre moins de temps, permettant d'arriver avec une liste assez facile à justifier (si elle l'est…). Après, tout ne sera sans doute pas accepté…
[^] # Re: Heureusement, il y a des solutions
Posté par fearan . Évalué à 2.
effectivement, vu comme ça c'est plus gérable, mais j'ai déjà eu des fin de non recevoir lorsque j'ai réclamé certains site, parce qu'ils ne voulaient pas autoriser les 'forum' dans les urls.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Heureusement, il y a des solutions
Posté par BAud (site web personnel) . Évalué à 1. Dernière modification le 02 septembre 2014 à 16:32.
bin, c'est surtout que l'admin réseau, il ne fait qu'appliquer des directives qu'on lui a indiquées, il ne le fait pas pour t'embêter spécifiquement. Certains ont néanmoins la main un peu lourde, arriver avec un besoin légitime lui permettra de lever certaines restrictions (ce qui au passage soulagera d'autres collègues qui n'ont pas fait la démarche).
les outils de filtrage ont des classes de filtrage (ou d'accès), le niveau peut être adapté. Dans ce cas, il aurait pu faire que la règle ne s'applique pas à ton cas, mais n'en avait sans doute pas le temps, pas l'envie ou tout simplement pas les outils adaptés…
[^] # Re: Heureusement, il y a des solutions
Posté par Parleur . Évalué à 3.
C'est bien gentil comme reponse, mais pas vraiment adapte.
Crois-tu sincerement qu'il y a une micro-chance pour que les regles de securite d'un reseau de bibliotheque d'un etat complet, si petit soit cet etat, soit modifiee parce-qu'un etranger qui passe de ville en ville et qui n'a meme pas paye son abonnement (ce qui n'interdit aucunement la consultation de livres et du reseau WiFi, mais qunad-meme) leur en fait la demande de debloquer entre autres des pages avec "forum" dans l'URL (parce-que oui, c'etait bien le cas, parmi d'autres problemes).
[^] # Re: Heureusement, il y a des solutions
Posté par BAud (site web personnel) . Évalué à 1.
Comment veux-tu que je sache que tu n'y étais que ponctuellement, le sujet concerne initialement les employés en entreprise ;-)
# Juste une question de point de vue
Posté par lejocelyn (site web personnel) . Évalué à 8.
Je crois qu'il faut aussi bien prendre en compte le point de vue émis qui est proposé ici : c'est un article pour les décideurs, donc du point de vue de l'entreprise et de son fonctionnement.
Au fil des ans, les entreprises ont déployé de multiples solutions – contrôles sur les contenus, IPS, IDS, firewalls, gateway, etc. – pour apporter à leurs utilisateurs un certain niveau de confiance dans l’usage de la technologie.
Si je comprends bien, il affirme que les entreprises (jolie généralisation) ont mis en place des systèmes d'analyse et de filtrage dynamique du contenu sur ces divers nœuds du réseau. Comme il l'écrit par la suite, c'est vrai que HTTPS rend en partie ces systèmes aveugles. Bon, ceci dit, il me semble que des politiques de filtrage sont toujours possibles même avec le HTTPS (moins avec le VPN mais ce n'est pas de ça dont il s'agit ici).
Est-ce qu'il y a des systèmes qui analysent le contenu HTML des pages pour les filtrer ? Est-ce que ces systèmes sont déployés en entreprise ? de manière légitime ? Si oui, effectivement, c'est effectivement problèmatique pour ces entreprises.
Ces boîtiers réseau, issus d’une technologie rachetée en 2013 à Netronome, déchiffrent le trafic crypté une seul fois et redirigent les flux vers les différents équipements.
Un petit peu de pub sur la route :)
Avec la généralisation des flux cryptés, on peut imaginer que les fabricants de firewalls, d’IDS ou de gateway proposent des composants dédiés afin d’assurer le déchiffrement sans dégrader les performances [question du mag]
Je ne suis pas sûr de comprendre. Le principe du HTTPS étant que seuls le site et l'internaute puissent déchiffrer les échanges. Ceci dit, j'imagine qu'avec un proxy, on peut changer cela, le proxy faisant office de passerelle d'internaute, c'est lui qui déchiffre les informations. Je me demande si les entreprises qui mettent cela en place informent leurs usagers de cette pratique…
Je ne comprends pas vraiment cet argument. Le SSL ne fait que garantir la confidentialité des informations véhiculées. Et n’est en rien une garantie contre la vulnérabilité des sites.
Ici, nous voyons bien le point de vue qui est défendu. La personne n'imagine même pas être un utilisateur d'internet mais seulement un fournisseur de contenu et donc responsable de la maintenance du serveur (site).
D'une manière générale, je dirais que l'article est très révélateur des pratiques mises en place et des problèmes que posent l'HTTPS vis-à-vis de ces pratiques. Je n'ai pas l'impression qu'il soit dit n'importe quoi, corrigez-moi si je me trompe, mais que seul un point de vue est défendu.
[^] # Re: Juste une question de point de vue
Posté par Jérôme Flesch (site web personnel) . Évalué à 7.
Ayant travaillé pour un fabriquant d'UTM-IPS, je peux répondre facilement à ces questions : oui.
Les UTMs sont généralement capables de filtrer, directement dans les flux HTTP, HTML et Javascript. Ceci dit, pour le HTTPS, à ma connaissance, ils proposent maintenant tous aussi des fonctionnalités pour faire du man-in-the-middle. La seule contrainte est que les postes clients doivent faire confiance à l'autorité de certification de l'UTM. À partir de là, l'UTM génère des certificats à la volée pour se faire passer pour les serveurs légitimes.
[^] # Re: Juste une question de point de vue
Posté par rakoo (site web personnel) . Évalué à 2.
Bien sur ça existe, et il en parle même dans l'article: le déchiffrement dégraderait les performances de 74%. C'est une des raisons qui fait qu'il est contre.
[^] # Re: Juste une question de point de vue
Posté par Anonyme . Évalué à 9.
Oui, pour certaines entreprises ca peut avoir du sens. Celles ou l'on a absolument aucune confiance dans les employés au point qu'ils ne doivent pas pouvoir charger une page sans que le contenu ne soit surveillé. Je suppose que dans ces entreprises, on installe aussi des micros et cameras dans toutes les pièces pour savoir ce qui se dit et se fait ? Mais c'est juste pour des raisons de sécurité, éviter qu'un employé malveillant puisse donner de mauvaises idées à ses collègues.
# Ni pour ni contre, bien au contraire !
Posté par kowalsky . Évalué à 10.
Bon, je me fais l'avocat du diable :
Parfois, je HTTPS, c'est chiant !
Je boss sur loadbalancer ou du proxy, en parfois, il y a des applis HTTPS qui déconnent et bien sur, c'est toujours la faute du réseau…
Donc je dois sortir le bon certificat, le mettre dans wireshark, déchiffrer, montrer que le problème vient de l'appli, me moquer, etc…
Mais dans certain cas, je n'ai pas le bon certificat et la, c'est chiant. Mais en même temps, de ce cas la, Blue Coat et autre ne peuvent rien faire non plus.
Par contre, je trouve que le HTTPS est "sur-vendu". Je veux dire, bien sur que c'est important, sinon on peut trivialement sniffer le réseau (entreprise, WIFI dans certain cas, opérateur) mais ce n'est pas tout. Ici (linuxfr), les gens le savent très bien que HTTPS =/= Sécurité. C'est un élément de sécurité (et encore, les proxys justement montrent qu'on peut passer outre, des états ont déjà joué avec), il faut ensuite que chez l'hébergeur du service la sécurité soit bonne, qu'il n'y ai pas de faille grossière dans l'appli, que l'utilisateur ne fasse pas n'importe quoi, qu'il n'y ai pas de personne malveillante chez l'hebergeur, etc…
Il faut du HTTPS, mais il ne faut pas que ça !
[^] # Re: Ni pour ni contre, bien au contraire !
Posté par kowalsky . Évalué à 7.
La j'étais en mode avocat du diable.
Et c'est vrai que quand tu es responsable de la sécurité d'une entreprise (ce qui n'est pas mon cas !), comment tu peux être certain que tout tes utilisateurs n'utilisent que des services sur ? Tu ne peux pas, donc tu mets des proxys qui lisent les codes qui passent pour voir les faillent à la voler ou par signature. Et la, HTTPS, c'est chiant.
En mode normal, je dirais qu'à notre époque, espérer que les utilisateurs ne naviguent que sur des sites sains sans exposer la boite, c'est un peu dommage. Si le poste de l'utilisateur est "à risque", il ne doit pas avoir accès à internet, ou au pire à un internet en mode Whitelist. Ou alors il faut accepter le risque…
[^] # Re: Ni pour ni contre, bien au contraire !
Posté par Tony Cheneau (site web personnel) . Évalué à 4.
Je réponds juste pour l'aspect technique, pour le cas où tu n'as pas le certificat et que tu maîtrises quand même ton client. Si ton application est basée sur la lib NSS (comme Mozilla et Thunderbird), tu peux renseigner la variable d'environnement SSLKEYLOGFILE pour dumper les clés SSL (les "RSA pre-master secrets" comme dit la page de doc) et les donner à manger par la suite à ton Wireshark.
# Pas crédible
Posté par steph1978 . Évalué à 5.
J'ai arrêté d'y croire à ce moment là.
# site qui sent pas bon du tout
Posté par deasy . Évalué à 3.
Je me souviens d'un
articlecoup de pub pour intel et leurs soc concurrent aux arms…en employant les mA (pas des mAh hein!) comme unité de comparaison de consommation des soc Intel sans même parler de tension pour permettre de calculer la consommation du bousin…bref ça vaut pas un clou ce que ce site diffuse.Je pense que ce site s'adresse à des dsi…
[^] # Re: site qui sent pas bon du tout
Posté par deasy . Évalué à 2.
aussi appelé dayssideure preyssay
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.