[jitsi-users] provisionin and HTTPS host name


#1

Hello,

I'm experimenting with jisti provisioning with bonjour using the
instructions at
http://jitsi.org/index.php/Documentation/Provisioning

There seems to be a design issue there wrt HTTPS.

The host name of the provisioning server is never given (other
than the ".local" one), so jitsi can't verify the server
certificate.

Also, I tried to set the provisioning parameters via
provisioning parameters like:

net.java.sip.communicator.plugin.provisioning=${null}
net.java.sip.communicator.plugin.provisioning.METHOD=Manual
net.java.sip.communicator.plugin.provisioning.URL=https\://fqdn.example.com/jitsi?u\=${username}&p\=${password}&o\=${osname}

But that didn't seem to work.

Is there any way around that?

Thanks,
Stephane


#2

2011-09-29 07:25:42 +0200, Emil Ivov:
[...]

> The host name of the provisioning server is never given (other
> than the ".local" one), so jitsi can't verify the server
> certificate.

Hmm interesting. We'd have to think about this. In the mean
time, you may want to try with DHCP discovery.

Hi Emil, yes,

though I suspect I'll be more likely to run in firewall issues
with that 6767 UDP port... The advantage though is that I might
be able to use DHCP relay on our router to be able to serve the
provisioning parameters on more than one subnet. I'll give it a
try.

> Also, I tried to set the provisioning parameters via
> provisioning parameters like:
>
> net.java.sip.communicator.plugin.provisioning=${null}
> net.java.sip.communicator.plugin.provisioning.METHOD=Manual
> net.java.sip.communicator.plugin.provisioning.URL=https\://fqdn.example.com/jitsi?u\=${username}&p\=${password}&o\=${osname}
>
> But that didn't seem to work.

Mmm ... How exactly did you try to set those?

[...]

That was in the output generated by the provisioning CGI script.

Every other setting was applied, not that one. The
provisioning.URL was set based on the bonjour settings though.
https://aa.bb.cc.dd/jitsi?uuid=${...

But I tried with manual provisioning and it didn't work either.

When I tried manual provisioning at first, I had hoped I could
tell the users to enter a short URL like: https://fqdn/jitsi, and
that the first pass of the provisioning script would change that
to https://fqdn/jitsi?u=${username},p=... but that didn't work.

By the way, I tried:

https://fqdn/jitsi?u=${username}

that is ${username} was provided and not ${password}, and the
user wasn't asked for a username or password, and ${username}
was expanded to the empty string.

Also, the "remember my password" on that provisioning server
login banner doesn't seem to work (I'm asked for both the
username and password each time).

Thanks,
Stephane


#3

Hi Stephane,

Le 28/09/11 18:51, Stephane Chazelas a �crit :

Hello,

I'm experimenting with jisti provisioning with bonjour using the
instructions at
http://jitsi.org/index.php/Documentation/Provisioning

There seems to be a design issue there wrt HTTPS.

The host name of the provisioning server is never given (other
than the ".local" one), so jitsi can't verify the server
certificate.

Yes you are right, it is not possible to advertise fqdn in bonjour.

But you can try the following way to ensure certificate verification:
- Advertise HTTP service in avahi (_http._tcp) instead of HTTPS.
- Use HTTP redirection of the link to FQDN with HTTPS, htaccess syntax:
Redirect /provisioning.php https://www.example.org/myprovisioning.php
- Use $_GET instead of $_POST to get the variable (after a redirection only HEAD or GET are allowed according to RFC2616 section 10.3).

Be careful for the htaccess's Redirect line to choose a different provisioning.php name for the two (provisioning.php and myprovisioning.php) otherwise you will go to an undless redirect loop.

Regards,

···

--
Seb

Also, I tried to set the provisioning parameters via
provisioning parameters like:

net.java.sip.communicator.plugin.provisioning=${null}
net.java.sip.communicator.plugin.provisioning.METHOD=Manual
net.java.sip.communicator.plugin.provisioning.URL=https\://fqdn.example.com/jitsi?u\=${username}&p\=${password}&o\=${osname}

