Cyber Security Details

When connecting to Rapport from a browser, the browser is the basis of all communication security and acts as our Trusted Computing Base (TCB), which includes our server communications for both session management and WebRTC streams. Our security is thus directly impacted by the security of the browser.
For transactional communications, all our traffic is encrypted utilizing HTTPS. Data sent using HTTPS is secured via Transport Layer Security protocol (TLS), which provides three key layers of protection:

1. Encryption — encrypting the exchanged data to keep it secure from eavesdroppers. That means that while the user is browsing a website, nobody can "listen"     to their conversations, track their activities across multiple pages, or steal their information.

2. Data integrity — data cannot be modified or corrupted during transfer, intentionally or otherwise, without being detected.

3. Authentication — proves that your users communicate with the intended website. It protects against man-in-the-middle attacks and builds user trust, which translates into other business benefits.

Our security certificate (as a part of enabling HTTPS for our sites) is an OV certificate issued by http://SSL.com (RSA SSL subCA) and uses RSA-2048 / sha256RSA for a public key with yearly updates. We redirect legacy HTTP requests via permanent redirects (301 Moved Permanently).
Our public facing server certificates are purchased from http://SSL.COM (Dec/12/2021) and are issued for:

• api.rapport.cloud

• cdn.rapport.cloud

• accounts.rapport.cloud

• rapport.cloud

• www.rapport.cloud

When a CPI tower (Cloud Processing Infra - where individual sessions are handled from) is instantiated due to scaling out, it opens an SSH port (AMI has the public key and the username) - RRMS (private key + username) and RRMS ssh copies the certificate (tower certificate *.cpi-rapport.cloud - self-signed SSM parameter store containing our RRMS CA) and the necessary settings. As the next step, an NGINX instance gets (re)started that acts as a reverse proxy for the CPI communication server (CPI 2.x is a go server). All servers thus have server certificates issued for RRMS-CPI communications during tower provisioning.

Browser-to-backend communications use WebRTC for streaming HTTPS for session setups. All streams use end-to-end encrypted data channels utilizing the model of ICE/UDP -> DTLS (Datagram Transport Layer Security) -> SCTP (Stream Control Transmission Protocol - better than TCP on UDP). We chose WebRTC over WebSockets to enable better integration with non-browsers solutions and to simplify NAT traversal issues. Our CPI backend uses the latest PION code base (MIT License) to which we contributed with code development on fixing ICE connection timeouts. Code is at https://github.com/pion/webrtc .
More on WebRTC security can be found at https://webrtc-security.github.io/