HTTPS : Google anticipe les attaques par décryptage rétrospectif

[Idelways]

HTTPS : Google anticipe les attaques par décryptage rétrospectif
Sur ses services et promeut la confidentialité persistante


Google anticipe un risque lointain et néanmoins palpable qui pèse sur les connexions sécurisées. Il annonce l'activation sur ses services de la technique dite de Confidentialité persistante.

La majorité des implémentations actuelles du HTTPS reposent sur une clé privée connue uniquement par le serveur. Ce dernier l'utilise pour générer des clés de sessions et chiffrer ses échanges avec les clients.

Que se passera-t-il dans 10 ans, quand les ordinateurs seront tellement plus puissants que casser une clé privée sera plus facile ? Des attaques de décryptage rétrospectif, répond Adam Langley, l'un des ingénieurs de l'équipe de sécurité de Google.

La technique de Confidentialité persistante s'assure que les messages chiffrés et capturés ne peuvent être décryptés en masse, tout simplement en évitant de garder les clés privées dans une base de données persistante.

L'implémentation de Google consiste à utiliser différentes clés privées pour une même connexion et s'en débarrasser définitivement après un laps de temps.
Dans l'absolu, « même le serveur opérateur ne sera pas en mesure de décrypter rétroactivement les sessions HTTPS », affirme Langley.

Cette technique est active depuis l'annonce de Google mardi sur Gmail, les recherches SSL (par défaut pour les comptes identifiés), la suite Docs et Google+.

L'équipe sécurité de l'entreprise a choisi la méthode combinée d'échange de clés « ECDHE_RSA »; implémentée par Chrome et Firefox.
Internet Explorer supporte une autre méthode de confidentialité persistante que Google n'a pas choisie pour des raisons de performances, mais qu’il espère supporter à l'avenir.



Google espère aussi encourager les autres acteurs majeurs du Web à adopter cette technique. Le patch qui l'a rendu possible a été proposé au projet de bibliothèque OpenSSL et devrait se répandre avec sa version 1.0.1.


Source : Google

Et vous ?

Qu'en pensez-vous ?

[_Xavier_]

L'implémentation de Google consiste à utiliser différentes clés privées pour une même connexion et s'en débarrasser définitivement après un laps de temps.

J'aime bien Google, et je salue ses efforts. Mais qu'il présente son implémentation comme une innovation ...

Dans l'authentification Http de type Digest, il y a un champs qu'on appelle nonce qui est sensé faire la même chose.

[Joker-eph]

Peux-tu préciser le rapport entre nonce et l'échange de clé SSL ?

De plus l'article (et la source...) ne parle pas "d'innovation", mais d'activation d'une technique connue (tellement connue qu'elle est supportée par Firefox et Chrome...), ainsi que d'une contribution à OpenSSL pour faciliter le support par les différents serveurs web qui se basent dessus.

[pcdwarf]

Que se passera-t-il dans 10 ans, quand les ordinateurs seront tellement plus puissants que casser une clé privée sera plus facile ? Des attaques de décryptage rétrospectif

Alors je ne suis pas une pointure en cryptographie mais il me semble que sauf révolution dans les mathématiques, les algos comme RSA sont fiable même en multipliant par plusieurs milliards les capacités de traitement des machines. Il suffit d'augmenter la taille de la clé (et pas tant que ça d'ailleurs).

La principale faiblesse de https, ce ne sont pas les couples clé privée/clée publique. C'est plutôt les protocoles symétriques utilisés pour coder le flux de données comme par exemple AES qui sont beaucoup beaucoup plus faibles.

un expert sur la question peut-il éclairer ce point ?