But that didn't seem to work.

Is there any way around that?

Thanks,
Stephane


#4

2011-09-29 10:33:49 +0100, Stephane Chazelas:

2011-09-29 07:25:42 +0200, Emil Ivov:
[...]
> > The host name of the provisioning server is never given (other
> > than the ".local" one), so jitsi can't verify the server
> > certificate.
>
> Hmm interesting. We'd have to think about this. In the mean
> time, you may want to try with DHCP discovery.

Hi Emil, yes,

though I suspect I'll be more likely to run in firewall issues
with that 6767 UDP port... The advantage though is that I might
be able to use DHCP relay on our router to be able to serve the
provisioning parameters on more than one subnet. I'll give it a
try.

[...]

I tried to use dnsmasq for that, but it fails because the
DHCPINFORM generated by jitsi (debian x86, latest nightly build)
has 0.0.0.0 as the client IP address:

Bootstrap Protocol
    Message type: Boot Request (1)
    Hardware type: Ethernet
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x3148bf1f
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
        0... .... .... .... = Broadcast flag: Unicast
        .000 0000 0000 0000 = Reserved flags: 0x0000
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: 0.0.0.0 (0.0.0.0)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (t=53,l=1) DHCP Message Type = DHCP Inform
        Option: (53) DHCP Message Type
        Length: 1
        Value: 08
    Option: (t=55,l=1) Parameter Request List
        Option: (55) Parameter Request List
        Length: 1
        Value: e0
        224 = Private
    End Option
    Padding

RFC 2131 says
  Servers receiving a DHCPINFORM message construct a DHCPACK
  message with any local configuration parameters appropriate
  for the client without: allocating a new address, checking for
  an existing binding, filling in 'yiaddr' or including lease
  time parameters. The servers SHOULD unicast the DHCPACK reply
  to the address given in the 'ciaddr' field of the DHCPINFORM
  message.
[...]
  4.4.3 Initialization with an externally assigned network address

  The client sends a DHCPINFORM message. The client may request
  specific configuration parameters by including the 'parameter
  request list' option. The client generates and records a
  random transaction identifier and inserts that identifier into
  the 'xid' field. The client places its own network address in
  the 'ciaddr' field. The client SHOULD NOT request lease time
  parameters.

So, it would seem that dnsmasq behavior is correct and jitsi's
incorrect.

dnsmasq is handy here as it is small and all the configuration
can be specified on the command line:

dnsmasq --dhcp-alternate-port=6767 -p 0 \
        --dhcp-option='224,https://...' \
  --dhcp-authoritative \
  --no-ping \
  --dhcp-leasefile=/dev/null \
  --dhcp-range=1.1.1.1,1.1.1.1,0.0.0.0

···

--
Stephane


#5

2011-09-29 10:33:49 +0100, Stephane Chazelas:
[...]

> > Also, I tried to set the provisioning parameters via
> > provisioning parameters like:
> >
> > net.java.sip.communicator.plugin.provisioning=${null}
> > net.java.sip.communicator.plugin.provisioning.METHOD=Manual
> > net.java.sip.communicator.plugin.provisioning.URL=https\://fqdn.example.com/jitsi?u\=${username}&p\=${password}&o\=${osname}
> >
> > But that didn't seem to work.
>
> Mmm ... How exactly did you try to set those?
[...]

That was in the output generated by the provisioning CGI script.

[...]

Also, the "remember my password" on that provisioning server
login banner doesn't seem to work (I'm asked for both the
username and password each time).

That part was because of the
net.java.sip.communicator.plugin.provisioning=${null}

I suspect that my settings are taken into account but then
overriden after that.

···

--
Stephane


#6

2011-09-29 10:33:49 +0100, Stephane Chazelas:

2011-09-29 07:25:42 +0200, Emil Ivov:
[...]
> > The host name of the provisioning server is never given (other
> > than the ".local" one), so jitsi can't verify the server
> > certificate.
>
> Hmm interesting. We'd have to think about this. In the mean
> time, you may want to try with DHCP discovery.

[...]

