Bonjour!
Grande question existentielle : est ce que c'est possible que ça soit le serveur qui initie une connexion SSL...??
parce que dans tout ce que j'ai trouvé jusqu'à présent, c'est toujours l'initiative du client...
Version imprimable
Bonjour!
Grande question existentielle : est ce que c'est possible que ça soit le serveur qui initie une connexion SSL...??
parce que dans tout ce que j'ai trouvé jusqu'à présent, c'est toujours l'initiative du client...
Mais la définition même de "client" n'est-elle pas "celui qui initie la connexion" ?
Comment le serveur saurait-il qu'il doit se connecter au client ?
Basiquement, comme il y a une connection TCP puis la construction d'une connexion SSL au dessus, inverser les rôles client/serveur pour la partie SSL devrait être possible.
Enfin, vu de loin, je ne vois pas pourquoi cela ne pourrait pas marcher mais je ne me suis pas amusé à en décliner les implications pour voir si cela posait problème.
Et je ne vais pas le faire parce que une telle gymnastique me donne le tournis.
- W
Il faudrait regarder le protocole SSL dans les détails mais ce ne serait pas étonnant qu'il y ait un sens dans celui qui envoie le premier message.
Je crois que cette page décrit assez précissement les échanges protocolaires
merci pour vos réponses...et désolée de pas m'être remanifestée, j'ai oublié le sujet :oops:
donc si je résume le principe d'une interface client/serveur, c'est bien que le client demande la connexion au serveur. C'est donc le cas pour SSL.
on m'a dit qu'en TCP, c'était possible par contre que la demande de connexion vienne du serveur (mode permanent, non permanent...) et j'ai pas trouvé d'info dessus sur Google...
est ce que quelqu'un saurait m'expliquer le fonctionnement que je puisses voir si c'est adaptable à ssl après...??
merci par avance...
Attention, ne pas confondre initiateur de la connexion/session TCP et initiateur du protocole, c'est pas le même niveau.
Sur une session TCP, c'est le bien client qui initie la session TCP par l'appel connect() et c'est le serveur qui accepte l'appel entrant avec accept().
Par contre, au niveau protocole, quand la session TCP est établie, on ne sait pas. C'est la RFC du protocole qui le dit et il n'y a pas de généralisation.
Typiquement pour le protocole SMTP, c'est le serveur qui envoie le 1er message protocolaire par contre, pour le protocole SSL, c'est le client qui envoie le 1er message protocolaire. Donc aucune généralisation à ce niveau, il n'y a pas de règle, il faut lire la spec du protocole.
J'ai lu la doc rfc 246 sur tls.
Et j'ai presque trouvé mon bonheur...
Donc apparement, il y a possibilité que le serveur initie la connexion ssl en faisant un hello request.
Donc c'est très bien mais ma question, c'est comment le programmer... je suppose que ça doit être dans la lib d'openssl mais je ne vois pas quelle fonction appeller... est ce que quelqu'un le saurait par un heureux hasard...??Citation:
Hello request
When this message will be sent:
The hello request message may be sent by the server at any time.
Meaning of this message:
Hello request is a simple notification that the client should begin the negotiation process anew by sending a client hello message when convenient. This message will be ignored by the client if the client is currently negotiating a session. This message may be ignored by the client if it does not wish to renegotiate a session, or the client may, if it wishes, respond with a no_renegotiation alert. Since handshake messages are intended to have transmission precedence over application data, it is expected that the negotiation will begin before no more than a few records are received from the client. If the server sends a hello request but does not receive a client hello in response, it may close the connection with a fatal alert.
After sending a hello request, servers should not repeat the request until the subsequent handshake negotiation is complete.
Structure of this message:
struct { } HelloRequest;
Note: This message should never be included in the message hashes which are maintained throughout the handshake and used in the finished messages and the certificate verify message.
sinon je continue à farfouiller... :google: est devenu mon meilleur ami:aie: