[andymoe]

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]

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.

[eps]

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]

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 [e-mail] (PGP key 6E1DC9F9, if you prefer encrypted email).

[abcd_f]

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.

[zarvox]

Cert pinning only makes sense if you happen to trust multiple CAs, but want to stick to the cert issued by one particular one. We only trust one CA, and each issued cert is bound to a user and device id, so this is a non-issue. :)

[abcd_f]

No, no, no.

It has nothing to do with that. Cert pinning is used to mitigate man-in-the-middle attacks whereby an attacker somehow obtains a valid certificate for peer's ID further down the road. If the certificate is not pinned, then the client will swallow a new cert without a peep, because it tracks back to a trusted CA.

Cert pinning is an equivalent of ~/.ssh/known_hosts. It allows me to pin specific public key to a peer and be notified if that key ever changes.

In your case, you might've gone with self-signed peer certs, but that would've obviously require manual verification of the peer's key on 1st contact. This is a bit of UX issue, because few people would bother to actually verify a string of hex numbers between two computers. So, naturally, you introduce a chaperon entity - your CA - that vouches for peer's credentials. I am willing to trust it, but consider it a "weak" trust that I put in place only for convenience purposes and to get stuff going quickly. Later on I may look and compare the key hashes (one provided by peer in an out of band fashion and the other I compute from my own copy of the key) and if they match only then I will know that I have a truly secure connection with the peer and that you didn't lie in your initial peer introduction. At this point I want to pin peer's key, so to be notified to repeat the manual verification process if/when the key changes.

tl;dr - Just add the cert pinning and display cert's public key hashes (mine and peers) somewhere in the UI.

[rdl]

Arguably you should also public key pin the key for https://www.aerofs.com/ anyway, just to get initial protection. IMO you're important enough and clueful enough to get this from Chrome, but I'm not agl.

[newman314]

ECDHE used?

[rdl]

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]

Yes, we use NAT traversal techniques where possible on the WAN, and direct TCP connections over the LAN.

[andrewflnr]

I'm confused. This makes your servers sound almost entirely useless most of the time. What role do they normally play?

[mbreese]

It sounds like they are using their servers as a relay to get around two clients that are behinds NATs.

[andrewflnr]

Yes, I got that, but what else do they do?

[huhtenberg]

It's a rendezvous service. They help clients locate each other.

[andymoe]

Great, thanks for the response!