[jitsi-users] Jitsi and SOCKSV proxy


#1

As reported earlier we now have Jitsi working with Asterisk-11 via
TSL/SRTP through our gateway firewall. In consequence I have spent
the last week or so investigating the security issues relating to
actually deploying that capability. And they are legion.

Consequently, I am investigating the possibility of having the initial
SIP requests tunneled into our internal LAN via SSH using SOCKSV. We
use this extensively for things like http and imap.

I have discovered that, on OSX-10.9 at least, if I set up a SOCKSV
proxy over SSH for my internal http connection then I cannot use
Jitsi. This seems to be because Jitsi is requesting registrations from
the IP of the LAN end of my tunnel. Since is not the IP address of my
external node the call obviously fails.

If I simply take down the tunnel then Jitsi works. I did not
configure Jitsi to do this. Nonetheless it is empirically determined
that this indeed happens. Therefore it seems likely that this is the
default behaviour.

Since this is part of what I want to accomplish anyway can someone
explain to me what is happening? Also, in the case of SOCKSV proxy
over an SSH tunnel how does one get Jitsi to register the actual
external node IP address with the SIP proxy?

If we can get this to work then it will greatly simplify our deployment.

···

--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3


#2

Hi James,

This is a known issue. SOCKS 5 is supported, but DNS name resolving
through the SOCKS 5 proxy isn't. Jitsi will do local resolving first,
then go through the proxy to establish the connection.

AFAICT at this moment, my impression is that we need to solve this per
protocol implementation and the protocol client library needs to support
this, so that we can ask the library to defer resolving the hostname to
an address.

To clarify, resolving DNS names through the SOCKS 5 proxy is currently
not supported and should be considered a new feature. (i.e. not a bug)

Regards,
Danny

···

On 30-03-15 19:05, James B. Byrne wrote:

As reported earlier we now have Jitsi working with Asterisk-11 via
TSL/SRTP through our gateway firewall. In consequence I have spent
the last week or so investigating the security issues relating to
actually deploying that capability. And they are legion.

Consequently, I am investigating the possibility of having the initial
SIP requests tunneled into our internal LAN via SSH using SOCKSV. We
use this extensively for things like http and imap.

I have discovered that, on OSX-10.9 at least, if I set up a SOCKSV
proxy over SSH for my internal http connection then I cannot use
Jitsi. This seems to be because Jitsi is requesting registrations from
the IP of the LAN end of my tunnel. Since is not the IP address of my
external node the call obviously fails.

If I simply take down the tunnel then Jitsi works. I did not
configure Jitsi to do this. Nonetheless it is empirically determined
that this indeed happens. Therefore it seems likely that this is the
default behaviour.

Since this is part of what I want to accomplish anyway can someone
explain to me what is happening? Also, in the case of SOCKSV proxy
over an SSH tunnel how does one get Jitsi to register the actual
external node IP address with the SIP proxy?

If we can get this to work then it will greatly simplify our deployment.


#3

I only have a rough understanding how an HTTP proxy works and there it is obvious how DNS lookups can be deferred to the proxy. But how should an SRV lookup be performed on/by a proxy?

Freundliche Grüsse,
Ingo Bauersachs

-- Sent from my tablet

···

On 31.03.2015, at 23:34, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#4

http://k0rx.com/blog/2013/06/ssrtext.html

Apparently, DNS queries are done over UDP by default, so requests are not
"socksified".

Allegedly, you need to do DNS resolving over TCP, and then those requests
are handled by SOCKS5 in the usual way.

YMMV, that's only after a quick reading of the above text.

FC
During times of Universal Deceit, telling the truth becomes a revolutionary
act
Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto
Revolucionario
- George Orwell

···

On Tue, Mar 31, 2015 at 7:18 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

I only have a rough understanding how an HTTP proxy works and there it is
obvious how DNS lookups can be deferred to the proxy. But how should an SRV
lookup be performed on/by a proxy?


#5

Ingo, you might want to peek into this Open Source BUT BSD licensed code...

http://analogbit.com/software/tcp-over-dns/

FC

···

On Tue, Mar 31, 2015 at 7:18 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

I only have a rough understanding how an HTTP proxy works and there it is
obvious how DNS lookups can be deferred to the proxy. But how should an SRV
lookup be performed on/by a proxy?


#6

