Nimbostratus
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 "
EmployeeWell,
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.
NimbostratusI 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.
EmployeeRight, but the iRule can't work if the traffic isn't encrypted.