SSL en Java

Pour sécuriser les communications TCP/IP, que se soit entre deux machines d’un réseau local ou sur Internet, il est nécessaire d’utiliser une sur-couche applicative cryptée. La norme IPV6 propose cette fonctionnalité dans les couches réseaux mais elle n’est pas suffisamment diffusée pour le moment.

Par Philippe PRADOS - 2002
www.prados.fr

Le protocole TCP/IP a été conçu pour résister à une destruction partielle du réseau. Le flux de communication est découpé en paquet. Chaque paquet avance vers la cible en parcourant des chemins divers, sélectionnés au fur et à mesure. Si un chemin ne fonctionne plus, une route alternative est utilisée.

Ce mécanisme entraîne que les paquets peuvent potentiellement transiter par n’importe quelle machine du réseau. Les pirates savent manipuler les routeurs pour détourner les communications vers le poste de leurs choix.

Il n’est pas possible d’interdire un paquet de transiter par un chemin non désiré. Par contre, il est possible d’empêcher son exploitation. Pour cela, il faut que le contenu du paquet soit crypté. Il faut également qu’il soit impossible de rejouer une transaction cryptée ou d’insérer un paquet dans la communication.

Le protocole SSL permet d’ouvrir une communication chiffrée entre deux machines. Il s’agit d’un protocole et non d’une technologie car les algorithmes utilisés pour crypter et signer les paquets sont négociables. Si une attaque majeure invalide un algorithme de cryptage, un autre algorithme peut être utilisé sans remise en cause du protocole. Par exemple, l’algorithme DES est maintenant considéré comme faible. Il est possible de déchiffrer une communication trop rapidement. Pour corriger cela, SSL peut utiliser Triple-DES, appliquant trois fois l’algorithme DES, avant d’envoyer un paquet. La clef est alors trois fois plus longue.

Le protocole SSL est complexe. Plusieurs technologies sont combinées. Pour chacune, différents outils sont disponibles.

Chiffrage asymétrique

Le premier outil est un algorithme de cryptage asymétrique. C’est un algorithme de cryptage qui utilise une clef pour crypter l’information et une autre pour décrypter. Les clefs sont reliées l’une à l’autre par un lien mathématique choisi de telle sorte qu’avec l’une des deux clefs, il n’est pas possible de déduire l’autre sans utiliser des puissances de calculs importantes.

L’une des clefs est appelée arbitrairement « clef publique », l’autre est appelée « clef privée ». La clef publique est, comme son nom l’indique, publique. C'est-à-dire qu’elle est connue du monde entier. La clef privée est maintenue secrète le plus longtemps possible. Toute donnée chiffrée avec l’une des clefs est déchiffrable avec l’autre. Cette particularité sert à plusieurs usages.

Par exemple, cela permet d’envoyer un message confidentiel dont seul le destinataire pourra avoir accès. Pour cela, il faut crypter le message avec la clé publique, connue de tous. Seul le propriétaire de la clef privée est en mesure de le décoder. C’est un peu comme un coffre fort avec une fente. Tout le monde connaît l’existence du coffre fort. Il est facile d’introduire un courrier dans le bon coffre, mais il n’est pas possible de l’ouvrir sans la clef.

Une autre application consiste à signer un document. Le propriétaire de la clef privée chiffre son message avec celle-ci. Le monde entier peut déchiffrer le message. Il faut utiliser pour cela la clef publique de l’émetteur. Le chiffrement n’a pas vocation à cacher le message mais à garantir son origine. Si un message est déchiffrable à l’aide d’une clef publique, on est certain qu’il a été chiffré par le propriétaire de la clef privée correspondante. Pour reprendre l’analogie avec le coffre fort, c’est comme si celui-ci était transparent. Tout le monde peut voir son contenu, mais une seule personne peut le modifier.

Utilisant intensivement des calculs arithmétiques sur des grands nombres, les algorithmes asymétriques sont particulièrement lents. Pour améliorer cela, d’autres technologies sont utilisées.

Chiffrage symétrique

Les algorithmes de chiffrages symétriques utilisent la même clé pour chiffrer et déchiffrer le message. Ces algorithmes sont relativement rapides, comparativement aux algorithmes asymétriques. Ils posent un problème important : comment communiquer la clef de chiffrement de façon sécurisée ? Vous pouvez donner une disquette avec la clef au destinataire avant l’envoi mais ce n’est pas très pratique.

Les algorithmes asymétriques vont régler cela. Une clef symétrique réellement aléatoire est générée. Elle est cryptée à l’aide d’un algorithme asymétrique. Puis le message est crypté à l’aide d’un algorithme symétrique utilisant la clef du message. Les différentes informations sont ensuite réunies au sein du message : la clef symétrique cryptée à l’aide d’une clé asymétrique et le message cryptée à l’aide de la clef symétrique.

Parmi les algorithmes de chiffrement symétriques citons : Data Encryption Standard (DES), triple-strength DES (3DES), Rivest Cipher 2 (RC2), et Rivest Cipher 4 (RC4).

Lorsque que l’on parle de cryptage SSL 40 bit, 56 bits ou plus, il s’agit de la taille de la clé symétrique utilisée pour la communication. Sans casser la clef privée d’un utilisateur, il est possible de décrypter ses communications en cassant la clef symétrique correspondante. Ce travail doit être refait pour chaque communication car la clef symétrique est différente pour chaque connexion.

Signature

Pour éviter de chiffrer un message complet à l’aide d’un algorithme asymétrique ou symétrique, des algorithmes de calcul de « hash » ont été proposés. Ils permettent de calculer un résumé d’un document. Un message de taille variable est transformé en un ensemble fini de bit.

Une signature est un élément additionnel à un document, prouvant la véracité de celui-ci et l'authenticité du signataire.

Ce texte est bien de Philippe PRADOS.

Il contient cinq 'a', deux 'b', cinq 'c', neuf 'd', vingt-deux
'e', trois 'f', quatre 'g', quatre 'h', vingt et un 'i', un 'j', un
'k', trois 'l', deux 'm', dix-huit 'n', six 'o', sept 'p', six 'q',
sept 'r', neuf 's', vingt et un 't', dix-huit 'u', quatre 'v', un
'w', dix 'x', un 'y' et un 'z'.

La phrase « Ce texte est bien de Philippe PRADOS » est signé par le paragraphe suivant. L'algorithme de signature effectue un calcul sur le document et sur lui-même. L'ensemble du texte possède cinq 'a'. Un lecteur humain est parfaitement capable de vérifier la validité du document. Par contre, il est très difficile de modifier une seule lettre du premier paragraphe sans perturber immédiatement l'ensemble de la signature. Par exemple, en modifiant la lettre O du texte, il faut modifier la chaîne six 'o' en cinq 'o', donc modifier les valeurs pour les lettres s, i, x, c, n et q. Et ainsi de suite. Sans l'algorithme adéquat, il est quasiment impossible de forger une nouvelle signature.

Cet algorithme simpliste ne résiste pas à une anagramme de texte. Par exemple, le texte peut être remplacé par « Ce texte est bien de Philippe SODARP ». La signature est toujours valide.

Les algorithmes de calcul de « hash » sont conçus de telle façon qu’il soit très difficile, mais pas impossible, d’obtenir un autre message ayant le même résumé. Parmi l’ensemble des messages produisant une signature donnée, il est extrêmement rare qu’ils soient exploitables, car les messages valides ne veulent rien dire.

Pour sceller la valeur de « hash », elle est cryptée à l’aide d’un algorithme asymétrique. Cela permet de chiffrer une information bien plus petite que le message en entier. L’enveloppe possède alors le texte en clair et la valeur de « hash » signée à l’aide de la clef privée de l’émetteur.

Il est alors facile de vérifier que le message n’a pas été modifié. Utilisez la clef publique de l’émetteur pour déchiffrer la valeur de « hash », calculez la valeur correspondante du message et comparez-la avec la valeur signée. Si les résultats sont identiques, le message n’a pas été modifié et vient bien de l’émetteur.

Parmi les algorithmes de « hash » citons : Message Digest 5 (MD5) et Secure Hash Algorithm (SHA).

Autorité de certification

On remarque dans ce principe qu'il faut posséder la clé publique d'un individu pour vérifier que le message est bien de lui. Comme dans la vie réelle, il faut un exemplaire de la signature de l'individu. Comment vérifier qu'un message est bien de l'auteur sans connaître sa clé publique ? Est-il nécessaire de garder la liste des clefs publiques de toutes les personnes de votre entourage ? Est-il possible de communiquer avec une personne inconnue ?

La solution consiste à faire appel à une autorité ayant pour charge de contresigner les signatures. Ces autorités sont appelées Autorité de certification (Certificate Authority ou CA). Comme dans la vie réelle, un document possédant un tampon d’une autorité publique (mairie, préfecture, etc.) permet de renforcer la confiance en la véracité d’un document.

