limitation de la journalisation du débogage java ssl

94

Utilisation de l'indicateur JVM 

-Djavax.net.debug=ssl

produit une quantité énorme de journalisation, les détails de chaque événement SSL sur le serveur. Existe-t-il de toute façon uniquement des erreurs de journalisation? ou peut-être qu'il existe un meilleur sous-ensemble de ces indicateurs qui produisent une sortie plus ordonnée

all            turn on all debugging
ssl            turn on ssl debugging

The following can be used with ssl:

    record       enable per-record tracing
    handshake    print each handshake message
    keygen       print key generation data
    session      print session activity
    defaultctx   print default SSL initialization
    sslctx       print SSLContext tracing
    sessioncache print session cache tracing
    keymanager   print key manager tracing
    trustmanager print trust manager tracing
    pluggability print pluggability tracing

    handshake debugging can be widened with:
    data         hex dump of each handshake message
    verbose      verbose handshake message printing

    record debugging can be widened with:
    plaintext    hex dump of record plaintext
    packet       print raw SSL/TLS packets
java logging ssl jvm Steve Renyolds
la source
3
Je pense que vous obtenez les erreurs gratuitement à titre d'exceptions. Aucune action spéciale n'est nécessaire.
jww
Ceci est spécifiquement utilisé pour le débogage. D'où la grande quantité de journaux.
javajavajava
1
Le définir sur ""semble afficher seulement quelques avertissements.
NateS

Réponses:

85

Le format d'utilisation des sslindicateurs supplémentaires est ssl:[flag]par exemple:

-Djavax.net.debug=ssl:recordou -Djavax.net.debug=ssl:handshake.

Alan MacK
la source
2
c'est une réponse hautement votée, mais cela fonctionne-t-il vraiment pour les gens? Cela ne semble pas être pour moi. Il existe également une entrée de bogue indiquant que ces options ne fonctionneraient pas réellement.
eis
1
@eis oui, cela a fonctionné pour moi. Peut-être que vous ne le définissez pas correctement et, si oui, vous devriez définitivement poser une nouvelle question afin que nous puissions vous aider :)
Alfabravo
@Alfabravo donc vous dites que l'entrée de bogue est invalide et que cela fonctionne comme prévu?
eis
1
Eh bien, c'est à partir de 2014, jdk7 et openjdk. Aussi, quelqu'un a commenté ici que la journalisation du débogage a été améliorée, donc il y a ça
Alfabravo
14

Je trouve également que l'utilisation -Djavax.net.debug=ssl(ou même ses filtres) est trop lourde pour déboguer les problèmes HTTPS.

C'est un peu compliqué , mais ce que je préfère faire est de configurer mitmproxy sur un serveur bon marché quelque part, puis de configurer mes clients Java pour qu'ils utilisent un proxy. De cette façon, je peux facilement inspecter et rejouer les flux de demande / réponse HTTPS sur le proxy sans avoir à parcourir un tas de journaux.

Si vous êtes intéressé, j'ai écrit un guide sur la façon de faire avancer les choses: Débogage SSL en Java à l'aide de mitmproxy

capotej
la source
Je pense que votre approche est utile pour déboguer le trafic qui se produit dans une session TLS et avoir tous les détails dessus, pouvoir le modifier, mais cela a beaucoup moins de sens lors de l'enquête sur un problème qui se produit au niveau de la session TLS elle-même. Votre proxy changera et cachera ce qui se passe initialement à ce niveau.
jmd