[jitsi-users] improving security of Jitsi overall


#1

Hi,

I'm a new Jitsi user and I think it's a really great project. I had a
few suggestions with the hope of improving Jitsi - specifically
improving integration with Tor and other various things such as secure
download.

A few things stand out that I think could use some help - the first is
that I'd like the default download link to be over SSL/TLS. As it
stands, I'm not clear how anyone can securely download Jitsi - it's not
really integrated in Gnu/Linux distros that I use nor does it appear to
be available through any secure mechanism such as HTTPS. I mean, I
admit, I think SSL/TLS isn't great for security but it's certainly an
improvement on HTTP.

I'd also like to perform an audit to see what works with Tor and what
doesn't work with Tor - is anyone up for pairing up for testing with me?
I'd like a mode where a Jitsi user will be able to use Tor and it will
not ever deanonymize them. This is pretty non-trivial and only the very
newest versions of Pidgin support a "Tor/Privacy proxy" - it's basically
SOCKS5 and tries to ensure that the client won't leak DNS.

I was wondering if the persons who implemented OTR can talk about how
they ensure that it's to spec? Is there any interest in mpOTR for group
chat? I've just written up a spec with a few other people that might be
an alright mpOTR:
https://github.com/kaepora/cryptocat/blob/master/spec/mpOTR.txt

All the best,
Jacob


#2

