Non, il ne s’agit pas d’un nouveau concurrent pour Tor (réseau) ou Freenet. Il s’agit juste d’un outil pour les personnes auto‐hébergées qui voudraient accéder à tous leurs services de n’importe où.
Cette dépêche explique son fonctionnement et ce qu’apporte sa dernière version.
Pour ceux qui ne connaissent pas, sslh part d’un constat simple : la majorité des réseaux (d’entreprise ou publics) n’acceptent plus que le HTTP. La solution des décideurs pressés est faire du HTTP pour tout « parce que ça marche partout », ça devient donc un cercle vicieux. sslh est un outil pour les idiots qui croient encore que si un protocole a été fait et optimisé pour quelque chose, c’est pour cet usage que l’on s’en sert.
Fonctionnalités premières
sslh est un raccourci pour SSL/SSH multiplexer. À l’origine, c’était un démon Perl, il a maintenant été ré‐implémenté en C pour être plus performant.
Il permet de faire tourner HTTPS et SSH sur le même port. sslh est une sorte de point d’entrée qui redirige les connexions vers le bon service.
Si on l’utilise sur le port 443, cela permet de pouvoir se connecter en SSH en utilisant le port 443 (non filtré sur la plupart des réseaux contrairement au port 22) tout en pouvant servir des pages Web en HTTPS, avec une seule adresse IP.
Comment ça marche
sslh ne déchiffre pas les connexions qui arrivent. Il repose sur une très grande différence entre le protocole SSH et HTTPS : « qui parle le premier ? ».
Dans le cas du HTTP, le client se connecte en disant « je veux telle page ». A contrario, en SSH le client attend que le serveur se présente. De cette manière, à chaque connexion, sslh attend un certain temps (configurable). Puis, si pendant ce laps de temps :
- le client ne parle pas, il redirige la connexion vers le serveur SSH ;
- le client parle, il redirige la connexion vers le serveur HTTPS.
Les nouvelles fonctionnalités
La version 1.10 supporte maintenant tous les protocoles dont vous aurez besoin pour avoir un vrai Internet comme à la maison :
- OpenVPN, qui vous permettra d’utiliser votre serveur comme point de sortie de votre connexion ;
- Tinc, OpenVPN en mieux ;
- XMPP, que certains connaissent sans doute mieux sous le nom de « Jabber ».
Mais comment est‐ce possible ?!
Eh bien, ces trois nouveaux protocoles ont aussi des particularités qui leurs sont bien singulières. Et sslh redirige les connexions en fonction de ces caractéristiques :
- le client OpenVPN commence tout le temps sa connexion par les octets
0x00,0x0Det0x38; - le client Tinc, quant à lui, commence par
« 0 »; - le client XMPP commence sa connexion avec un paquet contenant
« jabber ».
Filtrer intelligemment le port 443
Peut‐être avez‐vous peur maintenant que, sachant cela, les censeurs commencent à filtrer intelligemment le port 443.
Ne vous inquiétez pas, les décideurs pressés n’ont pas le temps de bloquer cinq gus dans un garage, qui veulent voir leur courriel en IMAP et non pas en HTTP avec Gmail. Les seuls ennemis de sslh sont les réseaux qui filtrent avec une liste blanche d’adresses IP.
Aller plus loin
- Site officiel de sslh (3069 clics)
- sslh dans Debian Sid (1470 clics)
# Pratique
Posté par ®om (site web personnel) . Évalué à 2.
Je l'utilise, ça fonctionne assez bien.
Par contre, ça ne supporte pas IPv6 (j'ai la version 1.7a-3).
Et j'ai aussi un problème pour accéder au webmail (roundcube) : si j'accède à https://monserveur/mail ça ne fonctionne pas (alors que sans sslh ça fonctionne), par contre si j'accède à https://monserveur/mail/index.php ça fonctionne (avec ou sans sslh).
blog.rom1v.com
[^] # Re: Pratique
Posté par slubman (site web personnel, Mastodon) . Évalué à 10.
J'avais fait un patch (crade) pour supporter l’IPv6 sur la version 1.7a-4. Il est disponible ici: https://github.com/slubman/sslh , si ça peut servir à certains.
[^] # Re: Pratique
Posté par ®om (site web personnel) . Évalué à 2.
Pour compléter mon message précédent, le support de l'IPv6 peut sembler accessoire (car si on avait l'IPv6, on aurait facilement plusieurs IP et pas forcément besoin de faire passer plusieurs protocoles sur le même port pour la même IP).
Si je le précise, c'est qu'en utilisant IPv6, ça ne marche pas, et on ne comprend pas pourquoi.
blog.rom1v.com
[^] # Re: Pratique
Posté par Grunt . Évalué à -2. Dernière modification le 30 novembre 2011 à 22:55.
En même temps, en IPv6, tu peux faire écouter chaque démon sur une IP différente :)
Edit: ok, j'aurais du finir de lire. Tapez moi dessus.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Pratique
Posté par Marotte ⛧ . Évalué à 2.
Voilà c'est fait.
[^] # Re: Pratique
Posté par ®om (site web personnel) . Évalué à 0. Dernière modification le 01 décembre 2011 à 07:54.
Comment tu fais pour éditer un message sur LinuxFR une fois que tu l'as validé ?
EDIT: ah bah j'ai trouvé, je n'avais jamais vu qu'on pouvait le faire ici ;-)
blog.rom1v.com
[^] # Re: Pratique
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
La fonctionnalité a été récemment introduite. Cf
https://linuxfr.org/suivi/patch-possibilit%C3%A9-d%C3%A9diter-les-commentaires et
https://linuxfr.org/suivi/am%C3%A9lioration-de-l%C3%A9dition-des-commentaires
[^] # Re: Pratique
Posté par Couz . Évalué à 2. Dernière modification le 01 décembre 2011 à 10:07.
Je ne l'avais pas vu passer non plus.
Cette fonction tellement attendue aurait au moins mérité un journal + une dépêche récapitulative des journaux en vogue du moment.
Edit : ceci est mon premier édit.
[^] # Re: Pratique
Posté par Professeur Méphisto . Évalué à 4.
et on peut aussi éditer les posts des autres ?
ok, dehors, toussa...
[^] # Re: Pratique
Posté par Moogle . Évalué à 3.
moi dessus.
# Support des proxy HTTP ?
Posté par C. OB (site web personnel) . Évalué à 3.
Bonjour,
D'après la description de la technique utilisée, ça ne parait pas possible d'utiliser sslh pour faire la même chose lorsque la boite utilise un proxy HTTPS.
J'ai commencé à voir ceci dans des grandes boites: Ils mettent des proxy HTTPS (boîtiers spécifiques je pense), ce qui fait que depuis navigateur sur un réseau local tous les sites en HTTPS déclenchent une alerte d'auto-signature SSL. En la passant, on accède au site, mais plus en mode sécurisé bien sur.
Bon, c'est un peu con, parcequ'il suffit de tunneler ça vite fait bien fait via un serveur que l'on contrôle, mais c'est néanmoins bloquant pour des choses comme sslh il me semble, non ?
Merci.
[^] # Re: Support des proxy HTTP ?
Posté par Grunt . Évalué à 2.
L'étape d'après, c'est donc un tunnel HTTP(S) qui permet de monter carrément une interface réseau virtuelle chez toi, à laquelle tu fais passer ce que tu veux.
Et dans ce cas faudrait faire le tri en fonction du User-Agent du tunnel (pour différencier le vrai HTTPS des gens, de ton tunnel).
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Support des proxy HTTP ?
Posté par Niniryoku . Évalué à 4.
C'est un problème avec les utilisateurs, ils voient une alerte SSL, ils l'ignorent et la passe. Dans le cas dont tu parles, à mon avis, ça déchiffre le connexion SSL vers le serveur et la « re-chiffre » pour le client. Et au milieu, le « proxy HTTPS » peut tout écouter et voit tout en clair. C'est plus du HTTPS, le HTTPS c'est pour que personne d'autre, à part le client et le serveur, ne puisse écouter ou modifier le flux ; c'est pour ça d'ailleurs que le navigateur met une alerte, car plus rien n'est sécurisé.
Je te déconseille totalement de te connecter au site de ta banque ou à linuxfr sur ce genre de réseau d'entreprise.
Je ne comprend pas ce que tu veux dire.
Oui, en effet.
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: Support des proxy HTTP ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Je ne comprends pas l’intérêt des boites de faire du MiM sur les connections internet https. Si jamais, une boite utilise ce genre de donné ou simplement les égare, il prenne un risque juridique énorme autour du secret de correspondance privée.
Imaginez qu'il sorte un mail privé. Ou pire imaginez qu'une base de donné est perdu, et que des identifiants de banques circulent sur internet !
Bientôt, il faudra faire du https over http.
"La première sécurité est la liberté"
[^] # Re: Support des proxy HTTP ?
Posté par oinkoink_daotter . Évalué à 5.
Vu le nombre de boîtes qui utilisent ça, je pense que quelqu'un, peut être même les antennes françaises des constructeurs qui dealent ces machins se sont posés la question ?
En pratique la violation du secret des correspondances est loin d'être si évidente si la seule intervention est par exemple des vérifications protocolaires sans regarder ce qu'il y a dedans (ie, ce qu'il y a dans un flux à destination d'un port 443 est bien du https avec des "get" dedans et pas juste un truc qui ressemble de l'extérieur) ou du contrôle antivirus (donc automatisé).
En outre, à ma connaissance, le secret de la correspondance privée n'est pas acquis en milieu professionnel, il y a eu pas mal de jurisprudences un peu contradictoires je dirais ces 5 dernières années dans le domaine du cercle privé "transporté au boulot". (Non je n'ai pas de liens)
[^] # Re: Support des proxy HTTP ?
Posté par Professeur Méphisto . Évalué à 2.
jurisprudence « nikon » et tout ce qui suit...
sur jurispedia par exemple
[^] # Re: Support des proxy HTTP ?
Posté par GTof . Évalué à 2.
Même si tu n'es pas censé lire tes mails privés ou gérer tes comptes au boulot, il y a des boites où tu dois avancer les frais pour certaines missions que ta boites rembourse ensuite. Tu peut donc être amené dans le cadre de ton boulot a utiliser des données privées (banquaire, mail, ...) avec le proxy espion de la boite. La boite n'est pas forcément mal attentionné, mais des données privées qui fuites, ca arrive. Et la, la responsabilité de la boite peut sans doute être engagée.
[^] # Re: Support des proxy HTTP ?
Posté par izulium . Évalué à 2.
L'intérêt est de simplement permettre l'analyse du flux et de filtrer en conséquence. En effet, impossible de filtrer le contenu d'un flux HTTPS. Par contre si ton contenu est en clair, tu peux interdire certains fichiers, des objets, des pages, des sites en fonction de critères. Tu peux également faire de l'analyse virale et/ou interdire l'encapsulation (et voilà, nous y sommes !).
[^] # Re: Support des proxy HTTP ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
J'ai bien compris ce qui est faisable. Sauf que si l'utilisateur passe en https, c'est pour éviter que cela soit possible. Faire des faux certificats, peut être vu comme une tromperie dans un but d'espionnage de la correspondance privée.
"La première sécurité est la liberté"
[^] # Re: Support des proxy HTTP ?
Posté par izulium . Évalué à -2.
En effet, tu dois faire confiance à un équipement supplémentaire... Ce n'est pas vraiment de l'espionnage vu que l'analyse est automatisée (et j'espère non logué!)... Un peu comme un filtre antispam... Peux-tu considérer cela comme de l'espionnage?
De plus, la charte d'utilisation d'Internet fournie par l'entreprise doit surement mentionner les termes et les conditions d'utilisation.
[^] # Re: Support des proxy HTTP ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Un mail n'est pas crypté, c'est la grosse différence. Que l'équipement soit automatique n'a aucune importance, il y a toujours quelqu'un pour le piloter derrière. Il arrivera un jour ou un informaticien viré pourrait tout à fait balancer sur internet un fichier de log avec plein d'information de connexion.
La loi interdit que l'entreprise fouille le courrier, mes emails, et les dossiers dans les ordinateurs dés qu'ils ont l'air privé. La charte d'utilisation d'internet doit aussi se conformer à cette loi.
Si le but de l'entreprise est d'éviter la fuite d'information, c'est ridicule, une clef usb fait le même boulot de façon encore plus discrète.
"La première sécurité est la liberté"
[^] # Re: Support des proxy HTTP ?
Posté par Juke (site web personnel) . Évalué à 4.
Le vendredi 02 décembre 2011 à 11:44 +0100, Nicolas Boulay a écrit :
> une clef usb fait le même boulot de façon encore plus discrète.
Exactement et si l'usb est bouché, un appareil photo ou pire la memoire du salarié suffira.
Ces limitations techniques sont donc inutile si on a interdit la fuite d'information.
De la meme facon qu'en voiture il suffit de mettre une ligne blanche pour signifier une interdiction de doubler, on ne construit pas un mur au milieu de la route.
[^] # Re: Support des proxy HTTP ?
Posté par izulium . Évalué à -3.
Tu n'y es pas sur l'encryption. L'échange de mails peut être encrypté (http://www.exim.org/exim-html-current/doc/html/spec_html/ch39.html). Quant au mail en lui-même, il peut être encrypté par d'autres moyens (PGP par exemple).
Tu n'y es pas non plus sur l'analyse. Si tu reprends les échanges précédents, je parle d'analyse virale, de filtrage mais pas de fuite d'information (ni de clef usb ! lol).
PS: Un DRH peut balancer les salaires sur Internet, un financier les comptes de la société, un ingénieur R&D des informations stratégiques... Alors ton informaticien... :-) Chaque élément de l'organisation est important.
[^] # Re: Support des proxy HTTP ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Si tu reprends les échanges précédents, je parle d'analyse virale, de filtrage mais pas de fuite d'information (ni de clef usb ! lol).
Faire croire à un informaticien, qu'il y a une différence fondamentale entre une lecture et une copie est stupéfiant.
"La première sécurité est la liberté"
[^] # Re: Support des proxy HTTP ?
Posté par izulium . Évalué à 0.
Encore une fois, tu n'y es pas.
Je parle d'un traitement automatisé vs traitement manuel.
Faire croire à un informaticien, qu'il n'y a aucune différence fondamentale entre un système automatisé et un système manuel est stupéfiant !
"Les deux corps de règles de la loi
Une partie des dispositions de la loi s’applique à tout traitement de données, même non automatisé, ce qui est trop souvent oublié. Une seconde série de dispositions s’applique en cas de traitement automatisé."
Lien: http://www.les-infostrateges.com/article/061017/les-donnees-a-caractere-personnel
[^] # Re: Support des proxy HTTP ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
La loi est juste stupide concernant l'informatique.
J'attends de voir l'admin sys avec son oscillo qui compte les bits sur le brin réseau. Et encore, est-ce que l'oscilloscope n'est pas une aide automatique ?
Derrière les trucs automatiques, il y a des hommes, qui lisent des logs avec des trucs écrit de dedans, il y a des core dump qui trainent avec tout plein d'infos. Faire croire que parce que un cron job ou un proxy transparent tourne tout seul, même dans une appliance boite noire, il ne peut y avoir de fuite, est du foutage de gueule. Il y a toujours la maintenance qui peut mettre son nez dedans.
De plus, personne ne peut jamais te garantir que le soft interne ne va pas évoluer, et la boite qui a créer l'appliance, ne garantira jamais contre des fuites de données.
J'aimerais connaitre le nombre d'admin sys qui dirait "merde" à leur patron, qui leur ordonne de leur donner des mails de webmail initialement en https.
"La première sécurité est la liberté"
[^] # Re: Support des proxy HTTP ?
Posté par izulium . Évalué à 0.
On est en accord sur deux points:
- "La loi est juste stupide concernant l'informatique."
- L'analyse technique,
- Le point de vue "Utilisateur" (Surtout pour les sites bancaires par exemple).
Je reste sur ma position sur le point de vue entreprise/gestion de la sécurité: Les clients de ces solutions (généralement de grands comptes) protègent leurs intérêts en protégeant leurs utilisateurs (généralement des non techniciens) par l'analyse virale, le filtrage applicatif...
Exemples:
- Comment traites tu le téléchargement en https (exe, bin, mp*)?
- Comment traites tu le blocage de code malicieux en https?
- Comment adaptes tu le filtrage en fonction de la politique de ta société en https?
Les besoins de l'entreprise définiront la solution et l'architecture (proxy http? https? ...).
PS: J'avoue que je n'aimerai pas être utilisateur d'un proxy https... mais il y a un intérêt à ce type de solutions !
[^] # Re: Support des proxy HTTP ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Peut-être que l'intérêt des salariés est d'avoir "Internet" et non pas, un "internet by tartenpion".
Pourquoi bloquer le téléchargement (ton 1) ? Pour faire suer tout le monde ? Si le problème est la consommation de bande passante, il faut utiliser de la Qos pour mieux la répartir. On peut avoir besoin de charger des programmes pour bosser !
Pour la lutte anti-virus, il est peut être plus utile d'avoir des machines à jour. Il me semble aussi que les url passent en clair même pour https, il peuvent donc être étudié en parallèle sans MiM pour ce qui concerne les sites publiques.
Et pourquoi avoir une politique de filtrage ? Pour pousser les gens à utiliser leur clef 3G perso ou leur smartphone ? A l'époque de la chasse à l'usage du téléphone ou du minitel, c'était pour faire des économies. Et maintenant ?
"La première sécurité est la liberté"
[^] # Re: Support des proxy HTTP ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 5.
Dans un grand compte, ce n'est pas à toi, simple utilisateur, de décider des applications que tu peux ou non installer sur ton poste de travail.
Bien souvent, tu n'auras même pas les privilèges nécessaires pour installer quoique ce soit. Cela fait partie de la sécurité de l'entreprise et du travail des équipes chargées de mettre à jour les postes de travail. Quant à savoir si elles sont réactives aux demandes, c'est une autre question.
Quant aux smartphones et clés 3G ? En général, c'est rigoureusement interdit explicitement par la Charte. Cela peut pousser (comme pour limiter les simples clés USB) à interdire les connexions USB, tout simplement. L'abus entraîne l'abus.
[^] # Re: Support des proxy HTTP ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
L'abus ? En quoi est-ce un abus ? J'ai souvent l'impression que les "grands comptes" commencent par interdire au lieu de faire confiance un minimum, je comprends mieux pourquoi les petites structure sont beaucoup plus efficace et réactive. Elle cherche d'abord à être productive, au lieu de commencer par tout interdire.
Je suis d'accord pour comprendre que selon le type d'employés, les besoins et risque ne sont pas les mêmes (employé de bureau, développeur, etc...). Parfois, je comprends aussi que l'on ne veut pas gérer d'historique et 50 version différent de format de fichier. Mais c'est ce genre de politique préhistorique qui fait que certaines boites utilisent encore IE6.
Pourquoi les services informatique en se compte pas d'agir comme une sorte de FAI du point de vue réseau ?
Quant à savoir si elles sont réactives aux demandes, c'est une autre question.
C'est juste primordial. C'est la différence entre faire le boulot et ne pas le faire. Et si jamais, ils ont leur avis à donner, cela sera toujours la solution la moins innovante qui sera choisi (car la moins risqué pour le service informatique, mais qui n'a rien à faire du résultat derrière)
Cela me rappelle que l'on m'avais parlé d'un local pour un développement classé secret défense, avec son propre réseau et port usb verrouillé. Ils avaient juste oublié de prévoir que les pdf de spec devait bien arriver par un endroit !
"La première sécurité est la liberté"
[^] # Re: Support des proxy HTTP ?
Posté par izulium . Évalué à 1.
Mon impression est que plus l'entreprise est grande, plus la confiance en l'Homme est petite. L'entreprise restreint en "pensant" instaurer la productivité (notamment via les procédures, l'organisation, des responsabilités limitées, un contrôle strict...).
En ce qui concerne l’obsolescence, il est nécessaire de revalider toutes les applications avant un déploiement. C'est long et couteux... Les DSI choisissent généralement la solution de facilité: On ne touche pas tant que cela fonctionne et que cela répond à nos besoins.
"Pourquoi les services informatique en se compte pas d'agir comme une sorte de FAI du point de vue réseau ?"
> Les DSI sont généralement des ex-financiers ou ex-directeurs rattachés à la direction financière. Ce sont de plus en plus des gestionnaires et des politiciens (et de moins en moins des visionnaires et des techniciens...). Peu de risques = peu de vagues.
[^] # Re: Support des proxy HTTP ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
DSI choisissent généralement la solution de facilité: On ne touche pas tant que cela fonctionne et que cela répond à nos besoins.
C'est bien mon reproche, ils sont un frein complet à l'amélioration.
"La première sécurité est la liberté"
[^] # Re: Support des proxy HTTP ?
Posté par izulium . Évalué à 0.
En effet, je te rejoins... L'ère du temps est de recentrer sur son secteur d'activité (Où est parti l'esprit de conquête?). En bref l'informatique est de plus en plus vu comme un secteur de coûts/contraintes et non de rentabilité/d'améliorations/d'innovations...
[^] # Re: Support des proxy HTTP ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Pour moi, un service info, c'est les gars que tu va voir en disant, "tu peux me faire ça". Et c'est fait dans l'heure. Là, tu gagnes du temps en permanence. Ils ne commencent pas, par se poser la question, si, éventuellement, il y aurait des risques potentiels.
"La première sécurité est la liberté"
[^] # Re: Support des proxy HTTP ?
Posté par izulium . Évalué à 1.
Ca marchait comme cela, il y a 10 ans. Maintenant tes ressources (parfois externes, parfois dans un autre pays) sont planifiées, réservées... les demandes du métier sont priorisées et estimées... Chaque charge est associée à un projet et à un coût. Chaque projet dispose de phases de GO/NOGO avec avantages et inconvénients qui permettent au sponsor de choisir (généralement une personne bien placé voir le DSI...). L'informaticien est devenu un conseiller et/ou un réalisation mais n'est plus décideur !
[^] # Re: Support des proxy HTTP ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Il n'y a même pas une évaluation du cout de la solution, pour éviter de dépenser plus à la discuter (genre la réunion à 10 personnes haut placé à 10k€) ?
"La première sécurité est la liberté"
[^] # Re: Support des proxy HTTP ?
Posté par izulium . Évalué à 0.
Cette méthodologie, ces processus, cette organisation ne sont pas très adaptés aux petites demandes... Il y a bien une évaluation du coût de la solution mais pas une comparaison avec le coût du traitement/de la validation (Généralement pas de plan de charge pour les managers, encore moins pour les directeurs) ! Tu peux arriver à des aberrations: Plusieurs personnes pour discuter de quelques kE autour d'une présentation de plusieurs slides !!! Les décideurs délèguent de moins en moins leur rôle décisionnel au middle management et, encore moins, aux techniciens (Le pouvoir de signature en est un exemple). Le plus difficile est de trouver le bon équilibre...
[^] # Re: Support des proxy HTTP ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 9.
Dans un grand compte, ce n'est pas à toi, simple utilisateur, de décider des applications que tu peux ou non installer sur ton poste de travail.
Sur le poste de l'hôtesse d'accueil ok, mais sur une station de travail d'un ingénieur, je ne vois pas comment il est possible de travailler correctement sans être administrateur de la machine.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Support des proxy HTTP ?
Posté par oinkoink_daotter . Évalué à 4.
Si la boîte est maline, le gars de l'informatique va déployer une mise à jour des CA des navigateurs en incluant la chaîne de certificats qui va bien pour que le navigateur reconnaisse le certificat du proxy comme étant "digne de confiance".
[^] # Re: Support des proxy HTTP ?
Posté par Damien Thébault . Évalué à 3.
Pour que ça fonctionne, il faudrait en effet que le boîte génère un certificat pour chaque site (google, banques, etc.) avec son propre CA auto-signé et installe ledit CA sur tous les PCs, c'est limite de la fraude à ce niveau.
[^] # Re: Support des proxy HTTP ?
Posté par ohm . Évalué à 3.
Non seulement ce n'est pas de la fraude, mais en plus, pour l'avoir vu, ça se pratique par au moins une entreprise du CAC40 et une de ses filiales.
[^] # Re: Support des proxy HTTP ?
Posté par Juke (site web personnel) . Évalué à 3.
Le jeudi 01 décembre 2011 à 01:20 +0100, yvesk a écrit :
> Non seulement ce n'est pas de la fraude, mais en plus, pour l'avoir vu, ça se
> pratique par au moins une entreprise du CAC40 et une de ses filiales.
ils ecoutent aussi vos conversations téléphoniques ?
[^] # Re: Support des proxy HTTP ?
Posté par ohm . Évalué à 1.
Ça ne nécessiterait pas grand-chose pour le faire. Bien entendu, ils ne le font pas, quoi qu'on en dise, on est encore un minimum protégé par la loi à ce niveau en France. Ils conservent juste les logs des appels, même si les coups de fils personnels sont tolérés. Mais il faut remettre tout dans son contexte, cette filiale étant une entreprise de Défense, donc très encadrée (ce qui est compréhensible).
[^] # Re: Support des proxy HTTP ?
Posté par Schnouki (Mastodon) . Évalué à 2.
Ahah, j'ai aussi vu ça en œuvre pendant un stage dans une filiale d'entreprise du CAC40.
Et le plus rigolo c'est que ça ne marchait "bien" qu'avec Internet Explorer (6 bien sûr) : quand je lançais mon petit Firefox, le proxy HTTPS me demandait de m'authentifier (avec des identifiants que bien sûr je n'avais pas) pour environ la moitié des sites, ce qui revenait en gros à les bloquer.
Bon en fait c'est peut-être pas si rigolo que ça...
[^] # Re: Support des proxy HTTP ?
Posté par Yves (site web personnel) . Évalué à 2.
Ça, ça vient peut-être d’un proxy NTLM, pour lequel un petit « cntlm » bien configuré te débarrasse des demandes de mot de passe… mais ça n’est pas hyper fiable, malheureusement.
tYY.
[^] # Re: Support des proxy HTTP ?
Posté par oinkoink_daotter . Évalué à 2.
Ben c'est que l'admin s'y est pris comme un branque ou que la friture n'était pas sèche.
Ca marche pas mal du tout en fait (et ça bloque mon ajaxterm, f*ck).
(Pour confirmer ce que dit gle<, ça se voit bien quand on clique sur les propriétés de sécurité de la page, et les sites à validation SSL "EV" ne sont plus en vert)
[^] # Re: Support des proxy HTTP ?
Posté par Grunt . Évalué à 10.
Ben si, c'est de la fraude: tu interceptes un échange dont le but est d'être privé, et tu maquilles l'existence de cette interception. C'est totalement mafieux comme pratique.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Support des proxy HTTP ?
Posté par C. OB (site web personnel) . Évalué à 7.
J'en suis pas si sur:
La jurisprudence considère toujours que son matos informatique, même entre tes mains et même chez toi est sa propriété, ainsi que le réseau d'accès.
En gros, donc, tu es invité sur leur réseau et leur matériel, et comme l'ont dis oinkoink_daotter et Professeur Méphisto , a partir du moment ou t'es informé (normalement en signant la charte info, ou via simple affichage), tu sais que t'a plus de vie privée entre ces murs et sur ce réseau.
Donc, ils ont le droit de faire ce qu'ils veulent, à mon avis: Bloquer toutes les connections qu'ils veulent, voire même modifier tes post en ligne sur linuxfr par exemple, à partir du moment ou ils sont chez eux. Vicieux, mais je suis pas 100% sur que tu puisses les attaquer sur çà dès lors que t'a accepté la charte. Et c'est pareil dans les écoles et universités.
Actuellement la parade est simple : Smartphone en connection 3G, ou attendre d'être revenu chez toi. Le problème reste important lorsque le SI te bloque des sites (via leur proxy filtrant y compris en HTTPS) dont t'a besoin pour bosser, comme par exemple kernel.org ou des blogs techniques avec des infos dessus (bloqué parceque c'est un blog, vu qu'ils détectent simplement la chaîne "wordpress" dans la page, ou bien , dans le cas de kernel.org, parcequ'ils considèrent que c'est un site de hacking).
J'dis pas que je trouve ça normal, mais c'est comme ça. Dans les grosses boites, c'est le nivellement par le bas qui est la norme : Sous prétexte que certains employé vont sur fessebouc la journée, on en empêche d'autre de bosser. De toute façon, tout le monde s'en fout.
Je pense qu'il y a aussi une responsabilité de l'entreprise, même si capillotracté (par exemple si, depuis la machine du boulot j'insulte mon chef sur viadeo :-) )
(comme ça ils peuvent répondre aux réquisitions judiciaires avec le texte en clair, dans une très grosse boite ça dois arriver, parfois)
Dans les entreprises, c'est chiant mais bon - c'est un jeu de chat & souris, qui abouti parfois à des chefs qui prennent un abo ADSL perso avec une box sur la ligne analogique du fax tellement le réseau "officiel" est inutilisable :-)
Non, ce qui m'ennuie vraiment beaucoup plus, c'est quand ce sont les FAI qui font ça, parfois à la demande des gouvernements, avec des certificats signé par une VRAI autorité de certif: http://files.cloudprivacy.net/ssl-mitm.pdf
Là c'est moins cool. En tous cas la France vends des systèmes pour faire pile poil ça, en particulier sur le mobile, via les autorités de certification "FAI" intégrés sur les téléphones & smartphones, systèmes que j'ai constaté être utilisés en France.
La seule solution que je connais pour, au moins, détecter ça c'est l'extension de firefox "Certificate Patrol" , et/ou les extensions du type Convergence.io et Perspectives. Pour le contourner ya pas 50 solutions, à mon avis c'est VPN dans un pays ami et puis c'est tout. En attendant que plus aucun pays ne soit ami.
[^] # Re: Support des proxy HTTP ?
Posté par Juke (site web personnel) . Évalué à 10.
Le jeudi 01 décembre 2011 à 12:33 +0100, C. OB a écrit :
> tu es invité sur leur réseau et leur matériel
C'est pas parce que ton voisin t'invite chez lui, que tu te pose sur SON
canapé, qu'il te fourni le GHB et la vaseline qu'il a forcement le droit
de te taper dans la boite.
[^] # Re: Support des proxy HTTP ?
Posté par Misc (site web personnel) . Évalué à 4. Dernière modification le 02 décembre 2011 à 17:20.
en même temps, on accepte ce genre de liberté d'entité privé pour leur gain personnel, en quoi on doit refuser ça à des entité publiques ( donc plus transparentes ) pour le bien de la société ?
SI on légitime d'un coté pour le privé, on légitime aussi pour le publique.
De plus, le fait d'accepter ces pratiques fait qu'un marché se developpe, et que les solutions sont ensuite revendus à des états peu scrupuleux, puis proposer aux notres. Il faut bien voir d'ou tout ceci commence.
[^] # Re: Support des proxy HTTP ?
Posté par Grunt . Évalué à 2.
Tu réfléchis trop, c'est suspect.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Support des proxy HTTP ?
Posté par Moonz . Évalué à 2.
Parce que le privé, tu peux dire « fuck you, je bosserai pas dans ces conditions, trouvez-vous quelqu’un d’autre ».
Par contre, un gouvernement qui surveille ses « citoyens », il apprécie rarement les « fuck you… »
[^] # Re: Support des proxy HTTP ?
Posté par ohm . Évalué à 3.
Je précise les choses pour remettre dans le bon contexte : c'était une boîte avec des contrats Défense et l'usage du réseau est bien entendu soumis à une charte. On sait donc pertinemment qu'on est derrière un proxy, avec liste blanche d'hôtes autorisés, avec le 80 et le 443 pour seuls ports d'ouverts. Et personne ne trouve ça anormal (car ça ne l'est pas) : tu n'as accès au réseau que pour une utilisation professionnelle, avec une tolérance pour une utilisation plus personnelle (pas Facebook parce que les gens y font n'importe quoi, mais des sites d'intérêt technologique par exemple). Pour le reste, tu as la 3G ou les postes du CE. Et tu es au courant parce que tu as signé la charte ; donc il n'y aucune sorte de fraude. Certes, c'est un peu caguant si t'as besoin d'accéder à ton serveur mail en cas de problème, mais ta boîte, c'est pas un FAI.
Et bien évidemment, ils ne lisent pas tes mails sans ta permission. Pour autant que je sache, le DPI en France, ce n'est encore qu'un produit d'exportation :)
[^] # Re: Support des proxy HTTP ?
Posté par oinkoink_daotter . Évalué à 2.
Nan, mais faut arrêter avec les boîtes qui font de la défense ! La réglementation impose des contraintes qui font que ce genre de fuites n'est pas possible fortuitement.
Par contre, c'est le b a b a(?) de n'importe quelle politique SSI (normalement une politique SSI, ça devrait être assez courant) d'avoir une charte informatique . Ça doit être la première ou la deuxième exigence du manuel (ptet que j’exagère). Si la boite a un RSSI, il doit y avoir une charte.
[^] # Re: Support des proxy HTTP ?
Posté par dyno partouzeur de drouate . Évalué à 7.
On peut détecter ce genre de magouille:
En inspectant le certificat (en cliquant sur le cadenas dans la barre d'état de FireFox par exemple), je vais probablement voir que la chaîne de confiance même à un certificat racine qui n'est pas le bon.
Si je veux être vraiment parano, je peux comparer les fingerprints du certificat avec ceux que j'aurais noté via une connexion différente. Même si le certificat racine maison installé dans le browser est assez bien foutu pour ressembler à un organisme légitime, je doute qu'il soit possible d'obtenir la même signature SHA1 et MD5.
[^] # Re: Support des proxy HTTP ?
Posté par neerd . Évalué à 2.
Cela existe et rien de mieux que d'installer un navigateur qui n'utilise pas les certificats installés sur le système pour le détecter (il y a de forte chance que la CA de l'employeur soit installé sur l'OS pour éviter justement les alertes intempestives).
J'ai eu un moment de surprise en voyant que le certificat de google était signé par mon (ex-)employeur la première fois :)
[^] # Re: Support des proxy HTTP ?
Posté par Arnal . Évalué à 1.
En fait cela fonctionne de la manière suivante :
Il y a une liste blanche de site qui ne sont pas intercepté (banque, assurance etc ...)
Pour le reste (linuxfr.org et consœur) le boitier va faire du MitM afin de valider le contenu du site ou des liens 2.0 afin de coller à la politique de sécurité de l'entreprise (Websense fait cela par exemple).
[^] # Re: Support des proxy HTTP ?
Posté par oinkoink_daotter . Évalué à 1.
Les impots surtout : c'est le seul site que je connaisse qui fasse un check sur le certificat client ...
[^] # Re: Support des proxy HTTP ?
Posté par C. OB (site web personnel) . Évalué à 1.
Bien sur ! Le problème se pose lorsque justement on veux vraiment aller sur un site sécurisé. Ca peux être très bête, hein : Simplement aller sur une forge pour télécharger une archive d'un projet... Si celle-ci est en HTTPS, ben crac.
Grunt et d'autres plsu bas ont exposés des méthodes pour faire ça.
Je connais au moins OpenVPN qui fait ça en natif, corkscrew , ...
[^] # Re: Support des proxy HTTP ?
Posté par Volnai . Évalué à 2.
Pas forcement, ça peut-être fait "proprement" en générant à la volée un certificat par site depuis une autorité racine déployé et trusté préalablement sur les postes. Dans ce cas, pas d'alerte.
Par contre ça doit être spécifié dans une charte, et d'après ce que je sais c'est autorisé à condition de ne 'pas lire les logs'...Sauf en cas de litige
[^] # Re: Support des proxy HTTP ?
Posté par billux (site web personnel) . Évalué à 6.
Ça ne passe effectivement pas les proxies car ceux-ci vont bloquer les connexions directes avec les serveurs (c'est le rôle des proxies).
L'astuce est d'utiliser corkscrew dans ton ProxyCommand SSH, qui va en gros établir une connexion avec le proxy et lui dire je veux me connecter directement à tel serveur (avec la méthode HTTP CONNECT). À partir de là, le proxy ne s'occupe plus de l'échange (à moins qu'il bloque la méthode CONNECT, mais je n'ai jamais vu ça)
Je me permet un lien vers un article où j'en parlais en détail.
[^] # Re: Support des proxy HTTP ?
Posté par Juke (site web personnel) . Évalué à 9.
Le mercredi 30 novembre 2011 à 22:32 +0100, C. OB a écrit :
>
> J'ai commencé à voir ceci dans des grandes boites:
ça a l'air sympa de bosser chez eux.
[^] # Re: Support des proxy HTTP ?
Posté par C. OB (site web personnel) . Évalué à 4.
Comme l'ont montré plusieurs autres commentaire, cette pratique commence à bien se répandre dans les grandes sociétés (je l'ai même vu dans des plus petites, lorsque celles-ci externalisaient leurs service info à des SSII).
Quand ton taff c'est d'aller de boites en boites pour de la presta, tu sais pas dans quoi tu mets les pieds, non plus : A la présentation de la mission, le despotisme du service SI n'est pas un sujet abordé.
[^] # Re: Support des proxy HTTP ?
Posté par Juke (site web personnel) . Évalué à 7.
Le jeudi 01 décembre 2011 à 12:01 +0100, C. OB a écrit :
> Quand ton taff c'est d'aller de boites en boites pour de la presta
Et quand ils externalisent le ménage ils interdisent aussi aux prestas d'utiliser leurs propres balais ?
[^] # Re: Support des proxy HTTP ?
Posté par Antoine . Évalué à 3.
Et pourtant, pour une prestation informatique, c'est un facteur important...
[^] # Re: Support des proxy HTTP ?
Posté par Yves (site web personnel) . Évalué à 2.
Pour ma part, j’utilise sslh et j’en suis très content. Je ne l’utilise que pour HTTPS et SSH.
Pour être exact, j’ai une connexion SSH via ProxyTunnel vers le port SSH:443 d’une adresse IP autorisée, à travers laquelle je fais une connexion SSH vers une autre machine:443 disposant de sslh. :-/ Ça marche nickel.
Pour répondre à la remarque très pertinente au sujet des proxy HTTPS, je me dis que peut-être une solution est d’utiliser un outil de type http-tunnel pour encapsuler le tunnel SSH vers la machine ayant sslh… À tester…
tYY.
# Comprends pas tout
Posté par manatlan (site web personnel) . Évalué à 3.
C'est quoi la différence fondamentale entre ça ... et tunneler les ports qui vont bien dans un tunnel ssh:443, genre le port openvpn, le port xmpp, etc ...
On arrive au même résultat, non ?
[^] # Re: Comprends pas tout
Posté par Grunt . Évalué à 10.
On perd la possibilité d'héberger un site en HTTPS.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Comprends pas tout
Posté par manatlan (site web personnel) . Évalué à 2.
Ok,je comprends mieux ;-)
C'est pour les personnes qui ont un serveur dédié, avec plein de services dispo (dont un ssh, et un https).
Ces personnes peuvent alors accéder à ces services, sur le même port, à partir de leur boulot ...
Cependant, avec ssh, et stunnel, il devrait y avoir moyen de rendre son site https dispo, via tunnelling sous un autre port à travers stunnel ... (mais bon, j'ai jamais essayé)
[^] # Re: Comprends pas tout
Posté par Niniryoku . Évalué à 2.
Si j'ai bien compris, stunnel sert seulement à faire du chiffrement et/ou de l'authentification sur des protocoles qui le font pas. Je n'ai jamais entendu parlé de multiplexage (plusieurs services sur un même port).
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: Comprends pas tout
Posté par suJeSelS . Évalué à 2. Dernière modification le 01 décembre 2011 à 08:51.
Pas forcement, on peut s'en sortir avec des vhost + reverse proxy. Il faut pas mal triturer la configuration d'apache pour rediriger les bons flux qu'il faut là où il faut, mais ça se fait. Seule limitation, ça ne fonctionnera pas avec des serveurs http/https plus minimalistes.
[^] # Re: Comprends pas tout
Posté par Niniryoku . Évalué à 3.
En plus de comme dis plus haut, d'avoir un site HTTPS, tu arrives à imaginer tunneler openvpn à travers du ssh ?
Voilà les entêtes quand tu fait du HTTP à travers ton OpenVPN dans ton tunnel SSH (je commence à la couche 3 seulement) :
T'as 3 couches TCP et sur ces dernières t'as toutes les vérifications superflues qui vont avec ( « – est-ce que t'as bien reçu mon segment TCP ? – oui. – t'es sur ? – oui, oui, c'est bon. » ).
En utilisant sslh, tu peux faire du ssh, et du vpn (qu'avec deux couches TCP seulement, c'est déjà ça de pris) tout en servant des pages en HTTPS.
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: Comprends pas tout
Posté par billux (site web personnel) . Évalué à 1.
Petite précision, par défaut OpenVPN c'est de l'UDP, donc ça allège un peu, mais je suis quand même d'accord avec toi ce n'est pas du tout optimum.
[^] # Re: Comprends pas tout
Posté par Niniryoku . Évalué à 1.
L'UDP qui est bloqué sur les réseaux dont on parle. Ce qui nous oblige à passer OpenVPN en TCP :D . Et je ne crois pas que tu puisse tunneler de l'UDP avec les implémentations SSH existantes. (J'ai vu ça, mais le mec proxyfie l'UDP dans du TCP).
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: Comprends pas tout
Posté par Grunt . Évalué à 3.
Dans tous les cas, un VPN en TCP c'est sale (même si parfois on ne peut pas faire autrement). La solidité des connexions apportée par TCP est inutile si on tunnellise de l'UDP et redondante (voire génératrice d'instabilité ou de saturation) si on tunnellise du TCP.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Comprends pas tout
Posté par st3rk (site web personnel) . Évalué à 1.
Si c'est juste pour partager le port 443 entre un VPN et un serveur web, l'option "port-share" d'OpenVPN est une alternative intéressante.
# Ma technique avec apache
Posté par Damien Thébault . Évalué à 4.
J'ai moi-même été confronté à ce problème, serveur web https port 443 + ssh que je voulais faire passer par le même port pour pouvoir faire du ssh à travers le proxy qui ne permet de faire des CONNET que vers un port de destination 443.
J'utilise au final proxytunnel [1], un apache en proxy et un patch pour apache [2][3] qui permet de corriger le comportement de apache en proxy https (qui est à priori non définit par la rfc).
Du coup le principe est le suivant:
- ssh est utilisé pour avoir proxytunnel en tant que ProxyCommand [4]
- proxytunnel utilise CONNECT à travers le proxy HTTPS récalcitrant vers l'adresse du serveur apache
- au serveur apache en question reçoit une connection HTTPS contenant un CONNECT HTTP
qui redirige vers l'adresse IP choisie dans ssh (typiquement localhost:22, à bien vérifier lors
de la configuration du serveur car possible faille de sécu).
- la connexion en question est une session ssh classique, qui arrive ensuite sur localhost:22
du serveur
On a donc une connexion ssh dans un HTTP CONNECT dans une connexion SSL dans un HTTP CONNECT.
Ça ne permet pas de faire autant de choses, mais l'avantage de cette méthode est qu'elle ne nécessite pas de démon supplémentaire, seul un serveur apache suffit.
(et ensuite comme sur un ssh normal, proxy SOCKS over ssh avec socksify qui permet à n'importe quelle application de se passer dans un proxy SOCKS, git ne fonctionne pas, mais ça marche souvent et ça peut bien aider)
[1] http://proxytunnel.sourceforge.net/
[2] https://issues.apache.org/bugzilla/attachment.cgi?id=24615
[3] https://issues.apache.org/bugzilla/show_bug.cgi?id=29744
[4] ProxyCommand ~/.ssh/proxytunnel -q -X -p evil.proxy:8080 -r friendly.host:443 -d localhost:22
[^] # Re: Ma technique avec apache
Posté par Misc (site web personnel) . Évalué à 3.
Sinon, haproxy fait ça : https://dgl.cx/2010/01/haproxy-ssh-and-ssl-on-same-port
[^] # Re: Ma technique avec apache
Posté par chmduquesne . Évalué à 3.
C'est clairement une meilleure méthode. Une boîte munie d'un pare-feu correct va très facilement détecter les paquets ssh et les filtrer. Je le sais car j'en ai déjà fait les frais: ssh, ça se voit, même sur le port 443.
En faisant du ssh sur ssl, le flux passe pour une connection ssl anodine (ce qu'il est, d'ailleurs) et on risque beaucoup moins de se faire prendre. À priori, pour contrer cela, il faudrait être capable de reconnaître l'utilisation du CONNECT, mais comme ce CONNECT se fait seulement après établissement de la connection SSL, je doute que cela soit possible facilement.
Au vu des liens que tu donnes, j'imagine qu'il mérite d'être signalé qu'il existe au moins une méthode permettant de se passer de patcher apache: passer par stunnel. J'en ai fait un petit article (en anglais) 1.
[^] # Re: Ma technique avec apache
Posté par barmic . Évalué à 6.
Tu pourra toujours te faire gauler si tu as un boitier qui fait du Man in the middle sur https. Pour moi la technique qui me semble la plus imparable consiste non pas à chiffrer sa connexion mais à l'encoder. LinuxMag parlait d'une techno qui va dans ce sens il n'y a pas longtemps.
Le principe c'est de créer un tunnel HTTP dans le quel tu ne fait pas circuler du SSL/SSH, mais un flux encodé. L'avantage de ce flux encodé c'est qu'il garde une entropie proche d'un texte normal (et potentiellement, mais je ne me souviens plus très bien, il peut être moins gourmand). A partir de là tu peux faire ce que tu veux et faire passer soit un tunnel SSH et te servir de ton client ssh comme d'un proxy SOCKS soit placer un VPN.
L'idée de cet encodage c'est qu'il n'est pas possible avec les moyens actuels de le déchiffrer suffisamment rapidement pour le faire en temps réelle (ce qui est je trouve plus proche des besoins que l'on a dans ce genre de cas).
La seule méthode que je vois pour arrêter cela c'est de filtrer sur une liste blanche d'adresses IP.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ma technique avec apache
Posté par ymorin . Évalué à 5.
C'était dans LinuxMag #135 (que j'ai acheté exprès pour cet article !), de Février 2011, dans un article intitulé "Perseus: protéger des communications avec du bruit".
Donc, la librairie Perseus permet, en gros, de coder la communication, tout en maintenant une entropie proche de celle d'un texte en clair. De cette façon, l'échange passe "sous le radar", et n'est pas détecté.
Attention, ce n'est pas du chiffrement, et le code utilisé n'est pas très costaud ; il est donc sujet à des attaques relativement aisées.
Hop,
Moi.
[^] # Re: Ma technique avec apache
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
En gros, il s'agit de faire de la stéganographie. On peut toujours faire un système qui prends des vrai page html qui existe en rajoutant du bruit dedans qui sont de l'information supplémentaire qui peut elle-même être compressé/crypté.
"La première sécurité est la liberté"
[^] # Re: Ma technique avec apache
Posté par delio . Évalué à 1.
stunnel c'est bien si tu n'as pas pas besoin d'avoir un serveur web sur la même ip. Mais si tu veux un tunnel ssl sur le port 443 et un serveur apache sur la même ip, il n'y a pas trop le choix.
[^] # Re: Ma technique avec apache
Posté par GouNiNi . Évalué à 4.
Entièrement d'accord, je me suis fait gaulé dans une grosse boite avec SSLH chez moi tout simplement parce que ça se voit !
Si SSLH est capable de différencier HTTPS et SSH, le proxy de ta boite sait le faire aussi, c'est aussi bête que ça.
Firewall, IDS ou autre, il faut pas grand chose pour identifier ce genre de connexion.
# L'outil idéal en compagnon de dns2tcp
Posté par nethenic (site web personnel) . Évalué à 3.
Donc, si j'ai bien compris, plutôt que de tunneliser un service à la fois avec ssh via dns2tcp (contournement des portails captifs via un faux serveur dns), avec sslh, je vais pouvoir faire passer plusieurs protocoles. Chouette !
# Si ça continue...
Posté par Maclag . Évalué à 10.
On va voir apparaître un protocole appelé "TCP/IP-over-HTTP".
Mais c'est pas grave, on y remettra un pare-feu...
-------------> [ ]
[^] # Re: Si ça continue...
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
Les responsables, se sont les DSI qui obligent à fermer tous les ports. La seule solution pour continuer à bosser est de tout faire passer sur 80 et 443. Du coup, on complexifie tout, on rend tout verbeux, on aura des firewall plus gourmand...
On refait sur le http la daube d'IBM et de Microsoft avec NetBIOS/SMB ou tout est mélangé...
Si les DSI (et les FAI) laissaient les ports s'ouvrir "facilement", le principe simple et logique un port un service pourrait continuer à s'appliquer.
[^] # Re: Si ça continue...
Posté par Maclag . Évalué à 10.
Je ne critique pas ce projet, je critique justement les politiques d'entreprises qui incitent à créer ce genre de projet, politiques qui de plus ne servent pas à grand chose pour ceux qui ont des smartphone 3G: on passe le smartphone en hotspot pour accéder aux sites interdits.
Comme ça le DSI perd encore un peu plus le contrôle de son parc...
[^] # Re: Si ça continue...
Posté par Volnai . Évalué à 1.
C'est à la fois pas faux et dangereux : à force de contourner ce qui est interdit, la sécurité est de plus en plus contraignante.
Pendant ce temps, les grands gagnant sont les vendeurs d'IPS, antivirus, firewalls,...
[^] # Re: Si ça continue...
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
C'est juste un non sens. Pourquoi partir du principe que les utilisateurs des ports autre que 80 et 443, le font pour un usage illicite ?
Pourquoi ne pas lever simplement une alerte de demander ce que fais la personne à posteriori ? En quoi est gênant de ce connecter à ssh à son serveur perso, faire du ftp, du sip ?
"La première sécurité est la liberté"
[^] # Re: Si ça continue...
Posté par inico (site web personnel) . Évalué à 8.
Personnellement, je considère HTTP comme étant un protocole de niveau 4 du Modèle_OSI de fait.
Félicitation à tous les administrateurs de fw qui ont rendu cela possible et surtout nécessaire, vous rendu un fier service à l'ossification de l'Internet !
[^] # Re: Si ça continue...
Posté par yodaz . Évalué à 3. Dernière modification le 02 décembre 2011 à 06:45.
Ca existe déjà, mais le nom est légèrement différent
# pour les idiots ?
Posté par tildebis . Évalué à -2.
"sslh est un outil pour les idiots..."
Qui a dit qu'il utilisait cet outil au fait ? ;)
# Testé dans quels environnements?
Posté par Katyucha (site web personnel) . Évalué à 2.
Est ce que quelqu'un a testé avec des firewalls orienté applicatifs, tel que les produits de Palo Alto ? Ces firewalls ont la particularité d'orienté le filtrage sur le contenu d'un flux et non plus seulement sur du simple port.
Il faut voir aussi avec les fonctionnalités "proxy ssl" de certains équipements, vu que c'est l'équipement qui déchiffre d'un coté et rechiffre de l'autre coté... Bref, je suis assez sceptique tant que j'ai pas tout vérifié ^^
[^] # Re: Testé dans quels environnements?
Posté par Volnai . Évalué à 1.
Palo Alto, comme d'autres IPS, detecte le ssh, surement en regardant bétement la bannière. D'une mannière générale, je ne pense pas que sslh change quoique ce soit pour les censeurs, ils savent déjà detecter du ssh sur autre chose que le port 22.
Pour openvpn et jabber, c'est également detecté facilement, et intégré dans les PaloAlto. Par contre pas de trace de Tinc, mais c'est forcement faisable avec une signature custom
[^] # Re: Testé dans quels environnements?
Posté par barmic . Évalué à 3.
Quand tu en arrive là pourquoi ne pas simplement utiliser un tunnel HTTP ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Testé dans quels environnements?
Posté par Volnai . Évalué à 1.
C'est clair qu'il y aura toujours une faille, c'est une course sans fin et les seuls gagnants sont les vendeurs, ca fait travailler l'écononomie... Mais pour le tunnel http, les soft habituels permettant ça sont aussi detectés depuis longtemps.
[^] # Re: Testé dans quels environnements?
Posté par barmic . Évalué à -1.
C'est dommage de devoir se répéter inlassablement sur la même page : https://linuxfr.org/news/sslh%C2%A0110-la-b%C3%AAte-noire-des-censeurs#comment-1295818
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Testé dans quels environnements?
Posté par Volnai . Évalué à 1.
Excuse moi de de ne pas apprendre par coeur tout tes commentaires lumineux. Et puis tu en te répète pas vraiment, dans le commentaire que tu pointes le tunnel est 'encodé', là tu parlais juste de tunnel http. Bref, plutôt que de parler dans le vide, as-tu un exemple d’implémentation de ce dont tu parles ?
# Fonction similaire dans openVPN
Posté par nerbrume . Évalué à 5.
Pour info, openVPN fait déjà quelquechose de similaire (ecoute sur 443, et redirection des requetes HTTPS). C'est --port-share.
Je l'avais utilisé un moment, en tcp, et ca avait l'air de marcher. Mais jamais tésté en milieu "hostile", avec proxy, etc...
Et puis j'avais laisser tomber, en me disant que si mon OpenVPN se cassait la gueule pour une quelconque raison, mes utilisateurs n'auraient plus accès à leur webmail en HTTPS, et ca craignait un peu.
Du coup, sslh, ca me plait bien.
# Filtrage du port 443
Posté par theocrite (site web personnel) . Évalué à 7.
En fait si, et c'est même déjà très courant. Et c'est même très facile à faire.
Dans les grosses boites, le port 443 est bloqué par défaut et ouvert au cas par cas grâce à une whitelist.
Des sites https que ta boite juge utile d'utiliser (c'est à dire qui ne soit pas quelque chose de privé, commue ta banque ou ton webmail) et qui ne soit pas aussi accessible en http par ailleurs (comme linuxfr et les sites de google), il n'y en a pas des masses.
Du coup, ce serait bien plus simple si on pouvait utiliser sslh sur le port 80. C'est possible simplement ?
[^] # Re: Filtrage du port 443
Posté par Brieuc Roblin (site web personnel) . Évalué à -2.
Le soucis du port 80, c'est que c'est facile de savoir si oui ou non le paquet est de l'HTTP ou du SSH.
Avec le port 443 tu as soit du SSL, soit du SSH, dans les deux cas c'est chiffrer, donc c'est un peu plus compliqué de repérer si c'est vraiment du SSL qui transite ou non. Pour contré ca, sois tu arrives à les différencier (si possible?) ou alors tu utilises un MitM, tu dechiffres au niveau du proxy et chiffre à nouveau pour le client (les données sont plus chiffrées au niveau du proxy, et donc lisible, et le certificats est pas celui du site mais celui du proxy).
Bref, sur le 80, si c'est un protocole que tu comprends pas tu bloques...
# Ouai enfin bon....
Posté par nomorsad . Évalué à 10.
Pensez quand même à vérifier que votre boite vous autorise à sortir sur le port 443 pour autre chose que du HTTPS.
Si je dis ça, c'est que je me suis fait griller (et que j'ai passé un sale quart d'heure!) ^_^
Mais c'est sûr que ça doit être assez facile pour un firewall un peu évolué, de détecter "qui parle en premier" !
Maintenant je pense que je vais basculer sur AjaxTerm sur HTTPS car j'ai juste besoin d'un accès SSH pour faire la maintenance de mon hébergement perso. Je pense que je n'ai pas le droit non plus dans ma boite, mais je pense pas que ça puisse être détecté!
Bon, ils ont peut-être blaklister mon IP... On peut demander une nouvelle IP chez Free?? :-p
[^] # Re: Ouai enfin bon....
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Sinon tu peux changer de boite... Parce que les proxys nazis, les filtres, les listes blanches, noires, grises, ça pourrit vraiment la vie de l'ingénieur au quotidien.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ouai enfin bon....
Posté par Katyucha (site web personnel) . Évalué à 2.
N'empeche, t'es pas censé bosser sur tes petits projets persos quand tu es au travail...
[^] # Re: Ouai enfin bon....
Posté par Juke (site web personnel) . Évalué à 3.
Le jeudi 01 décembre 2011 à 13:21 +0100, Katyucha a écrit :
> N'empeche, t'es pas censé bosser sur tes petits projets persos quand
> tu es au
> travail...
>
>
ha bon ? pourquoi ?
au lieu de ça tu passe ton temps à chercher des solutions pour detourner la politique de « securité »
et dans dans le pire des cas tu va perdre encode plus de temps car tu le fera via ton smartphone.
[^] # Re: Ouai enfin bon....
Posté par BFG . Évalué à 9.
Ce n'est pas forcément pour travailler sur ses projets personnels, mais par exemple si l'on n'a pas certains outils sur le lieu de travail alors qu'on les a déjà ailleurs (chez soi par exemple), et qu'on en a plus besoin plus vite que s'il fallait les installer sur le lieu de travail et ponctuellement.
Si tous les ports non-HTTP sont bloqués, comment ira-t-on trouver de l'aide sur (par exemple) IRC ou Jabber ?
[^] # Re: Ouai enfin bon....
Posté par Adrien . Évalué à 5.
J'ajouterais aussi la VoIP, ou le téléchargement en bittorrent d'un DVD Debian…
Mais bon, quand on est con, on est con, et on ferme tout sans distinction aucune.
[^] # Re: Ouai enfin bon....
Posté par Volnai . Évalué à 1.
Pendant que toi, honnête utilisateur, tu utilises bittorent pour un DVD débian, ton voisin en profite pour télécharger le dernier blockbuster. Et comme le DSI est responsable de ce téléchargement illégal, il est pas si con et il demande de tout fermer.
[^] # Re: Ouai enfin bon....
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Le RSI peut aussi demander ce que tu as téléchargé c'est facile de mettre l'iso debian sous son nez.
"La première sécurité est la liberté"
[^] # Re: Ouai enfin bon....
Posté par Volnai . Évalué à 2.
Oui, mais ça n’empêche pas que le DSI est responsable si quelqu'un télécharge quelque chose d'illégal. Je parle de responsabilité civile et pénale. Tu ferais quoi toi ? Serais-tu prêt à laisser tout le monde faire ce qu'il veut sur ton accès internet en sachant que tu peux avoir de gros problèmes si des petits malins l'utilise à des fin illégales ?
Un petit lien intéressant qui traite du sujet : http://www.olfeo.com/pdf/filtrage.pdf
[^] # Re: Ouai enfin bon....
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
J'ai un peu de mal à comprendre comment un RSI peut être responsable du comportement d'un employé mais bon.
Ton 'petit' lien est un peu trop gros pour trouver rapidement l'info.
"La première sécurité est la liberté"
[^] # Re: Ouai enfin bon....
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
En plus, la première fois, tu expliques à la personne qu'avec l'ADSL chez elle, elle ne doit pas faire n'importe quoi au boulot.
La seconde fois, tu menaces d'aller voir le directeur...
Jamais eu besoin d'aller au delà de ça !
[^] # Re: Ouai enfin bon....
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
J'ai du mal à suivre, ce que tu veux dire par là.
"La première sécurité est la liberté"
[^] # Re: Ouai enfin bon....
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Je veux dire dire que lorsqu'une personne télécharge un film au boulot ou fait du P2P, il suffit d'aller discuter avec lui une fois pour que l'expérience ne se renouvelle plus. En cas de récidive (très faible), une légère menace suffit...
Il faut dire que nous sommes directement au giga sur le net (Renater) et peut être bientôt au 10Go... Donc au boulot, cela va bien plus vite que chez soit !
[^] # Re: Ouai enfin bon....
Posté par Juke (site web personnel) . Évalué à 1.
heu...
En quoi un lien vers un prestataire de tf1 justifie tes propos ?
[^] # Re: Ouai enfin bon....
Posté par barmic . Évalué à 6.
Toutes les entreprises où j'ai travaillées qui avaient un proxy filtrant se débrouillaient pour bloquer des sites nécessaire à mon travail. C'est à partir du moment où cela m'empêche trop régulièrement de travailler que je contourne leur sécurité et que je suis près à accueillir l'admin système ou le DSI comme il se doit avec une liste d'arguments longue comme le bras pour lui expliquer pourquoi sa configuration de proxy gêne mon travail et pourquoi faire des demandes pour ajouter chaque site dont j'ai besoin me fais perdre un temps infini.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ouai enfin bon....
Posté par Joël Thieffry (site web personnel) . Évalué à 7. Dernière modification le 01 décembre 2011 à 19:39.
Des fois même, le DSI ne veut absolument pas honorer les demander d'ouverture de port, même officielle. Conjugué avec le proxy filtrant, on se retrouvait dans des situations ubuesques :
- les sites Wikipedia inaccessibles car classés dans la catégorie "diffamation" ;
- le site de Sam Hocevar (http://sam.zoy.org/) inaccessible car classé en "obscène" à cause de libcaca (bye bye cvs2svn) ;
- le port CVS bloqué (cool je rentre chez moi juste pour télécharger un repository crucial à mon projet).
Tout ça dans une grosse SSII(CAC40). Certes, elle traite avec la Défense, mais justement ces secteurs sont isolés sur leur propre réseau. Heureusement le proxy filtrant a disparu au bout de 3 mois car il plantait tous les jours, bloqué sur une page "erreur anti-virus". Ça ressemble à un troll, mais c'est du vécu.
Edit : le markup pour les liens ne marche pas très bien.
[^] # Re: Ouai enfin bon....
Posté par Juke (site web personnel) . Évalué à 7.
Le jeudi 01 décembre 2011 à 19:38 +0100, Joël Thieffry a écrit :
> repository crucial à mon projet
C'est pas grave, le projet avance pas c'est tout.
Quand plus rien n'avancera ils vireront peu être les incompétents qui
déploient ça.
[^] # Re: Ouai enfin bon....
Posté par khivapia . Évalué à 5.
toi tu ne connais pas les boîtes françaises...
http://www.raby-f.fr/fable2.htm
[^] # Re: Ouai enfin bon....
Posté par ndv . Évalué à 1.
SSII au cac 40 ? Il n'y en a qu'une...
[^] # Re: Ouai enfin bon....
Posté par barmic . Évalué à 3.
C'est pas si simple. Le groupe Francetélécom possède une SSII (Orange Buziness Service si je ne me trompe pas) et jusqu'en 2006 Thales y était aussi. De plus Cap Gé possède Sogeti.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Re: Technologie—sslh 1.10, labêtenoire des censeurs
Posté par Juke (site web personnel) . Évalué à 8.
Entre les boites qui bloquent le ssh et les boites qui bloquent le mail https://linuxfr.org/users/paladar/journaux/31908 ça va commencer à valoir le coup de monter un annuaire des endroits où il fait bon travailler.
[^] # Re: Technologie—sslh 1.10, labêtenoire des censeurs
Posté par Larry Cow . Évalué à 0.
Le souci, c'est que ça fait aussi un annuaire des endroits que ça vaut le coup de venir "visiter".
Parce qu'autant un admin qui verrouille tous les ports est rarement un bon admin, autant un admin qui les laisse ouverts n'en est pas nécessairement (et de loin) un bon.
# Une simple règle IPTables.
Posté par classic . Évalué à 2.
Personnellement j'utilise iptable depuis longtemps. C'est simple et efficace, parce que je m'en sers toujours depuis la même IP. Pour quelqu'un qui ne se connecterait pas toujours du même endroit sslh a l'air plutôt bien pensé.
# redirection selective de https vers ssh:
iptables -t nat -I PREROUTING -i eth0 -p tcp --dport 443 -s IP_DU_DECIDEUR_PRESSE -j REDIRECT --to-ports 22
[^] # Re: Une simple règle IPTables.
Posté par neerd . Évalué à 2.
Le problème c'est que si tu souhaites accéder à ton site hébergé en HTTPS c'est pas possible.
[^] # Re: Une simple règle IPTables.
Posté par classic . Évalué à 2.
C'est pas vraiment un problème, parce que tout mon trafic perso passe justement par le tunnel SSH pour ne pas passer par le proxy du décideur pressé. Donc l'IP est différente, donc c'est possible.
# OpenDPI
Posté par Mimoza . Évalué à 5.
J'utilise SSLH depuis plus d'un an et j'ai quelques griefs à son encontre.
1) A chaque redémarrage de la machine j'ai 1 chance sur deux pour qu'il démarre correctement. Et même en modifiant sont ordre de lancement dans init.d je ne suis pas arrivé a quelque chose de satisfaisant. Au final j'ai du me rabattre sur un cron @reboot pour m'assurer qu'il se lance bien. (NB : le fait que ce soit sur un guruplug, donc ARM, est peut être en cause ...)
2) Les serveurs SSH et HTTP "voient" uniquement des connexions provenant de 127.0.0.1. Du coup Fail2Ban devient inefficace.
3) SSLH ne ssuporte pas autre chose que SSL & SSH => Problème résolu avec cette nouvelle version.
Pour palier à tous ces problèmes je me suis penché sur une solution plus "générique", le DPI avec OpenDPI qui permet de faire des règle IPTable au niveau service.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: OpenDPI
Posté par classic . Évalué à 0.
http://linuxfr.org/nodes/88458/comments/1295861
J'ai fait un commentaire identique deux heures avant le tien. Le tien est noté "+3" et le mien "-3". C'est scandaleux. Je demande un recomptage des votes.
[^] # Re: OpenDPI
Posté par Mimoza . Évalué à 1.
ton poste est revenu à 0 ;-)
Ta solution est intéressante pour celui qui se connecte toujours du même endroit, le DPI permet d'outre passer cette limitation.
[^] # Re: OpenDPI
Posté par nomorsad . Évalué à 1.
SSLH fonctionne parfaitement depuis plus d'un an sur ma Debian Squeeze sur Sheevaplug.
Donc comme on dit chez nous : "Chez moi ça marche (tm)"
[^] # Re: OpenDPI
Posté par Mimoza . Évalué à 1.
Donc ca doit venir de chez moi :-s
Mais comme mon objectif est de me passer de cet outil je n'aurais plus le problème ^^
[^] # Re: OpenDPI
Posté par nerbrume . Évalué à -1.
En revanche, le coup de Fail2Ban inutilisable, c'est un peu dommage. Pas moyen de tagger les paquets avec l'IP, en amont, genre avec IPTables ? (je suis nul en IPTables)
Puis utiliser ce tag dans Fail2Ban ? (ca en revanche, ca devrait pas être trop compliqué).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
# sshttp
Posté par M . Évalué à 4.
sshttp (http://c-skills.blogspot.com/2011/08/new-sshttp-available.html)ne fait il pas la même chose ?
Qu'elles sont les différences entre les 2 ?
[^] # Re: sshttp
Posté par izulium . Évalué à 1.
L'un semble encapsuler ("[...] sshttp is now able to hide SSH inside HTTPS as well. [...]") et l'autre fait cohabiter plusieurs protocoles sur un même port ("[...] SSL/SSH multiplexer [...]").
# OpenVPN comme proxy SSL
Posté par Giljåm . Évalué à 1.
Perso, j'utilise OpenVPN avec l'option "port-share". Donc OpenVPN écoute sur le port 443 et si ce n'est pas une connexion TLS valide il drop la connexion à mon serveur web qui écoute sur le port 4443 par exemple et agit comme un proxy SSL.
Donc au final, je n'ai besoin que d'un seul port, il y a plein de clients pour openVPN (notamment sur les téléphones), j'ai un vrai vpn et le firewall ne voit que du SSL qui aboutit sur mon blog.
Donc je vois pas trop l'intérêt de sslh...
# SSLH ça se voit
Posté par GouNiNi . Évalué à 7.
Ce n'est pas vrai ! Il y a déjà plusieurs commentaires sur ce sujet.
Principe de base ; si SSLH sait faire la différence entre HTTPS et SSH, le proxy de votre boite sait le faire aussi (si les ingés sont un minimum compétents).
De plus, SSH a des "comportement" reconnaissables, vous ne serez donc pas "caché" comme j'ai pu le croire à une époque avant de me prendre un savon ;).
SSLH est bien utile si vous utilisez un hotspot wifi (hôtel, gare...) qui n'ouvre que le 80 et 443. Vous n'allez pas perdre votre job si les proxy de l’hôtel remontent une alerte. Dans le cadre de votre boulot, le risque est à calculer sérieusement.
[^] # Re: SSLHçase voit
Posté par Juke (site web personnel) . Évalué à 5.
Le vendredi 02 décembre 2011 à 11:52 +0100, GouNiNi a écrit :
> comme j'ai pu le croire à une époque avant de me prendre un savon ;)
Le monsieur il est venu te voir pour te dire qu'il n'arrivait pas à espionner ce que tu faisais ?
[^] # Re: SSLH ça se voit
Posté par GouNiNi . Évalué à 3.
Il est venu me voir pour me dire que j'avais signer un truc qui s'appelle une charte et que je ne la respectais pas.
[^] # Re: SSLH ça se voit
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
C'était quel point que tu ne respectais pas et dont il était furieux ?
"La première sécurité est la liberté"
[^] # Re: SSLH ça se voit
Posté par barmic . Évalué à 2.
Un truc du genre "ne pas contourner les politiques de sécurité de l'entreprise".
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: SSLH ça se voit
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
J'ai vu une fois un truc débile. En gros, on ne pouvait pas monter de serveur ftp pour les clients pour transférer des gros fichiers, car cela n'était pas prévu, le firewall bloquait. C'était tellement long à mettre en place, que les fichiers sont partis par mail (dont le quota de taille était plus gros) depuis le domicile d'un employé !
Souvent les politiques de sécurité sont contournés, parce qu'il faut bien travailler !
"La première sécurité est la liberté"
[^] # Re: SSLH ça se voit
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
En quoi avoir un serveur ssh et un site en HTTPS sont un contournement de la politique de sécurité???
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: SSLH ça se voit
Posté par barmic . Évalué à 4.
Tout le monde s'en fout de ce que tu fait de ton serveur c'est la manière d'y accéder qui est dangereuse, ici contourner leur proxy.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: SSLH ça se voit
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Je ne vois pas où est le danger.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: SSLH ça se voit
Posté par barmic . Évalué à 2.
Tu peut aller sur des sites de vilains hackers.
Je ne dis pas que je suis d'accord avec ce fonctionnement, je dis ce qu'il en est par rapport aux chartes informatiques classiques (tout ce qui n'est pas autorisé est interdit, tu ne peut en faire usage que pour ton travail, « by-passer » les moyens techniques mis en place pour t'y contraindre est interdit, etc).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: SSLH ça se voit
Posté par devnewton 🍺 (site web personnel) . Évalué à 8.
Tu peut aller sur des sites de vilains hackers.
Seulement si je fais un tunnel pour aller sur ces sites. SSH et HTTPS servent à bien d'autres choses. Encore une fois, on confonds un moyen technique avec un usage très particulier.
Enfin interdire certains sites ou protocoles, ce n'est pas une politique de sécurité.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: SSLH ça se voit
Posté par barmic . Évalué à 2.
Je n'ai jamais dis le contraire. C'est du même niveau que d'affirmer que le téléchargement c'est illégale. Néanmoins un grand nombre de charte le fond.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: SSLH ça se voit
Posté par Volnai . Évalué à 1.
Ou pire, un reverse tunnel : tu pourrais te connecter au réseau de la boite depuis une machine qui ne respecte pas forcement les prérequis de sécurité (antivirus, etc). Et ça, le RSSI n'aime pas, vu qu'il est responsable en cas de problème, comme son nom l'indique.
[^] # Re: SSLHçase voit
Posté par Juke (site web personnel) . Évalué à 2.
Le lundi 05 décembre 2011 à 09:14 +0100, Barret Michel a écrit :
> les moyens techniques mis en place pour t'y contraindre
Si c'est interdit pourquoi prendre des mesures techniques pour l'empecher ? il suffit de licencier les personnes enfreignant cette chartre.
[^] # Re: SSLHçase voit
Posté par barmic . Évalué à 4.
A moins de considérer que c'est une faute grave (ce qui pourrait être remis en cause aux prud'homme), ça leur serait couteux. Il y a d'autres moyens de répressions comme la retenu de salaire, mais là je ne connais pas du tout le cadre légal de cette sanction.
Contrairement à ce que certains pensent et heureusement, le code du travail est régis pas mal de règles pour empêcher ce genre d'abus (et il reste relativement protecteur pour le salarié).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: SSLHçase voit
Posté par Juke (site web personnel) . Évalué à 2.
j'ai dis licencié mais effectivement ça pourrait etre n'importe quelle sanction.
Ce que je veux dire c'est que ce n'est pas parce qu'il est interdit de revendre la base client de la boite, insulter ses collegues, ou envoyer du contenu pedonazi que je suis prêt à accepter que tout mes echanges soient espionnés.
[^] # Re: SSLHçase voit
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
la retenu de salaire,
Il n'y a aucune base légal pour faire ça.
"La première sécurité est la liberté"
[^] # Re: SSLHçase voit
Posté par barmic . Évalué à 1.
T'es sûr ? J'étais persuadé qu'il était possible de pour une entreprise de définir certaines règles de retenues de salaire. J'en avais notamment entendu parler pour des retards.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: SSLHçase voit
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
"Ainsi, les retenues sur salaire pour absence injustifiée ou retard sont licites dès lors que la retenue est strictement proportionnelle à l’absence."
Cela semble être le seul cas d'après le 1er lien trouvé sur google :
http://fo.rro.chez-alice.fr/vos_droits/les_sanctions_pecuniaires_sont_interdites.pdf
"La première sécurité est la liberté"
[^] # Re: SSLH ça se voit
Posté par zebra3 . Évalué à 2.
Donc si on passe par le proxy en utilisant HTTPS+AjaxTerm, c'est bon ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: SSLH ça se voit
Posté par errabes (site web personnel) . Évalué à 3.
La bannière de connexion SSH passe en clair, il suffit de faire du DPI (ou un tcpdump) pour le voir. Ça doit être prévu dans la plupart des appliances que les boites achètent.
Il faut utiliser une couche de plus (proxytunnel, stunnel ou autre).
# cinq gus dans un garage
Posté par mikemowgli . Évalué à -1.
jolie référence... :)
# SSH dans SSL
Posté par whiterabbit . Évalué à 4. Dernière modification le 15 décembre 2011 à 11:40.
On peut cacher le traffic SSH d'un proxy qui vérifierait les bannières en utilisant proxytunnel d'un coté, et stunnel + sslh de l'autre: on peut alors toujours servir HTTPS et SSH sur le même port. Cette manoeuvre est décrite dans le README de sslh.
D'autre part, par rapport aux premiers commentaires, IPv6 est maintenant supporté directement depuis la version 1.9
Pour les problèmes de démarrage, n'hésitez pas à faire des rapports de bugs aux mainteneurs de vos distributions, c'est pas normal!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.