Il y a 3 conditions pour commencer la poignée de main sur une SSLSocket:
- appel startHandshake qui commence explicitement les poignées de main, ou
- toute tentative de lecture ou d'écriture des données d'application sur ce socket provoque une poignée de main implicite ou
- Un appel à getSession essaie d'établir une session s'il n'y a pas de session actuellement valide, et une prise de contact implicite est effectuée.
Tout échec de négociation génère une exception (y compris lorsque le certificat est pas approuvé):
Si l'échange échoue pour une raison quelconque, la SSLSocket est fermée et aucune communications futher peut être terminé.
Souvent, appelant startHandshake() explicitement lors de l'établissement de la connexion est inutile, puisque la poignée de main est lancée lorsque vous commencez à lire à partir du InputStream (ou en écrivant au outputstream). Tout échec là-bas provoquerait une exception et arrêterait le flux de contrôle normal. Vous n'avez pas besoin de vous enregistrer explicitement pour capturer l'achèvement de la prise de contact dans ces cas: si vous pouvez lire/écrire à partir des flux, c'est fait. La notification de la finalisation de la prise de contact est surtout utile si vous êtes un serveur demandant une renégociation (en appelant startHandshake() après l'échange de certaines données d'application). Dans ce cas, vous pouvez attendre que la poignée de main soit terminée avant de continuer. Par exemple, si le serveur demande un certificat client après avoir reçu une requête HTTP pour un chemin particulier, il peut vouloir attendre que l'établissement de la liaison aboutisse pour pouvoir autoriser le certificat client, avant d'envoyer la réponse. En effet, startHandshake() ne s'arrête pas le flux de données d'application:
Si des données ont déjà été envoyées à la connexion, il continue de couler au cours de cette poignée de main.
Il semble que le serveur doit mettre en cache les données envoyées par le client jusqu'à la fin de la prise de contact. Cela semble causer des problèmes parce que le cache du serveur web Apache par défaut est ~ 128K et un HTTP PUT d'un fichier peut être énorme ... – Ryan
@Ryan Non. Le serveur ne * reçoit * pas les données de données envoyées par le client jusqu'à ce que le la poignée de main est terminée. Jusqu'à l'achèvement de la prise de contact, il n'y a pas de connexion sur laquelle les données peuvent être envoyées. – EJP
@EJP N ° SSL La renégociation se produit concurremment avec le transfert de données. Voir http://stackoverflow.com/questions/14281628/ssl-renegotiation-with-client-certificate-causes-server-buffer-overflow et http://httpd.apache.org/docs/2.2/mod/mod_ssl.html # sslrenegbuffersize et http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.20 et ... – Ryan