après avoir lu l'interview d'Octave Klaba ici :
http://minilien.fr/a0ppef je retiens que :
-1- les FAI seront sûrement écoutés de manière non discriminée ;
-2- les centres d'hébergements resteront sur une technique "normale", à
savoir des écoutes ciblées et pas permanentes.
Donc me vient une question : j'ai un serveur dédiés chez OVH, si je tire
un VPN de chez moi à ce serveur, puis-je éviter les écoutes massives ?
laurent , dans le message <554dff2d$0$3160$, a écrit :
ben justement, l'idée est de dire que comme tu seras écouté sur la ligne de ton FAI, tu chiffres ce trafic jusqu'à un datacentre qui lui ne sera pas écouté (selon Klaba). Donc le trafic sur ta ligne perso n'est pas exploitable jusqu'au datacentre et non écouté en sortie de ce dernier. Sauf que apparemment, le datacentre sera écouté lui aussi, rendant par là même caduque cette solution.
La seule solution est de tout chiffrer de bout en bout.
Et bien sûr de jeter le mécanisme des autorités de certifications, qui est totalement inefficace pour assurer l'identité de l'interlocuteur face à des entités gouvernementales.
laurent , dans le message <554dff2d$0$3160$426a74cc@news.free.fr>, a
écrit :
ben justement, l'idée est de dire que comme tu seras écouté sur la ligne
de ton FAI, tu chiffres ce trafic jusqu'à un datacentre qui lui ne sera
pas écouté (selon Klaba). Donc le trafic sur ta ligne perso n'est pas
exploitable jusqu'au datacentre et non écouté en sortie de ce dernier.
Sauf que apparemment, le datacentre sera écouté lui aussi, rendant par
là même caduque cette solution.
La seule solution est de tout chiffrer de bout en bout.
Et bien sûr de jeter le mécanisme des autorités de certifications, qui est
totalement inefficace pour assurer l'identité de l'interlocuteur face à des
entités gouvernementales.
laurent , dans le message <554dff2d$0$3160$, a écrit :
ben justement, l'idée est de dire que comme tu seras écouté sur la ligne de ton FAI, tu chiffres ce trafic jusqu'à un datacentre qui lui ne sera pas écouté (selon Klaba). Donc le trafic sur ta ligne perso n'est pas exploitable jusqu'au datacentre et non écouté en sortie de ce dernier. Sauf que apparemment, le datacentre sera écouté lui aussi, rendant par là même caduque cette solution.
La seule solution est de tout chiffrer de bout en bout.
Et bien sûr de jeter le mécanisme des autorités de certifications, qui est totalement inefficace pour assurer l'identité de l'interlocuteur face à des entités gouvernementales.
patpro ~ patrick proniewski
In article <554e01be$0$3352$, Nicolas George <nicolas$ wrote:
laurent , dans le message <554dff2d$0$3160$, a écrit : > ben justement, l'idée est de dire que comme tu seras écouté sur la ligne > de ton FAI, tu chiffres ce trafic jusqu'à un datacentre qui lui ne sera > pas écouté (selon Klaba). Donc le trafic sur ta ligne perso n'est pas > exploitable jusqu'au datacentre et non écouté en sortie de ce dernier. > Sauf que apparemment, le datacentre sera écouté lui aussi, rendant par > là même caduque cette solution.
La seule solution est de tout chiffrer de bout en bout.
Ce n'est même plus une solution. Des chercheurs ont montré récemment comment il est possible de savoir ce que visite une personne sans même décrypter l'https, et les études sur la désanonymisation se multiplient. Donc finalement on peut espionner un utilisateur en restant en dehors du tuyau chiffré. Bien sûr ça ne permet pas de savoir ce qu'il raconte à son amant(e), mais c'est suffisant pour savoir avec une bonne certitude qu'il/elle a un(e) amant(e).
Si une organisation suffisamment motivée veut savoir ce qu'une personne raconte à d'autres, elle peut aussi espionner ces autres. Donc chiffrer de bout en bout, ok, mais si les destinataires ne prennent pas les mêmes précaution c'est cuit.
Et comme tu l'indiquais, le système de certification SSL n'est pas fiable pour lutter contre l'espionnage gouvernemental.
C'est finalement assez désespérant.
patpro
-- À vendre : http://www.leboncoin.fr/informatique/770978814.htm http://www.leboncoin.fr/informatique/770976404.htm
In article <554e01be$0$3352$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> wrote:
laurent , dans le message <554dff2d$0$3160$426a74cc@news.free.fr>, a
écrit :
> ben justement, l'idée est de dire que comme tu seras écouté sur la ligne
> de ton FAI, tu chiffres ce trafic jusqu'à un datacentre qui lui ne sera
> pas écouté (selon Klaba). Donc le trafic sur ta ligne perso n'est pas
> exploitable jusqu'au datacentre et non écouté en sortie de ce dernier.
> Sauf que apparemment, le datacentre sera écouté lui aussi, rendant par
> là même caduque cette solution.
La seule solution est de tout chiffrer de bout en bout.
Ce n'est même plus une solution. Des chercheurs ont montré récemment
comment il est possible de savoir ce que visite une personne sans même
décrypter l'https, et les études sur la désanonymisation se multiplient.
Donc finalement on peut espionner un utilisateur en restant en dehors du
tuyau chiffré. Bien sûr ça ne permet pas de savoir ce qu'il raconte à
son amant(e), mais c'est suffisant pour savoir avec une bonne certitude
qu'il/elle a un(e) amant(e).
Si une organisation suffisamment motivée veut savoir ce qu'une personne
raconte à d'autres, elle peut aussi espionner ces autres. Donc chiffrer
de bout en bout, ok, mais si les destinataires ne prennent pas les mêmes
précaution c'est cuit.
Et comme tu l'indiquais, le système de certification SSL n'est pas
fiable pour lutter contre l'espionnage gouvernemental.
C'est finalement assez désespérant.
patpro
--
À vendre :
http://www.leboncoin.fr/informatique/770978814.htm
http://www.leboncoin.fr/informatique/770976404.htm
In article <554e01be$0$3352$, Nicolas George <nicolas$ wrote:
laurent , dans le message <554dff2d$0$3160$, a écrit : > ben justement, l'idée est de dire que comme tu seras écouté sur la ligne > de ton FAI, tu chiffres ce trafic jusqu'à un datacentre qui lui ne sera > pas écouté (selon Klaba). Donc le trafic sur ta ligne perso n'est pas > exploitable jusqu'au datacentre et non écouté en sortie de ce dernier. > Sauf que apparemment, le datacentre sera écouté lui aussi, rendant par > là même caduque cette solution.
La seule solution est de tout chiffrer de bout en bout.
Ce n'est même plus une solution. Des chercheurs ont montré récemment comment il est possible de savoir ce que visite une personne sans même décrypter l'https, et les études sur la désanonymisation se multiplient. Donc finalement on peut espionner un utilisateur en restant en dehors du tuyau chiffré. Bien sûr ça ne permet pas de savoir ce qu'il raconte à son amant(e), mais c'est suffisant pour savoir avec une bonne certitude qu'il/elle a un(e) amant(e).
Si une organisation suffisamment motivée veut savoir ce qu'une personne raconte à d'autres, elle peut aussi espionner ces autres. Donc chiffrer de bout en bout, ok, mais si les destinataires ne prennent pas les mêmes précaution c'est cuit.
Et comme tu l'indiquais, le système de certification SSL n'est pas fiable pour lutter contre l'espionnage gouvernemental.
C'est finalement assez désespérant.
patpro
-- À vendre : http://www.leboncoin.fr/informatique/770978814.htm http://www.leboncoin.fr/informatique/770976404.htm
Yannix
Le 09/05/2015 11:55, laurent a écrit :
On 09/05/2015 10:01, Yannix wrote:
Si c'est perso, un "hébergement" chez soi suffit non ? Sinon, par définition, OVH peut déjà mettre le nez dans votre serveur et vos données. Pour un particulier, je ne vois qu'un seul intérêt au "cloud" : stoker physiquement ses sauvegardes à l'extérieur.
oui et non. L'avantage d'un hébergement dans un datacentre est multiple : bande passant élevée, haute disponibilité (électrique, connectivité, ...). Les mails que je reçois sont certes perso mais importants : fisc, réponse d'employeur quand je cherchais du taf, ...
Au niveau du wiki, je m'en sers dans un cadre professionnel aussi en capitalisant mes maigres connaissances et l'air de rien ça marche mieux avec une vraie connexion internet qu'un pauvre ADSL en 256k de remontée.
De plus, si je dois faire une démo quelconque à un client d'une webapp que j'aurais développée, monter un VPN quand je suis dans des pays où la liberté sur internet est limitée, ... avoir une bande passante élevée est une sûreté de fonctionnement est agréable.
Enfin, je ne suis pas convaincu que ça coûte vraiment moins cher de s'auto héberger. Je paye 15€ / mois l'hébergement. Entre le coût de la machine et de l'électricité, ça doit s'équivaloir. Et il y a des VPS encore moins chers.
Vous êtes là dans le cadre d'une utilisation pro, pas perso -> sous entendu d'un particulier!
Au niveau pro, un serveur dédié dans un datacenter, le tout avec une bande passante correcte se justifie très bien, mais ce n'est conforme à l'énoncé initial de votre problème...
X.
PS: C'est là qu'on va rigoler dans les DSI qui ne juraient que par "le cloud" quand cette loi va passer ! ;-) -- syncing file systems... done Press any key to reboot.
Le 09/05/2015 11:55, laurent a écrit :
On 09/05/2015 10:01, Yannix wrote:
Si c'est perso, un "hébergement" chez soi suffit non ? Sinon, par
définition, OVH peut déjà mettre le nez dans votre serveur et vos
données. Pour un particulier, je ne vois qu'un seul intérêt au "cloud" :
stoker physiquement ses sauvegardes à l'extérieur.
oui et non. L'avantage d'un hébergement dans un datacentre est multiple
: bande passant élevée, haute disponibilité (électrique, connectivité,
...). Les mails que je reçois sont certes perso mais importants : fisc,
réponse d'employeur quand je cherchais du taf, ...
Au niveau du wiki, je m'en sers dans un cadre professionnel aussi en
capitalisant mes maigres connaissances et l'air de rien ça marche mieux
avec une vraie connexion internet qu'un pauvre ADSL en 256k de remontée.
De plus, si je dois faire une démo quelconque à un client d'une webapp
que j'aurais développée, monter un VPN quand je suis dans des pays où la
liberté sur internet est limitée, ... avoir une bande passante élevée
est une sûreté de fonctionnement est agréable.
Enfin, je ne suis pas convaincu que ça coûte vraiment moins cher de
s'auto héberger. Je paye 15€ / mois l'hébergement. Entre le coût de la
machine et de l'électricité, ça doit s'équivaloir. Et il y a des VPS
encore moins chers.
Vous êtes là dans le cadre d'une utilisation pro, pas perso -> sous
entendu d'un particulier!
Au niveau pro, un serveur dédié dans un datacenter, le tout avec une
bande passante correcte se justifie très bien, mais ce n'est conforme à
l'énoncé initial de votre problème...
X.
PS: C'est là qu'on va rigoler dans les DSI qui ne juraient que par "le
cloud" quand cette loi va passer ! ;-)
--
syncing file systems... done
Press any key to reboot.
Si c'est perso, un "hébergement" chez soi suffit non ? Sinon, par définition, OVH peut déjà mettre le nez dans votre serveur et vos données. Pour un particulier, je ne vois qu'un seul intérêt au "cloud" : stoker physiquement ses sauvegardes à l'extérieur.
oui et non. L'avantage d'un hébergement dans un datacentre est multiple : bande passant élevée, haute disponibilité (électrique, connectivité, ...). Les mails que je reçois sont certes perso mais importants : fisc, réponse d'employeur quand je cherchais du taf, ...
Au niveau du wiki, je m'en sers dans un cadre professionnel aussi en capitalisant mes maigres connaissances et l'air de rien ça marche mieux avec une vraie connexion internet qu'un pauvre ADSL en 256k de remontée.
De plus, si je dois faire une démo quelconque à un client d'une webapp que j'aurais développée, monter un VPN quand je suis dans des pays où la liberté sur internet est limitée, ... avoir une bande passante élevée est une sûreté de fonctionnement est agréable.
Enfin, je ne suis pas convaincu que ça coûte vraiment moins cher de s'auto héberger. Je paye 15€ / mois l'hébergement. Entre le coût de la machine et de l'électricité, ça doit s'équivaloir. Et il y a des VPS encore moins chers.
Vous êtes là dans le cadre d'une utilisation pro, pas perso -> sous entendu d'un particulier!
Au niveau pro, un serveur dédié dans un datacenter, le tout avec une bande passante correcte se justifie très bien, mais ce n'est conforme à l'énoncé initial de votre problème...
X.
PS: C'est là qu'on va rigoler dans les DSI qui ne juraient que par "le cloud" quand cette loi va passer ! ;-) -- syncing file systems... done Press any key to reboot.
Yannix
Le 09/05/2015 14:46, Nicolas George a écrit : [...]
La seule solution est de tout chiffrer de bout en bout.
Même pas. Les "boites noires" sont censées enregistrer qui communique avec qui au niveau 3 de l'OSI et en conclure "des choses" selon leurs algorithmes...
X. -- syncing file systems... done Press any key to reboot.
Le 09/05/2015 14:46, Nicolas George a écrit :
[...]
La seule solution est de tout chiffrer de bout en bout.
Même pas. Les "boites noires" sont censées enregistrer qui communique
avec qui au niveau 3 de l'OSI et en conclure "des choses" selon leurs
algorithmes...
X.
--
syncing file systems... done
Press any key to reboot.
Le 09/05/2015 14:46, Nicolas George a écrit : [...]
La seule solution est de tout chiffrer de bout en bout.
Même pas. Les "boites noires" sont censées enregistrer qui communique avec qui au niveau 3 de l'OSI et en conclure "des choses" selon leurs algorithmes...
X. -- syncing file systems... done Press any key to reboot.
Yannix
Le 09/05/2015 12:07, laurent a écrit :
On 09/05/2015 10:01, Yannix wrote:
Si c'est perso, un "hébergement" chez soi suffit non ? Sinon, par définition, OVH peut déjà mettre le nez dans votre serveur et vos données.
Je n'avais pas rebondi sur ce point. Effectivement OVH peut mettre le nez dans mon serveur et je me suis toujours demandé comment je pouvais éviter cela.
Aujourd'hui j'utilise des containers KVM dont l'image est chiffrée sur le host. On peut y accéder en SSH. Donc plusieurs cas de figure (c'est exploratoire et pas péremptoire ! Il y a sûrement des failles et je suis à votre écoute !) : - le serveur est arrêté. Les containers sont donc chiffrés et à priori indéchiffrables (on part du principe que AES-256 est fiable ) ; - la machine est allumée, OVH peut prendre la main en console dessus mais ne dispose à priori pas des mots de passes et ne peut donc pas rentrer. Admettons qu'ils rentrent quand même (j'aimerai savoir comment sachant que j'ai réinstallé la machine complètement avec un noyau Vanilla et les drivers d'origine) : -> ils se retrouvent sur un host avec rien dedans hormis un vSwitch et des containers qui tournent. Ils peuvent accéder aux données non chiffrées qui transitent sur le vSwitch et les interfaces réseau. Ils peuvent sûrement accéder à des clés de chiffrement en fouillant la mémoire des processus KVM. Mais comment ? /dev/mem n'est pas présent, en fouillant la mémoire processus par processus ? Une idée ?
Enfin il y a aussi la solution d'un MITM pour trafiquer les connexions réseaux avant qu'elles ne soient chiffrées par SSH et introduire des backdoors. Mais une fois de plus, les paquets Debian sont signés, les signatures vérifiées, je ne pense donc pas que ce soit trivial.
Ou alors je passe à côté de quelque chose ?
De prime abord, je dirais qu'à partir du moment où OVH a déjà *accédé physiquement* à votre serveur, avant même que vous y installiez quoi que ce soit, devrait logiquement vous laisser supposer qu'il est d'ores et déjà compromis. ;-)
X. -- syncing file systems... done Press any key to reboot.
Le 09/05/2015 12:07, laurent a écrit :
On 09/05/2015 10:01, Yannix wrote:
Si c'est perso, un "hébergement" chez soi suffit non ? Sinon, par
définition, OVH peut déjà mettre le nez dans votre serveur et vos
données.
Je n'avais pas rebondi sur ce point. Effectivement OVH peut mettre le
nez dans mon serveur et je me suis toujours demandé comment je pouvais
éviter cela.
Aujourd'hui j'utilise des containers KVM dont l'image est chiffrée sur
le host. On peut y accéder en SSH. Donc plusieurs cas de figure (c'est
exploratoire et pas péremptoire ! Il y a sûrement des failles et je suis
à votre écoute !) :
- le serveur est arrêté. Les containers sont donc chiffrés et à priori
indéchiffrables (on part du principe que AES-256 est fiable ) ;
- la machine est allumée, OVH peut prendre la main en console dessus
mais ne dispose à priori pas des mots de passes et ne peut donc pas
rentrer. Admettons qu'ils rentrent quand même (j'aimerai savoir comment
sachant que j'ai réinstallé la machine complètement avec un noyau
Vanilla et les drivers d'origine) :
-> ils se retrouvent sur un host avec rien dedans hormis un vSwitch et
des containers qui tournent. Ils peuvent accéder aux données non
chiffrées qui transitent sur le vSwitch et les interfaces réseau. Ils
peuvent sûrement accéder à des clés de chiffrement en fouillant la
mémoire des processus KVM. Mais comment ? /dev/mem n'est pas présent, en
fouillant la mémoire processus par processus ? Une idée ?
Enfin il y a aussi la solution d'un MITM pour trafiquer les connexions
réseaux avant qu'elles ne soient chiffrées par SSH et introduire des
backdoors. Mais une fois de plus, les paquets Debian sont signés, les
signatures vérifiées, je ne pense donc pas que ce soit trivial.
Ou alors je passe à côté de quelque chose ?
De prime abord, je dirais qu'à partir du moment où OVH a déjà *accédé
physiquement* à votre serveur, avant même que vous y installiez quoi que
ce soit, devrait logiquement vous laisser supposer qu'il est d'ores et
déjà compromis. ;-)
X.
--
syncing file systems... done
Press any key to reboot.
Si c'est perso, un "hébergement" chez soi suffit non ? Sinon, par définition, OVH peut déjà mettre le nez dans votre serveur et vos données.
Je n'avais pas rebondi sur ce point. Effectivement OVH peut mettre le nez dans mon serveur et je me suis toujours demandé comment je pouvais éviter cela.
Aujourd'hui j'utilise des containers KVM dont l'image est chiffrée sur le host. On peut y accéder en SSH. Donc plusieurs cas de figure (c'est exploratoire et pas péremptoire ! Il y a sûrement des failles et je suis à votre écoute !) : - le serveur est arrêté. Les containers sont donc chiffrés et à priori indéchiffrables (on part du principe que AES-256 est fiable ) ; - la machine est allumée, OVH peut prendre la main en console dessus mais ne dispose à priori pas des mots de passes et ne peut donc pas rentrer. Admettons qu'ils rentrent quand même (j'aimerai savoir comment sachant que j'ai réinstallé la machine complètement avec un noyau Vanilla et les drivers d'origine) : -> ils se retrouvent sur un host avec rien dedans hormis un vSwitch et des containers qui tournent. Ils peuvent accéder aux données non chiffrées qui transitent sur le vSwitch et les interfaces réseau. Ils peuvent sûrement accéder à des clés de chiffrement en fouillant la mémoire des processus KVM. Mais comment ? /dev/mem n'est pas présent, en fouillant la mémoire processus par processus ? Une idée ?
Enfin il y a aussi la solution d'un MITM pour trafiquer les connexions réseaux avant qu'elles ne soient chiffrées par SSH et introduire des backdoors. Mais une fois de plus, les paquets Debian sont signés, les signatures vérifiées, je ne pense donc pas que ce soit trivial.
Ou alors je passe à côté de quelque chose ?
De prime abord, je dirais qu'à partir du moment où OVH a déjà *accédé physiquement* à votre serveur, avant même que vous y installiez quoi que ce soit, devrait logiquement vous laisser supposer qu'il est d'ores et déjà compromis. ;-)
X. -- syncing file systems... done Press any key to reboot.
Nicolas George
Yannix , dans le message <milci3$vnr$, a écrit :
Même pas. Les "boites noires" sont censées enregistrer qui communique avec qui au niveau 3 de l'OSI et en conclure "des choses" selon leurs algorithmes...
Déjà, pour ta gouverne, les niveaux OSI n'ont jamais été pertinents dans le cadre d'Internet, TCP/IP ne colle pas à ce modèle.
Ensuite... oui, si tu envoies tes paquets directement à la destination, les boîtes noires pourront conclure l'identité de ta destination. Point final.
Yannix , dans le message <milci3$vnr$1@speranza.aioe.org>, a écrit :
Même pas. Les "boites noires" sont censées enregistrer qui communique
avec qui au niveau 3 de l'OSI et en conclure "des choses" selon leurs
algorithmes...
Déjà, pour ta gouverne, les niveaux OSI n'ont jamais été pertinents dans le
cadre d'Internet, TCP/IP ne colle pas à ce modèle.
Ensuite... oui, si tu envoies tes paquets directement à la destination, les
boîtes noires pourront conclure l'identité de ta destination. Point final.
Même pas. Les "boites noires" sont censées enregistrer qui communique avec qui au niveau 3 de l'OSI et en conclure "des choses" selon leurs algorithmes...
Déjà, pour ta gouverne, les niveaux OSI n'ont jamais été pertinents dans le cadre d'Internet, TCP/IP ne colle pas à ce modèle.
Ensuite... oui, si tu envoies tes paquets directement à la destination, les boîtes noires pourront conclure l'identité de ta destination. Point final.
Yannix
Le 09/05/2015 20:51, Nicolas George a écrit :
Yannix , dans le message <milci3$vnr$, a écrit :
Même pas. Les "boites noires" sont censées enregistrer qui communique avec qui au niveau 3 de l'OSI et en conclure "des choses" selon leurs algorithmes...
Déjà, pour ta gouverne, les niveaux OSI n'ont jamais été pertinents dans le cadre d'Internet, TCP/IP ne colle pas à ce modèle.
Ah oui ? Tient ! Et pourquoi donc ?
Ensuite... oui, si tu envoies tes paquets directement à la destination, les boîtes noires pourront conclure l'identité de ta destination. Point final.
Tout à fait Thierry. Si Laurent ouvre un VPN sur IP comme il le souhaite, les "boites noires" mettront fatalement en relation son IP avec celle de son correspondant.
https://www.torproject.org/ ?
X. -- syncing file systems... done Press any key to reboot.
Le 09/05/2015 20:51, Nicolas George a écrit :
Yannix , dans le message <milci3$vnr$1@speranza.aioe.org>, a écrit :
Même pas. Les "boites noires" sont censées enregistrer qui communique
avec qui au niveau 3 de l'OSI et en conclure "des choses" selon leurs
algorithmes...
Déjà, pour ta gouverne, les niveaux OSI n'ont jamais été pertinents dans le
cadre d'Internet, TCP/IP ne colle pas à ce modèle.
Ah oui ? Tient ! Et pourquoi donc ?
Ensuite... oui, si tu envoies tes paquets directement à la destination, les
boîtes noires pourront conclure l'identité de ta destination. Point final.
Tout à fait Thierry. Si Laurent ouvre un VPN sur IP comme il le
souhaite, les "boites noires" mettront fatalement en relation son IP
avec celle de son correspondant.
https://www.torproject.org/ ?
X.
--
syncing file systems... done
Press any key to reboot.
Même pas. Les "boites noires" sont censées enregistrer qui communique avec qui au niveau 3 de l'OSI et en conclure "des choses" selon leurs algorithmes...
Déjà, pour ta gouverne, les niveaux OSI n'ont jamais été pertinents dans le cadre d'Internet, TCP/IP ne colle pas à ce modèle.
Ah oui ? Tient ! Et pourquoi donc ?
Ensuite... oui, si tu envoies tes paquets directement à la destination, les boîtes noires pourront conclure l'identité de ta destination. Point final.
Tout à fait Thierry. Si Laurent ouvre un VPN sur IP comme il le souhaite, les "boites noires" mettront fatalement en relation son IP avec celle de son correspondant.
https://www.torproject.org/ ?
X. -- syncing file systems... done Press any key to reboot.
Nicolas George
Yannix , dans le message <milvp0$fe3$, a écrit :
Ah oui ? Tient ! Et pourquoi donc ?
Parce que le modèle OSI a été conçu par un comité Théodule alors que TCP/IP a été conçu par des gens de terrain.
Tout à fait Thierry. Si Laurent ouvre un VPN sur IP comme il le souhaite, les "boites noires" mettront fatalement en relation son IP avec celle de son correspondant.
Mais pas ce que vous vous dites.
https://www.torproject.org/ ?
Aussi, oui.
Yannix , dans le message <milvp0$fe3$1@speranza.aioe.org>, a écrit :
Ah oui ? Tient ! Et pourquoi donc ?
Parce que le modèle OSI a été conçu par un comité Théodule alors que TCP/IP
a été conçu par des gens de terrain.
Tout à fait Thierry. Si Laurent ouvre un VPN sur IP comme il le
souhaite, les "boites noires" mettront fatalement en relation son IP
avec celle de son correspondant.
Parce que le modèle OSI a été conçu par un comité Théodule alors que TCP/IP a été conçu par des gens de terrain.
Tout à fait Thierry. Si Laurent ouvre un VPN sur IP comme il le souhaite, les "boites noires" mettront fatalement en relation son IP avec celle de son correspondant.
Mais pas ce que vous vous dites.
https://www.torproject.org/ ?
Aussi, oui.
Yannix
Le 10/05/2015 00:21, Nicolas George a écrit :
Yannix , dans le message <milvp0$fe3$, a écrit :
Ah oui ? Tient ! Et pourquoi donc ?
Parce que le modèle OSI a été conçu par un comité Théodule alors que TCP/IP a été conçu par des gens de terrain.
Tout à fait Thierry. Si Laurent ouvre un VPN sur IP comme il le souhaite, les "boites noires" mettront fatalement en relation son IP avec celle de son correspondant.
Mais pas ce que vous vous dites.
https://www.torproject.org/ ?
Aussi, oui.
D'où l'idée de faire de l'IPSec via Tor ?
X. -- syncing file systems... done Press any key to reboot.
Le 10/05/2015 00:21, Nicolas George a écrit :
Yannix , dans le message <milvp0$fe3$1@speranza.aioe.org>, a écrit :
Ah oui ? Tient ! Et pourquoi donc ?
Parce que le modèle OSI a été conçu par un comité Théodule alors que TCP/IP
a été conçu par des gens de terrain.
Tout à fait Thierry. Si Laurent ouvre un VPN sur IP comme il le
souhaite, les "boites noires" mettront fatalement en relation son IP
avec celle de son correspondant.
Mais pas ce que vous vous dites.
https://www.torproject.org/ ?
Aussi, oui.
D'où l'idée de faire de l'IPSec via Tor ?
X.
--
syncing file systems... done
Press any key to reboot.
Parce que le modèle OSI a été conçu par un comité Théodule alors que TCP/IP a été conçu par des gens de terrain.
Tout à fait Thierry. Si Laurent ouvre un VPN sur IP comme il le souhaite, les "boites noires" mettront fatalement en relation son IP avec celle de son correspondant.
Mais pas ce que vous vous dites.
https://www.torproject.org/ ?
Aussi, oui.
D'où l'idée de faire de l'IPSec via Tor ?
X. -- syncing file systems... done Press any key to reboot.
Kevin Denis
Le 09-05-2015, laurent a écrit :
- le serveur est arrêté. Les containers sont donc chiffrés et à priori indéchiffrables (on part du principe que AES-256 est fiable ) ;
Même si AES est fiable, certaines attaques sont possibles. Dans certains cas dmcrypt offline est vulnérable à une attaque par malléabilité: http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/
Ensuite, lorsque tu allumes ta machine, tu ne bootes pas sur du chiffré, tu bootes sur /boot qui contient un noyau et un initrd en clair. Si on a modifié ce noyau et cet initrd pour keylogger ton mot de passe luks, c'est perdu.
- la machine est allumée, OVH peut prendre la main en console dessus mais ne dispose à priori pas des mots de passes et ne peut donc pas rentrer. Admettons qu'ils rentrent quand même (j'aimerai savoir comment sachant que j'ai réinstallé la machine complètement avec un noyau Vanilla et les drivers d'origine) : -> ils se retrouvent sur un host avec rien dedans hormis un vSwitch et des containers qui tournent. Ils peuvent accéder aux données non chiffrées qui transitent sur le vSwitch et les interfaces réseau. Ils peuvent sûrement accéder à des clés de chiffrement en fouillant la mémoire des processus KVM. Mais comment ? /dev/mem n'est pas présent, en fouillant la mémoire processus par processus ? Une idée ?
https://citp.princeton.edu/research/memory/ La RAM peut être lue, même après un arrêt brutal. Donc lorsque ta machine est allumée, tes containers sont ouverts et les clés sont en mémoire. OVH peut donc faire un arrêt brutal du serveur, lire les clés et déchiffrer tes containers.
Après, je ne connais pas l'infra OVH et la manière dont tu connectes, mais il peut y avoir encore pleins de failles: sniffer sur un KVM si tu en utilises un par exemple. -- Kevin
Le 09-05-2015, laurent <laurent@none.fr.invalid> a écrit :
- le serveur est arrêté. Les containers sont donc chiffrés et à priori
indéchiffrables (on part du principe que AES-256 est fiable ) ;
Même si AES est fiable, certaines attaques sont possibles. Dans
certains cas dmcrypt offline est vulnérable à une attaque par malléabilité:
http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/
Ensuite, lorsque tu allumes ta machine, tu ne bootes pas sur du chiffré,
tu bootes sur /boot qui contient un noyau et un initrd en clair. Si on
a modifié ce noyau et cet initrd pour keylogger ton mot de passe luks,
c'est perdu.
- la machine est allumée, OVH peut prendre la main en console dessus
mais ne dispose à priori pas des mots de passes et ne peut donc pas
rentrer. Admettons qu'ils rentrent quand même (j'aimerai savoir comment
sachant que j'ai réinstallé la machine complètement avec un noyau
Vanilla et les drivers d'origine) :
-> ils se retrouvent sur un host avec rien dedans hormis un vSwitch et
des containers qui tournent. Ils peuvent accéder aux données non
chiffrées qui transitent sur le vSwitch et les interfaces réseau. Ils
peuvent sûrement accéder à des clés de chiffrement en fouillant la
mémoire des processus KVM. Mais comment ? /dev/mem n'est pas présent, en
fouillant la mémoire processus par processus ? Une idée ?
https://citp.princeton.edu/research/memory/
La RAM peut être lue, même après un arrêt brutal. Donc lorsque ta machine
est allumée, tes containers sont ouverts et les clés sont en mémoire.
OVH peut donc faire un arrêt brutal du serveur, lire les clés et déchiffrer
tes containers.
Après, je ne connais pas l'infra OVH et la manière dont tu connectes, mais
il peut y avoir encore pleins de failles: sniffer sur un KVM si tu en
utilises un par exemple.
--
Kevin
- le serveur est arrêté. Les containers sont donc chiffrés et à priori indéchiffrables (on part du principe que AES-256 est fiable ) ;
Même si AES est fiable, certaines attaques sont possibles. Dans certains cas dmcrypt offline est vulnérable à une attaque par malléabilité: http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/
Ensuite, lorsque tu allumes ta machine, tu ne bootes pas sur du chiffré, tu bootes sur /boot qui contient un noyau et un initrd en clair. Si on a modifié ce noyau et cet initrd pour keylogger ton mot de passe luks, c'est perdu.
- la machine est allumée, OVH peut prendre la main en console dessus mais ne dispose à priori pas des mots de passes et ne peut donc pas rentrer. Admettons qu'ils rentrent quand même (j'aimerai savoir comment sachant que j'ai réinstallé la machine complètement avec un noyau Vanilla et les drivers d'origine) : -> ils se retrouvent sur un host avec rien dedans hormis un vSwitch et des containers qui tournent. Ils peuvent accéder aux données non chiffrées qui transitent sur le vSwitch et les interfaces réseau. Ils peuvent sûrement accéder à des clés de chiffrement en fouillant la mémoire des processus KVM. Mais comment ? /dev/mem n'est pas présent, en fouillant la mémoire processus par processus ? Une idée ?
https://citp.princeton.edu/research/memory/ La RAM peut être lue, même après un arrêt brutal. Donc lorsque ta machine est allumée, tes containers sont ouverts et les clés sont en mémoire. OVH peut donc faire un arrêt brutal du serveur, lire les clés et déchiffrer tes containers.
Après, je ne connais pas l'infra OVH et la manière dont tu connectes, mais il peut y avoir encore pleins de failles: sniffer sur un KVM si tu en utilises un par exemple. -- Kevin
