[jitsi-dev] TLS Client Certificate Support for XMPP


#1

Hi

I would like to introduce TLS Client Certificate Support for XMPP. I
currently have a proof-of-concept working which connects to an openfire -
Server. Currently I only touched ProtocolProviderServiceJabberImpl, but
this is because I hard-coded most of the stuff. The change I have in mind
would probably touch the following parts:

- ProtocolProviderServiceJabberImpl
- CertificateService(?) (maybe add some additional methods to access the
information I need for the smack ConnectionConfiguration)
- jabberaccregwiz.ConnectionPanel: Add the option to specify the client
certificate to use (like in the SIP wizard)

What do you think about it?

Regards

Stefan


#2

Hey

I would like to introduce TLS Client Certificate Support for XMPP. I
currently have a proof-of-concept working which connects to an openfire -
Server. Currently I only touched ProtocolProviderServiceJabberImpl, but

this

is because I hard-coded most of the stuff. The change I have in mind would
probably touch the following parts:

- ProtocolProviderServiceJabberImpl

That's to be expected.

- CertificateService(?) (maybe add some additional methods to access the
information I need for the smack ConnectionConfiguration)

I had hoped there's everything available, but we can extend that if
necessary.
For SIP I used a customized SocketFactory, so perhaps you could use that as
well? ConnectionConfiguration.setSocketFactory(f) and
CertificateService.getSSLContext(clientConfig, new
HostTrustManager(...)).getSocketFactory() seem reasonable.

- jabberaccregwiz.ConnectionPanel: Add the option to specify the client
certificate to use (like in the SIP wizard)

Sure.

What do you think about it?

Sounds good!
I don't think that this could still go into the upcoming 2.0 release, but
I'll certainly review your patches.

Regards
Stefan

Regards,
Ingo


#3

Hi Ingo

Thanks for your fast reply!

[...]

> The change I have in mind would
> probably touch the following parts:
>
>
> - ProtocolProviderServiceJabberImpl

That's to be expected.

> - CertificateService(?) (maybe add some additional methods to access the
> information I need for the smack ConnectionConfiguration)

I had hoped there's everything available, but we can extend that if
necessary.
For SIP I used a customized SocketFactory, so perhaps you could use that as
well? ConnectionConfiguration.setSocketFactory(f) and
CertificateService.getSSLContext(clientConfig, new
HostTrustManager(...)).getSocketFactory() seem reasonable.

Yes, configuring the socket factory seemed reasonable to me, too. I
gave it a try this morning, but unfortunately smack doesn't like it.
The only documented successful TLS Client certificate configuration
with smack I've found was:

···

On Mon, Dec 3, 2012 at 8:13 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:
---------------
//ConnectionConfiguration cc
cc.setKeystorePath("....");
cc.setKeystoreType("jks"); //not needed, by default jks
cc.setCallbackHandler(new CallbackHandler()[........]);
connection = new XMPPConnection(cc);
SASLAuthentication.supportSASLMechanism("EXTERNAL", 0);
connection.connect();
connection.login("", "");
---------------

This means I need to retrieve the password for a Keystore via
CertificateService.

Everything else worked fine (configuration and change in the
CertificateService) - I still need to tidy it up a bit, but there
should be no big issue left.

I was tempted to do some refactoring in
ProtocolProviderServiceJabberImpl but will not do it in order to keep
the patch small. I might introduce a JabberLoginStrategy that handles
the two alternative ways of logging in (username/password and TLS) to
avoid introducing further branches in several methods.

Are there recommendations regarding testing? I guess I can't add an
automated test for client certificate authentication without a server
that supports it.

Regards

Stefan

> - jabberaccregwiz.ConnectionPanel: Add the option to specify the client
> certificate to use (like in the SIP wizard)

Sure.

> What do you think about it?

Sounds good!
I don't think that this could still go into the upcoming 2.0 release, but
I'll certainly review your patches.

> Regards
> Stefan

Regards,
Ingo


#4

Hi,

good idea. Just a reminder. In terms of security
CRL service (configurable) and client certificate authentication
is necessary.

CRL:
TLS client has to read certificate distribution points in server cetificates
and contact the distribution points to see if certificate is still valid
or has been
revoked. If not provided in certificate manual configuration of
distribution points
would be desirable. This implies technical connectivity to different
services
like http, ldap (directory service) etc.

Client certificate:
Client has private key and client certificate which then in turn is
required from
server to authenticate. This is like in the common browsers where you
import a .p12
containing private key and certificate to authenticate to a secure side.

When it must be prioritized, CRL has much more priority as one has to
validate if
server certificate is still valid or has been compromised. We all have
heard of the
crappy safety of CA authorities out there, so the more important this is!

Best regards,
Matt

···

Am 03.12.2012 17:48, schrieb Stefan Sieber:

Hi

I would like to introduce TLS Client Certificate Support for XMPP. I
currently have a proof-of-concept working which connects to an
openfire - Server. Currently I only touched
ProtocolProviderServiceJabberImpl, but this is because I hard-coded
most of the stuff. The change I have in mind would probably touch the
following parts:

- ProtocolProviderServiceJabberImpl
- CertificateService(?) (maybe add some additional methods to access
the information I need for the smack ConnectionConfiguration)
- jabberaccregwiz.ConnectionPanel: Add the option to specify the
client certificate to use (like in the SIP wizard)

What do you think about it?

Regards

Stefan


#5

- CertificateService(?) (maybe add some additional methods to access the
information I need for the smack ConnectionConfiguration)

I had hoped there's everything available, but we can extend that if
necessary.
For SIP I used a customized SocketFactory, so perhaps you could use that

as

well? ConnectionConfiguration.setSocketFactory(f) and
CertificateService.getSSLContext(clientConfig, new
HostTrustManager(...)).getSocketFactory() seem reasonable.

Yes, configuring the socket factory seemed reasonable to me, too. I gave
it a try this morning, but unfortunately smack doesn't like it. The only
documented successful TLS Client certificate configuration with smack
I've found was:
---------------
//ConnectionConfiguration cc
cc.setKeystorePath("....");
cc.setKeystoreType("jks"); //not needed, by
default jks cc.setCallbackHandler(new CallbackHandler()[........]);
connection = new XMPPConnection(cc);
SASLAuthentication.supportSASLMechanism("EXTERNAL", 0);
connection.connect();
connection.login("", "");
---------------

This means I need to retrieve the password for a Keystore via
CertificateService.

I saw that too, but it's kind of too much stuff going on there. I don't get
why the need to duplicate almost the whole Cryptography API and I don't like
the idea that the callback-handler that does the password stuff is
duplicated. And then there's the stuff that handles the PKCS#11-Libraries
with their specially configured KeyStores (perhaps not even possible with
the current Smack API).

What is it that smack doesn't like the SocketFactory? Is it ignoring it?
Throwing Exceptions around?

Everything else worked fine (configuration and change in the
CertificateService) - I still need to tidy it up a bit, but there
should be no big issue left.

I was tempted to do some refactoring in
ProtocolProviderServiceJabberImpl but will not do it in order to keep
the patch small. I might introduce a JabberLoginStrategy that handles
the two alternative ways of logging in (username/password and TLS) to
avoid introducing further branches in several methods.

You can do some refactoring if you feel it's necessary, but please try do so
in separate, small patches (means: refactor, then do the new functionality).

Are there recommendations regarding testing? I guess I can't add an
automated test for client certificate authentication without a server
that supports it.

Well, no. That's one of our weak points. If you have an idea to test it with
some Mock-Server that would be great, but it's okay if it doesn't have
tests.

Regards
Stefan

Regards,
Ingo


#6

This means I need to retrieve the password for a Keystore via
CertificateService.

I saw that too, but it's kind of too much stuff going on there. I don't get
why the need to duplicate almost the whole Cryptography API and I don't like
the idea that the callback-handler that does the password stuff is
duplicated.

Yes, XMPPConnection tries to do to much at the same time.
By obtaining the password from the Certificate Service I'm at least
able to reuse most of logic inside
the callback handler (except the callback handler itself).

And then there's the stuff that handles the PKCS#11-Libraries
with their specially configured KeyStores (perhaps not even possible with
the current Smack API).

What is it that smack doesn't like the SocketFactory? Is it ignoring it?
Throwing Exceptions around?

It's throwing Exceptions. I was not able to have a closer look at it, because I
don't have smack sources that match the contents of your smack.jar. I
tried checking
out smack version 3.2.2, but it doesn't seem to match (Debugger says,
it's in XMPPConnection#connect on Line 977 but
in my sources thats somewhere else).
If you can tell me where to get the sources behind your smack.jar I'll
give it another try.

Regards,

Stefan


#7

Hey

good idea. Just a reminder. In terms of security
CRL service (configurable) and client certificate authentication
is necessary.

The client certificate that Stefan wants to implement needs to be checked on
the server side.

CRL: TLS client has to read certificate distribution points in server
cetificates and contact the distribution points to see if certificate is
still valid or has been revoked. If not provided in certificate manual
configuration of distribution points would be desirable. This implies
technical connectivity to different services like http, ldap (directory
service) etc.

We rely on the Java cryptography infrastructure to do that. If you find
errors in our usage of the API however, I'd be happy to fix them.

Client certificate:
Client has private key and client certificate which then in turn is
required from
server to authenticate. This is like in the common browsers where you
import a .p12
containing private key and certificate to authenticate to a secure side.

That's exactly what we're talking about, and it's already there for SIP.

When it must be prioritized, CRL has much more priority as one has to
validate if
server certificate is still valid or has been compromised. We all have
heard of the
crappy safety of CA authorities out there, so the more important this is!

Best regards,
Matt

Regards,
Ingo


#8

Hi,

sry, did not see that thread is about client certificate.
Then only focus on CRL part of mail.

Best regards,
Matt

···

Am 05.12.2012 10:25, schrieb Buddy Butterfly:

Hi,

good idea. Just a reminder. In terms of security
CRL service (configurable) and client certificate authentication
is necessary.

CRL:
TLS client has to read certificate distribution points in server cetificates
and contact the distribution points to see if certificate is still valid
or has been
revoked. If not provided in certificate manual configuration of
distribution points
would be desirable. This implies technical connectivity to different
services
like http, ldap (directory service) etc.

Client certificate:
Client has private key and client certificate which then in turn is
required from
server to authenticate. This is like in the common browsers where you
import a .p12
containing private key and certificate to authenticate to a secure side.

When it must be prioritized, CRL has much more priority as one has to
validate if
server certificate is still valid or has been compromised. We all have
heard of the
crappy safety of CA authorities out there, so the more important this is!

Best regards,
Matt

Am 03.12.2012 17:48, schrieb Stefan Sieber:

Hi

I would like to introduce TLS Client Certificate Support for XMPP. I
currently have a proof-of-concept working which connects to an
openfire - Server. Currently I only touched
ProtocolProviderServiceJabberImpl, but this is because I hard-coded
most of the stuff. The change I have in mind would probably touch the
following parts:

- ProtocolProviderServiceJabberImpl
- CertificateService(?) (maybe add some additional methods to access
the information I need for the smack ConnectionConfiguration)
- jabberaccregwiz.ConnectionPanel: Add the option to specify the
client certificate to use (like in the SIP wizard)

What do you think about it?

Regards

Stefan


#9

Hi Ingo,

thanks for reply. Sry, but it was too early today for me and
I overlooked the "TLS Client" ;-). I immediately corrected this
with a reply to my own mail.

As long as I know there is probably support for CRL verification
but it will not happen automatically. Unfortunately the whole
PKI is mostly driven by organizational / manual decisions.

So to have at least a base minimum on security, the check for the
validity of the certificate is necessary. And, if I remember it
right, the CRL (Certificate Revocation List) distribution points
are even optional in X509. And in general nowadays we talk about the
OCSP (Online Certificate Status Protocol) which is implemented in
most browsers. In Firefox you can find the example in

    Properties->Advanced->Encryption->Validation

There it is specified to validate the certificate if it contains an
OCSP-Server or a manually configured one can be given.

Best regards,
Matt

···

Am 05.12.2012 15:10, schrieb Ingo Bauersachs:

Hey

good idea. Just a reminder. In terms of security
CRL service (configurable) and client certificate authentication
is necessary.

The client certificate that Stefan wants to implement needs to be checked on
the server side.

CRL: TLS client has to read certificate distribution points in server
cetificates and contact the distribution points to see if certificate is
still valid or has been revoked. If not provided in certificate manual
configuration of distribution points would be desirable. This implies
technical connectivity to different services like http, ldap (directory
service) etc.

We rely on the Java cryptography infrastructure to do that. If you find
errors in our usage of the API however, I'd be happy to fix them.

Client certificate:
Client has private key and client certificate which then in turn is
required from
server to authenticate. This is like in the common browsers where you
import a .p12
containing private key and certificate to authenticate to a secure side.

That's exactly what we're talking about, and it's already there for SIP.

When it must be prioritized, CRL has much more priority as one has to
validate if
server certificate is still valid or has been compromised. We all have
heard of the
crappy safety of CA authorities out there, so the more important this is!

Best regards,
Matt

Regards,
Ingo


#10

Hi,

you can check out the sources from :
https://svn.java.net/svn/jitsi~svn/libsrc/smack
The zip contains the patched sources. Most of the patches have already
been contributed to the smack project, but I think only one has been
committed in their repository.

Regards
damencho

···

On Wed, Dec 5, 2012 at 8:40 AM, Stefan Sieber <stesieber@gmail.com> wrote:

This means I need to retrieve the password for a Keystore via
CertificateService.

I saw that too, but it's kind of too much stuff going on there. I don't get
why the need to duplicate almost the whole Cryptography API and I don't like
the idea that the callback-handler that does the password stuff is
duplicated.

Yes, XMPPConnection tries to do to much at the same time.
By obtaining the password from the Certificate Service I'm at least
able to reuse most of logic inside
the callback handler (except the callback handler itself).

And then there's the stuff that handles the PKCS#11-Libraries
with their specially configured KeyStores (perhaps not even possible with
the current Smack API).

What is it that smack doesn't like the SocketFactory? Is it ignoring it?
Throwing Exceptions around?

It's throwing Exceptions. I was not able to have a closer look at it, because I
don't have smack sources that match the contents of your smack.jar. I
tried checking
out smack version 3.2.2, but it doesn't seem to match (Debugger says,
it's in XMPPConnection#connect on Line 977 but
in my sources thats somewhere else).
If you can tell me where to get the sources behind your smack.jar I'll
give it another try.

Regards,

Stefan


#11

Hey

thanks for reply. Sry, but it was too early today for me and
I overlooked the "TLS Client" ;-). I immediately corrected this
with a reply to my own mail.

I saw your second mail, but replied anyway because of the CRL stuff.

As long as I know there is probably support for CRL verification
but it will not happen automatically. Unfortunately the whole
PKI is mostly driven by organizational / manual decisions.

Sorry, I don't get what you mean. Could you elaborate that a bit more?

So to have at least a base minimum on security, the check for the
validity of the certificate is necessary. And, if I remember it
right, the CRL (Certificate Revocation List) distribution points
are even optional in X509. And in general nowadays we talk about the
OCSP (Online Certificate Status Protocol) which is implemented in
most browsers.

