Re: [FRnOG] [ALERT] IGC/A et google
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 juste pour préciser > qu'une AC ne peut pas signer ce qu'elle veut. > Quand une AC signe "quelque chose", elle définie précisément quels > sont les droits de ce "quelque chose". ex: une SubCA, un certificat > serveur, un certificat client, une signature de code, un certificat > mail, une CRL, etc... Bonsoir, En effet, j'ai peut-être été un peu trop général (ou amiral pour les marins ;-) ). En théorie, il y a aussi le "Name Constraints" (RFC 5280, section 4.2.1.10), dont a déjà parlé Stéphane Bortzmeyer un peu plus haut dans le fil, mais comme il le dit, cette fonction est très peu mise en oeuvre (la preuve), donc dans les faits, rien n'empêche une AC intermédiaire de signer un certificat avec un "Subject Name" quelconque. C'est d'ailleurs bien ce qui s'est passé dans le cas présent, et c'est la raison pour laquelle des choses comme le Public Key Pinning ou le protocole DANE présentent un intérêt (protection contre les AC compromises, etc.). Cordialement, Bruno Tréguier -- - 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] [MISC] Business de location d'IP : WTF ?
Ça pourrait être aussi pour de la fraude au clic ? Simuler des faux clics sur des pubs type AdSense de sites web pour se faire rémunérer, avec des ranges différents pour ne pas se faire détecter par Google (et sans besoin du port 25 ni de débits élevés). Patrick. Le 09/12/2013 16:51, Sylvain Charron (LASOTEL) a écrit : > Pensé à bloquer le 587 aussi. > De plus nous avons de plus en plus de spammeur qui passe par les webmail > avec des logins/mdp fisher a nos abonnés. > > Sylvain Charron > LA SOLUTION TELECOM (LASOTEL) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
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. Quand une AC signe "quelque chose", elle définie précisément quels sont les droits de ce "quelque chose". ex: une SubCA, un certificat serveur, un certificat client, une signature de code, un certificat mail, une CRL, etc... RFC: http://tools.ietf.org/html/rfc5280#section-4.2.1.9 Alexandre Pierret 2013/12/8 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/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
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à proposés >> pour réduire la voilure niveau portes d'entrée dans le système des >> IGC (moins problable) > > La solution a déployer serait plutôt un DANE vraiment intégré dans > les navigateurs, seul bémol, ça dépends de DNSSEC et DNSSEC c'est > bien mais c'est pas "effortless" a intégrer... Hélas :( Je me dis que les gens qui déploient du SSL Intercept vont pas être tentés de déployer des résolveurs validants sur leur réseau si ça casse leur jouet :-) Et souvent en entreprise, l'on est pas administrateur de la machine, donc va changer le résolveur DNS ou installer un unbound local… -- Cyprien --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [ALERT] IGC/A et google
Le 2013-12-09 12:51, Christophe Renard a écrit : On 12/09/2013 09:54 AM, Fabien Delmotte wrote: Personne n'a dit que cela ne marchait pas. C'est la moralité de ce détournement qui était en cause. Mon propos était de dire que si il y a eu detection c’est que l’implementation au niveau technique n’était pas bonne. 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 matin !!! Trop de contrôle c'est la dictature mas pas de contrôle c’est le borde……. Il y a un cas d'usage encore plus simple: avec la multiplication des webmails, des Google Docs, et autres DropBox, si on désire appliquer du filtrage anti-virus, voir de la détection d'attaque sur les flux, il faut intercepter le SSL/TLS. Il est clair qu'avec le Claude, on en arrive à ce genre d'aberrations ... Puisque les mails ne sont pas stockés chez moi (GoogleApps), mais que l'utilisateur peut envoyer / télécharger des pièces jointes à travers ce flux SSL, comment bloquer soit les mails à destination des concurrents, soit le téléchargement de fichiers vérolés ??? Plein de SI utilisent ZScaler comme tiers de confiance sur l'analyse antivirale / antispam Et le pire c'est que les mails sont je sais pas ou, et qu'ils transitent par un proxy SSL qui fait du MiTM je ne sais pas ou Résultat : à force de vouloir blinder les échanges, on se retrouve avec des idioties qui consiste à faire passer toute la merde dans du SSL/443, et à devoir faire du MiTM pas très légal mais souvent inscrit implicitement dans la charte de l'entreprise. En bref, avec le Claude, le chiffrement SSL se généralise, mais du coup le MiTM aussi ! PS : Dans mes souvenirs, le proxy SSL NETASQ a une exception par défaut des sites bancaires pour ne faire le déchiffrement et du coup squeezer la responsabilité pour le domaine bancaire ... Il n'en empêche que le mec désœuvré qui ne sait pas quoi faire de sa journée, peut dumper entre 2 loopbacks sur le point de MiTM Vivement qu'on se mette tous à faire de l'IP over DNS, avec le proxy DNS UDP comme prochaine killer feature des IPS / NGFW / FGFW (pour Future Generation Firewall vu que la Next c'est l'actuelle Désolé on est pas trolldi et le Gartner est pas encore au courant). Est-ce tromper l'utilisateur ? Est-ce protéger le SI, voir l'usager ? A voir selon le contexte. Évidemment ce qui serai une faute éthique et possiblement légale serai d'intercepter les communications pour permettre à l'employeur d'empiéter sur la vie privée des employés, du moins en France. Il me semble, en tout cas, que c'est une pratique plutôt courante même si elle nécessite, évidemment, un encadrement rigoureux: communication, inclusion dans les règlements intérieurs et autres chartes d'utilisation, protection de la machine faisant l'interception, restriction de l'accès aux données interceptées au plus strict besoin d'en connaitre (sur incident sans doute ...), qui ne sont probablement pas toujours mis en œuvre. Enfin, il faut noter que les informations aujourd'hui publiquement disponibles ne permettent guère de conclure sur la nature et le détail de l'incident. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Business de location d'IP : WTF ?
Pensé à bloquer le 587 aussi. De plus nous avons de plus en plus de spammeur qui passe par les webmail avec des logins/mdp fisher a nos abonnés. Sylvain Charron LA SOLUTION TELECOM (LASOTEL) Le 09/12/2013 16:46, Cedric T. a écrit : j'ai déja vu quelque chose d'ingénieux pour contourner le blocage du port 25 en sortie : Il envoie tout son spam depuis un fournisseur peu regardant : en fait il spoof les IP d'un autre fournisseur qui bloque le 25 qu'en sortie. Du coup les ACK arrivent par le 2e fournisseur, qui ne comprend pas comment on a pu spammer et protège son client connement "mais j'vous jure, c'est pas possible, il peut pas spammer le port 25 est bloqué !!!" Cédric * Radu-Adrian Feurdean [2013-12-09 15:41 +0100]: On Mon, Dec 9, 2013, at 11:35, Julien Escario wrote: toujours annoncés chez nous et avec 10 Mbps, je les vois mal rerouter du trafic pour crawler/spammer/what else ? Ne sous-estime jamais les spammeurs :) Ils ont souvent des moyens plus importants que toi. Multiplie ce qu'ils te demandent par 100 (voire plus) et essaye de voir ce qu;ils peuvent faire avec ca :) --- 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] [MISC] Business de location d'IP : WTF ?
j'ai déja vu quelque chose d'ingénieux pour contourner le blocage du port 25 en sortie : Il envoie tout son spam depuis un fournisseur peu regardant : en fait il spoof les IP d'un autre fournisseur qui bloque le 25 qu'en sortie. Du coup les ACK arrivent par le 2e fournisseur, qui ne comprend pas comment on a pu spammer et protège son client connement "mais j'vous jure, c'est pas possible, il peut pas spammer le port 25 est bloqué !!!" Cédric * Radu-Adrian Feurdean [2013-12-09 15:41 +0100]: > On Mon, Dec 9, 2013, at 11:35, Julien Escario wrote: > > > toujours annoncés chez nous et avec 10 Mbps, je les vois mal rerouter du > > trafic pour crawler/spammer/what else ? > > Ne sous-estime jamais les spammeurs :) > Ils ont souvent des moyens plus importants que toi. Multiplie ce qu'ils > te demandent par 100 (voire plus) et essaye de voir ce qu;ils peuvent > faire avec ca :) > > > --- > 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
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é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 inspecté. > > Yann, > >> Le 9 déc. 2013 à 16:00, "Radu-Adrian Feurdean" >> a écrit : >> >>> 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 savoir ce que tu as intercepte. >> Les autorisations "fine-grained" vers internet NE MARCHENT PAS !!! Meme >> si la technologie existe, la gestion c'est un echec a plus de 99% des >> cas. > > > --- > 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
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 inspecté. Yann, > Le 9 déc. 2013 à 16:00, "Radu-Adrian Feurdean" > a écrit : > >> 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 savoir ce que tu as intercepte. > Les autorisations "fine-grained" vers internet NE MARCHENT PAS !!! Meme > si la technologie existe, la gestion c'est un echec a plus de 99% des > cas. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
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 savoir ce que tu as intercepte. Les autorisations "fine-grained" vers internet NE MARCHENT PAS !!! Meme si la technologie existe, la gestion c'est un echec a plus de 99% des cas. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
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 juin 2004 impose aux personnes qui fournissent un accès à internet de garder confidentielles les données personnelles de leurs clients (article 6 III 2 de la loi). Mais en même temps, cette loi leur impose aussi la conservation des données « de nature à permettre l'identification de quiconque a contribué à la création du contenu ou de l'un des contenus des services dont elle est prestataire » (article 6 II). Certains y ont vu un paradoxe, mais il n'est qu'apparent. Le FAI doit seulement pouvoir déconfidentialiser les données si l'autorité judiciaire lui en fait la demande. Il reste tenu au secret professionnel. L'article L.34-1 du CPCE reprend cette exigence. Conformément à la LCEN, le code rappelle donc que l'OCE doit conserver les données permettant l'identification des personnes utilisatrices des services fournis par les opérateurs. En outre, l'article R.10-13 du CPCE issu du décret du 24 mars 2006 décrit les catégories de données à conserver. Il s'agit des données permettant l'identification de la personne qui s'est connectée, les données de connexion dont la date et l'heure, les données relatives aux équipements utilisés et même les données permettant d'identifier les destinataires de toute communication effectuée. Le décret du 24 mars 2006 fixe la durée de conservation des données à un an, durée au-delà de laquelle elles devront être anonymisées. La loi « Informatique & Libertés » du 6 janvier 1978 intervient également, puisque le FAI doit absolument respecter les obligations d'information des personnes quant à leurs droits d'accès, de rectification, d'opposition et de suppression. En outre, conformément à la décision de ARCEP du 26 avril 2007 (mettant fin à la phase initiale d'expérimentation des réseaux WLAN), les opérateurs wifi sont dorénavant soumis au respect de l'ensemble des dispositions du CPCE Yann, > Le 9 déc. 2013 à 15:35, "Radu-Adrian Feurdean" > a écrit : > >> 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 son identifiant est intercepte ? En > clair/decrypte ? > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Business de location d'IP : WTF ?
On Mon, Dec 9, 2013, at 11:35, Julien Escario wrote: > toujours annoncés chez nous et avec 10 Mbps, je les vois mal rerouter du > trafic pour crawler/spammer/what else ? Ne sous-estime jamais les spammeurs :) Ils ont souvent des moyens plus importants que toi. Multiplie ce qu'ils te demandent par 100 (voire plus) et essaye de voir ce qu;ils peuvent faire avec ca :) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
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 son identifiant est intercepte ? En clair/decrypte ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
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 . --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
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 loguer les flux HTTPS. Il est tenu juridiquement d'aller jusqu'au ou ? On fait quoi de SSL-VPN ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
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, qui n'est pas tout a fait a cote de la realite: - 1 PME a 250 personnes chaque (en moyenne) deployent du "SSL intercept". - Ca fait ~2 500 000 personnes qui pendant 35-40 heures par semaine ne voyent plus qu'une seule CA qui signe TOUS les certifs SSL du monde - Ils ne voyent pas tous la meme CA, mais le temps d'etre salaries d'une seule societe ils voyent systematiquement la meme CA. - du coup, les certificats EV n'existent plus. - il y a parfois des rates dans les services informatiques de certaines entreprises (globalement, sur les 1 PME, je dirais "assez souvent"). Pendant ces rates, les gens ont des "SSL warning", dont le service IT leur dit "pas de probleme". - les 2 500 000 personnes surfent chez eux, avec leurs ordinateurs sur des sites parfois douteux. Parfois ce sites sont en SSL, avec des faux cetifs. - BONUS : rajouter au lot 100 grands groupes a 5000 personens en moyenne (total, encore 500 K personnes, voire plus). -> Comment voulez-vous que les 2 500 000 personnes reagissent devant un "vrai faux certif" (lire frauduleux) quand ils passent pas mal de leur temps devant des certifs "re-signes" ? Est-ce que par la meme logique on peut dire que pour un service B2B c'est meme pas la peine d'acheter un vrai certificat, car la plupart des utilisateurs risquent de passe par des soi-disant "boities de securite" qui font du "SSL Intercept" ? Oui, la technique permet de faire ca, mais il faut avoir quand-meme un peu de discernement dans l'utilisation. La soi-disant "securite" de nos jours me fait penser a la course a l'armement nucleaire d'il y a pas si longtemps que ca. Si vous ne savez pas ce qu'est, demandez a vos parents/grand-parents. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
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 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) La solution a déployer serait plutôt un DANE vraiment intégré dans les navigateurs, seul bémol, ça dépends de DNSSEC et DNSSEC c'est bien mais c'est pas "effortless" a intégrer... Hélas :( Xavier -- Xavier Beaudouin --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
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 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). Le fait que c'est techniquement possible ne veut pas dire qu'il faut faire ca. Autre les aspects juridiques que Kave a deja evoque plus haut, il y a l'aspect "confiance" dans la chaine de certification qui est attaque par des tels procedures. Bref si on a des "problemes" avec l'utilisation du SSL: - on a la clef prive de la destination et on fait ce qu'on veut avec le traffic (generalement valable uniquement pour les sites internes) - on regarder ce qu'on peut pour prendre une decision (accept ou block). Generallement ca se limite aux donnees presentes dans le certif (CN, signed by, O/OU, date d'expiration) parfois un peu plus (HTTP_Host si SNI), mais ca ne concerne jamais traffic crypte. - on prend la decision de bloquer ou non uniquement sur des criteres non-lies au payload (IP dest, port TCP, ) La MITM SSL , il faut eviter de l'utiliser, meme s'il y a de plus en plus de constructeurs qui la proposent. Imagine juste ce que ca peut donner si "pour le bien du client" les FAI se mettent a faire ca. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [BIZ] recherche AC zone RP
Bonjour, Je cherche un agent commercial pour des service bas niveau en région parisienne. Merci de me contacter en privé SVP. Bien cordialement, S. Vallerot --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [ALERT] IGC/A et google
On 12/09/2013 09:54 AM, Fabien Delmotte wrote: >> Personne n'a dit que cela ne marchait pas. C'est la moralité de ce >> détournement qui était en cause. > Mon propos était de dire que si il y a eu detection c’est que > l’implementation au niveau technique n’était pas bonne. > > 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 matin !!! > > Trop de contrôle c'est la dictature mas pas de contrôle c’est le borde……. Il y a un cas d'usage encore plus simple: avec la multiplication des webmails, des Google Docs, et autres DropBox, si on désire appliquer du filtrage anti-virus, voir de la détection d'attaque sur les flux, il faut intercepter le SSL/TLS. Est-ce tromper l'utilisateur ? Est-ce protéger le SI, voir l'usager ? A voir selon le contexte. Évidemment ce qui serai une faute éthique et possiblement légale serai d'intercepter les communications pour permettre à l'employeur d'empiéter sur la vie privée des employés, du moins en France. Il me semble, en tout cas, que c'est une pratique plutôt courante même si elle nécessite, évidemment, un encadrement rigoureux: communication, inclusion dans les règlements intérieurs et autres chartes d'utilisation, protection de la machine faisant l'interception, restriction de l'accès aux données interceptées au plus strict besoin d'en connaitre (sur incident sans doute ...), qui ne sont probablement pas toujours mis en œuvre. Enfin, il faut noter que les informations aujourd'hui publiquement disponibles ne permettent guère de conclure sur la nature et le détail de l'incident. -- Christophe Renard signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Re: [ALERT] IGC/A et google
On 12/08/2013 11:12 PM, Stephane Bortzmeyer wrote: > 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. Il y a eu des discussions longues et virulentes sur le sujet. La FAQ Mozilla résume bien la situation: https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Frequently_Asked_Questions Apparemment, les membres du CA/Browser Forum craignent de faire rejeter trop de certificats par les implémentations SSL/TLS ne supportant pas l'attribut (qui est pourtant dans PKIX depuis ) -- Christophe Renard Hervé Schauer Consultants (HSC) signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [ALERT] IGC/A et google
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 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. Techniquement parlant que je pense que l'attribut NameConstraint de la RFC5280 est la pour ça. Maintenant, ma compréhension est que son non support dans les ancien navigateurs l'a fait marquer non-critique ce qui rends son intérêt bien moindre. Cordialement, -- Christophe Renard Hervé Schauer Consultants (HSC) signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Re: [ALERT] IGC/A et google
Le 09/12/2013 à 9:54, Fabien Delmotte a écrit : > Mon propos était de dire que si il y a eu detection c’est > que l’implementation au niveau technique n’était pas bonne. En l'espèce, cette détection semble avoir été faite à l'aide du "public key pinning" mis en place par Google dans Chrome à partir de la version 13 pour ses propres certificats. Chrome a donc râlé (ce qui n'aurait pas été le cas si une AC locale avait été installée pour le MITM SSL, car une telle AC a priorité sur le public key pinning, d'après Adam Langley lui-même: https://www.imperialviolet.org/2011/05/04/pinning.html), mais après, comment l'info est-elle remontée chez Google, je me le demande. Chrome "téléphonerait-il maison" (pas le temps de regarder les sources) ? Sont-ce les utilisateurs eux-mêmes qui ont averti Google ? L'article posté par Langley sur Google Online Security Blog n'est pas très bavard là-dessus, puisqu'on ne sait pas très bien qui étaient les utilisateurs concernés et quel était le matériel commercial dans lequel l'AC intermédiaire se trouvait... Article extrêmement éclairant sur l'interception SSL: http://blog.cryptographyengineering.com/2012/03/how-do-interception-proxies-fail.html Voir en particulier l'ultimatum lancé en 2012 par Mozilla envers TrustWave, qui à une époque avait autorisé ce que l'AC intermédiaire de l'IGC/A vient "par erreur" de se permettre: http://blog.cryptographyengineering.com/2012/02/quick-hit-ssl-mitm-update.html 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] [MISC] Business de location d'IP : WTF ?
Ca peut être du spamming web aussi : - faux avis consomamteurs sur des comparateurs - faux commentaires dans les forums - ou du vpn, mais 10mbps ca fait léger Cédric * Manuel Martinez [2013-12-09 10:42 +]: > Salut la liste, > > J'ai rencontré quelqu'un qui faisait ça pour acheter des tickets online pour > certains évènements sportifs ou concerts (Roland Garros, M. Farmer, etc), > pour dépasser les quotas avec des robots et faire de la revente, au black. > Apparemment, c'était très rentable. > Cependant c'était il y a un bout de temps. > Je ne saurais dire si ça pourrait faire le job, pour des tickets pour la > coupe du monde de foot ? ;-) > > Manuel MARTINEZ > > -Message d'origine- > De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de > Julien Escario > Envoyé : lundi 9 décembre 2013 11:35 > À : frnog-m...@frnog.org > Objet : [FRnOG] [MISC] Business de location d'IP : WTF ? > > Bonjour, > Ca fait 2/3 fois que je reçois des mails, semble t'il assez sérieux, de mecs > qui veulent le louer des IPs. > > La dernière fois que j'ai creusé, le type voulait un serveur avec 10 Mbps de > transit, un blocage du port 25 en guise de bonne foi et un max d'IP dans des > ranges différents. > > Mais ils en font quoi au final ? Parce que dans tous les cas, les préfixes > sont toujours annoncés chez nous et avec 10 Mbps, je les vois mal rerouter du > trafic pour crawler/spammer/what else ? > > C'est quoi ce business au final ? > > Julien > > > --- > 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] [MISC] Business de location d'IP : WTF ?
Salut la liste, J'ai rencontré quelqu'un qui faisait ça pour acheter des tickets online pour certains évènements sportifs ou concerts (Roland Garros, M. Farmer, etc), pour dépasser les quotas avec des robots et faire de la revente, au black. Apparemment, c'était très rentable. Cependant c'était il y a un bout de temps. Je ne saurais dire si ça pourrait faire le job, pour des tickets pour la coupe du monde de foot ? ;-) Manuel MARTINEZ -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Julien Escario Envoyé : lundi 9 décembre 2013 11:35 À : frnog-m...@frnog.org Objet : [FRnOG] [MISC] Business de location d'IP : WTF ? Bonjour, Ca fait 2/3 fois que je reçois des mails, semble t'il assez sérieux, de mecs qui veulent le louer des IPs. La dernière fois que j'ai creusé, le type voulait un serveur avec 10 Mbps de transit, un blocage du port 25 en guise de bonne foi et un max d'IP dans des ranges différents. Mais ils en font quoi au final ? Parce que dans tous les cas, les préfixes sont toujours annoncés chez nous et avec 10 Mbps, je les vois mal rerouter du trafic pour crawler/spammer/what else ? C'est quoi ce business au final ? Julien --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] Business de location d'IP : WTF ?
Bonjour, Ca fait 2/3 fois que je reçois des mails, semble t'il assez sérieux, de mecs qui veulent le louer des IPs. La dernière fois que j'ai creusé, le type voulait un serveur avec 10 Mbps de transit, un blocage du port 25 en guise de bonne foi et un max d'IP dans des ranges différents. Mais ils en font quoi au final ? Parce que dans tous les cas, les préfixes sont toujours annoncés chez nous et avec 10 Mbps, je les vois mal rerouter du trafic pour crawler/spammer/what else ? C'est quoi ce business au final ? Julien --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [ALERT] IGC/A et google
On Mon, Dec 09, 2013 at 09:54:53AM +0100, Fabien Delmotte wrote: > N’oublions pas que lorsque nous faisons des stats sur les IP destinations > dans des grands groupes Facebook arrive en tete a 10h le matin !!! Et alors ? Tant que le boulot est fait. Qu'ils jactent sur facebook ou à la machine à café ça change quoi ? Si tu bloques (et rien ne justifie d'inspecter le contenu des paquets pour ça), les mecs perdront du temps à faire ça sur leur mobile par exemple, mais ne seront pas forcement plus productifs. signature.asc Description: Digital signature
Re: [FRnOG] [ALERT] IGC/A et google
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 montage de vpn, on peut jouer hein... un peu de steganographie par ci, de l'encapsulation a la con par la... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
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 é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. Après quelques recherches google, j'ai trouvé les informations suivantes, pistes pour les articles de loi http://open.arkoon.net/aoc/l-ere-de-l-analyse-protocolaire-quid-des-flux-cryptes-ssl http://www.legalis.net/?page=jurisprudence-decision&id_article=1182 Le problème de l'interception SSL que tous les acteurs offrent dorenavant dans leurs produits ne semble pas être un problème juridique simple. Florent Nolot Université de Reims Champagne-Ardenne --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [ALERT] IGC/A et google
Le 9 déc. 2013 à 09:54, Fabien Delmotte a écrit : >> Personne n'a dit que cela ne marchait pas. C'est la moralité de ce >> détournement qui était en cause. > > Mon propos était de dire que si il y a eu detection c’est que > l’implementation au niveau technique n’était pas bonne. > > 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 matin !!! Je ne comprend pas comment connaitre le contenu des échanges Facebook peux aider à réduire le trafic ! à la rigueur bloquer le trafic, mais casser SSL pour ça ! > > Trop de contrôle c'est la dictature mas pas de contrôle c’est le borde……. Trop de contrôle commence toujours avec un peu de contrôle sans règles. Kavé Salamatian > > Cordialement > > Fabien > > Le 8 déc. 2013 à 23:10, Stephane Bortzmeyer a écrit : > >> 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
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 matin !!! > > Trop de contrôle c’est la dictature mas pas de contrôle c’est le borde……. Pourquoi décortiquer des paquets à l’aide de MITM dans ce cas précis ? Il suffit de bloquer si il n’y a pas d’utilisation pro, tout simplement … 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. Mathieu --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [ALERT] IGC/A et google
> Personne n'a dit que cela ne marchait pas. C'est la moralité de ce > détournement qui était en cause. Mon propos était de dire que si il y a eu detection c’est que l’implementation au niveau technique n’était pas bonne. 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 matin !!! Trop de contrôle c'est la dictature mas pas de contrôle c’est le borde……. Cordialement Fabien Le 8 déc. 2013 à 23:10, Stephane Bortzmeyer a écrit : > 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/
