Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't send phone number hashes in plain text #498

Open
chaos095 opened this issue Jul 7, 2015 · 9 comments
Open

Don't send phone number hashes in plain text #498

chaos095 opened this issue Jul 7, 2015 · 9 comments
Labels
enhancement New feature or request

Comments

@chaos095
Copy link

chaos095 commented Jul 7, 2015

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 [email protected].
Why is this part of the communication not encrypted? Combined with issue #497, the situation is bad.

@daniele-athome daniele-athome added the invalid This doesn't seem right label Jul 8, 2015
@daniele-athome
Copy link
Member

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.

@daniele-athome daniele-athome self-assigned this Jul 8, 2015
@abika
Copy link
Member

abika commented Jul 8, 2015

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
Copy link
Member

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
Copy link
Member

abika commented Jul 8, 2015

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
Copy link
Member

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
Copy link
Member

abika commented Jul 8, 2015

Yes.

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

@daniele-athome
Copy link
Member

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
Copy link
Author

chaos095 commented Jul 8, 2015

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.

@daniele-athome daniele-athome added enhancement New feature or request and removed invalid This doesn't seem right labels Jul 9, 2015
@daniele-athome daniele-athome added this to the 4.0 milestone Jul 9, 2015
@daniele-athome daniele-athome removed their assignment Jul 9, 2015
@daniele-athome
Copy link
Member

The Kontalk web page advertises "Encrypted Encrypted everywhere." as first item, which I find misleading.

Fair enough.

I also have to see if Tigase supports that. Maybe renegotiating TLS will not need a stream reset.

@daniele-athome daniele-athome removed this from the Future milestone Nov 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants