If you trust jabber80.com
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
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
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
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
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
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.
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
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!
On 28.05.12 18:24, email@example.com wrote:
On 28 May 2012 11:53, Emil Ivov <firstname.lastname@example.org> wrote:
On 28.05.12 11:49, email@example.com wrote:
On 25 May 2012 08:58, Earl <Large.Files@gmx.net> wrote:
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
firstname.lastname@example.org PHONE: +184.108.40.206.43.30
http://jitsi.org FAX: +220.127.116.11.47.31