[carterx]

Is it possible to do a backup to a specified FTP account/space? I have FTP space and I was looking to have certain files on my computer backed up automatically. I was looking at DropBox but the space I want to backup I think could reach the 2gb limit.

I know there are apps that can connect to a FTP account/space to do a backup of the ftp space, but what about the opposite to backup to the ftp space.

Thanks,

[besson3c]

You can with SFTP/SSH using public keys. You shouldn't be backing up daily to regular FTP anyway - too insecure.

[turtle777]

Originally Posted by besson3c 

You shouldn't be backing up daily to regular FTP anyway - too insecure.

Depends. If you have a backup software that encrypts the traffic, it's not a problem.

See here for my recommendation of Twin.

It does all the OP needs and more.

-t

[besson3c]

The encryption will only work with protocols that support secure tunneling - I'm pretty sure you need this layer on both ends to support a tunnel. It could be that this user's FTP server supports FTP over SSL (which is different than SFTP), but I doubt that.

However, I wasn't even thinking so much of encrypting all traffic as much as I was simply encrypting the transmission of the password during authentication. This is the part that would concern me about using regular FTP.

[turtle777]

Originally Posted by besson3c 

The encryption will only work with protocols that support secure tunneling - I'm pretty sure you need this layer on both ends to support a tunnel. It could be that this user's FTP server supports FTP over SSL (which is different than SFTP), but I doubt that.

Care to click the link ?

Twin encrypts the traffic, no matter what connection is used. It's independent of the layer.

-t

[besson3c]

I think you're misunderstanding it, turtle. How can something on the client end control what happens once traffic leaves that computer? A secure tunnel is formed when there is a handshake between server and client. If there is nothing the server to facilitate this, I don't see how this is possible.

[turtle777]

Originally Posted by besson3c 

I think you're misunderstanding it, turtle. How can something on the client end control what happens once traffic leaves that computer? A secure tunnel is formed when there is a handshake between server and client. If there is nothing the server to facilitate this, I don't see how this is possible.

Dadgummit, Besson, don't be so dense, hit up the link.

The data is encrypted BEFORE it's transmitted. YOU define the encryption keys. It's like encrypted email.

-t

[besson3c]

Originally Posted by turtle777 

Dadgummit, Besson, don't be so dense, hit up the link.

The data is encrypted BEFORE it's transmitted. YOU define the encryption keys. It's like encrypted email.

-t

I guess my logic is no match for your gut feeling, huh?

Please don't call me dense, there is no need for that. I was polite to you in suggesting that I *think* you don't understand this, when as it turns out my own gut feelings were right, I'm pretty sure that you don't.

Encrypted email... Do you mean PGP encrypted? Have you ever sent somebody an encrypted email who didn't have your public key or something to decrypt your encrypt email so that they can read it? What do they get? A bunch of gobbily gook. Are you suggesting that this thing converts megabytes and megabytes of data into encrypted data on the fly? I highly doubt that. Do you have any idea what kind of performance hit this would ensue? What are people supposed to do when they download these files from the server with a client that cannot decrypt this data? Altering data on the fly in this manner is insane, this client is not doing this. How do PGP or SSL email certs work? The same way that most security mechanisms are derived: challenge and response. This relies on participation from both server and client - both ends need to be a part of this transaction.

Or, by email encryption do you mean the SSL/TLS encryption that some email servers support as an authentication layer to the SMTP and/or IMAP server? Guess what? The protocol needs to support this, the server needs to have this enabled. Again, you cannot just flip a switch on the client and expect things to just magically work. There is a difference between an encrypted tunnel and encrypted data.

I was hoping we could have this conversation without you being an ass. Oh well.

[ghporter]

Knock off the bickering. FTP is inherently insecure, and any technique that makes an FTP link secure is both non-standard and implementation dependent. In other words, "you can make it secure, but both ends have to cooperate." You can't just add software at the user end and "make" a standard FTP connection secure. Turtle, you could explain how Twin impacts the server end to make it produce secure connections; that would decrease the level of animosity I'm seeing in these posts.

[turtle777]

Originally Posted by besson3c 

I was hoping we could have this conversation without you being an ass. Oh well.

Besson, you annoy the freaking hell out of me, sometime.

Why do you keep arguing, when I provided you a link that explains it ?
You do this crap all the time, you argue w/o consulting the facts, and throw in a lot of tech mumbo jumbo to appear knowledgable.

So, instead of getting all defensive and what not, if you had read the link, it would have indeed told you that the encryption is on the fly ONLY on the client's side.

SECURE
You can optionally protect the privacy of your data with on-the-fly top-grade AES-256 encryption
(approved by the US Government to protect classified information). If you choose to do so, not a single
byte of your backup data leaving Twin will be readable by strangers. Most competitors backup software
still use 15 years old BlowFish encryption.

Originally Posted by ghporter 

In other words, "you can make it secure, but both ends have to cooperate." You can't just add software at the user end and "make" a standard FTP connection secure.

Yes you can. Twin does it.

It's like an encrypted sparseimage, of which only the changes get uploaded.
It's doesn't matter at all that the protocol is not encrypted, and no special interaction is needed on the receiving side.

-t

[ghporter]

Originally Posted by turtle777 

It's like an encrypted sparseimage, of which only the changes get uploaded.
It's doesn't matter at all that the protocol is not encrypted, and no special interaction is needed on the receiving side.

-t

So what's saved on the server is your encrypted image? That's quite a different matter. From the way the earlier conversation was going, it looked like you were inferring that the process was secure, not that what was saved on the FTP server was itself secure.

[turtle777]

Originally Posted by ghporter 

So what's saved on the server is your encrypted image? That's quite a different matter. From the way the earlier conversation was going, it looked like you were inferring that the process was secure, not that what was saved on the FTP server was itself secure.

Did I ? I'm not aware of that.

This is what I said:

Originally Posted by turtle777 

Twin encrypts the traffic, no matter what connection is used. It's independent of the layer.

I thought that made it clear that the encryption is not done by the FTP protocol, but by the client (Twin).

-t

[besson3c]

So, you need something that will decrypt stuff from this image, you need their client. You wrote:

Twin encrypts the traffic, no matter what connection is used. It's independent of the layer.

This is wrong. It does not encrypt the traffic, it saves the files into an encrypted file format. You are not gaining security during the transmission of data, you are getting a file that if stolen cannot be accessed. There is no secure tunnel, there is no encryption of data happening on the fly in transmission, there is no traffic being encrypted. This is not what you wrote.

[turtle777]

This is wrong. It does not encrypt the traffic, it saves the files into an encrypted file format. You are not gaining security during the transmission of data, you are getting a file that if stolen cannot be accessed. There is no secure tunnel, there is no encryption of data happening on the fly in transmission, there is no traffic being encrypted. This is not what you wrote.

For 99% of the people, the description of "traffic is encrypted on the fly" is exactly what's happening, although it's technically not correct.
In reality, nobody cares that the data is encrypted by the client, and not by the tunnel / transmission. It's a technical geek argument that the OP probably could care less about.

My basic premise stands:

Twin does secure backups via all kinds of unsecure connections, and all that's needed is a backup client.

-t

[besson3c]

Sorry to get on you turtle, but what you just wrote is still not right...

The whole point of not using FTP is because of the insecurity of both traffic and authentication. Once the data reaches its end point, all bets are off as far as the safety of this data. The encrypted disk image takes care of the latter, but does nothing to secure the actual data transfer and authentication, which is again what is at concern here. If you are using FTP without a secure tunnel (such as stunnel) or without SSL, your data is sent in the clear, and authentication is not encrypted, period.

Therefore, it is not accurate to say that it "secures backups", because it doesn't. It ensures that your data cannot be accessed once it reaches its end point, but that's it.

Take home message: don't use FTP, Twin or not.

[besson3c]

