Re: [FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet Bruno Tréguier 
Bonsoir,

Le 08/12/2013 à 21:06, Raphaël Stehli a écrit :
> Il faudrait également savoir comment les responsables de l'AC
> intermédiaire ont pu signer un certificat de pour google ou gmail.

Techniquement parlant, une AC intermédiaire peut signer ce qu'elle veut,
tout comme une AC racine... Après, du point de vue des procédures, il y
a un hic, c'est sûr.

Cordialement,

Bruno

-- 
- Service Hydrographique et Oceanographique de la Marine  -  DMGS/INF
-  13, rue du Chatellier -  CS 92803  - 29228 Brest Cedex 2, FRANCE
- Phone: +33 2 98 22 17 49  -  Email: bruno.tregu...@shom.fr


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

Re: [FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet Raphaël Stehli 
Le 08/12/2013 23:19, Kavé Salamatian a écrit :
>> - les salariés ou agents doivent être au courant de l'interception SSL via 
>> la charte informatique et la déclaration CNIL donc en utilisant le système 
>> informatique de l'entreprise / administration, ils étaient au courant et ils 
>> ont fait le choix de se connecter à leur banque avec le système,
> pas suffisant. L’interception ne peut se faire qu’à avec objectif 
> d’amélioration du service. L’information de justifie pas l’action illégale de 
> l’entreprise ou de l’administration. Il y’a de la jurisprudence la dessus. 

Je veux bien la jurisprudence.
>
>> - les banques sérieuses utilisent un autre système complémentaire (SMS, code 
>> à usage unique, etc.)
> Le fait que la banque n’est pas sérieuse ou le système est mal protégé ne 
> réduit pas la responsabilité juridique de l’attaquant. 
Effectivement, mais un système avec une vérification par un autre canal
limite la casse pour la boite, pas pour l'attaquant.
>
>> Le problème ici est que ce problème, lié a du gmail a fait bondir Google : 
>> son modèle économique est uniquement basé sur la confiance des utilisateurs.
>> Le modèle des ACR est basé sur la confiance des acteurs du secteurs.
>> La réaction de Google était donc prévisible.
>>
>> Pour la restriction à *.gouv.fr, ce n'est pas forcément possible : il existe 
>> des administrations qui n'utilisent pas le .gouv.fr : je pense aux 
>> assemblées, aux juridictions et aux autres agences administratives 
>> indépendantes.
>>
>> Je ne sais pas si quelqu'un peut maintenant prévoir la suite des évènements, 
>> mais il faut espérer que les modifications de protocoles de l'ANSSI 
>> arriveront à convaincre Google, Microsoft et Mozilla de ne pas bloquer les 
>> certificats racine de l'IGC/A.
> On que non. J’espère que l’épisode permettra de montrer qu’on ne peut pas 
> faire n’importe quoi par qu’il est techniquement possible de le faire. Ce 
> genre d’épisode met complètement à terre l’édifice de la sécurité 
> informatique par certificat.
Oui : et également la confiance en l'économie numérique. On sait tous
que ça tient sur un château de carte. Je ne suis pas convaincu qu'il
faille tout faire planter.

>
>> Il faudrait également savoir comment les responsables de l'AC intermédiaire 
>> ont pu signer un certificat de pour google ou gmail.
> C’est une partie du n’importe quoi dont je parle. J’ose pas espérer, mais une 
> petite plainte contre X des personnels de l'administration ou de son syndicat 
> ferait avancer les choses pour réduire la surveillance et le sentiment de 
> liberté totale des administrations et des entreprises sur les informations 
> privées des personnes.
Je ne suis pas convaincu que ce soit une infraction pénale.
>
> Kavé Salamatian
>>
>> Cordialement,
>> Raphaël
>>
>>
>> Le 08/12/2013 20:33, Jean-Yves Faye a écrit :
>>> Bonsoir,
>>>
>>> NetASQ a cette fonctionnalité, et de plus est un produit bien Français. 
>>> Purement techniquement parlant, cette technique peut être pratique pour 
>>> garder l'aspect SSL des communications, tout en soumettant à l'analyse 
>>> antivirus/IDS les flux entrants, chose courante avec les appliances type 
>>> NetASQ justement. 
>>>
>>> Comme déjà dit, le danger vient plutôt de le faire avec une AC certifiée et 
>>> publique (par transitivité). Normalement on fait ça avec une AC interne et 
>>> les certificats spécifiques sont déployés sur les postes.
>>>
>>> Après cela remet encore une fois sur le tapis la question de la liste à 
>>> rallonge des autorités "de confiance" qui peuvent donner des certificats 
>>> pour n'importe quoi, qui ne veut plus dire grand chose. Dans ce cas précis, 
>>> une fonctionnalité de type restriction à *.gouv.fr sur l'IGC de 
>>> l'administration aurait été pertinente.
>>>
>>> Un nettoyage des magasins de certificats des navigateurs est la seule 
>>> solution à court terme, ça ou alors les éditeurs de navigateurs se mettent 
>>> à implémenter les protocoles déjà proposés pour réduire la voilure niveau 
>>> portes d'entrée dans le système des IGC (moins problable)
>>>
>>> Cordialement,
>>>
>>> Jean-Yves Faye
>>>
>>>
>>> Le 8 décembre 2013 20:08, Fabien Delmotte  a écrit :
>>> Bonsoir,
>>>
>>> Pareil pour A10 networks et le SSL intercept .. Cela me parait plus un 
>>> problème de configuration qu’autre chose.
>>>
>>> Je ne connais pas les lois pour la France (il doit y en avoir beaucoup sur 
>>> le sujet avec le comment faire et son contraire), mais cela fonctionne sans 
>>> problème Technique dans les autres pays.
>>> J’ai personnellement installé plusieurs configuration en dehors de la 
>>> France sans problèmes techniques.
>>>
>>> Cordialement
>>>
>>> Fabien
>>>
>>> Le 8 déc. 2013 à 19:48, Surya ARBY  a écrit :
>>>
 C'est pourtant le principe de fonctionnement des firewalls palo alto qui 
 font du MITM SSL avec des certificats signés par la PKI interne.

 Le 08/12/2013 19:26, Kavé Salamatian a écrit :
> 2-l’employeur n’a pas a inspecter le trafic SSL qu

[FRnOG] Re: [ALERT] IGC/A et google

2013-12-08 Par sujet Raphaël Stehli 
Aucun rapport en l'espèce : c'était pour l'hypothèse de la
responsabilité de l'entreprise qui avait un certif intermédiaire en cas
de piratage suite à la lecture d'un flux SSL. C'était pour conclure
qu'elle serait très limitée voir écartée, quelques soit les hypothèses
envisagées. Mais effectivement, rien de directement lié.

 08/12/2013 23:16, Stephane Bortzmeyer a écrit :
> On Sun, Dec 08, 2013 at 09:06:02PM +0100,
>  Raphaël Stehli  wrote 
>  a message of 442 lines which said:
>
>> - les banques sérieuses utilise du forward secrecy, qui devrait limiter
>> les problèmes de l'interception SSL,
> Je ne vois pas en quoi. On parle d'un Homme du Milieu ici. Le PFS ne
> gène pas l'Homme du Milieu, uniquement l'espion qui a stocké un flux
> chiffré antérieur.
>
>> - les entreprises ne laisse pas trainer leurs clés privées n'importent
>> où (ou elles se retourneront à leur tour contre le responsable
>> informatique),
> Mais, là encore, quel rapport ? Si un Homme du Milieu peut demander à
> une AC de générer un certificat pour bigbank.example (ou pour *),
> quelle importance que bigbank fasse attention à ses clés privées ou
> pas ?
>
>> - les banques sérieuses utilisent un autre système complémentaire (SMS,
>> code à usage unique, etc.)
> Cela protège contre certaines opérations (comme un virement), pas
> contre l'espionnage (il ne me semble pas normal qu'un employeur
> puisse voir l'état du compte en banque d'un employé).
>
>> Donc, même en cas de vol de la clé, 
> Mais il n'y a eu aucun vol de clé dans cette affaire.
>




smime.p7s
Description: Signature cryptographique S/MIME

[FRnOG] Re: [ALERT] IGC/A et google

2013-12-08 Par sujet Stephane Bortzmeyer 
On Sun, Dec 08, 2013 at 09:06:02PM +0100,
 Raphaël Stehli  wrote 
 a message of 442 lines which said:

> - les banques sérieuses utilise du forward secrecy, qui devrait limiter
> les problèmes de l'interception SSL,

Je ne vois pas en quoi. On parle d'un Homme du Milieu ici. Le PFS ne
gène pas l'Homme du Milieu, uniquement l'espion qui a stocké un flux
chiffré antérieur.

> - les entreprises ne laisse pas trainer leurs clés privées n'importent
> où (ou elles se retourneront à leur tour contre le responsable
> informatique),

Mais, là encore, quel rapport ? Si un Homme du Milieu peut demander à
une AC de générer un certificat pour bigbank.example (ou pour *),
quelle importance que bigbank fasse attention à ses clés privées ou
pas ?

> - les banques sérieuses utilisent un autre système complémentaire (SMS,
> code à usage unique, etc.)

Cela protège contre certaines opérations (comme un virement), pas
contre l'espionnage (il ne me semble pas normal qu'un employeur
puisse voir l'état du compte en banque d'un employé).

> Donc, même en cas de vol de la clé, 

Mais il n'y a eu aucun vol de clé dans cette affaire.


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

[FRnOG] Re: [ALERT] IGC/A et google

2013-12-08 Par sujet Stephane Bortzmeyer 
On Sun, Dec 08, 2013 at 08:33:53PM +0100,
 Jean-Yves Faye  wrote 
 a message of 81 lines which said:

> Après cela remet encore une fois sur le tapis la question de la
> liste à rallonge des autorités "de confiance" qui peuvent donner des
> certificats pour n'importe quoi, qui ne veut plus dire grand chose.

J'ai oublié de mentionner qu'une solution technique existe, DANE,
présentée dans ce dossier thématique de l'AFNIC :

http://www.afnic.fr/fr/l-afnic-en-bref/actualites/actualites-generales/7450/show/securiser-les-communications-sur-internet-de-bout-en-bout-avec-le-protocole-dane-2.html


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

Re: [FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet Kavé Salamatian 

Le 8 déc. 2013 à 21:06, Raphaël Stehli  a écrit :

> Juridiquement parlant, rien n'empêche à un employeur (public ou privé) :
> - de déchiffrer le contenu des flux chiffrés pour les analyser de manière 
> automatique,

Oui a condition que rien en dehors de l’adresse IP SRC/DST en mode anonymisé ne 
soit enregistré.
> - de déchiffrer le contenu des flux chiffrés pour interception manuelle, à la 
> demande d'une autorité administration ou juridictionnelle, voir même à des 
> fins internes, sous réserve de ne pas consulter les informations ayant un 
> caractère personnel sans que le salarié ait été appelé. Le juge prudhommal 
> vérifiera.

Les fins internes autorisés ne sont que l’amélioration du service. Mes faibles 
connaissances juridique m’amène a penser qu’on ne peut justifier après coup la 
légalité d’un acte de procédure. Ca s’appelle un vice de procédure et aboutit à 
l’annulation de la pièce.

> 
> Il existerait un risque théorique de réutiliser le résultats de 
> l'interception pour pirater une banque. Néanmoins, le risque est faible :

pas autant que ça.
> - les banques sérieuses utilise du forward secrecy, qui devrait limiter les 
> problèmes de l'interception SSL,
> - les entreprises ne laisse pas trainer leurs clés privées n'importent où (ou 
> elles se retourneront à leur tour contre le responsable informatique),

et elles sont sures de ne pas se faire pirater :-). Aller dire ça à adobe, Sony 
et d’autres :-).
> - les salariés ou agents doivent être au courant de l'interception SSL via la 
> charte informatique et la déclaration CNIL donc en utilisant le système 
> informatique de l'entreprise / administration, ils étaient au courant et ils 
> ont fait le choix de se connecter à leur banque avec le système,

pas suffisant. L’interception ne peut se faire qu’à avec objectif 
d’amélioration du service. L’information de justifie pas l’action illégale de 
l’entreprise ou de l’administration. Il y’a de la jurisprudence la dessus. 

> - les banques sérieuses utilisent un autre système complémentaire (SMS, code 
> à usage unique, etc.)

Le fait que la banque n’est pas sérieuse ou le système est mal protégé ne 
réduit pas la responsabilité juridique de l’attaquant. 
> 
> Donc, même en cas de vol de la clé, l'entreprise devrait voir sa 
> responsabilité fortement minorée.

Ca dépend de la qualité des avocats de la partie adverse.

> 
> Le problème ici est que ce problème, lié a du gmail a fait bondir Google : 
> son modèle économique est uniquement basé sur la confiance des utilisateurs.
> Le modèle des ACR est basé sur la confiance des acteurs du secteurs.
> La réaction de Google était donc prévisible.
> 
> Pour la restriction à *.gouv.fr, ce n'est pas forcément possible : il existe 
> des administrations qui n'utilisent pas le .gouv.fr : je pense aux 
> assemblées, aux juridictions et aux autres agences administratives 
> indépendantes.
> 
> Je ne sais pas si quelqu'un peut maintenant prévoir la suite des évènements, 
> mais il faut espérer que les modifications de protocoles de l'ANSSI 
> arriveront à convaincre Google, Microsoft et Mozilla de ne pas bloquer les 
> certificats racine de l'IGC/A.

On que non. J’espère que l’épisode permettra de montrer qu’on ne peut pas faire 
n’importe quoi par qu’il est techniquement possible de le faire. Ce genre 
d’épisode met complètement à terre l’édifice de la sécurité informatique par 
certificat.

> 
> Il faudrait également savoir comment les responsables de l'AC intermédiaire 
> ont pu signer un certificat de pour google ou gmail.

C’est une partie du n’importe quoi dont je parle. J’ose pas espérer, mais une 
petite plainte contre X des personnels de l'administration ou de son syndicat 
ferait avancer les choses pour réduire la surveillance et le sentiment de 
liberté totale des administrations et des entreprises sur les informations 
privées des personnes.

Kavé Salamatian
> 
> 
> Cordialement,
> Raphaël
> 
> 
> Le 08/12/2013 20:33, Jean-Yves Faye a écrit :
>> Bonsoir,
>> 
>> NetASQ a cette fonctionnalité, et de plus est un produit bien Français. 
>> Purement techniquement parlant, cette technique peut être pratique pour 
>> garder l'aspect SSL des communications, tout en soumettant à l'analyse 
>> antivirus/IDS les flux entrants, chose courante avec les appliances type 
>> NetASQ justement. 
>> 
>> Comme déjà dit, le danger vient plutôt de le faire avec une AC certifiée et 
>> publique (par transitivité). Normalement on fait ça avec une AC interne et 
>> les certificats spécifiques sont déployés sur les postes.
>> 
>> Après cela remet encore une fois sur le tapis la question de la liste à 
>> rallonge des autorités "de confiance" qui peuvent donner des certificats 
>> pour n'importe quoi, qui ne veut plus dire grand chose. Dans ce cas précis, 
>> une fonctionnalité de type restriction à *.gouv.fr sur l'IGC de 
>> l'administration aurait été pertinente.
>> 
>> Un nettoyage des magasins de certificats des navigateurs est la seule 
>> solution à court terme,

[FRnOG] Re: [ALERT] IGC/A et google

2013-12-08 Par sujet Stephane Bortzmeyer 
On Sun, Dec 08, 2013 at 08:33:53PM +0100,
 Jean-Yves Faye  wrote 
 a message of 81 lines which said:

> Dans ce cas précis, une fonctionnalité de type restriction à
> *.gouv.fr sur l'IGC de l'administration aurait été pertinente.

La fonction "Name Constraints" de X.509 (RFC 5280, section 4.2.1.10)
semble très peu mise en œuvre et on ne peut donc pas compter dessus.


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

[FRnOG] Re: [ALERT] IGC/A et google

2013-12-08 Par sujet Stephane Bortzmeyer 
On Sun, Dec 08, 2013 at 08:08:00PM +0100,
 Fabien Delmotte  wrote 
 a message of 36 lines which said:

> J’ai personnellement installé plusieurs configuration en dehors de
> la France sans problèmes techniques.

Personne n'a dit que cela ne marchait pas. C'est la moralité de ce
détournement qui était en cause.



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

Re: [FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet Florent Nolot 

Bonjour

Ci-dessous les infos que j'avais trouvées il y a quelques mois sur ce 
sujet mais cela a pu évoluer. Je ne suis pas à jour et pas juriste


Décret du 25 Février 2011
Obligation Conservation des données d'identification pour les opérateurs 
WIFI

Opérateurs WIFI (Article 32 CPCE)
Personne physique ou morale et exploitant un réseau de communications 
électroniques et mettant ce réseau à disposition du public

Conservation pendant 1 an minimum
Demander un identifiant ne signifie pas « ne plus être public »

Les entreprises et administrations sont exclues des obligations légales 
des opérateurs publiques, d'après la CNIL.
Mais il est conseillé de mettre en place un dispositif de surveillance 
et de prévenir les utilisateurs (loi 23 Janvier 2006 lutte contre le 
terrorisme, activité pédophile, piratages, ...)


Conservation des données techniques : IP ou MAC, terminaux utilisés, 
dates heures durées des communications, services complémentaires 
utilisés ou demandés, information donnant la possibilité d'identifier 
des destinataires, origine et localisation

des communications

Cordialement

Florent NOLOT
Université de Reims Champagne-Ardenne

Le 08/12/2013 23:01, MM a écrit :

Bonjour,


Je suis la discussion avec intérêt depuis un moment.
Effectivement, la pratique de MITM est connue et simple à réaliser, ce qui est 
inédit est qu’une autorité de certification génère un certificat … et se fasse 
choper surtout.

Par contre, auriez-vous des précisions sur cette histoire de hotspot invité ?
Quels sont les textes - depuis quand datent-t-ils ?

J’ai vu des solutions d’hôtel, ils ne loguent rien du traffic (rien de brut, de 
mémoire il y a les connexions par contre).
De même en entreprise, je n’ai jamais rien vu de logué sur les connexion 
invités (elles étaient simplement isolées du réseau classique / restreint à 
certaines utilisations).
Je doute que le McDo logue grand chose, tout comme le réseau invité sur les 
freebox (peut être que dans ce cas la connexion n’est pas considérée comme 
anonyme car requérant un identifiant lié à une connexion)
Déjà l’année de log a fait plaisir à tout le mode, j’imagine ce que peut donner 
cette loi …

Merci par avance pour les éclaircissements.
Mathieu



Le 8 déc. 2013 à 22:30, Yann Vercucque  a écrit :


Je rajouterai également qu'un employeur est tenu (Juridiquement parlant, loi 
anti-terroriste) de loguer l'intégralité des flux web lorsqu'il dispose d'un 
hotspot invité. De ce faite, il est nécessaire de faire de l'interception SSL, 
afin loguer les flux HTTPS.

Comme cela a déjà été dit, le problème n'est pas l'interception SSL. Mais 
l'interception SSL par un certificat signé par une autorité connu.

Au passage les équipements comme Fortigate, permettent de choisir de ne pas 
intercepter les banques, les sites médicaux et les réseaux sociaux.

Yann,






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




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

Re: [FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet Kavé Salamatian 

Le 8 déc. 2013 à 22:53, Alexandre Archambault  a 
écrit :

> 
> Le 8 déc. 2013 à 22:30, Yann Vercucque  a écrit :
> 
>> Je rajouterai également qu'un employeur est tenu (Juridiquement parlant, loi 
>> anti-terroriste) de loguer l'intégralité des flux web lorsqu'il dispose d'un 
>> hotspot invité
> 
> Non. Tenus de conserver les données de connexion (en gros à quel était 
> l’utilisateur correspondant à telle IP), oui, quel que soit d’ailleurs le 
> statut de celui qui met à disposition l’accès. Mais en aucun cas l’usage qui 
> est fait de cette connexion n’a à être loggé.
> 
> Je précise juste que, contrairement à ce qu’on peut lire ici ou là que le log 
> des données de navigation (ou "l’intégralité des flux web" comme vous dites) 
> est à ce stade prohibé (cf. art. L.34-1 CPCE VI 2nd alinéa), en tout cas pour 
> un réseau ouvert au public.

+1
> 
> —
> Alec,
> 
> 
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet MM 
Bonjour,


Je suis la discussion avec intérêt depuis un moment.
Effectivement, la pratique de MITM est connue et simple à réaliser, ce qui est 
inédit est qu’une autorité de certification génère un certificat … et se fasse 
choper surtout.

Par contre, auriez-vous des précisions sur cette histoire de hotspot invité ?
Quels sont les textes - depuis quand datent-t-ils ?

J’ai vu des solutions d’hôtel, ils ne loguent rien du traffic (rien de brut, de 
mémoire il y a les connexions par contre).
De même en entreprise, je n’ai jamais rien vu de logué sur les connexion 
invités (elles étaient simplement isolées du réseau classique / restreint à 
certaines utilisations).
Je doute que le McDo logue grand chose, tout comme le réseau invité sur les 
freebox (peut être que dans ce cas la connexion n’est pas considérée comme 
anonyme car requérant un identifiant lié à une connexion) 
Déjà l’année de log a fait plaisir à tout le mode, j’imagine ce que peut donner 
cette loi …

Merci par avance pour les éclaircissements.
Mathieu



Le 8 déc. 2013 à 22:30, Yann Vercucque  a écrit :

> Je rajouterai également qu'un employeur est tenu (Juridiquement parlant, loi 
> anti-terroriste) de loguer l'intégralité des flux web lorsqu'il dispose d'un 
> hotspot invité. De ce faite, il est nécessaire de faire de l'interception 
> SSL, afin loguer les flux HTTPS.
> 
> Comme cela a déjà été dit, le problème n'est pas l'interception SSL. Mais 
> l'interception SSL par un certificat signé par une autorité connu.
> 
> Au passage les équipements comme Fortigate, permettent de choisir de ne pas 
> intercepter les banques, les sites médicaux et les réseaux sociaux.
> 
> Yann,






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

Re: [FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet Alexandre Archambault 

Le 8 déc. 2013 à 22:30, Yann Vercucque  a écrit :

> Je rajouterai également qu'un employeur est tenu (Juridiquement parlant, loi 
> anti-terroriste) de loguer l'intégralité des flux web lorsqu'il dispose d'un 
> hotspot invité

Non. Tenus de conserver les données de connexion (en gros à quel était 
l’utilisateur correspondant à telle IP), oui, quel que soit d’ailleurs le 
statut de celui qui met à disposition l’accès. Mais en aucun cas l’usage qui 
est fait de cette connexion n’a à être loggé.

Je précise juste que, contrairement à ce qu’on peut lire ici ou là que le log 
des données de navigation (ou "l’intégralité des flux web" comme vous dites) 
est à ce stade prohibé (cf. art. L.34-1 CPCE VI 2nd alinéa), en tout cas pour 
un réseau ouvert au public.

—
Alec,





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

Re: [FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet Kavé Salamatian 

Le 8 déc. 2013 à 22:30, Yann Vercucque  a écrit :

> Je rajouterai également qu'un employeur est tenu (Juridiquement parlant, loi 
> anti-terroriste) de loguer l'intégralité des flux web lorsqu'il dispose d'un 
> hotspot invité. De ce faite, il est nécessaire de faire de l'interception 
> SSL, afin loguer les flux HTTPS.

Pas nécessaire de casser SSL pour cela. Il suffit de garder l’entête http de la 
négociation SSL. Il faut pas loggue le  contenu de l’échange.
> 
> Comme cela a déjà été dit, le problème n'est pas l'interception SSL. Mais 
> l'interception SSL par un certificat signé par une autorité connu.
> 
> Au passage les équipements comme Fortigate, permettent de choisir de ne pas 
> intercepter les banques, les sites médicaux et les réseaux sociaux.