Here, Ingo, all the RFCs about DNS and the UDP vs TCP issue. As the
Americans say "knock yourself out". :wink:

https://www.nanog.org/sites/default/files/nanog63-dnstrack-kristoff-dnstcp.pdf

FC
PS: I think this discussion is for the dev list more than the users list :slight_smile:

···

On Tue, Mar 31, 2015 at 7:18 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

I only have a rough understanding how an HTTP proxy works and there it is
obvious how DNS lookups can be deferred to the proxy


#7

I only have a rough understanding how an HTTP proxy works and there it
is obvious how DNS lookups can be deferred to the proxy

Here, Ingo, all the RFCs about DNS and the UDP vs TCP issue. As the Americans
say "knock yourself out". :wink:

https://www.nanog.org/sites/default/files/nanog63-dnstrack-kristoff-
dnstcp.pdf

Thanks for the links, but apparently you misunderstood my question. I know that an application can tell a SOCKS5 proxy to connect to the actual server by specifying an IPv4 address, a domain name or an IPv6 address along with a port number. But AFAIK there's no option to request a lookup of the destination host, protocol and port (which is what an SRV record specifies). And without such an option automatic detection of the SIP or XMPP server is impossible, specifically the request from some user to work with domain name ACLs on the proxy side.

It would of course be possible to connect to servers and defer lookup to the proxy if the server name is known in advance and manually configured. But this would make ACLs pointless to a certain extent as e.g. talk.google.com hosts the GMail XMPP server as well as the those for Google Apps domains.

Simply tunneling DNS lookups over the proxy is already available in Jitsi, check the box named "Also tunnel DNS" in the global proxy options.

FC

PS: I think this discussion is for the dev list more than the users list :slight_smile:

Ingo


#8

Hi,

I only have a rough understanding how an HTTP proxy works and there it
is obvious how DNS lookups can be deferred to the proxy

Here, Ingo, all the RFCs about DNS and the UDP vs TCP issue. As the Americans
say "knock yourself out". :wink:

https://www.nanog.org/sites/default/files/nanog63-dnstrack-kristoff-
dnstcp.pdf

Thanks for the links, but apparently you misunderstood my question. I know that an application can tell a SOCKS5 proxy to connect to the actual server by specifying an IPv4 address, a domain name or an IPv6 address along with a port number. But AFAIK there's no option to request a lookup of the destination host, protocol and port (which is what an SRV record specifies). And without such an option automatic detection of the SIP or XMPP server is impossible, specifically the request from some user to work with domain name ACLs on the proxy side.

I think you are right for this. I can't imagine how that would work:
getting an SRV record via the proxy. (Apart from querying to a DNS
server yourself.)

It would of course be possible to connect to servers and defer lookup to the proxy if the server name is known in advance and manually configured. But this would make ACLs pointless to a certain extent as e.g. talk.google.com hosts the GMail XMPP server as well as the those for Google Apps domains.

Simply tunneling DNS lookups over the proxy is already available in Jitsi, check the box named "Also tunnel DNS" in the global proxy options.

Huh ... so, is that how it works? We're talking about the bottom
checkbox for the global proxy settings, right? So you're supposed to
enter a DNS server and it will send those DNS requests via the
configured proxy to a DNS server of your own choosing, i.e. the one
whose address and port you entered in the input fields that appear when
you check the box.

I didn't get that, actually. I thought you needed to provide your own
local DNS server for the case where there is no other DNS server you can
reach, because your cut off by a proxy.

Danny

···

On 01-04-15 08:06, Ingo Bauersachs wrote:

FC

PS: I think this discussion is for the dev list more than the users list :slight_smile:

Ingo

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#9

Simply tunneling DNS lookups over the proxy is already available in Jitsi,
check the box named "Also tunnel DNS" in the global proxy options.

Huh ... so, is that how it works? We're talking about the bottom
checkbox for the global proxy settings, right? So you're supposed to
enter a DNS server and it will send those DNS requests via the
configured proxy to a DNS server of your own choosing, i.e. the one
whose address and port you entered in the input fields that appear when
you check the box.

I didn't get that, actually. I thought you needed to provide your own
local DNS server for the case where there is no other DNS server you can
reach, because your cut off by a proxy.

Hm, no, actually you're right, there's no real proxying. The requests would simply be sent to the address provided when the checkbox is selected.

Danny

Ingo

Ingo