Looking at the downloads section of the website, there doesn't seem to be any signatures for the source or binary packages. There doesn't even seem to be a sha hash or anything, either.
Is this the case or am I missing something?
For a SIP / IM client that prides itself as being "Encrypted by default", this seems to be somewhat out of step.
If this is really the case, I'd be in favor of a sha256/512 hash and
use signify for signing:
http://www.tedunangst.com/flak/post/signify
https://www.youtube.com/watch?v=9R5s3l-0wh0
https://news.ycombinator.com/item?id=9708120
I know gpg/pgp is very common, but let's keep singing and verifying as
simple as jitsi is to use.
from the HN link:
Teaching people how to use the tool, from the point of generating
keys, to generating signature manifests for a packages, to signing,
and verifying takes < 3 minutes for someone who already knows what a
hash is.
On 26 July 2015 at 20:24, Michael Rose <mdrose@ucdavis.edu> wrote:
Looking at the downloads section of the website, there doesn't seem to be
any signatures for the source or binary packages. There doesn't even seem to
be a sha hash or anything, either.Is this the case or am I missing something?
For a SIP / IM client that prides itself as being "Encrypted by default",
this seems to be somewhat out of step.
--
-------
inum: 883510009027723
sip: jungleboogie@sip2sip.info
xmpp: jungle-boogie@jit.si
Yes, this can even happen over plain http. This is why you want to
distribute your key in a different manner. With signify, the key is
very small:
RWRGNg6NU+JAt9ju3ItQfOMmDhXmEkHp28mej8ickx4lOJjE2Tg2DxEO
Since it is so small, it can be provided in a twitter message or
easily in an email. OpenBSD prints the public key on the disc images.
The Jitsi folk could get clever and have the key somewhere in the app
itself and the key for the next release.
On 26 July 2015 at 21:36, Fernando Cassia <fcassia@gmail.com> wrote:
If you distrust the binaries why trust a text string posted on the same
server?
--
-------
inum: 883510009027723
sip: jungleboogie@sip2sip.info
xmpp: jungle-boogie@jit.si
The downloads are provided over https.
So a MITM attack would present you with a different certificate not
belonging to downloads.jitsi.org. In which case you would notice something
is fishy.
If, however, you don't trust the security of the download servers,
including hashes or not is irrelevant, as in that case with a compromised
server the pwner will also simply replace the fingerprint on the web page.
Think about that for a minute and you will see that providing hashes does
not make your downloads any safer. If you distrust the binaries why trust a
text string posted on the same server?
FC
On Mon, Jul 27, 2015 at 12:24 AM, Michael Rose <mdrose@ucdavis.edu> wrote:
Looking at the downloads section of the website, there doesn't seem to be
any signatures for the source or binary packages. There doesn't even seem
to be a sha hash or anything, either.Is this the case or am I missing something?
For a SIP / IM client that prides itself as being "Encrypted by default",
this seems to be somewhat out of step._______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
--
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
With a signature you'd be able to verify through web of trust or out of band methods, where the server's certificate might not be good enough. There's, for instance, people in countries whose governments use their own fake certificates that prevent people from getting non backdoor'ed software. These people could make good use of a high quality ZRTP client to protect themselves. By not offering a signature, there's no way it could be trusted as a secure means of communication.
Either way, regardless of whether you see the validity of a signature, there's not even a hash to verify file integrity.
On 07/27/2015 04:36 AM, Fernando Cassia wrote:
The downloads are provided over https.
So a MITM attack would present you with a different certificate not belonging to downloads.jitsi.org <http://downloads.jitsi.org>. In which case you would notice something is fishy.
If, however, you don't trust the security of the download servers, including hashes or not is irrelevant, as in that case with a compromised server the pwner will also simply replace the fingerprint on the web page. Think about that for a minute and you will see that providing hashes does not make your downloads any safer. If you distrust the binaries why trust a text string posted on the same server?
FC
On Mon, Jul 27, 2015 at 12:24 AM, Michael Rose <mdrose@ucdavis.edu > <mailto:mdrose@ucdavis.edu>> wrote:
Looking at the downloads section of the website, there doesn't
seem to be any signatures for the source or binary packages. There
doesn't even seem to be a sha hash or anything, either.Is this the case or am I missing something?
For a SIP / IM client that prides itself as being "Encrypted by
default", this seems to be somewhat out of step._______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users--
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_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
How would one be able to know IN ADVANCE the hash of the next binary that
is yet to be compiled?
Boggles my mind...
FC
On Mon, Jul 27, 2015 at 2:03 AM, jungle Boogie <jungleboogie0@gmail.com> wrote:
The Jitsi folk could get clever and have the key somewhere in the app
itself and the key for the next release.
--
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
Hi Fernando,
The Jitsi folk could get clever and have the key somewhere in the app
itself and the key for the next release.How would one be able to know IN ADVANCE the hash of the next binary that is
yet to be compiled?
Boggles my mind...
They wouldn't know the hash.
They could generate the KEY for the next release and put in in the
current release for the next release. OpenBSD does this with signify,
release 5.7 contains the keys for 5.8 and 5.8 will contain keys for
5.9.
On 27 July 2015 at 09:49, Fernando Cassia <fcassia@gmail.com> wrote:
On Mon, Jul 27, 2015 at 2:03 AM, jungle Boogie <jungleboogie0@gmail.com> > wrote:
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
--
-------
inum: 883510009027723
sip: jungleboogie@sip2sip.info
xmpp: jungle-boogie@jit.si
The key, not the hash.
This is quite common approach, you pack a new
public key, sometimes or always, which will
be used in the next release.
This is to avoid to be stuck with one key
forever, which might be insecure.
bye,
On Mon, Jul 27, 2015 at 01:49:41PM -0300, Fernando Cassia wrote:
On Mon, Jul 27, 2015 at 2:03 AM, jungle Boogie <jungleboogie0@gmail.com> > wrote:
> The Jitsi folk could get clever and have the key somewhere in the app
> itself and the key for the next release.
>How would one be able to know IN ADVANCE the hash of the next binary that
is yet to be compiled?
Boggles my mind...
--
piergiorgio
As pointed out, the key could be provided in multiple places: twitter,
email, website, IRC, github, etc.
Signify keys are small so they're easy to look at and compare.
openbsd puts it in the email when a new release is announced, on
twitter (don't remember the user) and you can see in the source:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/signify/
On 27 July 2015 at 11:06, 
Adam <adam@dc949.org> wrote:
Publishing a public RSA key could help, but we're back to the root of
trust problem. How do you know that key is actually the authors? If
you assume that TLS is not perfect, then the public key could have be
swapped out, just as a hash could.
--
-------
inum: 883510009027723
sip: jungleboogie@sip2sip.info
xmpp: jungle-boogie@jit.si
Hi,
there are signatures for the debian packets:
https://download.jitsi.org/jitsi/nightly/debian/signatures/.
Also for the mac os x, there is signature verification for the sparkle
updates there is a dsa signature for every build and delta update.
Also the whole application is signed with Apple Application ID and is
verified by the OS.
For the windows build, every binary and the msi and the setup
installer are signed with a valid certificate.
Regards
damencho
On Mon, Jul 27, 2015 at 1:06 PM, Adam <adam@dc949.org> wrote:
For what it's worth, here are the SHA256 checksums I have. If yours
do not match, then one of us is almost certainly in trouble.9cab176de23cecd532851def8eda1a8a3a8195cb0f85991041a1a1548867cd8d
jitsi_2.8.5426-1_amd64.deb
3eab29510f16c0ad962ac5df3b7d6d5d34cfd104f52cc060eb541c522f18fbbc
jitsi_2.8.5426-1_i386.deb
5f896a0ca8b1e5c9e0e7d568684b3c8e931cf4f8a33ccd7d6accb100be961369
jitsi-2.8-5426.i686.rpm
5c1f0143034f11c9d7d780cfc52522107ff80823a43a576c09acac65ba81ea74
jitsi-2.8-5426.x86_64.rpm
91980b803ba5c165c5ec109b784a7338bf5d1af2f866c513baf114bbda2953a4
jitsi-latest.dmg
9cf2a12d2f2a40f392e42eab131b4b65c8ffdf8626f2cd6924922ed7c2e0c3e3
jitsi-latest-x86.exe
e649867e186cf195c4b1bb159d7ffe0a38c4dc60659e5c55f9a74461a309f36c
jitsi-src-2.8.5426.zipI think the reason people are not convinced that TLS is enough is due
to the number of CAs which have been found to be compromised (e.g.
Comodo), as well as things like this:https://www.cdw.com/shop/products/RSA-ROOT-SIGNING-SERVICE/1628425.aspx
The idea with publishing the hashes is that the hash would be
published on one server, and the binary would be published on another.
The servers should be controlled by different people. Somewhere this
was lost along the way and people started publishing the hashes right
next to the binaries. While it makes them easier to find, it defeats
the purpose, as Fernando pointed out.Having a public key embedded into the software which takes care of the
verification on update would work if there is an automated update
mechanism to check and download the updates. If properly implemented,
that solves the problem once you have a copy of the software, but what
about the first time you downloaded the program?Publishing a public RSA key could help, but we're back to the root of
trust problem. How do you know that key is actually the authors? If
you assume that TLS is not perfect, then the public key could have be
swapped out, just as a hash could.Personally, I like the idea of having a hash and a signature for
releases which are downloaded over HTTPS. There's RSA for the people
who are paranoid (and it's up to them to make sure that the public key
actually belongs to someone who is trustworthy). There's a hash for
casual checking, and there's TLS for the people that are either
unwilling or unable to check the hash.In general, it would be interesting to see independent parties sign
releases. For example, a security expert could review the code and
sign it saying that the source matches the binary, or that they went
through the source code and didn't find any (major) issues. A
performance person could sign off on it saying that it is written in a
reasonably efficient manner. Then users could decide that they trust
anything that Joe the security guy has reviewed and signed, and set a
theoretical policy which would only allow installing packages which
are signed by someone that particular user feels comfortable with.
We're a long way off from that. Also, just to be clear, this idea of
having independent reviewers and allowing users decide who they do or
don't trust is not new. It dates back to at least 1992 with
Zimmermann, possibly earlier. Maybe in another 20 years we'll have
something like that..._______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
For what it's worth, here are the SHA256 checksums I have. If yours
do not match, then one of us is almost certainly in trouble.
9cab176de23cecd532851def8eda1a8a3a8195cb0f85991041a1a1548867cd8d
jitsi_2.8.5426-1_amd64.deb
3eab29510f16c0ad962ac5df3b7d6d5d34cfd104f52cc060eb541c522f18fbbc
jitsi_2.8.5426-1_i386.deb
5f896a0ca8b1e5c9e0e7d568684b3c8e931cf4f8a33ccd7d6accb100be961369
jitsi-2.8-5426.i686.rpm
5c1f0143034f11c9d7d780cfc52522107ff80823a43a576c09acac65ba81ea74
jitsi-2.8-5426.x86_64.rpm
91980b803ba5c165c5ec109b784a7338bf5d1af2f866c513baf114bbda2953a4
jitsi-latest.dmg
9cf2a12d2f2a40f392e42eab131b4b65c8ffdf8626f2cd6924922ed7c2e0c3e3
jitsi-latest-x86.exe
e649867e186cf195c4b1bb159d7ffe0a38c4dc60659e5c55f9a74461a309f36c
jitsi-src-2.8.5426.zip
I think the reason people are not convinced that TLS is enough is due
to the number of CAs which have been found to be compromised (e.g.
Comodo), as well as things like this:
https://www.cdw.com/shop/products/RSA-ROOT-SIGNING-SERVICE/1628425.aspx
The idea with publishing the hashes is that the hash would be
published on one server, and the binary would be published on another.
The servers should be controlled by different people. Somewhere this
was lost along the way and people started publishing the hashes right
next to the binaries. While it makes them easier to find, it defeats
the purpose, as Fernando pointed out.
Having a public key embedded into the software which takes care of the
verification on update would work if there is an automated update
mechanism to check and download the updates. If properly implemented,
that solves the problem once you have a copy of the software, but what
about the first time you downloaded the program?
Publishing a public RSA key could help, but we're back to the root of
trust problem. How do you know that key is actually the authors? If
you assume that TLS is not perfect, then the public key could have be
swapped out, just as a hash could.
Personally, I like the idea of having a hash and a signature for
releases which are downloaded over HTTPS. There's RSA for the people
who are paranoid (and it's up to them to make sure that the public key
actually belongs to someone who is trustworthy). There's a hash for
casual checking, and there's TLS for the people that are either
unwilling or unable to check the hash.
In general, it would be interesting to see independent parties sign
releases. For example, a security expert could review the code and
sign it saying that the source matches the binary, or that they went
through the source code and didn't find any (major) issues. A
performance person could sign off on it saying that it is written in a
reasonably efficient manner. Then users could decide that they trust
anything that Joe the security guy has reviewed and signed, and set a
theoretical policy which would only allow installing packages which
are signed by someone that particular user feels comfortable with.
We're a long way off from that. Also, just to be clear, this idea of
having independent reviewers and allowing users decide who they do or
don't trust is not new. It dates back to at least 1992 with
Zimmermann, possibly earlier. Maybe in another 20 years we'll have
something like that...
Another place: the DNS txt record!
How neat would it be to have Jitsi query the txt record when it opens
up and displays a message that you're using the 'authentic' jitsi.
Note, I didn't actually look to see how large the txt record supports.
On 27 July 2015 at 11:25, jungle Boogie <jungleboogie0@gmail.com> wrote:
As pointed out, the key could be provided in multiple places: twitter,
email, website, IRC, github, etc.
--
-------
inum: 883510009027723
sip: jungleboogie@sip2sip.info
xmpp: jungle-boogie@jit.si
Another place: the DNS txt record!
How neat would it be to have Jitsi query the txt record when it opens
up and displays a message that you're using the 'authentic' jitsi.
You'd probably want to use DANE for such a record. The rest of what you mean
is nonsense. If the download is forged, the "authentic" message can be forged
as well. As Damian already pointed out, our binary downloads are all signed.
Ingo
They're not nonsense, you just disagree.
On 29 July 2015 at 08:16, Ingo Bauersachs <ingo@jitsi.org> wrote:
You'd probably want to use DANE for such a record. The rest of what you mean
is nonsense. If the download is forged, the "authentic" message can be forged
as well. As Damian already pointed out, our binary downloads are all signed.
--
-------
inum: 883510009027723
sip: jungleboogie@sip2sip.info
xmpp: jungle-boogie@jit.si