carterx: sorry to take over your thread. Seriously, your best bet will be SSH/SFTP and public key access, regardless of any of these security issues we are bickering over - much easier, much more common of a setup to configure and get going.

[turtle777]

Originally Posted by besson3c 

The encrypted disk image takes care of the latter, but does nothing to secure the actual data transfer and authentication, which is again what is at concern here. If you are using FTP without a secure tunnel (such as stunnel) or without SSL, your data is sent in the clear, and authentication is not encrypted, period.

Therefore, it is not accurate to say that it "secures backups", because it doesn't. It ensures that your data cannot be accessed once it reaches its end point, but that's it.

What the heck ?

How the heck is transmitting an encrypted disk image in the clear unsecure ?
Why does it matter if the tunnel is secure or not ?
Even that the FTP authentication is not encrypted is not an issue. You could upload your AES256 bit encrypted disk image to a public FTP server, and it would be safe, given that you use a good password for the encryption.

I think you still don't get the concept of Twin.

Carterx, using Twin is safe and secure. Don't let besson's tech mumbo jumbo confuse you.

-t

[ghporter]

Originally Posted by turtle777 

I thought that made it clear that the encryption is not done by the FTP protocol, but by the client (Twin).

My interpretation of "encrypts the traffic" may not have been anything near what you meant. But to me, "traffic" implies a two-way exchange, which thus implied that something at the server was decrypting the data. If you'd said that Twin "encrypts the data so it can be sent securely," that might not have confused me as much. Saying that there was a client at the user end did not tell me enough-I inferred that you were still talking about storing plain text data on the FTP server, rather than encrypted data.

By working In this way, Twin effectively puts together an FTP client with something like PGP, but without the public key aspect. Apparently it's much neater than using PGP to create your encrypted file and then FTPing the result to your server.

Having had to deal with computer security in a very serious way for a long time (plus being an instructor whose words had to be exactly right all the time), I seem to have only a few ways to interpret certain key terms. My apologies.

[besson3c]

No, are writing *to* an encrypted disk image.

I think you don't get the concepts of networking.

You are not looking at what happens to get the data from point A to point B, only whether the file itself is encrypted. This is not tech mumbo jumbo, this is fact. Encrypted file formats do not buy you encrypted data transmission.

Leaving all of this aside, I have no idea what you mean by:

Even that the FTP authentication is not encrypted is not an issue

Sure it's an issue! If you send your password in the clear you are putting your entire account at risk. That's like having the Club on your steering wheel but leaving your doors unlocked.

[besson3c]

Originally Posted by ghporter 

If you'd said that Twin "encrypts the data so it can be sent securely," that might not have confused me as much.

It would confuse me, because it doesn't mean that it can be sent securely, it means that the file itself if nabbed once the upload was complete would be useless to people, but the data still has to get from point A to point B securely, and authentication still needs to be secured. IOW, the data itself in transmission is no different than it otherwise would be, it's just that it is wrapped in a container that is protected.

Let's look at it a different way... If you were to upload a folder that was somehow password protected, you'd have to upload the folder itself, but also the individual files into this folder. Those individual files would not encrypted during transmission just because the folder that these files will be stored in is protected. An FTP client simply uploads files in serial:

- upload folder (or in this case, encrypted disk image)
- upload file 1
- upload file 2
etc.

If files 1 and 2 are sent in the clear, the previous files that were uploaded are irrelevant. Even if those files are uploaded as one giant file, unless you alter each individual file to wrap it in some encryption layer such as PGP encryption as per your example (which would be a very expensive operation), you are still dealing with the same 1s and 0s sent in the clear. Does this make sense?

Again, it's the Club on steering wheel, doors unlocked analogy.

[turtle777]

Originally Posted by besson3c 

You aren't transmitting an encrypted disk image (unless you think that each individual file is an encrypted disk image?!) you are writing to an encrypted disk image. Big difference.

I think you don't get the concepts of networking. You are not looking at what happens to get the data from point A to point B, only whether the file itself is encrypted. This is not tech mumbo jumbo, this is fact. Encrypted file formats do not buy you encrypted data transmission.

