-
Notifications
You must be signed in to change notification settings - Fork 194
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
Comments
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. |
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. |
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.
However, right after that you say:
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 |
Very complicated. What I see by sniffing the packets during connection is exactly as described in XEP 0178 until step 6:
And now the SSL handshake aka TLS negotiation occurs, where the client sends his x.509 login certificate in plain text. |
That's right. Until the beginning of the SSL handshake no userid goes through the wire. |
Yes. And Im afraid the user ID must be included in the certificate? |
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. |
@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.
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. |
Fair enough. I also have to see if Tigase supports that. Maybe renegotiating TLS will not need a stream reset. |
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.
The text was updated successfully, but these errors were encountered: