Pour ceux qui l'aurait pas lu :
http://www.pcinpact.com/news/84830-blocage-certificats-par-google-interview-patrick-pailloux-anssi.htm?utm_source=PCi_RSS_Feed&utm_medium=news&utm_campaign=pcinpact
David
Le 10 décembre 2013 15:58, Raphaël Stehli a
écrit :
> Bonjour la liste,
>
> D'un point de v
Bonjour la liste,
D'un point de vue juridique, l'intercept SSL n'est pas illégal si c'est
pour protéger le réseau et ne rentre pas sous le coup du 226-15 du code
pénal qui énonce que
"Le fait, commis de mauvaise foi, d'ouvrir, de supprimer, de retarder ou
de détourner des correspondances arrivées
Le 09/12/2013 à 22:57, Alexandre PIERRET a écrit :
> Bruno Tréguier
>
> "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."
>
> J'arrive un peu tard dans la conversation, mais j
Bruno Tréguier
"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."
J'arrive un peu tard dans la conversation, mais juste pour préciser
qu'une AC ne peut pas signer ce qu'elle veut.
Bonsoir,
Le 09/12/2013 14:56, Xavier Beaudouin écrivit :
> Le 08/12/2013 20:33, Jean-Yves Faye a écrit :
>> 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à propo
Beacoup de VPN utilisent précisément le port 443 ! (Cisco AnyConnect par
exemple)
Kavé Salamatian
Le 9 déc. 2013 à 16:25, Yann Vercucque a écrit :
> La majorité des équipements rendant possible l'utilisation de l'interception
> SSL, permettent d'appliquer du deep inspection sur des flux préci
La majorité des équipements rendant possible l'utilisation de l'interception
SSL, permettent d'appliquer du deep inspection sur des flux précis (de Hotspot
vers internet, par exemple) de même il possible de définir que ce n'est
uniquement les flux à destination du port 443 qui seront deep inspec
On Mon, Dec 9, 2013, at 15:50, Yann Vercucque wrote:
> Il faut arrêter d'aller dans tout les sens...
>
> Une interception SSL peut ce faire sur certain flux, pas sur une page
> d'authentification VPN, par exemple (techniquement faisable mais sans intérêt)
Generalement tu interceptes avant de sav
Il faut arrêter d'aller dans tout les sens...
Une interception SSL peut ce faire sur certain flux, pas sur une page
d'authentification VPN, par exemple (techniquement faisable mais sans intérêt)
Pour les textes de lois concernant les accès internet public :
Premièrement, la loi LCEN du 21 jui
On Mon, Dec 9, 2013, at 10:05, MM wrote:
> Décortiquer le SSL pour s’assurer qu’il n’est pas utilisé à des fins de
> VPN, ou pour protéger les échanges de virus vers des centres de contrôle
En occurence comment expliques-tu a un de tes partennaires que son flux
VPN vers son entreprise, fait avec
On Sun, Dec 8, 2013, at 22:46, Kavé Salamatian wrote:
> 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.
ce qui est largement faisable meme en mode TAP/SPAN .
---
List
On Sun, Dec 8, 2013, at 22:30, Yann Vercucque wrote:
> 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
On Sun, Dec 8, 2013, at 21:06, Raphaël Stehli wrote:
> 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,
Faut voir le probleme sous un autre angle.
Supposons le scenario suivant, qu
Bonjour,
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 le
On Sun, Dec 8, 2013, at 19:48, Surya ARBY wrote:
> 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
On 12/08/2013 11:53 PM, Bruno Tréguier wrote:
> 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 sign
On 09.12.2013 10:05, MM wrote:
Décortiquer le SSL pour s’assurer qu’il n’est pas utilisé à des fins
de VPN, ou pour protéger les échanges de virus vers des centres de
contrôle (par exemple) - oui, mais Facebook je ne vois pas le rapport.
dans la catégorie course a l'échalotte a empecher le mon
Le 08/12/2013 23:44, Raphaël Stehli a écrit :
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
Bonjour,
> Maintenant, dans le cas ou les employes sont prévenus et que le contenu des
> messages n’est pas loggué, je ne vois pas ce qu’il y a de choquant !!!
> N’oublions pas que lorsque nous faisons des stats sur les IP destinations
> dans des grands groupes Facebook arrive en tete a 10h le m
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,
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 l
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
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
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é
>
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
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 étai
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, afi
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 prob
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, vo
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
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 :
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
N
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 da
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 firew
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é
m: "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érifi
t; 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
m: "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é
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
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-certifi
40 matches
Mail list logo