Leaving all of this aside, I have no idea what you mean by:



Sure it's an issue! If you send your password in the clear you are putting your entire account at risk. That's like having the Club on your steering wheel but leaving your doors unlocked.

TWIN IS TRANSMITTING ENCRYPTED DISK IMAGES.

It creates the master disk image locally first, encrypted, and then calculates what has changed to the disk images on the remote server. Then those changes are transmitted, and of course, that's already encrypted.

It does NOT write directly to the remote disk image. Instead, it creates "delta" disk images on the remote server, only containing the changes (sort of like TM does).

Twin can put all those images back together, or you can do it manually, since the format used is based on open standards.

The backup data generated by Twin is compatible with open standard technologies (CPIO or CPGZ archives, split files, OpenSSL encryption…), and does not use proprietary formats, so you can still access your backup data without Twin if you ever needed to. This may require some preliminary manipulations in Terminal because the backed up files can be open in the Finder.

Note that if you had choosen to crypt the data, nobody can access it without the key.

1) uncrypt with "openssl"
2) Join all parts with "cat"

Here's some of the files my Twin backup created.

sftp://hanjin.dreamhost.com/vol/raid3050/2/user_xyz/computer/File_0028.dmg.0006.aes
sftp://hanjin.dreamhost.com/vol/raid3050/2/user_xyz/computer/File_0028.dmg.0007.aes
sftp://hanjin.dreamhost.com/vol/raid3050/2/user_xyz/computer/File_0028.dmg.0008.aes
sftp://hanjin.dreamhost.com/vol/raid3050/2/user_xyz/computer/File_0029.zip.apdb.aes
sftp://hanjin.dreamhost.com/vol/raid3050/2/user_xyz/computer/File_0029.zip.0001.aes
sftp://hanjin.dreamhost.com/vol/raid3050/2/user_xyz/computer/File_0029.zip.0002.aes
sftp://hanjin.dreamhost.com/vol/raid3050/2/user_xyz/computer/File_0029.zip.0003.aes
sftp://hanjin.dreamhost.com/vol/raid3050/2/user_xyz/computer/File_0030.dmg.apdb.aes
sftp://hanjin.dreamhost.com/vol/raid3050/2/user_xyz/computer/File_0030.dmg.0001.aes

Could you now please confirm to carterx that Twin is safe, and will do exactly what he needs.

-t

[turtle777]

Originally Posted by besson3c 

unless you alter each individual file to wrap it in some encryption layer such as PGP encryption as per your example (which would be a very expensive operation),

I would say this is EXACTLY what Twin is doing.

It's very unobtrusive, and easy for the end-user, even for non-geeks.
Twin is a rally, really smart approach to online backups.

-t

[besson3c]

Originally Posted by turtle777 

TWIN IS TRANSMITTING ENCRYPTED DISK IMAGES.

It creates the master disk image locally first, encrypted, and then calculates what has changed to the disk images on the remote server. Then those changes are transmitted, and of course, that's already encrypted.

No, it's not. Those files are encrypted. You still aren't getting the difference between encrypted files and encrypted data transmission.

Here's some of the files my Twin backup created.

sftp://hanjin.dreamhost.com/vol/raid3050/2/user_xyz/computer/File_0028.dmg.0006.aes
sftp://hanjin.dreamhost.com/vol/raid3050/2/user_xyz/computer/File_0028.dmg.0007.aes
sftp://hanjin.dreamhost.com/vol/raid3050/2/user_xyz/computer/File_0028.dmg.0008.aes
sftp://hanjin.dreamhost.com/vol/raid3050/2/user_xyz/computer/File_0029.zip.apdb.aes
sftp://hanjin.dreamhost.com/vol/raid3050/2/user_xyz/computer/File_0029.zip.0001.aes
sftp://hanjin.dreamhost.com/vol/raid3050/2/user_xyz/computer/File_0029.zip.0002.aes
sftp://hanjin.dreamhost.com/vol/raid3050/2/user_xyz/computer/File_0029.zip.0003.aes
sftp://hanjin.dreamhost.com/vol/raid3050/2/user_xyz/computer/File_0030.dmg.apdb.aes
sftp://hanjin.dreamhost.com/vol/raid3050/2/user_xyz/computer/File_0030.dmg.0001.aes

