1 votes

Journal SSL d'Apache - Handshake SSL incomplet

Scénario : Nous menons quelques expériences dans notre classe autour des connexions de confiance et de SSL, et je veux démontrer la demande de poignée de main SSL sur une attaque man-in-the-middle.

J'ai un serveur Apache avec un certificat auto-signé. Tout fonctionne bien, mais la journalisation semble incomplète car il n'y a aucun moyen d'obtenir une liste des tentatives SSL. Une fois que le client accepte l'"exception", je reçois des messages normaux du journal d'accès pour chaque demande. Cependant, j'ai besoin de savoir quelle demande SSL a provoqué l'échec. Voici mes directives de journalisation :

LogLevel prévient ErrorLog logs/ssl_error_log CustomLog logs/ssl_access_log combiné #the combiné est votre journal personnalisé moyen

Je souhaite obtenir une liste de toutes les tentatives de poignée de main SSL. Qu'est-ce qui me manque pour produire quelque chose comme ce qui suit ? (Il est évident que les mots exacts ne sont pas nécessaires, mais c'est à peu près ça)

0/0/0 00:00:00 - 192.168.1.10 - hijk.lmnop.edu - Mauvaise correspondance SSL

1voto

Amy Anuszewski Points 1228

Les connexions SSL ont options supplémentaires pour CustomLog mais ils ne vont pas décomposer l'état de la connexion étape par étape. Vous voudrez probablement essayer LogLevel debug mais cela vous donnera beaucoup de déchets supplémentaires à trier.

Honnêtement, une meilleure idée pour ce cours serait de démontrer l'utilisation de l'option openssl s_server puisqu'elle peut être configurée pour afficher la progression étape par étape de la machine d'état SSL, vous serez en mesure de voir exactement à quelle étape le client a abandonné la connexion.

Quelque chose comme

openssl s_server -key [somekey.pem] -cert [somecert.pem] -accept 443 -state -www 

Quand quelqu'un se connecte, il imprime les étapes de la connexion :

SSL_accept:before/accept initialization
SSL_accept:SSLv3 read client hello A
SSL_accept:SSLv3 write server hello A
SSL_accept:SSLv3 write certificate A
SSL_accept:SSLv3 write key exchange A
SSL_accept:SSLv3 write server done A
SSL_accept:SSLv3 flush data
SSL_accept:SSLv3 read client key exchange A
SSL_accept:SSLv3 read finished A
SSL_accept:SSLv3 write change cipher spec A
SSL_accept:SSLv3 write finished A
SSL_accept:SSLv3 flush data

l'option -www lui permet d'imprimer certaines informations lorsque quelqu'un s'y connecte avec un navigateur web. Si l'utilisateur s'éloigne sans accepter le faux certificat, je suppose que la connexion sera interrompue quelque part au milieu.

Vous pouvez utiliser le openssl s_client de manière similaire, bien que je ne sois pas certain de sa flexibilité quant à l'acceptation ou non des certificats invalides.

0voto

jcollum Points 10236

La négociation du certificat se fait entre votre navigateur et le proxy qui réalise l'attaque man-in-the-middle. Du côté du serveur, la seule différence que vous pouvez voir est l'IP du client.

Cependant, sur le serveur, vous pouvez configurer des certificats clients pour authentifier les clients. Le serveur n'acceptera que les connexions des clients de confiance. Si la connexion est altérée, le certificat du client sera différent et le serveur fermera la connexion.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X