though I suspect I'll be more likely to run in firewall issues
with that 6767 UDP port... The advantage though is that I might
be able to use DHCP relay on our router to be able to serve the
provisioning parameters on more than one subnet. I'll give it a
try.

[...]

That does work when using the ISC DHCP server. I even managed to
have relay in place by our netgear router.

Now, I can provision all the settings. The only thing I'm
stumbling on is how to make all clients trust the StartSSL CA
automatically in a OS-independant fashion for LDAPS to work.

···

--
Stephane


#7

2011-10-04 11:38:35 +0200, Sebastien Vincent:
[...]

Yes you are right, it is not possible to advertise fqdn in bonjour.

But you can try the following way to ensure certificate verification:
- Advertise HTTP service in avahi (_http._tcp) instead of HTTPS.
- Use HTTP redirection of the link to FQDN with HTTPS, htaccess syntax:
Redirect /provisioning.php https://www.example.org/myprovisioning.php
- Use $_GET instead of $_POST to get the variable (after a
redirection only HEAD or GET are allowed according to RFC2616
section 10.3).

Be careful for the htaccess's Redirect line to choose a different
provisioning.php name for the two (provisioning.php and
myprovisioning.php) otherwise you will go to an undless redirect
loop.

[...]

Bonjour Vincent,

though that is an interesting idea, that doesn't really work
from a security stand point as jitsi will record the http://...
URI as the provisioning.URI, and http provides no server
authentication, so you may end up sending your username and
password to the wrong web server. Also, with GET, the CGI
parameter will appear in clear in the log files.

Anyway, I'm using DHCP happily now with the script I provided
earlier.

···

--
Stephane


#8

2011-09-29 15:09:29 +0100, Stephane Chazelas:
[...]

I tried to use dnsmasq for that, but it fails because the
DHCPINFORM generated by jitsi (debian x86, latest nightly build)
has 0.0.0.0 as the client IP address:

[...]

Actually, as the DHCP server here is just meant to answer fixed
DHCPINFORM requests, it's as easy to write a simple script that
does the job, rather than deploying a complete DHCP server. Here
is an example:

-------------------------->8 CUT-HERE 8<--------------------------
#! /usr/bin/perl -w
use Socket;
my $port = 6767;
my $opt = 224;
my $value = 'https://prov.example.com/jitsi?u=${username}&p=${password}&ip=${ipaddr}&hw=${hwaddr}&osname=${o}&b=${build}&uuid=${uuid}';
my $magic = 0x63825363;

my $proto = getprotobyname('udp');
socket(DHCP, PF_INET, SOCK_DGRAM, $proto) or die "socket: $!";
$sin = sockaddr_in($port, INADDR_ANY);
bind(DHCP, $sin) or die "bind: $!";

while (1) {
  my $pkt;
  my $from;

  unless ($from = recv(DHCP, $pkt, 512, 0)) {
    warn "recv: $!";
    next;
  }
  my ($t1, $xid, $t2, $t3, $opt_req) = unpack("NNx228NNxC", $pkt);
  if ($t1 == 0x01010600 && $t2 == $magic && $t3 == 0x35010837 && $opt_req == $opt) {
    $pkt = pack("NNx228NCCCCC/aC", 0x02010600, $xid, $magic, 53, 1, 5, $opt, $value, 0xff);
    send(DHCP, $pkt, 0, $from) or warn "send: $!";
  } else {
    warn "t1=$t1, t2=$t2, t3=$t3, opt_req=$opt_req\n";
  }
}
-------------------------->8 CUT-HERE 8<--------------------------

HTH,
Stephane


#9

Hey Stephane,

На 29.09.11 16:09, Stephane Chazelas написа:

2011-09-29 10:33:49 +0100, Stephane Chazelas:

2011-09-29 07:25:42 +0200, Emil Ivov:
[...]

The host name of the provisioning server is never given (other
than the ".local" one), so jitsi can't verify the server
certificate.

Hmm interesting. We'd have to think about this. In the mean
time, you may want to try with DHCP discovery.

Hi Emil, yes,

though I suspect I'll be more likely to run in firewall issues
with that 6767 UDP port... The advantage though is that I might
be able to use DHCP relay on our router to be able to serve the
provisioning parameters on more than one subnet. I'll give it a
try.

[...]

I tried to use dnsmasq for that, but it fails because the
DHCPINFORM generated by jitsi (debian x86, latest nightly build)
has 0.0.0.0 as the client IP address:

Bootstrap Protocol
    Message type: Boot Request (1)
    Hardware type: Ethernet
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x3148bf1f
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
        0... .... .... .... = Broadcast flag: Unicast
        .000 0000 0000 0000 = Reserved flags: 0x0000
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: 0.0.0.0 (0.0.0.0)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (t=53,l=1) DHCP Message Type = DHCP Inform
        Option: (53) DHCP Message Type
        Length: 1
        Value: 08
    Option: (t=55,l=1) Parameter Request List
        Option: (55) Parameter Request List
        Length: 1
        Value: e0
        224 = Private
    End Option
    Padding

RFC 2131 says
  Servers receiving a DHCPINFORM message construct a DHCPACK
  message with any local configuration parameters appropriate
  for the client without: allocating a new address, checking for
  an existing binding, filling in 'yiaddr' or including lease
  time parameters. The servers SHOULD unicast the DHCPACK reply
  to the address given in the 'ciaddr' field of the DHCPINFORM
  message.
[...]
  4.4.3 Initialization with an externally assigned network address

  The client sends a DHCPINFORM message. The client may request
  specific configuration parameters by including the 'parameter
  request list' option. The client generates and records a
  random transaction identifier and inserts that identifier into
  the 'xid' field. The client places its own network address in
  the 'ciaddr' field. The client SHOULD NOT request lease time
  parameters.

So, it would seem that dnsmasq behavior is correct and jitsi's
incorrect.

Could you be a bit more specific? Which normative statement do you think
Jitsi is violating in a way that would force dnsmasq to drop the request?

Emil

···

dnsmasq is handy here as it is small and all the configuration
can be specified on the command line:

dnsmasq --dhcp-alternate-port=6767 -p 0 \
        --dhcp-option='224,https://...' \
  --dhcp-authoritative \
  --no-ping \
  --dhcp-leasefile=/dev/null \
  --dhcp-range=1.1.1.1,1.1.1.1,0.0.0.0

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#10

На 29.09.11 17:31, Stephane Chazelas написа:

2011-09-29 10:33:49 +0100, Stephane Chazelas:
[...]

Also, I tried to set the provisioning parameters via
provisioning parameters like:

net.java.sip.communicator.plugin.provisioning=\{null\} net\.java\.sip\.communicator\.plugin\.provisioning\.METHOD=Manual net\.java\.sip\.communicator\.plugin\.provisioning\.URL=https\\://fqdn\.example\.com/jitsi?u\\={username}&p\=\{password\}&amp;o\\={osname}

But that didn't seem to work.

Mmm ... How exactly did you try to set those?

[...]

That was in the output generated by the provisioning CGI script.

[...]

Also, the "remember my password" on that provisioning server
login banner doesn't seem to work (I'm asked for both the
username and password each time).

That part was because of the
net.java.sip.communicator.plugin.provisioning=${null}

I suspect that my settings are taken into account but then
overriden after that.

Confirmed.

Emil


#11

Hi Stephane,

Just for the record, after reading a little bit more on JmDNS source code (library that we use to handle Bonjour), I have discovered that we could simply use the full path of the address for the "path" txt-record and not only the relative ones (in which JmDNS will concatenate the machine.local, the port and the path txt-record value).

In other words, change in your /etc/avahi/services/provisioning.service:

<txt-record>path=/provisioning.php</txt-record>

to

<txt-record>path=https://www.example.org/provisioning.php</txt-record>

I have updated documentation on http://jitsi.org/index.php/Documentation/Provisioning.

With that Jitsi will directly use the full URL _with_ the FQDN and so if HTTPS is used it will verify the certificate.

Regards,

···

--
Seb

