ICE TCP Pseudo-SSL implementation

[Marcello Vezzelli]

Hi everyone,
I've had some experiences with ssltcp ICE candidates and WebRTC
Pseudo-SSL implementation and I'm quite disappointed.
Firewalls with full SSL handshake checks (like Watchguard for example)
drop ICE connections detecting them as illegal.

For those who don't know, Pseudo SSL implementation consists in Chrome
sending a SSL Client Hello message, server replying with a SSL Server Hello.
After this 2 packets exchange, instead of proceeding with SSL handshake
(server should send CA certificate), Chrome starts to send STUN then
DTLS over the same connection. Each packet has a 2 bytes header
containing packet size.
This is a partial SSL handshake that might fool only some super cheap
packet inspection firewalls.
For sure, this will never work in enterprise environments with good
firewalls.
If UDP ports are closed, Hangouts won't work either as it relies on the
same ssltcp ICE connection.

Is there a real reason (apart from SSL overhead) why ssltcp ICE
candidates do not use a regular SSL connection instead of a Pseudo-SSL one?
Having DTLS inside SSL means encrypting two times and that might sound
silly: is it sillier than breaking SSL protocol with an hack and getting
blocked by professional firewalls?

I'd be glad to share opinions and experiences on this matter.

regards
Marcello Vezzelli

[Philipp Hancke]

2015-12-08 8:32 GMT-08:00 Marcello Vezzelli <m...@3cx.com>:

Hi everyone,
I've had some experiences with ssltcp ICE candidates and WebRTC Pseudo-SSL implementation and I'm quite disappointed.
Firewalls with full SSL handshake checks (like Watchguard for example) drop ICE connections detecting them as illegal.

For those who don't know, Pseudo SSL implementation consists in Chrome sending a SSL Client Hello message, server replying with a SSL Server Hello.
After this 2 packets exchange, instead of proceeding with SSL handshake (server should send CA certificate), Chrome starts to send STUN then DTLS over the same connection. Each packet has a 2 bytes header containing packet size.
This is a partial SSL handshake that might fool only some super cheap packet inspection firewalls.

Which are common enough to make this worthwhile. Apart from Chrome's proprietary implementation Microsoft has TURN extensions which use the same pattern, see https://msdn.microsoft.com/en-us/library/office/cc431507(v=office.12).aspx if you're interested.

 

For sure, this will never work in enterprise environments with good firewalls.
If UDP ports are closed, Hangouts won't work either as it relies on the same ssltcp ICE connection.

Is there a real reason (apart from SSL overhead) why ssltcp ICE candidates do not use a regular SSL connection instead of a Pseudo-SSL one?
Having DTLS inside SSL means encrypting two times and that might sound silly: is it sillier than breaking SSL protocol with an hack and getting blocked by professional firewalls?

You can use TURN/TLS if you want a full TLS handshake. It comes with double encryption though.

I'd be glad to share opinions and experiences on this matter.

regards

Marcello Vezzelli





--

--- You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/5667061B.6020109%403cx.com.
For more options, visit https://groups.google.com/d/optout.

[Marcello Vezzelli]

Il 08/12/2015 18:46, 'Philipp Hancke' via discuss-webrtc ha scritto:

This is a partial SSL handshake that might fool only some super cheap packet inspection firewalls.

Which are common enough to make this worthwhile. Apart from Chrome's proprietary implementation Microsoft has TURN extensions which use the same pattern, see https://msdn.microsoft.com/en-us/library/office/cc431507(v=office.12).aspx if you're interested.

Thank you for the hint. It's very interesting.
Actually this Microsoft implementation sends also a Server Hello Done after Server Hello.
I'm not 100% sure but it seems to me that Chrome implementation uses only Client Hello and Server Hello. Nothing must be sent after Server Hello otherwise Chrome disconnects with a protocol error.
Maybe the additional Server Hello Done is more firewall friendly.
If this won't harm Chrome it's a thing to try.

Is there a real reason (apart from SSL overhead) why ssltcp ICE candidates do not use a regular SSL connection instead of a Pseudo-SSL one?
Having DTLS inside SSL means encrypting two times and that might sound silly: is it sillier than breaking SSL protocol with an hack and getting blocked by professional firewalls?

