Hi Evan, 

I recommend looking at our FTP docs (doc 1) (doc 2) on the community site if you have not already done so.

Outside of this, I always recommend customers try using the API to do operations rather than FTP. There are several guides here on API actions, including file operations. Something I've found specifically helpful is the Box CLI - that may be the best of both worlds for your situation. It would allow you to do quick and easy file operations, but you would not have to code something extravagant to get the job done. 

Thanks, 

Alex, Box Developer Advocate 

@AlexNovotny,
     Can we assume by your comment above, the API calls encrypt the traffic?  Can you describe the level of  encryption?  Are the API calls made over HTTPS?

Rick

Telling people to learn and use the API is a bit extreme when all they want to do is use FTP to upload a load of data for a 1 time operation. One of our users has also recently come across this and is questioning whether its safe to use. What am i suppose to tell them? go and learn the API?

If Box cannot resolve the TLS issue (as other providers have done) then it seems appropriate to publish clear guidelines for customers that are considering or continuing to use the FTP upload option.  At a minimum, Box can you please respond more thoroughly to the concerns and questions posted here?  Thank you!

Hey Evan,

I am a product manager for the Uploads & Downloads and I want to chime in to better understand the ask.

But first thanks for your message which describes the issue very well. I also want to reassure that Box aims at maintaining the highest standard when it comes to security and compliance and I would be happy to prioritize any effort that would help us make progress on that front.

Now about the TLS session resumption, I have a couple of questions that would help us understand your ask:
- Not supporting TLS session resumption doesn't mean that TLS is not used anymore, the connection is still going to require a TLS session to be established when you click 'OK' on the 'Insecure FTP data connection' dialog). A first consequence (which is not new) is that for every new connection FileZilla will have to re-establish the TLS session every time = additional latency. Is my understanding correct? 
- From a security benefit perspective I must admit I struggle to find proper documentation around this setting and what it does (after a quick check, I don't see any reference to this in the FTP RFC). My guess is that it helps reduce the risk of an attacker 'stealing' an FTP connection but only for subsequent connections (if any). The risk is still there for the first connection (and this is why we do not recommend FTPS for sensitive content transfer), is my understanding correct?

Thanks in advance for your cooperation on this one,

Jacques

A couple of quick comments:

1\ the 'error' message I indicated in the OP no longer pops up using the latest FileZilla (3.56.2). 

2\  TLS resumptipon is well-documented all over the place. See for example CloudFlare's page on same: https://blog.cloudflare.com/tls-session-resumption-full-speed-and-secure/

3\ Box and FileZilla should talk - directly. It gets annoying when the users (like me) have to act as middle-men between cloud host on one side (Box), and client connection software on the other (FileZilla). So, why not simply talk to the FZ devs? 

278156538 +1 on your comments above except the first: have you exited and re-started FZ to connect to Box?  I find that the OP issue recurs consistently with 3.56.2 but a fresh start of FZ is required. 

Yes -- my FZ is set up to automatically exit after transfer complete. No TLS resumption error messages at all since updating to 3.56.2. 

But, seems as I might be 'lucky', since you seem to still be seeing the error/warning. Either that, or something 'funky' (from the Latin) at your end. You could always blow away all the old Box certificates, and 'start over'. 

Also, if it matters, I'm using 'protocol FTP', point at ftp.box.com, and 'Require explicit FTP over TLS'. 

278156538 possible you selected "Always allow insecure data connections for this server in future sessions." 

Possibly. That FZ 'feature' never worked very well, so I stopped using it. But, perhaps it was flipped at one point. I can't tell from my Box site manager. 

At any rate - original comment stands. Box needs to talk to FZ (and stop pretending everyone is going to use a browser to transfer file, or has the technical chops to work directly with the API), and FZ needs to play nice with cloud services it is not getting $$$ from (like Dropbox). 

278156538 site manager apparently hides the setting once it's set, but it's stored in a config file I found you can safely edit or delete to return the setting to its original/default/unset state.  Reference this file: appdata\roaming\filezilla\trustedcerts.xml

Bottom line: FZ client tool reports that Box server has a known security vulnerability. We can choose to ignore the warning each session, or configure FZ to ignore the warning in future sessions, or even use a different FTP tool altogether and never see the warning.  Regardless, the issue persists and the questions remain: 1) will Box fix this issue and if so when, and 2) will Box publish guidelines on appropriate use?

380382724394 above you state "this is why we do not recommend FTPS for sensitive content transfer" and I'm curious where that's stated?  If that's the official guideline then I believe it deserves more prominence and attention than this 8 month old support thread.

The only guideline that I see published is "we do not recommend using FTP as your primary access method."

380382724394 Any updates on Box adding this security feature to FTP? It's been almost 3 years since this issue was first reported.