[jitsi-users] guidance on reporting issues


#1

Hello

Some issues I would like to make you aware of, but not ready to be
filed as tickets yet:

(list numbers correspond to attachment numbers)

1. Visiting http://jitsi.org/index.php/Register/Register with Chrome
results in a "insecure content" warning, which will probably scare
users. Firefox is fine.

2. Symantec Endpoint Security (SEP)'s Network Threat Protection module
throws up a warning when Jitsi attempts to communicate with the
outside world. Renaming the binary from run.exe to jitsi.exe (or
something similar) would help users understand what's going on.

3. Jitsi crashes during voice calls over XMPP and leaves a zombie
window that needs to be killed with Windows Task Manager before the
application can be restarted. Memory consumption is impressive in such
situations (here showing 330MB). How can I troubleshoot this? Can I
increase log verbosity and send you the logs with a ticket when it
next crashes?

4. Jitsi can not connect to jit.si over XMPP behind our corporate
firewall. Can Skype-style firewall circumvention techniques be
implemented, or is this not possible due to XMPP's usual network
architecture or implementation?

Thanks

Alex


#2

Hey Alex,

Hello

Some issues I would like to make you aware of, but not ready to be
filed as tickets yet:

(list numbers correspond to attachment numbers)

1. Visiting http://jitsi.org/index.php/Register/Register with Chrome
results in a "insecure content" warning, which will probably scare
users. Firefox is fine.

This will probably disappear when we move jitsi.org to https. We'll have
to wait and see. You can open a ticket for the https switch on jitsi.org
and we'll close at soon as we are ready.

2. Symantec Endpoint Security (SEP)'s Network Threat Protection module
throws up a warning when Jitsi attempts to communicate with the
outside world. Renaming the binary from run.exe to jitsi.exe (or
something similar) would help users understand what's going on.

This has been on our todo list for a while. We just haven't got around
to it yet. Could you please open a ticket?

3. Jitsi crashes during voice calls over XMPP and leaves a zombie
window that needs to be killed with Windows Task Manager before the
application can be restarted. Memory consumption is impressive in such
situations (here showing 330MB). How can I troubleshoot this? Can I
increase log verbosity and send you the logs with a ticket when it
next crashes?

Let's first see the logs as they are. Note that crashes are often
related to hardware specifics in which case we probably won't be able to
do much at this point.

(Also, for the record, this is unlikely to be an XMPP specific issues).

4. Jitsi can not connect to jit.si over XMPP behind our corporate
firewall. Can Skype-style firewall circumvention techniques be
implemented, or is this not possible due to XMPP's usual network
architecture or implementation?

First we'd have to know exactly why it doesn't connect. Are you using a
proxy? Have you configured it in Jitsi? We already do a number of things
in order to be NAT & Firewall friendly so depending on the exact issue
we here we may also through in something more. For example, if this is a
simple matter of a port number, we may consider adding 443 to jit.si.

Cheers,
Emil

···

On 18.05.12 16:53, ix4svs@gmail.com wrote:

Thanks

Alex


#3

Alex,

please let me know if you can get through your corporate firewall by using
an account with jabber80.com and setting the client port to 80 for this
account ?

Regards, Earl

···

On 05/21/2012 12:27, Emil Ivov wrote:

Hey Alex,

On 18.05.12 16:53, ix4svs@gmail.com wrote:

Hello

Some issues I would like to make you aware of, but not ready to be
filed as tickets yet:

(list numbers correspond to attachment numbers)

1. Visiting http://jitsi.org/index.php/Register/Register with Chrome
results in a "insecure content" warning, which will probably scare
users. Firefox is fine.

This will probably disappear when we move jitsi.org to https. We'll have
to wait and see. You can open a ticket for the https switch on jitsi.org
and we'll close at soon as we are ready.

2. Symantec Endpoint Security (SEP)'s Network Threat Protection module
throws up a warning when Jitsi attempts to communicate with the
outside world. Renaming the binary from run.exe to jitsi.exe (or
something similar) would help users understand what's going on.

This has been on our todo list for a while. We just haven't got around
to it yet. Could you please open a ticket?

3. Jitsi crashes during voice calls over XMPP and leaves a zombie
window that needs to be killed with Windows Task Manager before the
application can be restarted. Memory consumption is impressive in such
situations (here showing 330MB). How can I troubleshoot this? Can I
increase log verbosity and send you the logs with a ticket when it
next crashes?

Let's first see the logs as they are. Note that crashes are often
related to hardware specifics in which case we probably won't be able to
do much at this point.

(Also, for the record, this is unlikely to be an XMPP specific issues).

4. Jitsi can not connect to jit.si over XMPP behind our corporate
firewall. Can Skype-style firewall circumvention techniques be
implemented, or is this not possible due to XMPP's usual network
architecture or implementation?

First we'd have to know exactly why it doesn't connect. Are you using a
proxy? Have you configured it in Jitsi? We already do a number of things
in order to be NAT& Firewall friendly so depending on the exact issue
we here we may also through in something more. For example, if this is a
simple matter of a port number, we may consider adding 443 to jit.si.

Cheers,
Emil

Thanks

Alex


#4

Alex,

please let me know if you can get through your corporate firewall by using
an account with jabber80.com and setting the client port to 80 for this
account ?

Regards, Earl

···

On 05/21/2012 12:27, Emil Ivov wrote:

Hey Alex,

On 18.05.12 16:53, ix4svs@gmail.com wrote:

Hello

Some issues I would like to make you aware of, but not ready to be
filed as tickets yet:

(list numbers correspond to attachment numbers)

1. Visiting http://jitsi.org/index.php/Register/Register with Chrome
results in a "insecure content" warning, which will probably scare
users. Firefox is fine.

This will probably disappear when we move jitsi.org to https. We'll have
to wait and see. You can open a ticket for the https switch on jitsi.org
and we'll close at soon as we are ready.

2. Symantec Endpoint Security (SEP)'s Network Threat Protection module
throws up a warning when Jitsi attempts to communicate with the
outside world. Renaming the binary from run.exe to jitsi.exe (or
something similar) would help users understand what's going on.

This has been on our todo list for a while. We just haven't got around
to it yet. Could you please open a ticket?

3. Jitsi crashes during voice calls over XMPP and leaves a zombie
window that needs to be killed with Windows Task Manager before the
application can be restarted. Memory consumption is impressive in such
situations (here showing 330MB). How can I troubleshoot this? Can I
increase log verbosity and send you the logs with a ticket when it
next crashes?

Let's first see the logs as they are. Note that crashes are often
related to hardware specifics in which case we probably won't be able to
do much at this point.

(Also, for the record, this is unlikely to be an XMPP specific issues).

4. Jitsi can not connect to jit.si over XMPP behind our corporate
firewall. Can Skype-style firewall circumvention techniques be
implemented, or is this not possible due to XMPP's usual network
architecture or implementation?

First we'd have to know exactly why it doesn't connect. Are you using a
proxy? Have you configured it in Jitsi? We already do a number of things
in order to be NAT& Firewall friendly so depending on the exact issue
we here we may also through in something more. For example, if this is a
simple matter of a port number, we may consider adding 443 to jit.si.

Cheers,
Emil

Thanks

Alex


#5

Hey all,

1. Visiting http://jitsi.org/index.php/Register/Register with Chrome
results in a "insecure content" warning, which will probably scare
users. Firefox is fine.

This will probably disappear when we move jitsi.org to https. We'll have
to wait and see. You can open a ticket for the https switch on jitsi.org
and we'll close at soon as we are ready.

So, we did move jitsi.org to https (it should now be impossible to get
anything from jitsi.org over anything else but https).

There's still an issue on that particular page though (i.e.
https://jit.si). It seems that the problem's caused by the way the
Openfire registration plugin uses Recaptcha. It accesses google via http
which makes Chrome unhappy.

The recaptcha site seems to support https (when accessed as google.com).
The secure URL is also mentioned in the lib src so we'll see if we can
patch the openfire plugin. We won't be able to do it before next week
though.

Cheers,
Emil

···

On 21.05.12 12:27, Emil Ivov wrote:

On 18.05.12 16:53, ix4svs@gmail.com wrote:


#6

<snip>

please let me know if you can get through your corporate firewall by using
an account with jabber80.com and setting the client port to 80 for this
account ?

http://www.jabber80.com/jabber80.php says: "Just configure your client to use
Server: jabber80.com
Port 80"

Sure enough, I "just" make this change (from
Server: jit.si
Port 5222
which are my current settings)

...and it "just" doesn't work.

So, do I have to throw away my @jit.si account and create a new
account with jabber80.com? If yes, how would I do that?

Alex

···

On 21 May 2012 13:58, Earl <Large.Files@gmx.net> wrote:


#7

Hey all,

···

On 21.05.12 19:11, Emil Ivov wrote:

Hey all,

On 21.05.12 12:27, Emil Ivov wrote:
So, we did move jitsi.org to https (it should now be impossible to get
anything from jitsi.org over anything else but https).

There's still an issue on that particular page though (i.e.
https://jit.si). It seems that the problem's caused by the way the
Openfire registration plugin uses Recaptcha. It accesses google via http
which makes Chrome unhappy.

The recaptcha site seems to support https (when accessed as google.com).
The secure URL is also mentioned in the lib src so we'll see if we can
patch the openfire plugin. We won't be able to do it before next week
though.

This is now working. http://jit.si would take you to an https-only page.

Cheers,
Emil


#8

You don't need to throw it away, but you do need to start from scratch
for any new account.

Go to the accounts configuration panel, choose "Add" and then select
XMPP. In there move the radio button to "Create a new account" then type
"jabber80.com" in the "Server" field. Then type your user name and
password (twice) and click "Add". You don't even need to change the port
number. Jitsi will discover it from the DNS.

Hope this helps,
Emil

···

On 24.05.12 21:47, ix4svs@gmail.com wrote:

On 21 May 2012 13:58, Earl <Large.Files@gmx.net> wrote:
<snip>

please let me know if you can get through your corporate firewall by using
an account with jabber80.com and setting the client port to 80 for this
account ?

http://www.jabber80.com/jabber80.php says: "Just configure your client to use
Server: jabber80.com
Port 80"

Sure enough, I "just" make this change (from
Server: jit.si
Port 5222
which are my current settings)

...and it "just" doesn't work.

So, do I have to throw away my @jit.si account and create a new
account with jabber80.com? If yes, how would I do that?


#9

Thanks for the instructions Emil

I created the new account on jabber80.com and will test it next time
I'm behind a restrictive corporate firewall (probably next Friday) and
report back with results.

In the meantime, on first connect to jabber80.com jitsi throws the
attached popup. A certificate prompt that looks like it's got nothing
to do with jabber80.com. I have zero information to validate this
against, so I will do what most users do - just click through and hope
it's ok.

Would it be possible to integrate certificates in jitsi or somehow
give users a validation mechanism?

Cheers

Alex

···

On 24 May 2012 21:11, Emil Ivov <emcho@jitsi.org> wrote:

On 24.05.12 21:47, ix4svs@gmail.com wrote:

On 21 May 2012 13:58, Earl <Large.Files@gmx.net> wrote:
<snip>

please let me know if you can get through your corporate firewall by using
an account with jabber80.com and setting the client port to 80 for this
account ?

http://www.jabber80.com/jabber80.php says: "Just configure your client to use
Server: jabber80.com
Port 80"

Sure enough, I "just" make this change (from
Server: jit.si
Port 5222
which are my current settings)

...and it "just" doesn't work.

So, do I have to throw away my @jit.si account and create a new
account with jabber80.com? If yes, how would I do that?

You don't need to throw it away, but you do need to start from scratch
for any new account.

Go to the accounts configuration panel, choose "Add" and then select
XMPP. In there move the radio button to "Create a new account" then type
"jabber80.com" in the "Server" field. Then type your user name and
password (twice) and click "Add". You don't even need to change the port
number. Jitsi will discover it from the DNS.


#10

Hey Alex,

<snip>

please let me know if you can get through your corporate firewall by using
an account with jabber80.com and setting the client port to 80 for this
account ?

http://www.jabber80.com/jabber80.php says: "Just configure your client to use
Server: jabber80.com
Port 80"

Sure enough, I "just" make this change (from
Server: jit.si
Port 5222
which are my current settings)

...and it "just" doesn't work.

So, do I have to throw away my @jit.si account and create a new
account with jabber80.com? If yes, how would I do that?

You don't need to throw it away, but you do need to start from scratch
for any new account.

Go to the accounts configuration panel, choose "Add" and then select
XMPP. In there move the radio button to "Create a new account" then type
"jabber80.com" in the "Server" field. Then type your user name and
password (twice) and click "Add". You don't even need to change the port
number. Jitsi will discover it from the DNS.

Thanks for the instructions Emil

I created the new account on jabber80.com and will test it next time
I'm behind a restrictive corporate firewall (probably next Friday) and
report back with results.

In the meantime, on first connect to jabber80.com jitsi throws the
attached popup. A certificate prompt that looks like it's got nothing
to do with jabber80.com. I have zero information to validate this
against, so I will do what most users do - just click through and hope
it's ok.

Would it be possible to integrate certificates in jitsi or somehow
give users a validation mechanism?

What you are seeing is exactly this mechanism. If a site has a trusted
certificate, you wouldn't be seeing the warning. The fact that you do
see it means that Jitsi can't validate it and it's up to you to decide
whether or not you would continue connecting.

Same as with the web.

Cheers,
Emil

···

On 24.05.12 22:54, ix4svs@gmail.com wrote:

On 24 May 2012 21:11, Emil Ivov <emcho@jitsi.org> wrote:

On 24.05.12 21:47, ix4svs@gmail.com wrote:

On 21 May 2012 13:58, Earl <Large.Files@gmx.net> wrote:


#11

Alex,

the first time you use jabber80.com, Jitsi will notice that they use a self-signed
certificate. If you trust jabber80.com and do not want this notice every time
that you use jitsi, then click on the view certificate. Once you are viewing the
certificate, there is a place to click on that says always trust this certificate.
If you click there, then you will never be disturbed again about this certificate
being self-signed.

Regards, Earl

···

On 05/24/2012 23:03, Emil Ivov wrote:

Hey Alex,

On 24.05.12 22:54, ix4svs@gmail.com wrote:

On 24 May 2012 21:11, Emil Ivov<emcho@jitsi.org> wrote:

On 24.05.12 21:47, ix4svs@gmail.com wrote:

On 21 May 2012 13:58, Earl<Large.Files@gmx.net> wrote:
<snip>

please let me know if you can get through your corporate firewall by using
an account with jabber80.com and setting the client port to 80 for this
account ?

http://www.jabber80.com/jabber80.php says: "Just configure your client to use
Server: jabber80.com
Port 80"

Sure enough, I "just" make this change (from
Server: jit.si
Port 5222
which are my current settings)

...and it "just" doesn't work.

So, do I have to throw away my @jit.si account and create a new
account with jabber80.com? If yes, how would I do that?

You don't need to throw it away, but you do need to start from scratch
for any new account.

Go to the accounts configuration panel, choose "Add" and then select
XMPP. In there move the radio button to "Create a new account" then type
"jabber80.com" in the "Server" field. Then type your user name and
password (twice) and click "Add". You don't even need to change the port
number. Jitsi will discover it from the DNS.

Thanks for the instructions Emil

I created the new account on jabber80.com and will test it next time
I'm behind a restrictive corporate firewall (probably next Friday) and
report back with results.

In the meantime, on first connect to jabber80.com jitsi throws the
attached popup. A certificate prompt that looks like it's got nothing
to do with jabber80.com. I have zero information to validate this
against, so I will do what most users do - just click through and hope
it's ok.

Would it be possible to integrate certificates in jitsi or somehow
give users a validation mechanism?

What you are seeing is exactly this mechanism. If a site has a trusted
certificate, you wouldn't be seeing the warning. The fact that you do
see it means that Jitsi can't validate it and it's up to you to decide
whether or not you would continue connecting.

Same as with the web.

Cheers,
Emil


#12

<snip>

If you trust jabber80.com

<snip>

Gents, I understand the user-level mechanics of accepting a certificate.

My question is, how can I possibly make an informed decision about
trusting this certificate?

Is there a valid chain of trust? No, since this is self-signed.
Is there a pointer to a webpage with an online fingerprint for the
supplied certificate? None that I can find.
Is there at least a mailing list archive where the jabber80.com people
indicate that this is the certificate they will be using? None that I
can find.

Training people to blindly trust self-signed certificates breaks the
SSL trust model and has the potential to compromise the
privacy/security of Jitsi users.

On the web, self-signed certificates with no mitigating validation
methods (like the ones mentioned above) are considered at least bad
style if not outright dangerous. Given Jitsi users are likely to be
privacy conscious and/or be dealing with tricky security situations, I
would like to stop people from blindly accepting self-signed
certificates. This only makes them easier MITM targets.

Cheers

Alex

···

On 25 May 2012 08:58, Earl <Large.Files@gmx.net> wrote:


#13

Frankly, I am sick to death of the self signed cert paranoia. I wish I could eliminate the warning in my browser altogether. It could be because I have a few hundred systems on the net either as firewalls, or other network appliances, all with self signed certs. But even if they are all the same cert, I can not globally accept them for more than one IP address, because someone decided for me that self signed certs are EVIL! Not if you only use them for trivial encryption, not identity management...

      Lee

···

On 05/28/2012 04:49 AM, ix4svs@gmail.com wrote:

On 25 May 2012 08:58, Earl<Large.Files@gmx.net> wrote:
<snip>

If you trust jabber80.com

<snip>

Gents, I understand the user-level mechanics of accepting a certificate.

My question is, how can I possibly make an informed decision about
trusting this certificate?

Is there a valid chain of trust? No, since this is self-signed.
Is there a pointer to a webpage with an online fingerprint for the
supplied certificate? None that I can find.
Is there at least a mailing list archive where the jabber80.com people
indicate that this is the certificate they will be using? None that I
can find.

Training people to blindly trust self-signed certificates breaks the
SSL trust model and has the potential to compromise the
privacy/security of Jitsi users.

On the web, self-signed certificates with no mitigating validation
methods (like the ones mentioned above) are considered at least bad
style if not outright dangerous. Given Jitsi users are likely to be
privacy conscious and/or be dealing with tricky security situations, I
would like to stop people from blindly accepting self-signed
certificates. This only makes them easier MITM targets.


#14

If you trust jabber80.com

<snip>

Gents, I understand the user-level mechanics of accepting a certificate.

My question is, how can I possibly make an informed decision about
trusting this certificate?

Is there a valid chain of trust? No, since this is self-signed.
Is there a pointer to a webpage with an online fingerprint for the
supplied certificate? None that I can find.
Is there at least a mailing list archive where the jabber80.com people
indicate that this is the certificate they will be using? None that I
can find.

That is really a concern for the people of Jabber80, not Jitsi. The dialog you've seen doesn't appear with a valid certificate, so it is up to the user to accept it or not.

Training people to blindly trust self-signed certificates breaks the
SSL trust model and has the potential to compromise the
privacy/security of Jitsi users.

Nobody should be trained to accept invalid certificates and we certainly don't intend to do that either. The big red X, the message shown there and the "Continue anyway" label hopefully indicate that relatively clearly. If you have suggestions for improvement however maybe we could make it more understandable.

On the web, self-signed certificates with no mitigating validation
methods (like the ones mentioned above) are considered at least bad
style if not outright dangerous. Given Jitsi users are likely to be
privacy conscious and/or be dealing with tricky security situations, I
would like to stop people from blindly accepting self-signed
certificates. This only makes them easier MITM targets.

From a security point of view, I'd love to remove that dialog altogether. However this would prevent users running Jitsi on an Intranet with self-signed certificates, it would prevent you from testing Jabber80, and it would prevent connecting to any Google Apps account. So this thing is a compromise.

Cheers

Alex

Regards,
Ingo


#15

Hey there,

<snip>

If you trust jabber80.com

<snip>

Gents, I understand the user-level mechanics of accepting a certificate.

My question is, how can I possibly make an informed decision about
trusting this certificate?

Is there a valid chain of trust? No, since this is self-signed.
Is there a pointer to a webpage with an online fingerprint for the
supplied certificate? None that I can find.
Is there at least a mailing list archive where the jabber80.com people
indicate that this is the certificate they will be using? None that I
can find.

You do realize that all these are issues that you need to discuss with
the jabber80 maintainers, right? I am not sure how you expect Jitsi to
help you with any of them.

If you'd really like to use the jabber80 service then please get in
touch with them and ask them to either get a valid cert or provide you
with their public fingerprint in a secure way.

(Incidentally, we'll try to see if we could provide a similar service by
also running jit.si on port 443.)

Training people to blindly trust self-signed certificates breaks the
SSL trust model and has the potential to compromise the
privacy/security of Jitsi users.

