Scenario: We're running some experiments in our classroom around trusted connections and SSL, and I want to demonstrate the SSL handshake request on a man-in-the-middle attack.

I have an Apache server with a self-signed cert. Everything works fine, but the logging seems incomplete as there is no way to get a list of SSL attempts. Once the client accepts the 'exception', I get normal access log messages for every request. However, I need to know what ssl request caused it to fail. Here are my log directives:

LogLevel warn ErrorLog logs/ssl_error_log CustomLog logs/ssl_access_log combined #the combined is your average custom log

My desire is a list of every SSL handshake attempted. What am I missing that could produce something like the following? (Obviously the exact words aren't needed, but in the ballpark)

0/0/0 00:00:00 - - hijk.lmnop.edu - SSL Mismatch

  • To get what I wanted, I wound up logging every request to 443 with iptables. It's not giving me a domain, but I think that's standard for the SSL exchange. At least, that's what I've learned from today's research. – Raymond Berg Feb 18 '11 at 3:36

SSL connections have extra options for CustomLog but they're not going to break down the step-by-step connection status. You'll probably want to try LogLevel debug, but that will get you plenty of extra junk to wade through.

Honestly, a better idea for this class would be to demonstrate using the openssl s_server command, since it can be configured to show the step-by-step progress of the SSL state machine, you'll be able to see exactly at what step the client dropped the connection.

Something like

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

When someone connects it'll print off the steps of the connection:

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

the -www option makes it print some information when someone actually connects to it with a webbrowser. If the user navigates away without accepting the fake cert, then I'm guessing the connection will be broken somewhere in the middle there.

You can use the openssl s_client command in a similar fashion, though I'm not certain how flexible it is about accepting or not accepting invalid certificates.

  • Great answer! This is exactly what I was looking for. – Raymond Berg Feb 18 '11 at 3:35

The certificate negotiation is between your browser and the proxy that is doing the man-in-the-middle attack. On the server side the only difference you can see is the IP of the client.

However, on the server you can configure client certificates to authenticate the clients. The server will accept only connections from the trusted clients. If the connection is tampered, the client certificate will be different and the server will close the connection.

  • Thanks for responding, but my question isn't about the MITM attack, it's about logging requests in Apache during the SSL exchange. If a user doesn't click 'Continue to the Webpage', I don't see any traffic at the server, even though the server provided the SSL cert. I don't know if it's possible, but that's the intent. – Raymond Berg Feb 17 '11 at 17:34
  • If the user does not accept the certificate, the traffic will be only between the browser and the proxy. No packet will be send to the site. – Mircea Vutcovici Feb 18 '11 at 3:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.