Starting with version 97, Google Chrome has decided to deprecate and remove what it describes as ‘a security problem' from Chromium and WebRTC.
The SDES key exchange mechanism for WebRTC, which was declared Historic by the Internet Engineering Task Force (IETF) in 2013, is finally being removed from the stable Chrome version 97, which is scheduled to release on Jan 4, 2022.
What is SDES key exchange mechanism?
Stands for Session Description Protocol Security Descriptions, SDES for Media Streams was proposed for standardization to the IETF in 2016 as a way to negotiate the key for Secure Real-time Transport Protocol.
The keys transported in the Session Description Protocol (SDP) attachment of a Session Initiation Protocol (SIP) message ensure the attachment is end-to-end encrypted so that no one else can see the attachment.
The problem statement
The Google Chrome team says it exposes session keys to Javascript. Therefore, entities with access to the negotiation exchange, or with the ability to subvert the Javascript, can decipher the media sent over the connection. This issue pertains to both data as well as audio/video communication.
"The reason why SDES is deprecated is that it is a security problem: It exposes session keys to Javascript, which means that entities with access to the negotiation exchange, or with the ability to subvert the Javascript, can decrypt the media sent over the connection," Google Chrome notes.
Since the security of communications has been a long-standing issue in the SIP world, there has to be a way for the communicating parties to establish a secure channel to prevent recovery and modification to message content.
Ideally, the security mechanisms like Secure Real-time Transport Protocol (SRTP), Datagram Transport Layer Security (DTLS), and DTLS-SRTP would solve the purpose. However, these technologies and protocols in the WebRTC context is not as secure today as it was in the past.
Unlike a conventional SIP proxy, the Web server controls not only the channel between the communicating endpoints but also the application running on the user's browser. Although Chrome could get rid of the calling service out of the loop and directly present trusted information, modern web browsers are recommended to avoid this whenever possible.
The solution
By removing the SDES key exchange mechanism for WebRTC, Google Chrome will be protected against retrospective attack, in which an uncompromised calling service could be compromised with the attacker accessing the protected media stream as well as full control of the calling service.
This form of attack is particularly serious in the WebRTC context because it is standard practice in Web services to run extensive logging and monitoring. Thus, it is highly likely that if the traffic key is part of any HTTP request it will be logged somewhere and thus subject to subsequent compromise.
Google Chrome Team has said that the usage of SDES key exchange mechanism for WebRTC in Chrome has declined significantly over the recent year.
Comments
Post a Comment