[jitsi-dev] "The State of TLS on XMPP" by Thijs Alkemade

Andreas_Kuckartz · September 5, 2013, 9:53am

The recent three-part series "The State of TLS on XMPP" by Thijs
Alkemade are interesting for some Jitsi developers:
https://blog.thijsalkema.de/

Part 3 is evaluating XMPP clients (including Jitsi) but the other parts
are also very relevant regarding security.

Cheers,
Andreas

Markus_Kilas · September 6, 2013, 6:48pm

This is very interesting.

Any comments from the developers?, especially regarding the list for
Jitsi on Debian, with RC4-MD5 as the most preferred cipher suite and the
inclusion of the weak DES-CBC-MD5?

Regards,
Markus

···

On 2013-09-05 11:53, Andreas Kuckartz wrote:

The recent three-part series "The State of TLS on XMPP" by Thijs
Alkemade are interesting for some Jitsi developers:
https://blog.thijsalkema.de/

Part 3 is evaluating XMPP clients (including Jitsi) but the other parts
are also very relevant regarding security.

Cheers,
Andreas

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

emcho · September 6, 2013, 8:47pm

I believe we just use the Java defaults. The issue can either be brought to
the attention of the Java maintainers or we could take a patch that changes
this in Jitsi (or both of course)

--sent from my mobile

···

On 6 Sep 2013 21:49, "Markus Kilås" <subjunctive.post@gmail.com> wrote:

This is very interesting.

Any comments from the developers?, especially regarding the list for
Jitsi on Debian, with RC4-MD5 as the most preferred cipher suite and the
inclusion of the weak DES-CBC-MD5?

Regards,
Markus

On 2013-09-05 11:53, Andreas Kuckartz wrote:
> The recent three-part series "The State of TLS on XMPP" by Thijs
> Alkemade are interesting for some Jitsi developers:
> https://blog.thijsalkema.de/
>
> Part 3 is evaluating XMPP clients (including Jitsi) but the other parts
> are also very relevant regarding security.
>
> Cheers,
> Andreas
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>

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

Markus_Kilas · September 9, 2013, 6:24pm

Hi,

I made some tests by adding some printouts in XMPPConnections.java after
the startHandshake():

jdk6-1.txt (4.45 KB)

jdk7-1.txt (4.55 KB)

···

---
System.out.println("Enabled protocols: " + Arrays.asList(((SSLSocket)
socket).getEnabledProtocols()));
        System.out.println("Enabled cipher suites: " +
Arrays.asList(((SSLSocket) socket).getEnabledCipherSuites()));
        System.out.println("SSL Parameters cipher suites: " +
Arrays.asList(((SSLSocket) socket).getSSLParameters().getCipherSuites()));
        System.out.println("Supported protocols: " +
Arrays.asList(((SSLSocket) socket).getSupportedProtocols()));
        System.out.println("Supported cipher suites: " +
Arrays.asList(((SSLSocket) socket).getSupportedCipherSuites()));
        System.out.println("Used suite: " + ((SSLSocket)
socket).getSession().getCipherSuite());
---

There was a big difference between using Java 6 and 7 (OpenJDK in Ubuntu).

In my example when connecting the algorithms used in the end were:
Java 6: SSL_RSA_WITH_RC4_128_MD5
Java 7: TLS_RSA_WITH_AES_256_CBC_SHA

Best regards,
Markus

On 2013-09-06 22:47, Emil Ivov wrote:

I believe we just use the Java defaults. The issue can either be brought
to the attention of the Java maintainers or we could take a patch that
changes this in Jitsi (or both of course)

--sent from my mobile

On 6 Sep 2013 21:49, "Markus Kil�s" <subjunctive.post@gmail.com > <mailto:subjunctive.post@gmail.com>> wrote:

    This is very interesting.

    Any comments from the developers?, especially regarding the list for
    Jitsi on Debian, with RC4-MD5 as the most preferred cipher suite and the
    inclusion of the weak DES-CBC-MD5?

    Regards,
    Markus

    On 2013-09-05 11:53, Andreas Kuckartz wrote:
    > The recent three-part series "The State of TLS on XMPP" by Thijs
    > Alkemade are interesting for some Jitsi developers:
    > https://blog.thijsalkema.de/
    >
    > Part 3 is evaluating XMPP clients (including Jitsi) but the other
    parts
    > are also very relevant regarding security.
    >
    > Cheers,
    > Andreas
    >
    > _______________________________________________
    > dev mailing list
    > dev@jitsi.org <mailto:dev@jitsi.org>
    > Unsubscribe instructions and other list options:
    > http://lists.jitsi.org/mailman/listinfo/dev
    >

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

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

Peter_Saint-Andre1 · September 9, 2013, 7:55pm

Related documentation here:

https://datatracker.ietf.org/doc/draft-saintandre-xmpp-tls/

Peter

···

On 9/9/13 12:24 PM, Markus Kil�s wrote:

Hi,

I made some tests by adding some printouts in XMPPConnections.java
after the startHandshake(): --- System.out.println("Enabled
protocols: " + Arrays.asList(((SSLSocket)
socket).getEnabledProtocols())); System.out.println("Enabled cipher
suites: " + Arrays.asList(((SSLSocket)
socket).getEnabledCipherSuites())); System.out.println("SSL
Parameters cipher suites: " + Arrays.asList(((SSLSocket)
socket).getSSLParameters().getCipherSuites()));
System.out.println("Supported protocols: " +
Arrays.asList(((SSLSocket) socket).getSupportedProtocols()));
System.out.println("Supported cipher suites: " +
Arrays.asList(((SSLSocket) socket).getSupportedCipherSuites()));
System.out.println("Used suite: " + ((SSLSocket)
socket).getSession().getCipherSuite()); ---

There was a big difference between using Java 6 and 7 (OpenJDK in
Ubuntu).

In my example when connecting the algorithms used in the end were:
Java 6: SSL_RSA_WITH_RC4_128_MD5 Java 7:
TLS_RSA_WITH_AES_256_CBC_SHA

Best regards, Markus

On 2013-09-06 22:47, Emil Ivov wrote:

I believe we just use the Java defaults. The issue can either be
brought to the attention of the Java maintainers or we could take
a patch that changes this in Jitsi (or both of course)

--sent from my mobile

On 6 Sep 2013 21:49, "Markus Kil�s" <subjunctive.post@gmail.com >> <mailto:subjunctive.post@gmail.com>> wrote:

This is very interesting.

Any comments from the developers?, especially regarding the list
for Jitsi on Debian, with RC4-MD5 as the most preferred cipher
suite and the inclusion of the weak DES-CBC-MD5?

Regards, Markus

On 2013-09-05 11:53, Andreas Kuckartz wrote:

The recent three-part series "The State of TLS on XMPP" by
Thijs Alkemade are interesting for some Jitsi developers:
https://blog.thijsalkema.de/

Part 3 is evaluating XMPP clients (including Jitsi) but the
other

parts

are also very relevant regarding security.

Cheers, Andreas

Markus_Kilas · September 12, 2013, 6:28pm

My suggestion is that Jitsi makes the necessary adjustments in which
protocols and cipher suites and their priorities as suggested in the
draft specification.

In addition it would be good if it could be fine-tuned by the user as
the recommendations will change when weaknesses are discovered etc and
also the other way around, some users might want to still use some not
recommended algorithms for compatibility reasons.

I propose a few configuration properties that will allow both Jitsi to
change the default list of suites in the future but at the same time
gives the user some flexibility when it comes to add or remove
algorithms as well as control the preference.

1) tlsBlacklistedAlgorithms:
Optional property with set of algorithms that should be enabled even
if Jitsi by default does enable them.

2) tlsWhitelistedAlgorithms:
Optional property with set of algorithms that should be enabled even
if Jitsi (or Java) by default does not.

3) tlsAlgorithmOrder:
Optional property with an ordered list of algorithms to prefer.
Enabled algorithms not included in the list are put at the end of the
final list of enabled algorithms.

What do you think?

Best regards,
Markus

···

On 2013-09-09 21:55, Peter Saint-Andre wrote:

Related documentation here:

https://datatracker.ietf.org/doc/draft-saintandre-xmpp-tls/

Peter

On 9/9/13 12:24 PM, Markus Kil�s wrote:

Hi,

I made some tests by adding some printouts in
XMPPConnections.java after the startHandshake(): ---
System.out.println("Enabled protocols: " +
Arrays.asList(((SSLSocket) socket).getEnabledProtocols()));
System.out.println("Enabled cipher suites: " +
Arrays.asList(((SSLSocket) socket).getEnabledCipherSuites()));
System.out.println("SSL Parameters cipher suites: " +
Arrays.asList(((SSLSocket)
socket).getSSLParameters().getCipherSuites()));
System.out.println("Supported protocols: " +
Arrays.asList(((SSLSocket) socket).getSupportedProtocols()));
System.out.println("Supported cipher suites: " +
Arrays.asList(((SSLSocket) socket).getSupportedCipherSuites()));
System.out.println("Used suite: " + ((SSLSocket)
socket).getSession().getCipherSuite()); ---

There was a big difference between using Java 6 and 7 (OpenJDK
in Ubuntu).

In my example when connecting the algorithms used in the end
were: Java 6: SSL_RSA_WITH_RC4_128_MD5 Java 7:
TLS_RSA_WITH_AES_256_CBC_SHA

Best regards, Markus

On 2013-09-06 22:47, Emil Ivov wrote:

I believe we just use the Java defaults. The issue can either
be brought to the attention of the Java maintainers or we could
take a patch that changes this in Jitsi (or both of course)

--sent from my mobile

On 6 Sep 2013 21:49, "Markus Kil�s" <subjunctive.post@gmail.com >>> <mailto:subjunctive.post@gmail.com>> wrote:

This is very interesting.

Any comments from the developers?, especially regarding the
list for Jitsi on Debian, with RC4-MD5 as the most preferred
cipher suite and the inclusion of the weak DES-CBC-MD5?

Regards, Markus

On 2013-09-05 11:53, Andreas Kuckartz wrote:

The recent three-part series "The State of TLS on XMPP" by
Thijs Alkemade are interesting for some Jitsi developers:
https://blog.thijsalkema.de/

Part 3 is evaluating XMPP clients (including Jitsi) but the
other

parts

are also very relevant regarding security.

Cheers, Andreas

emcho · September 12, 2013, 7:34pm

Sounds reasonable. Anyone interested in providing a patch?

--sent from my mobile

···

On 12 Sep 2013 21:29, "Markus Kilås" <subjunctive.post@gmail.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

My suggestion is that Jitsi makes the necessary adjustments in which
protocols and cipher suites and their priorities as suggested in the
draft specification.

In addition it would be good if it could be fine-tuned by the user as
the recommendations will change when weaknesses are discovered etc and
also the other way around, some users might want to still use some not
recommended algorithms for compatibility reasons.

I propose a few configuration properties that will allow both Jitsi to
change the default list of suites in the future but at the same time
gives the user some flexibility when it comes to add or remove
algorithms as well as control the preference.

1) tlsBlacklistedAlgorithms:
Optional property with set of algorithms that should be enabled even
if Jitsi by default does enable them.

2) tlsWhitelistedAlgorithms:
Optional property with set of algorithms that should be enabled even
if Jitsi (or Java) by default does not.

3) tlsAlgorithmOrder:
Optional property with an ordered list of algorithms to prefer.
Enabled algorithms not included in the list are put at the end of the
final list of enabled algorithms.

What do you think?

Best regards,
Markus

On 2013-09-09 21:55, Peter Saint-Andre wrote:
> Related documentation here:
>
> https://datatracker.ietf.org/doc/draft-saintandre-xmpp-tls/
>
> Peter
>
> On 9/9/13 12:24 PM, Markus Kilås wrote:
>> Hi,
>
>> I made some tests by adding some printouts in
>> XMPPConnections.java after the startHandshake(): ---
>> System.out.println("Enabled protocols: " +
>> Arrays.asList(((SSLSocket) socket).getEnabledProtocols()));
>> System.out.println("Enabled cipher suites: " +
>> Arrays.asList(((SSLSocket) socket).getEnabledCipherSuites()));
>> System.out.println("SSL Parameters cipher suites: " +
>> Arrays.asList(((SSLSocket)
>> socket).getSSLParameters().getCipherSuites()));
>> System.out.println("Supported protocols: " +
>> Arrays.asList(((SSLSocket) socket).getSupportedProtocols()));
>> System.out.println("Supported cipher suites: " +
>> Arrays.asList(((SSLSocket) socket).getSupportedCipherSuites()));
>> System.out.println("Used suite: " + ((SSLSocket)
>> socket).getSession().getCipherSuite()); ---
>
>> There was a big difference between using Java 6 and 7 (OpenJDK
>> in Ubuntu).
>
>> In my example when connecting the algorithms used in the end
>> were: Java 6: SSL_RSA_WITH_RC4_128_MD5 Java 7:
>> TLS_RSA_WITH_AES_256_CBC_SHA
>
>
>> Best regards, Markus
>
>
>> On 2013-09-06 22:47, Emil Ivov wrote:
>>> I believe we just use the Java defaults. The issue can either
>>> be brought to the attention of the Java maintainers or we could
>>> take a patch that changes this in Jitsi (or both of course)
>>>
>>> --sent from my mobile
>>>
>>> On 6 Sep 2013 21:49, "Markus Kilås" <subjunctive.post@gmail.com > >>> <mailto:subjunctive.post@gmail.com>> wrote:
>>>
>>> This is very interesting.
>>>
>>> Any comments from the developers?, especially regarding the
>>> list for Jitsi on Debian, with RC4-MD5 as the most preferred
>>> cipher suite and the inclusion of the weak DES-CBC-MD5?
>>>
>>>
>>> Regards, Markus
>>>
>>> On 2013-09-05 11:53, Andreas Kuckartz wrote:
>>>> The recent three-part series "The State of TLS on XMPP" by
>>>> Thijs Alkemade are interesting for some Jitsi developers:
>>>> https://blog.thijsalkema.de/
>>>>
>>>> Part 3 is evaluating XMPP clients (including Jitsi) but the
>>>> other
>>> parts
>>>> are also very relevant regarding security.
>>>>
>>>> Cheers, Andreas
>>>>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJSMgfCAAoJEP5t3VAYwkOpNPcH/0ciXqAZrhdMXae2Pt3cxXV2
WhIZ4eQKQtWQRPoHXqOgOAIXXCGW/lTxAjBOS7lprG6Jbns63ZelXProi9CtUXiJ
31eud5xGHPrcVd8s3WFdcF5rVih1KRW8zCboN9ylJl3CbsiDerdvkhbQPtaC4200
jNRF3cu3PE/roWy052eXvi+l6vuTQe86KS5d75F4C+H3/rTqRmDCvQ3N0NjDVAfr
mSn904+taUKTLyOE92nFFbp1RFG3N1leX7KP1medL/IUBn3T31dA8nFSIm2I/9lb
p/gdm43UGCCJq1V3j/Yvrj/tYhX9wgGrtLXnLFKNIJG8feuzHBn5lfNyqduLFMo=
=udMA
-----END PGP SIGNATURE-----

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

Peter_Saint-Andre1 · September 13, 2013, 3:15pm

BTW I updated that Internet-Draft last night:

https://datatracker.ietf.org/doc/draft-saintandre-xmpp-tls/

Peter

- --
Peter Saint-Andre
https://stpeter.im/

···

On 9/12/13 12:28 PM, Markus Kil�s wrote:

My suggestion is that Jitsi makes the necessary adjustments in
which protocols and cipher suites and their priorities as suggested
in the draft specification.

Andreas_Kuckartz · September 13, 2013, 12:10pm

Markus Kil�s:

1) tlsBlacklistedAlgorithms: Optional property with set of
algorithms that should be enabled even if Jitsi by default does
enable them.

enabled -> disabled

3) tlsAlgorithmOrder: Optional property with an ordered list of
algorithms to prefer. Enabled algorithms not included in the list
are put at the end of the final list of enabled algorithms.

That implies that the Jitsi-internal order will be followed at the end
of the list, correct?

The Jitsi-internal order best should be contained in a human readable
file and/or Jitsi should be able to display the ordered list.

Cheers,
Andreas

Markus_Kilas · September 13, 2013, 8:36pm

Markus Kil�s:

1) tlsBlacklistedAlgorithms: Optional property with set of
algorithms that should be enabled even if Jitsi by default does
enable them.

enabled -> disabled

Yes, you are right, I meant "set of algorithms that should be disabled".

3) tlsAlgorithmOrder: Optional property with an ordered list of
algorithms to prefer. Enabled algorithms not included in the list
are put at the end of the final list of enabled algorithms.

That implies that the Jitsi-internal order will be followed at the end
of the list, correct?

I think so. This part is maybe not completely figured out yet.

The Jitsi-internal order best should be contained in a human readable
file and/or Jitsi should be able to display the ordered list.

For the GUI, I was thinking of a set of JLists/JTables which displays
the list of available algorithms as well as at the enabled and somehow
the whitelisted and blacklisted ones. There could be add/remove buttons
for moving algorithms to the respective lists as well as changing the
orders.

I would look at how this is done in other applications like for instance
the GlassFish admin console.

Regards,
Markus

···

On 2013-09-13 14:10, Andreas Kuckartz wrote:

Cheers,
Andreas

Markus_Kilas · October 30, 2013, 9:27am

Hi all,

As a first step towards the support for configuring TLS protocols and
cipher suites, I have created a patch which adds logging of the
available protocols/algorithms and finally the chosen ones. The patch
also adds the ability to access the protocol and algorithm used as well
as the server certificate chain.

At the moment this information will be available in the call information
frame however, in the future it would be great if this information could
be made available in a more central place in the GUI for the user to
inspect the certificate and used algorithm.

Maybe something similar to the pad lock in the web browser and its
security information dialog. As a first step towards that maybe there
could be a "call" information frame also for chats where the signaling
information could be obtained in a similar way as for the call information.

Currently this patch only implements support for getting the TLS
information from the Jabber ProtocolProviderService. For completeness I
wanted to have this implemented also for SIP however I got lost
somewhere in the source when searching for where this is handled. Also I
am not personally using SIP and only tried using an iptel.org account
but was unable to find any information on how to configure it to use TLS...

I have created a pull request on Github and patch is attached:

Best regards,
Markus

tls-information-github-pullrequest-11.patch (17.5 KB)

···

On 2013-09-12 21:34, Emil Ivov wrote:

Sounds reasonable. Anyone interested in providing a patch?

--sent from my mobile

On 12 Sep 2013 21:29, "Markus Kil�s" <subjunctive.post@gmail.com > <mailto:subjunctive.post@gmail.com>> wrote:

My suggestion is that Jitsi makes the necessary adjustments in which
protocols and cipher suites and their priorities as suggested in the
draft specification.

In addition it would be good if it could be fine-tuned by the user as
the recommendations will change when weaknesses are discovered etc and
also the other way around, some users might want to still use some not
recommended algorithms for compatibility reasons.

I propose a few configuration properties that will allow both Jitsi to
change the default list of suites in the future but at the same time
gives the user some flexibility when it comes to add or remove
algorithms as well as control the preference.

1) tlsBlacklistedAlgorithms:
Optional property with set of algorithms that should be enabled even
if Jitsi by default does enable them.

2) tlsWhitelistedAlgorithms:
Optional property with set of algorithms that should be enabled even
if Jitsi (or Java) by default does not.

3) tlsAlgorithmOrder:
Optional property with an ordered list of algorithms to prefer.
Enabled algorithms not included in the list are put at the end of the
final list of enabled algorithms.

What do you think?

Best regards,
Markus

On 2013-09-09 21:55, Peter Saint-Andre wrote:

Related documentation here:

https://datatracker.ietf.org/doc/draft-saintandre-xmpp-tls/

Peter

On 9/9/13 12:24 PM, Markus Kil�s wrote:

Hi,

I made some tests by adding some printouts in
XMPPConnections.java after the startHandshake(): ---
System.out.println("Enabled protocols: " +
Arrays.asList(((SSLSocket) socket).getEnabledProtocols()));
System.out.println("Enabled cipher suites: " +
Arrays.asList(((SSLSocket) socket).getEnabledCipherSuites()));
System.out.println("SSL Parameters cipher suites: " +
Arrays.asList(((SSLSocket)
socket).getSSLParameters().getCipherSuites()));
System.out.println("Supported protocols: " +
Arrays.asList(((SSLSocket) socket).getSupportedProtocols()));
System.out.println("Supported cipher suites: " +
Arrays.asList(((SSLSocket) socket).getSupportedCipherSuites()));
System.out.println("Used suite: " + ((SSLSocket)
socket).getSession().getCipherSuite()); ---

There was a big difference between using Java 6 and 7 (OpenJDK
in Ubuntu).

In my example when connecting the algorithms used in the end
were: Java 6: SSL_RSA_WITH_RC4_128_MD5 Java 7:
TLS_RSA_WITH_AES_256_CBC_SHA

Best regards, Markus

On 2013-09-06 22:47, Emil Ivov wrote:

I believe we just use the Java defaults. The issue can either
be brought to the attention of the Java maintainers or we could
take a patch that changes this in Jitsi (or both of course)

--sent from my mobile

On 6 Sep 2013 21:49, "Markus Kil�s" <subjunctive.post@gmail.com > <mailto:subjunctive.post@gmail.com> >>>> <mailto:subjunctive.post@gmail.com > <mailto:subjunctive.post@gmail.com>>> wrote:

This is very interesting.

Any comments from the developers?, especially regarding the
list for Jitsi on Debian, with RC4-MD5 as the most preferred
cipher suite and the inclusion of the weak DES-CBC-MD5?

Regards, Markus

On 2013-09-05 11:53, Andreas Kuckartz wrote:

The recent three-part series "The State of TLS on XMPP" by
Thijs Alkemade are interesting for some Jitsi developers:
https://blog.thijsalkema.de/

Part 3 is evaluating XMPP clients (including Jitsi) but the
other

parts

are also very relevant regarding security.

Cheers, Andreas

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

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

Ingo_Bauersachs · October 30, 2013, 3:47pm

Hi Markus

Thanks for your contribution!

As a first step towards the support for configuring TLS protocols and
cipher suites, I have created a patch which adds logging of the
available protocols/algorithms and finally the chosen ones. The patch
also adds the ability to access the protocol and algorithm used as well
as the server certificate chain.

At the moment this information will be available in the call information
frame however, in the future it would be great if this information could
be made available in a more central place in the GUI for the user to
inspect the certificate and used algorithm.

Maybe something similar to the pad lock in the web browser and its
security information dialog. As a first step towards that maybe there
could be a "call" information frame also for chats where the signaling
information could be obtained in a similar way as for the call

information.

Currently this patch only implements support for getting the TLS
information from the Jabber ProtocolProviderService. For completeness I
wanted to have this implemented also for SIP however I got lost
somewhere in the source when searching for where this is handled. Also I
am not personally using SIP and only tried using an iptel.org account
but was unable to find any information on how to configure it to use

TLS...

I have created a pull request on Github and patch is attached:
https://github.com/jitsi/jitsi/pull/11

It'll take me some time to review this, but as a first comment/in the
meantime could you please update the request so that it conforms to our
coding guidelines? (Line length is the most apparent)

Best regards,
Markus

Ingo

Markus_Kilas · October 31, 2013, 2:08pm

Hi Markus

Thanks for your contribution!

As a first step towards the support for configuring TLS protocols and
cipher suites, I have created a patch which adds logging of the
available protocols/algorithms and finally the chosen ones. The patch
also adds the ability to access the protocol and algorithm used as well
as the server certificate chain.

At the moment this information will be available in the call information
frame however, in the future it would be great if this information could
be made available in a more central place in the GUI for the user to
inspect the certificate and used algorithm.

Maybe something similar to the pad lock in the web browser and its
security information dialog. As a first step towards that maybe there
could be a "call" information frame also for chats where the signaling
information could be obtained in a similar way as for the call

information.

Currently this patch only implements support for getting the TLS
information from the Jabber ProtocolProviderService. For completeness I
wanted to have this implemented also for SIP however I got lost
somewhere in the source when searching for where this is handled. Also I
am not personally using SIP and only tried using an iptel.org account
but was unable to find any information on how to configure it to use

TLS...

I have created a pull request on Github and patch is attached:
https://github.com/jitsi/jitsi/pull/11

It'll take me some time to review this, but as a first comment/in the
meantime could you please update the request so that it conforms to our
coding guidelines? (Line length is the most apparent)

Hi Ingo,

I have fixed all code convention violations that I could find and
updated the request. I also added internationalizations for some texts
that I forgot that I had added in the GUI.

Cheers,
Markus

···

On 2013-10-30 16:47, Ingo Bauersachs wrote:

Best regards,
Markus

Ingo

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

Ingo_Bauersachs · November 10, 2013, 4:42pm

Hey Markus

I could finally look at your patch:

- The TLS version and used cipher are okay in the CallInfo-Dialog

- The PEM certificates don't make any sense in there
What about adding the common name and the issue/end-date of the certificate
as a third line, which would be a link opening the X509CertificatePanel? If
you really want to access the raw PEM, then the X509CertificatePanel could
be modified accordingly (e.g. with a "Save As" or "Show PEM" button).

- I'm not so keen on adding three methods to the protocol provider to obtain
information about the socket
We already have providers that don't use TLS and there might be providers
that don't even use a socket. What do you (and the other devs) think about
adding an OpSet TlsConnectionDetails that would provide all these infos?

- SIP
The socket creation is handled by the JSIP stack. I don't know how to obtain
the created socket without using some ugly reflection, e.g.

regTrans.sendRequest();
Field f = TLSMessageChannel.class.getDeclaredField("mySock");
f.setAccessible(true);
Socket s =
(Socket)f.get(((TLSMessageChannel)((SIPTransaction)regTrans).getMessageChann
el()));

in SipRegistrarConnection.register() and saving it in a field for future
access.
Emil, do you know of a better way?

Ingo

From: Markus Kilås [mailto:subjunctive.post@gmail.com]
Sent: Donnerstag, 31. Oktober 2013 15:09
To: Jitsi Developers; Ingo Bauersachs
Subject: Re: [jitsi-dev] [PATCH] Display TLS information, Was: Re: "The

State

···

-----Original Message-----
of TLS on XMPP" by Thijs Alkemade
On 2013-10-30 16:47, Ingo Bauersachs wrote:

Hi Markus

Thanks for your contribution!

As a first step towards the support for configuring TLS protocols and
cipher suites, I have created a patch which adds logging of the
available protocols/algorithms and finally the chosen ones. The patch
also adds the ability to access the protocol and algorithm used as well
as the server certificate chain.

At the moment this information will be available in the call information
frame however, in the future it would be great if this information could
be made available in a more central place in the GUI for the user to
inspect the certificate and used algorithm.

Maybe something similar to the pad lock in the web browser and its
security information dialog. As a first step towards that maybe there
could be a "call" information frame also for chats where the signaling
information could be obtained in a similar way as for the call
information.

Currently this patch only implements support for getting the TLS
information from the Jabber ProtocolProviderService. For completeness
I wanted to have this implemented also for SIP however I got lost
somewhere in the source when searching for where this is handled. Also
I am not personally using SIP and only tried using an iptel.org
account but was unable to find any information on how to configure it
to use TLS...

I have created a pull request on Github and patch is attached:
https://github.com/jitsi/jitsi/pull/11

It'll take me some time to review this, but as a first comment/in the
meantime could you please update the request so that it conforms to our
coding guidelines? (Line length is the most apparent)

Hi Ingo,

I have fixed all code convention violations that I could find and
updated the request. I also added internationalizations for some texts
that I forgot that I had added in the GUI.

Cheers,
Markus

Best regards,
Markus

Ingo

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

Markus_Kilas · November 11, 2013, 7:11pm

Hey Ingo,

Hey Markus

I could finally look at your patch:

- The TLS version and used cipher are okay in the CallInfo-Dialog

- The PEM certificates don't make any sense in there
What about adding the common name and the issue/end-date of the certificate
as a third line, which would be a link opening the X509CertificatePanel? If
you really want to access the raw PEM, then the X509CertificatePanel could
be modified accordingly (e.g. with a "Save As" or "Show PEM" button).

Yes, sounds better.

However, I just added the complete certificate there as I wanted to have
access to it in lack of a better place.
In the longer run I think the security information about the connection
should be accessible directly from the chat window. There should be some
indication that TLS is in use and the certificates are trusted or not etc.
As it is now I would have to start an audio call and open the Call
information dialog to see the security information about the signaling...

- I'm not so keen on adding three methods to the protocol provider to obtain
information about the socket
We already have providers that don't use TLS and there might be providers
that don't even use a socket. What do you (and the other devs) think about
adding an OpSet TlsConnectionDetails that would provide all these infos?

Sounds good to me.

- SIP
The socket creation is handled by the JSIP stack. I don't know how to obtain
the created socket without using some ugly reflection, e.g.

regTrans.sendRequest();
Field f = TLSMessageChannel.class.getDeclaredField("mySock");
f.setAccessible(true);
Socket s =
(Socket)f.get(((TLSMessageChannel)((SIPTransaction)regTrans).getMessageChann
el()));

in SipRegistrarConnection.register() and saving it in a field for future
access.
Emil, do you know of a better way?

What about improving JSIP with a method giving us access to what we need?

I will soon provide a patch implementing the
whitelist/blacklist/ordering properties for cipher suites + GUI for
changing those. Should I open a separate pull request for that?

Cheers,
Markus

···

On 2013-11-10 17:42, Ingo Bauersachs wrote:

Ingo

-----Original Message-----
From: Markus Kil�s [mailto:subjunctive.post@gmail.com]
Sent: Donnerstag, 31. Oktober 2013 15:09
To: Jitsi Developers; Ingo Bauersachs
Subject: Re: [jitsi-dev] [PATCH] Display TLS information, Was: Re: "The

State

of TLS on XMPP" by Thijs Alkemade
On 2013-10-30 16:47, Ingo Bauersachs wrote:

Hi Markus

Thanks for your contribution!

As a first step towards the support for configuring TLS protocols and
cipher suites, I have created a patch which adds logging of the
available protocols/algorithms and finally the chosen ones. The patch
also adds the ability to access the protocol and algorithm used as well
as the server certificate chain.

At the moment this information will be available in the call information
frame however, in the future it would be great if this information could
be made available in a more central place in the GUI for the user to
inspect the certificate and used algorithm.

Maybe something similar to the pad lock in the web browser and its
security information dialog. As a first step towards that maybe there
could be a "call" information frame also for chats where the signaling
information could be obtained in a similar way as for the call
information.

Currently this patch only implements support for getting the TLS
information from the Jabber ProtocolProviderService. For completeness
I wanted to have this implemented also for SIP however I got lost
somewhere in the source when searching for where this is handled. Also
I am not personally using SIP and only tried using an iptel.org
account but was unable to find any information on how to configure it
to use TLS...

I have created a pull request on Github and patch is attached:
https://github.com/jitsi/jitsi/pull/11

