Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?
Le 2016-04-13 12:01, Edouard Chamillard a écrit : > le sujet c'etait les proxy transparents. CONNECT était hors course au > premier mail. Une discussion ça dérive tu sais ? On parlait sécurité des réseaux business en général. Et puis la transparence c'est très subjectif. Parler de transparence en voulant insérer des signatures X.509 forgées, c'est un contre-sens, c'est plutôt l'opacité totale pour l'utilisateur. Bref, CONNECT ça fonctionne. Solarus --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?
Le 2016-04-13 10:56, Edouard Chamillard a écrit : > donc la plupart des boites serieuses ont un proxy en MITM, capable de > lire un en tete SNI ou un champ Server: (et pas un FQDN, a part si ton > proxy fait aussi la résolution dns (ce que certains font)). > effectivement ça méritait de parler de deux types d'équipement. Pourquoi faire si compliqué ? La RFC 2817 (qui date de 2000) prévoit que seul le CONNECT doit passer en HTTP/1.1. Là le proxy peut accepter ou refuser la connexion en fonction du domaine demandé dans le CONNECT. En cas d'acceptation le client peut demander un upgrade (passage en HTTPS) et établir un tunnel TLS directement avec le serveur distant, tunnel qui n'est pas intercepté et qui permet de conserver authentification X.509 légitime. https://tools.ietf.org/rfc/rfc2817 5. Upgrade across Proxies As a hop-by-hop header, Upgrade is negotiated between each pair of HTTP counterparties. If a User Agent sends a request with an Upgrade header to a proxy, it is requesting a change to the protocol between itself and the proxy, not an end-to-end change. Since TLS, in particular, requires end-to-end connectivity to provide authentication and prevent man-in-the-middle attacks, this memo specifies the CONNECT method to establish a tunnel across proxies. Once a tunnel is established, any of the operations in Section 3 can be used to establish a TLS connection. 5.2 Requesting a Tunnel with CONNECT A CONNECT method requests that a proxy establish a tunnel connection on its behalf. The Request-URI portion of the Request-Line is always an 'authority' as defined by URI Generic Syntax [2], which is to say the host name and port number destination of the requested connection separated by a colon: CONNECT server.example.com:80 HTTP/1.1 Host: server.example.com:80 Other HTTP mechanisms can be used normally with the CONNECT method -- except end-to-end protocol Upgrade requests, of course, since the tunnel must be established first. For example, proxy authentication might be used to establish the authority to create a tunnel: CONNECT server.example.com:80 HTTP/1.1 Host: server.example.com:80 Proxy-Authorization: basic aGVsbG86d29ybGQ= Like any other pipelined HTTP/1.1 request, data to be tunneled may be sent immediately after the blank line. The usual caveats also apply: data may be discarded if the eventual response is negative, and the connection may be reset with no response if more than one TCP segment is outstanding. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?
Le 2016-04-12 17:07, Edouard Chamillard a écrit : > sérieux compromettent carrément la session complète sur tout internet au > lieu de la compromettre en interne sur un seul équipement, et pire, > rendent impossible la connexion aux sites qui utilisent HSTS ? ce genre > de gens sérieux ? on est déja trolldi ? Va falloir m'expliquer comment compromettre une «session complète sur tout internet» avec simplement un proxy d'entreprise, parce que ça à l'air intéressant comme faille. Oui, la plupart des boites sérieuses ont un proxy avec un filtrage sur les FQDN. -Demande de connexion HTTPS au site d'une banque : OK -Demande de connexion HTTPS à Facebook : KO Si tu a le droit d'accéder au site, tu y accède, si le site n'a pas d'intérêt professionnel ou présente un danger (webmail, fishing etc) ben tu reçois un joli code HTTP 403 t'interdisant d'y accéder. C'est aussi simple que ça et ça permet de protéger le réseau d'entreprise sans mettre en œuvre de solutions qui ELLES seraient dangereuses pour la confiance que peuvent avoir les utilisateurs envers le modèle X.509/TLS au niveau global. Au delà de l'aspect technique, je considère à titre personnel et éthique que toute volonté d'interception (contrairement au blocage) n'a pour but que d'espionner les salariés et les utilisateurs de manière disproportionnée. Et j'attends encore la preuve du contraire. Solarus --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?
Le 2016-04-12 11:52, Edouard Chamillard a écrit : > "on doit jamais MITM une session ssl (web ou non)" c'est un beau > principe mais ça va être dur a vendre aux entreprises. Le HTTPS il ne faut pas l'intercepter mais on peut le bloquer à l'aide d'un proxy ou d'un firewall, c'est ce que font déjà les gens sérieux. Mais comme tout le monde est déjà équipé des ces deux équipements c'est moins intéressant pour le chiffre d'affaire des vendeurs de solutions de sécurité. Solarus --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Relais SMTP
Le 2016-03-11 10:42, Lacroix, Baptiste a écrit : > Je veux faire du propre, je fais du gris et je nettoie le gris foncé et > putain c'est laborieux, entre les demandes au produit pour faire évoluer et > les clients à qui il faut faire comprendre qu'on les à laissé prendre de > mauvaises habitudes... > > Baptiste > http://www.frnog.org/ [1] C'est pas idiot de rappeller que le client au travers du contenu est en grande partie responsable de la réputation de tes serveurs. On aura beau mettre du SPF, du DKIM et surveiller les RBL, si ton client prospecte des emails récupérés n'importe comment ou qu'il n'offre pas d'opt-out le plus basique, c'est même pas la peine d'aller plus loin. Sans parler des newsletters composées uniquement d'images distantes, avec Spamassassin c'est un classement en spam quasi direct. Yes, score=5,019 HTML_IMAGE_ONLY_24=1.282 HTML_MESSAGE=0.001 HTML_MIME_NO_HTML_TAG=0.635 MIME_HEADER_CTYPE_ONLY=1.996 MIME_HTML_ONLY=1.105 Solarus Links: -- [1] http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] detection VPN SSL
Le 2016-03-08 09:44, Jocelyn Lagarenne a écrit : > Bonjour à tous, > > je me retrouve face à un dilemme. On me demande de proposer une solution > pour détecter/bloquer les VPN SSL non autorisés mais autant que je sache le > traffic au travers d'un proxy est identique à un traffic https. il est donc > impossible de le detecter non ? ou est ce que je fais fausse route ? > Il est techniquement envisageable de casser le https sur les proxys mais ce > n'est pas une recommandation que j'aime. > la seul solution que je vois est de détecter les connexions SSL "longue" et > de vérifier ce qu'elles sont (eliminer les faux positives comme par exemple > gtalk), mais je ne suis meme pas sure que des logs proxy puissent me donner > cette information. > > Auriez vous des idées/suggestions ? avez vous déjà eu ce genre de cas dans > vos entreprises ? > > d'avance merci de vos retours > > Cordialement, Les VPN ont un port par défaut qui diffère du port HTTPS, mais effectivement ils utilisent souvent le TCP/443 pour traverser les proxys ou pour éviter les QOS non-neutres.Effectivement, il est inconcevable de casser du HTTPS ou de faire du man in the middle, pour autant il y a des solutions. La première c'est la gestion de parc en interdisant les logiciels de VPN, mais cela implique d'avoir la main sur tout le parc et sur tous les équipements qui se connectent. La seconde c'est de travailles avec un système de blacklist. Elle consiste à relever les IP jointes en SSL sur le port 443 et à faire 2 vérifications simples. D'abord un simple reverse de l'IP donne généralement de bonnes infos sur l'usage de cette IP. Ensuite avec un telnet sur le port 443 de l'IP en question, on peut voir si c'est un serveur HTTP au bout ou autre chose. La difficulté reste de faire ça à grande échelle ou d'automatiser ça mais ça me semble la bonne solution. Solarus --- Liste de diffusion du FRnOG http://www.frnog.org/
