- Products
- Learn
- Local User Groups
- Partners
- More
Quantum Spark Management Unleashed!
Introducing Check Point Quantum Spark 2500:
Smarter Security, Faster Connectivity, and Simpler MSP Management!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
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.
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.
And what does the referred log tell you ?
This is what it tells.
Confirm with TAC that your case matches but I believe there is a hotfix for this issue.
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.
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.
Noted on it. Will open a TAC case for this matter once ready
So what is written in flow_2544_330697 ?
Haven't check it yet, but i will check it once having free time
Can you share the solution if you find it? I have same logs in my Firewall.
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
Does the log entry in smart console show actual name of the protection?
Andy
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.
Yep, cert is 100% valid, until March 10, 2024. I would also try add an exception first, good idea.
Andy
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.
Interesting...
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).
thank you for this! We see the same
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. |
Good to know!
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!
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
10 | |
7 | |
7 | |
6 | |
6 | |
5 | |
5 | |
5 | |
5 | |
5 |
Thu 04 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: External Risk Management for DummiesWed 10 Sep 2025 @ 11:00 AM (CEST)
Effortless Web Application & API Security with AI-Powered WAF, an intro to CloudGuard WAFWed 10 Sep 2025 @ 11:00 AM (EDT)
Quantum Spark Management Unleashed: Hands-On TechTalk for MSPs Managing SMB NetworksThu 04 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: External Risk Management for DummiesWed 10 Sep 2025 @ 11:00 AM (EDT)
Quantum Spark Management Unleashed: Hands-On TechTalk for MSPs Managing SMB NetworksFri 12 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live Netherlands - Sessie 38: Harmony Email & CollaborationAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY