Feature Request: ICE support Host TLS candidates

[k-wasniowski]

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.

[juberti]

are you thinking the candidates would be IPs or FQDN? If IP, how would certificate verification be handled?

[k-wasniowski]

Rather FQDN based only

[alvestrand]

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?

[k-wasniowski]

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.

[alvestrand]

I find traces in the code of a protocol called "TLS", but I can't find a spec for it at the moment.

[k-wasniowski]

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

[fippo]

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

[juberti]

TURN-TLS is well defined by RFC 5766, so we can set that aside.

Here, we can either try to focus on:

1. ICE-TLS using FQDN candidates
2. 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.

[fluffy]

If we are going to do this, I think we should consider fake QUIC handshake for UDP as well

[juberti]

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.

[Sean-Der]

@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

[juberti]

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 😀

[juberti]

@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...

[k-wasniowski]

@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.

[martinthomson]

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?