[jitsi-dev] Re: TLS Configuration Dialogs


#1

На 19.08.11 00:58, Bauersachs Ingo написа:

You mean it's ready? That's awesome!!!!! Mucho cooool! :slight_smile:

I can authenticate against my local Kamailio with the configured
certificates. So, yeah :slight_smile:

Niiiiiiice :slight_smile: This is awesome!

This is just the signalling part though ... right? Or does this
also include the SDES?

That is just logging in at a proxy/registrar with a TLS client
certificate, nothing about voice encryption at all (yet, that's what
I'm attacking next).

OK, cool!

Also .. what's that thing with the smartcard there? Does it allow
reading a certificate from a card? How does it access it?

Yepp, it reads SmartCards (the selected entry SuisseID is actually a
SmartCard too). You can supply the .dll/.so of your PKCS#11 interface
as the keystore file. Java then accesses it through a JNI wrapper
(already included with the JRE) as a regular KeyStore.

Eeeer ... didn't get that. Who provides the .dll/.so? Is it part of or
somehow referenced by the the PFX file that I see in your third
screenshot in the previous mail?

A few quick thoughts:

1. Empty option on the first image should probably have a name?
E.g. "regular authentication" or "don't use a certificate" or
something like that. An empty entry seems somewhat ambiguous to
me.

Yepp, I'll create that.

2. There seems to be a problem with the transparency in the panel
with the trusted root certificates source (second image).

Right, I saw that earlier and thought it magically disappeared. But
it's obviously just the crappy LCD in my notebook... Guess I have to
create a SIPCommRadioButton? Or is that thing already around
somewhere?

Yeah. I believe the SIPCommXXX components address that. Yana will
correct if I am wrong (maybe later though ... she must be half way
through the Atlantic now)

3. I think we could add a bit more text here too. Rather than just
saying they could be used for account configuration (which I am
afraid may sound somewhat cryptic to many uses), you might want to
give an example. Something like "... you can use these certificates
when authenticating with your SIP server for example or securing
your communication with it". WDYT?

What about: "The configurations managed here can be chosen as client
TLS certificates in the account configurations (e.g. to authenticate
with a certificate against your SIP provider instead of a username
and password)."

OK sounds fine to me.

Emil


#2

Eeeer ... didn't get that. Who provides the .dll/.so? Is it part of or
somehow referenced by the the PFX file that I see in your third
screenshot in the previous mail?

The SmartCard supplier. You usually get a bunch of additional software with SmartCards, part of it being a PKCS#11 provider. You have to have the same .dll/.so to access SmartCards from within e.g. Firefox.

PFXs are files that contain the certificate (public part), the private key, and possibly the certificate chain of the signers. The related standard is PKCS#12. They have nothing to do with the SmartCards.

Ingo


#3

What I mostly wanted to know is whether the shared lib has to be made
available to Jitsi in some way.

Basically you are saying that it is up to the supplier or an admin to make
sure that they are properly installed and present on PATH/LD_LIBRARY_PATH
for the JRE to find. Is that it?

You can place it anywhere you like as long as you have the permission to read the file. If it's available somewhere on the system, fine, just point a configuration entry to it. There is no way for me or Java to know which lib should be loaded for which SmartCard.

(This is why Windows has CAPI: it abstracts all that stuff away. You have a central store to access certificates. And sadly, SUN/Oracle is incapable of fixing the bugs in their provider to actually use it from within Java for anything else than the truststore).

Ingo


#4

На 19.08.11 02:00, Bauersachs Ingo написа:

What I mostly wanted to know is whether the shared lib has to be
made available to Jitsi in some way.

Basically you are saying that it is up to the supplier or an admin
to make sure that they are properly installed and present on
PATH/LD_LIBRARY_PATH for the JRE to find. Is that it?

You can place it anywhere you like as long as you have the permission

I am sorry, I am not being clear enough (or I am completely missing your
point). My only concern here was:

Does Jitsi need to know about these files?

If yes, then we need to add the forms that would allow users to point to
them. Otherwise, we are fine.

to read the file. If it's available somewhere on the system, fine,
just point a configuration entry to it.

This is what confuses me. What configuration entry are you referring to?
Who needs to be configured to do what?

Emil

···

There is no way for me or
Java to know which lib should be loaded for which SmartCard.

(This is why Windows has CAPI: it abstracts all that stuff away. You
have a central store to access certificates. And sadly, SUN/Oracle is
incapable of fixing the bugs in their provider to actually use it
from within Java for anything else than the truststore).


#5

You can place it anywhere you like as long as you have the permission

I am sorry, I am not being clear enough (or I am completely missing your
point). My only concern here was:

Does Jitsi need to know about these files?

Yes.

If yes, then we need to add the forms that would allow users to point to
them. Otherwise, we are fine.

That is exactly what the new TLS configuration plugin does :slight_smile:
See the attached screenshot with the configuration for my SuisseID SmartCard.

to read the file. If it's available somewhere on the system, fine,
just point a configuration entry to it.

This is what confuses me. What configuration entry are you referring to?
Who needs to be configured to do what?

You need to create an entry in the TLS configuration advanced panel. See the screenshot "TLS_configuration.png" from my first mail.

Ingo


#6

На 19.08.11 09:20, Bauersachs Ingo написа:

You can place it anywhere you like as long as you have the permission

I am sorry, I am not being clear enough (or I am completely missing your
point). My only concern here was:

Does Jitsi need to know about these files?

Yes.

If yes, then we need to add the forms that would allow users to point to
them. Otherwise, we are fine.

That is exactly what the new TLS configuration plugin does :slight_smile:
See the attached screenshot with the configuration for my SuisseID SmartCard.

Cool that's exactly what I needed to hear. It didn't immediately dawn on
me that the field that contained a pfx in your first example can also
take DLLs.

We might want to add a short example a description underneath it. WDYT?

Emil

···

to read the file. If it's available somewhere on the system, fine,
just point a configuration entry to it.

This is what confuses me. What configuration entry are you referring to?
Who needs to be configured to do what?

You need to create an entry in the TLS configuration advanced panel. See the screenshot "TLS_configuration.png" from my first mail.

Ingo

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


#7

Dear all,

some thoughts about the TLS stuff.

After looking at the dialogs (attached PNG files in the first e-mail)
I'm really asking myself: who are the target users/audience for this feature?
Who, except security aware people, can deal with this? Joe or Jane Public
don't really understand what's going on here. Most users, not even many
computer admins can deal with terms like PKCS11, PKSC12. What is a
"client TLS certificate" they will ask? What are these long, strange
looking numbers in a key store? Etc. And IMHO they start to feel
uneasy.

IMHO we are going to compromise the "simple-to-use" concept than enables
an ordinary, non-computer aware user to use Jitsi.

Yana did a good job to hide the ZRTP configuration, we use a sensible
default setting and do not bother the user with annoying details. And with
TLS we now introduce an even more complex scenario.

Certificate based security is complex: for example I've not seen how to
manage or display certificates in terms of certificate revocation,
introducing new certificates, deleting old certificates, or display and
verify a certificate in case of problems, e.g. a root certificate is not
in the main key store.

Do we rely on Windows or Java certificate management - one of the screen
shots indicates this? In such a case usually a system administrator is
required because these "management" programs require admin/root access.
Hopefully we are not going to use the Java command line keystore management,
aren't we?

Or is it planned to have this whole stuff in a _very_ specific "expert mode"
only? Again: who are the target users / audience? Can we expect that these
users are trained security people that know most of this and know how to
deal with certificates, client certificates in particular?

Don't get me wrong: I'm very much in favor to have security featurs but the
overall stuff must be easy to use, must not require specific user know-how,
and shall not be intrusive. Maintaining TLS certificates will
definitely ask too much of a normal user (and of most sys admins as well).

Best regards,
Werner

···

Am 19.08.2011 09:56, schrieb Emil Ivov:

На 19.08.11 09:20, Bauersachs Ingo написа:

You can place it anywhere you like as long as you have the permission

I am sorry, I am not being clear enough (or I am completely missing your
point). My only concern here was:

Does Jitsi need to know about these files?

Yes.

If yes, then we need to add the forms that would allow users to point to
them. Otherwise, we are fine.

That is exactly what the new TLS configuration plugin does :slight_smile:
See the attached screenshot with the configuration for my SuisseID SmartCard.

Cool that's exactly what I needed to hear. It didn't immediately dawn on
me that the field that contained a pfx in your first example can also
take DLLs.

We might want to add a short example a description underneath it. WDYT?

Emil

to read the file. If it's available somewhere on the system, fine,
just point a configuration entry to it.

This is what confuses me. What configuration entry are you referring to?
Who needs to be configured to do what?

You need to create an entry in the TLS configuration advanced panel. See the screenshot "TLS_configuration.png" from my first mail.

Ingo


#8

some thoughts about the TLS stuff.

Thanks for your input!

After looking at the dialogs (attached PNG files in the first e-mail)
I'm really asking myself: who are the target users/audience for this
feature?

I developed this as part of a university project so, apart from a request from a user on the dev list back in February, there is probably not much demand. But companies that deploy Jitsi inside their organization might still be interested.

Who, except security aware people, can deal with this? Joe or
Jane Public don't really understand what's going on here. Most users,
not even many computer admins can deal with terms like PKCS11, PKSC12.
What is a "client TLS certificate" they will ask? What are these long,
strange looking numbers in a key store? Etc. And IMHO they start to feel
uneasy.

IMHO we are going to compromise the "simple-to-use" concept than enables
an ordinary, non-computer aware user to use Jitsi.

Yana did a good job to hide the ZRTP configuration, we use a sensible
default setting and do not bother the user with annoying details. And with
TLS we now introduce an even more complex scenario.

The defaults all stay the same, so the ordinary use doesn’t have to care about anything of that. He can even completely ignore the advanced configuration panels. After all, they wear the name "Advanced" for purpose.
The Combobox to select a template might be confusing, I agree here. But so might be anything else in that dialog. For example, why is the authorization name located below the registrar, but the password on the first tab? They are related. Maybe the whole design of the SIP Wizard should be reconsidered.

Certificate based security is complex: for example I've not seen how to
manage or display certificates in terms of certificate revocation,
introducing new certificates, deleting old certificates, or display and
verify a certificate in case of problems, e.g. a root certificate is not
in the main key store.

Indeed. A regular end user might be capable of using a SmartCard (like the SuisseID or the ePerso), which takes care of the distribution. Inside a company the distribution is the job of the admin who deploys Jitsi.
Adding a root certificate to the truststore can either happen by including it in cacerts (all platforms) or in the system cert store (Windows only currently). Distribution of an internal root certificate might therefore be done using Active Directory.

Do we rely on Windows or Java certificate management - one of the screen
shots indicates this? In such a case usually a system administrator is
required because these "management" programs require admin/root access.
Hopefully we are not going to use the Java command line keystore
management, aren't we?

Sadly, Java's provider for CAPI is incapable of using private keys from CAPI for signing, therefore we have to rely on Java. The thing you have seen in the screenshot is only the source of the trusted root certificates. Settings this to "Windows" should take care of this feature request/bug report: http://java.net/jira/browse/JITSI-944

For the client certificates, it might be a SmartCard through a PKCS#11 provider (.dll/.so), .pfx's and the obvious Java keystore with keytool.

Or is it planned to have this whole stuff in a _very_ specific "expert
mode" only? Again: who are the target users / audience? Can we expect
that these users are trained security people that know most of this and
know how to deal with certificates, client certificates in particular?

Well, isn't the advanced config the expert mode? You could argue the same for the Parallel DNS panel, Provisioning, LDAP, ...
But it is definitely oriented amongst expert users. I actually haven't even found a public provider that provides SIP over TLS.

Don't get me wrong: I'm very much in favor to have security featurs but
the overall stuff must be easy to use, must not require specific user
know- how, and shall not be intrusive. Maintaining TLS certificates will
definitely ask too much of a normal user (and of most sys admins as
well).

Do you have an idea how to hide the client TLS certificate options in a way that an experienced/interested user can still find them?

Cu,
Ingo


#9

RE:

Do you have an idea how to hide the client TLS certificate options in a way that an experienced/interested user can still find them?

I suggest the same way as many programs do it:
A button marked "advanced users only".

Regards, Earl

···

On 8/19/2011 7:31 PM, Bauersachs Ingo wrote:

some thoughts about the TLS stuff.

Thanks for your input!

After looking at the dialogs (attached PNG files in the first e-mail)
I'm really asking myself: who are the target users/audience for this
feature?

I developed this as part of a university project so, apart from a request from a user on the dev list back in February, there is probably not much demand. But companies that deploy Jitsi inside their organization might still be interested.

Who, except security aware people, can deal with this? Joe or
Jane Public don't really understand what's going on here. Most users,
not even many computer admins can deal with terms like PKCS11, PKSC12.
What is a "client TLS certificate" they will ask? What are these long,
strange looking numbers in a key store? Etc. And IMHO they start to feel
uneasy.

IMHO we are going to compromise the "simple-to-use" concept than enables
an ordinary, non-computer aware user to use Jitsi.

Yana did a good job to hide the ZRTP configuration, we use a sensible
default setting and do not bother the user with annoying details. And with
TLS we now introduce an even more complex scenario.

The defaults all stay the same, so the ordinary use doesn’t have to care about anything of that. He can even completely ignore the advanced configuration panels. After all, they wear the name "Advanced" for purpose.
The Combobox to select a template might be confusing, I agree here. But so might be anything else in that dialog. For example, why is the authorization name located below the registrar, but the password on the first tab? They are related. Maybe the whole design of the SIP Wizard should be reconsidered.

Certificate based security is complex: for example I've not seen how to
manage or display certificates in terms of certificate revocation,
introducing new certificates, deleting old certificates, or display and
verify a certificate in case of problems, e.g. a root certificate is not
in the main key store.

Indeed. A regular end user might be capable of using a SmartCard (like the SuisseID or the ePerso), which takes care of the distribution. Inside a company the distribution is the job of the admin who deploys Jitsi.
Adding a root certificate to the truststore can either happen by including it in cacerts (all platforms) or in the system cert store (Windows only currently). Distribution of an internal root certificate might therefore be done using Active Directory.

Do we rely on Windows or Java certificate management - one of the screen
shots indicates this? In such a case usually a system administrator is
required because these "management" programs require admin/root access.
Hopefully we are not going to use the Java command line keystore
management, aren't we?

Sadly, Java's provider for CAPI is incapable of using private keys from CAPI for signing, therefore we have to rely on Java. The thing you have seen in the screenshot is only the source of the trusted root certificates. Settings this to "Windows" should take care of this feature request/bug report: http://java.net/jira/browse/JITSI-944

For the client certificates, it might be a SmartCard through a PKCS#11 provider (.dll/.so), .pfx's and the obvious Java keystore with keytool.

Or is it planned to have this whole stuff in a _very_ specific "expert
mode" only? Again: who are the target users / audience? Can we expect
that these users are trained security people that know most of this and
know how to deal with certificates, client certificates in particular?

Well, isn't the advanced config the expert mode? You could argue the same for the Parallel DNS panel, Provisioning, LDAP, ...
But it is definitely oriented amongst expert users. I actually haven't even found a public provider that provides SIP over TLS.

Don't get me wrong: I'm very much in favor to have security featurs but
the overall stuff must be easy to use, must not require specific user
know- how, and shall not be intrusive. Maintaining TLS certificates will
definitely ask too much of a normal user (and of most sys admins as
well).

Do you have an idea how to hide the client TLS certificate options in a way that an experienced/interested user can still find them?

Cu,
Ingo