Le document va posséder la clé publique de l'auteur. Celle-ci est contresignée par l'autorité. Connaissant la clé publique de l’autorité, vous pouvez décoder la valeur de « hash » et vérifier la clé publique de l'auteur.

Le problème est remonté d'un niveau, vous devez posséder la clé publique de l'autorité ! Votre environnement doit en effet indiquer les clés publiques des différentes autorités dont vous avez confiance. Un document contresigné par une autorité que vous n'avez pas enregistrée ne sera pas valide. Les autorités sont comme les préfectures ou les mairies lorsque vous demandez un tampon certifiant une copie d'un document. Si vous recevez un document « certifié conforme », vous consultez le tampon pour savoir si vous pouvez faire confiance au document.

Les autorités de certification demandent un certain nombre de documents avant de signer une clé publique. Le travail de vérification de l'individu ou de l'entreprise est fait par l'autorité. Suivant les règles de vérification, vous autorisez ou non les signatures contresignées par celle-ci.

Il y a parfois des failles dans les processus de vérification. Des pirates ont réussi à se faire passer pour des employés de Microsoft afin d’obtenir un certificat numérique signé par l’autorité Verisign. Pour éviter ces déconvenues, l’autorité maintient une liste signée de certificats révoqués.

Les autorités peuvent être enchaînées. Une autorité principale signe une autorité secondaire qui signe un certificat. Cela permet de hiérarchiser les autorités de certification. Par exemple, un état signé les clefs publiques des préfectures, qui elles-mêmes signent les documents des usagers. Ainsi, si la clef privée d’une préfecture est volée, seuls les certificats signés par elle sont compromis. Il n’est pas nécessaire de révoquer tous les certificats du pays.

C’est dans la vérification de ces chaînes qu’une faille a été découverte récemment avec Internet Explorer de Microsoft. Il était possible d’utiliser la clef privée d’un site Internet pour contresigner un faux certificat d’un autre site. En combinant tout cela, le certificat présenté à l’utilisateur est organisé ainsi : Un certificat pour le site www.spoof.org est signé à l’aide d’un certificat pour le site www.officiel.org, lui-même signé par une autorité valide. Le navigateur ne trouve rien à redire car les signatures sont bonnes et ont été validées par une autorité. La faille vient du fait que le certificat signé par l’autorité pour www.officiel.org n’est pas habilité à signer d’autres certificats. Internet Explorer ne faisait pas cette vérification. Cette attaque permet d’obtenir les communications cryptées en clair, à l’insu de l’utilisateur. Un patch est disponible chez Microsoft.

Algorithme d’échange de clef

Pour échanger une clef symétrique, plusieurs algorithmes sont disponibles, plus ou moins sécurisés.

• RSA
• Fixed Diffie-Hellman
• Ephemeral Diffie-Hellman
• Anonymous Diffie-Hellman
• Fortezza

L’algorithme RSA consiste à crypter la clé de session à l’aide de la clef publique du certificat serveur.

L’algorithme de Diffie-Hellman a été mis au point en 1976 afin de permettre l’échange de clés à travers un canal non sécurisé. Il repose sur la difficulté du calcul du logarithme discret dans un corps fini (calculs modulo n). Un calcul est effectué sur le client et sur le serveur à partir d’informations échangées sur le réseau. L’algorithme est conçu de telle manière qu’il n’est pas possible de déduire la valeur de la clef en écoutant le réseau. Cet algorithme est sensible à une attaque par « homme-au-milieu ». Des versions améliorées sont proposées pour corriger ces failles. Le dialogue est crypté à l’aide de la clef publique du certificat serveur.

Le protocol

Regardons comment le protocole SSL utilise ces technologies pour ouvrir une communication sécurisée.

Client

Serveur

1. Bonjour client

>

<

2. Bonjour serveur

<

3. Certificat (Optionnel)

<

4. Demande de certificat (Optionnel)

<

5. Echange de clef serveur (Optionnel)

<

6. Bonjour du serveur terminé

7. Certificat (Optionnel)

>

8. Échange de clef client

>

9. Vérification du certificat (Optionnel)

>

10. Change le chiffrement

>

11. Terminé

>

<

12. Change le chiffrement

<

13. Terminé

14. Données cryptées

<>

14. Données cryptées

La première étape d’une connexion SSL consiste à ouvrir une connexion TCP vers le serveur (1). Le client indique la version du protocole à utiliser et les différents algorithmes qu’il gère, la taille des clefs correspondantes et leurs combinaisons pour une communication. Chaque combinaison est décrite sous le terme « cipher suite ».

Le serveur retourne un acquittement de la connexion (2), sélectionne le meilleur algorithme qu’il sait gérer.

A l’étape trois, le serveur présente un certificat numérique. Cela permet de s’assurer que le serveur atteint par la communication est bien celui qu’il prétend être. En effet, un pirate peut détourner la communication pour se faire passer pour le serveur cible. Pour empêcher cela, le serveur présente un certificat numérique, signé électroniquement par une autorité de certification. Un certificat est un fichier binaire possédant différentes informations. Un calcul de « hash » est pratiqué sur les données, puis le résultat est crypté à l’aide de la clef privée de l’autorité de certification.

Pour pouvoir vérifier la validité du certificat, il faut posséder la clef publique de l’autorité. Les navigateurs possèdent ces clefs. Il est alors possible de calculer la valeur de « hash » du certificat et de la comparer avec la valeur décryptée présente dans le certificat. S’il y a correspondance, le certificat est digne de confiance.

Il faut ensuite vérifier quelques informations supplémentaires. Les certificats ont une durée de vie. Cela permet de réduire la fenêtre de tir permettant à un pirate de casser la clef privée. Régulièrement, les clefs sont changées. Si un certificat est valide mais est trop vieux pour être digne de confiance, une alerte est présentée à l’utilisateur.

Une autre information importante est présente dans le certificat : le nom du site qu’il représente. En effet, un certificat valide pour le site www.mon-site.org peut être volé et utilisé pour simuler un site www.un-autre-site.org. Le navigateur doit vérifier cette concordance.

La dernière information majeure présente dans un certificat est la clef publique du serveur. Cette clé va permettre l’ouverture de la communication.

L’étape quatre est optionnelle. Elle indique que le serveur désire l’authentification du client à l’aide d’un certificat numérique. Ce n’est généralement pas le cas lorsque vous naviguez sur des sites sécurisés. Le certificat que doit présenter le client doit être signé par une autorité que le serveur connaît, pas forcément identique à l’autorité utilisée par le serveur pour signer son propre certificat. Par exemple, un site www.secret.org peut proposer un certificat signé par www.mon-autorité.org et attendre des certificats clients signés par www.secret.org. Les certificats clients permettent de garantir une sécurité maximale. Le risque résiduel est le vol du certificat client à l’aide d’un virus ou autre cheval de Troie. Pour éviter cela, il faut garder les certificats clients sur un support physique sécurisé (carte à puce, …).

A l’étape 5, le serveur peut fournir des informations complémentaires si le certificat présenté n’est pas suffisant pour permettre un échange de clef symétrique. Enfin, le serveur informe qu’il a terminé avec cette étape du protocole (6). C’est au tour du client de jouer.

Si le serveur l’exige, le client présente également son certificat numérique (7). Il génère ensuite une information servant à la production d’une clef symétrique. Il peut crypter cette information avec la clef publique du serveur. Celui-ci est le seul à pouvoir obtenir l’information en clair.

L’étape neuf est rarement utilisée. Elle permet au client de prouver qu’il possède la clef privée correspondante à la clef publique de son certificat. Pour cela, le client envoie une information signée avec sa clef privée. Le serveur peut décrypter cette information avec la clef publique correspondante pour vérifier que le client possède bien toutes les informations nécessaires à la communication.

Le client informe ensuite le serveur (10) qu’il est temps de sélectionner les algorithmes nécessaires à la communication.

Le serveur confirme le choix des algorithmes à utiliser (12). La communication chiffrée peut commencer.

Le protocole étant volumineux, les clefs de sessions peuvent être réutilisées sur l’initiative du client. Celui-ci ouvre une communication SSL en proposant de réutiliser une clef précédente. Si le serveur accepte (parce qu’il l’a gardée dans un cache et qu’elle n’est pas trop ancienne) le protocole est simplifié. La communication récupère les algorithmes utilisés précédemment pour commencer immédiatement la communication chiffrée.

La faiblesse

L’autorité de certification ou un gouvernement possédant la clef privée de l’organisme de certification est capable d’obtenir en clair toutes les communications entre le client et le site. En effet, en se plaçant au milieu de la communication, il est possible de livrer un vrai-faux certificat, signé par une autorité valide.

Le client dialogue avec un site d’écoute. Celui-ci délivre un vrai-faux certificat et communique vers le serveur. Au milieu, les flux sont clairs. La négociation des clefs entre le client et l’écoute s’effectue avec la clef privée du vrai-faux certificat. Cette information permet de déchiffrer immédiatement toutes les communications. Il est plus difficile de déchiffrer une communication ancienne, n’utilisant pas le vrai-faux certificat.

Client SSL en Java

L’API JSSE de Java permet une communication SSL. Cette API est incluse dans le JDK 1.4 et est disponible en téléchargement pour les versions précédentes des JDK. Elle est livrée avec un provider IBM pour le JDK 1.3 d’IBM. Nous allons regarder comment communiquer avec un serveur HTTPS.

Pour installer JSSE avec un ancien JDK, il faut recopier les archives jsse.jar, jcert.jar et jnet.jar dans le répertoire <java_home>/jre/lib/ext et indiquer les providers dans le fichier java.security.

security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.net.ssl.internal.ssl.Provider
security.provider.3=com.ibm.jsse.JSSEProvider

La classe SSLSocketFactory hérite de SocketFactory pour spécialiser la création de sockets cryptés, étendant les sockets classiques. Elle propose des méthodes complémentaires permettant de manipuler le protocole SSL. Par exemple, pour connaître la liste des suites de chiffrements disponibles, utilisez la méthode getDefaultCipherSuites().

SSLSocketFactory factory=(SSLSocketFactory)SSLSocketFactory.getDefault();
String[] cipherSuite=factory.getDefaultCipherSuites();
for (int i=0;i<cipherSuite.length;++i)
  System.out.println(cipherSuite[i]);

Cela affiche quelque chose comme ceci :

SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5

À partir d’une instance fabrique, il est facile d’ouvrir une communication SSL. Il faut indiquer le nom du site et le port à utiliser. Par défaut, le protocole HTTPS est porté par le port 443.

SSLSocketFactory factory=(SSLSocketFactory)SSLSocketFactory.getDefault();
SSLSocket sslSocket=(SSLSocket)factory.createSocket(
 "www.ma-banque.com",443);

Il ne reste plus qu’à exploiter le socket pour obtenir la page du site.

OutputStream out=sslSocket.getOutputStream();
PrintWriter wout=new PrintWriter(out);
wout.println("GET / HTTP/1.0");
wout.println("Host:www.ma-banque.com");
wout.println();
wout.flush();
InputStream in=sslSocket.getInputStream();
InputStreamReader rin=new InputStreamReader(in);
int c;
for (;;)
{
  c = in.read();
  if (c == -1)
    throw new EOFException("socket closed");
  System.out.print((char)c);
}

Il est possible de récupérer les informations de la session SSL à partir du socket. Pour cela, invoquez la méthode getSession(). Vous y retrouvez la suite utilisée pour le chiffrement, la clé symétrique et le certificat serveur.

SSLSession session=sslSocket.getSession();
System.out.println("Cipher suite:"+session.getCipherSuite());
System.out.print("id=");
byte[] key=session.getId();
for (int i=0;i<key.length;++i)
  System.out.print(' '+Integer.toHexString(((int)key[i]) & 0xFF));
System.out.println();
X509Certificate[] chain=session.getPeerCertificateChain();
System.out.println("Certificat serveur =");
for (int i=0;i<chain.length;++i)
  System.out.println(chain[i]);

Le contexte SSL peut être recyclé pour simplifier la procédure de connexion. Cela permet d’accélérer les communications ultérieures avec le même serveur. Certains produits de Load-Balancing utilisent la session SSL comme critère d’affinité d’un client. Lorsqu’une communication SSL nouvelle arrive, la session est associée à un serveur. Si une communication SSL désire recycler une session précédente, le même serveur est sélectionné pour le client.

Cette approche fonctionne dans les faits car les sessions SSL ont généralement une durée de vie d’une journée. En principe, rien n’oblige le serveur à accepter les sessions aussi longtemps, ni au client de renégocier une nouvelle session plus rapidement. Un bug de I.E. recyclait les sessions toutes les minutes ! Regardez le document Q265369 dans la base de support de Microsoft.

Java offre une technique plus simple pour communiquer avec un serveur HTTPS. Un gestionnaire de ce protocole est disponible. Il faut l’enregistrer dans la variable d’environnement java.protocol.handler.pkgs.

String protocol=System.getProperty("java.protocol.handler.pkgs");
if (protocol==null)
  System.setProperty("java.protocol.handler.pkgs",
    "com.sun.net.ssl.internal.www.protocol");
else
  System.setProperty("java.protocol.handler.pkgs",
    protocol + "|com.sun.net.ssl.internal.www.protocol");

Il est ensuite possible d’ouvrir directement une connexion HTTPS.

URL url=new java.net.URL("https://www.ma-banque.com");
URLConnection cnx=url.openConnection();
System.out.println(cnx.getContent());

Si le certificat présenté par le serveur n’est pas signé par les autorités par défaut, il faut enregistrer le certificat ou l’autorité de certification dans une base de données de clefs et signaler à l’API de l’utiliser. L’utilitaire keytool va nous aider à importer un certificat.

keytool –keystore keystore.kdb –storepass coucou –import –file serveur.cer

Il faut ensuite valoriser la variable d’environnement javax.net.ssl.trustStore pour signaler l’utilisation de la base de certificats.

System.setProperty("javax.net.ssl.trustStore","keystore.kdb");

Serveur SSL en Java

Pour offrir un serveur SSL, il faut auparavant générer un couple clef publique/clef privée pour le serveur et l’ajouter dans la base des clefs.

keytool -keystore keystore.kdb -storepass coucou -keypass coucou –genkey
 -alias ma-banque -keyalg rsa -dname "CN=www.ma-banque.com"

Il est nécessaire de préciser le paramètre -keyalg à rsa, car sinon, les navigateurs ne peuvent trouver une suite de communication compatible avec le serveur. Le nom CN doit être celui du site.

Il faut ensuite construire un contexte SSL et l’initialiser avec les clefs publiques et les clefs privées.

protected static SSLContext makeSSLContext() throws Exception
{
  SSLContext ctx=SSLContext.getInstance("TLS");
  char[] passphrase = "coucou".toCharArray();
  KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
  KeyStore ks = KeyStore.getInstance("JKS");
  ks.load(new FileInputStream("keystore.kdb"), passphrase);
  kmf.init(ks, passphrase);
  TrustManagerFactory tmf=TrustManagerFactory.getInstance("SunX509");
  tmf.init(ks);
  ctx.init(kmf.getKeyManagers(),tmf.getTrustManagers(), null);
  return ctx;
}

Ce contexte est utilisé pour ouvrir un socket en écoute.

SSLContext ctx=makeSSLContext();
SSLServerSocketFactory factory = ctx.getServerSocketFactory();
SSLServerSocket serverSocket = (SSLServerSocket)factory.createServerSocket(443);
Socket socket=serverSocket.accept();

Internet Explorer ouvre une première connexion pour négocier une clef de session, puis il coupe la communication avant d’envoyer la moindre requête HTTP. Il ouvre ensuite une deuxième connexion en recyclant la clef de session obtenue lors de la première connexion. Pour simuler un serveur HTTPS, il faut tenir compte de cette situation.

ServerSocketFactory factory=getSSLContext().getServerSocketFactory();
ServerSocket serverSocket = factory.createServerSocket(443);

// Première connexion
Socket socket=serverSocket.accept();
socket.close();

// Deuxième connexion
socket=serverSocket.accept();
DataOutputStream out = new DataOutputStream(socket.getOutputStream());
DataInputStream  in  = new DataInputStream(socket.getInputStream());
String request = in.readLine();
byte[] bytecodes = "coucou".getBytes();//getBytes(path);
out.writeBytes("HTTP/1.0 200 OK\r\n");
out.writeBytes("Content-Length: " + bytecodes.length +"\r\n");
out.writeBytes("Content-Type: text/html\r\n\r\n");
out.write(bytecodes);
out.flush();

Pour tracer tous les échanges SSL entre le client et le serveur, valorisez la variable d’environnement javax.net.debug à all.

System.setProperty("javax.net.debug","all");

D’autres valeurs sont possibles. Utilisez la valeur help pour avoir plus de détails.

Il n’est pas possible de générer des chaînes de certificats avec l’utilitaire keytool. Utilisez une version de OpenSSL pour Linux ou Windows afin de manipuler les certificats. Il faut ensuite les importer avec l’utilitaire de Java pour pouvoir les utiliser.

D’autres fournisseurs JSSE sont disponibles. Ils sont généralement plus rapides ou plus complet. IBM propose une version ici www7b.boulder.ibm.com/wsdd/wspvtdevkit-info.html.