You don't quite describe what is the relationship between this monitoring-program and the requests that, as you say, "come in on the wire." SSL conversations are encrypted on at least a per-conversation basis, each with a separate (asymmetric) crypto-key that is unique and which your monitor won't have. Therefore, all that you can do is simple traffic-analysis . . .
. . . unless you can engineer a monitoring interface into the applications that these incoming conversations are referring to. In other words, instead of trying to "eavesdrop," arrange for the recipient applications to write a record to some kind of log-file or pipe that you can listen to. They are already decrypting those conversations. Since you apparently do control the target applications that are being talked-to, you ought to be able to engineer some instrumentation capabilities into them.
Furthermore, when you take this approach, it becomes a simple matter of off-line statistical analysis: parsing values out of the raw-data datasets, taking random samples of the collected data, and generating various descriptive statistics. You collect the data timely, but you can analyze it at your leisure. Plenty of packages, including the open-source "R," can do this sort of thing easily.
Last edited by sundialsvcs; 10-21-2014 at 10:15 AM.
|