> 
> Yann,
> 
> Le 8 déc. 2013 à 21:06, Raphaël Stehli  a écrit 
> :
> 
>> Juridiquement parlant, rien n'empêche à un employeur (public ou privé) :
>> - de déchiffrer le contenu des flux chiffrés pour les analyser de manière 
>> automatique,
>> - de déchiffrer le contenu des flux chiffrés pour interception manuelle, à 
>> la demande d'une autorité administration ou juridictionnelle, voir même à 
>> des fins internes, sous réserve de ne pas consulter les informations ayant 
>> un caractère personnel sans que le salarié ait été appelé. Le juge 
>> prudhommal vérifiera.
>> 
>> Il existerait un risque théorique de réutiliser le résultats de 
>> l'interception pour pirater une banque. Néanmoins, le risque est faible :
>> - les banques sérieuses utilise du forward secrecy, qui devrait limiter les 
>> problèmes de l'interception SSL,
>> - les entreprises ne laisse pas trainer leurs clés privées n'importent où 
>> (ou elles se retourneront à leur tour contre le responsable informatique),
>> - les salariés ou agents doivent être au courant de l'interception SSL via 
>> la charte informatique et la déclaration CNIL donc en utilisant le système 
>> informatique de l'entreprise / administration, ils étaient au courant et ils 
>> ont fait le choix de se connecter à leur banque avec le système,
>> - les banques sérieuses utilisent un autre système complémentaire (SMS, code 
>> à usage unique, etc.)
>> 
>> Donc, même en cas de vol de la clé, l'entreprise devrait voir sa 
>> responsabilité fortement minorée.
>> 
>> Le problème ici est que ce problème, lié a du gmail a fait bondir Google : 
>> son modèle économique est uniquement basé sur la confiance des utilisateurs.
>> Le modèle des ACR est basé sur la confiance des acteurs du secteurs.
>> La réaction de Google était donc prévisible.
>> 
>> Pour la restriction à *.gouv.fr, ce n'est pas forcément possible : il existe 
>> des administrations qui n'utilisent pas le .gouv.fr : je pense aux 
>> assemblées, aux juridictions et aux autres agences administratives 
>> indépendantes.
>> 
>> Je ne sais pas si quelqu'un peut maintenant prévoir la suite des évènements, 
>> mais il faut espérer que les modifications de protocoles de l'ANSSI 
>> arriveront à convaincre Google, Microsoft et Mozilla de ne pas bloquer les 
>> certificats racine de l'IGC/A.
>> 
>> Il faudrait également savoir comment les responsables de l'AC intermédiaire 
>> ont pu signer un certificat de pour google ou gmail.
>> 
>> 
>> Cordialement,
>> Raphaël
>> 
>> 
>> Le 08/12/2013 20:33, Jean-Yves Faye a écrit :
>>> Bonsoir,
>>> 
>>> NetASQ a cette fonctionnalité, et de plus est un produit bien Français. 
>>> Purement techniquement parlant, cette technique peut être pratique pour 
>>> garder l'aspect SSL des communications, tout en soumettant à l'analyse 
>>> antivirus/IDS les flux entrants, chose courante avec les appliances type 
>>> NetASQ justement. 
>>> 
>>> Comme déjà dit, le danger vient plutôt de le faire avec une AC certifiée et 
>>> publique (par transitivité). Normalement on fait ça avec une AC interne et 
>>> les certificats spécifiques sont déployés sur les postes.
>>> 
>>> Après cela remet encore une fois sur le tapis la question de la liste à 
>>> rallonge des autorités "de confiance" qui peuvent donner des certificats 
>>> pour n'importe quoi, qui ne veut plus dire grand chose. Dans ce cas précis, 
>>> une fonctionnalité de type restriction à *.gouv.fr sur l'IGC de 
>>> l'administration aurait été pertinente.
>>> 
>>> Un nettoyage des magasins de certificats des navigateurs est la seule 
>>> solution à court terme, ça ou alors les éditeurs de navigateurs se mettent 
>>> à implémenter les protocoles déjà proposés pour réduire la voilure niveau 
>>> portes d'entrée dans le système des IGC (moins problable)
>>> 
>>> Cordialement,
>>> 
>>> Jean-Yves Faye
>>> 
>>> 
>>> Le 8 décembre 2013 20:08, Fabien Delmotte  a écrit :
>>> Bonsoir,
>>> 
>>> Pareil pour A10 networks et le SSL intercept .. Cela me parait plus un 
>>> problème de configuration qu’autre chose.
>>> 
>>> Je ne connais pas les lois pour la France (il doit y en avoir beaucoup sur 
>>> le sujet avec le comment faire et son contraire), mais cela fonctionne sans 
>>> problème Technique dans

Re: [FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet Yann Vercucque 
Je rajouterai également qu'un employeur est tenu (Juridiquement parlant, loi 
anti-terroriste) de loguer l'intégralité des flux web lorsqu'il dispose d'un 
hotspot invité. De ce faite, il est nécessaire de faire de l'interception SSL, 
afin loguer les flux HTTPS.

Comme cela a déjà été dit, le problème n'est pas l'interception SSL. Mais 
l'interception SSL par un certificat signé par une autorité connu.

Au passage les équipements comme Fortigate, permettent de choisir de ne pas 
intercepter les banques, les sites médicaux et les réseaux sociaux.

Yann,

> Le 8 déc. 2013 à 21:06, Raphaël Stehli  a écrit 
> :
> 
> Juridiquement parlant, rien n'empêche à un employeur (public ou privé) :
> - de déchiffrer le contenu des flux chiffrés pour les analyser de manière 
> automatique,
> - de déchiffrer le contenu des flux chiffrés pour interception manuelle, à la 
> demande d'une autorité administration ou juridictionnelle, voir même à des 
> fins internes, sous réserve de ne pas consulter les informations ayant un 
> caractère personnel sans que le salarié ait été appelé. Le juge prudhommal 
> vérifiera.
> 
> Il existerait un risque théorique de réutiliser le résultats de 
> l'interception pour pirater une banque. Néanmoins, le risque est faible :
> - les banques sérieuses utilise du forward secrecy, qui devrait limiter les 
> problèmes de l'interception SSL,
> - les entreprises ne laisse pas trainer leurs clés privées n'importent où (ou 
> elles se retourneront à leur tour contre le responsable informatique),
> - les salariés ou agents doivent être au courant de l'interception SSL via la 
> charte informatique et la déclaration CNIL donc en utilisant le système 
> informatique de l'entreprise / administration, ils étaient au courant et ils 
> ont fait le choix de se connecter à leur banque avec le système,
> - les banques sérieuses utilisent un autre système complémentaire (SMS, code 
> à usage unique, etc.)
> 
> Donc, même en cas de vol de la clé, l'entreprise devrait voir sa 
> responsabilité fortement minorée.
> 
> Le problème ici est que ce problème, lié a du gmail a fait bondir Google : 
> son modèle économique est uniquement basé sur la confiance des utilisateurs.
> Le modèle des ACR est basé sur la confiance des acteurs du secteurs.
> La réaction de Google était donc prévisible.
> 
> Pour la restriction à *.gouv.fr, ce n'est pas forcément possible : il existe 
> des administrations qui n'utilisent pas le .gouv.fr : je pense aux 
> assemblées, aux juridictions et aux autres agences administratives 
> indépendantes.
> 
> Je ne sais pas si quelqu'un peut maintenant prévoir la suite des évènements, 
> mais il faut espérer que les modifications de protocoles de l'ANSSI 
> arriveront à convaincre Google, Microsoft et Mozilla de ne pas bloquer les 
> certificats racine de l'IGC/A.
> 
> Il faudrait également savoir comment les responsables de l'AC intermédiaire 
> ont pu signer un certificat de pour google ou gmail.
> 
> 
> Cordialement,
> Raphaël
> 
> 
> Le 08/12/2013 20:33, Jean-Yves Faye a écrit :
>> Bonsoir,
>> 
>> NetASQ a cette fonctionnalité, et de plus est un produit bien Français. 
>> Purement techniquement parlant, cette technique peut être pratique pour 
>> garder l'aspect SSL des communications, tout en soumettant à l'analyse 
>> antivirus/IDS les flux entrants, chose courante avec les appliances type 
>> NetASQ justement. 
>> 
>> Comme déjà dit, le danger vient plutôt de le faire avec une AC certifiée et 
>> publique (par transitivité). Normalement on fait ça avec une AC interne et 
>> les certificats spécifiques sont déployés sur les postes.
>> 
>> Après cela remet encore une fois sur le tapis la question de la liste à 
>> rallonge des autorités "de confiance" qui peuvent donner des certificats 
>> pour n'importe quoi, qui ne veut plus dire grand chose. Dans ce cas précis, 
>> une fonctionnalité de type restriction à *.gouv.fr sur l'IGC de 
>> l'administration aurait été pertinente.
>> 
>> Un nettoyage des magasins de certificats des navigateurs est la seule 
>> solution à court terme, ça ou alors les éditeurs de navigateurs se mettent à 
>> implémenter les protocoles déjà proposés pour réduire la voilure niveau 
>> portes d'entrée dans le système des IGC (moins problable)
>> 
>> Cordialement,
>> 
>> Jean-Yves Faye
>> 
>> 
>> Le 8 décembre 2013 20:08, Fabien Delmotte  a écrit :
>>> Bonsoir,
>>> 
>>> Pareil pour A10 networks et le SSL intercept .. Cela me parait plus un 
>>> problème de configuration qu’autre chose.
>>> 
>>> Je ne connais pas les lois pour la France (il doit y en avoir beaucoup sur 
>>> le sujet avec le comment faire et son contraire), mais cela fonctionne sans 
>>> problème Technique dans les autres pays.
>>> J’ai personnellement installé plusieurs configuration en dehors de la 
>>> France sans problèmes techniques.
>>> 
>>> Cordialement
>>> 
>>> Fabien
>>> 
>>> Le 8 déc. 2013 à 19:48, Surya ARBY  a écrit :
>>> 
>>> > C'est pourtant le principe de fonctionnement des firewalls palo alt

