[Security] TLS Certificates Verification

Dirk Meyer dmeyer at tzi.de
Wed Aug 20 08:15:35 CDT 2008


Johansson Olle E wrote:
> Ok, let's use this thread and subject for that discussion and try to
> summarize where we are.

We have "XEP-0174: Serverless Messaging" and "XEP-0247: Jingle XML
Streams" to open a e2e connection. How this is done is up to Jingle
out of scope for this subthread. On top of that stream we use
"XEP-0246: End-to-End XML Streams". In this step we use starttls to
secure the connection. This is the scenario for this summary.

1. Enterprise use case when XMPP is used as middleware: TLS uses
   certificates signed by a CA. No human interaction needed except
   providing the certificates. It is complicated but IMHO the way a
   company would use e2e.

2. For end-users like my mother a CA is too complex. Even the concept
   is kind of strange why you trust someone you do not know. This
   results in clients having self-signed certificates.

3. RFC 5054 SRP can be used to set TLS without valid certificates. It
   requires a username and a password. We do not share a username
   between client so this has to be set to some simple default. The
   password is the shared secret.

4. After SRP we can rehandshake and now know the public key and
   fingerprint of the peers certificate. Store it for later use.

5. Bots may have predefined secrets, e.g. printed on the back of the
   set-top box.

6. A user may have different certificates for each client. He could
   sign each of these certificates with a CA he created, but again:
   too complicated. We could update XEP-0189: "Public Key Publishing"
   to publish all client keys of a user signed by the user key.

7. We also could create some sort of web of trust based on XEP-189. If
   I trust you and just trust Peter maybe I do not want to go through
   SRP and just believe it is Peter because you said so.

8. If you loose the private part of your user key you are lost.
   Guidelines how to help the user not to loose it are out of the
   scope of this subthread. In this subthread we know we have the user
   key.


Open Issues:

1. To to update a certificate? They have an expire date so I need
   create a new self-signed certificate from time to time. Maybe
   XEP-189 can help here.


SRP Usage:

Maybe I'm reading the doc wrong and I have no idea if openssl and
friends support the following guidelines. The question is: when to use
SRP and when to use public keys.

1. Sending ClientHello
   a. If I connect to someone I do not know, I only add SRP ciphers. I
      will refuse anything except SRP.

   b. If I know the other side I also add "normal" ciphers.

   c. If I am a bot and know the other side I only provide normal
      ciphers and hope that it will work.

2. When I get a request with SRP and normal ciphers I can choose.

   a. If I know the peer based on the JID I could continue normal TLS
      (Question: Is this possible? I do not see anything against it in
      the RFS).

   b. When I do not know the users public key, I want to use SRP and
      send unknown_psk_identity as described in 2.5.1.2. of the
      RFC. We start again (on TLS level) and the users have to provide
      a key.

3. When I get a request without SRP and I can not verify the
   certificate TLS fails.


Dirk

-- 
Computer analyst to programmer: "You start coding. I'll go
find out what they want."


More information about the Security mailing list