logconv.pl -- support parsing/showing/reporting different protocol versions

[389-ds-bot]

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/47949

• Created at 2014-11-11 04:57:16 by nhosoi (@nhosoi)
• Closed as Fixed
• Assigned to mreynolds (@mreynolds389)
• Associated bugzillas
  • https://bugzilla.redhat.com/show_bug.cgi?id=1193241

---

See Ticket 47945: Add SSL/TLS version info to the access log

Sample access log:

SSL
.. conn=3 fd=64 slot=64 SSL connection from ::1 to ::1
.. conn=3 TLS1.2 128-bit AES-GCM

startTLS
.. conn=4 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS"
.. conn=4 op=0 RESULT err=0 tag=120 nentries=0 etime=0
.. conn=4 TLS1.2 128-bit AES-GCM

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2014-12-05 23:13:47

New connection output section:

Total Connections:            283
 - LDAP Connections:          275
 - LDAPI Connections:         0
 - LDAPS Connections:         8
 - StartTLS Extended Ops:     9
 Secure Protocol Versions:
  - TLS1.2 128-bit AES - 7
  - TLS1.1 128-bit AES - 1
  - SSL3 128-bit AES - 2

[389-ds-bot]

Comment from nhosoi (@nhosoi) at 2014-12-05 23:28:30

Very nice!!

[389-ds-bot]

Comment from rmeggins (@richm) at 2014-12-05 23:31:38

Looks like this will fix a divide by zero problem we've seen in the past? Not sure if there is a ticket/bz open for that.

What happens if you run this against an older access log that doesn't have the SSL/TLS version information?

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2014-12-06 02:13:57

Replying to [comment:4 richm]:

Looks like this will fix a divide by zero problem we've seen in the past? Not sure if there is a ticket/bz open for that.

It is a division by zero, but it manifests itself differently than the previous division issue. In this case my access log only had one operation in it(all from the same second). So there was no elapsed time(0) which led to the division by zero. Definitely a corner case. However, I'm not finding another ticket/bug regarding the division by zero, but I recall working on it.

What happens if you run this against an older access log that doesn't have the SSL/TLS version information?

It displays it like this(regardless if TLS or SSL3 is used):

  - SSL128-bit AES - 4

A bit sloppy, so I'll revise it...

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2014-12-06 02:43:19

revision
0001-Ticket-47949-logconv.pl-support-parsing-showing-repo.patch

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2014-12-06 02:46:50

Here is the new output showing the detailed SSL version, and the legacy access log withthe plain SSL version info:

Total Connections:            293
 - LDAP Connections:          281
 - LDAPI Connections:         0
 - LDAPS Connections:         12
 - StartTLS Extended Ops:     10
 Secure Protocol Versions:
  - TLS1.2 128-bit AES - 7
  - TLS1.1 128-bit AES - 1
  - SSL3 128-bit AES - 2
  - SSL 128-bit AES - 4    --> legacy access log

New patch attached...

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2014-12-06 03:28:35

This ticket needs to stay in sync with https://fedorahosted.org/389/ticket/47945

Currently only applying to 1.3.3 and up.

42f935a..7aeeb7c master -> master
commit 7aeeb7c
Author: Mark Reynolds mreynolds389@redhat.com
Date: Fri Dec 5 15:42:45 2014 -0500

d06b397..8b7ae6d 389-ds-base-1.3.3 -> 389-ds-base-1.3.3
commit 8b7ae6d

[389-ds-bot]

Comment from nhosoi (@nhosoi) at 2015-01-06 02:26:48

Thanks for waiting, Mark. Please go ahead and close this ticket with "fixed".

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2015-01-08 04:26:00

df7bafa..a31bd5c 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit a31bd5c

c7c0e75..d1b5c7a 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
commit d1b5c7a63d12d1700db83ca5db95d2d2e6da87cd

c1ba7eb..099d1ce 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit 099d1ce

[389-ds-bot]

Comment from nhosoi (@nhosoi) at 2015-02-17 05:35:44

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1193241

[389-ds-bot]

Comment from nhosoi (@nhosoi) at 2017-02-11 22:51:16

Metadata Update from @nhosoi:

• Issue assigned to mreynolds389
• Issue set to the milestone: 1.2.11.33