[jitsi-dev] How is the SSLTCP ICE candidate preamble composed?


#1

Hello,

org.ice4j.ice.harvest.GoogleTurnSSLCandidateHarvester#SSL_CLIENT_HANDSHAKE
defines a preamble that the client sends when doing SSLTCP ICE.

Where is this documented? Is this mimicing a SSL 2.0 clienthello?

Regards,

  Guus


#2

I don't think there's detailed documentation anywhere. I think it's an SSL ClientHello/ServerHello, but I don't know the details. See here for a discussion on the topic:
https://groups.google.com/forum/#!msg/discuss-webrtc/YDPjHjSVkPM/8vNu6kCODQAJ

Regards,
Boris

···

On 09/11/2017 10:16, Guus der Kinderen wrote:

Hello,

org.ice4j.ice.harvest.GoogleTurnSSLCandidateHarvester#SSL_CLIENT_HANDSHAKE defines a preamble that the client sends when doing SSLTCP ICE.

Where is this documented? Is this mimicing a SSL 2.0 clienthello?


#3

Thanks for the reference. Does ice4 / jitsi also support candidates that
don't fake SSL like this, but do proper SSL/TLS? If not, is that worth
considering?

If I understand things right, that should help with enterprise-grade
firewalls (that are not fooled by the pseudo-SSL).

···

On 9 November 2017 at 17:54, Boris Grozev <boris@jitsi.org> wrote:

On 09/11/2017 10:16, Guus der Kinderen wrote:

Hello,

org.ice4j.ice.harvest.GoogleTurnSSLCandidateHarvester#SSL_CLIENT_HANDSHAKE
defines a preamble that the client sends when doing SSLTCP ICE.

Where is this documented? Is this mimicing a SSL 2.0 clienthello?

I don't think there's detailed documentation anywhere. I think it's an SSL
ClientHello/ServerHello, but I don't know the details. See here for a
discussion on the topic:
https://groups.google.com/forum/#!msg/discuss-webrtc/YDPjHjS
VkPM/8vNu6kCODQAJ

Regards,
Boris


#4

I don't know of any specification or implementation that does this.

Boris

···

On 10/11/2017 04:08, Guus der Kinderen wrote:

Thanks for the reference. Does ice4 / jitsi also support candidates that don't fake SSL like this, but do proper SSL/TLS? If not, is that worth considering?


#5

This might be my misunderstanding showing, but doesn't this apply:
https://tools.ietf.org/html/rfc5766#section-2.1 ?

Immediate follow-up questions: in the Jitsi-setup, what is acting as the
stun-client? Is that in the ofmeet-codebase, or is that supplied by the
browser, or, am I completely misinterpreting the architecture?

···

On 11 November 2017 at 01:38, Boris Grozev <boris@jitsi.org> wrote:

On 10/11/2017 04:08, Guus der Kinderen wrote:

Thanks for the reference. Does ice4 / jitsi also support candidates that
don't fake SSL like this, but do proper SSL/TLS? If not, is that worth
considering?

I don't know of any specification or implementation that does this.

Boris


#6

harg. *turn*-client, not stun-client.

···

On 21 November 2017 at 15:17, Guus der Kinderen <guus.der.kinderen@gmail.com > wrote:

This might be my misunderstanding showing, but doesn't this apply:
https://tools.ietf.org/html/rfc5766#section-2.1 ?

Immediate follow-up questions: in the Jitsi-setup, what is acting as the
stun-client? Is that in the ofmeet-codebase, or is that supplied by the
browser, or, am I completely misinterpreting the architecture?

On 11 November 2017 at 01:38, Boris Grozev <boris@jitsi.org> wrote:

On 10/11/2017 04:08, Guus der Kinderen wrote:

Thanks for the reference. Does ice4 / jitsi also support candidates that
don't fake SSL like this, but do proper SSL/TLS? If not, is that worth
considering?

I don't know of any specification or implementation that does this.

Boris