Forum Discussion
NimbostratusSSL Cipher (reporting, graphing, logging)
Nimbostratus@Kevin Stewart I tried to use the rule which you mentioned. I was unable to get the content type as 22 in the payload. Not sure why. I extracted all the bytes from the payload nothing made sense to me. Here is what it logs: Type == 72 84 84 80 47 49 46 49 32 50 48 ..... 125 125
Here is the part of the rule modified:
when SERVER_DATA {
binary scan [TCP::payload] c* type log local0. "Type == $type "
- Kevin_Stewart
Employee
Well,
-
c* would give you all of the bytes, and you only need the first one
-
72 probably indicate that you're not looking at part of the TLS handshake. In fact, if you decode that hex string, it starts with „„€"GIFI2PH", which looks like (I'm assuming) a plaintext image response.
-
- rshetty_242152
I used the rule which you posted. It never logged anything since the condition was not satisfied for 22 and 2 so i logged the values of type and hs in "binary scan [TCP::payload] cSSc type len ver hs".
The logs showed the following Rule /Common/cipher_used_hsl : Type == 72 || hs == 49
Since the number 72 and 49 were not what was expected i decided to get the entire list of payload to see what is going on, hence i ended up using c*.
I tried this rule on couple of different urls. All send the same initial strings.
- Kevin_Stewart
Right, but the iRule can't work if the traffic isn't encrypted.
