Hacker News Reader

Comment by rsync | Hacker News Reader

If you're intrigued by using basic unix primitives for tasks like this you'd probably also be intrigued by a cloud storage product that was built to act like a unix primitive.[1][2]

If you're interested in point-in-time snapshots, you're probably also intrigued by our ZFS platform that gives you day/week/month/quarter/year snapshots that you don't have to configure or maintain - you just do a "dumb" rsync (or whatever) to us and the snapshots just appear.

If you're interested in encrypted backups you should look into the 'borg backup' tool which has become the de facto standard for remote, encrypted, changes-only-upload backups.[3][4]

Finally, if S3 pricing is important, you should email us about our "HN Readers'" discount.

[1] https://www.rsync.net

[2] Examples: http://www.rsync.net/resources/howto/remote_commands.html

[3] https://www.stavros.io/posts/holy-grail-backups/

[4] http://rsync.net/products/attic.html

View on HN

Regarding rsync.net, I'm sorry but I won't trust any company to protect my data if they can't spend a few minutes to put an SSL certificate on their website. The rsync.net url just redirects to an http link with no SSL certificate.

What's the threat model for serving a read-only, public, marketing site over http? Or is it just a general principle?

That website is not a read-only, public marketing site. It contains their order page, which asks for personal information: https://www.rsync.net/signup/order.html

Their unencrypted pricing page links to that encrypted order form page. We all agree there should be no http to http transitions like that, right?

If you'll note, that encrypted order page is on the same host as their unencrypted pages. Both rsync.net and www.rsync.net covered by the cert. They have SSL set up already, and they just purposely redirect away to http for their static pages. That is a well-known ssl antipattern.

When you say "on the same host" do you mean "have the same DNS name" or do you mean literally on the same server? It's possible it's just behind the same load balancer so I'm curious what the threat model that you're concerned about is specifically.

To be clear: I don't like transitions like that either but that concern is something I've only previously had with sites that do e-commerce or login portal that's not on a different (sub)domain. Apple and some banking sites are notable examples that used to concern me (though I doubt they are still like that).

The threat for http to https transactions is that man in the middle can rewrite, drop, or add data before the user reaches the https site. See sslstrip[0] for an example of this attack.

[0] https://moxie.org/software/sslstrip/

That load balancer is a server. It has the TLS key, and so is authoritative for be content of the site.

The model of “surrogate origin server” is sometimes more helpful than “middlebox” and similar.

Users are for example protected from ISP injecting ads or tracking in the website.

It’s a sign that security isn’t their first priority. It’s almost 0 effort to put ssl on an entire site. Pretty much no reason not to.

The actual answer is probably going to surprise you ...

The reason that the vast majority of rsync.net is not covered by https is because I personally have not yet decided how I feel, philosophically, about the notion of https-only websites.

As silly as it may sound to you, I very much like the fact that you can read rsync.net HOWTO pages with netcat. Or telnet'ing to port 80. Or grab them with old versions of 'fetch'.

I used to do all kinds of interesting and time-saving tasks on the pre-https internet with simple, static UNIX tools. As you can imagine, almost all of those workflows are now either broken or require a big huge pile of python libraries.

So in summary, I am sorry to deprive you of your righteous indignation. You can see from our properly implemented order form that we understand https just fine, thank you.

The real answer is that https-everywhere sounds like it's probably a good idea ... but also sounds like you should maybe get off of my lawn ... but I'm not sure yet.

If you want to support HTTP too, that's fine. But why redirect people who use HTTPS URLs back to the HTTP page?

In any case, modern software toolchains have no trouble with HTTPS. I can interact with it from the command line pretty easily with `wget` or `curl` and similar.

Man, you don't even understand basic security practices.

When going from a HTTP page to a HTTPS page, what guarantees can you give that I see the original content and clicked the proper link and that I was not MITM-ed? A potential attacker can MITM and easily redirect me to any order page they want... This is security 101.

I understand the attack you've outlined just fine.

What you don't understand is that people that don't notice being redirected to a different domain are not smart enough to be using rsync.net in the first place.

So it's not an issue.

Or, I should say, in the fifteen years that we have been providing "cloud storage"[1] it hasn't been an issue.

[1] It wasn't called "cloud storage" back then - our service predates the term.

Probably I (working in security and even checking certificates sometimes) would not even notice if it would point to a different domain like rsync-app.net or some random name with a valid cert. There are a ton of examples and valid points of putting different things to different TLDs. Why should I be suspicious? How should I know what domain, subdomain, whatever did you choose and why?

Maybe even https://order.rsync.net could be the link and YOU (the sysadmin of the service) might not even notice, because I'm pretty sure you don't check/monitor your DNS records every couple of minutes.

The reason "it did not happened yet", is not valid, because if could happen anytime in your service's lifetime. It's like an open door and no robbery happened yet, but the likelihood of it is happening is worse than if you at least close the door. It would be silly to complain "It has been open for a long time and there were no robbery." after it happened.

> "people that don't notice being redirected to a different domain are not smart enough to be using rsync.net in the first place."

This is just an assumption, I would not make that. You could be surprised. Sometimes even web developers don't understand how x509 certs and https work.

Your reasons may be plentiful, but if it's because you prefer the protocol, without the obstruction of handshake, I'd recommend using openssl s_client.

Obvious disclaimer: openssl binary may or may not be part of your system (although the same can be said about netcat and telnet)

Just checked... and OMG that was terrible.

How can they be trusted with backups when they can't even run a HTTPS website.

I've seen your service advertised for years, but only started using it myself since August. I've had two outages in that time, once lasting for two+ days.

However despite the outages I have to say I've been genuinely impressed at how smoothly the process of signing up was, and how well the (borg) product works.

I have my own local backups, so I'd only ever need to restore from your copies in the event of a catastrophic failure, and I while I hope that never happens I do test-restores now and again and things have always been great.

I've been a happy rsync.net customer for several years. It's my personal backup solution (borg + append-only + locked down SSH key) for a while, and I just had to use it to restore my computer yesterday.

Their rates are incredible, and their support is excellent. I highly recommend it.

Reply on news.ycombinator.com