En même temps, je suis en intercontrat dans une SSII qui ne me donne rien de mieux à faire, donc autant se trouver une occupation :-)

 

Salut

Max a ecrit:

- l'applet ne peut se connecter qu'à son hôte mère c'est à dire www.belote-en-ligne.fr : lorsque le proxy se connecte, s'il copie le contenu du site il se peut que Java bloque l'accès.

C'est bien le problème, la connexion est directe et n'utilise pas les capacités de proxy de Java.

- les ports à libérer peuvent changer lors des mises à jour : libère de 47367 à 47370 pour être tranquille.
- est ce que ton proxy est en bout de ligne coté WAN ou est il relié à un autre proxy ou sur une DMZ ?

Le proxy autorise tout, et la configuration est tel que :

PC -> LAN -> INTERNET <- PROXY

- je ne comprend pas l'histoire du ssh... tu voulais dire ssl ? Si c'est ssl l'applet utilise des sockets non ssl donc c'est peut être pour ça.

Avec ssh, et l'accès à un serveur ssh, il est très facile de tunneler l'intégralité d'un trafic vers un port distant accessible par la machine à laquelle tu te connectes.
Techniquement, je me connecte à un serveur via ssh, je lui dis que mon port 3128 local doit être redirigé vers le port 3128 du serveur distant (port correspondant au proxy).
De fait, si je définis mon port local 3128 comme le proxy de mon navigateur, tout passe chiffré via ssh et atterrit sur le proxy distant, me donnant accès à tout port/tout site.

- la technique du coup de boule : un bon coup de tête sur le proxy des fois ca marche et ca defoule de ttes facons.

Been there, done that :-).

Selon moi le problème est vraiment que l'applet essaye d'initier une connexion directe vers le distant sans passer par les settings Java (y a des sockets ouvrable via proxy). Tripoter cette initiation de connexion résoudrait peut-être le problème ? Sans source, je ne peux pas essayer d'en deviner plus :-).

 

Au lycée j'ai aussi un proxy...
Je pourrais tenter des trucs^^
pas avec mon PC car je suis considéré Admin du réseau... ben oui^^

