Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?

[Radu-Adrian Feurdean]

On Tue, Apr 12, 2016, at 12:52, Edouard Chamillard wrote:
> chose, mais si j'essaye de dire aux clients "oui mais non, ça c'est dans
> du ssl, donc même si c'est un c zeus sur un site compromis on peut pas
> le savoir et/ou pas y toucher", ça va mal passer.

Bonjour mr Le Client. Soit je touche pas au traffic SSL (TLS) meme s'il
s'agit d'un "c zeus sur un site compromis", soit je vois tous vos mots
de passe et toutes les e-mails que vous envoyes via gmail/yahoo/hotmail.
A vous le choix.

presente comme ca, ca devra calmer du monde. Pas tous, certes.

> le matos de la boite c'est le matos de la boite, et en dehors de
> quelques communications protégées (contactez votre juriste le plus
> proche pour une réponse faisant autorité) personne ne peut s'attendre a
> la confidentialité des échanges avec des serveurs distants.

C'est quasiment un argument pour laisser son mobile pro (et son ordi
portable) au bureau et ne le sortir du bureau sans deplacement justifie
par un ordre de deplacement papier, signe par la hierarchie. A la maison
= 100% off-line (cote boulot).
Je ne suis pas sur que c'est le but recherche...


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?

[Solarus Lumenor]

 

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 ?

[Edouard Chamillard]

Le 13/04/2016 12:53, Solarus Lumenor a écrit :
>  
>
> 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 
>
le sujet c'etait les proxy transparents. CONNECT était hors course au
premier mail.



signature.asc
Description: OpenPGP digital signature

Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?

[Solarus Lumenor]

 

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 ?

[Edouard Chamillard]

Le 13/04/2016 09:25, Solarus Lumenor a écrit :
>  
>
> 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.

on interdit une connexion sur le port 443 tout en autorisant une
connexion sur le port 80 quelque part sur le trajet entre le client et
le reste des tuyaux du monde ? effectivement c'est passionant...
> 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
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.
>  
>
> 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.
donc. dans une session https. tu peux injecter un 403. ok. ou alors
encore mieux. le client se connecte en http sur ton proxy (et le reste
du réseau qui est manifestement ~de confiance~ voit le contenu en clair)
et le proxy fait le handshake.

non parce que y'a littéralement aucun moyen de faire ce que tu viens de
dire faire sans etre en MITM, et vu que tu es en MITM...

aucun commentaire sur l'argument bloquer/lire le flux. c'est une pure
question de PSSI qui doit etre prise par des gens mieux payés que moi.
>  
>
> 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/




signature.asc
Description: OpenPGP digital signature

Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?

[Solarus Lumenor]

 

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 ?

[Michel Py]

> Artur a écrit :
> Ce qui semblait une "bonne" idée au départ est au final une erreur. En 
> occurrence la solution était uniquement censée rendre les
> choses plus faciles pour le "grand public", mais comme on est pas chez les 
> bisounours il va falloir procéder différemment.

L'idée en elle-même n'est nouvelle; on a eu a moins un cas de fournisseur 
d'Internet dans les avions qui a fait çà, dans le but (soi-disant) d'économiser 
la bande passante.
http://www.neowin.net/news/gogo-inflight-internet-is-intentionally-issuing-fake-ssl-certificates


> Jonathan Leroy a écrit :
> J'abonde avec cette petite infographie, qui explique quand intercepter ou pas 
> le trafic HTTPS :
> https://twitter.com/__apf__/status/719577428058890240

Justement, c'est Adrienne Porter Felt qui a initialement soulevé le problème.


> 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. que les ISPs
> aient pas a toucher aux paquets qu'on les paye a transbahuter c'est une 
> chose, mais si j'essaye de dire aux clients "oui mais non,
> ça c'est dans du ssl, donc même si c'est un c zeus sur un site compromis on 
> peut pas le savoir et/ou pas y toucher", ça va mal passer.

+1

> le matos de la boite c'est le matos de la boite, et en dehors de quelques 
> communications protégées (contactez votre juriste le plus
> proche pour une réponse faisant autorité) personne ne peut s'attendre a la 
> confidentialité des échanges avec des serveurs distants.

Ici c'est vrai.

> apres vu le prix du DPI au pps, j'ai tendance a encourager a ne l'utiliser 
> qu'en dernier ressort et/ou sur des périmètres
> sensibles. dans l'immense majorité des cas, les métadonnées sont largement 
> suffisante pour prendre une décision.

Pour combien de temps ? les fabricants de merdiciels ne s'endorment pas, le 
vecteur d'attaque est de plus en plus camouflé; en étant l'avocat du diable, 
les solutions entreprise qui font du MITM de SSL sont inévitables à moyen 
terme. Il va falloir s'attendre à voir des installations automatisées de CA 
dans le but précis de rendre le MITM moins visible.