Re: [FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet Raphaël Stehli 
Juridiquement parlant, rien n'empêche à un employeur (public ou privé) :
- de déchiffrer le contenu des flux chiffrés pour les analyser de
manière automatique,
- de déchiffrer le contenu des flux chiffrés pour interception manuelle,
à la demande d'une autorité administration ou juridictionnelle, voir
même à des fins internes, sous réserve de ne pas consulter les
informations ayant un caractère personnel sans que le salarié ait été
appelé. Le juge prudhommal vérifiera.

Il existerait un risque théorique de réutiliser le résultats de
l'interception pour pirater une banque. Néanmoins, le risque est faible :
- les banques sérieuses utilise du forward secrecy, qui devrait limiter
les problèmes de l'interception SSL,
- les entreprises ne laisse pas trainer leurs clés privées n'importent
où (ou elles se retourneront à leur tour contre le responsable
informatique),
- les salariés ou agents doivent être au courant de l'interception SSL
via la charte informatique et la déclaration CNIL donc en utilisant le
système informatique de l'entreprise / administration, ils étaient au
courant et ils ont fait le choix de se connecter à leur banque avec le
système,
- les banques sérieuses utilisent un autre système complémentaire (SMS,
code à usage unique, etc.)

Donc, même en cas de vol de la clé, l'entreprise devrait voir sa
responsabilité fortement minorée.

Le problème ici est que ce problème, lié a du gmail a fait bondir Google
: son modèle économique est uniquement basé sur la confiance des
utilisateurs.
Le modèle des ACR est basé sur la confiance des acteurs du secteurs.
La réaction de Google était donc prévisible.

Pour la restriction à *.gouv.fr, ce n'est pas forcément possible : il
existe des administrations qui n'utilisent pas le .gouv.fr : je pense
aux assemblées, aux juridictions et aux autres agences administratives
indépendantes.

Je ne sais pas si quelqu'un peut maintenant prévoir la suite des
évènements, mais il faut espérer que les modifications de protocoles de
l'ANSSI arriveront à convaincre Google, Microsoft et Mozilla de ne pas
bloquer les certificats racine de l'IGC/A.

Il faudrait également savoir comment les responsables de l'AC
intermédiaire ont pu signer un certificat de pour google ou gmail.


Cordialement,
Raphaël


Le 08/12/2013 20:33, Jean-Yves Faye a écrit :
> Bonsoir,
>
> NetASQ a cette fonctionnalité, et de plus est un produit bien
> Français. Purement techniquement parlant, cette technique peut être
> pratique pour garder l'aspect SSL des communications, tout en
> soumettant à l'analyse antivirus/IDS les flux entrants, chose courante
> avec les appliances type NetASQ justement.
>
> Comme déjà dit, le danger vient plutôt de le faire avec une AC
> certifiée et publique (par transitivité). Normalement on fait ça avec
> une AC interne et les certificats spécifiques sont déployés sur les
> postes.
>
> Après cela remet encore une fois sur le tapis la question de la liste
> à rallonge des autorités "de confiance" qui peuvent donner des
> certificats pour n'importe quoi, qui ne veut plus dire grand chose.
> Dans ce cas précis, une fonctionnalité de type restriction à *.gouv.fr
>  sur l'IGC de l'administration aurait été pertinente.
>
> Un nettoyage des magasins de certificats des navigateurs est la seule
> solution à court terme, ça ou alors les éditeurs de navigateurs se
> mettent à implémenter les protocoles déjà proposés pour réduire la
> voilure niveau portes d'entrée dans le système des IGC (moins problable)
>
> Cordialement,
>
> Jean-Yves Faye
>
>
> Le 8 décembre 2013 20:08, Fabien Delmotte  > a écrit :
>
> Bonsoir,
>
> Pareil pour A10 networks et le SSL intercept .. Cela me parait
> plus un problème de configuration qu’autre chose.
>
> Je ne connais pas les lois pour la France (il doit y en avoir
> beaucoup sur le sujet avec le comment faire et son contraire),
> mais cela fonctionne sans problème Technique dans les autres pays.
> J’ai personnellement installé plusieurs configuration en dehors de
> la France sans problèmes techniques.
>
> Cordialement
>
> Fabien
>
> Le 8 déc. 2013 à 19:48, Surya ARBY  > a écrit :
>
> > C'est pourtant le principe de fonctionnement des firewalls palo
> alto qui font du MITM SSL avec des certificats signés par la PKI
> interne.
> >
> > Le 08/12/2013 19:26, Kavé Salamatian a écrit :
> >> 2-l’employeur n’a pas a inspecter le trafic SSL qui va de son
> réseau vers une destination en dehors de son réseau. Il peut
> décider de bloquer ce traffic, mais le décrypter avec un
> certificat « fake » c’est du piratage caractérisé et je suis sur
> qu’une ribambelle de lois de s’appliquent (pas le temps de les
> chercher).
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http

Re: [FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet Kavé Salamatian 
Bah non.

Que ça soit en interne ou en externe faire un MITM sur un transfert externe est 
problématique. Que ça soit dans l’administration ou pas (sauf exception genre 
l’armée ou autorisation de l’autorité judiciaire) et dans ce cas l’information 
recueillie est un scellé.

Kavé Salamatian
Le 8 déc. 2013 à 20:33, Jean-Yves Faye  a écrit :

> Bonsoir,
> 
> NetASQ a cette fonctionnalité, et de plus est un produit bien Français. 
> Purement techniquement parlant, cette technique peut être pratique pour 
> garder l'aspect SSL des communications, tout en soumettant à l'analyse 
> antivirus/IDS les flux entrants, chose courante avec les appliances type 
> NetASQ justement. 
> 
> Comme déjà dit, le danger vient plutôt de le faire avec une AC certifiée et 
> publique (par transitivité). Normalement on fait ça avec une AC interne et 
> les certificats spécifiques sont déployés sur les postes.
> 
> Après cela remet encore une fois sur le tapis la question de la liste à 
> rallonge des autorités "de confiance" qui peuvent donner des certificats pour 
> n'importe quoi, qui ne veut plus dire grand chose. Dans ce cas précis, une 
> fonctionnalité de type restriction à *.gouv.fr sur l'IGC de l'administration 
> aurait été pertinente.
> 
> Un nettoyage des magasins de certificats des navigateurs est la seule 
> solution à court terme, ça ou alors les éditeurs de navigateurs se mettent à 
> implémenter les protocoles déjà proposés pour réduire la voilure niveau 
> portes d'entrée dans le système des IGC (moins problable)
> 
> Cordialement,
> 
> Jean-Yves Faye
> 
> 
> Le 8 décembre 2013 20:08, Fabien Delmotte  a écrit :
> Bonsoir,
> 
> Pareil pour A10 networks et le SSL intercept .. Cela me parait plus un 
> problème de configuration qu’autre chose.
> 
> Je ne connais pas les lois pour la France (il doit y en avoir beaucoup sur le 
> sujet avec le comment faire et son contraire), mais cela fonctionne sans 
> problème Technique dans les autres pays.
> J’ai personnellement installé plusieurs configuration en dehors de la France 
> sans problèmes techniques.
> 
> Cordialement
> 
> Fabien
> 
> Le 8 déc. 2013 à 19:48, Surya ARBY  a écrit :
> 
> > C'est pourtant le principe de fonctionnement des firewalls palo alto qui 
> > font du MITM SSL avec des certificats signés par la PKI interne.
> >
> > Le 08/12/2013 19:26, Kavé Salamatian a écrit :
> >> 2-l’employeur n’a pas a inspecter le trafic SSL qui va de son réseau vers 
> >> une destination en dehors de son réseau. Il peut décider de bloquer ce 
> >> traffic, mais le décrypter avec un certificat « fake » c’est du piratage 
> >> caractérisé et je suis sur qu’une ribambelle de lois de s’appliquent (pas 
> >> le temps de les chercher).
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 


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

Re: [FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet Kavé Salamatian 
le problème n’est pas le SSL intercept ou un problème technique. Le problème 
est de « fake »r un certificat d’une entité externe. C’est pas parce que c’es 
techniquement possible qu’il est acceptable de le faire. Un peu d’éthique est 
bonne dans toute chose :-)

Une petite recherche google donne :

L’article L.323-1 du Nouveau code pénal prévoit que « le fait d’accéder ou de 
se maintenir, frauduleusement, dans tout ou partie d’un système de traitement 
automatisé de données est puni d’un an d’emprisonnement et de 15 000 euros 
d’amende ». Ces systèmes comprennent, entre autre, les sites web.

La Cour d’appel de Paris a considéré dans un arrêt du 5 avril 1994 que « 
l’accès frauduleux, au sens de la loi, vise tous les modes de pénétration 
irréguliers d’un système de traitement automatisé de données, que l’accédant 
travaille déjà sur la même machine mais à un autre système, qu’il procède à 
distance ou qu’il se branche sur une ligne de communication

Faire un MITM sur un transfert avec une entité externe est bien une pénétration 
irrégulière d’un système de traitement automatisé en se branchant (par proxy) 
sur une ligne de communication. Je suis sur qu’un bon juriste trouverait 
fouletitude d’autres arguments juridiques.


En résumé, que vous faisiez un SSL intercept sur une communication encrypté 
interne ça peut passer ( à vérifier avec les détails) mais que vous le faisiez 
sur un transfert qui va vers une entité externe (google, Facebook, banque, 
etc…) c’est du piratage caractérisé. Vous le faites, prenez un parachute et un 
paratonnerre avec vous :-). 

A ma connaissance même la NSA ne le fait pas :-) Bon c’est plus facile pour eu 
ils accèdent directement les données non-cryptées après stockage :-)

Kavé Salamatian 



Le 8 déc. 2013 à 20:08, Fabien Delmotte  a écrit :

> Bonsoir,
> 
> Pareil pour A10 networks et le SSL intercept .. Cela me parait plus un 
> problème de configuration qu’autre chose.
> 
> Je ne connais pas les lois pour la France (il doit y en avoir beaucoup sur le 
> sujet avec le comment faire et son contraire), mais cela fonctionne sans 
> problème Technique dans les autres pays.
> J’ai personnellement installé plusieurs configuration en dehors de la France 
> sans problèmes techniques.
> 
> Cordialement
> 
> Fabien
> 
> Le 8 déc. 2013 à 19:48, Surya ARBY  a écrit :
> 
>> C'est pourtant le principe de fonctionnement des firewalls palo alto qui 
>> font du MITM SSL avec des certificats signés par la PKI interne.
>> 
>> Le 08/12/2013 19:26, Kavé Salamatian a écrit :
>>> 2-l’employeur n’a pas a inspecter le trafic SSL qui va de son réseau vers 
>>> une destination en dehors de son réseau. Il peut décider de bloquer ce 
>>> traffic, mais le décrypter avec un certificat « fake » c’est du piratage 
>>> caractérisé et je suis sur qu’une ribambelle de lois de s’appliquent (pas 
>>> le temps de les chercher).
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 


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