Jitsi uses the TLS infrastructure of the Java Cryptography API and as such
checks validity, CA certificates, CRLs, the CA-chain flags, the necessary
certificate usage flags and as far as I know also the OCSP. In addition to
Java's certificate check, we validate the certificate against the hostname
(which is what most applications using Java's API forget).

In Firefox you can find the example in

    Properties->Advanced->Encryption->Validation
There it is specified to validate the certificate if it contains an
OCSP-Server or a manually configured one can be given.

We don't have an option to explicitly enable or disable OCSP, but you can
try to override settings manually with Java's ocsp.XYZ system properties.

Have you noticed that something is not working as expected?

Best regards,
Matt

Hey

good idea. Just a reminder. In terms of security
CRL service (configurable) and client certificate authentication
is necessary.

The client certificate that Stefan wants to implement needs to be
checked on the server side.

CRL: TLS client has to read certificate distribution points in server
cetificates and contact the distribution points to see if certificate is
still valid or has been revoked. If not provided in certificate manual
configuration of distribution points would be desirable. This implies
technical connectivity to different services like http, ldap (directory
service) etc.

We rely on the Java cryptography infrastructure to do that. If you find
errors in our usage of the API however, I'd be happy to fix them.

Client certificate:
Client has private key and client certificate which then in turn is
required from
server to authenticate. This is like in the common browsers where you
import a .p12
containing private key and certificate to authenticate to a secure side.

That's exactly what we're talking about, and it's already there for SIP.

When it must be prioritized, CRL has much more priority as one has to
validate if
server certificate is still valid or has been compromised. We all have
heard of the
crappy safety of CA authorities out there, so the more important this

is!

···

Am 05.12.2012 15:10, schrieb Ingo Bauersachs:

Best regards,
Matt

Regards,
Ingo


#12

Hi Ingo,

ok, here you got me. Did not look into the code, just wanted to
point out its importance. So

1. JCA has "ocsp.enable" false by default.

2. Properties like "ocsp.enable" can be set dynamically via
java.security.Security.setProperty().
   I did not find any option for that on the GUI.

So, a quick look at documentation showed that there is support for OCSP
in JCA, it just should be configurable. CRL handling on the other hand
is not
very clear and would need some testing to reveal. Though, Appendix B:
The "SUN" provider
states: " It does not implement support for the freshest CRL or ..."
which I understand as
implementing a CRL verification against the CRL cache but no online
retrieval by default.

From this it looks like OCSP would be nice to enable. It can also be

done Java wide in the
security options.

Best regards,
Matt

···

Am 05.12.2012 15:38, schrieb Ingo Bauersachs:

Hey

thanks for reply. Sry, but it was too early today for me and
I overlooked the "TLS Client" ;-). I immediately corrected this
with a reply to my own mail.

I saw your second mail, but replied anyway because of the CRL stuff.

As long as I know there is probably support for CRL verification
but it will not happen automatically. Unfortunately the whole
PKI is mostly driven by organizational / manual decisions.

Sorry, I don't get what you mean. Could you elaborate that a bit more?

So to have at least a base minimum on security, the check for the
validity of the certificate is necessary. And, if I remember it
right, the CRL (Certificate Revocation List) distribution points
are even optional in X509. And in general nowadays we talk about the
OCSP (Online Certificate Status Protocol) which is implemented in
most browsers.

Jitsi uses the TLS infrastructure of the Java Cryptography API and as such
checks validity, CA certificates, CRLs, the CA-chain flags, the necessary
certificate usage flags and as far as I know also the OCSP. In addition to
Java's certificate check, we validate the certificate against the hostname
(which is what most applications using Java's API forget).

In Firefox you can find the example in

    Properties->Advanced->Encryption->Validation
There it is specified to validate the certificate if it contains an
OCSP-Server or a manually configured one can be given.

We don't have an option to explicitly enable or disable OCSP, but you can
try to override settings manually with Java's ocsp.XYZ system properties.

Have you noticed that something is not working as expected?

Best regards,
Matt

Am 05.12.2012 15:10, schrieb Ingo Bauersachs:

Hey

good idea. Just a reminder. In terms of security
CRL service (configurable) and client certificate authentication
is necessary.

The client certificate that Stefan wants to implement needs to be
checked on the server side.

CRL: TLS client has to read certificate distribution points in server
cetificates and contact the distribution points to see if certificate is
still valid or has been revoked. If not provided in certificate manual
configuration of distribution points would be desirable. This implies
technical connectivity to different services like http, ldap (directory
service) etc.

We rely on the Java cryptography infrastructure to do that. If you find
errors in our usage of the API however, I'd be happy to fix them.

Client certificate:
Client has private key and client certificate which then in turn is
required from
server to authenticate. This is like in the common browsers where you
import a .p12
containing private key and certificate to authenticate to a secure side.

That's exactly what we're talking about, and it's already there for SIP.

When it must be prioritized, CRL has much more priority as one has to
validate if
server certificate is still valid or has been compromised. We all have
heard of the
crappy safety of CA authorities out there, so the more important this

is!

Best regards,
Matt

Regards,
Ingo


#13

@Damian Thanks for the sources, they helped me a lot!

@Ingo
If I got it right, in XMPP, the connection is not secured from the
beginning (http://xmpp.org/rfcs/rfc3920.html#tls). The SSL Handshake
is started on an existing connection, after the Server requests it by
sending a <starttls> - Message. In smack, this is done in
XMPPConnection#proceedTLSReceived(). Therefore XMPPConnection can't be
a SSL connection from the beginning.

Thus, it's not possible to configure XMPPConnection with a
SSLSocketFactory. We'll probably currently have to live with
configuring the key store and a CallbackHandler for the key store
password.

@Matt
In the case of client certificates, its the server that must verify
the certificate. I therefore do not consider CRL's as part of this
task (verification of the server certificate is already implemented)

I'll now try to put together my patches.

Regards

Stefan

···

On Wed, Dec 5, 2012 at 8:07 AM, Damian Minkov <damencho@jitsi.org> wrote:

Hi,

you can check out the sources from :
https://svn.java.net/svn/jitsi~svn/libsrc/smack
The zip contains the patched sources. Most of the patches have already
been contributed to the smack project, but I think only one has been
committed in their repository.

Regards
damencho

On Wed, Dec 5, 2012 at 8:40 AM, Stefan Sieber <stesieber@gmail.com> wrote:

This means I need to retrieve the password for a Keystore via
CertificateService.

I saw that too, but it's kind of too much stuff going on there. I don't get
why the need to duplicate almost the whole Cryptography API and I don't like
the idea that the callback-handler that does the password stuff is
duplicated.

Yes, XMPPConnection tries to do to much at the same time.
By obtaining the password from the Certificate Service I'm at least
able to reuse most of logic inside
the callback handler (except the callback handler itself).

And then there's the stuff that handles the PKCS#11-Libraries
with their specially configured KeyStores (perhaps not even possible with
the current Smack API).

What is it that smack doesn't like the SocketFactory? Is it ignoring it?
Throwing Exceptions around?

It's throwing Exceptions. I was not able to have a closer look at it, because I
don't have smack sources that match the contents of your smack.jar. I
tried checking
out smack version 3.2.2, but it doesn't seem to match (Debugger says,
it's in XMPPConnection#connect on Line 977 but
in my sources thats somewhere else).
If you can tell me where to get the sources behind your smack.jar I'll
give it another try.

Regards,

Stefan


#14

Hi,

ok, JCA also supports the CRL distribution points but they are also
disabled by default:

--- snip ---

      Support for the CRL Distribution Points Extension

Support for the CRL Distribution Points extension is available. It is
disabled by default for compatibility and can be enabled by setting the
system property |com.sun.security.enableCRLDP| to the value |true|.

If set to true, Sun's PKIX implementation uses the information in a
certificate's CRL Distribution Points extension (in addition to

CertStore>s that are specified) to find the CRL, provided the

