- CheckMates
- :
- Products
- :
- General Topics
- :
- Failed to deccrypt CP Site Response...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Failed to deccrypt CP Site Response...
Hi all,
Have you ever faced this kind reason message as below? I tried to search SK but no SK related to this matter.
Thank you.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello team!
we just had a very interesting call with TAC regarding this issue:
"[rad_decrypted_response_task.cpp:138] CRadDecryptedResponseTask::decrypt: [ERROR] response size is 1394880' limit to 1000000"
he said, Threat Clouds answer back to the RAD service is too large for the RAD service to handle!
Threat Cloud is constantly updating its indicator databases and this information is exceeding the 1000000 bytes limit on RAD.
and certain URL in Threat Cloud can contain alot more Indicators then other URL´s, so it means in future the 1000000 will be exceeding very likey on an everyday basis.
This value is also hardcoded in the RAD code, it required a hotfix.
This issue is already known, a Hotfix is available:
PMTR-97475 -> R82
PRJ-54192 -> R81.20
we installed and fixed in on top of R81.20 HFA 65
Also required is to empty the RAD cache via this GuiDBedit procedure "sk105179"
If answers from Threat Cloud are not fully loaded by RAD it can cause a chain of problems with web surfing.
this causes engine errors, https bypass error and many strange things.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Attached error message at below
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
And what does the referred log tell you ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is what it tells.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Confirm with TAC that your case matches but I believe there is a hotfix for this issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm not really understand what is the meaning of "Confirm with TAC that your case matches".
Meanwhile, I tried to search the R80.40 jumbo hotfix with keyword "decrypt", but no fix show in the jumbo hotix.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Log a case with support and have them check your symptoms, if they match other similar cases there is potentially a private hotfix that will address it. Eventually that same fix may form part of a Jumbo.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Noted on it. Will open a TAC case for this matter once ready
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So what is written in flow_2544_330697 ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Haven't check it yet, but i will check it once having free time
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you share the solution if you find it? I have same logs in my Firewall.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have the same issue for a particular site. It's coming up a lot. My referred log had pages and pages of these:
rad_curl_task.cpp:214] CRadCurlTask::write_callback: [INFO] nmemb = 1448
[rad_curl_task.cpp:213] CRadCurlTask::write_callback: [INFO] enter to ...
[rad_curl_task.cpp:214] CRadCurlTask::write_callback: [INFO] nmemb = 1448
but then more interestingly has this:
[rad_decrypted_response_task.cpp:138] CRadDecryptedResponseTask::decrypt: [ERROR] response size is 1394880' limit to 1000000
[rad_decrypted_response_task.cpp:81] CRadDecryptedResponseTask::getResponseString: [ERROR] failed to decrypt response 0xefc34238
[rad_response_task.cpp:67] CRadResponseTask::run: [ERROR] can not get response string
We seem to be overrunning some sort of response size limit.
It's all happening for the same URL over and over, the URL is nothing special, it's just this: cs.mytheresa.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Does the log entry in smart console show actual name of the protection?
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good question. So it first hits the HTTPS inspection blade, which tells us that this site's certificate is out of date. See 'bad cert' attached. The cert for the 'cs.mytheresa.com' in out of date, the cert on the main mytheresa.com site is fine.
Then the next thing is the Anti-Bot blade registers the 'Failed to decrypt CP Site Response' error.
I think I'll try putting in an override for the AB blade.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yep, cert is 100% valid, until March 10, 2024. I would also try add an exception first, good idea.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello team!
we just had a very interesting call with TAC regarding this issue:
"[rad_decrypted_response_task.cpp:138] CRadDecryptedResponseTask::decrypt: [ERROR] response size is 1394880' limit to 1000000"
he said, Threat Clouds answer back to the RAD service is too large for the RAD service to handle!
Threat Cloud is constantly updating its indicator databases and this information is exceeding the 1000000 bytes limit on RAD.
and certain URL in Threat Cloud can contain alot more Indicators then other URL´s, so it means in future the 1000000 will be exceeding very likey on an everyday basis.
This value is also hardcoded in the RAD code, it required a hotfix.
This issue is already known, a Hotfix is available:
PMTR-97475 -> R82
PRJ-54192 -> R81.20
we installed and fixed in on top of R81.20 HFA 65
Also required is to empty the RAD cache via this GuiDBedit procedure "sk105179"
If answers from Threat Cloud are not fully loaded by RAD it can cause a chain of problems with web surfing.
this causes engine errors, https bypass error and many strange things.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Interesting...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This sounds similar to the limit that existed in ioc_feeds in R81.10 and earlier.
This was fixed with new infrastructure (thus the ability to support 2 million+ IOC in R81.20).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
thank you for this! We see the same
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello team,
this is now fixed in R81.20 HFA 89
PRHF-36617/PRJ-54192 (Antibot error: Failed to Decrypt CP Site Response)
PRJ-54192 PRHF-31001 |
Anti-Bot |
The Anti-Bot Blade may generate error logs with the "Failed to Decrypt CP Site Response" reason. Refer to sk182494. |
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good to know!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Folks,
regarding this stuff, i just saw ... after installing HFA89/HFA90 the rad_conf.C is enriched with a new paramater:
cat /opt/CPsuite-R81.20/fw1/conf/rad_conf.C
(
:urlfs_service_check_seconds (7200)
:amws_service_check_seconds (1800)
:cpu_cores_as_number_of_threads (false)
:number_of_threads (0)
:threads_to_cores_ratio (0.334)
:minimal_resources_usage_ratio (0.2)
:number_of_threads_fast_response (0)
:number_of_threads_slow_response (0)
:number_of_threads_zph_response (0)
:number_of_threads_update (0)
:queue_max_capacity (2000)
:debug_traffic (false)
:use_dns_cache (true)
:dns_cache_timeout_sec (2)
:use_ssl_cache (true)
:cert_file_name ("ca-bundle.crt")
:cert_type ("CRT")
:ssl_version ("TLSv1_0")
:ciphers ("TLSv1")
:autodebug (true)
:timeout_events (false)
:normal_flow_events (false)
:log_timeouts (false)
:log_errors (true)
:number_of_reports (512)
:max_repository_multiplier (20)
:flow_timeout (6)
:excessive_flow_timeout (120)
:transfer_timeout_sec (15)
:max_flows (1000)
:max_pc_in_reply (0)
:max_content_length_in_reply (1000000)
:retry_mechanism_on (true)
:max_retries (25)
:retry_peroid_mins (15)
:happy_eyeballs_timeout (200)
:large_scale_min_cpus (100)
:large_scale_max_threads (70)
:max_threads (32)
:max_mal_pm_cache_size (100)
)
:max_content_length_in_reply (1000000)
this parameter can be tweaked to increase the buffer/cache for all return messages from ThreatCloud
set it to 1500000 for example 🙂
regarding this parameter
:autodebug (true)
we often get advice to stop the autodebug, since this creates a lot unnecessary load on the GW and is not required, since a manual RAD debug does the job as well 🙂
i would say its time for Check Point to create a comprehensive SK about rad_conf.C to explain every single parameter in great detail!
