ProxySG: weird behavior while processing the https traffic.

[Ramkumar Parkunan  Â]

Hi Team,

i have noticed below while analyzing the policy trace.

1. in that CONNECT protocol method for same url process by proxy till client in and stops transaction and it matches same rule as well for other processing trascation.

miss: category="High Risk Domain"
n/a: condition=!AUTH-InternetUsers
MATCH: ALLOW

connection: service.name=Explicit HTTP client.address=10.xx.xx.23 proxy.port=8080 client.interface=0:0.1 routing-domain=default
location-id=0 access_type=unknown
time: 2020-10-27 05:49:38 UTC
CONNECT tcp://securefile.mcdermott.com:443/
DNS lookup was unrestricted
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
user: unauthenticated
authentication status='not_attempted' authorization status='not_attempted'
url.category: none@Policy;none@YouTube;none@IWF;Business/Economy@Blue Coat
total categorization time: 0
static categorization time: 0
server.response.code: 0
client.response.code: 200
application.name: none
application.operation: none
application.group: none
DSCP client outbound: 65
DSCP server outbound: 65

Transaction timing: total-transaction-time 355 ms
Checkpoint timings:
new-connection: start 1 elapsed 0 ms
client-in: start 267 elapsed 1 ms
access-logging: start 355 elapsed 0 ms
stop-transaction: start 355 elapsed 0 ms
Total Policy evaluation time: 1 ms
url_categorization complete time: 267
client connection: first-response-byte 0 last-response-byte 355
stop transaction --------------------
start transaction -------------------
transaction ID=857816116 type=ssl.tunnel
transaction handed off from: 857815833



2. Same URL but this time unknow ssl and it processed completely as per the logs (we couldn't see client out as well).


miss: category="High Risk Domain"
n/a: condition=!AUTH-InternetUsers
MATCH: ALLOW

connection: service.name=Explicit HTTP client.address=10.xx.xx.23 proxy.port=8080 client.interface=0:0.1 routing-domain=default
location-id=0 access_type=unknown
time: 2020-10-27 05:49:34 UTC
unknown ssl://securefile.mcdermott.com:443/
DNS lookup was unrestricted
origin server next-hop IP address=131.184.128.155
user: unauthenticated
authentication status='not_attempted' authorization status='not_attempted'
client.host: <unset> (rdns resolution: lookup restricted by policy)
url.category: none@Policy;none@YouTube;none@IWF;Business/Economy@Blue Coat
total categorization time: 1
static categorization time: 1
application.name: none
application.operation: none
application.group: none
DSCP client outbound: 65
DSCP server outbound: 65

Transaction timing: total-transaction-time 2690 ms
Checkpoint timings:
new-connection: start 1 elapsed 0 ms
client-in: start 1 elapsed 1 ms
server-out: start 2 elapsed 0 ms
server-in: start 1033 elapsed 0 ms
client-out: start 1033 elapsed 0 ms
access-logging: start 2690 elapsed 0 ms
stop-transaction: start 2690 elapsed 0 ms
Total Policy evaluation time: 1 ms
ssl server hello complete: 1029
url_categorization complete time: 2
ssl_server started tunnel: 1035
server connection: start 2
DNS Lookup: start 1033 elapsed 0 ms
server connection: connected 3
client connection: first-response-byte 0 last-response-byte 2690

Please help me to understand this scenario, i have noticed this kind of behavior in other client policy trace logs as well.

Thanks,
Ram

[Jacob Miles]

Hi Ram,

In an explicit deployment, your client machine makes a CONNECT request to the ProxySG (not the OCS) that specifies where the client machine would like to go. The ProxySG will evaluate policy on that Connect request, and then return a result.

If the ProxySG has not denied the request, the client will then start the TLS handshake (Client Hello, Server Hello...), and after the TLS handshake is completed, the client will then send the ProxySG the copy of the actual request to give the OCS. If you could decrypt the first "Application Data" in Wireshark, you would most likely see the GET or other HTTP method request.

You see two separate transactions, because they are two separate transactions. Where you are not SSL decrypting, the ProxySG does not know what HTTP method was used on the second transaction, and so it defines it as unknown ssl. If you were to enable SSL decryption for this traffic, you would see GET or some other HTTP method in the trace instead.

In short, the CONNECT request is a conversation between the Client and the ProxySG. The unknown ssl transaction is a conversation between the client and the OCS that the ProxySG is also applying policy to.

Hope that Helps!

[Paul Riddington]

Hi All,

There was a major behavioral change between SGOS 6.7.3.x and 6.7.4.x where SSL is now evaluated by policy, whereas it wasn't on previous versions. See https://knowledge.broadcom.com/external/article?legacyId=TECH254549.

Regards
Paul Riddington