Comment activer le débogage SSL sur la plateforme Android?

Question

Y a-t-il quelque chose de similaire à la configuration -D javax.net.debug=ssl sur la ligne de commande pour les applications de bureau Java, mais pour Android? J'ai essayé de le mettre dans le code via System.setProperty("javax.net.debug", "ssl"); mais cela n'a pas fonctionné.

S'il n'existe aucun moyen d'activer cette propriété, existe-t-il au moins un autre moyen de déboguer le côté client d'une connexion SSL? Pour plus de clarté, il s'agit des sockets SSL brutes (SSLSocket et SSLSocketFactory), pas de la bibliothèque Apache ou de toute autre bibliothèque réseau.

Answer 1

À ce stade, il ne semble pas seulement être une façon de le faire. Mais dans tous les cas, nous passons bientôt à la bibliothèque Netty qui a des capacités de journalisation plus détaillées.

Donc la solution (pas géniale) à ce problème est simplement de ne pas utiliser SSLSocket, mais d'utiliser un meilleur réseau bibliothèque à la place.

Answer 2

Si vous utilisez Apache HttpClient (en important un fichier jar), vous pouvez activer la journalisation en définissant des variables d'environnement dans Eclipse. Si vous utilisez Commons Logging, les journaux sont imprimés sur la console. Cependant, cela ne fonctionne que si vous exécutez votre application dans l'émulateur et non sur l'appareil. Pas sûr de cela aide.

Voir http://hc.apache.org/httpcomponents-client-ga/logging.html

Answer 3

Vous pouvez écrire une classe TrustManager pour la gérer. exemple:

ClientConnectionManager cm = new BasicClientConnectionManager(); 
cm.getSchemeRegistry().register(createHttpsScheme()); 
DefaultHttpClient client = new DefaultHttpClient(cm); 
String url = "https://your domain/your url"; 
HttpGet get = new HttpGet(url); 
HttpResponse resp = client.execute(get); 

etc.. 

public static Scheme createHttpsScheme() { 
     SSLContext context = SSLContext.getInstance("TLS"); 
     context.init(null, new TrustManager[] { 
       new TestTrustManager() 
     }, new SecureRandom()); 

     SSLSocketFactory sf = new SSLSocketFactory(context); 
     return new Scheme("https", 443, sf); 
} 

int TestTrustManager.java vous pouvez imprimer la chaîne comme ceci:

public class TestTrustManager implements X509TrustManager { 
    @Override 
    public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException { 

     for (int i = 0; i < chain.length; ++i) { 
     System.out.println(chain[i]); 
     } 

     decorated.checkServerTrusted(chain, authType); 
    } 
} 

Answer 4

J'ai trouvé une aide au débogage utile est d'écrire un wrapper autour X509KeyManager et X509TrustManager qui appelle les délégués à la la mise en œuvre d'origine lors de la connexion des résultats, par exemple:

 TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()); 
     tmf.init(ks); 

     KeyManagerFactory kmf = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm()); 
     kmf.init(ks, null); 

     TrustManager[] tms = WrapTrustManager.WrapArray(tmf.getTrustManagers()); 
     KeyManager[] kms = WrapKeyManager.WrapArray(kmf.getKeyManagers()); 
     SSLContext context = SSLContext.getInstance("TLS"); 
     context.init(kms, tms, null); 

     ....setSocketFactory(context.getSocketFactory()); 

La mise en œuvre de WrapTrustManager et WrapKeyManager sont Pret Il est clair qu'ils utilisent des exceptions pour indiquer un échec et qu'il est donc important de ne pas avaler des exceptions lors de la consignation du résultat.

Notez que l'interface utilise les interfaces vides KeyManager et TrustManager et que vous devez les transférer de manière dynamique vers X509KeyManager et X509TrustManager.