Re: [FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet Jean-Yves Faye 
Bonsoir,

NetASQ a cette fonctionnalité, et de plus est un produit bien Français.
Purement techniquement parlant, cette technique peut être pratique pour
garder l'aspect SSL des communications, tout en soumettant à l'analyse
antivirus/IDS les flux entrants, chose courante avec les appliances type
NetASQ justement.

Comme déjà dit, le danger vient plutôt de le faire avec une AC certifiée et
publique (par transitivité). Normalement on fait ça avec une AC interne et
les certificats spécifiques sont déployés sur les postes.

Après cela remet encore une fois sur le tapis la question de la liste à
rallonge des autorités "de confiance" qui peuvent donner des certificats
pour n'importe quoi, qui ne veut plus dire grand chose. Dans ce cas précis,
une fonctionnalité de type restriction à *.gouv.fr sur l'IGC de
l'administration aurait été pertinente.

Un nettoyage des magasins de certificats des navigateurs est la seule
solution à court terme, ça ou alors les éditeurs de navigateurs se mettent
à implémenter les protocoles déjà proposés pour réduire la voilure niveau
portes d'entrée dans le système des IGC (moins problable)

Cordialement,

Jean-Yves Faye


Le 8 décembre 2013 20:08, Fabien Delmotte  a écrit :

> Bonsoir,
>
> Pareil pour A10 networks et le SSL intercept .. Cela me parait plus un
> problème de configuration qu’autre chose.
>
> Je ne connais pas les lois pour la France (il doit y en avoir beaucoup sur
> le sujet avec le comment faire et son contraire), mais cela fonctionne sans
> problème Technique dans les autres pays.
> J’ai personnellement installé plusieurs configuration en dehors de la
> France sans problèmes techniques.
>
> Cordialement
>
> Fabien
>
> Le 8 déc. 2013 à 19:48, Surya ARBY  a écrit :
>
> > C'est pourtant le principe de fonctionnement des firewalls palo alto qui
> font du MITM SSL avec des certificats signés par la PKI interne.
> >
> > Le 08/12/2013 19:26, Kavé Salamatian a écrit :
> >> 2-l’employeur n’a pas a inspecter le trafic SSL qui va de son réseau
> vers une destination en dehors de son réseau. Il peut décider de bloquer ce
> traffic, mais le décrypter avec un certificat « fake » c’est du piratage
> caractérisé et je suis sur qu’une ribambelle de lois de s’appliquent (pas
> le temps de les chercher).
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet Fabien Delmotte 
Bonsoir,

Pareil pour A10 networks et le SSL intercept .. Cela me parait plus un problème 
de configuration qu’autre chose.

Je ne connais pas les lois pour la France (il doit y en avoir beaucoup sur le 
sujet avec le comment faire et son contraire), mais cela fonctionne sans 
problème Technique dans les autres pays.
J’ai personnellement installé plusieurs configuration en dehors de la France 
sans problèmes techniques.

Cordialement

Fabien

Le 8 déc. 2013 à 19:48, Surya ARBY  a écrit :

> C'est pourtant le principe de fonctionnement des firewalls palo alto qui font 
> du MITM SSL avec des certificats signés par la PKI interne.
> 
> Le 08/12/2013 19:26, Kavé Salamatian a écrit :
>> 2-l’employeur n’a pas a inspecter le trafic SSL qui va de son réseau vers 
>> une destination en dehors de son réseau. Il peut décider de bloquer ce 
>> traffic, mais le décrypter avec un certificat « fake » c’est du piratage 
>> caractérisé et je suis sur qu’une ribambelle de lois de s’appliquent (pas le 
>> temps de les chercher).
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet Kavé Salamatian 
J’espère que l’entreprise qui fait ça a une bonne assurance, car le jour ou 
elle aura une banque qui s’est fait piraté avec un MITM se retournera vers 
elle, elle risque gros ….

Kavé Salamatian
Le 8 déc. 2013 à 19:48, Surya ARBY  a écrit :

> C'est pourtant le principe de fonctionnement des firewalls palo alto qui font 
> du MITM SSL avec des certificats signés par la PKI interne.
> 
> Le 08/12/2013 19:26, Kavé Salamatian a écrit :
>> 2-l’employeur n’a pas a inspecter le trafic SSL qui va de son réseau vers 
>> une destination en dehors de son réseau. Il peut décider de bloquer ce 
>> traffic, mais le décrypter avec un certificat « fake » c’est du piratage 
>> caractérisé et je suis sur qu’une ribambelle de lois de s’appliquent (pas le 
>> temps de les chercher).
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet Surya ARBY 
C'est pourtant le principe de fonctionnement des firewalls palo alto qui 
font du MITM SSL avec des certificats signés par la PKI interne.


Le 08/12/2013 19:26, Kavé Salamatian a écrit :

2-l’employeur n’a pas a inspecter le trafic SSL qui va de son réseau vers une 
destination en dehors de son réseau. Il peut décider de bloquer ce traffic, 
mais le décrypter avec un certificat « fake » c’est du piratage caractérisé et 
je suis sur qu’une ribambelle de lois de s’appliquent (pas le temps de les 
chercher).



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

Re: [FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet Raphaël Stehli 
Le problème est le suivant :
- l'IGC/A interdit dans sa politique la signature de tiers à
l'administration http://www.ssi.gouv.fr/fr/anssi/services-securises/igc-a/
- les certificats IGC/A sont (ou étaient) installés par défaut dans les
magasins des principaux clients

La signature illégitime d'un certif par une AC dont l'ACR est par défaut
dans tous les navigateurs et permettrait d'intercepter toutes les
connexions, même hors de l'administration concernée.

Quand un employeur veut lire le flux SSL des postes de ses agents ou
employés, il se fait un certificat maison et l'intègre au master ou aux
postes déjà en service.

Google surveille les certificats depuis le problème qui a eu lieu en
Tunisie : ils se sont fait prendre comme ça.

Cordialement,
Raphaël Stehli

Le 08/12/2013 19:13, Marc Abel a écrit :
> Bonjour,
>
> Je comprends pas bien pourquoi ils se sont fait prendre : pour
> intercepter les flux ssl l'employeur annonce à tout le personnel ce
> qu'il va faire, qu'on est pas à la maison mais au boulot, que le
> pare-feu va inspecter les messages et donc les certificats seront ceux
> du boulot (comme on accepte déjà le certificat de la messagerie), pour
> se faire passer pour google ou autre il faut avoir envie de faire ça
> en douce, à l'insu des utilisateurs, est-ce concevable  ?
>
> Marc, (dans l'administration mais pas aux finances)
> - Original Message - From: "Kavé Salamatian"
> 
> To: "Raphaël Stehli" 
> Cc: 
> Sent: Sunday, December 08, 2013 4:38 PM
> Subject: Re: [FRnOG] [ALERT] IGC/A et google
>
>
> A priori il y’a des outils qui sont vendus afin d’intercepter des
> connexions SSL sortantes et de vérifier leur contenu. Une
> administration liée au ministère des finances à voulu « tester » cette
> solution sur du trafic gmail. Pour ceci il faut forger un certificat
> de google (tout comme n’importe quel vulgaire voleur d’identité par
> phishing ou comme des gouvernement dictatoriaux voulant volant les
> logins de leurs nationaux à des services sécurisé).  Le certificat a
> été forgé par une sous-autorité de certification rattaché à l’ANSSI et
> Ils se sont fait prendre la main dans le pot de confiture. Montrant
> l’amateurisme en vigueur …..
>
> Kavé Salamatian
> Le 8 déc. 2013 à 16:31, Raphaël Stehli 
> a écrit :
>
>> Bonjour la liste,
>>
>> Après plusieurs mois de lecture, il s'agit de ma première intervention.
>>
>> - Le Monde vient de publier un article "Google bloque des certificats de
>> sécurité Internet émis par une autorité française"
>> http://abonnes.lemonde.fr/technologies/article/2013/12/08/google-bloque-des-certificats-de-securite-internet-emis-par-une-autorite-francaise_3527535_651865.html
>>
>>
>>
>> - l'ANSSI a publié un communiqué de presse "Suppression d’une branche de
>> l’IGC/A"
>> http://www.ssi.gouv.fr/fr/menu/actualites/suppression-d-une-branche-de-l-igc-a.html
>>
>> où il est fait mention que "Suite à une erreur humaine lors d’une action
>> de renforcement de la sécurité au ministère des finances, des
>> certificats numériques correspondant à des domaines extérieurs à
>> l’administration française ont été signés par une autorité de
>> certification de la direction générale du Trésor rattachée à l’IGC/A."
>>
>> - Google indique dans un communiqué
>> http://googleonlinesecurity.blogspot.it/2013/12/further-improving-digital-certificate.html?m=1
>>
>> que le problème est sérieux.
>>
>> Quelqu'un aurait-il des informations sur ce qui s'est passé ?
>>
>> Bien cordialement,
>>
>> Raphaël Stehli
>>
>> -- 
>> Raphaël Stehli,
>> Fonctionnaire détaché en cycle préparatoire de l'ENA,
>> Chargé d'enseignement vacataire à l'Université de Strasbourg,
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet Kavé Salamatian 
Bonjour
1-pourquoi ils se font fait prendre?
Google a detecté le « man in the middle »
2-l’employeur n’a pas a inspecter le trafic SSL qui va de son réseau vers une 
destination en dehors de son réseau. Il peut décider de bloquer ce traffic, 
mais le décrypter avec un certificat « fake » c’est du piratage caractérisé et 
je suis sur qu’une ribambelle de lois de s’appliquent (pas le temps de les 
chercher).
3- grosso modo, forger un certificat de google par une autorité de certif 
relève de la faute grave. L’excuse « Oups, je me suis fait pirater » aurait été 
plus acceptable que l’excuse « on a fait une erreur de manip ». Car pour faire 
une erreur de manip il faut en faire beaucoup pour arriver à mettre un 
certificat google dans la nature.

Bref, l’administration en question et l’ANSSI sont méchamment dans le fumier 
(pour ne pas dire dans le caca :-).

Kavé Salamatian 




Le 8 déc. 2013 à 19:13, Marc Abel  a écrit :

> Bonjour,
> 
> Je comprends pas bien pourquoi ils se sont fait prendre : pour intercepter 
> les flux ssl l'employeur annonce à tout le personnel ce qu'il va faire, qu'on 
> est pas à la maison mais au boulot, que le pare-feu va inspecter les messages 
> et donc les certificats seront ceux du boulot (comme on accepte déjà le 
> certificat de la messagerie), pour se faire passer pour google ou autre il 
> faut avoir envie de faire ça en douce, à l'insu des utilisateurs, est-ce 
> concevable  ?
> 
> Marc, (dans l'administration mais pas aux finances)
> - Original Message - From: "Kavé Salamatian" 
> 
> To: "Raphaël Stehli" 
> Cc: 
> Sent: Sunday, December 08, 2013 4:38 PM
> Subject: Re: [FRnOG] [ALERT] IGC/A et google
> 
> 
> A priori il y’a des outils qui sont vendus afin d’intercepter des connexions 
> SSL sortantes et de vérifier leur contenu. Une administration liée au 
> ministère des finances à voulu « tester » cette solution sur du trafic gmail. 
> Pour ceci il faut forger un certificat de google (tout comme n’importe quel 
> vulgaire voleur d’identité par phishing ou comme des gouvernement 
> dictatoriaux voulant volant les logins de leurs nationaux à des services 
> sécurisé).  Le certificat a été forgé par une sous-autorité de certification 
> rattaché à l’ANSSI et Ils se sont fait prendre la main dans le pot de 
> confiture. Montrant l’amateurisme en vigueur …..
> 
> Kavé Salamatian
> Le 8 déc. 2013 à 16:31, Raphaël Stehli  a écrit 
> :
> 
>> Bonjour la liste,
>> 
>> Après plusieurs mois de lecture, il s'agit de ma première intervention.
>> 
>> - Le Monde vient de publier un article "Google bloque des certificats de
>> sécurité Internet émis par une autorité française"
>> http://abonnes.lemonde.fr/technologies/article/2013/12/08/google-bloque-des-certificats-de-securite-internet-emis-par-une-autorite-francaise_3527535_651865.html
>> 
>> 
>> - l'ANSSI a publié un communiqué de presse "Suppression d’une branche de
>> l’IGC/A"
>> http://www.ssi.gouv.fr/fr/menu/actualites/suppression-d-une-branche-de-l-igc-a.html
>> où il est fait mention que "Suite à une erreur humaine lors d’une action
>> de renforcement de la sécurité au ministère des finances, des
>> certificats numériques correspondant à des domaines extérieurs à
>> l’administration française ont été signés par une autorité de
>> certification de la direction générale du Trésor rattachée à l’IGC/A."
>> 
>> - Google indique dans un communiqué
>> http://googleonlinesecurity.blogspot.it/2013/12/further-improving-digital-certificate.html?m=1
>> que le problème est sérieux.
>> 
>> Quelqu'un aurait-il des informations sur ce qui s'est passé ?
>> 
>> Bien cordialement,
>> 
>> Raphaël Stehli
>> 
>> -- 
>> Raphaël Stehli,
>> Fonctionnaire détaché en cycle préparatoire de l'ENA,
>> Chargé d'enseignement vacataire à l'Université de Strasbourg,
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/ 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet Marc Abel 

Bonjour,

Je comprends pas bien pourquoi ils se sont fait prendre : pour intercepter 
les flux ssl l'employeur annonce à tout le personnel ce qu'il va faire, 
qu'on est pas à la maison mais au boulot, que le pare-feu va inspecter les 
messages et donc les certificats seront ceux du boulot (comme on accepte 
déjà le certificat de la messagerie), pour se faire passer pour google ou 
autre il faut avoir envie de faire ça en douce, à l'insu des utilisateurs, 
est-ce concevable  ?


Marc, (dans l'administration mais pas aux finances)
- Original Message - 
From: "Kavé Salamatian" 

To: "Raphaël Stehli" 
Cc: 
Sent: Sunday, December 08, 2013 4:38 PM
Subject: Re: [FRnOG] [ALERT] IGC/A et google


A priori il y’a des outils qui sont vendus afin d’intercepter des connexions 
SSL sortantes et de vérifier leur contenu. Une administration liée au 
ministère des finances à voulu « tester » cette solution sur du trafic 
gmail. Pour ceci il faut forger un certificat de google (tout comme n’importe 
quel vulgaire voleur d’identité par phishing ou comme des gouvernement 
dictatoriaux voulant volant les logins de leurs nationaux à des services 
sécurisé).  Le certificat a été forgé par une sous-autorité de certification 
rattaché à l’ANSSI et Ils se sont fait prendre la main dans le pot de 
confiture. Montrant l’amateurisme en vigueur …..


Kavé Salamatian
Le 8 déc. 2013 à 16:31, Raphaël Stehli  a 
écrit :



Bonjour la liste,

Après plusieurs mois de lecture, il s'agit de ma première intervention.

- Le Monde vient de publier un article "Google bloque des certificats de
sécurité Internet émis par une autorité française"
http://abonnes.lemonde.fr/technologies/article/2013/12/08/google-bloque-des-certificats-de-securite-internet-emis-par-une-autorite-francaise_3527535_651865.html


- l'ANSSI a publié un communiqué de presse "Suppression d’une branche de
l’IGC/A"
http://www.ssi.gouv.fr/fr/menu/actualites/suppression-d-une-branche-de-l-igc-a.html
où il est fait mention que "Suite à une erreur humaine lors d’une action
de renforcement de la sécurité au ministère des finances, des
certificats numériques correspondant à des domaines extérieurs à
l’administration française ont été signés par une autorité de
certification de la direction générale du Trésor rattachée à l’IGC/A."

- Google indique dans un communiqué
http://googleonlinesecurity.blogspot.it/2013/12/further-improving-digital-certificate.html?m=1
que le problème est sérieux.

Quelqu'un aurait-il des informations sur ce qui s'est passé ?

Bien cordialement,

Raphaël Stehli

--
Raphaël Stehli,
Fonctionnaire détaché en cycle préparatoire de l'ENA,
Chargé d'enseignement vacataire à l'Université de Strasbourg,


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



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



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

Re: [FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet Kavé Salamatian 
A priori il y’a des outils qui sont vendus afin d’intercepter des connexions 
SSL sortantes et de vérifier leur contenu. Une administration liée au ministère 
des finances à voulu « tester » cette solution sur du trafic gmail. Pour ceci 
il faut forger un certificat de google (tout comme n’importe quel vulgaire 
voleur d’identité par phishing ou comme des gouvernement dictatoriaux voulant 
volant les logins de leurs nationaux à des services sécurisé).  Le certificat a 
été forgé par une sous-autorité de certification rattaché à l’ANSSI et Ils se 
sont fait prendre la main dans le pot de confiture. Montrant l’amateurisme en 
vigueur …..

Kavé Salamatian
Le 8 déc. 2013 à 16:31, Raphaël Stehli  a écrit :

> Bonjour la liste,
> 
> Après plusieurs mois de lecture, il s'agit de ma première intervention.
> 
> - Le Monde vient de publier un article "Google bloque des certificats de
> sécurité Internet émis par une autorité française"
> http://abonnes.lemonde.fr/technologies/article/2013/12/08/google-bloque-des-certificats-de-securite-internet-emis-par-une-autorite-francaise_3527535_651865.html
> 
> 
> - l'ANSSI a publié un communiqué de presse "Suppression d’une branche de
> l’IGC/A"
> http://www.ssi.gouv.fr/fr/menu/actualites/suppression-d-une-branche-de-l-igc-a.html
> où il est fait mention que "Suite à une erreur humaine lors d’une action
> de renforcement de la sécurité au ministère des finances, des
> certificats numériques correspondant à des domaines extérieurs à
> l’administration française ont été signés par une autorité de
> certification de la direction générale du Trésor rattachée à l’IGC/A."
> 
> - Google indique dans un communiqué
> http://googleonlinesecurity.blogspot.it/2013/12/further-improving-digital-certificate.html?m=1
> que le problème est sérieux.
> 
> Quelqu'un aurait-il des informations sur ce qui s'est passé ?
> 
> Bien cordialement,
> 
> Raphaël Stehli
> 
> -- 
> Raphaël Stehli,
> Fonctionnaire détaché en cycle préparatoire de l'ENA,
> Chargé d'enseignement vacataire à l'Université de Strasbourg,
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [ALERT] IGC/A et google

2013-12-08 Par sujet Raphaël Stehli 
Bonjour la liste,

Après plusieurs mois de lecture, il s'agit de ma première intervention.

- Le Monde vient de publier un article "Google bloque des certificats de
sécurité Internet émis par une autorité française"
http://abonnes.lemonde.fr/technologies/article/2013/12/08/google-bloque-des-certificats-de-securite-internet-emis-par-une-autorite-francaise_3527535_651865.html


- l'ANSSI a publié un communiqué de presse "Suppression d’une branche de
l’IGC/A"
http://www.ssi.gouv.fr/fr/menu/actualites/suppression-d-une-branche-de-l-igc-a.html
où il est fait mention que "Suite à une erreur humaine lors d’une action
de renforcement de la sécurité au ministère des finances, des
certificats numériques correspondant à des domaines extérieurs à
l’administration française ont été signés par une autorité de
certification de la direction générale du Trésor rattachée à l’IGC/A."

- Google indique dans un communiqué
http://googleonlinesecurity.blogspot.it/2013/12/further-improving-digital-certificate.html?m=1
que le problème est sérieux.

Quelqu'un aurait-il des informations sur ce qui s'est passé ?

Bien cordialement,

Raphaël Stehli

-- 
Raphaël Stehli,
Fonctionnaire détaché en cycle préparatoire de l'ENA,
Chargé d'enseignement vacataire à l'Université de Strasbourg,


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