Setup: Media Type Filtering with default Rules --> Block undetectable Data: Property List.OfMediaType.IsEmpty (MediaType.EnsuredTypes) == true
Looks like OCSP/CRLs requets are dropped with this rule for example:
|403|POST http://ocsp.thawte.com HTTP/1.1|Business, Software/Hardware|Minimal Risk||3287|353|Mozilla/4.0 (Windows 7 6.1) Java/1.7.0_09||20||ocsp.thawte.com
This issues seems to be with all OCSP/CRL Requests to Thawte or Verisign URLs. Any other idea to solve this problem other then whitelisting these requests?
Working Bypass Log Entry:
200|POST http://ocsp.thawte.com HTTP/1.1|Business, Software/Hardware|Minimal Risk|application/ocsp-response|1605|353|Mozilla/4.0 (Windows 7 6.1) Java/1.7.0_09||0||ocsp.thawte.com
- Looks like the Media Type is not detected, if passed through the Media Typ /Composite Opener the application requests is identified: "application/ocsp-response"
- Authentication works fine
Thanks for your input!
it's enough to have client's tcpdump - I want to see which data are sent from client. If possible, can you make several dumps, so we'll have different data files
This is a typical OCSP Request from the client. This requests stays the same if I have the OCSP Rule activated or not. With the OCSP Rule in Place, we ill cet a OCSP Response: Successful (0)
If you want full TCP Dumps, I would need your email address.
Was there a solution or workaround for this in respect of allowing the CRL/OCSP requests? It's an issue I'm seeing as well.
@ales: message is on the way.
@trevorw2000: the issue has been forwarded to mcafee and is now a "feature" request. the working solution is still the mentioned workaround rules to bypass the "non"-detection:
IF Property List.OfMediaType.IsEmpty (MediaType.EnsuredTypes) == true
IF Destination URL / IP is http://ocsp.thawte.com
THEN Stop Ruleset