morganava
commented
2 years ago So to be clear, this is a MITM attack not in the protocol itself: if you connect to an onion service and complete a gosling handshake, the client can be sure that no other parties had access to the communications that occurred. A MITM can occur if a client gets a server's identity through insecure/MITM'able means (eg from an HTTP clearnet website), just like many other protocols.
So the gosling protocol was designed with the assumption users are able to share their onion service ids safely/securely by some side-channel and that it is the connecting client which is potentially untrustworthy and must be validated.
However, it was also designed to include an application-specific challenge/response portion to the handshake so that application developers can include whatever further authentication/validation as makes sense for their application. Different applications may have different verification needs (compare an instant messenger vs distributed file sharing for instance).
The reviewed version of the protocol did not allow for SMP-style handshakes, but this has since been fixed as of commit 9776bd19a853bc7b6a7d789b503b394a74dd2d65 by moving/changing the client_identity to be an argument to gosling_identity::begin_handshake() from gosling_identity::send_response(). This way, an identity server may send along some SMP-like shared secret derived parameter with the endpoint_challenge for the client to verify (and the client may send their own derived parameter with the challenge response for the server to verify).
Technical description:
Consider the following scenario: Alice wants to set up a connection over TOR with Bob. To this end, Bob has published his service id sid_Bob on an untrusted platform. Charlie controls the untrusted platform and replaces sid_Bob with his own service id sid_Charlie . Alice, believing she is connecting to Bob will set up a connection with Charlie instead. Alice will complete the handshake with Charlie's identity server, and open a channel on Charlie's endpoint service. Charlie will now open a connection with Bob using sid_Bob and will end up with a channel on Bob's endpoint service.
At this point Charlie can eavesdrop on communication between Alice and Bob and even inject and or alter messages of his own to both Alice and Bob.
The reason this is possible is that there is no system in place to establish trust between the communicating parties.
Impact:
An adversary who is able to successfully insert themselves between the communicating parties is able to eavesdrop on and tamper with their data without their knowledge.
Recommendation:
To mitigate this issue we recommend implementing a provision that establishes trust after the communication channel has been established.
One could consider the socialist millionaire protocol (SMP) to achieve this. It requires Alice and Bob to share a secret through a secure side channel. The knowledge of this secret is verified by the protocol without transmitting any information about the secret itself.
The SMP is implemented in the Off-The-Record (OTR) secure communications protocol. One could decide on implementing OTR for secure communication and leave Gosling to negotiate a channel to set up a secure channel over.
Sources
• https://blog.securegroup.com/the-socialist-millionaire-protocol-how-secure-chat-prevents-mitm-attacks • https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html • https://robertheaton.com/otr1