4 ms·

It is not clear from the site if the data I give to AeroFS is encrypted at rest. There is a section called "End-to-end Security" that states: AeroFS uses AES

by andymoe 14y ago

It is not clear from the site if the data I give to AeroFS is encrypted at rest. There is a section called "End-to-end Security" that states: AeroFS uses AES-256 with 2048-bit RSA to create secure connections directly from one device to another. Because encryption is end-to-end, even we can't see your data or even file names. But this does not actually tell me in plain terms if you encrypt my data when it's sitting on your servers or not and that's actually a more important question to answer. Everyone expects data to be encrypted in transit. You don't get extra points for that. Would you mind clarifying if the data is ever on your servers in an unencrypted form?

zarvox 14y 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 14y ago
  Great, thanks for the response!
- andrewflnr 14y ago
  I'm confused. This makes your servers sound almost entirely useless most of the time. What role do they normally play?
  - mbreese 14y ago
    It sounds like they are using their servers as a relay to get around two clients that are behinds NATs.
    - andrewflnr 14y ago
      Yes, I got that, but what else do they do?
      - huhtenberg 14y ago
        It's a rendezvous service. They help clients locate each other.
- rdl 14y ago
  You 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 14y ago
    Yes, we use NAT traversal techniques where possible on the WAN, and direct TCP connections over the LAN.
- eps 14y ago
  Do 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 14y ago
    A 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 14y ago
      Do 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.

by andymoe 14y ago

zarvox 14y 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 14y ago
Great, thanks for the response!
andrewflnr 14y ago
I'm confused. This makes your servers sound almost entirely useless most of the time. What role do they normally play?
- mbreese 14y ago
  It sounds like they are using their servers as a relay to get around two clients that are behinds NATs.
  - andrewflnr 14y ago
    Yes, I got that, but what else do they do?
    - huhtenberg 14y ago
      It's a rendezvous service. They help clients locate each other.
rdl 14y ago
You 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 14y ago
  Yes, we use NAT traversal techniques where possible on the WAN, and direct TCP connections over the LAN.
eps 14y ago
Do 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 14y ago
  A 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 14y ago
    Do 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.