Dans le cas d'un litige sur l'horodatage d'un email ou d'un fichier, je
cherche quels outils avons-nous pour certifier que l'heure affectée à ce
courrier ou à ce fichier reçu est la même que celle du ser veur ntp sur
lequel est branché la machine à un poulième de delta prà ¨s?
Je cherche juste à pouvoir produire la preuve qu'un fichier dép osé sur ma
machine ou un email reçu porte l'heure d'un serveur de temps reconnu par au
moins une large population d'utilisateurs pensant que c'est suffisant pou r
faire autorité.
Dans le cas d'un litige sur l'horodatage d'un email ou d'un fichier, je
cherche quels outils avons-nous pour certifier que l'heure affectée à ce
courrier ou à ce fichier reçu est la même que celle du ser veur ntp sur
lequel est branché la machine à un poulième de delta prà ¨s?
Je cherche juste à pouvoir produire la preuve qu'un fichier dép osé sur ma
machine ou un email reçu porte l'heure d'un serveur de temps reconnu par au
moins une large population d'utilisateurs pensant que c'est suffisant pou r
faire autorité.
Dans le cas d'un litige sur l'horodatage d'un email ou d'un fichier, je
cherche quels outils avons-nous pour certifier que l'heure affectée à ce
courrier ou à ce fichier reçu est la même que celle du ser veur ntp sur
lequel est branché la machine à un poulième de delta prà ¨s?
Je cherche juste à pouvoir produire la preuve qu'un fichier dép osé sur ma
machine ou un email reçu porte l'heure d'un serveur de temps reconnu par au
moins une large population d'utilisateurs pensant que c'est suffisant pou r
faire autorité.
On Fri, 21 Jan 2011 11:36:25 +0100, Alain Vaugham
wrote:
...
> Dans le cas d'un litige sur l'horodatage d'un email ou d'un fichier, je
> cherche quels outils avons-nous pour certifier que l'heure affecté e à ce
> courrier ou à ce fichier reçu est la même que celle du s erveur ntp sur
> lequel est branché la machine à un poulième de delta pr ès?
...
> Je cherche juste à pouvoir produire la preuve qu'un fichier dà ©posé sur ma
> machine ou un email reçu porte l'heure d'un serveur de temps recon nu par
> au moins une large population d'utilisateurs pensant que c'est suffisant
> pour faire autorité.
Au fait, il me vient quelques questions/affirmations subsidiaires:
Si tu as besoin de cela, c'est que c'est important (CQFD), DONC:
* Tes users & destinataires utilisent tous un chiffrement de leurs emails
(clé gpg de 2048bits) avec une signature électronique certi fiée!?
* Ton svr SMTP ne correspond qu'avec d'autres SMTPs bien identifiés et
encrypte toutes ses transmissions?!
* L'accès à ton SMTP ne peut se faire que par SSL, avec un cert ificat
différent pour chaque user?!
Parce que sans cela... avant de savoir quand, qui peut savoir qui a envoy é
quoi à qui d'autre?
Le cadre :
Les emails reçus, les fichiers déposés ainsi que les fax ( Hylafax) ce sont
des commandes clients.
Notre horodatage marque le point de départ d'un processus.
Actuellement, seuls fonctionnent les emails et les faxes.
On Fri, 21 Jan 2011 11:36:25 +0100, Alain Vaugham <alain@vaugham.com>
wrote:
...
> Dans le cas d'un litige sur l'horodatage d'un email ou d'un fichier, je
> cherche quels outils avons-nous pour certifier que l'heure affecté e à ce
> courrier ou à ce fichier reçu est la même que celle du s erveur ntp sur
> lequel est branché la machine à un poulième de delta pr ès?
...
> Je cherche juste à pouvoir produire la preuve qu'un fichier dà ©posé sur ma
> machine ou un email reçu porte l'heure d'un serveur de temps recon nu par
> au moins une large population d'utilisateurs pensant que c'est suffisant
> pour faire autorité.
Au fait, il me vient quelques questions/affirmations subsidiaires:
Si tu as besoin de cela, c'est que c'est important (CQFD), DONC:
* Tes users & destinataires utilisent tous un chiffrement de leurs emails
(clé gpg de 2048bits) avec une signature électronique certi fiée!?
* Ton svr SMTP ne correspond qu'avec d'autres SMTPs bien identifiés et
encrypte toutes ses transmissions?!
* L'accès à ton SMTP ne peut se faire que par SSL, avec un cert ificat
différent pour chaque user?!
Parce que sans cela... avant de savoir quand, qui peut savoir qui a envoy é
quoi à qui d'autre?
Le cadre :
Les emails reçus, les fichiers déposés ainsi que les fax ( Hylafax) ce sont
des commandes clients.
Notre horodatage marque le point de départ d'un processus.
Actuellement, seuls fonctionnent les emails et les faxes.
On Fri, 21 Jan 2011 11:36:25 +0100, Alain Vaugham
wrote:
...
> Dans le cas d'un litige sur l'horodatage d'un email ou d'un fichier, je
> cherche quels outils avons-nous pour certifier que l'heure affecté e à ce
> courrier ou à ce fichier reçu est la même que celle du s erveur ntp sur
> lequel est branché la machine à un poulième de delta pr ès?
...
> Je cherche juste à pouvoir produire la preuve qu'un fichier dà ©posé sur ma
> machine ou un email reçu porte l'heure d'un serveur de temps recon nu par
> au moins une large population d'utilisateurs pensant que c'est suffisant
> pour faire autorité.
Au fait, il me vient quelques questions/affirmations subsidiaires:
Si tu as besoin de cela, c'est que c'est important (CQFD), DONC:
* Tes users & destinataires utilisent tous un chiffrement de leurs emails
(clé gpg de 2048bits) avec une signature électronique certi fiée!?
* Ton svr SMTP ne correspond qu'avec d'autres SMTPs bien identifiés et
encrypte toutes ses transmissions?!
* L'accès à ton SMTP ne peut se faire que par SSL, avec un cert ificat
différent pour chaque user?!
Parce que sans cela... avant de savoir quand, qui peut savoir qui a envoy é
quoi à qui d'autre?
Le cadre :
Les emails reçus, les fichiers déposés ainsi que les fax ( Hylafax) ce sont
des commandes clients.
Notre horodatage marque le point de départ d'un processus.
Actuellement, seuls fonctionnent les emails et les faxes.
Alors oui, c'est important (CQFD).
Oui, c'est très important d'avoir une chaîne de traitement du c ourrier avec
du TLS comme tu le soulignes et c'est déjà fait en interne jusq u'au Postfix.
Reste un problème de port 25 à résoudre chez le FAI pour q ue le Postfix
relaie directement.
On est passé en mode HS là .
Dans le cadre de ma recherche, demander à des partenaires commerciau x
d'utiliser GPG pour des emails n'est pas concevable.
Pour exemple, j'ai affaire à certains qui sont prêts à env oyer **tous** les
détails de leur carte bancaire sur une carte postale sans enveloppe : c'est
à dire par email. No comments.
J'ai affaire à d'autres qui n'ont aucune intention d'apporter une qu elconque
modif dans leur organisation. C'est la majorité et c'est leur libert é.
De plus, le flux le plus volumineux est celui des fax.
C'est peut-être parceque ces clients-là sont justement sensibil isés au
problème des emails.
Hylafax fonctionne lui en mode connecté.
Les fichiers TIFF/pdf sont passés à Postfix et Procmail y met s a griffe :
c'est le champX que j'ai mentionné précédemment.
Je ne cherche pas une solution qui impose un changement de méthode p our
certains, mais une solution qui permet un consensus avec un minimum
d'efforts pour moi.
Alors oui, c'est important (CQFD).
Oui, c'est très important d'avoir une chaîne de traitement du c ourrier avec
du TLS comme tu le soulignes et c'est déjà fait en interne jusq u'au Postfix.
Reste un problème de port 25 à résoudre chez le FAI pour q ue le Postfix
relaie directement.
On est passé en mode HS là .
Dans le cadre de ma recherche, demander à des partenaires commerciau x
d'utiliser GPG pour des emails n'est pas concevable.
Pour exemple, j'ai affaire à certains qui sont prêts à env oyer **tous** les
détails de leur carte bancaire sur une carte postale sans enveloppe : c'est
à dire par email. No comments.
J'ai affaire à d'autres qui n'ont aucune intention d'apporter une qu elconque
modif dans leur organisation. C'est la majorité et c'est leur libert é.
De plus, le flux le plus volumineux est celui des fax.
C'est peut-être parceque ces clients-là sont justement sensibil isés au
problème des emails.
Hylafax fonctionne lui en mode connecté.
Les fichiers TIFF/pdf sont passés à Postfix et Procmail y met s a griffe :
c'est le champX que j'ai mentionné précédemment.
Je ne cherche pas une solution qui impose un changement de méthode p our
certains, mais une solution qui permet un consensus avec un minimum
d'efforts pour moi.
Alors oui, c'est important (CQFD).
Oui, c'est très important d'avoir une chaîne de traitement du c ourrier avec
du TLS comme tu le soulignes et c'est déjà fait en interne jusq u'au Postfix.
Reste un problème de port 25 à résoudre chez le FAI pour q ue le Postfix
relaie directement.
On est passé en mode HS là .
Dans le cadre de ma recherche, demander à des partenaires commerciau x
d'utiliser GPG pour des emails n'est pas concevable.
Pour exemple, j'ai affaire à certains qui sont prêts à env oyer **tous** les
détails de leur carte bancaire sur une carte postale sans enveloppe : c'est
à dire par email. No comments.
J'ai affaire à d'autres qui n'ont aucune intention d'apporter une qu elconque
modif dans leur organisation. C'est la majorité et c'est leur libert é.
De plus, le flux le plus volumineux est celui des fax.
C'est peut-être parceque ces clients-là sont justement sensibil isés au
problème des emails.
Hylafax fonctionne lui en mode connecté.
Les fichiers TIFF/pdf sont passés à Postfix et Procmail y met s a griffe :
c'est le champX que j'ai mentionné précédemment.
Je ne cherche pas une solution qui impose un changement de méthode p our
certains, mais une solution qui permet un consensus avec un minimum
d'efforts pour moi.
S'il ne coopère pas, change de port (en Gal 443 reste ouvert.)
Tout dépend si tu vends des paniers moules, auquel cas pas de PB, ou de la
haute technologie, auquel cas GROS PB.
Je dirais qu'en l'état actuel des choses, soit tu sécurises *to ute* la
chaîne, avec logs signés, SMTP 'amis' only, etc; soit tu reste au même
niveau, et dans ce cas, un logging de 'ntptrace' suffit largement puisqu' il
te donne l'écart avec le svr ntp externe.
Il existe aussi la poss. d'accèder à certains svrs ntp d'une fa çon
sécurisée (chiffrage assym.): le package 'ntp-doc' est ton pote sur ce coup
là ;
mais je persiste en disant que c'est disproportionné par rapport à la
sécurité aléatoire du reste de la chaîne:
S'il ne coopère pas, change de port (en Gal 443 reste ouvert.)
Tout dépend si tu vends des paniers moules, auquel cas pas de PB, ou de la
haute technologie, auquel cas GROS PB.
Je dirais qu'en l'état actuel des choses, soit tu sécurises *to ute* la
chaîne, avec logs signés, SMTP 'amis' only, etc; soit tu reste au même
niveau, et dans ce cas, un logging de 'ntptrace' suffit largement puisqu' il
te donne l'écart avec le svr ntp externe.
Il existe aussi la poss. d'accèder à certains svrs ntp d'une fa çon
sécurisée (chiffrage assym.): le package 'ntp-doc' est ton pote sur ce coup
là ;
mais je persiste en disant que c'est disproportionné par rapport à la
sécurité aléatoire du reste de la chaîne:
S'il ne coopère pas, change de port (en Gal 443 reste ouvert.)
Tout dépend si tu vends des paniers moules, auquel cas pas de PB, ou de la
haute technologie, auquel cas GROS PB.
Je dirais qu'en l'état actuel des choses, soit tu sécurises *to ute* la
chaîne, avec logs signés, SMTP 'amis' only, etc; soit tu reste au même
niveau, et dans ce cas, un logging de 'ntptrace' suffit largement puisqu' il
te donne l'écart avec le svr ntp externe.
Il existe aussi la poss. d'accèder à certains svrs ntp d'une fa çon
sécurisée (chiffrage assym.): le package 'ntp-doc' est ton pote sur ce coup
là ;
mais je persiste en disant que c'est disproportionné par rapport à la
sécurité aléatoire du reste de la chaîne:
> Je dirais qu'en l'état actuel des choses, soit tu sécurises * toute* la
> chaîne, avec logs signés, SMTP 'amis' only, etc; soit tu rest e au même
> niveau, et dans ce cas, un logging de 'ntptrace' suffit largement puisq u'il
> te donne l'écart avec le svr ntp externe.
Cette suggestion me plait beaucoup au sens que c'est autonome.
Elle ne tiendra pas face à certains tiers en l'absence d'audit mais elle a
l'avantage de montrer qu'une action a été mise en place.
> Je dirais qu'en l'état actuel des choses, soit tu sécurises * toute* la
> chaîne, avec logs signés, SMTP 'amis' only, etc; soit tu rest e au même
> niveau, et dans ce cas, un logging de 'ntptrace' suffit largement puisq u'il
> te donne l'écart avec le svr ntp externe.
Cette suggestion me plait beaucoup au sens que c'est autonome.
Elle ne tiendra pas face à certains tiers en l'absence d'audit mais elle a
l'avantage de montrer qu'une action a été mise en place.
> Je dirais qu'en l'état actuel des choses, soit tu sécurises * toute* la
> chaîne, avec logs signés, SMTP 'amis' only, etc; soit tu rest e au même
> niveau, et dans ce cas, un logging de 'ntptrace' suffit largement puisq u'il
> te donne l'écart avec le svr ntp externe.
Cette suggestion me plait beaucoup au sens que c'est autonome.
Elle ne tiendra pas face à certains tiers en l'absence d'audit mais elle a
l'avantage de montrer qu'une action a été mise en place.
C'est peut-être parceque ces clients-là sont justement sensibilisés au
problème des emails.
Hylafax fonctionne lui en mode connecté.
C'est peut-être parceque ces clients-là sont justement sensibilisés au
problème des emails.
Hylafax fonctionne lui en mode connecté.
C'est peut-être parceque ces clients-là sont justement sensibilisés au
problème des emails.
Hylafax fonctionne lui en mode connecté.
Faudra quand même leur rappeler que le fax a le même niveau
de sécurité que l'e-mail: aucune confidentialité, aucune
garantie que ça arrive, et aucune authentification de
l'émetteur.
Y.
Faudra quand même leur rappeler que le fax a le même niveau
de sécurité que l'e-mail: aucune confidentialité, aucune
garantie que ça arrive, et aucune authentification de
l'émetteur.
Y.
Faudra quand même leur rappeler que le fax a le même niveau
de sécurité que l'e-mail: aucune confidentialité, aucune
garantie que ça arrive, et aucune authentification de
l'émetteur.
Y.
On Fri, Jan 21, 2011 at 06:46:01PM +0100, Alain Vaugham wrote:
> C'est peut-être parceque ces clients-là sont justement sensibilis és au
> problème des emails.
> Hylafax fonctionne lui en mode connecté.
Faudra quand même leur rappeler que le fax a le même niveau
de sécurité que l'e-mail: aucune confidentialité,
aucune garantie que ça arrive,
et aucune authentification de l'émetteur.
On Fri, Jan 21, 2011 at 06:46:01PM +0100, Alain Vaugham wrote:
> C'est peut-être parceque ces clients-là sont justement sensibilis és au
> problème des emails.
> Hylafax fonctionne lui en mode connecté.
Faudra quand même leur rappeler que le fax a le même niveau
de sécurité que l'e-mail: aucune confidentialité,
aucune garantie que ça arrive,
et aucune authentification de l'émetteur.
On Fri, Jan 21, 2011 at 06:46:01PM +0100, Alain Vaugham wrote:
> C'est peut-être parceque ces clients-là sont justement sensibilis és au
> problème des emails.
> Hylafax fonctionne lui en mode connecté.
Faudra quand même leur rappeler que le fax a le même niveau
de sécurité que l'e-mail: aucune confidentialité,
aucune garantie que ça arrive,
et aucune authentification de l'émetteur.
aucune garantie que ça arrive,
Sûr de ça?
ça doit pourtant arriver...
Peut-être pas en entier, peut-être pas dans le même état qu'au départ, ni
peut-être pas à la bonne destination, mais si on écoute l'engueulade entre
deux modems qui cherchent à s'accorder sur le groupe dont il font partie, la
définition des pages, la vitesse de transfert, les frames déjà transmises,
etc... c'est bien qu'ils sont connectés. D'autant plus que si un troisième
larron veut intervenir il sera gentiment prié d'attendre avec une tonalité
d'occupation que l'engueulade en cours soit terminée par la réception d'un
Disconnect.
Il y a autre chose que je ne vois pas?
aucune garantie que ça arrive,
Sûr de ça?
ça doit pourtant arriver...
Peut-être pas en entier, peut-être pas dans le même état qu'au départ, ni
peut-être pas à la bonne destination, mais si on écoute l'engueulade entre
deux modems qui cherchent à s'accorder sur le groupe dont il font partie, la
définition des pages, la vitesse de transfert, les frames déjà transmises,
etc... c'est bien qu'ils sont connectés. D'autant plus que si un troisième
larron veut intervenir il sera gentiment prié d'attendre avec une tonalité
d'occupation que l'engueulade en cours soit terminée par la réception d'un
Disconnect.
Il y a autre chose que je ne vois pas?
aucune garantie que ça arrive,
Sûr de ça?
ça doit pourtant arriver...
Peut-être pas en entier, peut-être pas dans le même état qu'au départ, ni
peut-être pas à la bonne destination, mais si on écoute l'engueulade entre
deux modems qui cherchent à s'accorder sur le groupe dont il font partie, la
définition des pages, la vitesse de transfert, les frames déjà transmises,
etc... c'est bien qu'ils sont connectés. D'autant plus que si un troisième
larron veut intervenir il sera gentiment prié d'attendre avec une tonalité
d'occupation que l'engueulade en cours soit terminée par la réception d'un
Disconnect.
Il y a autre chose que je ne vois pas?
> aucune garantie que ça arrive,
Sûr de ça?
ça doit pourtant arriver...
Peut-être pas en entier, peut-être pas dans le même état qu'au départ, ni
peut-être pas à la bonne destination, mais si on écoute l'engueulade entre
deux modems qui cherchent à s'accorder sur le groupe dont il font partie, la
définition des pages, la vitesse de transfert, les frames déjà transmises,
etc... c'est bien qu'ils sont connectés. D'autant plus que si un troisième
larron veut intervenir il sera gentiment prié d'attendre avec une tonalité
d'occupation que l'engueulade en cours soit terminée par la réception d'un
Disconnect.
Il y a autre chose que je ne vois pas?
Par contre, la notion d'horodatage non forgé/trafiqué reste un élément
important même si il n'atteint pas la précision atomique.
On est dans une zone de mesure à échelle humaine.
C'est pareil dans un bureau de poste de la vie réelle. Je n'ai pas encore vu
un préposé demander à vérifier l'identité de la personne qui dépose une LR
avec AR.
Moi je pense que ces utilisateurs-là sont actuellement plus confiants dans la
transmission d'une télécopie que dans celle d'un email. Le jour où la
situation de l'email évoluera, ils appuieront sur l'autre bouton de leur ERP.
> aucune garantie que ça arrive,
Sûr de ça?
ça doit pourtant arriver...
Peut-être pas en entier, peut-être pas dans le même état qu'au départ, ni
peut-être pas à la bonne destination, mais si on écoute l'engueulade entre
deux modems qui cherchent à s'accorder sur le groupe dont il font partie, la
définition des pages, la vitesse de transfert, les frames déjà transmises,
etc... c'est bien qu'ils sont connectés. D'autant plus que si un troisième
larron veut intervenir il sera gentiment prié d'attendre avec une tonalité
d'occupation que l'engueulade en cours soit terminée par la réception d'un
Disconnect.
Il y a autre chose que je ne vois pas?
Par contre, la notion d'horodatage non forgé/trafiqué reste un élément
important même si il n'atteint pas la précision atomique.
On est dans une zone de mesure à échelle humaine.
C'est pareil dans un bureau de poste de la vie réelle. Je n'ai pas encore vu
un préposé demander à vérifier l'identité de la personne qui dépose une LR
avec AR.
Moi je pense que ces utilisateurs-là sont actuellement plus confiants dans la
transmission d'une télécopie que dans celle d'un email. Le jour où la
situation de l'email évoluera, ils appuieront sur l'autre bouton de leur ERP.
> aucune garantie que ça arrive,
Sûr de ça?
ça doit pourtant arriver...
Peut-être pas en entier, peut-être pas dans le même état qu'au départ, ni
peut-être pas à la bonne destination, mais si on écoute l'engueulade entre
deux modems qui cherchent à s'accorder sur le groupe dont il font partie, la
définition des pages, la vitesse de transfert, les frames déjà transmises,
etc... c'est bien qu'ils sont connectés. D'autant plus que si un troisième
larron veut intervenir il sera gentiment prié d'attendre avec une tonalité
d'occupation que l'engueulade en cours soit terminée par la réception d'un
Disconnect.
Il y a autre chose que je ne vois pas?
Par contre, la notion d'horodatage non forgé/trafiqué reste un élément
important même si il n'atteint pas la précision atomique.
On est dans une zone de mesure à échelle humaine.
C'est pareil dans un bureau de poste de la vie réelle. Je n'ai pas encore vu
un préposé demander à vérifier l'identité de la personne qui dépose une LR
avec AR.
Moi je pense que ces utilisateurs-là sont actuellement plus confiants dans la
transmission d'une télécopie que dans celle d'un email. Le jour où la
situation de l'email évoluera, ils appuieront sur l'autre bouton de leur ERP.