Michel.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?

[Edouard Chamillard]

Le 12/04/2016 17:51, Solarus Lumenor a écrit :
>  
>
> 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/
les gens sérieux bloquent complètement l'https ? donc au lieu de
compromettre la confidentialité de la connexion au cas ou, les gens
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 ?



signature.asc
Description: OpenPGP digital signature

Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?

[Solarus Lumenor]

 

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/

[FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?

[Kavé Salamatian]

> Le 12 avr. 2016 à 13:52, Stephane Bortzmeyer  a écrit :
> 
> On Tue, Apr 12, 2016 at 12:50:57PM +0200,
> Kavé Salamatian  wrote 
> a message of 95 lines which said:
> 
>> C’est pas ce qu’avait fait en 2013 la direction du trésor avec le
>> certificat fake émis l’IGC/A (voir
>> https://www.mail-archive.com/frnog@frnog.org/msg26501.html
> 
> Avant de répondre, il faut bien lire les messages. Artur demandait
> « il n'est pas question d'avoir des messages d'avertissement dans le
> navigateur ou autres configurations manuelles (installation des clés
> ssl, etc) » et ma réponse commençait par « Avec ces critères ».

C’était le cas dans l’événement de 2013. Ce n’était pas les personnels du 
trésor qui c’était aperçu du MITM et du certificat fake, mais Google qui avait 
trouvé le certificat dans la nature. 

Donc j’avais bien lu et ma réponse était pertinente. Ai je mon absolution 
monseigneur inquisiteur :-).

A+

Kv
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?

[Stephane Bortzmeyer]

On Tue, Apr 12, 2016 at 12:50:57PM +0200,
 Kavé Salamatian  wrote 
 a message of 95 lines which said:

> C’est pas ce qu’avait fait en 2013 la direction du trésor avec le
> certificat fake émis l’IGC/A (voir
> https://www.mail-archive.com/frnog@frnog.org/msg26501.html

Avant de répondre, il faut bien lire les messages. Artur demandait
« il n'est pas question d'avoir des messages d'avertissement dans le
navigateur ou autres configurations manuelles (installation des clés
ssl, etc) » et ma réponse commençait par « Avec ces critères ».


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?

[James Pic]

As-tu essayé mitmproxy ?

Je pense que de telles solutions ont leur utilité si on ne met pas
d'utilisateur humain derrière, et qu'on s'en sert par exemple pour
router une infra de test éphémère.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?

[Kavé Salamatian]

J’ai déjà donné les arguments et les infos juridiques en 2013 (voir 
https://www.mail-archive.com/frnog%40frnog.org/msg26510.html 
)

A+

Kv
> Le 12 avr. 2016 à 12:52, Edouard Chamillard  a 
> écrit :
> 
> 
> Le 12/04/2016 12:38, Jonathan Leroy a écrit :
>> Le 12 avril 2016 à 12:17, Stephane Bortzmeyer  a écrit :
>>> Avec ces critères, si une telle solution existait, ce serait une
>>> énorme faille de sécurité dans TLS, et il faudrait la publier dans une
>>> conf' fameuse (avec nom qui déchire et logo, bien sûr, comme toutes
>>> les failles de sécurité).
>> J'abonde avec cette petite infographie, qui explique quand intercepter
>> ou pas le trafic HTTPS :
>> https://twitter.com/__apf__/status/719577428058890240
>> 
> "on doit jamais MITM une session ssl (web ou non)" c'est un beau
> principe mais ça va être dur a vendre aux entreprises. que les ISPs
> aient pas a toucher aux paquets qu'on les paye a transbahuter c'est une
> chose, mais si j'essaye de dire aux clients "oui mais non, ça c'est dans
> du ssl, donc même si c'est un c zeus sur un site compromis on peut pas
> le savoir et/ou pas y toucher", ça va mal passer.
> 
> le matos de la boite c'est le matos de la boite, et en dehors de
> quelques communications protégées (contactez votre juriste le plus
> proche pour une réponse faisant autorité) personne ne peut s'attendre a
> la confidentialité des échanges avec des serveurs distants.
> 
> apres vu le prix du DPI au pps, j'ai tendance a encourager a ne
> l'utiliser qu'en dernier ressort et/ou sur des périmètres sensibles.
> dans l'immense majorité des cas, les métadonnées sont largement
> suffisante pour prendre une décision.
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?

[Edouard Chamillard]

Le 12/04/2016 12:38, Jonathan Leroy a écrit :
> Le 12 avril 2016 à 12:17, Stephane Bortzmeyer  a écrit :
>> Avec ces critères, si une telle solution existait, ce serait une
>> énorme faille de sécurité dans TLS, et il faudrait la publier dans une
>> conf' fameuse (avec nom qui déchire et logo, bien sûr, comme toutes
>> les failles de sécurité).
> J'abonde avec cette petite infographie, qui explique quand intercepter
> ou pas le trafic HTTPS :
> https://twitter.com/__apf__/status/719577428058890240
>
"on doit jamais MITM une session ssl (web ou non)" c'est un beau
principe mais ça va être dur a vendre aux entreprises. que les ISPs
aient pas a toucher aux paquets qu'on les paye a transbahuter c'est une
chose, mais si j'essaye de dire aux clients "oui mais non, ça c'est dans
du ssl, donc même si c'est un c zeus sur un site compromis on peut pas
le savoir et/ou pas y toucher", ça va mal passer.

