5 ms·

So audit the client assuming that all of the traffic it sends is in the clear (i.e. not over https to keybase's servers). If that's not sufficient, then don't u

by zeeboo 8y ago

So audit the client assuming that all of the traffic it sends is in the clear (i.e. not over https to keybase's servers). If that's not sufficient, then don't use keybase. Regardless, until you have a way to ensure the server is running the code you expect it to be running (can this even exist? what about hardware level attacks on the servers keybase is running?) the server code is useless from a security perspective.

josh2600 8y ago
You’re just pretending the server is outside of scope. In reality you have to consider the security model of the whole system. The server is not outside of scope.
- zeeboo 8y ago
  You can construct a client such that the server IS outside of the scope. You can determine if a client has such a property from the client alone. I would only want to use a client such that the server is outside of the scope. It's strictly better if the client has this property even if the server is open and magically trusted to be running the code you expect. The keybase client is such a client. If it isn't please inform someone with details on why. edit: Do you audit all of the software running on all of the routers between you and keybase's servers? Why or why not? If not, why does this reasoning not extend to the servers? Why would the routers not part of the whole system, top to bottom?
  - josh2600 8y ago
    It would be great to audit all of the software running on all of the routers I use. I hope that we someday move to a model where all routers run open-source attestable software. Let me phrase this another way: if there's nothing to hide on the server, why isn't it open source? We can go back and forth on this forever. My position is simple: strictly speaking, it's more rational to trust open source software. Trusting closed source software ultimately boils down to "trust me". I would love to reduce the degrees to which we have to blindly trust the systems we use.
    - zeeboo 8y ago
      And yet, all of the routers are not audited, and I presume you believe in the security of some applications that use them. In other words, the trusted base of the system does not depend on all of the components in the system (you start with the assumption that any closed components are hostile). The keybase servers are exactly the same. The answer is that they do have things to hide: anti-spam/anti-scam systems, for example. The question is if they are hiding something that matters for security. You can determine this by auditing only the client. Sure, open source software is great, and has many uses. In this case, it has no use in ensuring that keybase is secure. Somehow, you don't have to trust a great many components in the secure software you use on a daily basis, and yet you have to trust keybase's servers because.. reasons? And somehow this trust is important even though you'd still be blindly trusting that they're running what you hope. I won't argue that some people would benefit from the server being open source, but to argue that open sourcing it has anything to do with security is just inane and FUD.
      - josh2600 8y ago
        The question boils down to "what can an attacker learn by owning the server" and right now you don't know. You can pretend that doesn't matter, but it's not inane or FUD. You have to model the whole system to understand the threat model. Anything less is blind trust.
        zeeboo 8y ago
        You can know exactly what the attacker can learn because you can see ALL of the information that your client passes to the server by auditing ONLY the client. Your argument applies equally well to every single router or middle box on the internet, and it's just as wrong there. You prove that it doesn't matter by assuming that keybase is running the most malicious code possible, auditing your client, and deciding that the system is still secure. This is what auditing the client means. Additionally, to bring up this fact again because it has only been hand-waved away: Even if the server was open source, there is no guarantee they are running that code. Thus, there is no benefit to security until systems exist (somehow?) to prove the server is running the code you expect. Double additionally: even IF you can prove that the server is running what you expect, how do you know that some box, after https is peeled off, but before the request makes it to the server, is not sending the same request off to some other, malicious, server?
a3_nm 8y ago
Releasing the server code allows concerned users to run their own servers, and this way they can ensure that they are using a server that runs the code that they expect.
- zeeboo 8y ago
  There is no need to run the code that you expect if the client is designed properly, and you are only sure you're running the code you expect until your server is hacked, which also becomes a non-issue if the client is designed properly. There are other reasons to want to self host: to be in control of your (encrypted) data so that it isn't lost if keybase goes under, for example. But security is not one of the reasons.
  - a3_nm 8y ago
    Why assume that the server will eventually get hacked? Why shouldn't the server be designed properly, just like the client? I still think it makes sense in terms of security. If I run a piece of client software X that connects to a server Y, it will always be better in terms of security if I'm in control of what runs on Y. This is independent on how X has been audited. So yeah I would argue that security is also a reason.
    - zeeboo 8y ago
      Assuming the server will eventually get hacked is how you design secure systems. You assume the worst, and ensure you are still secure. The server code being designed well had nothing to do with the hardware running the system being hacked. For instance, no amount of good design in my server stops a remote 0-day against linux, for example. This is a subtle point, but that thinking is misguided. You, as a client, have no control over what server you’re actually talking to. The only way to be sure you are secure is to be secure independently of if the server has been hacked, or is malicious, or whatever. Thus, you design your system such that the client only discloses information that is allowed to be public to the server (public keys, encrypted messages where the server can’t decrypt it, etc). In that way, you don’t care what code the server is running, and auditing the server makes no difference to security. The whole purpose of cryptography is to reduce the set of things you need to trust. Including the server in the trusted base is not only a worse design but a false sense of security if your trust ends up misplaced (hacked). So, this is different than how a bank would work, for example. In the case of a bank, you have to trust that their servers are secure, and their software being open would help with auditing that. In this case, keybase is not the endpoint you’re talking to: another keybase client is. The keybase server is just an intermediary, just like any router on the internet.

by zeeboo 8y ago

josh2600 8y ago

You’re just pretending the server is outside of scope. In reality you have to consider the security model of the whole system. The server is not outside of scope.

zeeboo 8y ago
You can construct a client such that the server IS outside of the scope. You can determine if a client has such a property from the client alone. I would only want to use a client such that the server is outside of the scope. It's strictly better if the client has this property even if the server is open and magically trusted to be running the code you expect. The keybase client is such a client. If it isn't please inform someone with details on why. edit: Do you audit all of the software running on all of the routers between you and keybase's servers? Why or why not? If not, why does this reasoning not extend to the servers? Why would the routers not part of the whole system, top to bottom?
- josh2600 8y ago
  It would be great to audit all of the software running on all of the routers I use. I hope that we someday move to a model where all routers run open-source attestable software. Let me phrase this another way: if there's nothing to hide on the server, why isn't it open source? We can go back and forth on this forever. My position is simple: strictly speaking, it's more rational to trust open source software. Trusting closed source software ultimately boils down to "trust me". I would love to reduce the degrees to which we have to blindly trust the systems we use.
  - zeeboo 8y ago
    And yet, all of the routers are not audited, and I presume you believe in the security of some applications that use them. In other words, the trusted base of the system does not depend on all of the components in the system (you start with the assumption that any closed components are hostile). The keybase servers are exactly the same. The answer is that they do have things to hide: anti-spam/anti-scam systems, for example. The question is if they are hiding something that matters for security. You can determine this by auditing only the client. Sure, open source software is great, and has many uses. In this case, it has no use in ensuring that keybase is secure. Somehow, you don't have to trust a great many components in the secure software you use on a daily basis, and yet you have to trust keybase's servers because.. reasons? And somehow this trust is important even though you'd still be blindly trusting that they're running what you hope. I won't argue that some people would benefit from the server being open source, but to argue that open sourcing it has anything to do with security is just inane and FUD.
    - josh2600 8y ago
      The question boils down to "what can an attacker learn by owning the server" and right now you don't know. You can pretend that doesn't matter, but it's not inane or FUD. You have to model the whole system to understand the threat model. Anything less is blind trust.
      - zeeboo 8y ago
        You can know exactly what the attacker can learn because you can see ALL of the information that your client passes to the server by auditing ONLY the client. Your argument applies equally well to every single router or middle box on the internet, and it's just as wrong there. You prove that it doesn't matter by assuming that keybase is running the most malicious code possible, auditing your client, and deciding that the system is still secure. This is what auditing the client means. Additionally, to bring up this fact again because it has only been hand-waved away: Even if the server was open source, there is no guarantee they are running that code. Thus, there is no benefit to security until systems exist (somehow?) to prove the server is running the code you expect. Double additionally: even IF you can prove that the server is running what you expect, how do you know that some box, after https is peeled off, but before the request makes it to the server, is not sending the same request off to some other, malicious, server?

a3_nm 8y ago

Releasing the server code allows concerned users to run their own servers, and this way they can ensure that they are using a server that runs the code that they expect.

zeeboo 8y ago
There is no need to run the code that you expect if the client is designed properly, and you are only sure you're running the code you expect until your server is hacked, which also becomes a non-issue if the client is designed properly. There are other reasons to want to self host: to be in control of your (encrypted) data so that it isn't lost if keybase goes under, for example. But security is not one of the reasons.
- a3_nm 8y ago
  Why assume that the server will eventually get hacked? Why shouldn't the server be designed properly, just like the client? I still think it makes sense in terms of security. If I run a piece of client software X that connects to a server Y, it will always be better in terms of security if I'm in control of what runs on Y. This is independent on how X has been audited. So yeah I would argue that security is also a reason.
  - zeeboo 8y ago
    Assuming the server will eventually get hacked is how you design secure systems. You assume the worst, and ensure you are still secure. The server code being designed well had nothing to do with the hardware running the system being hacked. For instance, no amount of good design in my server stops a remote 0-day against linux, for example. This is a subtle point, but that thinking is misguided. You, as a client, have no control over what server you’re actually talking to. The only way to be sure you are secure is to be secure independently of if the server has been hacked, or is malicious, or whatever. Thus, you design your system such that the client only discloses information that is allowed to be public to the server (public keys, encrypted messages where the server can’t decrypt it, etc). In that way, you don’t care what code the server is running, and auditing the server makes no difference to security. The whole purpose of cryptography is to reduce the set of things you need to trust. Including the server in the trusted base is not only a worse design but a false sense of security if your trust ends up misplaced (hacked). So, this is different than how a bank would work, for example. In the case of a bank, you have to trust that their servers are secure, and their software being open would help with auditing that. In this case, keybase is not the endpoint you’re talking to: another keybase client is. The keybase server is just an intermediary, just like any router on the internet.