It'll take me some time to review this, but as a first comment/in the
meantime could you please update the request so that it conforms to our
coding guidelines? (Line length is the most apparent)

Hi Ingo,

I have fixed all code convention violations that I could find and
updated the request. I also added internationalizations for some texts
that I forgot that I had added in the GUI.

Cheers,
Markus

Best regards,
Markus

Ingo

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

emcho · November 11, 2013, 7:29pm

- SIP
The socket creation is handled by the JSIP stack. I don't know how to obtain
the created socket without using some ugly reflection, e.g.

regTrans.sendRequest();
Field f = TLSMessageChannel.class.getDeclaredField("mySock");
f.setAccessible(true);
Socket s =
(Socket)f.get(((TLSMessageChannel)((SIPTransaction)regTrans).getMessageChann
el()));

in SipRegistrarConnection.register() and saving it in a field for future
access.
Emil, do you know of a better way?

How about the XxxNetworkLayer classes? That's JSIP's way of providing
access to sockets.

Emil

···

On Sun, Nov 10, 2013 at 5:42 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Ingo

-----Original Message-----
From: Markus Kilås [mailto:subjunctive.post@gmail.com]
Sent: Donnerstag, 31. Oktober 2013 15:09
To: Jitsi Developers; Ingo Bauersachs
Subject: Re: [jitsi-dev] [PATCH] Display TLS information, Was: Re: "The

State

of TLS on XMPP" by Thijs Alkemade
On 2013-10-30 16:47, Ingo Bauersachs wrote:

Hi Markus

Thanks for your contribution!

As a first step towards the support for configuring TLS protocols and
cipher suites, I have created a patch which adds logging of the
available protocols/algorithms and finally the chosen ones. The patch
also adds the ability to access the protocol and algorithm used as well
as the server certificate chain.

At the moment this information will be available in the call information
frame however, in the future it would be great if this information could
be made available in a more central place in the GUI for the user to
inspect the certificate and used algorithm.

Maybe something similar to the pad lock in the web browser and its
security information dialog. As a first step towards that maybe there
could be a "call" information frame also for chats where the signaling
information could be obtained in a similar way as for the call
information.

Currently this patch only implements support for getting the TLS
information from the Jabber ProtocolProviderService. For completeness
I wanted to have this implemented also for SIP however I got lost
somewhere in the source when searching for where this is handled. Also
I am not personally using SIP and only tried using an iptel.org
account but was unable to find any information on how to configure it
to use TLS...

I have created a pull request on Github and patch is attached:
https://github.com/jitsi/jitsi/pull/11

It'll take me some time to review this, but as a first comment/in the
meantime could you please update the request so that it conforms to our
coding guidelines? (Line length is the most apparent)

Hi Ingo,

I have fixed all code convention violations that I could find and
updated the request. I also added internationalizations for some texts
that I forgot that I had added in the GUI.

Cheers,
Markus

Best regards,
Markus

Ingo

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

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

Markus_Kilas · April 13, 2014, 4:20pm

Hey again,

I finally come around to make the requested improvements. The new pull
request is:
https://github.com/jitsi/jitsi/pull/20

As compared with the previous patch:
- The PEM encoded certificate is removed from the call info dialog and
replaced with a link which opens a new frame with the existing
certificate panel.
- The new TLS related methods are now put in its own Operation Set

I also would like to, later as an other patch if I get time to, look at
improving the certificate panel so it offers the ability to save
certificates for more close inspection, support for XMPP extensions as
well as displaying all certificates available not just the end entity
certificate.

Best regards,
Markus

···

On 2013-11-10 17:42, Ingo Bauersachs wrote:

Hey Markus

I could finally look at your patch:

- The TLS version and used cipher are okay in the CallInfo-Dialog

- The PEM certificates don't make any sense in there
What about adding the common name and the issue/end-date of the certificate
as a third line, which would be a link opening the X509CertificatePanel? If
you really want to access the raw PEM, then the X509CertificatePanel could
be modified accordingly (e.g. with a "Save As" or "Show PEM" button).

- I'm not so keen on adding three methods to the protocol provider to obtain
information about the socket
We already have providers that don't use TLS and there might be providers
that don't even use a socket. What do you (and the other devs) think about
adding an OpSet TlsConnectionDetails that would provide all these infos?

- SIP
The socket creation is handled by the JSIP stack. I don't know how to obtain
the created socket without using some ugly reflection, e.g.

regTrans.sendRequest();
Field f = TLSMessageChannel.class.getDeclaredField("mySock");
f.setAccessible(true);
Socket s =
(Socket)f.get(((TLSMessageChannel)((SIPTransaction)regTrans).getMessageChann
el()));

in SipRegistrarConnection.register() and saving it in a field for future
access.
Emil, do you know of a better way?

Ingo

-----Original Message-----
From: Markus Kil�s [mailto:subjunctive.post@gmail.com]
Sent: Donnerstag, 31. Oktober 2013 15:09
To: Jitsi Developers; Ingo Bauersachs
Subject: Re: [jitsi-dev] [PATCH] Display TLS information, Was: Re: "The

State

of TLS on XMPP" by Thijs Alkemade
On 2013-10-30 16:47, Ingo Bauersachs wrote:

Hi Markus

Thanks for your contribution!