le matos de la boite c'est le matos de la boite, et en dehors de
quelques communications protégées (contactez votre juriste le plus
proche pour une réponse faisant autorité) personne ne peut s'attendre a
la confidentialité des échanges avec des serveurs distants.

apres vu le prix du DPI au pps, j'ai tendance a encourager a ne
l'utiliser qu'en dernier ressort et/ou sur des périmètres sensibles.
dans l'immense majorité des cas, les métadonnées sont largement
suffisante pour prendre une décision.



signature.asc
Description: OpenPGP digital signature

Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?

[Kavé Salamatian]

C’est pas ce qu’avait fait en 2013 la direction du trésor avec le certificat 
fake émis l’IGC/A (voir 
https://www.mail-archive.com/frnog@frnog.org/msg26501.html 
)? . Je me rappelle 
que certains sur la liste avait justifié cette pratique en disant que des 
produits comme les Palo Alto et les A10 network avec le SSL intercept faisait 
ça.Je me rappelle que ca avait donné lieu a une discussion animée :-) (voir 
https://www.mail-archive.com/frnog%40frnog.org/msg26510.html 
).

Kv




> Le 12 avr. 2016 à 12:38, Jonathan Leroy  a 
> écrit :
> 
> Le 12 avril 2016 à 12:17, Stephane Bortzmeyer  a écrit :
>> Avec ces critères, si une telle solution existait, ce serait une
>> énorme faille de sécurité dans TLS, et il faudrait la publier dans une
>> conf' fameuse (avec nom qui déchire et logo, bien sûr, comme toutes
>> les failles de sécurité).
> 
> J'abonde avec cette petite infographie, qui explique quand intercepter
> ou pas le trafic HTTPS :
> https://twitter.com/__apf__/status/719577428058890240
> 
> -- 
> Jonathan Leroy.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?

[Jonathan Leroy]

Le 12 avril 2016 à 12:17, Stephane Bortzmeyer  a écrit :
> Avec ces critères, si une telle solution existait, ce serait une
> énorme faille de sécurité dans TLS, et il faudrait la publier dans une
> conf' fameuse (avec nom qui déchire et logo, bien sûr, comme toutes
> les failles de sécurité).

J'abonde avec cette petite infographie, qui explique quand intercepter
ou pas le trafic HTTPS :
https://twitter.com/__apf__/status/719577428058890240

-- 
Jonathan Leroy.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?

[Artur]

Le 12/04/2016 12:17, Stephane Bortzmeyer a écrit :
> [« Clé SSL » ? Je suppose que vous vouliez parler de certificats
> X.509 ? Ou, à la rigueur, de certificats pour TLS ?] 
Tout-à-fait.
> Avec ces critères, si une telle solution existait, ce serait une
> énorme faille de sécurité dans TLS 
En effet, en me focalisant sur le côté "utile" j'ai complétement zappé
l'aspect sécurité de MITM. :/

Du coup, WPAD DNS poserait un peu la même problématique et il serait
étonnant qu'on permette l'utilisation d'un proxy à l'issue de son plein
gré... Non ?

-- 
Cordialement,
Artur.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?

[Stephane Bortzmeyer]

On Tue, Apr 12, 2016 at 12:10:45PM +0200,
 Artur  wrote 
 a message of 34 lines which said:

> Donc, il n'est pas question d'avoir des messages d'avertissement
> dans le navigateur ou autres configurations manuelles (installation
> des clés ssl, etc).

[« Clé SSL » ? Je suppose que vous vouliez parler de certificats
X.509 ? Ou, à la rigueur, de certificats pour TLS ?]

> A votre connaissance, une telle solution existe-t-elle aujourd'hui ?

Avec ces critères, si une telle solution existait, ce serait une
énorme faille de sécurité dans TLS, et il faudrait la publier dans une
conf' fameuse (avec nom qui déchire et logo, bien sûr, comme toutes
les failles de sécurité).


---
Liste de diffusion du FRnOG
http://www.frnog.org/