5 ms·
Your data is never stored on our servers in an unencrypted form. Moreover, the data is never stored on our servers at all. In some scenarios (when two clients
by zarvox 13y ago
Your data is never stored on our servers in an unencrypted form. Moreover, the data is never stored on our servers at all.
In some scenarios (when two clients are both behind aggressive firewalls, for instance) the data may be _relayed_ by our servers, but in those cases it is encrypted (end-to-end) between the devices syncing using their respective public/private keys, so we can't eavesdrop.
- andymoe 13y agoGreat, thanks for the response!
- andrewflnr 13y agoI'm confused. This makes your servers sound almost entirely useless most of the time. What role do they normally play?
- mbreese 13y agoIt sounds like they are using their servers as a relay to get around two clients that are behinds NATs.
- andrewflnr 13y agoYes, I got that, but what else do they do?
- huhtenberg 13y agoIt's a rendezvous service. They help clients locate each other.
- rdl 13y agoYou can go straight peer to peer when behind less-than-totally-aggressive firewalls, using the double open trick used by voip apps like Skype, right?
- zarvox 13y agoYes, we use NAT traversal techniques where possible on the WAN, and direct TCP connections over the LAN.
- eps 13y agoDo you have a spec of your security model? I really hope it's not a homebrew solution but something based off existing protocols. In either case, since the security and privacy is your primary feature, a full disclosure of hos it works inside is a must.
- zarvox 13y agoA proper writeup is in the works, but to cover the basics: we know not to implement our own crypto. :) Passwords: we apply scrypt() before any use or storage. We never store the plaintext. Device-to-device: standard PKI. We have a CA, and the CA's cert is bundled with the client software. Devices generate 2048-bit RSA keys at setup time. They then generate a PKCS10 CSR which our CA signs, provided you give a valid username/password. When peers wish to communicate, they establish a DTLS connection (we use OpenSSL's DTLS implementation, and AES-256-CBC as the default ciphersuite), verifying that the other device: * is certified by our CA to represent the claimed user and device (identity) * is not using a certificate with a revoked serial number * is trusted to send and receive information about the relevant shared folder (authorization) Device-to-server: Everything between your machine and our servers uses TLS. Where possible, we trust only our own CA. Implementation-wise, we use Java's crypto providers for TLS. Revocation: When you unlink or remote-wipe a device, we mark the certificate associated with that device as revoked, and notify each of your clients either immediately (if they're online) or as soon as they come online and reconnect to our push notification service that the revoked device is no longer to be trusted. (This is one of the other tasks that our servers provide - prompt delivery of device revocation information.) We update our libraries promptly and are subscribed to the appropriate mailinglists. Finally, if you believe you have discovered a vulnerability in some part of the AeroFS system, please contact us at security@aerofs.com (PGP key 6E1DC9F9, if you prefer encrypted email).
- abcd_f 13y agoDo you use certificate pinning on the clients? I.e. once a client sees peer's cert for the first time, it should remember it and warn if it ever changed afterwards.