Quand vous installez windows, l'essentiel fonctionne. Sur le champ.
Quans vous installez linux, la plupart des trucs marchent plus ou moins. Et
une bonne partie ne marche pas du tout.
Linux pour le grand public c'est N.U.L. A fuir d'urgence.
Les différentes distros courent derrière Microsoft en essayant d'imiter son
interface, et ses fonctions... Mais elles restent éternellemnt en retrait
quant à la qualité, à l'efficacité à l'agrément d'utilisation. Et ce, depuis
bientôt dix ans.
Tout ce qui peut se réaliser intuitivement et vite sous Windows, demande des
heures de prise de tête sous Linux.
Et quand vous croyez que ça fonctionne enfin, vous ne tardez pas à découvrir
que ça ne fonctionne qu'en surface.. Et que des tas de détails continuent à
merder en sous-main.
Bref, linux c'est clairement de la daube.
Avant de vous laisser emporter par l'enthousiasme du néophyte, avant de vous
laisser tourner la tête par l'aspect "alternatif, communautaire,
altermondialiste-écologiste", dites vous bien que si Linux était une
expérience viable, depuis le temps, ça se saurait.
Gagnez du temps : restez sous Windows.
Et non, ce n'est pas un troll. Laissez tomber votre politiquement correct de
merde et dites enfin les choses telles qu'elles sont
le SSH qui devrait etre en UDP plutot qu'en TCP pour etre vraiment secure ...
???
Stephane TOUGARD
Nicolas George wrote:
le SSH qui devrait etre en UDP plutot qu'en TCP pour etre vraiment secure ...
???
C'est le principe du VPN, le serveur ne repond QUE SI le paquet est correctement et totalement formate. L'UDP etant non connecte, il presente aussi d'autres avantages en terme de fiabilite et sait mieux reagir a des connexions Internet qui sautillent dans tous les sens.
Nicolas George wrote:
le SSH qui devrait etre en UDP
plutot qu'en TCP pour etre vraiment secure ...
???
C'est le principe du VPN, le serveur ne repond QUE SI le paquet est
correctement et totalement formate. L'UDP etant non connecte, il
presente aussi d'autres avantages en terme de fiabilite et sait mieux
reagir a des connexions Internet qui sautillent dans tous les sens.
le SSH qui devrait etre en UDP plutot qu'en TCP pour etre vraiment secure ...
???
C'est le principe du VPN, le serveur ne repond QUE SI le paquet est correctement et totalement formate. L'UDP etant non connecte, il presente aussi d'autres avantages en terme de fiabilite et sait mieux reagir a des connexions Internet qui sautillent dans tous les sens.
Nicolas George
Stephane TOUGARD , dans le message , a écrit :
C'est le principe du VPN,
SSH n'a rien à voir avec un VPN, je ne vois pas le rapport.
le serveur ne repond QUE SI le paquet est correctement et totalement formate.
C'est le cas partout où on veut de la sécurité.
L'UDP etant non connecte, il presente aussi d'autres avantages en terme de fiabilite et sait mieux reagir a des connexions Internet qui sautillent dans tous les sens.
Non, justement. Quand la connexion sautille, les paquets UDP se perdent. Pour réagir à une connexion médiocre, il faut que l'application implémente un système de réémission, ce qu'en général elle fait moins bien que TCP.
De plus, avec un protocole en UDP, chaque paquet doit être chiffré de manière isolée, ce qui rend le chiffrement plus faible.
Stephane TOUGARD , dans le message
<tkb436-j3c1.ln1@gulliver.unices.org>, a écrit :
C'est le principe du VPN,
SSH n'a rien à voir avec un VPN, je ne vois pas le rapport.
le serveur ne repond QUE SI le paquet est
correctement et totalement formate.
C'est le cas partout où on veut de la sécurité.
L'UDP etant non connecte, il
presente aussi d'autres avantages en terme de fiabilite et sait mieux
reagir a des connexions Internet qui sautillent dans tous les sens.
Non, justement. Quand la connexion sautille, les paquets UDP se perdent.
Pour réagir à une connexion médiocre, il faut que l'application implémente
un système de réémission, ce qu'en général elle fait moins bien que TCP.
De plus, avec un protocole en UDP, chaque paquet doit être chiffré de
manière isolée, ce qui rend le chiffrement plus faible.
SSH n'a rien à voir avec un VPN, je ne vois pas le rapport.
le serveur ne repond QUE SI le paquet est correctement et totalement formate.
C'est le cas partout où on veut de la sécurité.
L'UDP etant non connecte, il presente aussi d'autres avantages en terme de fiabilite et sait mieux reagir a des connexions Internet qui sautillent dans tous les sens.
Non, justement. Quand la connexion sautille, les paquets UDP se perdent. Pour réagir à une connexion médiocre, il faut que l'application implémente un système de réémission, ce qu'en général elle fait moins bien que TCP.
De plus, avec un protocole en UDP, chaque paquet doit être chiffré de manière isolée, ce qui rend le chiffrement plus faible.
Patrice Karatchentzeff
Stephane TOUGARD a écrit :
C'est le principe du VPN, le serveur ne repond QUE SI le paquet est correctement et totalement formate. L'UDP etant non connecte, il presente aussi d'autres avantages en terme de fiabilite et sait mieux reagir a des connexions Internet qui sautillent dans tous les sens.
C'est le principe du VPN, le serveur ne repond QUE SI le paquet est
correctement et totalement formate. L'UDP etant non connecte, il
presente aussi d'autres avantages en terme de fiabilite et sait mieux
reagir a des connexions Internet qui sautillent dans tous les sens.
C'est le principe du VPN, le serveur ne repond QUE SI le paquet est correctement et totalement formate. L'UDP etant non connecte, il presente aussi d'autres avantages en terme de fiabilite et sait mieux reagir a des connexions Internet qui sautillent dans tous les sens.
SSH n'a rien à voir avec un VPN, je ne vois pas le rapport.
C'est marrant ta reponse. Elle ne m'etonne meme pas.
le serveur ne repond QUE SI le paquet est correctement et totalement formate.
C'est le cas partout où on veut de la sécurité.
Ah bon ?
:~$ telnet www.unices.org 22 Trying 203.81.54.120... Connected to sg3.propolys.com.sg. Escape character is '^]'. SSH-2.0-OpenSSH_4.5p1 FreeBSD-20061110
Oh, mon serveur ssh a repondu quelque chose sur un paquet mal formate.
C'est peut etre pas grand chose, mais ca donne deja une information : le serveur ssh tourne et on peut tester toutes les failles connues.
Sur le meme serveur tourne egalement quelques VPN en UDP, va me les trouver qu'on rigole. Eux ne repondent RIEN, absolument RIEN tant que le paquet emis n'est pas absolument celui attendu.
Non, justement. Quand la connexion sautille, les paquets UDP se perdent. Pour réagir à une connexion médiocre, il faut que l'application implémente un système de réémission, ce qu'en général elle fait moins bien que TCP.
ssh over vpn, tu verras qu'en terme de fiabilite c'est largement superieur a du ssh direct. Meme avec une connection RTC deconnecte puis reconnecte, tu as encore ta session. Va me faire la meme chose en ssh direct qu'on rigole.
De plus, avec un protocole en UDP, chaque paquet doit être chiffré de manière isolée, ce qui rend le chiffrement plus faible.
M'en fout de la qualite du chiffrement, ce qui m'interesse c'est que cela le soit assez pour etre secure. Et je prefere 100 fois un chiffrement plus faible et un serveur qui ne repond PAS si le dit chiffrement n'est pas absolument correct.
Nicolas George wrote:
C'est le principe du VPN,
SSH n'a rien à voir avec un VPN, je ne vois pas le rapport.
C'est marrant ta reponse. Elle ne m'etonne meme pas.
le serveur ne repond QUE SI le paquet est
correctement et totalement formate.
C'est le cas partout où on veut de la sécurité.
Ah bon ?
stephane@enterprise:~$ telnet www.unices.org 22
Trying 203.81.54.120...
Connected to sg3.propolys.com.sg.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.5p1 FreeBSD-20061110
Oh, mon serveur ssh a repondu quelque chose sur un paquet mal formate.
C'est peut etre pas grand chose, mais ca donne deja une information : le
serveur ssh tourne et on peut tester toutes les failles connues.
Sur le meme serveur tourne egalement quelques VPN en UDP, va me les trouver
qu'on rigole. Eux ne repondent RIEN, absolument RIEN tant que le paquet
emis n'est pas absolument celui attendu.
Non, justement. Quand la connexion sautille, les paquets UDP se perdent.
Pour réagir à une connexion médiocre, il faut que l'application implémente
un système de réémission, ce qu'en général elle fait moins bien que TCP.
ssh over vpn, tu verras qu'en terme de fiabilite c'est largement
superieur a du ssh direct. Meme avec une connection RTC deconnecte puis
reconnecte, tu as encore ta session. Va me faire la meme chose en ssh
direct qu'on rigole.
De plus, avec un protocole en UDP, chaque paquet doit être chiffré de
manière isolée, ce qui rend le chiffrement plus faible.
M'en fout de la qualite du chiffrement, ce qui m'interesse c'est que
cela le soit assez pour etre secure. Et je prefere 100 fois un
chiffrement plus faible et un serveur qui ne repond PAS si le dit
chiffrement n'est pas absolument correct.
SSH n'a rien à voir avec un VPN, je ne vois pas le rapport.
C'est marrant ta reponse. Elle ne m'etonne meme pas.
le serveur ne repond QUE SI le paquet est correctement et totalement formate.
C'est le cas partout où on veut de la sécurité.
Ah bon ?
:~$ telnet www.unices.org 22 Trying 203.81.54.120... Connected to sg3.propolys.com.sg. Escape character is '^]'. SSH-2.0-OpenSSH_4.5p1 FreeBSD-20061110
Oh, mon serveur ssh a repondu quelque chose sur un paquet mal formate.
C'est peut etre pas grand chose, mais ca donne deja une information : le serveur ssh tourne et on peut tester toutes les failles connues.
Sur le meme serveur tourne egalement quelques VPN en UDP, va me les trouver qu'on rigole. Eux ne repondent RIEN, absolument RIEN tant que le paquet emis n'est pas absolument celui attendu.
Non, justement. Quand la connexion sautille, les paquets UDP se perdent. Pour réagir à une connexion médiocre, il faut que l'application implémente un système de réémission, ce qu'en général elle fait moins bien que TCP.
ssh over vpn, tu verras qu'en terme de fiabilite c'est largement superieur a du ssh direct. Meme avec une connection RTC deconnecte puis reconnecte, tu as encore ta session. Va me faire la meme chose en ssh direct qu'on rigole.
De plus, avec un protocole en UDP, chaque paquet doit être chiffré de manière isolée, ce qui rend le chiffrement plus faible.
M'en fout de la qualite du chiffrement, ce qui m'interesse c'est que cela le soit assez pour etre secure. Et je prefere 100 fois un chiffrement plus faible et un serveur qui ne repond PAS si le dit chiffrement n'est pas absolument correct.
Stephane TOUGARD
Patrice Karatchentzeff wrote:
UDP fiable ?
Et oui, c'est bien joli le TCP, mais un mode deconnecte ca permet justement de supporter les deconnections. Maintenant, c'est sur, faut que ce soit bien gere.
Patrice Karatchentzeff wrote:
UDP fiable ?
Et oui, c'est bien joli le TCP, mais un mode deconnecte ca permet
justement de supporter les deconnections. Maintenant, c'est sur, faut
que ce soit bien gere.
Et oui, c'est bien joli le TCP, mais un mode deconnecte ca permet justement de supporter les deconnections. Maintenant, c'est sur, faut que ce soit bien gere.
Couard Anonyme
Cumbalero a écrit :
*.-pipolin-.* a écrit :
Un mai n'a rien de contractuel, un contrat ça se signe.
oué, dans ton monde de vieux reac largué, probalement, wake up mon gars, t'es au 21eme siecle !
C'est toi qui est largué dans ton monde virtuel.
Tu iras faire valoir tes droits devant un tribunal en présentant un m ail...
"D'un point de vue juridique, un e-mail peut être produit en justice dans tous les cas où la preuve est libre (droit pénal, droit commerci al et, selon les domaines, droit civil). Comme preuve, ou comme commencement de preuve, selon les cas."
Cumbalero a écrit :
*.-pipolin-.* a écrit :
Un mai n'a rien de contractuel, un contrat ça se signe.
oué, dans ton monde de vieux reac largué, probalement, wake up mon
gars, t'es au 21eme siecle !
C'est toi qui est largué dans ton monde virtuel.
Tu iras faire valoir tes droits devant un tribunal en présentant un m ail...
"D'un point de vue juridique, un e-mail peut être produit en justice
dans tous les cas où la preuve est libre (droit pénal, droit commerci al
et, selon les domaines, droit civil). Comme preuve, ou comme
commencement de preuve, selon les cas."
"D'un point de vue juridique, un e-mail peut être produit en justice dans tous les cas où la preuve est libre (droit pénal, droit commerci al et, selon les domaines, droit civil). Comme preuve, ou comme commencement de preuve, selon les cas."
Couard Anonyme
Stephane TOUGARD a écrit :
*.-pipolin-.* wrote:
tout dépent ce que contiens le mail, ce qui est important ce sont le s infos qui sont contenue dans le mail, pas le mail en lui même...
Je peux te demontrer demain devant n'importe quel tribunal que quoi qu e contienne ton email, on ne peut pas garantir que le contenu est egal a ce qui a ete envoye, que ca a ete envoye par la bonne personne ...
Hum:(http://www.arobase.org/loi/valeur.htm)
Pour les messages importants ou susceptibles de faire l'objet d'un litige, il est fortement conseillé de fiabiliser son envoi. S'i l satisfait les 3 critères de fiabilité (identification claire de l'émetteur, précision de la date et assurance de lintégrali té du message), votre e-mail sera plus facilement considéré comme une pre uve ou un commencement de preuve. Pour ce faire, plusieurs techniques sont à votre disposition.
* la signature électronique
Cette technologie garantit l'identité de l'émetteur et le con tenu du message. Depuis la loi du 29 février 2000, la signature électronique donne à l'écrit électronique valeur de preuv e au même titre que la feuille de papier. L'e-mail ainsi envoyé a une val eur juridique.
Pour en savoir plus, consultez la section sur la signature numérique
* les services de courrier recommandé
Par l'utilisation de ces services, l'expéditeur reçoit un certificat d'émission et le destinataire un certificat de délivrance. En juin 2001, le Tribunal de Grande Instance (TGI) de Paris a reconnu la valeur juridique d'un courrier recommandé , envoyé sur un site qui propose ce service. Depuis cette décis ion, ces services sont reconnus par les tribunaux.
Consultez la section sur l'e-mail recommandé
* Pour une double sécurité, il est également possible d'ajout er une signature électronique aux messages recommandés.
Stephane TOUGARD a écrit :
*.-pipolin-.* wrote:
tout dépent ce que contiens le mail, ce qui est important ce sont le s
infos qui sont contenue dans le mail, pas le mail en lui même...
Je peux te demontrer demain devant n'importe quel tribunal que quoi qu e
contienne ton email, on ne peut pas garantir que le contenu est egal a
ce qui a ete envoye, que ca a ete envoye par la bonne personne ...
Hum:(http://www.arobase.org/loi/valeur.htm)
Pour les messages importants ou susceptibles de faire l'objet d'un
litige, il est fortement conseillé de fiabiliser son envoi. S'i l
satisfait les 3 critères de fiabilité (identification claire de
l'émetteur, précision de la date et assurance de lintégrali té du
message), votre e-mail sera plus facilement considéré comme une pre uve
ou un commencement de preuve. Pour ce faire, plusieurs techniques sont à
votre disposition.
* la signature électronique
Cette technologie garantit l'identité de l'émetteur et le con tenu
du message. Depuis la loi du 29 février 2000, la signature
électronique donne à l'écrit électronique valeur de preuv e au même
titre que la feuille de papier. L'e-mail ainsi envoyé a une val eur
juridique.
Pour en savoir plus, consultez la section sur la signature
numérique
* les services de courrier recommandé
Par l'utilisation de ces services, l'expéditeur reçoit un
certificat d'émission et le destinataire un certificat de
délivrance. En juin 2001, le Tribunal de Grande Instance (TGI)
de Paris a reconnu la valeur juridique d'un courrier recommandé ,
envoyé sur un site qui propose ce service. Depuis cette décis ion,
ces services sont reconnus par les tribunaux.
Consultez la section sur l'e-mail recommandé
* Pour une double sécurité, il est également possible d'ajout er une
signature électronique aux messages recommandés.
tout dépent ce que contiens le mail, ce qui est important ce sont le s infos qui sont contenue dans le mail, pas le mail en lui même...
Je peux te demontrer demain devant n'importe quel tribunal que quoi qu e contienne ton email, on ne peut pas garantir que le contenu est egal a ce qui a ete envoye, que ca a ete envoye par la bonne personne ...
Hum:(http://www.arobase.org/loi/valeur.htm)
Pour les messages importants ou susceptibles de faire l'objet d'un litige, il est fortement conseillé de fiabiliser son envoi. S'i l satisfait les 3 critères de fiabilité (identification claire de l'émetteur, précision de la date et assurance de lintégrali té du message), votre e-mail sera plus facilement considéré comme une pre uve ou un commencement de preuve. Pour ce faire, plusieurs techniques sont à votre disposition.
* la signature électronique
Cette technologie garantit l'identité de l'émetteur et le con tenu du message. Depuis la loi du 29 février 2000, la signature électronique donne à l'écrit électronique valeur de preuv e au même titre que la feuille de papier. L'e-mail ainsi envoyé a une val eur juridique.
Pour en savoir plus, consultez la section sur la signature numérique
* les services de courrier recommandé
Par l'utilisation de ces services, l'expéditeur reçoit un certificat d'émission et le destinataire un certificat de délivrance. En juin 2001, le Tribunal de Grande Instance (TGI) de Paris a reconnu la valeur juridique d'un courrier recommandé , envoyé sur un site qui propose ce service. Depuis cette décis ion, ces services sont reconnus par les tribunaux.
Consultez la section sur l'e-mail recommandé
* Pour une double sécurité, il est également possible d'ajout er une signature électronique aux messages recommandés.
Nicolas George
Stephane TOUGARD , dans le message , a écrit :
Oh, mon serveur ssh a repondu quelque chose sur un paquet mal formate.
Non. Il a émis une mire, en réponse à aucun paquet, juste à l'établissement de la connexion.
ssh over vpn, tu verras qu'en terme de fiabilite c'est largement superieur a du ssh direct. Meme avec une connection RTC deconnecte puis reconnecte, tu as encore ta session. Va me faire la meme chose en ssh direct qu'on rigole.
Sans blague ? Les protocoles d'Internet ont été conçu pour marcher sur Internet, pas sur les vagues imitations que sont les connexions dynamiques dont les adresses IP changent toutes les 5 minutes. Ça n'a aucun rapport avec SSH.
M'en fout de la qualite du chiffrement
Et tu te permets de parler de sécurité...
Stephane TOUGARD , dans le message
<51k536-v6o1.ln1@gulliver.unices.org>, a écrit :
Oh, mon serveur ssh a repondu quelque chose sur un paquet mal formate.
Non. Il a émis une mire, en réponse à aucun paquet, juste à l'établissement
de la connexion.
ssh over vpn, tu verras qu'en terme de fiabilite c'est largement
superieur a du ssh direct. Meme avec une connection RTC deconnecte puis
reconnecte, tu as encore ta session. Va me faire la meme chose en ssh
direct qu'on rigole.
Sans blague ? Les protocoles d'Internet ont été conçu pour marcher sur
Internet, pas sur les vagues imitations que sont les connexions dynamiques
dont les adresses IP changent toutes les 5 minutes. Ça n'a aucun rapport
avec SSH.
Oh, mon serveur ssh a repondu quelque chose sur un paquet mal formate.
Non. Il a émis une mire, en réponse à aucun paquet, juste à l'établissement de la connexion.
ssh over vpn, tu verras qu'en terme de fiabilite c'est largement superieur a du ssh direct. Meme avec une connection RTC deconnecte puis reconnecte, tu as encore ta session. Va me faire la meme chose en ssh direct qu'on rigole.
Sans blague ? Les protocoles d'Internet ont été conçu pour marcher sur Internet, pas sur les vagues imitations que sont les connexions dynamiques dont les adresses IP changent toutes les 5 minutes. Ça n'a aucun rapport avec SSH.
M'en fout de la qualite du chiffrement
Et tu te permets de parler de sécurité...
Stephane TOUGARD
Nicolas George wrote:
M'en fout de la qualite du chiffrement
Et tu te permets de parler de sécurité...
Le jour ou tu gereras des vrais serveurs sur le vrai Internet, je te promets qu'on en reparlera.
Nicolas George wrote:
M'en fout de la qualite du chiffrement
Et tu te permets de parler de sécurité...
Le jour ou tu gereras des vrais serveurs sur le vrai Internet, je te
promets qu'on en reparlera.
