[jitsi-dev] SSL Security Concern


#1

Hi,

I could not get an answer on the user mailinglist. I'm concerned that
jitsi implemented a lax SSL security policy which makes it prone to
SSL ManInTheMiddle attacks to easily.

1. How can I configure jitsi to use one (and just one; exclusive) root
certificate and ignore all other system-wide root certs without having to
recompile the source? (and cross platform of course)

2. How can I configure jitsi to fail connecting to the jabber server if the
SSL trust can not be established? Currently in a man-in-the-middle attack
scenario jitsi shows a pop-up that the cert is not trusted (even that
previous connections had a trusted certificate) and allows the
user to manually accept the certificate (doh!).

thanks & regards,

skyper


#2

We would have been very interested in doing this too. But I think Jitsi either uses the System Root Certs or a list of Java Root Certs (depending on what you tick in the options), There doesn't seem to be a way to handle this kind of behaviour without either

* Reworking Jitsi to handle "manual" Certificate Authorities
* Controlling the User's JRE and hobbling it by taking out the other certs (may be technically possible in a corporate environment with no Java dependencies but even then it's still a nightmare).

We use Jitsi on a private XMPP server for our company alone, so it would be really nice not having to trust over 200 entities in nations with their own legal systems around the world.

I would also like the ability to set the UI into "super strict freakout and lockdown if anything seems fishy" mode, should certs ever be compromised. Even if it's just a flag in the .properties (and I think there may already be similar flags along these lines) I think that it would serve both the corporate environments and the security conscious individual.

···

On 21/09/13 19:30, skyper wrote:

Hi,

I could not get an answer on the user mailinglist. I'm concerned that jitsi implemented a lax SSL security policy which makes it prone to SSL ManInTheMiddle attacks to easily.

1. How can I configure jitsi to use one (and just one; exclusive) root
certificate and ignore all other system-wide root certs without having to
recompile the source? (and cross platform of course)

2. How can I configure jitsi to fail connecting to the jabber server if the
SSL trust can not be established? Currently in a man-in-the-middle attack
scenario jitsi shows a pop-up that the cert is not trusted (even that previous connections had a trusted certificate) and allows the
user to manually accept the certificate (doh!).

thanks & regards,

skyper

--
Toby Pinder | Telemetry Software Engineer

Switchboard +44 (0)845 077 9077
Office Phone: + 44 191 419 7135
Mobile Phone: + 44 (0)7821 036 600

E. toby.pinder@smithelectric.com<mailto:ross.cooney@smithelectric.com>
W. www.smithelectric.com<http://www.smithelectric.com/>

[cid:part3.02000402.03080809@smithelectric.com]

This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.


#3

Hey Toby,

These do sound useful so if anyone is interested in working on them, please let yourselves known.

FWIW, we do hava e PARANOIA_MODE but it does not currently concern SSL certs.

Emil

···

On 23.09.13, 12:35, Toby Pinder wrote:

We would have been very interested in doing this too. But I think Jitsi
either uses the System Root Certs or a list of Java Root Certs
(depending on what you tick in the options), There doesn't seem to be a
way to handle this kind of behaviour without either

* Reworking Jitsi to handle "manual" Certificate Authorities
* Controlling the User's JRE and hobbling it by taking out the other
certs (may be technically possible in a corporate environment with no
Java dependencies but even then it's still a nightmare).

We use Jitsi on a private XMPP server for our company alone, so it would
be really nice not having to trust over 200 entities in nations with
their own legal systems around the world.

I would also like the ability to set the UI into "super strict freakout
and lockdown if anything seems fishy" mode, should certs ever be
compromised. Even if it's just a flag in the .properties (and I think
there may already be similar flags along these lines) I think that it
would serve both the corporate environments and the security conscious
individual.

On 21/09/13 19:30, skyper wrote:

Hi,

I could not get an answer on the user mailinglist. I'm concerned that jitsi implemented a lax SSL security policy which makes it prone to SSL ManInTheMiddle attacks to easily.

1. How can I configure jitsi to use one (and just one; exclusive) root
certificate and ignore all other system-wide root certs without having to
recompile the source? (and cross platform of course)

2. How can I configure jitsi to fail connecting to the jabber server if the
SSL trust can not be established? Currently in a man-in-the-middle attack
scenario jitsi shows a pop-up that the cert is not trusted (even that previous connections had a trusted certificate) and allows the
user to manually accept the certificate (doh!).

thanks & regards,

skyper

--

*Toby Pinder | **Telemetry Software Engineer*

Switchboard +44 (0)845 077 9077

Office Phone: + 44 191 419 7135

Mobile Phone: + 44 (0)7821 036 600

E. toby.pinder@smithelectric.com <mailto:ross.cooney@smithelectric.com>

W. www.smithelectric.com <http://www.smithelectric.com/>

*/This email and any attachments thereto may contain private,
confidential, and privileged material for the sole use of the intended
recipient. Any review, copying, or distribution of this email (or any
attachments thereto) by others is strictly prohibited. If you are not
the intended recipient, please contact the sender immediately and
permanently delete the original and any copies of this email and any
attachments thereto./*

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#4

I'm interested in working on it. I know a lot about SSL and are happy to
give suggestions and advise but not sure how much actual source code
development I can do (time wise).

anyone else interested in a LOCKDOWN option (not compiler option) that
would:
- set default parameters strict and not allow the user to change them
(unless LOCKDOWN is disabled)
- allow for single ROOT-CA
- Do not leave it to the user to decide if a man-in-the-middle attack is
happening (quite honestly, the user never knows and should have have a say
in this....e.g. no manually trusting of untrusted certificates...)

regards,

skyper

···

On Mon, Sep 23, 2013 at 1:43 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Toby,

These do sound useful so if anyone is interested in working on them,
please let yourselves known.

FWIW, we do hava e PARANOIA_MODE but it does not currently concern SSL
certs.

Emil

On 23.09.13, 12:35, Toby Pinder wrote:

We would have been very interested in doing this too. But I think Jitsi
either uses the System Root Certs or a list of Java Root Certs
(depending on what you tick in the options), There doesn't seem to be a
way to handle this kind of behaviour without either

* Reworking Jitsi to handle "manual" Certificate Authorities
* Controlling the User's JRE and hobbling it by taking out the other
certs (may be technically possible in a corporate environment with no
Java dependencies but even then it's still a nightmare).

We use Jitsi on a private XMPP server for our company alone, so it would
be really nice not having to trust over 200 entities in nations with
their own legal systems around the world.

I would also like the ability to set the UI into "super strict freakout
and lockdown if anything seems fishy" mode, should certs ever be
compromised. Even if it's just a flag in the .properties (and I think
there may already be similar flags along these lines) I think that it
would serve both the corporate environments and the security conscious
individual.

On 21/09/13 19:30, skyper wrote:

Hi,

I could not get an answer on the user mailinglist. I'm concerned that
jitsi implemented a lax SSL security policy which makes it prone to SSL
ManInTheMiddle attacks to easily.

1. How can I configure jitsi to use one (and just one; exclusive) root
certificate and ignore all other system-wide root certs without having to
recompile the source? (and cross platform of course)

2. How can I configure jitsi to fail connecting to the jabber server if
the
SSL trust can not be established? Currently in a man-in-the-middle attack
scenario jitsi shows a pop-up that the cert is not trusted (even that
previous connections had a trusted certificate) and allows the
user to manually accept the certificate (doh!).

thanks & regards,

skyper

--

*Toby Pinder | **Telemetry Software Engineer*

Switchboard +44 (0)845 077 9077

Office Phone: + 44 191 419 7135

Mobile Phone: + 44 (0)7821 036 600

E. toby.pinder@smithelectric.com <mailto:ross.cooney@**smithelectric.com<ross.cooney@smithelectric.com>
>

W. www.smithelectric.com <http://www.smithelectric.com/**>

*/This email and any attachments thereto may contain private,

