Code With Me security overview
Code With Me is a powerful tool that gives you an ability to collaboratively work on your code. With that ability comes responsibility to keep your code and level of access secure.
Connection workflow
Let's say we have two users that want to connect to each other using Code With Me.
A user (Host) clicks the Start Code With Me Session action to create a session in their local IDE.
The local IDE sends a notification about the session creation to a lobby server, and asks for the session connection.
After the registration, the link is created.
The generated link is sent to another user (Guest) by any means that are available.
For example, it can be sent via Slack, WhatsApp messenger, e-mail, and so on.
The other user (Guest), clicks the received link.
A guest receives parameters on how to connect to the host and starts connecting.
At this point, the authorization from the host is requested. If the host grants the access, the connection is continued, and the guest connects to a session.
Data encryption
During a session, the host and the guest exchange private information including source code, passwords, and so on.
That is why the connection between the host and the guest is end-to-end encrypted using TLS 1.3. Whether the traffic flows between users directly, or through JetBrains relay servers, no third party, including JetBrains, can access this communication channel.
Protection against Man-in-the-Middle (MitM) attacks
Arguably, the biggest risk is malicious actors impersonating either the host or the guest to access the communication channel, or so-called Man-in-the-Middle attacks.
Impersonating a legitimate host
In the beginning of the connection, both a guest and a host generate a unique SSL certificate consisting of a public and a private sections. The guest and the host are authenticated by this pair of SSL certificates.
A join link contains a fingerprint of the host’s certificate, which is a hash of the public part of their SSL certificate. No one but the host holds a private section of this certificate. So, a guest cannot physically connect to a malicious actor, impersonating a host.
Impersonating a legitimate guest
Let's say the host created a link that leaked. For example, the host shared the link in a public channel.
So, if the host is not sure of the guest who is trying to connect to the created session, the host can check the pin code. The pin code must match that of the guest. The host should check that the guest can name the pin code displayed on the host's side using any available channel. If the pin code matches, then the user who is trying to connect to the session is the legitimate one.