Réglementation actuelle sur les outils cryptographiques en France
23 réponses
Wedjat
Comme l'indique le sujet, quelle est la réglementation en la matière
aujourd'hui ? Un éminent professeur à Jussieu en 2006 m'avait laissé
entendre, à l'époque, que la fourniture de moyens de cryptographie qui
utilisaient des clés de taille supérieure à 128 bits était interdite.
Certains d'entre vous ont-t'ils d'ailleurs eu des expériences à ce sujet
avec le ministère de la Défense ?
--
« J'étais toujours en faveur de l'immortalité. De quelle autre manière
pourrons-nous voir ce que sera le monde dans deux cents ans ? » (Richard
Stallman)
Ceci étant dit, je soupçonne que la loi vise surtout les sites web (et webmails) en HTTPS. La loi oblige l'administrateur à archiver la clé privée du serveur. En tant que professionnel il peut difficilement prétendre qu'il l'a "perdue suite à un formatage" alors que le reste de ses données est soigneusement sauvegardé hors site etc.
Et quel interêt de conserver la clé privée du serveur? Les flux arrivent sur ton serveur, donc tu as les logs en clair. -- Kevin
Le 24-03-2011, A. Caspis <a_caspis@yahoo.com> a écrit :
Ceci étant dit, je soupçonne que la loi vise surtout les sites
web (et webmails) en HTTPS. La loi oblige l'administrateur à
archiver la clé privée du serveur. En tant que professionnel
il peut difficilement prétendre qu'il l'a "perdue suite à un
formatage" alors que le reste de ses données est soigneusement
sauvegardé hors site etc.
Et quel interêt de conserver la clé privée du serveur? Les flux
arrivent sur ton serveur, donc tu as les logs en clair.
--
Kevin
Ceci étant dit, je soupçonne que la loi vise surtout les sites web (et webmails) en HTTPS. La loi oblige l'administrateur à archiver la clé privée du serveur. En tant que professionnel il peut difficilement prétendre qu'il l'a "perdue suite à un formatage" alors que le reste de ses données est soigneusement sauvegardé hors site etc.
Et quel interêt de conserver la clé privée du serveur? Les flux arrivent sur ton serveur, donc tu as les logs en clair. -- Kevin
Paul Gaborit
À (at) Thu, 24 Mar 2011 13:34:27 +0100, "A. Caspis" écrivait (wrote):
Ceci étant dit, je soupçonne que la loi vise surtout les sites web (et webmails) en HTTPS. La loi oblige l'administrateur à archiver la clé privée du serveur. En tant que professionnel il peut difficilement prétendre qu'il l'a "perdue suite à un formatage" alors que le reste de ses données est soigneusement sauvegardé hors site etc.
Quel intérêt ? Ce couple de clés ne sert pas à chiffrer le flux de données. Il sert juste à échanger une clé de session. À ma connaissance, aucune loi n'oblige quiconque à conserver la liste de toutes les clés de session utilisées.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 24 Mar 2011 13:34:27 +0100,
"A. Caspis" <a_caspis@yahoo.com> écrivait (wrote):
Ceci étant dit, je soupçonne que la loi vise surtout les sites
web (et webmails) en HTTPS. La loi oblige l'administrateur à
archiver la clé privée du serveur. En tant que professionnel
il peut difficilement prétendre qu'il l'a "perdue suite à un
formatage" alors que le reste de ses données est soigneusement
sauvegardé hors site etc.
Quel intérêt ? Ce couple de clés ne sert pas à chiffrer le flux de
données. Il sert juste à échanger une clé de session. À ma
connaissance, aucune loi n'oblige quiconque à conserver la liste de
toutes les clés de session utilisées.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 24 Mar 2011 13:34:27 +0100, "A. Caspis" écrivait (wrote):
Ceci étant dit, je soupçonne que la loi vise surtout les sites web (et webmails) en HTTPS. La loi oblige l'administrateur à archiver la clé privée du serveur. En tant que professionnel il peut difficilement prétendre qu'il l'a "perdue suite à un formatage" alors que le reste de ses données est soigneusement sauvegardé hors site etc.
Quel intérêt ? Ce couple de clés ne sert pas à chiffrer le flux de données. Il sert juste à échanger une clé de session. À ma connaissance, aucune loi n'oblige quiconque à conserver la liste de toutes les clés de session utilisées.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
A. Caspis
Kevin Denis wrote:
Et quel interêt de conserver la clé privée du serveur? Les flux arrivent sur ton serveur, donc tu as les logs en clair.
La clé permet de déchiffrer a posteriori des échanges HTTPS qui auraient été interceptés par l'autorité judiciaire, ce qui est plus intéressant que les seuls logs de connexion.
Après réflexion tu as peut-être raison; l'administrateur n'a pas de raison technique de conserver à long terme la clé privée d'un certificat expiré, donc il peut plaider qu'il ne connait plus la convention de chiffrement.
Reste l'article 11-1 de la loi n°91-646 du 10 juillet 1991 ( http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=LEGITEXT000006077781&dateTexte 110324 ) qui oblige les fournisseurs de "prestations de cryptologie" à révéler les clés. Mais ça reste un peu flou (est-ce que ça concerne les opérateurs de webmails HTTPS, de forums, de VPNs, de VoIP chiffrée, etc) et je n'ai pas trouvé de décret qui instaurerait une durée de conservation des clés.
Le décret sur la conservation des "données permettant d'identifier toute personne ayant contribué à la création d'un contenu mis en ligne", lui, vient de sortir, mais il ne parle pas des clés: http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000023646013&categorieLien=id
Des avis ? Faut-il archiver les clés privées HTTPS ?
AC
Kevin Denis wrote:
Et quel interêt de conserver la clé privée du serveur? Les flux
arrivent sur ton serveur, donc tu as les logs en clair.
La clé permet de déchiffrer a posteriori des échanges HTTPS qui
auraient été interceptés par l'autorité judiciaire, ce qui est
plus intéressant que les seuls logs de connexion.
Après réflexion tu as peut-être raison; l'administrateur n'a pas
de raison technique de conserver à long terme la clé privée d'un
certificat expiré, donc il peut plaider qu'il ne connait plus la
convention de chiffrement.
Reste l'article 11-1 de la loi n°91-646 du 10 juillet 1991
( http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=LEGITEXT000006077781&dateTexte 110324 )
qui oblige les fournisseurs de "prestations de cryptologie" à
révéler les clés. Mais ça reste un peu flou (est-ce que ça
concerne les opérateurs de webmails HTTPS, de forums, de VPNs,
de VoIP chiffrée, etc) et je n'ai pas trouvé de décret qui
instaurerait une durée de conservation des clés.
Le décret sur la conservation des "données permettant d'identifier
toute personne ayant contribué à la création d'un contenu mis en
ligne", lui, vient de sortir, mais il ne parle pas des clés:
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000023646013&categorieLien=id
Des avis ? Faut-il archiver les clés privées HTTPS ?
Et quel interêt de conserver la clé privée du serveur? Les flux arrivent sur ton serveur, donc tu as les logs en clair.
La clé permet de déchiffrer a posteriori des échanges HTTPS qui auraient été interceptés par l'autorité judiciaire, ce qui est plus intéressant que les seuls logs de connexion.
Après réflexion tu as peut-être raison; l'administrateur n'a pas de raison technique de conserver à long terme la clé privée d'un certificat expiré, donc il peut plaider qu'il ne connait plus la convention de chiffrement.
Reste l'article 11-1 de la loi n°91-646 du 10 juillet 1991 ( http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=LEGITEXT000006077781&dateTexte 110324 ) qui oblige les fournisseurs de "prestations de cryptologie" à révéler les clés. Mais ça reste un peu flou (est-ce que ça concerne les opérateurs de webmails HTTPS, de forums, de VPNs, de VoIP chiffrée, etc) et je n'ai pas trouvé de décret qui instaurerait une durée de conservation des clés.
Le décret sur la conservation des "données permettant d'identifier toute personne ayant contribué à la création d'un contenu mis en ligne", lui, vient de sortir, mais il ne parle pas des clés: http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000023646013&categorieLien=id
Des avis ? Faut-il archiver les clés privées HTTPS ?
AC
Kevin Denis
Le 24-03-2011, A. Caspis a écrit :
Quel intérêt ? Ce couple de clés ne sert pas à chiffrer le flux de données. Il sert juste à échanger une clé de session. À ma connaissance, aucune loi n'oblige quiconque à conserver la liste de toutes les clés de session utilisées.
Pas besoin de conserver les clés de session, la clé privée RSA du serveur HTTPS permet de les reconstituer, non ?
Pas forcément, tu peux jouer un diffie-hellman une fois les vérifs SSL effectuées. Il faut éviter qu'un attaquant réussissant à lire la clé privée puisse déchiffrer les échanges précedemment sniffés.
Mais je pense que quelqu'un l'expliquera mieux que moi :) -- Kevin
Le 24-03-2011, A. Caspis <a_caspis@yahoo.com> a écrit :
Quel intérêt ? Ce couple de clés ne sert pas à chiffrer le flux de
données. Il sert juste à échanger une clé de session. À ma
connaissance, aucune loi n'oblige quiconque à conserver la liste de
toutes les clés de session utilisées.
Pas besoin de conserver les clés de session, la clé privée RSA
du serveur HTTPS permet de les reconstituer, non ?
Pas forcément, tu peux jouer un diffie-hellman une fois les vérifs
SSL effectuées.
Il faut éviter qu'un attaquant réussissant à lire la clé privée puisse
déchiffrer les échanges précedemment sniffés.
Mais je pense que quelqu'un l'expliquera mieux que moi :)
--
Kevin
Quel intérêt ? Ce couple de clés ne sert pas à chiffrer le flux de données. Il sert juste à échanger une clé de session. À ma connaissance, aucune loi n'oblige quiconque à conserver la liste de toutes les clés de session utilisées.
Pas besoin de conserver les clés de session, la clé privée RSA du serveur HTTPS permet de les reconstituer, non ?
Pas forcément, tu peux jouer un diffie-hellman une fois les vérifs SSL effectuées. Il faut éviter qu'un attaquant réussissant à lire la clé privée puisse déchiffrer les échanges précedemment sniffés.
Mais je pense que quelqu'un l'expliquera mieux que moi :) -- Kevin
Bruno Tréguier
Kevin Denis wrote:
Il faut éviter qu'un attaquant réussissant à lire la clé privée puisse déchiffrer les échanges précedemment sniffés.
Mais je pense que quelqu'un l'expliquera mieux que moi :)
C'est dans ce genre de cas que les dispositifs de "déni plausible" comme celui existant dans le logiciel "truecrypt" deviennent "intéressants"... ;-)
Qui se retourne contre l'utilisateur dans le meilleur des cas.
Si on peut forcer l'utilisateur à donner le 1er mot de passe, alors on peut vraisemblablement le forcer à fournir le second. Et si le second n'existe pas, alors l'utilisateur est dans une situation très désagréable.
Je me plaçais strictement dans le cadre de l'application de la loi sur le séquestre des clefs, Kévin, donc face à des représentants de la force publique et de la justice, qui ont besoin de preuves *formelles* pour vous condamner (et plus si affinités).
Je n'envisageais pas l'éventualité de l'intervention de groupes dont les méthodes sont, disons, plus difficilement contrôlables (à tout le moins), et dans une telle éventualité, je suis d'accord avec vous (j'ai encore tous mes doigts, rassurez-vous). ;-)
Enfin, il y a tellement de "requirements" demandés que sa mise en oeuvre est très réduite, et dépendante de tellement de contraintes que son utilisation va en devenir évidente: si vous suivez toutes ces contraintes, alors cela signifie que vous utilisez de la plausible deniability. Si vous n'utilisez pas toutes ces contraintes, alors on peut détecter la plausible deniability. Et comme la seule raison d'utiliser ces contraintes sert à protéger la plausible deniablity, nous sommes en zugzwang, comme aux échecs: tous les mouvements sont mauvais. Conclusion: la plausible deniability est un faux sentiment de sécurité. http://www.truecrypt.org/docs/?s=plausible-deniability
Il ne m'a pas semblé que les prérequis soient si contraignants que ça, par ailleurs, le fait de randomiser tout le contenu d'un disque ou d'une clef USB n'est pas forcément le signe de l'utilisation d'un mécanisme de plausible deniability... Cela peut tout simplement correspondre à un effacement sécurisé du medium (passage extrait de l'URL que vous avez donnée):
"A possible plausible explanation for the existence of a partition/device containing solely random data is that you have wiped (securely erased) the content of the partition/device using one of the tools that erase data by overwriting it with random data"
Cela dit, comme toujours, quand on utilise ce genre d'outil, il vaut mieux savoir ce qu'on fait et à quoi on s'expose.
-- Bruno Tréguier
Kevin Denis wrote:
Le 23-03-2011, Bruno Tréguier a écrit :
C'est dans ce genre de cas que les dispositifs de "déni plausible" comme
celui existant dans le logiciel "truecrypt" deviennent "intéressants"... ;-)
Qui se retourne contre l'utilisateur dans le meilleur des cas.
Si on peut forcer l'utilisateur à donner le 1er mot de passe, alors
on peut vraisemblablement le forcer à fournir le second.
Et si le second n'existe pas, alors l'utilisateur est dans une
situation très désagréable.
Je me plaçais strictement dans le cadre de l'application de la loi sur
le séquestre des clefs, Kévin, donc face à des représentants de la force
publique et de la justice, qui ont besoin de preuves *formelles* pour
vous condamner (et plus si affinités).
Je n'envisageais pas l'éventualité de l'intervention de groupes dont les
méthodes sont, disons, plus difficilement contrôlables (à tout le
moins), et dans une telle éventualité, je suis d'accord avec vous (j'ai
encore tous mes doigts, rassurez-vous). ;-)
Enfin, il y a tellement de "requirements" demandés que sa mise en oeuvre
est très réduite, et dépendante de tellement de contraintes que son
utilisation va en devenir évidente: si vous suivez toutes ces
contraintes, alors cela signifie que vous utilisez de la plausible
deniability. Si vous n'utilisez pas toutes ces contraintes, alors
on peut détecter la plausible deniability. Et comme la seule raison
d'utiliser ces contraintes sert à protéger la plausible deniablity,
nous sommes en zugzwang, comme aux échecs: tous les mouvements
sont mauvais. Conclusion: la plausible deniability est un faux
sentiment de sécurité.
http://www.truecrypt.org/docs/?s=plausible-deniability
Il ne m'a pas semblé que les prérequis soient si contraignants que ça,
par ailleurs, le fait de randomiser tout le contenu d'un disque ou d'une
clef USB n'est pas forcément le signe de l'utilisation d'un mécanisme de
plausible deniability... Cela peut tout simplement correspondre à un
effacement sécurisé du medium (passage extrait de l'URL que vous avez
donnée):
"A possible plausible explanation for the existence of a
partition/device containing solely random data is that you have wiped
(securely erased) the content of the partition/device using one of the
tools that erase data by overwriting it with random data"
Cela dit, comme toujours, quand on utilise ce genre d'outil, il vaut
mieux savoir ce qu'on fait et à quoi on s'expose.
C'est dans ce genre de cas que les dispositifs de "déni plausible" comme celui existant dans le logiciel "truecrypt" deviennent "intéressants"... ;-)
Qui se retourne contre l'utilisateur dans le meilleur des cas.
Si on peut forcer l'utilisateur à donner le 1er mot de passe, alors on peut vraisemblablement le forcer à fournir le second. Et si le second n'existe pas, alors l'utilisateur est dans une situation très désagréable.
Je me plaçais strictement dans le cadre de l'application de la loi sur le séquestre des clefs, Kévin, donc face à des représentants de la force publique et de la justice, qui ont besoin de preuves *formelles* pour vous condamner (et plus si affinités).
Je n'envisageais pas l'éventualité de l'intervention de groupes dont les méthodes sont, disons, plus difficilement contrôlables (à tout le moins), et dans une telle éventualité, je suis d'accord avec vous (j'ai encore tous mes doigts, rassurez-vous). ;-)
Enfin, il y a tellement de "requirements" demandés que sa mise en oeuvre est très réduite, et dépendante de tellement de contraintes que son utilisation va en devenir évidente: si vous suivez toutes ces contraintes, alors cela signifie que vous utilisez de la plausible deniability. Si vous n'utilisez pas toutes ces contraintes, alors on peut détecter la plausible deniability. Et comme la seule raison d'utiliser ces contraintes sert à protéger la plausible deniablity, nous sommes en zugzwang, comme aux échecs: tous les mouvements sont mauvais. Conclusion: la plausible deniability est un faux sentiment de sécurité. http://www.truecrypt.org/docs/?s=plausible-deniability
Il ne m'a pas semblé que les prérequis soient si contraignants que ça, par ailleurs, le fait de randomiser tout le contenu d'un disque ou d'une clef USB n'est pas forcément le signe de l'utilisation d'un mécanisme de plausible deniability... Cela peut tout simplement correspondre à un effacement sécurisé du medium (passage extrait de l'URL que vous avez donnée):
"A possible plausible explanation for the existence of a partition/device containing solely random data is that you have wiped (securely erased) the content of the partition/device using one of the tools that erase data by overwriting it with random data"
Cela dit, comme toujours, quand on utilise ce genre d'outil, il vaut mieux savoir ce qu'on fait et à quoi on s'expose.
Intéressant, je ne savais pas que c'était prévu dans TLS. Mais c'est rarement utilisé d'après: http://utcc.utoronto.ca/~cks/space/blog/tech/SSLForwardSecrecy
Firefox a l'air de le supporter (chercher security.ssl3.dhe dans about:config) mais je ne sais pas comment déterminer si une connexion en cours l'utilise.
http://support.dcmtk.org/docs-snapshot/file_ciphers.html mentionne une norme européenne de protection des données médicales qui exige l'utilisation de DH.
Et ne *pas* activer DH sur un serveur HTTPS serait un moyen économique, pour l'administrateur, d'être en conformité avec une éventuelle obligation légale de pouvoir révéler les clés de session a posteriori.
Je pensais par ailleurs que pour HTTPS avec authentification mutuelle (pas très courant non plus) il faudrait forcément obtenir les *deux* clés privées pour reconstituer la clé de session, mais la clé du serveur suffit d'après: http://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake
Intéressant, je ne savais pas que c'était prévu dans TLS.
Mais c'est rarement utilisé d'après:
http://utcc.utoronto.ca/~cks/space/blog/tech/SSLForwardSecrecy
Firefox a l'air de le supporter (chercher security.ssl3.dhe
dans about:config) mais je ne sais pas comment déterminer si
une connexion en cours l'utilise.
http://support.dcmtk.org/docs-snapshot/file_ciphers.html
mentionne une norme européenne de protection des données
médicales qui exige l'utilisation de DH.
Et ne *pas* activer DH sur un serveur HTTPS serait un moyen
économique, pour l'administrateur, d'être en conformité avec
une éventuelle obligation légale de pouvoir révéler les clés
de session a posteriori.
Je pensais par ailleurs que pour HTTPS avec authentification
mutuelle (pas très courant non plus) il faudrait forcément
obtenir les *deux* clés privées pour reconstituer la clé de
session, mais la clé du serveur suffit d'après:
http://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake
Intéressant, je ne savais pas que c'était prévu dans TLS. Mais c'est rarement utilisé d'après: http://utcc.utoronto.ca/~cks/space/blog/tech/SSLForwardSecrecy
Firefox a l'air de le supporter (chercher security.ssl3.dhe dans about:config) mais je ne sais pas comment déterminer si une connexion en cours l'utilise.
http://support.dcmtk.org/docs-snapshot/file_ciphers.html mentionne une norme européenne de protection des données médicales qui exige l'utilisation de DH.
Et ne *pas* activer DH sur un serveur HTTPS serait un moyen économique, pour l'administrateur, d'être en conformité avec une éventuelle obligation légale de pouvoir révéler les clés de session a posteriori.
Je pensais par ailleurs que pour HTTPS avec authentification mutuelle (pas très courant non plus) il faudrait forcément obtenir les *deux* clés privées pour reconstituer la clé de session, mais la clé du serveur suffit d'après: http://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake
AC
Francois Grieu
Le 24/03/2011 13:34, A. Caspis a écrit :
Kevin Denis wrote:
Conclusion: la plausible deniability est un faux sentiment de sécurité.
Sauf quand tout le monde utilisera des outils qui l'implémentent (du genre: Microsoft rachète TrueCrypt).
Ceci étant dit, je soupçonne que la loi vise surtout les sites web (et webmails) en HTTPS. La loi oblige l'administrateur à archiver la clé privée du serveur. En tant que professionnel il peut difficilement prétendre qu'il l'a "perdue suite à un formatage" alors que le reste de ses données est soigneusement sauvegardé hors site etc.
Le HSM qui contenait la clé s'est réinitialisé; j'ai perdu la clé mais pas le reste. Ca arrive Mr. le juge...
Le pire, c'est que ça arrive vraiment.
François Grieu
Le 24/03/2011 13:34, A. Caspis a écrit :
Kevin Denis wrote:
Conclusion: la plausible deniability est un faux
sentiment de sécurité.
Sauf quand tout le monde utilisera des outils qui l'implémentent
(du genre: Microsoft rachète TrueCrypt).
Ceci étant dit, je soupçonne que la loi vise surtout les sites
web (et webmails) en HTTPS. La loi oblige l'administrateur à
archiver la clé privée du serveur. En tant que professionnel
il peut difficilement prétendre qu'il l'a "perdue suite à un
formatage" alors que le reste de ses données est soigneusement
sauvegardé hors site etc.
Le HSM qui contenait la clé s'est réinitialisé; j'ai perdu la clé
mais pas le reste. Ca arrive Mr. le juge...
Conclusion: la plausible deniability est un faux sentiment de sécurité.
Sauf quand tout le monde utilisera des outils qui l'implémentent (du genre: Microsoft rachète TrueCrypt).
Ceci étant dit, je soupçonne que la loi vise surtout les sites web (et webmails) en HTTPS. La loi oblige l'administrateur à archiver la clé privée du serveur. En tant que professionnel il peut difficilement prétendre qu'il l'a "perdue suite à un formatage" alors que le reste de ses données est soigneusement sauvegardé hors site etc.
Le HSM qui contenait la clé s'est réinitialisé; j'ai perdu la clé mais pas le reste. Ca arrive Mr. le juge...
Le pire, c'est que ça arrive vraiment.
François Grieu
Thomas Pornin
According to A. Caspis :
Intéressant, je ne savais pas que c'était prévu dans TLS. Mais c'est rarement utilisé d'après: http://utcc.utoronto.ca/~cks/space/blog/tech/SSLForwardSecrecy
En fait c'est supporté "partout" (un Internet Explorer 5.0 sait faire, par exemple). Mais c'est au choix du serveur : dans TLS, le client annonce la liste des "cipher suites" qu'il supporte, et le serveur choisit à sa guise. De plus, l'ordre dans lequel le client envoie sa liste indique ses "préférences" : souvent, le client déclare préférer le "RSA key exchange" (chiffrement asymétrique d'une clé aléatoire) au "ephemeral Diffie-Hellman" (échange DH, le serveur utilise sa clé privée pour _signer_ sa moitié de l'échange). Donc, en pratique, le serveur a une clé RSA, le client et le serveur savent tous les deux faire du DHE, mais ils font du chiffrement RSA simplement parce que le client envoie ce nom-là en premier.
On peut normalement configurer le serveur Web pour choisir autrement, i.e. sélectionner DHE quand c'est possible (supporté par le client). Mais ce n'est pas la configuration par défaut, donc c'est rare (l'administrateur de site Web est comme tout le monde, il est un gros fainéant qui en fait le moins possible).
Une autre manière de forcer le DHE est de donner au serveur une clé DSA (ou ECDSA) : comme DSA ne fait que de la signature, le serveur ne peut utiliser qu'une cipher suite DHE.
Firefox a l'air de le supporter (chercher security.ssl3.dhe dans about:config) mais je ne sais pas comment déterminer si une connexion en cours l'utilise.
Il n'est pas dans les habitudes des browsers de donner autant de détails. Au mieux, ils diront "on chiffre en 128 bits" pour dire que la cipher suite utilise AES pour la partie chiffrement symétrique.
Je pensais par ailleurs que pour HTTPS avec authentification mutuelle (pas très courant non plus) il faudrait forcément obtenir les *deux* clés privées pour reconstituer la clé de session, mais la clé du serveur suffit
En TLS, l'authentification du client par clé publique utilise une signature, et n'influe pas sur la clé de session calculée.
--Thomas Pornin
According to A. Caspis <a_caspis@yahoo.com>:
Intéressant, je ne savais pas que c'était prévu dans TLS.
Mais c'est rarement utilisé d'après:
http://utcc.utoronto.ca/~cks/space/blog/tech/SSLForwardSecrecy
En fait c'est supporté "partout" (un Internet Explorer 5.0 sait faire,
par exemple). Mais c'est au choix du serveur : dans TLS, le client
annonce la liste des "cipher suites" qu'il supporte, et le serveur
choisit à sa guise. De plus, l'ordre dans lequel le client envoie sa
liste indique ses "préférences" : souvent, le client déclare préférer le
"RSA key exchange" (chiffrement asymétrique d'une clé aléatoire) au
"ephemeral Diffie-Hellman" (échange DH, le serveur utilise sa clé privée
pour _signer_ sa moitié de l'échange). Donc, en pratique, le serveur a
une clé RSA, le client et le serveur savent tous les deux faire du DHE,
mais ils font du chiffrement RSA simplement parce que le client envoie
ce nom-là en premier.
On peut normalement configurer le serveur Web pour choisir autrement,
i.e. sélectionner DHE quand c'est possible (supporté par le client).
Mais ce n'est pas la configuration par défaut, donc c'est rare
(l'administrateur de site Web est comme tout le monde, il est un gros
fainéant qui en fait le moins possible).
Une autre manière de forcer le DHE est de donner au serveur une
clé DSA (ou ECDSA) : comme DSA ne fait que de la signature, le
serveur ne peut utiliser qu'une cipher suite DHE.
Firefox a l'air de le supporter (chercher security.ssl3.dhe
dans about:config) mais je ne sais pas comment déterminer si
une connexion en cours l'utilise.
Il n'est pas dans les habitudes des browsers de donner autant de
détails. Au mieux, ils diront "on chiffre en 128 bits" pour dire que la
cipher suite utilise AES pour la partie chiffrement symétrique.
Je pensais par ailleurs que pour HTTPS avec authentification mutuelle
(pas très courant non plus) il faudrait forcément obtenir les *deux*
clés privées pour reconstituer la clé de session, mais la clé du
serveur suffit
En TLS, l'authentification du client par clé publique utilise une
signature, et n'influe pas sur la clé de session calculée.
Intéressant, je ne savais pas que c'était prévu dans TLS. Mais c'est rarement utilisé d'après: http://utcc.utoronto.ca/~cks/space/blog/tech/SSLForwardSecrecy
En fait c'est supporté "partout" (un Internet Explorer 5.0 sait faire, par exemple). Mais c'est au choix du serveur : dans TLS, le client annonce la liste des "cipher suites" qu'il supporte, et le serveur choisit à sa guise. De plus, l'ordre dans lequel le client envoie sa liste indique ses "préférences" : souvent, le client déclare préférer le "RSA key exchange" (chiffrement asymétrique d'une clé aléatoire) au "ephemeral Diffie-Hellman" (échange DH, le serveur utilise sa clé privée pour _signer_ sa moitié de l'échange). Donc, en pratique, le serveur a une clé RSA, le client et le serveur savent tous les deux faire du DHE, mais ils font du chiffrement RSA simplement parce que le client envoie ce nom-là en premier.
On peut normalement configurer le serveur Web pour choisir autrement, i.e. sélectionner DHE quand c'est possible (supporté par le client). Mais ce n'est pas la configuration par défaut, donc c'est rare (l'administrateur de site Web est comme tout le monde, il est un gros fainéant qui en fait le moins possible).
Une autre manière de forcer le DHE est de donner au serveur une clé DSA (ou ECDSA) : comme DSA ne fait que de la signature, le serveur ne peut utiliser qu'une cipher suite DHE.
Firefox a l'air de le supporter (chercher security.ssl3.dhe dans about:config) mais je ne sais pas comment déterminer si une connexion en cours l'utilise.
Il n'est pas dans les habitudes des browsers de donner autant de détails. Au mieux, ils diront "on chiffre en 128 bits" pour dire que la cipher suite utilise AES pour la partie chiffrement symétrique.
Je pensais par ailleurs que pour HTTPS avec authentification mutuelle (pas très courant non plus) il faudrait forcément obtenir les *deux* clés privées pour reconstituer la clé de session, mais la clé du serveur suffit
En TLS, l'authentification du client par clé publique utilise une signature, et n'influe pas sur la clé de session calculée.
--Thomas Pornin
Jean-Marc Desperrier
Francois Grieu wrote:
Le HSM qui contenait la clé s'est réinitialisé; j'ai perdu la clé mais pas le reste. Ca arrive Mr. le juge...
Le pire, c'est que ça arrive vraiment.
D'où l'intérêt du tiers de recouvrement même si la loi n'y oblige en rien. Quand c'est le tiers qui a perdu la clé, c'est son problème, et lui n'étant réellement pas impliqué vis-à-vis du contenu des données, ça commence à devenir réellement plausible face au juge que la perte est bien un accident.
Francois Grieu wrote:
Le HSM qui contenait la clé s'est réinitialisé; j'ai perdu la clé
mais pas le reste. Ca arrive Mr. le juge...
Le pire, c'est que ça arrive vraiment.
D'où l'intérêt du tiers de recouvrement même si la loi n'y oblige en
rien. Quand c'est le tiers qui a perdu la clé, c'est son problème, et
lui n'étant réellement pas impliqué vis-à-vis du contenu des données, ça
commence à devenir réellement plausible face au juge que la perte est
bien un accident.
Le HSM qui contenait la clé s'est réinitialisé; j'ai perdu la clé mais pas le reste. Ca arrive Mr. le juge...
Le pire, c'est que ça arrive vraiment.
D'où l'intérêt du tiers de recouvrement même si la loi n'y oblige en rien. Quand c'est le tiers qui a perdu la clé, c'est son problème, et lui n'étant réellement pas impliqué vis-à-vis du contenu des données, ça commence à devenir réellement plausible face au juge que la perte est bien un accident.