On the web, self-signed certificates with no mitigating validation
methods (like the ones mentioned above) are considered at least bad
style if not outright dangerous. Given Jitsi users are likely to be
privacy conscious and/or be dealing with tricky security situations, I
would like to stop people from blindly accepting self-signed
certificates. This only makes them easier MITM targets.

I am really not sure how you expect Jitsi to resolve these issues. Would
you rather we simply refused to connect to any site with a non-trusted
certificate?

All we can do is inform people of the situation and that's what we are
doing.

Emil

···

On 28.05.12 11:49, ix4svs@gmail.com wrote:

On 25 May 2012 08:58, Earl <Large.Files@gmx.net> wrote:


#16

Hey there,

<snip>

If you trust jabber80.com

<snip>

Gents, I understand the user-level mechanics of accepting a certificate.

My question is, how can I possibly make an informed decision about
trusting this certificate?

Is there a valid chain of trust? No, since this is self-signed.
Is there a pointer to a webpage with an online fingerprint for the
supplied certificate? None that I can find.
Is there at least a mailing list archive where the jabber80.com people
indicate that this is the certificate they will be using? None that I
can find.

You do realize that all these are issues that you need to discuss with
the jabber80 maintainers, right? I am not sure how you expect Jitsi to
help you with any of them.

I do realise these are issues of jabber80.com. My original question
was "how to use jitsi behind a firewall?" and it appears that the best
answer is "use jabber80.com".

Given that this gave rise to issues like the self-signed cert and
there is no contact information on the jabber80.com website, I was
hoping someone on this list would have a way forward. Please let me
know how to contact jabber80.com people and I'll be more than happy to
do so.

If you'd really like to use the jabber80 service then please get in
touch with them and ask them to either get a valid cert or provide you
with their public fingerprint in a secure way.

(Incidentally, we'll try to see if we could provide a similar service by
also running jit.si on port 443.)

That would probably be valuable for end users, especially if there is
an automatic fallback to port 443 implemented on the client if the
original connection times out.

Training people to blindly trust self-signed certificates breaks the
SSL trust model and has the potential to compromise the
privacy/security of Jitsi users.

On the web, self-signed certificates with no mitigating validation
methods (like the ones mentioned above) are considered at least bad
style if not outright dangerous. Given Jitsi users are likely to be
privacy conscious and/or be dealing with tricky security situations, I
would like to stop people from blindly accepting self-signed
certificates. This only makes them easier MITM targets.

I am really not sure how you expect Jitsi to resolve these issues. Would
you rather we simply refused to connect to any site with a non-trusted
certificate?

Absolutely not. This was an allergic reaction to the suggestion to
just click through a security warning. I would like to be shown how to
make an informed decision. On the UI if possible, on the mailing lists
if that's too hard.

All we can do is inform people of the situation and that's what we are
doing.

Emil

Thank you for working on this - Jitsi is a really promising piece of
software and I would love to see it be usable and secure by default
for as many use cases as possible.

It currently works very well for the most usual use cases (e.g.
Windows user with admin rights, no funny firewall).

I am supporting a broad base of non-technical users and therefore
share their frustrations when technology doesn't "just work". They
don't know the problem is with the corporate firewall. Or their ISP.
Or that they're not admins on their machines. Or that a service
provider breaks the protocol.

All they see is jitsi having issues where skype "just works". It's an
unfair comparison given resources etc, but as we all should know
people don't care about that. They further don't care about security
as much as they care about easy & hassle-free operation. Which is why
I challenge developers to come up with creative solutions to
well-known problems.

Your openness and dialogue on this is really appreciated.

Alex

···

On 28 May 2012 11:53, Emil Ivov <emcho@jitsi.org> wrote:

On 28.05.12 11:49, ix4svs@gmail.com wrote:

On 25 May 2012 08:58, Earl <Large.Files@gmx.net> wrote:


#17

Hey there,

<snip>

If you trust jabber80.com

<snip>

Gents, I understand the user-level mechanics of accepting a certificate.

My question is, how can I possibly make an informed decision about
trusting this certificate?

Is there a valid chain of trust? No, since this is self-signed.
Is there a pointer to a webpage with an online fingerprint for the
supplied certificate? None that I can find.
Is there at least a mailing list archive where the jabber80.com people
indicate that this is the certificate they will be using? None that I
can find.

