Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Encrypted response reasoning #72

Merged
merged 2 commits into from
Jul 19, 2023
Merged

fix: Encrypted response reasoning #72

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f08e70b
Update relying-party-solution.rst
NetBender Jul 17, 2023
7234d2b
Merge branch 'italia:versione-corrente' into versione-corrente
NetBender Jul 17, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 1 addition & 2 deletions docs/en/relying-party-solution.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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:

Expand Down