Don't send phone number hashes in plain text

[chaos095]

Whenever I connect to Wi-Fi, kontalk contacts the server and sends my kontalk ID in plain text. (This happens after the SSL handshake.) The string "OpenPGP to X.509 Bridge" is visible, a little later my nickname followed by my kontalk user ID in the form phone-number-hash@beta.kontalk.net.
Why is this part of the communication not encrypted? Combined with issue #497, the situation is bad.

[daniele-athome]

That is part of the SSL handshake which is used for authentication. Only the username and the public key gets through cleartext while handshaking, that's normal. Those information must be inside the certificate, otherwise it's impossible to authenticate safely.

[abika]

I don't wanna annoy with demanding more workload for you, but it would definitely be better if the client credentials are send encrypted.

However, reading about this in RFC6120 (Chapter 5.3.5., third case) it doesn't look easy to accomplish if Smack and/or Tigase doesn't support it and would always come with the cost of more network traffic.

So, giving it low priority, if it can't be solved easily, I guess this will have to stay as a little blemish.

[daniele-athome]

I think we are talking about different things here. The only step when the userid is transmitted in cleartext is the SSL handshake: before exchanging the keys, the peers exchange their certificates (but since they are going to verify it moments after that, it's safe to transmit in cleartext - safe as in verifiable). The client certificate has the PGP public key block inside it to allow for SSL authentication bridged to a X.509 certificate because of the lack of implementations for RFC 6091. After that step, all traffic is encrypted.
Therefore, I don't understand how you, @chaos095, could say:

(This happens after the SSL handshake.)

However, right after that you say:

The string "OpenPGP to X.509 Bridge" is visible

That string is part of the X.509 certificate I was talking about, so SSL handshake was just beginning at that time.

@abika you're talking about STARTTLS, but before <bind/> (which happens way after the SSL handshake) there is not indication of the userid (except for the aforementioned SSL handshake of course) passing through the channel - correct me if I'm wrong of course, I don't have papers in my hands right now, just using my own memory.

[abika]

Very complicated. What I see by sniffing the packets during connection is exactly as described in XEP 0178 until step 6:

• client and server start the <stream>
• server sends <stream:features>
• client sends <starttls>, server <proceed>

And now the SSL handshake aka TLS negotiation occurs, where the client sends his x.509 login certificate in plain text.

[daniele-athome]

Very complicated. What I see by sniffing the packets during connection is exactly as described in XEP 0178

That's right. Until the beginning of the SSL handshake no userid goes through the wire.

[abika]

Yes.

And Im afraid the user ID must be included in the certificate?

[daniele-athome]

Yes. The whole public key is included. The server needs to verify that the public key included in the certificate is signed by the private key linked to the X.509 certificate (which in turn is based on the same cryptographic parameters of the PGP private key). It's a trick to bind an OpenPGP key pair to a X.509 certificate.

[chaos095]

That is part of the SSL handshake which is used for authentication. Only the username and the public key gets through cleartext while handshaking, that's normal. Those information must be inside the certificate, otherwise it's impossible to authenticate safely.

@abika pointed out that it should be possible to set up an encrypted channel first, where only the server is authenticated, according to RFC6120, Sec 5.3.5. Then the client certificate could be transferred as ciphertext as part of a TLS Renegotiation. I don't understand your, @daniele-athome, answer concerning bind to @abika.

Therefore, I don't understand how you, @chaos095, could say:

(This happens after the SSL handshake.)

You are right. I meant: "After starttls".

In any case, I'd like to suggest to document (prominently) such a plaintext transmission of user identities. The Kontalk web page advertises "Encrypted Encrypted everywhere." as first item, which I find misleading.