Des rappels salvateurs sur TLS.

Rien d'innovant, juste des rappels essentiels de choses trop souvent oubliées :
  - Écouter les communications qui passent sur un réseau, c'est facile, quelles que soient les technos utilisées à tous les niveaux (physique, logique, logiciels, ...) ;

  - Attaques passives/actives ;

  - Confidentialité implique authentification *surtout* si l'attaquant est actif ;

  - TLS protège en transit mais ne protège pas contre des extrémités corrompues. Exemples : malwares, PRISM ;
 
  - Le modèle de sécurité x509 est vaseux. Exemples : n'importe quelle AC peut signer n'importe quelle clé publique qui revendique tel nom ; Vague de piratages en 2011 ;

  - Fonctions des librairies standards de certains langages mal conçues qui débrayent la sécurité (authentification) par défaut. Exemples : python, php/curl ;

- API complexes, documentation mal fichue. Les premières aides qu'on trouve (sur SO par exemple) expliquent systématiquement comment débrayer la sécurité sans l'indiquer clairement. Comment le dev' dont la sécurité n'est pas le domaine de compétence peut-il s'en rendre compte ?

  - Mauvaises pratiques côté développeurs :
    - Les tests valident uniquement les cas normaux donc la sécurité fonctionne forcément. Il faut tester des scénarios d'attaque et vérifier que la sécurité fonctionne toujours. C'est pas simple à mon avis : quels cas teste-t-on ? Quels sont ceux qui se produisent le plus en situation réelle ? Comment intégrer ça dans les délais de coding/intégration déjà serrés au maximum ?

    - Débrayer la sécurité en phase de développement pour ne pas se prendre la tête ... et oublier de réactiver ladite sécurité dans la version finale livrée.

   - Plutôt que de chercher à protéger des énormes volumes de données, pourquoi ne pas plutôt collecter que le strict minimum nécessaire à la fourniture de la prestation ?