You do realize that all these are issues that you need to discuss with
the jabber80 maintainers, right? I am not sure how you expect Jitsi to
help you with any of them.

I do realise these are issues of jabber80.com. My original question
was "how to use jitsi behind a firewall?" and it appears that the best
answer is "use jabber80.com".

Back when you asked it, my answer to your original question was: "First
we'd have to know exactly why it doesn't connect." Then someone else
asked you whether you are able to connect to jabber80. This was a good
diagnostics test since success would basically imply your firewall is
restricting communication on non-http ports.

I don't think anyone implied however that "jabber80 is the best way use
Jitsi from behind a firewall". I personally wasn't even aware of this
service before we had this mail exchange.

Now, I do think this is a neat trick and we'll probably consider doing
something along these lines with jit.si (only with 443).

Given that this gave rise to issues like the self-signed cert and
there is no contact information on the jabber80.com website, I was
hoping someone on this list would have a way forward. Please let me
know how to contact jabber80.com people and I'll be more than happy to
do so.

I'd love to help you but I am afraid we are in no way affiliated with
this service. I seem to recall their certificate was mentioning Prosody
though, so getting in touch with them may be a good idea
(http://prosody.im) .

If you'd really like to use the jabber80 service then please get in
touch with them and ask them to either get a valid cert or provide you
with their public fingerprint in a secure way.

(Incidentally, we'll try to see if we could provide a similar service by
also running jit.si on port 443.)

That would probably be valuable for end users, especially if there is
an automatic fallback to port 443 implemented on the client if the
original connection times out.

Sure. It would be something along those lines.

Training people to blindly trust self-signed certificates breaks the
SSL trust model and has the potential to compromise the
privacy/security of Jitsi users.

On the web, self-signed certificates with no mitigating validation
methods (like the ones mentioned above) are considered at least bad
style if not outright dangerous. Given Jitsi users are likely to be
privacy conscious and/or be dealing with tricky security situations, I
would like to stop people from blindly accepting self-signed
certificates. This only makes them easier MITM targets.

I am really not sure how you expect Jitsi to resolve these issues. Would
you rather we simply refused to connect to any site with a non-trusted
certificate?

Absolutely not. This was an allergic reaction to the suggestion to
just click through a security warning. I would like to be shown how to
make an informed decision. On the UI if possible, on the mailing lists
if that's too hard.

The best and the automatic way to allow users to make an informed
decision is for services to have a valid cert matching the proper domain
name. That's how identity validation works with SSL. There's no way
Jitsi could help you assert the identity of a site if they don't have
the proper cert.

All we can do is inform people of the situation and that's what we are
doing.

Emil

Thank you for working on this - Jitsi is a really promising piece of
software and I would love to see it be usable and secure by default
for as many use cases as possible.

It currently works very well for the most usual use cases (e.g.
Windows user

Well ... that's somewhat of an understatement. We have 10000+ users
downloading it for Mac and Linux every month. In most cases it also
works well on these operating systems.

with admin rights

You only need those on Windows during installation and that's because of
the MSI installer. You don't have to be an admin in order to use Jitsi.
You have pretty much the same model on Linux

no funny firewall).

Well ... yeah ... a firewall that limits itself to protecting you rather
than reducing your ways of communication would be nice.

I am supporting a broad base of non-technical users and therefore
share their frustrations when technology doesn't "just work". They
don't know the problem is with the corporate firewall. Or their ISP.
Or that they're not admins on their machines. Or that a service
provider breaks the protocol.

All they see is jitsi having issues where skype "just works". It's an
unfair comparison given resources etc, but as we all should know
people don't care about that. They further don't care about security
as much as they care about easy & hassle-free operation. Which is why
I challenge developers to come up with creative solutions to
well-known problems.

I completely agree with you! We are doing our best to address such
issues ... but it takes time :).

Your openness and dialogue on this is really appreciated.

Thank you for your support and kind words!
Emil

···

On 28.05.12 18:24, ix4svs@gmail.com wrote:

On 28 May 2012 11:53, Emil Ivov <emcho@jitsi.org> wrote:

On 28.05.12 11:49, ix4svs@gmail.com wrote:

On 25 May 2012 08:58, Earl <Large.Files@gmx.net> wrote:

Alex

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