Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AeroFS (YC S10) exits private beta

blog.aerofs.com

Post reply on HN
Print view View original

51–60 of 94 posts

Re: AeroFS (YC S10) exits private beta

#51

Post by yurisagalov »

eps wrote: post #48

Any plans for Java-free implementation of the client software? It's a pretty big and an unwelcome dependency.

We've actually just released a Java-free installable for Windows about a week ago (see release 0.4.173 @ http://support.aerofs.com/knowledgebase/articles/93285-relea...).

What we've done in the Windows installation is bundle a minimal JRE as a light-weight library. The JRE is loaded by AeroFS at runtime and is otherwise completely isolated, so no dependency exists on Java in Windows. Based on how well that has worked out so far, we'd like to do a similar approach for OSX and Linux soon.

Re: AeroFS (YC S10) exits private beta

#53

Post by yurisagalov »

newman314 wrote: post #46
rdl wrote: post #2

This is awesome. AeroFS does everything I want in a file sharing system -- I can either run it entirely on my own machines on LAN and potentially VPN, or at a company on a network also not connected to the Internet, or I can use it as a direct Dropbox alternative (although it lacks some mobile clients and API support). I've been using it for ~a year or two in beta, as well as all the other alternatives. I still use D…

I'm not too keen on the fact that AeroFS runs on Java as I would prefer to run Java free systems as much as possible (Go version would be nice =) but am willing to live with it if that's the only option.

We're working on it (a Java-free system, not a Go version, sorry ;)

See my response here: https://news.ycombinator.com/item?id=5484566

Re: AeroFS (YC S10) exits private beta

#54

Post by teekert »

Oh how nice it would be to be able to run this on my Raspberry Pi's and have off site backups on the cheap. Since most of the people I know now have fiber I'd make a nice distributed system of RPi's to keep everyone's pictures safe.

Re: AeroFS (YC S10) exits private beta

#55

Post by huhtenberg »

andrewflnr wrote: post #43
mbreese wrote: post #40

Earlier quoted context omitted.

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

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

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

Re: AeroFS (YC S10) exits private beta

#56

Post by eps »

yurisagalov wrote: post #51
eps wrote: post #48

Any plans for Java-free implementation of the client software? It's a pretty big and an unwelcome dependency.

We've actually just released a Java-free installable for Windows about a week ago (see release 0.4.173 @ http://support.aerofs.com/knowledgebase/articles/93285-relea... ). What we've done in the Windows installation is bundle a minimal JRE as a light-weight library. The JRE is loaded by AeroFS at runtime and is otherwise completely isolated, so no dependency exists on Java in Windows. Based on how well that has worke…

Great. That's a sensible solution.

Congrats by the way :)

Re: AeroFS (YC S10) exits private beta

#57

Post by zarvox »

eps wrote: post #50
zarvox wrote: post #34

Earlier quoted context omitted.

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.

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.

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).

Re: AeroFS (YC S10) exits private beta

#58

Post by abcd_f »

zarvox wrote: post #57
eps wrote: post #50

Earlier quoted context omitted.

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.

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 us…

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.

Re: AeroFS (YC S10) exits private beta

#60

Post by zarvox »

abcd_f wrote: post #58
zarvox wrote: post #57

Earlier quoted context omitted.

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 us…

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.

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. :)
Post reply on HN