TOR is perhaps not what you want: AFAIK it don't support directly
UDP, but it seems there's a solution:
http://archives.seul.org/or/talk/Dec-2010/msg00147.html
(I don't know if Mumble uses UDP or TCP and if it is SIP compliant);
however, in any case the latency will be terrible (XMPP would be a
better solution); there are also some projects derived from P2P for
jingles, but none has reached a production level yet.
Also don't forget that TOR POPs are closely watched by several
"services" in many countries (especially in EC).

PS: my signature is automatic LOL (and so true:)

···

On Sun, 06 May 2012 16:28:18 -0400 Jacob Appelbaum <jacob@appelbaum.net> wrote:

I'd also like to perform an audit to see what works with Tor and
what doesn't work with Tor - is anyone up for pairing up for
testing with me? I'd like a mode where a Jitsi user will be able
to use Tor and it will not ever deanonymize them. This is pretty
non-trivial and only the very newest versions of Pidgin support a
"Tor/Privacy proxy" - it's basically SOCKS5 and tries to ensure
that the client won't leak DNS.

--
The more laws and order are made prominent, the more thieves and
robbers there will be. -- Lao Tsu


#3

Hey Jacob,

Hi,

I'm a new Jitsi user and I think it's a really great project. I had a
few suggestions with the hope of improving Jitsi - specifically
improving integration with Tor and other various things such as secure
download.

A few things stand out that I think could use some help - the first is
that I'd like the default download link to be over SSL/TLS.

This has been on our to do list for a while now but it somehow always
got pushed down by other stuff. I've just had a talk with the people
maintaining the machines at the University of Strasbourg and there
shouldn't be any issues with it. Just give us a few days to sort out the
certs and it should be on.

As it
stands, I'm not clear how anyone can securely download Jitsi - it's not
really integrated in Gnu/Linux distros

Oh ... well ... unfortunately this would be quite harder to fix than
just adding https to our current download location.

that I use nor does it appear to
be available through any secure mechanism such as HTTPS. I mean, I
admit, I think SSL/TLS isn't great for security but it's certainly an
improvement on HTTP.

I'd also like to perform an audit to see what works with Tor and what
doesn't work with Tor - is anyone up for pairing up for testing with me?
I'd like a mode where a Jitsi user will be able to use Tor and it will
not ever deanonymize them. This is pretty non-trivial and only the very
newest versions of Pidgin support a "Tor/Privacy proxy" - it's basically
SOCKS5 and tries to ensure that the client won't leak DNS.

We'd need to think about this. Jitsi uses its own DNS resolver so we
have control over where the queries go. We'd just need to experiment a
bit with Tor. As it is, I don't know that much about how it works.

I was wondering if the persons who implemented OTR can talk about how
they ensure that it's to spec?

The original implementor, George Politis (CCed), has moved to other
things. Recently Ingo Bauersachs (on the list) has committed a few fixes
and improvements.

Is there any interest in mpOTR for group
chat?

There's definitely interest. I've heard various people asking for this
during the last year. The thing is that I am not aware of anyone
currently planning to work on it.

I've just written up a spec with a few other people that might be
an alright mpOTR:
https://github.com/kaepora/cryptocat/blob/master/spec/mpOTR.txt

Thanks for the ref!

(quoting your other mail)

That's part of why I think integrating Jitsi with Tor will
help those people - obviously unless the VoIP calls will happen over
TCP, it's not going to work for VoIP but it will work for xmpp/OTR chats
- which is a good start.

We currently support TCP only with Google Talk ... but we may be having
a few issues with it that we need to investigate. We also had plans on
adding TCP for Jingle Nodes but we haven't started yet.

Cheers,
Emil

···

On 06.05.12 22:28, Jacob Appelbaum wrote:

All the best,
Jacob

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


#4

Hey all,

···

On 06.05.12 22:28, Jacob Appelbaum wrote:

A few things stand out that I think could use some help - the first is
that I'd like the default download link to be over SSL/TLS.

Done. The download part of Jitsi is now entirely https.

We'll keep improving download security but we just wanted to give you a
heads up.

Emil

--
http://jitsi.org


#5

That is funny :slight_smile:

Just in case you do not know the relation between Jacob and Tor:
https://www.torproject.org/about/corepeople.html.en

Cheers,
Andreas

···

On 07.05.2012 03:20, Bzzz wrote:

On Sun, 06 May 2012 16:28:18 -0400 > Jacob Appelbaum <jacob@appelbaum.net> wrote:

I'd also like to perform an audit to see what works with Tor and
what doesn't work with Tor ...

TOR is perhaps not what you want:


#6

I'd also like to perform an audit to see what works with Tor and
what doesn't work with Tor - is anyone up for pairing up for
testing with me? I'd like a mode where a Jitsi user will be able
to use Tor and it will not ever deanonymize them. This is pretty
non-trivial and only the very newest versions of Pidgin support a
"Tor/Privacy proxy" - it's basically SOCKS5 and tries to ensure
that the client won't leak DNS.

TOR is perhaps not what you want: AFAIK it don't support directly
UDP, but it seems there's a solution:
http://archives.seul.org/or/talk/Dec-2010/msg00147.html

Yes, it is true that Tor doesn't support UDP.

(I don't know if Mumble uses UDP or TCP and if it is SIP compliant);
however, in any case the latency will be terrible (XMPP would be a
better solution); there are also some projects derived from P2P for
jingles, but none has reached a production level yet.

Tor is exactly what I want for my xmpp client - I use Tor hidden
services that are jabber servers - jabber.ccc.de for example has a
Hidden Service - so there isn't a concern about exit node sniffing, etc.

Also don't forget that TOR POPs are closely watched by several
"services" in many countries (especially in EC).

As a Tor developer, I often hear this kind of stuff and I think to
myself - "why do you think that your unprotected connection is somehow
better or safer?"

I don't really buy that the Tor network is as heavily monitored as
people often suggest. It is so rare to hear someone back that statement
up with evidence that I feel it silly to take it at face value.

Most countries monitor the internet and specific people often get
wiretapped. That's part of why I think integrating Jitsi with Tor will
help those people - obviously unless the VoIP calls will happen over
TCP, it's not going to work for VoIP but it will work for xmpp/OTR chats
- which is a good start.

PS: my signature is automatic LOL (and so true:)

Indeed. :slight_smile:

All the best,
Jacob

···

On 05/06/2012 09:20 PM, Bzzz wrote:

On Sun, 06 May 2012 16:28:18 -0400 > Jacob Appelbaum <jacob@appelbaum.net> wrote:


#7

Hey Jacob,

Hi,

I'm a new Jitsi user and I think it's a really great project. I had a
few suggestions with the hope of improving Jitsi - specifically
improving integration with Tor and other various things such as secure
download.

A few things stand out that I think could use some help - the first is
that I'd like the default download link to be over SSL/TLS.

This has been on our to do list for a while now but it somehow always
got pushed down by other stuff. I've just had a talk with the people
maintaining the machines at the University of Strasbourg and there
shouldn't be any issues with it. Just give us a few days to sort out the
certs and it should be on.

I'll gladly donate the money for a CA racket signed certificate - I'd
also offer to run a HTTPS mirror if it would help. In an ideal world,
I'd suggest HSTS for all HTTPS mirrors - anything less and Moxie's
stripping attacks will work. I also think we should try to get jitsi.org
under HTTPS with HSTS entirely - basically when we hit this url -
https://www.ssllabs.com/ssldb/analyze.html?d=jitsi.org - we should have
a really high score. If we find that it's possible, we can submit a
patch (I'm happy to write it) to Chrome and to do the same for
HTTPS-Everywhere (the EFF project).

Those are simple and very practical changes that will make a huge
difference. We can stop most network attackers without a CA using those
simple changes; to stop more advanced attackers, we'll want to pin certs
in browsers like Chrome and in Jitsi itself for any place it expects
SSL/TLS with certs controlled by the Jitsi team.

As it
stands, I'm not clear how anyone can securely download Jitsi - it's not
really integrated in Gnu/Linux distros

Oh ... well ... unfortunately this would be quite harder to fix than
just adding https to our current download location.

I think it's a perfectly reasonable goal. I agree that it is non-trivial. :slight_smile:

that I use nor does it appear to
be available through any secure mechanism such as HTTPS. I mean, I
admit, I think SSL/TLS isn't great for security but it's certainly an
improvement on HTTP.

I'd also like to perform an audit to see what works with Tor and what
doesn't work with Tor - is anyone up for pairing up for testing with me?
I'd like a mode where a Jitsi user will be able to use Tor and it will
not ever deanonymize them. This is pretty non-trivial and only the very
newest versions of Pidgin support a "Tor/Privacy proxy" - it's basically
SOCKS5 and tries to ensure that the client won't leak DNS.

We'd need to think about this. Jitsi uses its own DNS resolver so we
have control over where the queries go. We'd just need to experiment a
bit with Tor. As it is, I don't know that much about how it works.

Oh - can we force Jitsi to make outgoing DNS queries with TCP? Can we
have it do all the recursion locally? If so - we're in good shape!

I was wondering if the persons who implemented OTR can talk about how
they ensure that it's to spec?

The original implementor, George Politis (CCed), has moved to other
things. Recently Ingo Bauersachs (on the list) has committed a few fixes
and improvements.

I'd love to hear about test vectors and other stuff. Specifically, what
is the status on protection against timing attacks? Is stuff written
with remote/local timing issues in mind?

Is there any interest in mpOTR for group
chat?

There's definitely interest. I've heard various people asking for this
during the last year. The thing is that I am not aware of anyone
currently planning to work on it.

Great - we've started to implement it in cryptocat but it's a toy and
not actually possible to secure at the moment. Browser java script
crypto is a total joke as I'm sure you're aware...

I've just written up a spec with a few other people that might be
an alright mpOTR:
https://github.com/kaepora/cryptocat/blob/master/spec/mpOTR.txt

Thanks for the ref!

Sure - I've asked Ian to look at it but I haven't heard back from him.

(quoting your other mail)

That's part of why I think integrating Jitsi with Tor will
help those people - obviously unless the VoIP calls will happen over
TCP, it's not going to work for VoIP but it will work for xmpp/OTR chats
- which is a good start.

We currently support TCP only with Google Talk ... but we may be having
a few issues with it that we need to investigate. We also had plans on
adding TCP for Jingle Nodes but we haven't started yet.

Oh? What do you mean? Only for Google Talk or only for generic xmpp
services, one of which is Google Talk?

All the best,
Jacob

···

On 05/07/2012 08:48 AM, Emil Ivov wrote:

On 06.05.12 22:28, Jacob Appelbaum wrote:


#8

On Sat, May 19, 2012 at 08:44:19PM +0200, emcho@jitsi.org wrote 0.3K bytes in 15 lines about:
: Done. The download part of Jitsi is now entirely https.

While ssl is great, it breaks apt-get on debian-based operating systems.

http://download.jitsi.org/deb/ now redirects to https:// which apt does
not understand by default.

If apt-get update complains, run:

sudo apt-get install apt-transport-https

from your favorite shell and then jitsi repo will work again.

You can even update /etc/apt/sources.list.d/jitsi.list to use https:

···

sed -i -e 's/http/https/' jitsi.list

--
Andrew
pgp 0x6B4D6475


#9

Hey

A few things stand out that I think could use some help - the first is
that I'd like the default download link to be over SSL/TLS.

Done. The download part of Jitsi is now entirely https.

The versionupdate.properties as well as the provisioning-*.properties
(stable and nightlies) still contain the http-link.

We'll keep improving download security but we just wanted to give you a
heads up.

Emil

Regards,
Ingo

···

On 06.05.12 22:28, Jacob Appelbaum wrote:


#10

Hello,

I noticed, that while on audio/video call, my Jitsi (XMPP & jit.si) connects
to some server via ports 5001 and 5003 (as far as I remember). It
does not connect to my peer directly. That is not good.

Which ports should I open ?

Or maybe there is another way to persuade Jitsi to connect directly to
the contact’s IP address (somebody had mentioned ICE) ?

I already asked that question on the IRC and caused quite a confusion
there.

Thanks a lot,

Adrian.

···

++

“People don’t
want wars. Politicians, bankers and corporations do.”


#11

Thanks! I'm really happy to see how seriously you guys improve things at
the suggestion of your users!

All the best,
Jacob

···

On 05/19/2012 11:44 AM, Emil Ivov wrote:

Hey all,

On 06.05.12 22:28, Jacob Appelbaum wrote:

A few things stand out that I think could use some help - the first is
that I'd like the default download link to be over SSL/TLS.

Done. The download part of Jitsi is now entirely https.

We'll keep improving download security but we just wanted to give you a
heads up.


#12

Arfff ]:->

···

On 7 May 2012 07:38:57 +0200 "Andreas Kuckartz" <A.Kuckartz@ping.de> wrote:

That is funny :slight_smile:

Just in case you do not know the relation between Jacob and Tor:
https://www.torproject.org/about/corepeople.html.en

--
Long life is in store for you.


#13

On Mon, May 07, 2012 at 09:08:40PM -0700, jacob@appelbaum.net wrote 4.7K bytes in 116 lines about:
: in browsers like Chrome and in Jitsi itself for any place it expects
: SSL/TLS with certs controlled by the Jitsi team.

+1 on https in some fashion for jitsi.org.

As for everything else, those seem like step 5 towards a better jitsi. I'd
much rather a code audit of jitsi occur first. There are a lot of moving
parts to jitsi and included libraries. Finding and fixing code bugs in
all of it would probably have a much larger impact on security of jitsi
than addressing the network attacks.

I don't know of any specific bugs and have only started to go down this
path using some automated tools to find some obvious things to fix. I'd
much rather get owned by a government using advanced network surveillance
techniques than some script kiddie exploiting the client for fun and
profit.

Just my 0.02.

···

--
Andrew
pgp 0x6B4D6475


#14

Hey Jacob,

Hey Jacob,

Hi,

I'm a new Jitsi user and I think it's a really great project. I had a
few suggestions with the hope of improving Jitsi - specifically
improving integration with Tor and other various things such as secure
download.

A few things stand out that I think could use some help - the first is
that I'd like the default download link to be over SSL/TLS.

This has been on our to do list for a while now but it somehow always
got pushed down by other stuff. I've just had a talk with the people
maintaining the machines at the University of Strasbourg and there
shouldn't be any issues with it. Just give us a few days to sort out the
certs and it should be on.

I'll gladly donate the money for a CA racket signed certificate

This won't be necessary but thanks for offering!

- I'd
also offer to run a HTTPS mirror if it would help. In an ideal world,
I'd suggest HSTS for all HTTPS mirrors - anything less and Moxie's
stripping attacks will work. I also think we should try to get jitsi.org
under HTTPS

We'll check this out. It shouldn't be too hard but it would probably
take some time to arrange.

with HSTS entirely

I've only just learned about HSTS so I am not quite sure yet as to how
exactly it would be a benefit to Jitsi given that the application itself
doesn't use jitsi.org.

Also, as Andrew pointed, at this point focusing on the client is
probably going to be more efficient in terms of improving security.

As it
stands, I'm not clear how anyone can securely download Jitsi - it's not
really integrated in Gnu/Linux distros

Oh ... well ... unfortunately this would be quite harder to fix than
just adding https to our current download location.

I think it's a perfectly reasonable goal. I agree that it is non-trivial. :slight_smile:

It is definitely something that we would be extremely thrilled to have.
Unfortunately however, the goal is not that easily attainable.

The main issue is that we ship Jitsi with a relatively high number of
libs. All the Java ones need a slightly modified manifest file in order
to run in our OSGi framework which makes it impossible to use the distro
versions and needs to carry them in its own package. That alone might be
a deal breaker for many repository maintainers.

Regarding the native libs, even though we could technically use some of
them, we don't currently have the resources to test a decent number of
distros and guarantee that Jitsi would run with whatever versions are
available in each of them.

A slightly more detailed explanation of the issue is available at the
bottom of this mail:

http://goo.gl/xyuDs

Cheers,
Emil

···

On 08.05.12 06:08, Jacob Appelbaum wrote:

On 05/07/2012 08:48 AM, Emil Ivov wrote:

On 06.05.12 22:28, Jacob Appelbaum wrote:

that I use nor does it appear to
be available through any secure mechanism such as HTTPS. I mean, I
admit, I think SSL/TLS isn't great for security but it's certainly an
improvement on HTTP.

I'd also like to perform an audit to see what works with Tor and what
doesn't work with Tor - is anyone up for pairing up for testing with me?
I'd like a mode where a Jitsi user will be able to use Tor and it will
not ever deanonymize them. This is pretty non-trivial and only the very
newest versions of Pidgin support a "Tor/Privacy proxy" - it's basically
SOCKS5 and tries to ensure that the client won't leak DNS.

We'd need to think about this. Jitsi uses its own DNS resolver so we
have control over where the queries go. We'd just need to experiment a
bit with Tor. As it is, I don't know that much about how it works.

Oh - can we force Jitsi to make outgoing DNS queries with TCP? Can we
have it do all the recursion locally? If so - we're in good shape!

I was wondering if the persons who implemented OTR can talk about how
they ensure that it's to spec?

The original implementor, George Politis (CCed), has moved to other
things. Recently Ingo Bauersachs (on the list) has committed a few fixes
and improvements.

I'd love to hear about test vectors and other stuff. Specifically, what
is the status on protection against timing attacks? Is stuff written
with remote/local timing issues in mind?

Is there any interest in mpOTR for group
chat?

There's definitely interest. I've heard various people asking for this
during the last year. The thing is that I am not aware of anyone
currently planning to work on it.

Great - we've started to implement it in cryptocat but it's a toy and
not actually possible to secure at the moment. Browser java script
crypto is a total joke as I'm sure you're aware...

I've just written up a spec with a few other people that might be
an alright mpOTR:
https://github.com/kaepora/cryptocat/blob/master/spec/mpOTR.txt

Thanks for the ref!

Sure - I've asked Ian to look at it but I haven't heard back from him.

(quoting your other mail)

That's part of why I think integrating Jitsi with Tor will
help those people - obviously unless the VoIP calls will happen over
TCP, it's not going to work for VoIP but it will work for xmpp/OTR chats
- which is a good start.

We currently support TCP only with Google Talk ... but we may be having
a few issues with it that we need to investigate. We also had plans on
adding TCP for Jingle Nodes but we haven't started yet.

Oh? What do you mean? Only for Google Talk or only for generic xmpp
services, one of which is Google Talk?

All the best,
Jacob

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


#15

Just noticed I missed a couple of questions

I'd also like to perform an audit to see what works with Tor and what
doesn't work with Tor - is anyone up for pairing up for testing with me?
I'd like a mode where a Jitsi user will be able to use Tor and it will
not ever deanonymize them. This is pretty non-trivial and only the very
newest versions of Pidgin support a "Tor/Privacy proxy" - it's basically
SOCKS5 and tries to ensure that the client won't leak DNS.

We'd need to think about this. Jitsi uses its own DNS resolver so we
have control over where the queries go. We'd just need to experiment a
bit with Tor. As it is, I don't know that much about how it works.

Oh - can we force Jitsi to make outgoing DNS queries with TCP?

dnsjava seems to have support for TCP (thanks Ingo for confirming) so it
shouldn't be too difficult.

Can we
have it do all the recursion locally?

This part wouldn't be so trivial. Do you guys have a DNS server
available to TOR nodes?

If so - we're in good shape!

I was wondering if the persons who implemented OTR can talk about how
they ensure that it's to spec?

The original implementor, George Politis (CCed), has moved to other
things. Recently Ingo Bauersachs (on the list) has committed a few fixes
and improvements.

I'd love to hear about test vectors and other stuff. Specifically, what
is the status on protection against timing attacks? Is stuff written
with remote/local timing issues in mind?

Not really sure.

Oh? What do you mean? Only for Google Talk or only for generic xmpp
services, one of which is Google Talk?

I meant the TCP relay service that Google offer as part of Google Talk.

Cheers,
Emil

···

On 08.05.12 06:08, Jacob Appelbaum wrote:

On 05/07/2012 08:48 AM, Emil Ivov wrote:

--
http://jitsi.org


#16

Right, hadn't thought of that. Thanks for the report Andrew!

We could maybe add a dependancy on apt-transport-https so that when the
user downloads it and manually installs it the first time, it also adds
this .... Although, just removing the http->https forward would probably be
easier. We'll check this out.

In the mean time, any other suggestions?

Emil

···

On Monday, May 21, 2012, wrote:

On Sat, May 19, 2012 at 08:44:19PM +0200, emcho@jitsi.org <javascript:;>wrote 0.3K bytes in 15 lines about:
: Done. The download part of Jitsi is now entirely https.

While ssl is great, it breaks apt-get on debian-based operating systems.

http://download.jitsi.org/deb/ now redirects to https:// which apt does
not understand by default.

If apt-get update complains, run:

> sudo apt-get install apt-transport-https

from your favorite shell and then jitsi repo will work again.

You can even update /etc/apt/sources.list.d/jitsi.list to use https:

> sed -i -e 's/http/https/' jitsi.list

--
Andrew
pgp 0x6B4D6475

--
--sent from my mobile


#17

Hey

A few things stand out that I think could use some help - the first is
that I'd like the default download link to be over SSL/TLS.

Done. The download part of Jitsi is now entirely https.

The versionupdate.properties as well as the provisioning-*.properties
(stable and nightlies) still contain the http-link.

Right, but that should then 301 to https.

Of course we still need to implement assertions for the jitsi.org
certificates in the updaters. One step at a time.

Emil

···

On 21.05.12 19:42, Ingo Bauersachs wrote:

On 06.05.12 22:28, Jacob Appelbaum wrote:

We'll keep improving download security but we just wanted to give you a
heads up.

Emil

Regards,
Ingo

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


#18

Hey Adrian,

Hello,

I noticed, that while on audio/video call, my Jitsi (XMPP & jit.si)
connects to some server via ports 5001 and 5003 (as far as I remember).
_It does not connect to my peer directly._ That is not good.

If you are certain that the IP address you are seeing is not your peer
this means you have been connected through the jit.si Jingle Node Relay.

During calls Jitsi would first try to establish a direct connection and
would only use relaying if this is not possible. We do this using the
ICE protocol.

Which ports should I open ?

By default Jitsi binds for media on ports 5000 to 6000. Your firewall
needs to allow responses people that have been first contacted from
within your network by UDP.

In other words - if you send an UDP packet to 1.2.3.4:5000, that address
has to be able to send you a response.

Or maybe there is another way to persuade Jitsi to connect directly to
the contact's IP address (somebody had mentioned ICE) ?

Right, as mentioned above, we already use the protocol with XMPP. ICE
however would not do miracles. It allows us to try a bunch of techniques
for reaching the remote party (such as STUN, UPnP, IPv6, your local
address etc.) If none of them work it falls back to a relay.

I already asked that question on the IRC and caused quite a confusion there.

Sorry to hear this. It often happens on IRC though, so our mailing lists
are simply the best place to get a response.

Emil

···

On 21.05.12 20:57, Adrian wrote:

--
http://jitsi.org


#19

Hi again,

I do agree with Jacob in regard to all your efforts and work in general.

In regard to this issue however I have to disagree!

As mentioned by someone else before by just changing from http to
https the whole update process via apt got broken! Which leaves the
system a lot more at risk than with a jitsi download via http.

I don't expect all the users to know how to deal with it and
understand people getting quite disappointed with a program breaking
their system update what might end up in them removing jitsi :frowning:

Therefore I've suggested a solution earlier to move to https without
having (at least the inexperienced) user facing a broken (security!)
update process.

What are your thoughts on that?

Cheers,
John

···

On Wed, May 23, 2012 at 12:45 PM, Jacob Appelbaum <jacob@appelbaum.net> wrote:

On 05/19/2012 11:44 AM, Emil Ivov wrote:

Hey all,

On 06.05.12 22:28, Jacob Appelbaum wrote:

A few things stand out that I think could use some help - the first is
that I'd like the default download link to be over SSL/TLS.

Done. The download part of Jitsi is now entirely https.

We'll keep improving download security but we just wanted to give you a
heads up.

Thanks! I'm really happy to see how seriously you guys improve things at
the suggestion of your users!

All the best,
Jacob


#20

Hi all,

about this topic, I'm not sure, but what about
signing the packages (like Truecrypt or KeePass
do) with some PGP key?

The public part of the key could be distributed
by several means, including this mailing list.

Of course, the user should then verify it, which
might not be so automatic.

Or the packages are already signed?

bye,

···

--

piergiorgio