La Fibre
Télécom => Réseau => 
Protocoles réseaux sécurisés (https) => Discussion démarrée par: Bensay le 07 novembre 2013 à 18:44:47
-
Pour le chiffrement de l’Ethernet filaire c'est 802.1AE plus connu sous le nom de MACsec, qui est a utiliser en complèment de 802.1x pour l’authentification. Je n'ai jamais eu l'occasion de le mettre en place, mais il doit avoir la cote sur les liaisons intercontinentale en ce moment ;)
Bonsoir Krtman,
Pourrais tu préciser pour le passage "coté" sur les lien Intercontinentaux ?
Cdt
Bensay
-
Bensay,
On a désormais la preuve que la NSA a intercepté des dark fiber de Google.
Ce qui devrait pousser les sociétés à déployer du chiffrements sur tous les liens inter-DC.
ps: A chaque RMLL, je voyais des équipements de chiffrement line-rate dans les DC des universités hôtes et je ne comprenais pas pourquoi les DSI en achetait car cela semblait overkill.
Maintenant, je comprends mieux et je soupçonne que c'était un ordre des services de contre-renseignement ...
-
On a désormais la preuve que la NSA a intercepté des dark fiber de Google.
Quelqu'un sait comment ils ont pu "intercepter" des fibres inter-DC car je vois pas comment en pratique ca se fait...
Faut deja se 'brancher" physiquement (ou?, comment?) puis transporter (idem) ce qu'on écoute et ensuite le stocker (ou l'analyser en temps reel).. vu le volume inter-DC chez Google en plus.
-
Quelqu'un sait comment ils ont pu "intercepter" des fibres inter-DC car je vois pas comment en pratique ca se fait...
Faut deja se 'brancher" physiquement (ou?, comment?) puis transporter (idem) ce qu'on écoute et ensuite le stocker (ou l'analyser en temps reel).. vu le volume inter-DC chez Google en plus.
comme ca :
https://en.wikipedia.org/w/index.php?title=File:SER_klein_exhibits.djvu&page=9 (https://en.wikipedia.org/w/index.php?title=File:SER_klein_exhibits.djvu&page=9)
-
Pourrais tu préciser pour le passage "coté" sur les lien Intercontinentaux ?
C’était de l'ironie, et comme l'a dit thenico certains services de renseignement interceptent les communications et cela ne s’arrête pas aux communications entre DC. Ils ne monitor pas seulement internet, c'est aussi le cas pour les réseaux fermés. Ceux des opérateurs, et par conséquence les réseaux privés de leurs clients. Il y a l'exemple des liens inter DC (http://www.itespresso.fr/nsa-pratique-espionnage-transatlantique-google-yahoo-69501.html) de Google et Yahoo, ou du réseau interbancaire Swift (http://www.silicon.fr/prism-les-etats-unis-lecoute-transactions-bancaires-89365.html), et probablement bien d'autres. Et quant on voit les précautions (http://www.lemonde.fr/technologies/article/2013/08/09/deux-groupes-de-telecommunications-indiens-collaborent-a-la-surveillance-des-americains_3459778_651865.html) qu'ils prennent avec les opérateurs étrangers, ça en dit long sur ce que eux doivent faire.
ps: A chaque RMLL, je voyais des équipements de chiffrement line-rate dans les DC des universités hôtes et je ne comprenais pas pourquoi les DSI en achetait car cela semblait overkill.
Maintenant, je comprends mieux et je soupçonne que c'était un ordre des services de contre-renseignement ...
Des équipements de ce genre la (http://www.thales-esecurity.com/products-and-services/products-and-services/network-encryption-appliances) ?
Quelqu'un sait comment ils ont pu "intercepter" des fibres inter-DC car je vois pas comment en pratique ca se fait...
Faut deja se 'brancher" physiquement (ou?, comment?) puis transporter (idem) ce qu'on écoute et ensuite le stocker (ou l'analyser en temps reel).. vu le volume inter-DC chez Google en plus.
Et bien ils mettent des TAPs (https://lafibre.info/images/wireshark/201006_capture_trafic_tap_demystifie.ppt) sur les fibres optiques, avec l'accord des opérateurs télécoms.
(https://lafibre.info/images/wireshark/201006_capture_trafic_tap_demystifie.png) (https://lafibre.info/images/wireshark/201006_capture_trafic_tap_demystifie.ppt)
Et ces derniers se refuse a parler car tout cela est probablement classé secret défense, et ils s'exposeraient a des poursuites s'ils le faisaient (voir le cas Lavabit (http://www.zdnet.fr/actualites/messageries-chiffrees-lavabit-et-silent-circle-se-sabordent-pour-proteger-edward-snowden-39793103.htm), etc). Ou bien a minima a une très mauvaise publicité.
Cela faisait longtemps que ça se savait. La première preuve et arrivé par un ancien employé d'AT&T (Mark Klein (http://www.wired.com/threatlevel/2013/06/nsa-whistleblower-klein/) cité plus haut), qui a eu accès a une salle d'interception. Il a noté les modèles d'équipements utilisés. Les détailles techniques sont ici (http://www.wired.com/science/discoveries/news/2006/05/70908). Il y avait des splitters optique, l'équipement clé qui analyse le trafic est un Narus STA 6400, des routeurs Juniper, des serveurs SUN. L'affaire de la Spy room chez AT&T et bien antérieur a Prism, depuis, il y a eu les révélation de Snowden, mais pour le moment et a ma connaissance aucun document sur les produits utilisés par la NSA n'a été publié. On sait juste que la NSA a dépensé des millions en 2009 pour moderniser ses stations (http://www.corpwatch.org/article.php?id=15862). Glimmer Glass est par contre soupçonné d'avoir fourni la NSA.
-
Des équipements de ce genre la (http://www.thales-esecurity.com/products-and-services/products-and-services/network-encryption-appliances) ?
C'est plutot celui-là (https://www.thalesgroup.com/en/content/layer-3-vpn-ip-security-mistral-datacryptor-ap) le plus connu (Mistral). C'est meme utilisé dans les boites de jeux videos...
Le chiffrement d'artère est devenu un peu désuet dans le monde WAN, le chiffrement au niveau IP est plus pratique (soit via encapsulation dans un tunnel IPSec, soit par chiffrement du champ data).
Edit: fiche d'identité sur l'ANSSI (http://www.ssi.gouv.fr/fr/produits-et-prestataires/produits-qualifies/p_25_Boitier_MISTRAL_TRC_7535_version_4.5.2.2.html)
-
le mistral c'est du layer 3.
les fournisseurs comme ADVA proposent des équipements de transmission optiques ou la liaison est chiffrée au niveau le plus bas.
-
C'est ce que l'on appel le chiffrement d'artère. L'inconvénient est que cela ne fonctionne qu'en point-à-point sur certains types de transport et que cela peut te masquer les problèmes de liaison.
Le chiffrement L3 est plus intéressant car tu gardes le controle au niveau liaison, tu peux en utiliser pleins de différentes et ça fonctionne en multi-point -> réduction du nombre d'équipements de chiffrement.
Le truc dommage avec MacSEC est qu'il ne fonctionne qu'entre la carte réseau et le switch, du coup ça réduit l'intéret.
-
Je préfère le chiffrement des couches hautes, cela permet du bout en bout (https au lieu de http, sftp au lieu de ftp, ssh au lieu de telnet, ect...)
Je vais d'ailleurs proposer de tester son débit en https dans quelques semaines sur https://testdebit.info (https://testdebit.info)
-
Disons que l'avantage avec un matériel de chiffrement dédié est que cela te sert de barrière car tout flux entrant est déchiffré (sauf en IPSec évidemment) : si t'essayes d'envoyer du trafic, en sortie ça fera de la bouillie :)
Tu vas utiliser une carte SSL sur ton serveur testdebit ?
Tiens d'ailleurs, ça manque sur les cartes réseaux, obligé de passer par une carte dédiée...
-
Cela prend tant de ressources que ça ?
Le fait d'avoir passé lafibre.info en https c'est passé de façon indolore sur la charge CPU.
J'arrive à monter à 1 Gb/s il me semble avec des échanges en SFTP.
-
1Gb/s en SFTP c'est pas mal. Il me semble que https est un peu plus lourd. En fait lafibre.info en terme de débit ça doit pas voler haut donc en software le ssl ça se gère facilement. J'ai un autre cas en software où le site ne génère qu'entre 2 et 10Mb de bande passante. Par contre, pour du test de débit, ça risque de commencer à faire mal, surtout vu la population de ce forum qui aime bien se la mesurer tous les matins (comment ça je suis aigri parce que je n'ai que 6Mb ? meuuuh noooon).
-
avec l'accord des opérateurs télécoms.
Ah c'est l'élèment clé qui me manquait et il est central a tout ce débat actuel sur la NSA et ses écoutes.
Et pourtant aucun journaliste ne se fait l'écho du rôle des opérateurs dans l'histoire.
-
Pourquoi vouloir passer testdebit.info en https?
-
Pourquoi vouloir passer testdebit.info en https?
Proposer de télécharger des fichiers en https (ce qui permet de voir facilement un bridage comme celui mis en place dans le passé par FreeMobile sur le https)
-
sftp au lieu de ftp
Attention : SFTP = SSH File Transfer Protocol (https://fr.wikipedia.org/wiki/SSH_File_Transfer_Protocol), schéma d'URL en sftp:. C'est une partie du protocole SSH qui permet de manipuler des fichiers et non d'ouvrir un shell. (Ce n'est pas une surcouche de SSH, c'est bien une fonction intégrée du protocole. (Les premières versions de scp implèmentaient le protocole SCP qui est une surcouche de SSH (en fait ils lançaient un processus SCP via le shell distant) mais maintenant scp utilise le protocole de transfert de fichiers de SSH, qui ne lance aucun processus en plus du processus serveur ssh acceptant.))
C'est un protocole mono-TCP qui ne pose pas de problème particulier avec les pare-feux et les NAT.
Tu voulais sans doute parler de FTP/SSL (https://fr.wikipedia.org/wiki/File_Transfer_Protocol_over_SSL) qui correspond aux schémas d'URL ftps://, ftpes://, et ftp://. Ce protocole hérite bien sûr de toutes les tares originelles de FTP, protocole bâtard, à la conception simpliste, dont une flopée d'amélioration ont tenté de palier les défauts. (Donc quand on dit que FTP est supporté, il faudrait toujours préciser quel dialecte est supporté.)
FTP est un protocole multi-TCP (séparant le TCP de contrôle et les TCP pour les charges utiles), ce qui fait qu'il ne passe pas les pare-feux bloquant les connexions entrantes dans le mode originel (mode actif), ni les NAT (quelle qu'en soit la forme : 1-à-1 sans état, 1-à-n avec état...), sauf présence d'un composant logiciel spécialisé (présent dans la plupart (toutes?) les box), ce qui est exclus par la sécurisation de la connexion de données.
SSH n'a aucun lien avec SSL/TLS. Le format des paquets, l'organisation en couches, tout est différent. SSH propose aussi un multiplexage (Channel Mechanism (https://tools.ietf.org/html/rfc4254#section-5), permettant de gérer de façon automatique le forwarding X/Windows par exemple) qui n'a aucun équivalent en SSL/TLS : pour avoir plusieurs tunnels sécurisés, on doit ouvrir plusieurs connexions TCP.
Les garanties de sécurité implèmentées par SSH et SSL/TLS sont les mêmes :
- authentification du serveur
- (en option) authentification du client (par clef)
- secret des données
- intégrité
- perfect forward secrecy (en option pour SSL/TLS)
Le protocole SSL n'intègre pas une PKI donnée, mais les outils utilisant SSL, si. SSL est utilisable avec un système de vérification des clefs publiques quelconque, ou même aucune vérification si ce n'est pas jugé pertinent (p.ex. le GoogleBot).
-
Il me semble que https est un peu plus lourd.
Quoi est plus lourd que quoi?
Ce type d'assertion sur HTTPS n'a pas vraiment de sens. Selon que tu proposes RC4, 3DES, AES-128, AES-256, Camelia, selon que le mode de chainage est un très classique CBC (Cipher-Block Chaining) (https://en.wikipedia.org/wiki/Cipher_block_chaining#Cipher-block_chaining_.28CBC.29) ou bien le plus moderne GCM (Galois/Counter_Mode) (https://en.wikipedia.org/wiki/Galois/Counter_Mode), selon que processeur propose des instructions spécialisées ou non, la charge CPU n'aura rien à voir!
WP : AES instruction set (https://en.wikipedia.org/wiki/AES_instruction_set)
Advanced Encryption Standard (AES) Instruction Set (or the Intel Advanced Encryption Standard (AES) New Instructions (AES-NI)) is an extension to the x86 instruction set architecture for microprocessors from Intel and AMD proposed by Intel in March 2008.[1] The purpose of the instruction set is to improve the speed of applications performing encryption and decryption using the Advanced Encryption Standard (AES).
Instruction Description
AESENC Perform one round of an AES encryption flow
AESENCLAST Perform the last round of an AES encryption flow
AESDEC Perform one round of an AES decryption flow
AESDECLAST Perform the last round of an AES decryption flow
AESKEYGENASSIST Assist in AES round key generation
AESIMC Assist in AES Inverse Mix Columns
PCLMULQDQ Carryless multiply (CLMUL).
sur certains processeurs Intel et AMD (https://en.wikipedia.org/wiki/AES_instruction_set#Supporting_CPUs).
-
Cela prend tant de ressources que ça ?
Moins que la plupart des gens ne s'imaginent.
Le fait d'avoir passé lafibre.info en https c'est passé de façon indolore sur la charge CPU.
Pour un site dynamique comme un forum, la charge CPU est liée aux nombreuses requêtes SQL nécessaires pour générer une page, donc la charge supplèmentaire de SSL est presque négligeable.
Pour un test de débit, ou n'importe quel site entièrement statique, c'est différent.
-
Sur un RPi, on le voit bien :
transfert SFTP : 4 mo/s
transfert FTP : 11 mo/s (limite par le port réseau)
-
Quel chiffrement? Quel logiciel serveur? Quel processeur?
-
Quel chiffrement?
Aucune idée, ceux par default, j'ai rien modifié je fais les transferts avec filezilla.
Quelle implèmentation?
??
Quel processeur?
Serveur : Rpi modèle B
Client : I7 4 cœurs à 3.4GHz.
-
??
Quel logiciel serveur?
Client : I7 4 cœurs à 3.4GHz.
Supporte AES-NI :)
http://software.intel.com/en-us/node/256280#intel-aes-ni (http://software.intel.com/en-us/node/256280#intel-aes-ni)
-
Ba pour le SFTP il n'y a rien besoin si ? Le serveur SSH suffit et c'est celui de base dans raspbian.
Pour le serveur FTP c'est pure-ftpd.
Processeur le voilà exactement : http://ark.intel.com/fr/products/65719/ (http://ark.intel.com/fr/products/65719/)
-
RFC 4253 - The Secure Shell (SSH) Transport Layer Protocol
6.3. Encryption (https://tools.ietf.org/html/rfc4253#section-6.3)
An encryption algorithm and a key will be negotiated during the key
exchange. When encryption is in effect, the packet length, padding
length, payload, and padding fields of each packet MUST be encrypted
with the given algorithm.
The encrypted data in all packets sent in one direction SHOULD be
considered a single data stream. For example, initialization vectors
SHOULD be passed from the end of one packet to the beginning of the
next packet. All ciphers SHOULD use keys with an effective key
length of 128 bits or more.
The ciphers in each direction MUST run independently of each other.
Implementations MUST allow the algorithm for each direction to be
independently selected, if multiple algorithms are allowed by local
policy. In practice however, it is RECOMMENDED that the same
algorithm be used in both directions.
The following ciphers are currently defined:
3des-cbc REQUIRED three-key 3DES in CBC mode
blowfish-cbc OPTIONAL Blowfish in CBC mode
twofish256-cbc OPTIONAL Twofish in CBC mode,
with a 256-bit key
twofish-cbc OPTIONAL alias for "twofish256-cbc"
(this is being retained
for historical reasons)
twofish192-cbc OPTIONAL Twofish with a 192-bit key
twofish128-cbc OPTIONAL Twofish with a 128-bit key
aes256-cbc OPTIONAL AES in CBC mode,
with a 256-bit key
aes192-cbc OPTIONAL AES with a 192-bit key
aes128-cbc RECOMMENDED AES with a 128-bit key
serpent256-cbc OPTIONAL Serpent in CBC mode, with
a 256-bit key
serpent192-cbc OPTIONAL Serpent with a 192-bit key
serpent128-cbc OPTIONAL Serpent with a 128-bit key
arcfour OPTIONAL the ARCFOUR stream cipher
with a 128-bit key
idea-cbc OPTIONAL IDEA in CBC mode
cast128-cbc OPTIONAL CAST-128 in CBC mode
none OPTIONAL no encryption; NOT RECOMMENDED
-
Ba pour le SFTP il n'y a rien besoin si ? Le sereur SSH suffit et c'est celui de base dans raspbian.
Oui, c'est bien du serveur SSH dont je parle.
Peux-tu te connecter en SSH en mode bavard (-v)?
Que contiennent /etc/ssh/ssh_config et ~/.ssh/config?
-
Il me semble que c'est OpenSSH.
Sinon pour les fichiers:
/etc/ssh/ssh_config
# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.
# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.
# Site-wide defaults for some commonly used options. For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.
Host *
# ForwardAgent no
# ForwardX11 no
# ForwardX11Trusted yes
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# GSSAPIKeyExchange no
# GSSAPITrustDNS no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
# Protocol 2,1
# Cipher 3des
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
~/.ssh/config
N’existe pas !
-
/etc/ssh/ssh_config
# Protocol 2,1
# Cipher 3des
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
Tu peux utiliser scp -c CHIFFRE pour sélectionner une méthode de chiffrement.
-
Quoi est plus lourd que quoi?
Que pour du débit brut, https est plus lourd qu'un SFTP. 'ttention, j'ai dit il me semble.
sur certains processeurs Intel et AMD (https://en.wikipedia.org/wiki/AES_instruction_set#Supporting_CPUs).
J'ai un Core i7 Westmere, y'a pas AES.
-
Pour LaFibre.info, le processeur gère bien AES :
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
Les infos compètes via cat /proc/cpuinfo :
processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Xeon(R) CPU E31230 @ 3.20GHz
stepping : 7
microcode : 0x25
cpu MHz : 1600.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 3
cpu cores : 4
apicid : 7
initial apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips : 6385.41
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
-
@Corrector : Tu veux que je fasse un test avec tous ?
Tu peux utiliser scp -c CHIFFRE pour sélectionner une méthode de chiffrement.
-
Lors du passage de GMail en HTTPS en 2010 les changements constatés étaient (https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html):
moins de 1% cpu load
moins de 10KB de mémoire consommée par connexion
moins de 2% de traffic réseau
Le plus gros du boulot a lieu a l'ouverture de connexion et est fait pas le client.
-
@Corrector : Tu veux que je fasse un test avec tous ?
Pas avec ceux qui sont overkill! (AES-256 n'a pas de justification.)
Juste AES-128 et ARC4.
-
Pour LaFibre.info, le processeur gère bien AES :
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
Mais https://lafibre.info/ propose RC4_128.
-
Merci à tous pour ces infos ;),
Topic fort intéressant ma fois.
Cdt
Bensay
-
Mais https://lafibre.info/ propose RC4_128.
Maintenant c'est du AES-128 en GCM (galois counter mode).
OpenSSL utilise bien les instructions AES et PCLMULQDQ?