Connexion proxy HTTPS

Bonjour,

J'aimerai utiliser Exchange activesync à travers un proxy https qui filtre les user-agent. Le problème c'est que Windows mobile 6 ne permet pas de régler un proxy https, seulement http.

Je me suis dit que j'allais coder un petit relai pour réaliser l'opération. Voilà comment je l'ai construit:
1. Activesync est configuré pour se connecter sur le serveur locahost.
2. TcpListener écoute sur le port 443.
3. Activesync se connecte -> on récupère le flux streamIN
4. Connexion TcpClient au proxy https -> on récupère le flux streamOUT
5. Envoi de la requête "CONNECT serveur:443 HTTP/1.1 + UserAgent" sur streamOUT
6. Réponse du proxy https "HTTP 200". Donc c'est bon.
7. Après je fait une simple recopie byte par byte d'un flux à l'autre en uplink et en downlink.

J'ai 2 questions:
- Si j'essaie de convertir en ASCII les byte que je transfère c'est illisible. Quand on appelle Read sur un NetworkStream créé à partir de TcpClient on lit le payload TCP ? ou toute la trame TCP ?
- Activesync n'arrive pas à se synchroniser avec ce relai. Voyez-vous une erreur de conception ?

Merci pour vos réponses

Bonsoir,

J'ai avancé sur mon problème. Je peux répondre à ma première question.

Effectivement appeller Read() sur un NetworkStream créé à partir de TcpClient permet de lire le payload des trames TCP. Très pratique on ne garde que les trames SSL par exemple sans se soucier de tout ce qui est propre au TCP.
Il est bien evidemment ridicule de vouloir convertir les octets transmis en chaîne de caractères puisque le protocole SSL ne se lit pas comme du texte. Il faut savoir à quels champs correspondent les octets et on comprend les échanges.

En me plongeant dans la spécification des trames SSL et en capturant les byte un par un au niveau de mon proxy, j'ai pu retracer les échanges entre activesync et le serveur exchange.

Le négociation SSL se fait bien entre les deux parties jsqu'au bout. Ensuite devrait commencer les échanges cryptés mais à ce moment là curieusement je reçois l'octet -1 de la part d'Activesync.

D'après le descriptif de la fonction Readbyte() cela veut dire:

Citation:

---

Valeur de retour
Cast de l'octet non signé en Int32 ou -1 s'il se situe à la fin du flux

---

Que signifie la fin du flux pour une socket ?
Cela veut dire qu'elle a été fermée ? Si c'est le cas comment garder cette connection vivante pour le reste des échanges ?


Merci pour votre aide.

Citation:

---

Envoyé par akrodev

Que signifie la fin du flux pour une socket ?

Cela veut dire qu'elle a été fermée ? Si c'est le cas comment garder cette connection vivante pour le reste des échanges ?

---

Non, ça signifie que tu as lu l'ensemble des octets envoyés, pas que la socket est fermée.

L'appel à ReadByte() n'est pas bloquant alors ?
Et

Code:

---

stream.DataAvailable == false

---

et équivalent à

Code:

---

stream.ReadByte() == -1

---

Non, il te retourne un Byte si il y en a un sur le flux, ou -1 dans le cas contraire.

Ceci dit c'est une méthode de lecture particuliérement inefficiente. (comme mentionné, elle est implémentée en appelent Read sur un tableau de 1 octets).

Je comprends mieux pourquoi mon programme s'arrête alors.
Merci pour ton aide.

Dernière question: existe-t-il une méthode bloquante de lecture de stream ?

Oui, en passant par la lecture asynchrone. Tu apelles BeginRead, et la méthode de callback ne sera appelé que quand des données seront présentes.

Si en revanche, tu veux vraiment bloquer ton programme, tu dois passer par la méthode Receive de l'objet Socket.

En fait l'écoute se fait au sein d'un thread donc çà ne me dérange pas de bloquer le programme.
Le problème est que j'utilise une instance de TcpClient. Si j'appelle Receive() sur la socket, je vais récupérer tous les octets propres au protocole TCP.
Il faut donc bricoler pour créer une méthode de lecture bloquante sur un flux créé à partir de TcpClient ?

Apparemment la méthode Read() est bloquante d'après ce post:
http://www.developpez.net/forums/sho...d.php?t=301706

et c'est confirmé dans le manuel de la fonction TcpClient.getStream():

Citation:

---

...appelez la méthode Write pour envoyer les données à l'hôte distant. Appelez la méthode Read pour recevoir les données en provenance de l'hôte distant. Ces deux méthodes sont bloquées jusqu'à ce que l'opération spécifiée soit exécutée. Vous pouvez éviter le blocage sur une opération de lecture en vérifiant la propriété DataAvailable. La valeur true signifie que les données sont arrivées de l'hôte distant et sont disponibles pour la lecture. Dans ce cas, la méthode Read est assurée de se terminer immédiatement. Si l'hôte distant a arrêté sa connexion, la méthode Read est retournée immédiatement avec zéro octet.

---

Malheureusement, si tu vas voir le Read du Networkstream, (qui est concerné ici) c'est le contraire qui est spécifié :D (if no data ..[snip].. the Read methods returns 0)

Je n'ai pas testé ce cas, mais le Read d'une Stream n'est pas bloquant en général. J'aurais donc, jusqu'à plus ample information, tendance à croire la doc du NetworkStream plutot que celle de la méthode getStream de TcpClient; mais à vérifier. En tout cas, une jolie petite contradiction de doc ici.:yaisse2:

Citation:

---

Envoyé par akrodev

Si j'appelle Receive() sur la socket, je vais récupérer tous les octets propres au protocole TCP.

---

Euh ... non... IIRC, Receive retourne la payload du paquet.

J'avais vu la contradiction effectivement.
çà ne doit pas être très compliqué à tester. Je verrai çà ce soir.

[EDIT] je viens de lire ton deuxième post. La classe TcpClient apporte quoi alors ?

Citation:

---

Envoyé par akrodev

J'avais vu la contradiction effectivement.

---

A vrai dire, je n'avais pas consulté ton lien interne de dvp; donc quelqu'un a testé et c'est moi qui dit des conneries (involontairement). dont acte.

Après quelques test il semblerait que la méthode Read() de la classe NetworkStream ne soit pas bloquante.
C'est vraiment bizarre car d'après la page de présentation de la classe dans la doc:

Citation:

---

La classe NetworkStream fournit les méthodes pour l'envoi et la réception de données via des sockets Stream en mode blocage.

---

C'est à n'y rien comprendre !
Je crois que je vais revenir aux bonnes vieilles sockets.

En fait si elle est bloquante.

Dans mes tests je n'avais pas réalisé çà: (extrait de la doc)

Citation:

---

Si l'hôte distant arrête la connexion et si toutes les données disponibles ont été reçues, la méthode Read se termine immédiatement et retourne zéro octet.

---

Elle est donc bloquante sauf à la toute fin et heureusement pour nous.

Il faut faire attention à cette phrase pas très claire:

Citation:

---

Si aucune donnée n'est disponible pour la lecture, la méthode Read retourne 0.

---

Pour conclure sur ce post, la méthode ReadByte() est elle aussi bloquante.