confidential, and privileged material for the sole use of the intended
recipient. Any review, copying, or distribution of this email (or any
attachments thereto) by others is strictly prohibited. If you are not
the intended recipient, please contact the sender immediately and
permanently delete the original and any copies of this email and any
attachments thereto./*

______________________________**_________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/**mailman/listinfo/dev<http://lists.jitsi.org/mailman/listinfo/dev>

--
https://jitsi.org

______________________________**_________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/**mailman/listinfo/dev<http://lists.jitsi.org/mailman/listinfo/dev>


#5

I know little of the technical impact of such an option but that would be great. In our corporate environment for example we can already compile Jitsi with a provisioning URI (in our case we did additional little config/ui changes: fork at https://github.com/smithev/smithchat-jitsi/) and have the entire system be locked to this. Adding a cert to this would be great from my side of things. The "TLS Paranoia" flag would be fine from a user experience point of view because we should control all aspects of the client side security for our users.

-- Toby

···

On 23/09/13 14:58, skyper wrote:
I'm interested in working on it. I know a lot about SSL and are happy to give suggestions and advise but not sure how much actual source code development I can do (time wise).

anyone else interested in a LOCKDOWN option (not compiler option) that would:
- set default parameters strict and not allow the user to change them (unless LOCKDOWN is disabled)
- allow for single ROOT-CA
- Do not leave it to the user to decide if a man-in-the-middle attack is happening (quite honestly, the user never knows and should have have a say in this....e.g. no manually trusting of untrusted certificates...)

regards,

skyper

On Mon, Sep 23, 2013 at 1:43 PM, Emil Ivov <emcho@jitsi.org<mailto:emcho@jitsi.org>> wrote:
Hey Toby,

These do sound useful so if anyone is interested in working on them, please let yourselves known.

FWIW, we do hava e PARANOIA_MODE but it does not currently concern SSL certs.

Emil

On 23.09.13, 12:35, Toby Pinder wrote:
We would have been very interested in doing this too. But I think Jitsi
either uses the System Root Certs or a list of Java Root Certs
(depending on what you tick in the options), There doesn't seem to be a
way to handle this kind of behaviour without either

* Reworking Jitsi to handle "manual" Certificate Authorities
* Controlling the User's JRE and hobbling it by taking out the other
certs (may be technically possible in a corporate environment with no
Java dependencies but even then it's still a nightmare).

We use Jitsi on a private XMPP server for our company alone, so it would
be really nice not having to trust over 200 entities in nations with
their own legal systems around the world.

I would also like the ability to set the UI into "super strict freakout
and lockdown if anything seems fishy" mode, should certs ever be
compromised. Even if it's just a flag in the .properties (and I think
there may already be similar flags along these lines) I think that it
would serve both the corporate environments and the security conscious
individual.

On 21/09/13 19:30, skyper wrote:
Hi,

I could not get an answer on the user mailinglist. I'm concerned that jitsi implemented a lax SSL security policy which makes it prone to SSL ManInTheMiddle attacks to easily.

1. How can I configure jitsi to use one (and just one; exclusive) root
certificate and ignore all other system-wide root certs without having to
recompile the source? (and cross platform of course)

2. How can I configure jitsi to fail connecting to the jabber server if the
SSL trust can not be established? Currently in a man-in-the-middle attack
scenario jitsi shows a pop-up that the cert is not trusted (even that previous connections had a trusted certificate) and allows the
user to manually accept the certificate (doh!).

thanks & regards,

skyper

--

*Toby Pinder | **Telemetry Software Engineer*

Switchboard +44 (0)845 077 9077<tel:%2B44%20%280%29845%20077%209077>

Office Phone: + 44 191 419 7135<tel:%2B%2044%20191%20419%207135>

Mobile Phone: + 44 (0)7821 036 600<tel:%2B%2044%20%280%297821%20036%20600>

E. toby.pinder@smithelectric.com<mailto:toby.pinder@smithelectric.com> <mailto:ross.cooney@smithelectric.com<mailto:ross.cooney@smithelectric.com>>

W. www.smithelectric.com<http://www.smithelectric.com> <http://www.smithelectric.com/>

*/This email and any attachments thereto may contain private,

confidential, and privileged material for the sole use of the intended
recipient. Any review, copying, or distribution of this email (or any
attachments thereto) by others is strictly prohibited. If you are not
the intended recipient, please contact the sender immediately and
permanently delete the original and any copies of this email and any
attachments thereto./*

_______________________________________________
dev mailing list
dev@jitsi.org<mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org<mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
Toby Pinder | Telemetry Software Engineer

Switchboard +44 (0)845 077 9077
Office Phone: + 44 191 419 7135
Mobile Phone: + 44 (0)7821 036 600

E. toby.pinder@smithelectric.com<mailto:ross.cooney@smithelectric.com>
W. www.smithelectric.com<http://www.smithelectric.com/>

[cid:part17.01080105.04090101@smithelectric.com]

This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.