You can use TURN/TLS if you want a full TLS handshake. It comes with double encryption though.

I will investigate this option too. The most important thing is having a fallback for very restrictive networks. Double encryption is a price to pay.
Most important is using a single TCP port, possibily 443, for both ssltcp ICE and TURN/TLS.
Are you aware of a similar implementation?

Thanks for your time.

--

Regards,
Marcello Vezzelli

Marcello Vezzelli

Senior Software Developer

Phone: +39 (055) 093 5447

Fax: +357 22 444 033

www.3CX.com

[Marcello Vezzelli]

Il 08/12/2015 21:48, Marcello Vezzelli ha scritto:

>> Which are common enough to make this worthwhile. Apart from Chrome's
>> proprietary implementation Microsoft has TURN extensions which use the
>> same pattern, see
>> https://msdn.microsoft.com/en-us/library/office/cc431507(v=office.12).aspx if
>> you're interested.
>

> Actually this Microsoft implementation sends also a Server Hello Done
> after Server Hello.
> I'm not 100% sure but it seems to me that Chrome implementation uses only
> Client Hello and Server Hello. Nothing must be sent after Server Hello
> otherwise Chrome disconnects with a protocol error.
> Maybe the additional Server Hello Done is more firewall friendly. If this
> won't harm Chrome it's a thing to try.

Chrome does not recognize Server Hello Done message on Pseudo SSL: adding a
Server Hello Done breaks Chrome pseudo SSL parser.
After Server Hello, Chrome is expecting to receive the 2 bytes header
followed by STUN reply.

Just in case someone is working on interoperability.

regards
Marcello Vezzelli

[Marcello Vezzelli]

Il 08/12/2015 18:46, 'Philipp Hancke' via discuss-webrtc ha scritto:

You can use TURN/TLS if you want a full TLS handshake. It comes with double encryption though.

Hi Philipp,
can you point me to an implementation of TURN/TLS working with Chrome?

Thanks!

[Iñaki Baz Castillo]

2015-12-08 17:32 GMT+01:00 Marcello Vezzelli <m...@3cx.com>:
> For those who don't know, Pseudo SSL implementation consists in Chrome
> sending a SSL Client Hello message, server replying with a SSL Server Hello.
> After this 2 packets exchange, instead of proceeding with SSL handshake
> (server should send CA certificate), Chrome starts to send STUN then DTLS
> over the same connection. Each packet has a 2 bytes header containing packet
> size.

I'm a bit afraid. Is this related to ICE+DTLS+SRTP/SCTP over TCP
(which already works in Chrome)? or is this another completely
different stuff?
You said Chrome implements that ("ssltcp"), is that right? where is
that defined within the WebRTC spec?