distribution point is an X.500 distinguished name or a URI of type ldap,
http, or ftp.

--- snap ---

So both, CRL distribution point and OCSP are disabled by default.

Best regards,
Matt

···

Am 05.12.2012 16:09, schrieb Buddy Butterfly:

Hi Ingo,

ok, here you got me. Did not look into the code, just wanted to
point out its importance. So

1. JCA has "ocsp.enable" false by default.

2. Properties like "ocsp.enable" can be set dynamically via
java.security.Security.setProperty().
   I did not find any option for that on the GUI.

So, a quick look at documentation showed that there is support for OCSP
in JCA, it just should be configurable. CRL handling on the other hand
is not
very clear and would need some testing to reveal. Though, Appendix B:
The "SUN" provider
states: " It does not implement support for the freshest CRL or ..."
which I understand as
implementing a CRL verification against the CRL cache but no online
retrieval by default.
From this it looks like OCSP would be nice to enable. It can also be
done Java wide in the
security options.

Best regards,
Matt

Am 05.12.2012 15:38, schrieb Ingo Bauersachs:

Hey

thanks for reply. Sry, but it was too early today for me and
I overlooked the "TLS Client" ;-). I immediately corrected this
with a reply to my own mail.

I saw your second mail, but replied anyway because of the CRL stuff.

As long as I know there is probably support for CRL verification
but it will not happen automatically. Unfortunately the whole
PKI is mostly driven by organizational / manual decisions.

Sorry, I don't get what you mean. Could you elaborate that a bit more?

So to have at least a base minimum on security, the check for the
validity of the certificate is necessary. And, if I remember it
right, the CRL (Certificate Revocation List) distribution points
are even optional in X509. And in general nowadays we talk about the
OCSP (Online Certificate Status Protocol) which is implemented in
most browsers.

Jitsi uses the TLS infrastructure of the Java Cryptography API and as such
checks validity, CA certificates, CRLs, the CA-chain flags, the necessary
certificate usage flags and as far as I know also the OCSP. In addition to
Java's certificate check, we validate the certificate against the hostname
(which is what most applications using Java's API forget).

In Firefox you can find the example in

    Properties->Advanced->Encryption->Validation
There it is specified to validate the certificate if it contains an
OCSP-Server or a manually configured one can be given.

We don't have an option to explicitly enable or disable OCSP, but you can
try to override settings manually with Java's ocsp.XYZ system properties.

Have you noticed that something is not working as expected?

Best regards,
Matt

Am 05.12.2012 15:10, schrieb Ingo Bauersachs:

Hey

good idea. Just a reminder. In terms of security
CRL service (configurable) and client certificate authentication
is necessary.

The client certificate that Stefan wants to implement needs to be
checked on the server side.

CRL: TLS client has to read certificate distribution points in server
cetificates and contact the distribution points to see if certificate is
still valid or has been revoked. If not provided in certificate manual
configuration of distribution points would be desirable. This implies
technical connectivity to different services like http, ldap (directory
service) etc.

We rely on the Java cryptography infrastructure to do that. If you find
errors in our usage of the API however, I'd be happy to fix them.

Client certificate:
Client has private key and client certificate which then in turn is
required from
server to authenticate. This is like in the common browsers where you
import a .p12
containing private key and certificate to authenticate to a secure side.

That's exactly what we're talking about, and it's already there for SIP.

When it must be prioritized, CRL has much more priority as one has to
validate if
server certificate is still valid or has been compromised. We all have
heard of the
crappy safety of CA authorities out there, so the more important this

is!

Best regards,
Matt

Regards,
Ingo


#15

@Ingo
If I got it right, in XMPP, the connection is not secured from the
beginning (http://xmpp.org/rfcs/rfc3920.html#tls). The SSL Handshake
is started on an existing connection, after the Server requests it by
sending a <starttls> - Message. In smack, this is done in
XMPPConnection#proceedTLSReceived(). Therefore XMPPConnection can't be
a SSL connection from the beginning.

Thus, it's not possible to configure XMPPConnection with a
SSLSocketFactory. We'll probably currently have to live with configuring
the key store and a CallbackHandler for the key store password.

Rrrriiight... forgot about that in the hurry.

Do you think adding a method in Smack that allows supplying a
pre-instantiated KeyStore object would help to avoid duplicating stuff?
After all I guess they do that internally anyway.

Ingo


#16

Hi Stefan,

yep, I know that the server is responsible for validation.
But thought you would have a better security in mind anyway.
That is why I said that then we also need to consider proper
CRL handling.

Regarding testing you could test against openssl in server
mode. You can also increase debug level then and see
tls messages flowing. If you are able to isolate the tls stuff
for testing then this is an option.

If xmpp needs to be involved then maybe some netcat mockup would work?

regards,
Matt

···

Am 05.12.2012 15:05, schrieb Stefan Sieber:

@Damian Thanks for the sources, they helped me a lot!

@Ingo
If I got it right, in XMPP, the connection is not secured from the
beginning (http://xmpp.org/rfcs/rfc3920.html#tls). The SSL Handshake
is started on an existing connection, after the Server requests it by
sending a <starttls> - Message. In smack, this is done in
XMPPConnection#proceedTLSReceived(). Therefore XMPPConnection can't be
a SSL connection from the beginning.

Thus, it's not possible to configure XMPPConnection with a
SSLSocketFactory. We'll probably currently have to live with
configuring the key store and a CallbackHandler for the key store
password.

@Matt
In the case of client certificates, its the server that must verify
the certificate. I therefore do not consider CRL's as part of this
task (verification of the server certificate is already implemented)

I'll now try to put together my patches.

Regards

Stefan

On Wed, Dec 5, 2012 at 8:07 AM, Damian Minkov <damencho@jitsi.org> wrote:

Hi,

you can check out the sources from :
https://svn.java.net/svn/jitsi~svn/libsrc/smack
The zip contains the patched sources. Most of the patches have already
been contributed to the smack project, but I think only one has been
committed in their repository.

Regards
damencho

On Wed, Dec 5, 2012 at 8:40 AM, Stefan Sieber <stesieber@gmail.com> wrote:

This means I need to retrieve the password for a Keystore via
CertificateService.

I saw that too, but it's kind of too much stuff going on there. I don't get
why the need to duplicate almost the whole Cryptography API and I don't like
the idea that the callback-handler that does the password stuff is
duplicated.

Yes, XMPPConnection tries to do to much at the same time.
By obtaining the password from the Certificate Service I'm at least
able to reuse most of logic inside
the callback handler (except the callback handler itself).

And then there's the stuff that handles the PKCS#11-Libraries
with their specially configured KeyStores (perhaps not even possible with
the current Smack API).

What is it that smack doesn't like the SocketFactory? Is it ignoring it?
Throwing Exceptions around?

It's throwing Exceptions. I was not able to have a closer look at it, because I
don't have smack sources that match the contents of your smack.jar. I
tried checking
out smack version 3.2.2, but it doesn't seem to match (Debugger says,
it's in XMPPConnection#connect on Line 977 but
in my sources thats somewhere else).
If you can tell me where to get the sources behind your smack.jar I'll
give it another try.

Regards,

Stefan


#17

Hi Ingo

Do you think adding a method in Smack that allows supplying a
pre-instantiated KeyStore object would help to avoid duplicating stuff?
After all I guess they do that internally anyway.

I think the default smack solution doesn't cause too much code
duplication, as it reuses jitsis password dialog for
the keystore. XMPPConnection looks rather brittle to me so, I'd
rather like to leave smack as it is. If you think the solution
with password key store should be avoided I might have a closer look at smack.

Here's a first version of my patches.
1) refactoring_introducing_login_strategy.patch -> small refactoring
that introduces JabberLoginStrategy
2) client_cert_support.patch -> patch that enables client certificates
(it integrates into the XMPP configuration dialog)

Feedback to the patches is highly welcome!

Regards

Stefan

client_cert_support.patch (25.2 KB)

refactoring_introducing_login_strategy.patch (16.5 KB)


#18

Hey

I just committed a change that allows you to configure the CRL and OCSP
checking in the TLS configuration advanced options panel. They are currently
not enabled by default, but we (the other devs) can discuss to enable the
CRL checking.

As I consider the OCSP-Implementation of Java to be broken, enabling that by
default is currently not an option. Broken means that it causes validation
failures on perfectly valid certificates. About the sense of OCSP in
general, you might want to read this [1] blog post. I know it's a bit dated,
but the problems still apply.

Thanks for noting that those stuff is not enabled by default!

Regards,
Ingo

From: Buddy Butterfly [mailto:buddy.butterfly@web.de]
Sent: Mittwoch, 5. Dezember 2012 10:15
To: dev@jitsi.java.net
Subject: [jitsi-dev] Re: TLS Client Certificate Support for XMPP

Hi,

ok, JCA also supports the CRL distribution points but they are also
disabled by default:

--- snip ---

Support for the CRL Distribution Points Extension

Support for the CRL Distribution Points extension is available. It is
disabled by default for compatibility and can be enabled by setting the
system property com.sun.security.enableCRLDP to the value true.

If set to true, Sun's PKIX implementation uses the information in a
certificate's CRL Distribution Points extension (in addition to CertStores
that are specified) to find the CRL, provided the distribution point is an
X.500 distinguished name or a URI of type ldap, http, or ftp.

--- snap ---

So both, CRL distribution point and OCSP are disabled by default.

Best regards,
Matt

  Hi Ingo,

  ok, here you got me. Did not look into the code, just wanted to
  point out its importance. So

  1. JCA has "ocsp.enable" false by default.

  2. Properties like "ocsp.enable" can be set dynamically via
  java.security.Security.setProperty(). I did not find any option

for

that on the GUI.

  So, a quick look at documentation showed that there is support for

OCSP

  in JCA, it just should be configurable. CRL handling on the other

hand

  is not very clear and would need some testing to reveal. Though,
Appendix B: The "SUN" provider states: " It does not implement

support

for the freshest CRL or ..." which I understand as implementing a CRL
verification against the CRL cache but no online retrieval by

default.

  From this it looks like OCSP would be nice to enable. It can also be
  done Java wide in the security options.

  Best regards,
  Matt

    Hey

      thanks for reply. Sry, but it was too early today

for me

and
      I overlooked the "TLS Client" ;-). I immediately
corrected this
      with a reply to my own mail.

    I saw your second mail, but replied anyway because of the

CRL stuff.

      As long as I know there is probably support for CRL

verification

      but it will not happen automatically. Unfortunately

the whole PKI

is mostly driven by organizational / manual decisions.

    Sorry, I don't get what you mean. Could you elaborate that a

bit more?

      So to have at least a base minimum on security, the

check for the

      validity of the certificate is necessary. And, if I

remember it

      right, the CRL (Certificate Revocation List)

distribution points

      are even optional in X509. And in general nowadays

we talk about the

      OCSP (Online Certificate Status Protocol) which is

implemented in

      most browsers.

    Jitsi uses the TLS infrastructure of the Java Cryptography

API and as

such checks validity, CA certificates, CRLs, the CA-chain flags,

the

necessary certificate usage flags and as far as I know also

the OCSP.

In addition to Java's certificate check, we validate the

certificate

against the hostname (which is what most applications using

Java's API

forget).

      In Firefox you can find the example in

          Properties->Advanced->Encryption->Validation
      There it is specified to validate the certificate if

it

contains an
      OCSP-Server or a manually configured one can be

given.

    We don't have an option to explicitly enable or disable

OCSP, but you

can try to override settings manually with Java's ocsp.XYZ

system

properties.

    Have you noticed that something is not working as expected?

      Best regards,
      Matt

        Hey

          good idea. Just a reminder. In terms

of

security
          CRL service (configurable) and

client

certificate authentication
          is necessary.

        The client certificate that Stefan wants to
implement needs to be
        checked on the server side.

          CRL: TLS client has to read

certificate

distribution points in server
          cetificates and contact the

distribution

points to see if certificate is
          still valid or has been revoked. If

not

provided in certificate manual
          configuration of distribution points

would

be desirable. This implies
          technical connectivity to different

services

like http, ldap (directory
          service) etc.

        We rely on the Java cryptography

infrastructure to

do that. If you find
        errors in our usage of the API however, I'd

be

happy to fix them.

          Client certificate:
          Client has private key and client
certificate which then in turn is
          required from
          server to authenticate. This is like

in the

common browsers where you
          import a .p12
          containing private key and

certificate to

authenticate to a secure side.

        That's exactly what we're talking about, and

it's

already there for SIP.

          When it must be prioritized, CRL has

much

more priority as one has to
          validate if
          server certificate is still valid or

has

been compromised. We all have
          heard of the
          crappy safety of CA authorities out

there,

···

-----Original Message-----
Am 05.12.2012 16:09, schrieb Buddy Butterfly:
  Am 05.12.2012 15:38, schrieb Ingo Bauersachs:
      Am 05.12.2012 15:10, schrieb Ingo Bauersachs:
so the more important this

    is!

          Best regards,
          Matt

        Regards,
        Ingo


#19

Hey

Do you think adding a method in Smack that allows supplying a
pre-instantiated KeyStore object would help to avoid duplicating stuff?
After all I guess they do that internally anyway.

I think the default smack solution doesn't cause too much code
duplication, as it reuses jitsis password dialog for the keystore.
XMPPConnection looks rather brittle to me so, I'd rather like to leave
smack as it is. If you think the solution with password key store should
be avoided I might have a closer look at smack.

I took a look at XMPPConnection and I think the change would be rather easy:
instead of specifying just a custom TrustManager, we inject the whole
SSLContext. The attached patch would be on top of our existing patch.
Haven't tried it though.
Going that way would avoid some of the problems mentioned below.

Here's a first version of my patches.

In general, they look good, thank you!
Some cosmetics to begin with, please:
- add the Jitsi license header to new files
- respect the code style (line length) [1]
- add javadoc to new parameters (loginStrategy)
- avoid modifications to code you don't actually change

- Emil is going to contact you about the BCA [2]

1) refactoring_introducing_login_strategy.patch -> small refactoring
that introduces JabberLoginStrategy

- Although I said unit tests are not important, I'd prefer to avoid code
that makes testing more difficult if we ever want to add tests: the static
factory method. Can we just make the strategy classes public and use the
constructor?
- If applying the former: make the JabberLoginStrategy an interface
- Move the strategy classes into their own files, perhaps even a package (I
don't have a preference on this)
- Use XyzStrategy as class name

Technically I guess I'm okay with it.

2) client_cert_support.patch -> patch that enables client certificates
(it integrates into the XMPP configuration dialog)

- The case of an PKCS#11 library for the client cert is not handled. If we
can move to the SSLContext injection, this is automatically solved.
- I saw an "Apple" keychain in the Smack library. We don't support that yet,
but it would be another thing to duplicate in the CertService and the XMPP
cert stuff.
- The code copy from the sip wizard is okay, no need for a todo unless you
really intend to generalize the two implementations

- You return null in prepareLogin. What happens when the
IceUdpTransportManager kicks in and wants the password? If I read the code
correctly, it asks the user for a password again, which would certainly not
be intended.

@the other devs: Could that ICE/TURN/STUN stuff even accept something with a
certificate??

Feedback to the patches is highly welcome!

I hope I don't sound too rude with the above, I know I sometimes am...

Regards
Stefan

Ingo

[1] https://jitsi.org/index.php/Documentation/CodeConvention
[2] http://bluejimp.com/bca.pdf

XMPPConnextion-SSLContext.patch (2.31 KB)


#20

[1]
http://blog.spiderlabs.com/2011/04/certificate-revocation-behavior-in-modern
-browsers.html

From: Ingo Bauersachs [mailto:ingo@sip-communicator.org] On Behalf Of Ingo
Bauersachs
Sent: Freitag, 7. Dezember 2012 00:19
To: dev@jitsi.java.net
Cc: buddy.butterfly@web.de
Subject: [jitsi-dev] Re: TLS Client Certificate Support for XMPP
Hey

I just committed a change that allows you to configure the CRL and OCSP
checking in the TLS configuration advanced options panel. They are

currently

not enabled by default, but we (the other devs) can discuss to enable the
CRL checking.

As I consider the OCSP-Implementation of Java to be broken, enabling that

by

default is currently not an option. Broken means that it causes validation
failures on perfectly valid certificates. About the sense of OCSP in
general, you might want to read this [1] blog post. I know it's a bit

dated,

but the problems still apply.

Thanks for noting that those stuff is not enabled by default!

Regards,
Ingo

--- snip ---

Support for the CRL Distribution Points Extension

Support for the CRL Distribution Points extension is available. It is
disabled by default for compatibility and can be enabled by setting the
system property com.sun.security.enableCRLDP to the value true.

If set to true, Sun's PKIX implementation uses the information in a
certificate's CRL Distribution Points extension (in addition to

CertStores

that are specified) to find the CRL, provided the distribution point is

an

X.500 distinguished name or a URI of type ldap, http, or ftp.

--- snap ---

So both, CRL distribution point and OCSP are disabled by default.

Best regards,
Matt

  Hi Ingo,

  ok, here you got me. Did not look into the code, just wanted to
  point out its importance. So

  1. JCA has "ocsp.enable" false by default.

  2. Properties like "ocsp.enable" can be set dynamically via
  java.security.Security.setProperty(). I did not find any option
for that on the GUI.

  So, a quick look at documentation showed that there is support for
OCSP in JCA, it just should be configurable. CRL handling on the

other

hand is not very clear and would need some testing to reveal.

Though,

Appendix B: The "SUN" provider states: " It does not implement
support for the freshest CRL or ..." which I understand as
  implementing a CRL verification against the CRL cache but no online
  retrieval by default. From this it looks like OCSP would be nice

to

enable. It can also be done Java wide in the security options.

  Best regards,
  Matt

    Hey

      thanks for reply. Sry, but it was too early today

for me and I

overlooked the "TLS Client" ;-). I immediately corrected this

with

a reply to my own mail.

    I saw your second mail, but replied anyway because of the

CRL stuff.

      As long as I know there is probably support for CRL

verification

      but it will not happen automatically. Unfortunately

the whole PKI

is mostly driven by organizational / manual decisions.

    Sorry, I don't get what you mean. Could you elaborate that a

bit more?

      So to have at least a base minimum on security, the

check for the

      validity of the certificate is necessary. And, if I

remember it

      right, the CRL (Certificate Revocation List)

distribution points

      are even optional in X509. And in general nowadays

we talk about the

      OCSP (Online Certificate Status Protocol) which is

implemented in

      most browsers.

    Jitsi uses the TLS infrastructure of the Java Cryptography

API and as

such checks validity, CA certificates, CRLs, the CA-chain

flags,
the

necessary certificate usage flags and as far as I know also

the OCSP.

In addition to Java's certificate check, we validate the

certificate

against the hostname (which is what most applications

using Java's

API forget).

      In Firefox you can find the example in

          Properties->Advanced->Encryption->Validation

There it is

specified to validate the certificate if it contains an

OCSP-Server

or a manually configured one can be given.

    We don't have an option to explicitly enable or disable

OCSP, but you

can try to override settings manually with Java's ocsp.XYZ

system

properties.

    Have you noticed that something is not working as expected?

      Best regards,
      Matt

        Hey

          good idea. Just a reminder. In terms

of security CRL service

(configurable) and client certificate authentication

is necessary.

        The client certificate that Stefan wants to
implement needs to be
        checked on the server side.

          CRL: TLS client has to read

certificate distribution points in

server cetificates and contact the

distribution points to see if

certificate is still valid or has

been revoked. If not provided in

certificate manual configuration of

distribution points would be

desirable. This implies technical

connectivity to different

services like http, ldap (directory

service) etc.

        We rely on the Java cryptography

infrastructure to do that. If you

find errors in our usage of the API

however, I'd be happy to fix

them.

          Client certificate:

Client has private key and client

certificate which then in turn is

required from server to

authenticate. This is like in the common browsers where you

import

a .p12 containing private key and

certificate to authenticate to a

secure side.

        That's exactly what we're talking about, and

it's already there for

SIP.

          When it must be prioritized, CRL has

much more priority as one has

to validate if

server certificate is still valid or has been

compromised. We all have heard of the

crappy safety of CA

···

-----Original Message-----
Buddy Butterfly wrote on 2012-12-05: >> Hi, >> >> ok, JCA also supports the CRL distribution points but they are also >> disabled by default:

Am 05.12.2012 16:09, schrieb Buddy Butterfly:
  Am 05.12.2012 15:38, schrieb Ingo Bauersachs:
      Am 05.12.2012 15:10, schrieb Ingo Bauersachs:
authorities out there, so the more important this

    is!

          Best regards,
          Matt

        Regards,
        Ingo