Auteur Sujet: Chiffrement 802.1AE sur les liens intercontinentaux pour contrer la NSA  (Lu 10077 fois)

0 Membres et 1 Invité sur ce sujet

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 092
  • Paris (75)
Chiffrement 802.1AE sur les liens intercontinentaux pour contrer la NSA
« Réponse #12 le: 09 novembre 2013 à 19:01:47 »
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.

Optrolight

  • Client Orange Fibre
  • Modérateur
  • *
  • Messages: 4 673
  • Grenoble (38) @Optrolight
    • Optroastro
Chiffrement 802.1AE sur les liens intercontinentaux pour contrer la NSA
« Réponse #13 le: 09 novembre 2013 à 19:03:51 »
Pourquoi vouloir passer testdebit.info en https?

vivien

  • Administrateur
  • *
  • Messages: 47 240
    • Twitter LaFibre.info
Chiffrement 802.1AE sur les liens intercontinentaux pour contrer la NSA
« Réponse #14 le: 09 novembre 2013 à 21:55:15 »
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)

corrector

  • Invité
SSH != SSL
« Réponse #15 le: 09 novembre 2013 à 22:08:03 »
sftp au lieu de ftp
Attention : SFTP = 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 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, 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).
« Modifié: 09 juin 2014 à 02:09:15 par corrector »

corrector

  • Invité
Chiffrement 802.1AE sur les liens intercontinentaux pour contrer la NSA
« Réponse #16 le: 09 novembre 2013 à 22:36:55 »
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) ou bien le plus moderne GCM (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

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.
« Modifié: 09 juin 2014 à 02:09:38 par corrector »

corrector

  • Invité
Chiffrement 802.1AE sur les liens intercontinentaux pour contrer la NSA
« Réponse #17 le: 09 novembre 2013 à 22:48:44 »
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.

Thibault

  • AS2027 MilkyWan + Client K-Net
  • Modérateur
  • *
  • Messages: 2 030
  • BBox FTTH Lyon & FTTH K-net Cormoranche S/S
Chiffrement 802.1AE sur les liens intercontinentaux pour contrer la NSA
« Réponse #18 le: 10 novembre 2013 à 00:55:24 »
Sur un RPi, on le voit bien :
transfert SFTP : 4 mo/s
transfert FTP : 11 mo/s (limite par le port réseau)

corrector

  • Invité
Chiffrement 802.1AE sur les liens intercontinentaux pour contrer la NSA
« Réponse #19 le: 10 novembre 2013 à 01:11:51 »
Quel chiffrement? Quel logiciel serveur? Quel processeur?

Thibault

  • AS2027 MilkyWan + Client K-Net
  • Modérateur
  • *
  • Messages: 2 030
  • BBox FTTH Lyon & FTTH K-net Cormoranche S/S
Chiffrement 802.1AE sur les liens intercontinentaux pour contrer la NSA
« Réponse #20 le: 10 novembre 2013 à 01:17:05 »
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.

corrector

  • Invité

Thibault

  • AS2027 MilkyWan + Client K-Net
  • Modérateur
  • *
  • Messages: 2 030
  • BBox FTTH Lyon & FTTH K-net Cormoranche S/S
Chiffrement 802.1AE sur les liens intercontinentaux pour contrer la NSA
« Réponse #22 le: 10 novembre 2013 à 01:30:40 »
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/
« Modifié: 10 novembre 2013 à 01:51:28 par TitiDu01 »

corrector

  • Invité
SSH
« Réponse #23 le: 10 novembre 2013 à 01:32:18 »
RFC 4253 - The Secure Shell (SSH) Transport Layer Protocol

6.3.  Encryption

   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
« Modifié: 09 juin 2014 à 02:10:31 par corrector »