As a first step towards the support for configuring TLS protocols and
cipher suites, I have created a patch which adds logging of the
available protocols/algorithms and finally the chosen ones. The patch
also adds the ability to access the protocol and algorithm used as well
as the server certificate chain.

At the moment this information will be available in the call information
frame however, in the future it would be great if this information could
be made available in a more central place in the GUI for the user to
inspect the certificate and used algorithm.

Maybe something similar to the pad lock in the web browser and its
security information dialog. As a first step towards that maybe there
could be a "call" information frame also for chats where the signaling
information could be obtained in a similar way as for the call
information.

Currently this patch only implements support for getting the TLS
information from the Jabber ProtocolProviderService. For completeness
I wanted to have this implemented also for SIP however I got lost
somewhere in the source when searching for where this is handled. Also
I am not personally using SIP and only tried using an iptel.org
account but was unable to find any information on how to configure it
to use TLS...

I have created a pull request on Github and patch is attached:
https://github.com/jitsi/jitsi/pull/11

It'll take me some time to review this, but as a first comment/in the
meantime could you please update the request so that it conforms to our
coding guidelines? (Line length is the most apparent)

Hi Ingo,

I have fixed all code convention violations that I could find and
updated the request. I also added internationalizations for some texts
that I forgot that I had added in the GUI.

Cheers,
Markus

Best regards,
Markus

Ingo

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

Ingo_Bauersachs · November 11, 2013, 7:44pm

- SIP The socket creation is handled by the JSIP stack. I don't know
how to obtain the created socket without using some ugly reflection,
e.g.

regTrans.sendRequest();
Field f = TLSMessageChannel.class.getDeclaredField("mySock");
f.setAccessible(true);
Socket s =

(Socket)f.get(((TLSMessageChannel)((SIPTransaction)regTrans).getMessageC
hann el()));

in SipRegistrarConnection.register() and saving it in a field for future
access.
Emil, do you know of a better way?

How about the XxxNetworkLayer classes? That's JSIP's way of providing
access to sockets.

The SslNetworkLayer is just a factory, it doesn't really provide access to
the sockets (we don't even have access to the SslNetworkLayer instance). All
we could do there is passing the created socket back into the provider
(through the hack I used to determine which PPS is currently requesting the
socket). And this would be in the hope/assumption that JSIP only ever
creates a single socket.
Doesn't really sound more appealing to me...

Emil

Ingo

···

On Sun, Nov 10, 2013 at 5:42 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Ingo_Bauersachs · November 11, 2013, 8:00pm

- The PEM certificates don't make any sense in there
What about adding the common name and the issue/end-date of the

certificate

as a third line, which would be a link opening the X509CertificatePanel?

If

you really want to access the raw PEM, then the X509CertificatePanel

could

be modified accordingly (e.g. with a "Save As" or "Show PEM" button).

Yes, sounds better.

However, I just added the complete certificate there as I wanted to have
access to it in lack of a better place.
In the longer run I think the security information about the connection
should be accessible directly from the chat window. There should be some
indication that TLS is in use and the certificates are trusted or not etc.
As it is now I would have to start an audio call and open the Call
information dialog to see the security information about the signaling...

This could be made available somewhere in the menu (or IMO less preferably a
toolbar button).

[...]

- SIP The socket creation is handled by the JSIP stack. I don't know
how to obtain the created socket without using some ugly reflection,
e.g.

regTrans.sendRequest();
Field f = TLSMessageChannel.class.getDeclaredField("mySock");
f.setAccessible(true);
Socket s =

(Socket)f.get(((TLSMessageChannel)((SIPTransaction)regTrans).getMessageC
hann el()));

in SipRegistrarConnection.register() and saving it in a field for future
access.
Emil, do you know of a better way?

What about improving JSIP with a method giving us access to what we need?

JSIP already has partial support to obtain the negotiated cipher suites (and
some other TLS stuff):
getMessageChannel().getHandshakeCompletedListener().getHandshakeCompletedEve
nt().getCipherSuite()

Problem is: either our (old) version of JSIP is just too old or the code
there is too buggy. It always returns null as the handshake completed event
is not there. When I last debugged that stuff I couldn't get it to work
either.
If you want to fiddle in there - I won't hold you back

I will soon provide a patch implementing the
whitelist/blacklist/ordering properties for cipher suites + GUI for
changing those. Should I open a separate pull request for that?

Yes please.
Have you considered that JSIP plays around with (that is: overwrites) the
cipher suites and protocol versions set in the socket factory?

Cheers,
Markus

Ingo

Ingo_Bauersachs · April 13, 2014, 4:53pm

Hey Markus

I finally come around to make the requested improvements. The new pull
request is:
https://github.com/jitsi/jitsi/pull/20

As compared with the previous patch:
- The PEM encoded certificate is removed from the call info dialog and
replaced with a link which opens a new frame with the existing
certificate panel.
- The new TLS related methods are now put in its own Operation Set

This is good work now!
I've made some comments directly on the pull request, nothing serious. If
you can fix them, I'll commit it.

I also would like to, later as another patch if I get time to, look at
improving the certificate panel so it offers the ability to save
certificates for more close inspection, support for XMPP extensions as
well as displaying all certificates available not just the end entity
certificate.

That would be great too! I long wanted to implement the ability to show each
certificate of the chain separately (perhaps as tabs) but also never found
the time for it.

Best regards,
Markus

Regards,
Ingo