Harvesterify a écrit 33 commentaires

tu as de l'argent à mettre dans ton CPU (oui, le SSL a un coût)

https://istlsfastyet.com/

Le coût n'e'st pas si élevé comme ça, surtout quand tu as un trafic assez limité. Et si tu as un site qui ne dépend pas d'autres sous domaines, SPDY ou HTTP2 est une bonne idée pour réduire encore plus l'impact sur les perfs.

Mes messages engagent qui je veux.

La directive de cipherli.st ne devrait pas donner la suite de chiffrement que testssl te donne. Comme le dit si bien un autre commentaire, il doit y avoir une interférence avec une autre directive quelque part…

Mes messages engagent qui je veux.

Pour compléter le post d'en dessous justement, un autre benchmark fait sur un Galaxy S3 (donc plutôt vieux, et qui correspondrait en terme de processeur à de l'entrée de gamme acteullement) : https://jve.linuxwall.info/blog/index.php?post/2013/09/12/My-phone-does-crypto-faster-than-my-servers

Les mesures brutes sont disponibles au format TXT ici : https://jve.linuxwall.info/ressources/taf/aesmeasurements.txt

Première chose : il n'a pas testé le mode GCM. Ce n'est pas forcément dommageable, mais comme on en parlait ailleurs dans la conversation, autant le préciser. Deuxièmement, on se rend bien compte que oui, il y a bien une différence de perfs entre 128 vs. 256, mais :

1. Elle n'est pas si énorme que ça (68MB/s pour du 128 bits, 51MB/s pour du 256)
2. La perf en elle-même pour du 256 bits est bien suffisante pour l'usage "surf sur des sites HTTPS" et les quelques opérations de crypto qu'on peut bien faire sur son smartphone

Une conversation intéressante (de 2013 tout de même, comme quoi on avance pas vraiment sur le sujet 128 vs. 256…) avec les développeurs Mozilla : https://groups.google.com/forum/#!msg/mozilla.dev.tech.crypto/36na1B2brGU/xUMMPMgkmEMJ

Mes messages engagent qui je veux.

C'est assez simple : si tu casses algorithmiquement AES128, tu casses aussi AES256. C'est très peu probable, comme tu dis, de "trouver une faille dans AES128 et pas dans AES256".

Donc comme AES256 n'est pas accéléré sur les processeurs mobiles (pas sur le Snapdragon S4 en tous cas : https://calomel.org/aesni_ssl_performance.html) et que le compromis puissance requise/sécurité n'a semble t'il pas convaincu les ingés chez Google, c'est désactivé…

Luke O'Connor (sans vouloir jouer de l'argument d'autorité, ce n'est pas non plus le premier clampin venu en crypto) a un avis assez similaire, et le NIST aussi :

NIST’s recommendation above includes the threat model not only of predicting the key, but also of cracking the encryption algorithm. The difference between cracking AES-128 algorithm and AES-256 algorithm is considered minimal. Whatever breakthrough might crack 128-bit will probably also crack 256-bit.

(source : http://lukenotricks.blogspot.fr/2010/04/aes-128-versus-aes-256-encryption.html)

EDIT : cela dit, la différence ne semble pas non plus extrêmement importante, selon Google :

A standard phone (which is always defined by whatever I happen to have in my pocket; a Galaxy Nexus at the moment) can do AES-128-GCM at only 25MB/s and AES-256-GCM at 20MB/s (both measured with an 8KB block size).

(Source : https://www.imperialviolet.org/2013/10/07/chacha20.html)

Mes messages engagent qui je veux.

A moins que SSL Labs raconte n'imp (ce qui peut arriver), ce n'est pas vrai en pratique, ce que tu énonces, la preuve avec mon serveur :

Android 4.4.2 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp384r1 FS
Android 5.0.0 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp384r1 FS

Tiré de : https://dev.ssllabs.com/ssltest/analyze.html?d=harvester.fr&s=176.31.119.121&hideResults=on

Android 4.4.2 prend bien du 256-GCM là où Android 5.0 "régresse" (oui parce qu'on encule plutôt les mouches là, pour le coup…) avec du 128-GCM :)

EDIT : Au temps pour moi, tu parles de la 4.1, qui ne gère que TLS 1.0 donc automatiquement du CBC. Cela dit, Zenitram parlait bien de la version 4.4 dans son post.

Mes messages engagent qui je veux.

Je ne comprends pas, tu as moyen de modifier l'ordre des ciphers (donc avec un accès au fichier de conf, non ?), tu peux donc désactiver la signature du serveur, ou je suis à côté de mes pompes ?

Normalement, la directive ServerSignature Off est utilisable en global, mais aussi individuellement pour chaque vhost.

Mes messages engagent qui je veux.

Salut,

En reprenant la suite de chiffrement de cipherli.st ça devrait passer :

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH

Tu as d'autres options de conf' utiles pour Apache sur leur site :) Sinon le draft de BetterCrypto peut aider.

Mes messages engagent qui je veux.

Il ne restera plus qu'à désactiver le fingerprinting de ton Apache en plus de la réorganisation de la suite des ciphers, et ce sera pas mal :)

Mes messages engagent qui je veux.