If you uploaded these via SFTP than all is good. Otherwise, it's the same problem I described - the binary data sent in transmission was sent in the clear.

Could you now please confirm to carterx that Twin is safe, and will do exactly what he needs

Sorry, you don't get encrypted data transmission for free because the files you are sending are themselves encrypted. I wish I could find a way to explain this better.

[besson3c]

Originally Posted by turtle777 

I would say this is EXACTLY what Twin is doing.

It's very unobtrusive, and easy for the end-user, even for non-geeks.
Twin is a rally, really smart approach to online backups.

-t

It looks great, but again, you are still far better off with a secure tunnel.

Also, technically, not to play the alpha geek role or something, but it isn't exactly what Twin is doing. Twin is encrypting the single disk image file. I was referring to encrypting each individual file that is sent from point A to point B. It wouldn't matter if you intercepted this, the binary data would be useless without something to decrypt it. This is how PGP email encryption works. If Twin were doing this it would take a considerable amount of time to encrypt and decrypt each individual file.

[turtle777]

Originally Posted by besson3c 

Sorry, you don't get encrypted data transmission for free because the files you are sending are themselves encrypted. I wish I could find a way to explain this better.

No, it doesn't freaking matter that the data transmission is not encrypted, if the files themselves are encrypted.

Why do you keep insisting that encrypted data transmission is necessary for security ? It'snot. In fact, Twin shows it doesn't matter how you transmit the files, the encryption and security is taken care of. Period.

-t

[turtle777]

Originally Posted by besson3c 

It looks great, but again, you are still far better off with a secure tunnel.

Why, why, why, why, why, why, why, why ?

See above.

-t

[besson3c]

Let's look at this a different way...

Forget files, forget file formats, think of a stream of 1s and 0s wrapped in TCP packets.

Say you were to start and stop some sort of packet sniffer that captured the last third of this entire disk image. You'd get a corrupt file first of all, and a corrupt file wrapped in an encryption layer - not terribly useful, that is granted. However, if you could somehow manage to work around this, if you were to sift through this file you'd have a jigsaw puzzle of individual files that when reassembled would form some of the files in the original DMG.

Yes, it is very unlikely that you'd be able to hack the AES encryption, but this is where the Club on the steering wheel part of my analogy fits - this part is your Clubbed steering wheel.

Compare this to a secure tunnel...

In order to sniff anything at all you would need to compromise this tunnel, and you would need to decrypt this data.


This is very subtle and admittedly academic, but again, what I said is true on technicality - this is only secure because the files themselves are encrypted, your data transfer isn't. I would say that using Twin is secure enough though.

[turtle777]

Originally Posted by besson3c 

Yes, it is very unlikely that you'd be able to hack the AES encryption, but this is where the Club on the steering wheel part of my analogy fits - this part is your Clubbed steering wheel.

Well, if this is your only objection, then for all intents and purposes, please tell carterx that Twin is safe.

If someone finds a way to hack AES 256 bit in reasonable(!!!) time, then uploading my backups to a FTP server is the least of my problems.

Can we agree on that ?

-t

[besson3c]

I never really disagreed with Twin as a solution, only with the language that you used, much as ghporter pointed out... What can I say, I'm a stickler for precision

[turtle777]

Originally Posted by besson3c 

I never really disagreed with Twin as a solution, only with the language that you used, much as ghporter pointed out... What can I say, I'm a stickler for precision

And that's fine, in the right context.

The OP, however, probably got way confused, although Twin is the safest way for him to back up on his FTP server.

-t

[ghporter]

