This website uses cookies essential to its operation, for analytics, and for personalized content. By continuing to browse this site, you acknowledge the use of cookies.
For details on cookie usage on our site, read our Privacy Policy
For details on cookie usage on our site, read our Privacy Policy
About olukacko
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- LIVEcommunity
- About olukacko
04-05-2019
1Post
0Likes
0Solutions
Apr 05, 2019Last Visited
User
Activity
User
Profile
Latest posts by olukacko
| Subject | Views | Posted |
|---|---|---|
| 3450 | 04-05-2019 02:14 AM |
User Badges
Community Statistics
| Member Since | 03-19-2019 04:21 AM |
| Date Last Visited | 04-05-2019 10:00 AM |
| Posts | 1 |
04-05-2019
02:14 AM
I created custom app for ldaps tcp/636 based on signature (ssl-rsp-certificate) which contains text from certificate This caused https - tcp/443 (ssl based) traffic to match this new custom app. After some investigation I realised that https context ssl-req-client-hello contains http/version (i.e. http/1.1) and wanted to filter out this in my custom app so it will not match https any more. Unfortunately I run into limitation where I am not able to Negate my pattern-match. Something that is possible in Custom vulnerability is not possible in Custom App, unfortunately and sadly. Proposal to specify port 636 under Advanced/Defaults is not a solution. Reason: Custom application signature behaves similar way as pre-defined. App-ID does not work merely on default port information but also other conditions. For example, if you have web-application running on custom port, it will be identify as web-browsing as soon as it matches to web-browsing signatures.
... View more
Contact Me
| Online Status |
Offline
|
| Date Last Visited |
04-05-2019
10:00 AM
|
Latest Tags
No tags yet
LEGAL NOTICES
Copyright 2007 - 2023 - Palo Alto Networks