Le 04/10/11 13:44, Stephane Chazelas a �crit :

2011-10-04 11:38:35 +0200, Sebastien Vincent:
[...]

Yes you are right, it is not possible to advertise fqdn in bonjour.

But you can try the following way to ensure certificate verification:
- Advertise HTTP service in avahi (_http._tcp) instead of HTTPS.
- Use HTTP redirection of the link to FQDN with HTTPS, htaccess syntax:
Redirect /provisioning.php https://www.example.org/myprovisioning.php
- Use $_GET instead of $_POST to get the variable (after a
redirection only HEAD or GET are allowed according to RFC2616
section 10.3).

Be careful for the htaccess's Redirect line to choose a different
provisioning.php name for the two (provisioning.php and
myprovisioning.php) otherwise you will go to an undless redirect
loop.

[...]

Bonjour Vincent,

though that is an interesting idea, that doesn't really work
from a security stand point as jitsi will record the http://...
URI as the provisioning.URI, and http provides no server
authentication, so you may end up sending your username and
password to the wrong web server. Also, with GET, the CGI
parameter will appear in clear in the log files.

Anyway, I'm using DHCP happily now with the script I provided
earlier.


#12

2011-10-04 12:53:46 +0200, Emil Ivov:
[...]

> RFC 2131 says
> Servers receiving a DHCPINFORM message construct a DHCPACK
> message with any local configuration parameters appropriate
> for the client without: allocating a new address, checking for
> an existing binding, filling in 'yiaddr' or including lease
> time parameters. The servers SHOULD unicast the DHCPACK reply
> to the address given in the 'ciaddr' field of the DHCPINFORM
> message.
> [...]
> 4.4.3 Initialization with an externally assigned network address
>
> The client sends a DHCPINFORM message. The client may request
> specific configuration parameters by including the 'parameter
> request list' option. The client generates and records a
> random transaction identifier and inserts that identifier into
> the 'xid' field. The client places its own network address in
> the 'ciaddr' field. The client SHOULD NOT request lease time
> parameters.
>
>
> So, it would seem that dnsmasq behavior is correct and jitsi's
> incorrect.

Could you be a bit more specific? Which normative statement do you think
Jitsi is violating in a way that would force dnsmasq to drop the request?

[...]

Well, those above. The ciaddr in jisti's DHCPINFORM is 0.0.0.0.

"The client places its own network address in the 'ciaddr'
field".

"The servers SHOULD unicast the DHCPACK reply to the address
given in the 'ciaddr' field of the DHCPINFORM message.",

···

--
Stephane


#13

Hi Stephane,

It should be fixed in SVN revision 9004 and build 3706 (currently baking).

Regards,

···

--
Seb

Le 04/10/11 13:26, Stephane Chazelas a �crit :

2011-10-04 12:53:46 +0200, Emil Ivov:
[...]

RFC 2131 says
   Servers receiving a DHCPINFORM message construct a DHCPACK
   message with any local configuration parameters appropriate
   for the client without: allocating a new address, checking for
   an existing binding, filling in 'yiaddr' or including lease
   time parameters. The servers SHOULD unicast the DHCPACK reply
   to the address given in the 'ciaddr' field of the DHCPINFORM
   message.
[...]
   4.4.3 Initialization with an externally assigned network address

   The client sends a DHCPINFORM message. The client may request
   specific configuration parameters by including the 'parameter
   request list' option. The client generates and records a
   random transaction identifier and inserts that identifier into
   the 'xid' field. The client places its own network address in
   the 'ciaddr' field. The client SHOULD NOT request lease time
   parameters.

So, it would seem that dnsmasq behavior is correct and jitsi's
incorrect.

Could you be a bit more specific? Which normative statement do you think
Jitsi is violating in a way that would force dnsmasq to drop the request?

[...]

Well, those above. The ciaddr in jisti's DHCPINFORM is 0.0.0.0.

"The client places its own network address in the 'ciaddr'
field".

"The servers SHOULD unicast the DHCPACK reply to the address
given in the 'ciaddr' field of the DHCPINFORM message.",