3 ms·

Sorry, but doesn't the client check the published keys itself? According to this document the client verifies the key that has been published on twitter or whe

by ahnick 7y ago

Sorry, but doesn't the client check the published keys itself? According to this document the client verifies the key that has been published on twitter or wherever else the user you are interacting with has publicly confirmed his/her identity. https://keybase.io/docs/server_security/following https://keybase.io/docs/server_security/following My understanding is in the event of a server compromise in the beginning then the fake public key for the user that the malicious server would be sending would be easily detectable due to this client side check that is occurring. Whoever is behind the MITM attack would also have to compromise Twitter and all other places the user you are chatting with has published, no?

lucb1e 7y ago
I didn't connect my account to Twitter or HN or anything, I just have a Keybase account to chat with a friend and wanted to check whether it's secure. I guess this could work though, from the app I can indeed configure third party accounts (I guess in some next step, it'll tell me what to tweet to prove it). Assuming my phone generates the proof locally, that would prove it without doing manual verification, unless both Keybase and Twitter collude to attack us (or an attacker compromised both or sent NSLs to both), so that seems extremely unlikely. Does the Keybase client check this by itself though? It seems a bit odd, the app connecting to third parties, but it could be. Like, I'd find out your IP address by adding a website proof where I host a text file. We can test this if you want? Then I'll pcap my phone and see, while adding you, if my client connects to whatever third party you have configured.
- ahnick 7y ago
  Yes, supposedly the client scrapes it using the website. They have a number of third party integrations they do this for. It's actually a point of contention for them to add more third parties within the community. (People wanted LinkedIn and various other services) Going forward they want it to be the other way around and have third parties to start integrating with Keybase. (https://keybase.io/docs/proof_integration_guide https://keybase.io/docs/proof_integration_guide) Yeah, feel free to message me to test it out. My proof on twitter is here -> https://twitter.com/xan_nick/status/860495425920524290 https://twitter.com/xan_nick/status/860495425920524290. You should also see it verify my HN and github, which I also have connected. (https://keybase.io/ahnick https://keybase.io/ahnick) Definitely interested in your results.
  - lucb1e 7y ago
    I ran the test. What I did was run `tcpdump -i wlan0 -w /tmp/pcap` on my phone as root. I deliberately waited searching your username in the Keybase app until after starting the packet capture, so it couldn't have fetched your keys already. I also didn't add anyone else for at least a few weeks. After starting the capture, I searched your username, hit connect, and stopped the capture only once it was done connecting and it proudly claimed that this chat is end to end encrypted (this took a few seconds). I looked at two things: DNS results in case there is a quick win (like a lookup for Twitter) using `tshark -e dns.qry.name -Tfields -r /tmp/pcap | sort -u`, and when there was no Twitter lookup to be found, I looked into IP traffic using `tshark -r /tmp/pcap -e ip.dst -e ip.src -Tfields | tr \\t \\n | sort -u`. None of the IP addresses belong to Twitter in terms of reverse lookup or whois info. Since api.twitter.com (like *.twitter.com, as far as I can find) is hosted in its own IP range, that pretty much concludes the test already, but I dug into each IP address just in case they use some endpoint I don't know about. The only IP which it talked to in the right time window and I couldn't attribute to a particular app was 52.216.100.45, which (SNI tells me) is AWS S3. Does Twitter uses AWS S3 and does Keybase connect to that directly without going through api.twitter.com? Seems strange. The other IP addresses my phone talked to in the right time window are either pre-established connections (it would have to keep a permanent connection open to Twitter, and since I didn't add anyone for a while, that would mean it keeps a connection to Twitter open whenever I open the app... I would say we can rule that out) or attributable to other apps like Spotify (I am indeed playing music). TL;DR it doesn't seem to check your Twitter proof.
    - Gaelan 7y ago
      It looks like Keybase is using mobile.twitter.com. I just ran `sudo tcpdump -x host mobile.twitter.com` while browsing to ahnick's profile in the Keybase app on my Mac, and got a flurry of activity. It doesn't seem to do that if I just start a chat, however—it only happens if I pull up his profile (i.e. the screen that lists his Twitter account).
      - lucb1e 7y ago
        I guess it's good to know that it checks it in response to random actions, even if not when establishing a self-proclaimed end to end encrypted chat :P Btw mobile.twitter.com is also hosted in their own range (104.244.40.0/21), so I would have spotted that if it had been contacted when I tested it.
- nindwen 7y ago
  I don't know why it seems odd to you, it is literally what Keybase has been about since its start: the point is that you can bootstrap trust by linking to multiple already known identities (like twitter, hn, github) in a secure way. Even if you dislike all the other things Keybase has done since, this is a significant improvement over web-of-trust or TOFU. It should be trivially verifiable by yourself: just watch what requests your device is making. And the app itself is open source, so you should be able to trust it.
  - lucb1e 7y ago
    Edit: this comment can be ignored since it doesn't seem to verify third party proofs in the first place. As far as I can tell, it just queries the Keybase servers and calls it a day, so the trust anchor is still only Keybase unless I overlooked something. More details in my other comment: https://news.ycombinator.com/item?id=21748454 https://news.ycombinator.com/item?id=21748454 --- > It should be trivially verifiable by yourself Yeah sure, once you realize that third parties are required for security. This shifts the root of trust from just Keybase to Keybase + a third party. That's not quite what I would call end to end encryption, at least not if there is no fallback to checking the keys manually. That's just not what the word means to me, even if the risk is sufficiently low that I guess it can be considered equivalent. So I'm not saying it's a bad thing. If indeed all chat apps had such a scheme where third parties vet the keys, i.e. if it were commonplace to have to compromise two or more companies' servers before you can MITM someone successfully, it would be a huge improvement over the current state. Keybase is definitely being innovative here. It's just not how it's marketed (namely as being a secure chat in and of itself), and I hadn't realized that this might be what they mean when they write "end to end encrypted [but only if you sign up with a trusted third party!]".
    - Gaelan 7y ago
      IIRC a PGP key is one of the “third parties” you can attach to your account, so assuming that the app checks those, you could get verifiable E2E that way. I’m also quite surprised by your findings about Keybase not checking verifications—my impression from their marketing/docs was that they made a point of doing that. I’m not in front of a computer right now, but will look more into it later.

by ahnick 7y ago

lucb1e 7y ago

I didn't connect my account to Twitter or HN or anything, I just have a Keybase account to chat with a friend and wanted to check whether it's secure. I guess this could work though, from the app I can indeed configure third party accounts (I guess in some next step, it'll tell me what to tweet to prove it). Assuming my phone generates the proof locally, that would prove it without doing manual verification, unless both Keybase and Twitter collude to attack us (or an attacker compromised both or sent NSLs to both), so that seems extremely unlikely. Does the Keybase client check this by itself though? It seems a bit odd, the app connecting to third parties, but it could be. Like, I'd find out your IP address by adding a website proof where I host a text file. We can test this if you want? Then I'll pcap my phone and see, while adding you, if my client connects to whatever third party you have configured.

ahnick 7y ago
Yes, supposedly the client scrapes it using the website. They have a number of third party integrations they do this for. It's actually a point of contention for them to add more third parties within the community. (People wanted LinkedIn and various other services) Going forward they want it to be the other way around and have third parties to start integrating with Keybase. (https://keybase.io/docs/proof_integration_guide https://keybase.io/docs/proof_integration_guide) Yeah, feel free to message me to test it out. My proof on twitter is here -> https://twitter.com/xan_nick/status/860495425920524290 https://twitter.com/xan_nick/status/860495425920524290. You should also see it verify my HN and github, which I also have connected. (https://keybase.io/ahnick https://keybase.io/ahnick) Definitely interested in your results.
- lucb1e 7y ago
  I ran the test. What I did was run `tcpdump -i wlan0 -w /tmp/pcap` on my phone as root. I deliberately waited searching your username in the Keybase app until after starting the packet capture, so it couldn't have fetched your keys already. I also didn't add anyone else for at least a few weeks. After starting the capture, I searched your username, hit connect, and stopped the capture only once it was done connecting and it proudly claimed that this chat is end to end encrypted (this took a few seconds). I looked at two things: DNS results in case there is a quick win (like a lookup for Twitter) using `tshark -e dns.qry.name -Tfields -r /tmp/pcap | sort -u`, and when there was no Twitter lookup to be found, I looked into IP traffic using `tshark -r /tmp/pcap -e ip.dst -e ip.src -Tfields | tr \\t \\n | sort -u`. None of the IP addresses belong to Twitter in terms of reverse lookup or whois info. Since api.twitter.com (like *.twitter.com, as far as I can find) is hosted in its own IP range, that pretty much concludes the test already, but I dug into each IP address just in case they use some endpoint I don't know about. The only IP which it talked to in the right time window and I couldn't attribute to a particular app was 52.216.100.45, which (SNI tells me) is AWS S3. Does Twitter uses AWS S3 and does Keybase connect to that directly without going through api.twitter.com? Seems strange. The other IP addresses my phone talked to in the right time window are either pre-established connections (it would have to keep a permanent connection open to Twitter, and since I didn't add anyone for a while, that would mean it keeps a connection to Twitter open whenever I open the app... I would say we can rule that out) or attributable to other apps like Spotify (I am indeed playing music). TL;DR it doesn't seem to check your Twitter proof.
  - Gaelan 7y ago
    It looks like Keybase is using mobile.twitter.com. I just ran `sudo tcpdump -x host mobile.twitter.com` while browsing to ahnick's profile in the Keybase app on my Mac, and got a flurry of activity. It doesn't seem to do that if I just start a chat, however—it only happens if I pull up his profile (i.e. the screen that lists his Twitter account).
    - lucb1e 7y ago
      I guess it's good to know that it checks it in response to random actions, even if not when establishing a self-proclaimed end to end encrypted chat :P Btw mobile.twitter.com is also hosted in their own range (104.244.40.0/21), so I would have spotted that if it had been contacted when I tested it.
nindwen 7y ago
I don't know why it seems odd to you, it is literally what Keybase has been about since its start: the point is that you can bootstrap trust by linking to multiple already known identities (like twitter, hn, github) in a secure way. Even if you dislike all the other things Keybase has done since, this is a significant improvement over web-of-trust or TOFU. It should be trivially verifiable by yourself: just watch what requests your device is making. And the app itself is open source, so you should be able to trust it.
- lucb1e 7y ago
  Edit: this comment can be ignored since it doesn't seem to verify third party proofs in the first place. As far as I can tell, it just queries the Keybase servers and calls it a day, so the trust anchor is still only Keybase unless I overlooked something. More details in my other comment: https://news.ycombinator.com/item?id=21748454 https://news.ycombinator.com/item?id=21748454 --- > It should be trivially verifiable by yourself Yeah sure, once you realize that third parties are required for security. This shifts the root of trust from just Keybase to Keybase + a third party. That's not quite what I would call end to end encryption, at least not if there is no fallback to checking the keys manually. That's just not what the word means to me, even if the risk is sufficiently low that I guess it can be considered equivalent. So I'm not saying it's a bad thing. If indeed all chat apps had such a scheme where third parties vet the keys, i.e. if it were commonplace to have to compromise two or more companies' servers before you can MITM someone successfully, it would be a huge improvement over the current state. Keybase is definitely being innovative here. It's just not how it's marketed (namely as being a secure chat in and of itself), and I hadn't realized that this might be what they mean when they write "end to end encrypted [but only if you sign up with a trusted third party!]".
  - Gaelan 7y ago
    IIRC a PGP key is one of the “third parties” you can attach to your account, so assuming that the app checks those, you could get verifiable E2E that way. I’m also quite surprised by your findings about Keybase not checking verifications—my impression from their marketing/docs was that they made a point of doing that. I’m not in front of a computer right now, but will look more into it later.