diff --git a/docs/en/relying-party-solution.rst b/docs/en/relying-party-solution.rst
index 42d398975..8ee2c156e 100644
--- a/docs/en/relying-party-solution.rst
+++ b/docs/en/relying-party-solution.rst
@@ -384,8 +384,7 @@ After getting the User authorization and consent for the presentation of the cre
 .. note::
     **Why the response is encrypted?**
 
-    The response sent from the Wallet Instance to the Relying Party is encrypted
-    to prevent a technique called `SSL split attack <https://pdos.csail.mit.edu/papers/ssl-splitting-usenixsecurity03/>`_, that could be enabled by malicious app installed locally by Users,that intecepts the network traffic, or be present by-design in network environments where a next-generation firewalls or other security devices may reduce the privacy of the Users.
+    The response sent from the Wallet Instance to the Relying Party is encrypted to prevent a malicious agent from gaining access to the plaintext information transmitted within the verifier's network. This is only possible if the network environment of the verifier employs `TLS termination <https://www.f5.com/glossary/ssl-termination>`_. Such technique employs a termination proxy that acts as an intermediary between the client and the webserver and handles all TLS-related operations. In this manner, the proxy deciphers the transmission's content and either forwards it in plaintext or by negotiates an internal TLS session with the actual webserver's intended target. In the first scenario, any malicious actor within the network segment could intercept the transmitted data and obtain sensitive information, such as an unencrypted response, by sniffing the transmitted data.
 
 Below a non-normative example of the request: