Re: [FRnOG] [TECH] Re: RFC 8404: Effects of Pervasive Encryption on Operators

[Jean-Francois Billaud]

On 26/11/2018 08:08, Xavier Beaudouin wrote:

>> Je plussoie : j'ai tellement de warnings que le certificate est pas bon 
>> qu'on ne
>> regarde même plus; en plus maintenant avec les certificats limités à 2 and 
>> pour
>> les publics, çà devient un travail à plein temps rien que pour renouveler ces
>> trucs

>>> Donc tant qu'on ne pourras pas faire facilement "letsencrypt fout moi ton 
>>> certif
>>> sur cet netgear/juncisco/huatik/..." alors voila...

S'il y a des trucs merdiques dans les réseaux, c'est un peu parce qu'il y a des 
gens
qui en vendent, et beaucoup parce qu'il y a d'autres gens qui en achètent (le 
plus
souvent pas ceux qui travaillent avec).

>> La meilleure chance d'avoir un MITM qui marche, d'avoir tellement de 
>> certificats
>> incorrects que tout le monde s'en fout.

> Et bien là on est bien partit pour... Je passe mon temps a faire accept et 
> oublie que
> l'effet "positif" des trucs en chiffré est en fait de la poudre aux yeux.

Il ne faut pas croire les vendeurs. HTTPS ne garantit pas grand chose si on ne 
l'intègre
pas dans une infrastructure avec CAA, CT, preload, DANE etc.

> Donc à force, il est clair qu'un jour, un opérateur vas se faire 0wn3d par un 
> MiTM à cause
> de ces conneries (interface equiment réseau, ipmi, applet java ikvm non 
> signée, ...),
> clairement on arrive donc a saturation et on ne lis plus ces warnings...

Avec un rapport d'incident public honnête et détaillé pour que ça serve de 
leçon.

J.-F. B.

-- 
If you think the problem is bad now, just wait until we've solved it.
-- Arthur Kasspe


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

[FRnOG] [TECH] Re: RFC 8404: Effects of Pervasive Encryption on Operators

[Xavier Beaudouin]

Hello Michel,

(...)

> Je plussoie : j'ai tellement de warnings que le certificate est pas bon qu'on 
> ne
> regarde même plus; en plus maintenant avec les certificats limités à 2 and 
> pour
> les publics, çà devient un travail à plein temps rien que pour renouveler ces
> trucs
> 
>> Donc tant qu'on ne pourras pas faire facilement "letsencrypt fout moi ton 
>> certif
>> sur cet netgear/juncisco/huatik/..." alors voila...
> 
> La meilleure chance d'avoir un MITM qui marche, d'avoir tellement de 
> certificats
> incorrects que tout le monde s'en fout.

Et bien là on est bien partit pour... Je passe mon temps a faire accept et 
oublie que
l'effet "positif" des trucs en chiffré est en fait de la poudre aux yeux.

Donc à force, il est clair qu'un jour, un opérateur vas se faire 0wn3d par un 
MiTM à cause 
de ces conneries (interface equiment réseau, ipmi, applet java ikvm non signée, 
...), 
clairement on arrive donc a saturation et on ne lis plus ces warnings... 

Bref, en voulant faire du bien a MMe Michu on a rendu les systèmes plus 
vulnérables. Sans
compter le pain in the ass quand on a un reseau qui est un peu de mauvaise 
qualité, d'accèder
a des informations qui n'ont pas vraiment besoin d'être chiffrées (et aussi le 
fait qu'un 
squid ne cache presque plus rien dans un reseau d'entreprise).

J'irais même plus loin, il est fort probable que l'emprunte carbone (et autre) 
des réseaux
a augmenté car on en peux plus rien cacher et donc 5 users qui vont sur le même 
site = 5 fois 
les mêmes objets téléchargés... #fail.

Voila, voila
/xavier


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

Re: [FRnOG] [TECH] fibre

[Ge DUPIN]

> Le 25 nov. 2018 à 23:28, Mathieu HUSSON  a 
> écrit :
> 
> Au passage, si vous allez chez les principaux opérateurs, la probabilité est 
> très forte que leur produit vienne de chez nous.

LOL
GD


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

RE: [FRnOG] [TECH] fibre

[Mathieu HUSSON]

Désolé pour ma réponse tardive, j'étais absent.

Le principal contributeur de la perte lors d'une soudure (outre la qualité de 
la soudeuse) est le fait que les cœurs soient désalignés ou qu'ils aient des 
diamètre de champ de mode différents.
Le 2ème est la forme des cœurs. C'est là qu'il faut de bonnes machines de 
soudure qui soient capables de chauffer à différentes températures selon la 
fibre, et d'adapter leur mode de fusion. D'autant plus que les fabricants 
eux-mêmes ont fait évoluer leur design de fibre.

