webrtc-extensions
webrtc-extensions copied to clipboard
w3c
Feature Request: ICE support Host TLS candidates
Currently, browsers supports mainly:
- ICE-UDP
- ICE-TCP
- TURN-UDP
- TURN-TCP
- TURN-TLS
Chromium in addition supports establishing ICE connectivity with SSLTCP, which "hacks" firewalls to think that it's actual TLS connection.
It would be great to have a possibility to avoid doing a TURN discovery for TURN-TLS scenario, and simply add a possibility to connect to SFU's with public IP.
are you thinking the candidates would be IPs or FQDN? If IP, how would certificate verification be handled?
When connecting to SFUs with public IPs, ICE-UDP and ICE-TCP both work. What's the scenario you want to support where those mechanisms are not enough?
There are cases in which users block bare UDP and TCP and rely only on encrypted traffic, due to security concerns.
I believe ssltcp tried to address this issue, but it's not able to cheat more complex firewalls.
I find traces in the code of a protocol called "TLS", but I can't find a spec for it at the moment.
I think there are no ICE-TLS spec at the moment, but there are no TURN-TLS either if i'm correct (I might be wrong). I'm happy to work on the spec if needed.
Harald, I had an sample implementation done in the libwebrtc which I have tested couple times with local chromium build.
If you would be intested to take a look, I can create a CL with the changes
Rather FQDN based only
RFC 8445 put FQDN based ICE candidates into a limbo (pointer needed). It is a tough problem...
"SSLTCP" used a fake SSLv2 handshake and from what I gathered came up in libjingle during the mid-2000s. The closest thing I have seen to an actual spec is MS-TURN which calls it "Pseudo-TLS over TCP". The gist is basically "put a TLS 1.0" handshake with hardcoded stuff to fool firewalls. I assume it did back then but these days I expect DPI to reject TLS 1.0 handshakes. The nice property is that it avoids double encryption
TURN-TLS is well defined by RFC 5766, so we can set that aside.
Here, we can either try to focus on:
- ICE-TLS using FQDN candidates
- ICE-TCP but with a fake TLS handshake, a la "ssltcp".
#1 is tricky due to unclear procedures for resolving FQDNs WRT ICE, as @fippo mentions. (eg v4 vs v6, multiple IPs returned from the query, etc)
#2 might also be tricky as we'd need to signal the fact that the candidate needs the fake handshake, and probably also what version of handshake should be used. The IETF also historically frowned upon techniques that try to circumvent network restrictions, so that could also be an obstacle.
Long story short, I think this is worth pursuing, but it's not going to be a cakewalk.
If we are going to do this, I think we should consider fake QUIC handshake for UDP as well
I was on a walk today and realized I've been thinking about this the wrong way. The issue is that we don't have a hostname to verify the cert. but we can solve that simply by adding a SAN attribute to the a=candidate line in SDP. No DNS needed.
Agree with @fluffy we can also add QUIC as a new proto in the a=candidate and use the same SAN attribute.
@k-wasniowski Would ice-tls work for you?
Uses fingerprint, IPs are not a problem at all. I have been waiting to implement it in Pion for years, but lack of interoperability made it hard to get excited
Good suggestion. Just comes down to whether we want to put a SAN or a fingerprint in the a=candidate line. Or we could support both 😀
@pthatcherg also has https://datatracker.ietf.org/doc/html/draft-thatcher-p2p-quic-00 for sending RTP over QUIC, although it doesn't touch on how to verify certificates. I think the best path forward is to revive @martinthomson's draft as Sean suggests, and perhaps add SAN support if there's interest.
@fippo probably one more thing we can ask Chrome for...
@Sean-Der I believe this would be an great solution, since it should fit our needs. I think having an additional way to establish connection with SAN attribute could be interesting addition.
Initially, I've not been thinking about QUIC, but having it would be also an interesting option.
BTW, not me, but Pål-Erik. I would have to ask what you have in mind if you are talking about SAN (subjectAltName, I presume). Given that WebRTC relies on the session description for e2e security, what goals do you seek from having a TLS connection? Is it just to dupe middleboxes?
@martinthomson Not even middleboxes, but there are certain users which blocks pure UDP/TCP for security concerns, and allows only TLS traffic. For such cases, TURN-TLS is a good fit, however it introduces extra steps required for establishing connection to the server (it's rather client-server solution). For such cases, it would be great to have ability to connect directly to the servers which have public IP's.
This also needs some thought what the deployment model is going to be. I assume this is going via some load balancer in front of the server whose CA-signed certificate will be different from the servers (typically) self-signed certificate. This makes "gathering" the candidate a bit more involved for the server and there might be multiple load balancer IPs which map to multiple candidates. Not as simple as TURNs with round-robin DNS or colocating TURNs and the server but might be worth the effort.
Verification via SAN dNSName as described in https://www.rfc-editor.org/rfc/rfc9525 should be straightforward.
What purpose does the validation serve in this case? If you are authenticating via SDP and a=fingerprint, doesn't that just increase the operational burden? Or does the middlebox you are duping (@k-wasniowski that's 100% a middlebox case) have access at a level that necessitates the use of "real" names?
@k-wasniowski Have you seen/know if these middle boxes require TLS use a certificate signed by a certificate authority?
@fippo That's a great point. It would be nice if both could be supported. I have one deploy that is exactly like you describe (behind Cloudflare Spectrum)
I worked on another that wasn't behind a LB at all. If I wanted to deploy TURN-TLS I would just generate a self-signed certificate for each individual server. The signaling server grabs an offer from the WebRTC server that has the least load currently.
@Sean-Der I think Chrome will validate certs for TURN/TLS? Is that not what you were seeing?
@martinthomson I agree the value of verification is less clear here than in TURN/TLS, especially given the burden of aligning the cert between the LB and actual WebRTC host.
If you are authenticating via SDP and a=fingerprint, doesn't that just increase the operational burden?
You are connecting to an IP address through TLS. The load balancer (if there is one) should not know the SFUs certificate + private key that is being used for DTLS. This is different (or similar?) from TURN/TLS where the load balancer has the key+cert for the hostname of the TURN server. We have an IP address here.
Ideally we can say
- if the candidate has a
subjectAlternativeNameextension-att-namerun Peter's rules with the value. - otherwise expect the other side's
fingerprintto match the one in the SDP
Since someone said middleboxes we should also consult that Joe guy 😂
Let's say we will go with ip address + certificate. In that case, webrtc client would have to initialize tls connection, verify certificate and skip hostname verification, correct? @juberti @fippo
Correct. Client would only verify the hostname if we used the SAN approach.
@juberti should webrtc support both approaches? Or rather one of them ?
Let's assume that ICE TLS candidates would have following format:
a=candidate:3 1 TLS 2113933322 X.X.X.X 443 typ HOST tcptype passive fingerprint sha-1 XX:YY:ZZ
Should it require symmetric candidates in the way that both party needs to send it's fingerprint? Usually in establishing TLS connection only a fingerprint of the server is necessary to validate by the client. So that it could be not necessary for both party to send its fingerprint, only the answerer should provide it.