[Edit : cette conversation a été déplacée depuis le sujet « piratage TV5 »]

les TV n'ont pas pris les meme précautions que les banques pour sécuriser leurs infra,

LOL.
On pourrait parler longtemps de la sécurité des banques et assurances françaises.
Pour avoir eu des potes stagiaires en trading dans diverses banques, nombreuses étaient celles encore sous XP l'été dernier sur des postes reliés à Internet, avec un compte utilisateur pour toute l'équipe dont le mdp était affiché sur un mur...
C'est marrant de voir la chaîne de certification SSL de la Sogé sur le site des clients : l'algo AES_256_CBC, c'est cassé très rapidement aujourd'hui...
En fait, c'est même marrant de voir les procédures qu'ils ont avec leurs clients. La sécurité n'est juste absolument pas prise en compte dans leur façon de travailler.

Je prends cet exemple mais il y en a bien d'autres. Et les hackers le savent déjà très bien.

Pas compris le rapport entre les certificats SSL de la Soc Gen et AES256. Quand à la fragilité de ce dernier...

Comparaison d'un forum avec un site destiné à l'accès aux comptes bancaires de professionnels (c'est kifkif sur entreprises.societegenerale.fr) :

Les connexions sont avec un navigateur moderne et performant en matière de sécurisation du transport : Google Chrome.

lafibre.info

• Certificat :
  
  • signature du certificat par sha256RSA
    c'est à dire
    condensat du certificat par sha256       BON!
    signature par RSA
    
  • clé publique RSA 4096 bits     EXCELLENT!
    
• Connexion au serveur :
  
  protocole TLS 1.2          EXCELLENT!
  
  
  • protocole d'échange de clé ECDHE_RSA               EXCELLENT!
    c'est à dire :
    communication de la clé privée par elliptic curve diffie-hellman
    authentification du serveur par RSA
    
    
  • sécurisation des messages par AES_128_GCM
    c'est à dire :
    chiffrement symétrique : AES-128
    enchaînement et contrôle d'intégrité fournit par l'utilisation de Galois/Counter Mode
    

https://professionnels.societegenerale.fr/

• Certificat :
  
  • signature du certificat par sha1RSA
    c'est à dire
    condensat du certificat par sha1       PAS BON!!!
    signature par RSA
    
  • clé publique RSA 2048 bits
    
• Connexion au serveur :
  
  protocole TLS 1.0
  
  
  • protocole d'échange de clé RSA        Médiocre!!!
    c'est à dire :
    
    transmission de la clé secrète primaire (en clair) au serveur chiffré par la clé publique RSA
    
    
  • sécurisation des messages par AES_256_CBC
    c'est à dire :
    chiffrement symétrique : AES-256
    enchaînement par Cipher Block Chaining
    contrôle d'intégrité fournit par SHA1
    

https://www.ssllabs.com/ssltest/analyze.html?d=professionnels.societegenerale.fr

Note C!

C'est CATASTROPHIQUE pour un établissement bancaire!

Signature algorithm   SHA1withRSA   WEAK

Additional Certificates (if supplied)
Certificates provided   3 (4196 bytes)
Chain issues   Extra certs
#2
Subject   VeriSign Class 3 Secure Server CA - G3
Fingerprint: 5deb8f339e264c19f6686f5f8f32b54a4c46b476
Valid until   Fri Feb 07 15:59:59 PST 2020 (expires in 4 years and 9 months)
Key   RSA 2048 bits (e 65537)
Issuer   VeriSign Class 3 Public Primary Certification Authority - G5
Signature algorithm   SHA1withRSA   WEAK
#3
Subject   VeriSign Class 3 Public Primary Certification Authority - G5
Fingerprint: 32f30882622b87cf8856c63db873df0853b4dd27
Valid until   Sun Nov 07 15:59:59 PST 2021 (expires in 6 years and 6 months)
Key   RSA 2048 bits (e 65537)
Issuer   VeriSign / Class 3 Public Primary Certification Authority
Signature algorithm   SHA1withRSA   WEAK

Protocols
TLS 1.2   No
TLS 1.1   No
TLS 1.0   Yes
SSL 3   INSECURE   Yes
SSL 2   No


Cipher Suites (sorted by strength; the server has no preference)
TLS_RSA_WITH_RC4_128_MD5 (0x4)   WEAK   128
TLS_RSA_WITH_RC4_128_SHA (0x5)   WEAK   128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)   128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)   256

Protocol Details
Secure Renegotiation   Supported
Secure Client-Initiated Renegotiation   Supported   DoS DANGER
Insecure Client-Initiated Renegotiation   No
BEAST attack   Not mitigated server-side   SSL 3: 0x2f, TLS 1.0: 0x2f
POODLE (SSLv3)   Vulnerable   INSECURE
POODLE (TLS)   No
Downgrade attack prevention   Yes, TLS_FALLBACK_SCSV supported
TLS compression   No
RC4   Yes   WEAK
Heartbeat (extension)   No
Heartbleed (vulnerability)   No
OpenSSL CCS vuln. (CVE-2014-0224)   No
Forward Secrecy   No   WEAK
Next Protocol Negotiation (NPN)   No
Session resumption (caching)   Yes
Session resumption (tickets)   Yes
OCSP stapling   No
Strict Transport Security (HSTS)   No
Public Key Pinning (HPKP)   No
Long handshake intolerance   No
TLS extension intolerance   No
TLS version intolerance   TLS 2.98
SSL 2 handshake compatibility   Yes

Je crois que tu confonds avec les cas d'exposition aux vulnérabilités BEAST/POODLE, et qu'il n'y a rien de mal à utiliser CBC sur un serveur à jour et qui négocie les bonnes versions du protocole.

mais c'est le cas de la socgen!

Même le SSL v3 est supporté!

Le protocole SSL v3 date de novembre 1996; le protocole TLS 1.0 est décrit par la RFC 2246 publiée en 1999!

Mouais, très mauvaise réaction.
Ainsi, les gens s'imaginent être en sécurité, alors qu'il n'en est rien.

Pour avoir ce genre de compatibilité, autant tout mettre en HTTP.