I am interested in experimenting with WebRTC data streams as a method of low-latency communication between peers in multiplayer games in the browser, but have read that WebRTC is always encrypted. From http://webrtc-security.github.io/
Encryption is a mandatory feature of WebRTC, and is enforced on all components, including signaling mechanisms. Resultantly, all media streams sent over WebRTC are securely encrypted, enacted through standardised and well-known encryption protocols. The encryption protocol used depends on the channel type; data streams are encrypted using Datagram Transport Layer Security (DTLS) and media streams are encrypted using Secure Real-time Transport Protocol (SRTP).
It seems odd to me to have encryption so tightly coupled in this way. I can think of contexts where mandatory encryption is a hindrance, like multiplayer gaming where data transferred is non-sensitive and having to encrypt/decrypt data is unnecessary overhead, however small. For comparison, WebSockets communication is encrypted further down the stack by TLS if present, but the option of communicating over plain TCP is available as well. Am I misunderstanding this or is there a reason why it was decided that all WebRTC communication must be encrypted?
WebRTC is defining new realm for browsers which was not primarily intended. IMO Accessing camera/microphone rises enough resistance to use the technology solely so mandatory encryption gonna ease it.
The same reason as HTTPS communication is encrypted, they're trying to avoid a middle man to get advantage of the peer to peer communication
Related
If the signalling part of webrtc is handled by sip, is it mendatory that sip signalling has to be encrypted by TLS. Is it mendatory that sip over websocket has be encrypted as TLS
WebRTC uses TLS sessions or QUIC for its signaling transport – both are encrypted in nature. All other avenues for non-encrypted signaling don’t really exist in WebRTC. Theoretically they might work, but some browsers will either block them altogether or require the user to grant access to the camera and microphone on each interaction. Deploying anything serious to production with WebRTC without encrypting signaling for their browser implementations is not a real alternative.
WebRTC “forces” you to encrypt your signaling. What is left out of scope of WebRTC are things like authentication, authorization and identity management. You are free to do as you please in that domain – just make sure to do something here – and not leave this wide open for pranksters or worse.
For native applications on mobile, desktop or embedded – you can do whatever you like. That said, the mindset must be the same – mandatory encrypted signaling.
reference : Best webrtc related blog
WebRTC uses DTLS for encryption of SCTP (data). Furthermore it uses DTLS for key exchange of SRTP (media). But I do not quite understand, whether it also uses DTLS for encryption of SRTP. So my question: Does WebRTC use DTLS solely for key exchange (DTLS-SRTP) or does it encrypt SRTP additionally to its internal encryption mechanism (at least optionally)?
Why I am asking:
RFC 6904 as well as RFC 3711 state that SRTP provides authentication, but not encryption, of the headers of RTP packets. So only the payload of SRTP is encrypted by design.
What confuses me:
Many sources claim WebRTC to be fully end-to-end encrypted.
I am especially interested in the implementation of WebRTC in gstreamer.
DTLS is used for the handshake, but then the keys are extracted and a SRTP context is initialized.
I am not familiar with GStreamer, but in Pion WebRTC we connect via DTLS here. The WebRTC clients negotiate which side is a DTLS Server and which is a DTLS Client via the SDP.
When the DTLS handshake is complete you then export the keying material, you can see that here
If you are interested in seeing how SRTP works you can check out pion/srtp. It is pretty simple though, it is just AES and then you generate an authentication tag. You can see it all here
By WebRTC standard all connections should be encrypted via DTLS. This is great. However, unless application verifies authenticity of the peer, the connection is vulnerable to man in the middle (MITM) attack.
The question is how to do this with libWebRTC (http://www.webrtc.org/native-code) specifically in Objective C interface. Ideally, I would like to be able to specify my own certificate for WebRTC connection. In this case I will be able to verify it through my application-specific secure channel. If this is not possible, then what is the suggested approach? I will be grateful for any hints.
The WebRTC specification does not include the signaling layer, i.e., how the fingerprints, ICE candidates, etc are exchanged between peers. This means that in almost all WebRTC applications, there's a signaling socket to rapidly signal the connection with a service which exchanges the information between two peers.
Instead of supplying your own certificates or fingerprints, what you want to do is authenticate the signaling over which those are sent.
Your signaling server effectively is the man-in-the-middle, especially in cases of using an MCU or SFU. It should verify the identity of clients exchanging signaling information, and ensure the signaling information is exchanged between mutually agreeing peers (i.e., calling one another by address, or joining a common "room").
So the answer is: use secure websockets, and authenticate clients sending/receiving WebRTC offer/answer information. If you do that, there's no risk of man-in-the-middle attacks, beyond the risk of any other HTTPS+WSS application.
So, a few questions:
1) Does using a client certificate during TLS provide non-repudation?
1a) Follow-up: If so, does having a load balancer handle the transaction still provide this assurance at the end server/service level?
2/2a) Same questions as above, but for message integrity.
I know the answers for MLS, but I'm not sure about TLS. If I understand correctly, TLS involves a handshake where the shared secret is established, and that is used to secure the pipe - so none of these things hold, since each message uses only the shared secret.
Does using a client certificate during TLS provide non-repudation?
No. This is unfortunate, as it engages in everything that is necessary to implement it except making the digital signature available. It might be possible to stand up in court as an expert witness and make a case that as it all happens under the hood the transaction should be non-repudiable anyway, but I would much rather prefer to be able to produce an actual digital signature in court. Then there is nothing to debate.
2/2a) Same questions as above, but for message integrity.
TLS provides message privacy, message integrity, and authentication of at least one of the peers (unless you have broken that). It doesn't provide authorization, and it doesn't provide non-repudiation as above.
Does using a client certificate during TLS provide non-repudation?
1a) Follow-up: If so, does having a load balancer handle the
transaction still provide this assurance at the end server/service
level?
TLS is about transport level security (hence the name Transport Layer Security). It aims to secure the communication between the client and the server (possible a load-balancer), according to the specification:
The primary goal of the TLS Protocol is to provide privacy and data
integrity between two communicating applications.
You could in principle keep the entire TLS exchange, in particular keeping the handshake to prove that the client-certificate signed the content of the Certificate Verify message. You would also have to keep the various generated/calculated intermediate values (in particular the master secret, and subsequently the shared key). There is one problem with this: the TLS specification requires (only with "should") the pre-master secret to be deleted. This could make proving the path back from data to client certificate rather difficult. (You would certainly have to tweak SSL/TLS stacks to record all this too.)
In addition, recording all this would be under the application protocol (assuming HTTPS here, but the same would apply to other protocols). This would certainly be another layer before you get to the actual data you want not to be repudiated. (The problem is that you may have to record the entire session for proof, without being able to select with request/response to isolate.)
You may also run into further problems when it comes to session resumption (for example) and generally parallel requests. This would certainly add to the confusion.
Overall, it's not what TLS is designed for. Non-repudiation is about being able to keep a proof of the exchange, possibly to be able to display it in court or similar. Explaining to people (who might not have the technical background) how you make the link between the interesting data and the client certificate could be challenging.
2/2a) Same questions as above, but for message integrity.
TLS guarantees the integrity of the communication (see introduction to the specification). (All of this, of course, provided that the client verifies the server certificate correctly, although you should be able to detect a MITM if you're using client certificates anyway.)
Integrity will only be guaranteed up to the point where the TLS connection ends. This will be the load-balancer itself if you're using one. (Of course, it's better to link the load-balancer to its worker nodes via a network that can be trusted.)
If you're after a system where clients can send non-repudiating messages, which can be audited at a later date, you should look into message level solutions.
To the best of my knowledge SSL is to prevent only Eavesdropping i.e. plucking the digital data passing across a network. So, to prevent password SSL encrypts the data at the login page and decrypt it at database. Finally it carries information securely. I think this can be implemented even using some encryption algorithms like Md5/SHA/other?
What's the difference between SSL and normal encryption?
Please correct me if any of the above statements are false.
SSL is a protocol for transmitting encrypted data. It is not an encryption algorithm, per se. Though HTTPS uses SSL to encrypt web communications, SSL wasn't built for HTTP and has little to do with login pages, though it is common for login pages to be accessed via HTTPS (and hence SSL). Many secure protocols are carried over SSL.
MD5 and the SHA family aren't encryption algorithms either. They are hashing algorithms.
SSL can not prevent eavesdropping if the CA is not safe. As we have seen lately. The data is encrypted via SSL thats right e.g. not like you mentioned with Hashes(Hashing is not Encryption) its using encryption algorithms. Asynchronous and synchronous algorithms. The Asynchronous encryption is a certificate implementation.
To your question: "Whats the difference"
SSL - is a commonly used and accepted way of using encryption e.g for HTTPS in order to secure HTTP connection (using various encryption techniques) and a solid documentation of handshaking.
SSL is also used to secure different tcp protocols(like mail(smtps, pop3s, imaps), ftp(s), etc..)
Encyrption - is used inside SSL.
SSL is supported in common browsers and server implementations. If you would want to use "normal encryption" you have to implement everything by yourself.
To the best of my knowledge SSL is to
prevent only Eavesdropping
Incorrect. SSL provides secrecy, integrity, and authentication, and provides a mechanism for you the application to perform authorization. It protects you from eavesdropping, tampering, active man-in-the-middle attacks, truncation attacks, ... It is a lot more than mere encryption.