Voici ce que dit la norme : (définie à 1310nm) :
G652D: MFD : 8.6-9.2µm avec une tolérance de +/- 0.4µm
G657A: MFD: idem
G657B: MFD : idem - mais au départ, on descendait à 6.3µm, ce qui les rendait 
non compatible.

Donc la norme n'indique pas grand-chose, tant elle est large.
Si on prend le cas extrême avec une fibre de cœur 8.2µm, et une autre de 9.6µm, 
on a une perte supplémentaire de  ~0,2dB.
Ce cas est très peu probable quand on connait la réalité. Il faudrait que je 
fasse un calcul précis, mais on ne doit pas être loin d'avoir autant de chance 
de gagner au loto.

En réalité, les largeurs de cœur en G652D sont largement autour de 9.2µm, 
tandis que en 657A2, autour de 8.6µm.
Cela donne une perte minimum supplémentaire de 0.02dB [seulement].
Dessus s'ajoute la capacité de la machine à les souder correctement. On voit 
bien la différence entre les différents types de fibre et leur forme de dopant.
Au passage, si vous allez chez les principaux opérateurs, la probabilité est 
très forte que leur produit vienne de chez nous.

La norme spécifie que la Fibre B3 créé une perte de 0.15dB sur un rayon de 
courbure de  5mm, vs ~10mm pour de la A2 et 30mm en 652D.
Ces fibres étant plus chers B3>A2>2D, on les utilise là où cela fait sens.
2D = Backbone

En FTTH : débat en ce moment à l'ARCEP pour intégrer la 2D sur la partie 
transport entre le NRO et le Point de Mutualisation. 
(ce qui pour moi fait tout à fait sens techniquement - mais débat qui peut être 
long).
Cela donne :
NRO-PM : A2 (2D en débat)
PM-PBO : A2
PBO-PTO : A2
PTO à l'intérieur de l'appartement vers la box en jarretière B3.

PTO = Prise Terminale Optique
PBO= Point de Branchement Optique



Cordialement,

Mathieu HUSSON
www.infractive.fr

-Message d'origine-
De : Michel Hostettler 
Envoyé : vendredi 16 novembre 2018 12:26 À : Tony BARTHELEMY 
 Cc : Nicolas CORBEL ; 
Mathieu HUSSON ; Ducassou Laurent 
; frnog  Objet : Re: [FRnOG] [TECH] fibre

Bonjour Tony,

"ClearCurve ZBL fiber exceeds the most stringent bend performance requirements 
of ITU-T Recommendation G.652.D and the installed base of SMF-28e® and 
SMF-28e+® fibers".

En effet, les appellations G.652.D, G.657.A2, G.657.B3 ne semblent plus d'une 
quelconque utilité ou valeur.

Pour la fibre ZBL de Corning, on a les rayons de courbure annoncés de B3, soit 
5 mm pour ≤ 0,1 dB sur un tour.

Je n'ai pas encore vu la longueur. Je douterais que l'on puisse atteindre les 
160 km d'un seul tenant.

Merci pour le témoignage,
Cordialement, Michel

- Mail original -
De: "Tony BARTHELEMY" 
À: "Michel Hostettler" , "Nicolas 
CORBEL" 
Cc: "Mathieu Husson" , "Ducassou Laurent" 
, "frnog" 
Envoyé: Vendredi 16 Novembre 2018 10:52:27
Objet: Re: [FRnOG] [TECH] fibre

Bonjour, on est à 0.04/0.05dB de pertes sur la combinaison SMF28 
Ultra/Clearcurve ZBL chez Corning pour ne pas les citer. Ca passe!
On l’a soudée et connectorisée des milliers de fois, ça bouge pas, pas de 
fragilité constatée de notre côté.

Bonne journée, Tony.
-- 


Tony BARTHELEMY
Responsable des ventes/ Sales Manager
2 B LIGHTING TECHNOLOGIES
7 Chemin de Vaubesnard
ZA de Vaubesnard
91410 DOURDAN

Tél: +33 (0) 1 64 59 21 30
Fax: +33 (0) 1 64 59 21 31

tbarthel...@2blighting.com

NOUVEAU: Retrouvez tous nos produits sur notre nouveau site :
www.2blighting.fr 







Le 16/11/2018 12:43, « Michel Hostettler »  a écrit :

