Envoi d'un gros fichier par internet ? - Page 2

...et puis je peux t'envoyer une invit qui me ferait gagner 250Mo gratos

KillerX (./24) :
Avec Safari, on peut reprendre un download...

Le meilleur navigateur c'est christophe colomb !

montreuillois (./31) :
...et puis je peux t'envoyer une invit qui me ferait gagner 250Mo gratos

Non moi moi!

(j'ai que 1.750 GB sur les 8 permis là...)

juste comme ca, on parle de trouver une solution pour une entreprise... et vous proposez de mettre des fichiers qui sont peut-etre confidentiel sur des serveurs de partage... ou encore de faire des tunnels SSH ou autre... pas très professionnel tout ca !

Si c'est crypté le risque est moindre...

PoissonPilote (./33) :

montreuillois (./31) :
...et puis je peux t'envoyer une invit qui me ferait gagner 250Mo gratos

Non moi moi!

(j'ai que 1.750 GB sur les 8 permis là...)

Après toi. Je suis là avec mes 3,3Go

Zerosquare (./29) :
On parle de trucs pour le boulot, là... Bon courage pour faire accepter du torrenting ou du DCC à ton responsable informatique

Qui a dit qu'on lui demande son avis?

Spipu (./34) :
juste comme ca, on parle de trouver une solution pour une entreprise... et vous proposez de mettre des fichiers qui sont peut-etre confidentiel sur des serveurs de partage... ou encore de faire des tunnels SSH ou autre... pas très professionnel tout ca !

Le SSH utilisé correctement est parfaitement sécurisé, tout le traffic est crypté.

Bien sûr on peut faire des conneries, genre un tunnel qui ouvre un port public en dehors de tout firewall pour le tunnel, mais ce n'est pas la faute de la technologie employée.

Spipu (./34) :
juste comme ca, on parle de trouver une solution pour une entreprise... et vous proposez de mettre des fichiers qui sont peut-etre confidentiel sur des serveurs de partage... ou encore de faire des tunnels SSH ou autre... pas très professionnel tout ca !

Pour partager une vidéo...c'est bon quoi

(Moi je suis quand même d'accord avec Spipu )

(Nil : normal, vu le contenu de tes vidéos...)

Nil (./39) :
(Moi je suis quand même d'accord avec Spipu )

Pour rapidshare, ok mais un tunnel ssh, y'a quand même pas grand chose de plus sûr, efficace et facile à mettre en place...

Faut que les gens en face soient capables de s'en servir... c'est pas gagné en général.

BookeldOr (./41) :

Nil (./39) :
(Moi je suis quand même d'accord avec Spipu )

Pour rapidshare, ok mais un tunnel ssh, y'a quand même pas grand chose de plus sûr, efficace et facile à mettre en place...

Normalement, l'admin sys de ton entreprise ne doit pas permettre une connexion SSH entrante sur ta machine. Après, une sortante, ok, pas de souci, mais ça ne résout pas le problème : il faut un serveur où déposer le fichier...

Kevin Kofler (./20) :
Un tunnel SSH peut contourner n'importe quel firewall ou proxy, il suffit d'avoir accès à un serveur en dehors du firewall (et suffisamment bien connecté pour se taper 2 Go de transferts dans les 2 sens!). Une connexion SFTP (le protocole de transfert de fichiers intégré à SSH) directe (ou "directe" à travers un tunnel rapide) entre les 2 machines est certainement la manière la plus efficace de transférer les fichiers. Et au cas où ce n'était pas clair: oui, OS X livre SSH, c'est un Unix après tout!

Ça me rappelle que le proxy de ma boîte bloque SSH en entrée et sortie, tout simplement.

Mais sinon, c'est vrai que ça marche d'enfer: SFTP, pas de problème de mode actif ou passif, d'autres ports à ouvrir en entrée, etc.

J'ai déjà rencontré des problèmes en SFTP (non solutionnés) sur les caractères spéciaux : "Dossier%20Test" ou autres "Priorité" ne passent pas, le chemin (en copier coller depuis le log) est valide mais le SFTP ne parvient pas à trouver le dossier...

Si tu trouves quelqu'un qui a un site internet, ou toi-même peut être, tu devrais pouvoir le mettre sur ton hébergeur et transmettre le fichier comme ca..Bien sûr, il va te falloir leur donner les codes d'accès, mais je pense que c'est une technique qui marche, je l'ai fait pour récupérer de gros fichiers mais jamais encore pour des films..Si tu fais ca tu ne devrais pas rencontrer de problème! Bon courage en tout cas!

Ah, tiens, je n'avais pas réagi à

Kevin Kofler (./20) :
Un tunnel SSH peut contourner n'importe quel firewall ou proxy

Ca n'est pas vrai si du filtrage est fait avec de l'IPinspect (sauf à faire du SSH encapsulé dans des trames http, mais ça devient un peu plus compliqué à mettre en oeuvre, et je ne suis pas sûr que les dernières méthodes d'inspection de sachent pas détecter ça).

Disons que ce qui est dans le SSH contourne tout, mais il faut que le SSH lui-même passe.
J'ai bon?

(le SSH, ça se casse...)

Link (./48) :

Disons que ce qui est dans le SSH contourne tout, mais il faut que le SSH lui-même passe. J'ai bon?

Voilà

vince (./49) :
(le SSH, ça se casse...)

Mais normalement, pas en live, donc ça permet de faire passer de l'info sur l'instant.

Link (./44) :
Ça me rappelle que le proxy de ma boîte bloque SSH en entrée et sortie, tout simplement.

Si tu passes par le port HTTPS (443) voire HTTP (80), ça doit passer, non?

vince (./45) :
J'ai déjà rencontré des problèmes en SFTP (non solutionnés) sur les caractères spéciaux : "Dossier%20Test" ou autres "Priorité" ne passent pas, le chemin (en copier coller depuis le log) est valide mais le SFTP ne parvient pas à trouver le dossier...

C'est un bogue ou mauvais réglage dans les logiciels que tu utilises. Le protocole SFTP est en 8 bits, donc le charset importe. Normalement, c'est l'UTF-8, mais il existe des logiciels (inutile de dire pour quel OS c'est le plus souvent le cas ) qui utilisent autre chose et du coup ça ne passe pas.

Kevin Kofler (./51) :

Link (./44) :
Ça me rappelle que le proxy de ma boîte bloque SSH en entrée et sortie, tout simplement.

Si tu passes par le port HTTPS (443) voire HTTP (80), ça doit passer, non?

Si c'est un blocage de port, oui, ça passera ; s'il y a de l'analyse de trame, non...

Kevin Kofler (./51) :
(inutile de dire pour quel OS c'est le plus souvent le cas )

Bien vu, c'est en effet sous linux que le problème se pose à chaque fois...

Nil (./52) :
Si c'est un blocage de port, oui, ça passera ; s'il y a de l'analyse de trame, non...

Je veux voir comment ils comptent reconnaître du traffic non-HTTPS sur un port crypté. Au maximum, ils peuvent voir que le SSH n'est pas du SSL/TLS, mais il existe aussi des applications de tunneling TLS par lesquelles on peut faire passer n'importe quoi et je vois mal comment ils voudraient distinguer le HTTPS (HTTP+TLS) de SSH+TLS par exemple.

vince (./53) :

Kevin Kofler (./51) :
(inutile de dire pour quel OS c'est le plus souvent le cas )

Bien vu, c'est en effet sous linux que le problème se pose à chaque fois...

Non, justement, sous GNU/Linux, tout est en UTF-8 si ta distribution date de ce millénaire et si tu ne t'es pas amusé à changer manuellement le locale en un locale obsolète (les locales sans le suffixe .UTF-8 sont obsolètes et à ne plus utiliser).

Kevin Kofler (./54) :
Je veux voir comment ils comptent reconnaître du traffic non-HTTPS sur un port crypté. Au maximum, ils peuvent voir que le SSH n'est pas du SSL/TLS, mais il existe aussi des applications de tunneling TLS par lesquelles on peut faire passer n'importe quoi et je vois mal comment ils voudraient distinguer le HTTPS (HTTP+TLS) de SSH+TLS par exemple.

Ben si je ne m'abuse, tu peux distinguer du https du ssh par l'ouverture de session, qui indiquent explicitement ce qu'on va avoir (après, ça fait très longtemps que je n'ai pas fait d'étude de paquets, donc je ne saurais plus dire si les paquets ssh et les paquets https ont des différences notables au niveau des en-têtes, mais ça me paraîtrait cohérent).

Après, tu peux encapsuler les flux, voire mentir à l'ouverture de session lors du handshaking, mais ça devient plus compliqué à mettre en oeuvre, et il faut que tes parties soient toutes modifiées en conséquence...

En effet. Si tu veux bypasser ainsi un proxy, il faut que le serveur soit "dans la confidence"...

Et ensuite, il reste au proxy la solution d'utiliser une liste blanche pour les communications cryptées: Analyse de trame (ou tout simplement surveillance des ports ssh et https) pour voir les ouvertures de session, et refus si l'adresse (qui elle, ne peut être cryptée) n'est pas autorisée...

Nil (./56) :
Ben si je ne m'abuse, tu peux distinguer du https du ssh par l'ouverture de session, qui indiquent explicitement ce qu'on va avoir

Pas si tu fais passer le SSH par un tunnel TLS. On peut crypter pratiquement n'importe quel protocole par TLS, même le SSH (déjà crypté).