Encrypted files move like any other file. No difference at all. This sort of file can go over insecure channels safely, and its contents are secure.

"Secure data transmission" requires an encryption device, a decryption device, and a channel between the two. Plain text data is converted into cyphertext by the encryption device, and the cyphertext is transmitted on the communication channel. The cyphertext is received by the distant end, and the decryption device converts it into plain text.

If you "own" both ends of a dedicated channel and put an encryption device at one end and a decryption device at the other end, you have a "secure channel."

The three above items are all VERY different in both technical terms and in function.

Turtle, by your description, your backups are secure, but they are not "sent securely." Rather, they are sent in the open (as an encrypted file) and stored (as an encrypted file). It looks like Twin recovers the master image and then all the delta images, then reconstructs the "current" image by merging the deltas with the master image-which is probably a time consuming process.

[turtle777]

Originally Posted by ghporter 

The three above items are all VERY different in both technical terms and in function.

Yes, in technical terms. But in function, I'm not sure it ultimately matters.

See, for the average user, all it matters is that it is secure.
Whether secured by means of encrypting the transmission, or secured by means of encrypting the data doesn't matter that much.

Actually, what Twin does is very smart. Don't trust the secure channel / transmission or the server, of which both could be compromised. If you are in control of the data encryption, even compromised transmission or storage would pose no harm to your data.

Plus, Twin achieves the same level of security no matter what protocol you use.

Like I posted in the other thread, Twin's features are really great:

• fully preserves file metadata: creation and modification dates, Finder info (e.g. label or Spotlight comments), UNIX permissions, ACLs, extended attributes...
• supports WebDAV (over HTTP or HTTPS), AFP, SMB, FTP, FTPS, SFTP, Amazon S3 (over HTTP or HTTPS), Apple iDisk
• on-the-fly top-grade AES-256 encryption
• uses efficient bzip2 compression to reduce the size of the backed up data, but is also smart enough not to waste time trying to re-compress already compressed files (JPEG images, movies, Finder archives…).
• recover previous file versions just like Time Machine

-t

[besson3c]

There are no guarantees anywhere in any chain, in general.

There are no guarantees that Twin itself couldn't be used to decrypt contents that don't belong to somebody who compromises an account due to a password sent in the clear. There are no guarantees that this proprietary software doesn't have its own security problems. Depending on how paranoid you want to be you could look at this from a number of different ways. There aren't any guarantees that simply using SFTP would be bulletproof either.

I think the way to look at this is "is it secure enough?" Twin provides enough security that these setups are not really attractive targets. There are still *tons* of people foolishly using regular FTP without encrypting their files as Twin does, so if I really wanted to compromise an account or access somebody else's files, I'd have many better choices.

That being said, if it were me I still wouldn't want to use FTP no matter if my files were encrypted or not. I would not want my account compromised even if the files gained would have no value to the attacker. Put it this way, if you have to use FTP Twin is a good bet. If you don't have to use FTP, don't. For starters, you can script these backups without proprietary software that you have to pay for, should this specific fact be of particular value to you.

[besson3c]

Originally Posted by ghporter 

Encrypted files move like any other file. No difference at all. This sort of file can go over insecure channels safely, and its contents are secure.

"Secure data transmission" requires an encryption device, a decryption device, and a channel between the two. Plain text data is converted into cyphertext by the encryption device, and the cyphertext is transmitted on the communication channel. The cyphertext is received by the distant end, and the decryption device converts it into plain text.

If you "own" both ends of a dedicated channel and put an encryption device at one end and a decryption device at the other end, you have a "secure channel."

The three above items are all VERY different in both technical terms and in function.

Turtle, by your description, your backups are secure, but they are not "sent securely." Rather, they are sent in the open (as an encrypted file) and stored (as an encrypted file). It looks like Twin recovers the master image and then all the delta images, then reconstructs the "current" image by merging the deltas with the master image-which is probably a time consuming process.

Well summarized! You seem particularly good at being succinct and speaking with clarity, something that I envy!