Added SSL related fields to access.log

[acaciocenteno]

Added three fields to access log:

• SSL version, for instance 'TLSv1/SSLv3'.
• SSL cipher suite, for instance 'ECDHE-RSA-AES128-GCM-SHA256'
• SSL session reused.

[sc0ttbeardsley]

How will SPDY-enabled connections be logged?

[acaciocenteno]

Did a test using spdycat and ATS did no log the SSL infos. Will dig into the code tomorrow to learn why.

[bellofreedom]

This would return cipher's version like TLSv1/SSLv3 or SSLv2. For SSL protocol version , I think it would be better to use SSL_get_version.

[shinrich]

Agreed, SSL_get_version is probably what you want here.

[sc0ttbeardsley]

We should probably track this as a jira item...

[jpeach]

I don't like that this adds extra fields to HttpSM, can we avoid that by accessing the netvc? or is it too late by the time we want to log?

[SolidWallOfCode]

While I agree with James' distaste, it will be rare for the NetVC to be around to provide this information.

My recommendation at this point is to set up a sub struct for the HttpSM to hold data that is purely for logging, so at least it doesn't clutter the HttpSM directly. This is a problem that is going to come up again, where we want to log data that is not extant at the point the transaction is logged.

[jpeach]

FWIW for this specific case, you can use the sslheaders plugin as a workaround. Put the values you want into HTTP headers, then log those. In fact, maybe using @headers is a reasonable solution to @SolidWallOfCode's logging data problem.

[bryancall]

There is a related Jira for this:
Desire support for client TLS cipher in custom log format
https://issues.apache.org/jira/browse/TS-3648

[shinrich]

@fpesce got the ssl_session_reuse in TS-3683 (cqssl rather than cssr for the log field). It also includes session reuse via tickets.

Being able to record the the selected cipher and negotiated protocol would still be valuable. I see that @ericcarlschwartz is working on the related bug TS-3648. Hopefully he can pull these changes in via that issue.