>
>A priori, le diamètre du cœur optique, et même le diamètre MFD (de 
>transmission du mode) sont identiques.
>A2, B3 et 2D pourraient être soudées ensemble.
>
>Néanmoins B3 n'est pas faite pour l'environnement opérateur. Elle est 
>limitée en longueur.
>
>Cordialement,Michel
>
>- Mail original -
>De: "Nicolas CORBEL" 
>À: "Michel Hostettler" 
>Cc: "Mathieu Husson" , "Ducassou Laurent"
>, "frnog" 
>Envoyé: Vendredi 16 Novembre 2018 11:27:14
>Objet: Re: [FRnOG] [TECH] fibre
>
>Hello,
>
>Avec la G657B3 tu perds cependant l'avantage qu'ont la G657A2 et la 
>G652D, à savoir qu'elles sont faites pour être soudées ensemble ou je me 
>trompe ?
>
>Nicolas
>
>On Fri, Nov 16, 2018 at 10:37 AM Michel Hostettler < 
>michel.hostett...@telecom-paristech.fr> wrote:
>
>> Bonjour Mathieu,
>>
>> Dans le même sujet.
>>
>> Commercialisez-vous la fibre G.657.B3, cette fois-ci chez le client 
>> (particulier ou entreprise) ?
>> Elle dispose d'un rayon de courbure encore plus faible que A2, mais 
>> devrait être plus fragile.
>>
>> Cordialement, Michel
>>
>> - Mail original 

[FRnOG] [TECH] RE: RFC 8404: Effects of Pervasive Encryption on Operators

[Michel Py]

> Xavier Beaudouin a écrit :
> Je suis assez d'accord, mais d'un autre coté, vu le nombre de fois en tant 
> netops a cliquer sur "taggl je sais
> ce que je fais" quand j'ai un équipement réseau avec une interface à 
> cliquodrome pour gérer le merdier mais avec
> un certif self signé, on voit que la sécurité avec du https partout n'est pas 
> encore optimale. 

Je plussoie : j'ai tellement de warnings que le certificate est pas bon qu'on 
ne regarde même plus; en plus maintenant avec les certificats limités à 2 and 
pour les publics, çà devient un travail à plein temps rien que pour renouveler 
ces trucs

> Donc tant qu'on ne pourras pas faire facilement "letsencrypt fout moi ton 
> certif sur cet netgear/juncisco/huatik/..." alors voila...

La meilleure chance d'avoir un MITM qui marche, d'avoir tellement de 
certificats incorrects que tout le monde s'en fout.

Michel.


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

Re: [FRnOG] [TECH] RFC 8404: Effects of Pervasive Encryption on Operators

[David Ponzone]

1 FF ? Ça va, j’en ai au moins 2 anciens FF pour accéder à je sais plus quelles 
merdouilles de 10 ans d’âge.

A un moment, j’ai tenté de reverse-proxié l’accès à ces merdes mais parfois 
c’est pas possible (ou j’ai pas cherché assez).
Et encore faut-il que le reverse-proxy utilisé n’abandonne pas non plus l’algo 
défaillant.

David Ponzone



> Le 25 nov. 2018 à 18:02, Xavier Beaudouin  a écrit :
> 
> Hello,
> 
>> JFB (pour la fermeture du port 80)
> 
> 
> 
> Je suis assez d'accord, mais d'un autre coté, vu le nombre de fois en tant 
> netops a cliquer sur "taggl je sais ce que je fais" quand j'ai un équipement 
> réseau avec une interface à cliquodrome pour gérer le merdier mais avec un 
> certif self signé, on voit que la sécurité avec du https partout n'est pas 
> encore optimale. 
> 
> Parce que rien n'empêche dans ce cas là d'avoir un MiM qui intercepte le 
> bouzin 
> 
> Donc tant qu'on ne pourras pas faire facilement "letsencrypt fout moi ton 
> certif sur cet netgear/juncisco/huatik/..." alors voila...
> 
> Ah aussi un point "mauvais" élève au fabriquant de boite violettes avec les 
> ssh avec des cypher loose ou uniquement du sslv3, pratique quand on doit 
> avoir chrome pour y accéder car Firefox interdit l'accès. Le jour ou Chrome 
> le fait plus, il vas falloir que je garde un vieux FF dans une VM juste pour 
> configurer un machin ?
> 
> On arrive vite à l'équivalent de IE6 obligatoire d'il y a quelques années (je 
> croyais qu'on allais arrêter ces conneries...), donc le CLI en SSH c'est 
> BIEN. Au moins une fois que tu as accepté la PK du SSH t'es à peu près sûr 
> que c'est le bon équipement...
> 
> 
> 
> 
> /Xavier
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] RFC 8404: Effects of Pervasive Encryption on Operators

[François Raynaud]

Bonsoir,

Pour ajouter un exemple à ce que vous venez de dire, n'oublions pas qu'on
en est toujours là: http://neverssl.com/

Cordialement,
François Raynaud


Le dim. 25 nov. 2018 à 18:03, Xavier Beaudouin  a écrit :

> Hello,
>
> > JFB (pour la fermeture du port 80)
>
> 
>
> Je suis assez d'accord, mais d'un autre coté, vu le nombre de fois en tant
> netops a cliquer sur "taggl je sais ce que je fais" quand j'ai un
> équipement réseau avec une interface à cliquodrome pour gérer le merdier
> mais avec un certif self signé, on voit que la sécurité avec du https
> partout n'est pas encore optimale.
>
> Parce que rien n'empêche dans ce cas là d'avoir un MiM qui intercepte le
> bouzin
>
> Donc tant qu'on ne pourras pas faire facilement "letsencrypt fout moi ton
> certif sur cet netgear/juncisco/huatik/..." alors voila...
>
> Ah aussi un point "mauvais" élève au fabriquant de boite violettes avec
> les ssh avec des cypher loose ou uniquement du sslv3, pratique quand on
> doit avoir chrome pour y accéder car Firefox interdit l'accès. Le jour ou
> Chrome le fait plus, il vas falloir que je garde un vieux FF dans une VM
> juste pour configurer un machin ?
>
> On arrive vite à l'équivalent de IE6 obligatoire d'il y a quelques années
> (je croyais qu'on allais arrêter ces conneries...), donc le CLI en SSH
> c'est BIEN. Au moins une fois que tu as accepté la PK du SSH t'es à peu
> près sûr que c'est le bon équipement...
>
>
> 
>
> /Xavier
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] RFC 8404: Effects of Pervasive Encryption on Operators

[Xavier Beaudouin]

Hello,

> JFB (pour la fermeture du port 80)



Je suis assez d'accord, mais d'un autre coté, vu le nombre de fois en tant 
netops a cliquer sur "taggl je sais ce que je fais" quand j'ai un équipement 
réseau avec une interface à cliquodrome pour gérer le merdier mais avec un 
certif self signé, on voit que la sécurité avec du https partout n'est pas 
encore optimale. 

Parce que rien n'empêche dans ce cas là d'avoir un MiM qui intercepte le 
bouzin 

Donc tant qu'on ne pourras pas faire facilement "letsencrypt fout moi ton 
certif sur cet netgear/juncisco/huatik/..." alors voila...

Ah aussi un point "mauvais" élève au fabriquant de boite violettes avec les ssh 
avec des cypher loose ou uniquement du sslv3, pratique quand on doit avoir 
chrome pour y accéder car Firefox interdit l'accès. Le jour ou Chrome le fait 
plus, il vas falloir que je garde un vieux FF dans une VM juste pour configurer 
un machin ?

On arrive vite à l'équivalent de IE6 obligatoire d'il y a quelques années (je 
croyais qu'on allais arrêter ces conneries...), donc le CLI en SSH c'est BIEN. 
Au moins une fois que tu as accepté la PK du SSH t'es à peu près sûr que c'est 
le bon équipement...




/Xavier


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

Re: [FRnOG] [TECH] RFC 8404: Effects of Pervasive Encryption on Operators

[Jean-Francois Billaud]

On 23/11/2018 21:19, Stephane Bortzmeyer wrote:

> La vie privée sur l'Internet fait aujourd'hui l'objet d'innombrables
> attaques et l'une des techniques de défense les plus efficaces contre
> ces attaques est le chiffrement des données. Il protège également
> contre une autre menace, la modification des données en transit, comme
> le font certaines FAI. Il y a de nombreuses campagnes de
> sensibilisation pour promouvoir le chiffrement , avec des bons
> résultats. Évidemment, ce chiffrement gène ceux qui voudraient
> espionner et modifier le trafic, et il fallait donc s'attendre à voir
> une réaction. Ce RFC est l'expression de cette réaction, du côté de
> certains opérateurs réseaux, qui regrettent que le chiffrement empêche
> leurs mauvaises pratiques.
> 
> https://www.bortzmeyer.org/8404.html

En attendant la disparition complète des protocoles non chiffrés :
https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-01
Deprecating TLSv1.0 and TLSv1.1
draft-ietf-tls-oldversions-deprecate-01
K. Moriarty - S. Farrell

Ça serait aussi une bonne idée que l'ANSSI mette son guide à jour :
https://www.ssi.gouv.fr/uploads/2016/09/guide_tls_v1.1.pdf
(ajout de TLSv1.3, X25519, CHACHA20, suppression de brainpool, camellia, aria)


JFB (pour la fermeture du port 80)

-- 
If you think the problem is bad now, just wait until we've solved it.
-- Arthur Kasspe


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