Je te dirais ça Max ;) mais je crois que ça marche pas car:
pour que l'apelet JAVA se lance il faut une connections directe avec le serveur de la belote, et un proxy, son principe (enfin chez nous) c'est de relancer sur le réseau seulement des images tout en utilisant les infos du PC pour se connecter... en breff, ça utilise ton adresse réseau PC interne dans le réseau pour sortir (envoyer des infos sur le net) mais la réponse du serveur belote est bloquer car ce n'est qu'une copie conforme qui parvient sur nos écran PC (une copie qu'un émulateur du réseau PROXY fait pour nôtre "sécuritée") et donc:
La belote reçoit de l'ordi connecter au proxy par ex: 002
elle renvoi /002 mais le réseau proxy lui, comprend rien, et essaye d'envoyer une image, et.. sa marche pas...

On a étudier le principe avec un copain à moi, on a trouver que le plus simple c'était de faire "poto" avec le webmaster du lycée (ahah)... et il nous a donner des droits (pour moi, admin, pour mon copain une sorte de droit de modération)
C'est plus simple, mais dans une entreprise, quazi-impossible...

mais je demanderais à l'informaticien de m'expliquer un peut pourquoi ça bloque... et comprendre réellement le principe (car ce que j'ai dit, n'est que supposition d'après ce que j'ai (avec mon copain) observer...

 

Max a ecrit:

oui ca m'interesse : je connais le b.a.ba du principe des proxy mais je n'est jamais testé en réel dc ca reste flou

Folon, tu fais fausse route sur ta conception du proxy, tu trouveras plus d'informations là : http://en.wikipedia.org/wiki/Proxy_server
Je passe sur les explications un peu fantaisistes de notre ami folon pour te répondre directement Max ;-)

Il est de toutes façons nécessaire de signer ton applet pour pouvoir créer un socket à travers une connexion passant par un proxy (ref : http://forum.java.sun.com/thread.jspa?t … ID=1082304 ). Après, lorsque tu fais le run du socket de fond_total (et en passant c'est une mauvaise convention de nommage pour du Java ! :-p), la socket factory doit construire toute seule un socket avec les informations de proxy de Java.

Signer ne pose pas de problème, et je ne vois pas ce que tu entends par souci au niveau des certificats. Ce sera ton applet qui sera signée, et effectivement de base pas "officiellement", donc pas reconnue par les root certificates installés sur le poste client : tant que c'est écrit dans la documentation de belote-en-ligne.fr qu'il faut accepter la signature de l'applet, je ne vois pas de souci :-).

Une petite url pour signer : http://www.doc.ic.ac.uk/csg/java/signed-applets/

Edit : par ailleurs la documentation de Java précise que l'implémentation que tu utilises ne se soucie pas d'un proxy => http://java.sun.com/j2se/1.4.2/docs/api … tImpl.html pour PlainSocketImpl

Dernière modification par ainulindale (31/03/2008 08:08:03)

 

Max a ecrit:

Je regarderai ces docs + tard, merci.

Je ne signe pas l'applet tout simplement car il n'y en a pas besoin (acces disque, connection autre qu'au serveur mere , parametres systemes, ...) je n'utilise pas ses fonctionnalités et le meilleur moyen pour moi de le prouver est justement de ne aps signer l'applet !

Ce n'est pas parce que tu ne les utilises pas que la signature n'a pas d'intérêt :-).

Si on imagine un cas (fourbe, certes), où un petit malin désassemble ton applet, et insère des bouts de code malicieux : mettons que chaque fois que tu appuies sur le bouton belote, au lieu de simplement écrire "belote", ça écrive "Bilote, üNF, üNF". Ce petit malin crée ensuite un site bilote-en-ligne.fr, qui lance l'applet et se connecte normalement à belote-en-ligne.fr.
En quoi l'utilisateur est en mesure d'avoir la certitude que c'est toi qui a fourni la première applet et pas la deuxième ?

Seule la signature, et un certificat émis par toi, permet de savoir que tu es bien l'auteur. Ca te protège d'une part, car ça certifie que tu es bien le développeur du logiciel, et ça protège également l'utilisateur qui peut s'assurer que tu es bien le fournisseur du programme qu'il a téléchargé :-)

Edit et note : j'ai monté un petit VPN par curiosité, et je n'ai pas de problème pour jouer du bureau via le VPN. Ceci dit la solution est loin d'être à la portée du tout venant, mais prouve bien que la connexion initiée est directe et ne sait donc pas gérer les proxies :-)

Dernière modification par ainulindale (01/04/2008 08:03:34)

 

ainulindale a ecrit:

Seule la signature, et un certificat émis par toi, permet de savoir que tu es bien l'auteur. Ca te protège d'une part, car ça certifie que tu es bien le développeur du logiciel, et ça protège également l'utilisateur qui peut s'assurer que tu es bien le fournisseur du programme qu'il a téléchargé :-)

Je ne suis pas d'accord avec toi : la seule solution pour certifier que j'en suis bien l'auteur serait de faire passer mon certificat par une chaine de certification reconnue (et donc payante).

N'importe qui pourrait générer un certificat avec les mêmes informations que moi et ainsi induire les joueurs encore plus dans l'erreur et se mettre encore plus en danger, et s'ils ont pris l'habitude d'accepter mes certificats ils accepteront n'importe quoi.
Si je ne signe pas le joueur ne risque rien, et si un usurpateur veut faire du mal il devra signer sinon il ne pourra rien faire non plus. Ainsi le joueur verra un certificat qu'il n'a pas l'habitude de voir et ne l'acceptera pas aveuglément.

Je pense de toutes facons que l'accpetation de certificat n'est pas à la portée du premier internaute venu, et même pour des spécialistes les réponses sont loin d'être évidentes lorsque l'on voit un certificat.

De plus l'utilisation d'un certificat auto-signé n'a de but que de chiffrer les informations et en aucun cas d'assurer l'identité du serveur. Le chiffrement empechera les attaques de type "man in the middle".
Donc cela a un interet pour un serveur de mail par exemple mais en aucun cas d'une applet client : dans ce but l'utilisation de sockets ssl est une solution, mais pas une signature.

Qu'en penses-tu ?

 

ainulindale a ecrit:

Max a ecrit:

Je ne suis pas d'accord avec toi : la seule solution pour certifier que j'en suis bien l'auteur serait de faire passer mon certificat par une chaine de certification reconnue (et donc payante).

Non, ça c'est quand tu veux que ton certificat soit approuvé par une autorité tierce, ce qui ne t'empêche pas d'en générer un unique à ton nom en auto approuvé.

On est d'accord : n'importe qui peut générer son certificat auto-signé très facilement.

Si je ne signe pas le joueur ne risque rien, et si un usurpateur veut faire du mal il devra signer sinon il ne pourra rien faire non plus. Ainsi le joueur verra un certificat qu'il n'a pas l'habitude de voir et ne l'acceptera pas aveuglément.

Oui, mais a fortiori, un petit malin qui intercepte ton logiciel pour en émettre une version "pirate" est dangereux et fournira le même contenu non signé :-).
Bon, j'avoue, pirater une application de belote en ligne, l'intérêt est maigre !

Justement, une version pirate non signée ne pourra pas être nuisible. En plus le fait de signer la mienne ne l'empechera pas plus de la pirater.

Je pense de toutes facons que l'accpetation de certificat n'est pas à la portée du premier internaute venu, et même pour des spécialistes les réponses sont loin d'être évidentes lorsque l'on voit un certificat.

C'est assez facile avec Java, quand même !

Oui c'est facile de cliquer sur OK, mais aucun utilisateur de base ne sait vraiment ce qu'accepter le certificat implique !  Même des gens alèses en informatique ne le savent pas.
Et pour preuve ce débat philosophique que nous avons : on est pas d'accord alors qu'on a l'air de s'y connaitre tous les deux :)

De plus l'utilisation d'un certificat auto-signé n'a de but que de chiffrer les informations et en aucun cas d'assurer l'identité du serveur. Le chiffrement empechera les attaques de type "man in the middle".
Donc cela a un interet pour un serveur de mail par exemple mais en aucun cas d'une applet client : dans ce but l'utilisation de sockets ssl est une solution, mais pas une signature.

Le certificat n'a pas que pour but de chiffrer les informations, surtout dans ce cas là. Si tu veux vraiment éviter du man in the middle, certes, le SSL est nécessaire, mais dans ton cas le certificat ne sert qu'à signer, purement, ton applet. Ce n'est pas parce que tu signes ton applet que tu chiffres tes communications.

Non justement ce n'est pas mon but de chiffrer les echanges, il n'y a rien de confidentiel.
Je veux simplement dire que le fait de signer ne pourra jamais prouver que j'en suis bien l'auteur.

 

oui j'ai bien compris :)
Mais je ne t'oublie pas, une fois en place la belote sous forme d'application on verra si ca passe, si ca ne passe pas je ferais un lien spécial vers une applet signée.
Mais je continue de penser qu'il ne faut pas que je signe l'applet pour l'accès principal, quoiqu'il en soit c'est un débat interessant , ca fait plaisir de parler un peu technique plutot que d'expliquer aux gens comment vider les caches ou faire des captures d'ecran :)

 

Moi même pb avec belote rapide pour passer le proxy.

 

Bonjour,

Je suis de même à travaers un proxy où je pense seul le port 80 est ouvert.
Je n'arrive pas à m'y connecter que ce soit avec le navigateur ou belote rapide.

Belote rapide arrive bien à se connecter pour savoir si une mise à jour est disponible, puis l'interface se charge très bien mais une fois l'interface ouverte, j'ai le message "serveur indisponible : impossible de se connecter au serveur"

les parametres de connexion de Java sont bien identiques à celle de mon navigateur avec le proxy et le port 8080.

Merci pour votre aide