NOTE: WebRTC over TCP (I don't mean TURN9 works fine in Chrome and it
is easy to implement in server side. It consist in:

- Chrome connects to a TCP port in open in the remote peer.
- Normal STUN/ICE, DTLS, SRTP and SCTP packets are sent over this TCP
connection with 2 bytes header containing the packet size.


--
Iñaki Baz Castillo
<i...@aliax.net>

[Iñaki Baz Castillo]

2015-12-22 12:24 GMT+01:00 Iñaki Baz Castillo <i...@aliax.net>:
> (I don't mean TURN9

Sorry => (I don't mean TURN)

[Philipp Hancke]

2015-12-22 12:24 GMT+01:00 Iñaki Baz Castillo <i...@aliax.net>:

2015-12-08 17:32 GMT+01:00 Marcello Vezzelli <m...@3cx.com>:
> For those who don't know, Pseudo SSL implementation consists in Chrome
> sending a SSL Client Hello message, server replying with a SSL Server Hello.
> After this 2 packets exchange, instead of proceeding with SSL handshake
> (server should send CA certificate), Chrome starts to send STUN then DTLS
> over the same connection. Each packet has a 2 bytes header containing packet
> size.

I'm a bit afraid. Is this related to ICE+DTLS+SRTP/SCTP over TCP
(which already works in Chrome)? or is this another completely
different stuff?

Similar. Roughly "over TCP preceded by something that looks like a TLS handshake".

You said Chrome implements that ("ssltcp"), is that right? where is
that defined within the WebRTC spec?

It is not.

[Iñaki Baz Castillo]

2015-12-22 12:29 GMT+01:00 'Philipp Hancke' via discuss-webrtc
<discuss...@googlegroups.com>:

>> I'm a bit afraid. Is this related to ICE+DTLS+SRTP/SCTP over TCP
>> (which already works in Chrome)? or is this another completely
>> different stuff?
>
>
> Similar. Roughly "over TCP preceded by something that looks like a TLS
> handshake".

And... why??

And how/when does Chrome decide to send that ugly/propietary stuff
instead of the standard STUN/DTLS/STRP/SCTP-over-TCP?

Does it mean that, in case the remote peer provides TCP candidates,
Chrome will send this privative stuff?

[Marcello Vezzelli]

Il 22/12/2015 12:24, Iñaki Baz Castillo ha scritto:

> I'm a bit afraid. Is this related to ICE+DTLS+SRTP/SCTP over TCP
> (which already works in Chrome)? or is this another completely
> different stuff?

Yes, I was talking about the current Chrome implementation that has 'tcp'
and 'ssltcp' ICE candidates.

> You said Chrome implements that ("ssltcp"), is that right? where is
> that defined within the WebRTC spec?

At first I tried Hangouts with all UDP ports closed on firewall and I saw
from Wireshark how the Pseudo SSL connection was established.
Then I had to look into source code to understand implementation.

> NOTE: WebRTC over TCP (I don't mean TURN) works fine in Chrome and it

> is easy to implement in server side. It consist in:

The problem is that this kind of connection is rejected by enterprise
firewalls (Watchguard, Sonicwall, etc) because they perform a full check on
SSL handshake.

That's why I was asking more details about TURN/TLS: I'd like to have a real
SSL connection that it is not dropped by firewalls, with lowest priority.

regards
Marcello

[Philipp Hancke]

2015-12-22 12:32 GMT+01:00 Iñaki Baz Castillo <i...@aliax.net>:

2015-12-22 12:29 GMT+01:00 'Philipp Hancke' via discuss-webrtc
<discuss...@googlegroups.com>:
>> I'm a bit afraid. Is this related to ICE+DTLS+SRTP/SCTP over TCP
>> (which already works in Chrome)? or is this another completely
>> different stuff?
>
>
> Similar. Roughly "over TCP preceded by something that looks like a TLS
> handshake".

And... why??

Because it fools some stupid middleboxes??

And how/when does Chrome decide to send that ugly/propietary stuff
instead of the standard STUN/DTLS/STRP/SCTP-over-TCP?

Does it mean that, in case the remote peer provides TCP candidates,
Chrome will send this privative stuff?

No, it will only do that for ssltcp candidates. 

--
Iñaki Baz Castillo
<i...@aliax.net>

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CALiegf%3DYBDr5mNkELg1zU3JRmiKa6rHK2mWN%2BzZwE6BgNwZRxg%40mail.gmail.com.

[Marcello Vezzelli]

Il 22/12/2015 12:32, Iñaki Baz Castillo ha scritto:

Similar. Roughly "over TCP preceded by something that looks like a TLS
handshake".

And... why??

The reason is that low-class firewalls allow this kind of pseudo SSL connection and don't care about what happens to it.

And how/when does Chrome decide to send that ugly/propietary stuff
instead of the standard STUN/DTLS/STRP/SCTP-over-TCP?

Actually, the handshake is hardcoded in WebRTC library: two static SSL messages, Client Hello and Server Hello. Chrome sends Client Hello, then waits for Server Hello. Once received, starts to send STUN then DTLS like it was an UDP candidate.
Since this is a TCP connection you don't have packet size like in UDP: that's why there is a 2-byte header before each packet.
This implementation is based on RFC 4571.
https://www.ietf.org/rfc/rfc4571.txt

Does it mean that, in case the remote peer provides TCP candidates,
Chrome will send this privative stuff?

From what I understand, 'tcp' and 'ssltcp' candidates are using the same implementation, except that 'ssltcp' has two fake SSL messages at the beginning.

[Iñaki Baz Castillo]

2015-12-22 12:38 GMT+01:00 Marcello Vezzelli <m...@3cx.com>:
> Il 22/12/2015 12:24, Iñaki Baz Castillo ha scritto:
>
>> I'm a bit afraid. Is this related to ICE+DTLS+SRTP/SCTP over TCP
>> (which already works in Chrome)? or is this another completely
>> different stuff?
>
>
> Yes, I was talking about the current Chrome implementation that has 'tcp'
> and 'ssltcp' ICE candidates.

Oh, so does it mean that Chrome can handle ICE candidates with
protocol "udp", "tcp" and "ssltcp"? And does Chrome also generate
"ssltcp" candidates and place them in the SDP offer?

According to the WebRTC spec, it is clear that RTCIceProtocol just
allows "udp" and "tcp":

enum RTCIceProtocol {
"udp",
"tcp"
};

so, why Google??

[Philipp Hancke]

Oh, so does it mean that Chrome can handle ICE candidates with
protocol "udp", "tcp" and "ssltcp"?

Yes.

 

And does Chrome also generate
"ssltcp" candidates and place them in the SDP offer?

No.

 

According to the WebRTC spec, it is clear that RTCIceProtocol just
allows "udp" and "tcp":

enum RTCIceProtocol {
    "udp",
    "tcp"
};

I don't see normative language preventing other types in the spec. If there was, this would probably conflict with the definition of transport-extension in RFC 5245.

so, why Google??

Why does an additional candidate type that is accepted concern you?

It's been around at least since 2007 FWIW.

[Marcello Vezzelli]

Il 22/12/2015 13:57, 'Philipp Hancke' via discuss-webrtc ha scritto:

I don't see normative language preventing other types in the spec. If there was, this would probably conflict with the definition of transport-extension in RFC 5245.

so, why Google??

Why does an additional candidate type that is accepted concern you?

Together with 'udp', 'tcp' and 'ssltcp', I would really, really like to see also 'tlstcp' candidate with a real TLS connection! This would solve all the problems.
There is no need to enforce SSL certificates for this TLS connection since encryption is guaranteed from DTLS level.
Chrome should generate only 'udp' and 'tcp' ICE candidates, but should be able to connect to 'ssltcp' (already does) and 'tlstcp'.

Do you think it's a possibility? Should I open a feature request for this?

It's been around at least since 2007 FWIW.

If I understood well, pseudo TLS code appeared in WebRTC around beginning of 2014.

[Iñaki Baz Castillo]

2015-12-22 13:57 GMT+01:00 'Philipp Hancke' via discuss-webrtc
<discuss...@googlegroups.com>:

>> According to the WebRTC spec, it is clear that RTCIceProtocol just
>> allows "udp" and "tcp":
>>
>> enum RTCIceProtocol {
>> "udp",
>> "tcp"
>> };
>
>
> I don't see normative language preventing other types in the spec. If there
> was, this would probably conflict with the definition of transport-extension
> in RFC 5245.

You are right. Also, according to RFC 5245 (ICE), candidate
"transport" is defined as:

transport = "UDP" / transport-extension

so any other token is valid.

>> so, why Google??
>
> Why does an additional candidate type that is accepted concern you?

As long as it does not break a spec compliant implementation I'm fine.

Thanks.

[Iñaki Baz Castillo]

2015-12-22 16:01 GMT+01:00 Marcello Vezzelli <m...@3cx.com>:

Together with 'udp', 'tcp' and 'ssltcp', I would really, really like to see also 'tlstcp' candidate with a real TLS connection! This would solve all the problems.

WebRTC over TCP (this is: ICE/DTLS/SRTP/SCTP-over-TCP) cannot be started with a TLS connection. Well, that would require an entirely different protocol.

If you want something that solves all the problems, use TURNS connection on port 443 which involves a real TLS connection.