Non EXE file download?

[slezberg]

I want to post an update using the following URL as the download

http://support.deltek.com/Distribution/download.aspx?src=ou&fn=DeltekVision20SP1

But the Update Service requires a .EXE extension.

I dont want to post a file on a regular HTTP location as I dont want to expose it without some sort of authentication check before the file can be downloaded.

Any ideas?

Thanks

Scott

[Chris_Woerner]

Scott,

I'm interested. Tell me more. What type of security do you want for your download server? (user name/ psed) Are you using a third party tool to do this, or is this IIS authentication? If you aren't specifying the full path to the EXE, is the browser redircted to the full path?

[crehbein]

This thread was abandoned a while ago, but this is still a big problem with updates and authentication even in the 3.1 release.

I think the original poster's desire was to use a URL that doesn't point directly to the executable. When the update agent pulls the download, there's no way to wrap that transmission around authentication. Even though the URL of the download isn't necessarily exposed to the user, the current US model doesn't allow companies to protect their distributable -- it still needs to sit out there on a public web server.

The authentication support in the ISUS is merely a smoke screen hiding the fact that the distributable is publically available anyway. Even if our company supported authentication prior to updating, what's to stop someone from just taking a lucky guess at what we entered as the URL to the distributable? There's no means to program the agent to use a password-protected ftp account, for example, or to pass data in when the file is downloaded (such as an HTTP POST). My update is dangling out there in cyberspace, waiting for anyone (authorized or not) to grab it.

Of course, there are ways to protect it using non-US means, such as a separate serial number just for patches, but that doesn't always work out with other licensing schemes. Besides, I don't believe that InstallShield .cab files can't be unpacked, giving out the goods anyway.

What I would suggest is allowing companies to point the download URL's to a customer-controlled script, not just an .exe living on a web server or an internal file server. The agent needs to be able to pass data to this script much like it passes data to the authentication URL. The customer can then write their own logic to handle downloads and prevent unauthorized users from downloading the patch.

Just a suggestion.

- C

[Chris_Woerner]

We are very interesting in making the ISUS secure. One idea that we are considering is to encrypt the download files. That way, they won't do anyone any good to download. Only the ISUS Agent would be able to do the de-cryption. That may be another way to solve your problem. I'm curious to hear your thoughts on this.


In answer to your specific request, we can certainly have the Agent call a server side script, passing authentication data. However, how would the Agent get the file to download? If the script returns the URL, the Agent would have to request the file from the server. I'm not sure that helps with security. Or is there a way for the script to "hand" the update back to the Agent in resonse to the Agent calling the server side script? If so, how would we handle restarts on broken connections?

[crehbein]

Originally posted by Chris Woerner
One idea that we are considering is to encrypt the download files. That way, they won't do anyone any good to download.

That's not a bad idea at all. A similar idea posed by my boss was to zip & password-protect the executable, but that can't work with the current update agent model.

However, how would the Agent get the file to download? If the script returns the URL, the Agent would have to request the file from the server. I'm not sure that helps with security. Or is there a way for the script to "hand" the update back to the Agent in resonse to the Agent calling the server side script? If so, how would we handle restarts on broken connections?

The script would have to serve the executable directly (ie, can't use a client-side refresh/redirect), perhaps by returning the data in the http response. Not being too savvy with asp or jsp, I wouldn't know how to tackle restarts, but I feel a sufficiently smart web programmer could tackle that problem, especially if the agent can communicate the incomplete exe's size to the script.

I don't think many companies would want or need this level of security around their patches, though. Allowing the agent to use ftp credentials should be enough for most folks. FTP could easily be accomplished without drastic changes to the update service by allowing the download URL to use standard FTP URL schemes:

ftp://user : pass@ftp.site.com.

Since HTTP & FTP are clear-text protocols, however, it's not bulletproof, so persuing a server-side solution including SSL support for distributing the file might be best in the long term.

I do like the idea of encrypting the single-exe setups. Encryption could be one additional step while building a patch, and the agent can handle decryption at the client's end. Combine this with FTP access or access to a script via a secure HTTP layer, and the CSOs will be happy.

Cheers,
- C