If you specify HTTP for an HS-enabled Site, EFT Server prompts you to disable these unsecure protocols, or continue with reason. |
HTTP is the communication protocol for establishing a connection with a Web server and transmitting HTML pages to the client browser or any other files required by an HTTP client application.
HTTP is often referred to as a "stateless" protocol. The connection is maintained between client and server only for the immediate request, after which the connection is subsequently closed. Each time you need something from EFT Server, your client (browser) makes a connection, gets that file, and then the connection is closed. Since you do not connect and stay connected, the browser remembers your username and password for you, so it can send the authentication hash along with every new connection request.
For example, when you type http://www.globalscape.com/eft/whatsnew.aspx in your browser's address bar and press ENTER, your browser uses HTTP as specified in the URL to send a command to EFT Server running at the host name www.globalscape.com with the HTTP command "GET /eft/whatsnew.aspx HTTP/1.1," and EFT Server replies with that file (the HTML that makes up the page). In that page, there are references to a number of files (e.g., images, CSS documents, flash files), and your browser makes a separate connection to get each one of those resources.
EFT Server is primarily a file transfer server, not a Web server. This means it is not meant to "serve up" Web pages such as a typical Web server does for connecting HTTP clients (such as your Web browser). However, there are provisions for transferring files in the HTTP protocol, which is a convenience when a connecting partner, customer, or employee does not have an FTP client installed, but does have an HTTP client or access to a Web page with HTTP PUT capabilities (usually an ActiveX control or Java applet).
When EFT Server is configured to allow HTTP file transfers, any HTTP client will be able to PUT (upload) or GET (download) files to EFT Server, provided the client supports both of these HTTP commands. Most Web browsers only support the GET command or, if they support the PUT command, they provide no interface for browsing to the user's local file system to select and upload (PUT) files onto EFT Server. A few dedicated clients (such as CuteFTP Professional) and various thin clients (based on ActiveX controls or Java applets) support both PUT and GET capabilities, allowing these clients to transfer files to EFT Server in both directions. (For more information about standard HTTP/1.1 methods, refer to http://tools.ietf.org/html/rfc2616#section-5.1.1.)
In addition, EFT Server supports a subset of the WebDAV protocol, which is an extension to HTTP that adds more methods. Supported WebDAV extensions in the list below are used by the EFT Server Plain-Text Client, ClientFTP, and the CuteFTP application. (Refer to HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV) http://tools.ietf.org/html/rfc4918#section-9 for more information.)
Method |
EFT Server Support |
9.1. PROPFIND Method |
NOT supported |
9.2. PROPPATCH Method |
NOT supported |
9.3. MKCOL Method |
Supported |
9.4. GET, HEAD for Collections |
Supported |
9.5. POST for Collections |
Supported |
9.6.1. DELETE for Collections |
Supported |
9.7.1. PUT for Non-Collection Resources |
Supported |
9.7.2. PUT for Collections |
Supported |
9.8. COPY Method |
NOT supported |
9.9.1. MOVE for Properties |
NOT Supported |
9.9.2. MOVE for Collections |
Supported |
9.9.3. MOVE and the Overwrite Header |
NOT Supported |
9.10. LOCK Method |
NOT Supported |
9.11. UNLOCK Method |
NOT Supported |
10. HTTP Headers for Distributed Authoring |
NOT Supported |
10.1. DAV Header |
NOT Supported |
10.2. Depth Header |
NOT Supported |
10.3. Destination Header |
Supported |
10.4. If Header |
NOT Supported |
10.5. Lock-Token Header |
NOT Supported |
10.6. Overwrite Header |
NOT Supported |
10.7. Timeout Request Header |
NOT Supported |
EFT Server allows you to customize messages sent by EFT Server upon connection, login, maximum connections reached, and disconnect (for FTP sessions). Due to the nature of the HTTP protocol, custom login messages are not displayed for connecting HTTP clients.
Another limitation of HTTP is that after a connection is established, the browser sees EFT Server's root folder instead of the user's home holder. A workaround is to setup a distinct Site (In the Administrator, a Site is similar to a virtual FTP server bound to one or more IP addresses.) for HTTP sessions.
Microsoft Internet Explorer browsers that have installed MS04-004 Cumulative Security Update for Internet Explorer (832894), no longer support URLs that contain username info, even though they are properly formed URLs. This problem is unique to Internet Explorer, and does not affect the other major browsers. For more information, refer to http://www.microsoft.com/technet/security/Bulletin/MS04-004.asp.
If you create an Event Rule that sends a notification e-mail for each successful login event, an e-mail is sent every time a user connected through HTTP changes directories. This is a result of HTTP being a stateless protocol and can result in a large volume of notification e-mails even when performing typical directory browsing.
HTTPS is the protocol for accessing a secure Web server when authentication and encrypted communication is possible. Using HTTPS in the URL instead of HTTP directs the message to a secure port number rather than the default Web port number of 80. The default TCP/IP port of HTTPS is 443. The session is then managed by a security protocol. HTTPS encrypts the session data using the SSL (Secure Socket Layer) protocol ensuring reasonable protection from eavesdroppers and man-in-the-middle attacks.
Secure Socket Layer (SSL) is a protocol for encrypting and decrypting data across a secure connection from a client to a server with SSL capabilities. EFT Server is responsible for sending the client a certificate and a public key for encryption. If the client trusts EFT Server's certificate, an SSL connection can be established. All data passing from one side to the other will be encrypted. Only the client and EFT Server will be able to decrypt the data. The SSL protocol is the same protocol used in FTPS.
The following elements work together to establish a secure HTTPS connection:
Client: The client must have SSL capabilities.
Certificate: Certificates are digital identification documents that allow both servers and clients to authenticate each other. A certificate file has a .crt extension. Server certificates contain information about your company and the organization that issued the certificate (such as Verisign or Thawte) while client certificates contain information about the user and the organization that signed the certificate. You can choose to either trust or distrust a certificate. In some cases, the client's certificate must be signed by EFT Server's certificate to establish an SSL connection.
Session Key: The client and EFT Server use the session key to encrypt data. It is created by the client via EFT Server’s public key.
Public Key: The client encrypts a session key with EFT Server’s public key. It does not exist as a file, but is produced when a certificate and private key are created.
Private Key: EFT Server's private key decrypts the client's session. The private key has a .key extension and is part of the public-private key pair.
Certificate Signing Request: A Certificate Signing Request (CSR) is a PKCS10 request, which is an unsigned copy of your certificate. A certificate signing request is generated each time a certificate is created. A certificate signing request has a .csr extension. This file is used when you need to have your certificate signed. Once the Certificate Signing Request file is signed, a new certificate is made and can be used to replace the unsigned certificate.
In Web pages that use HTTPS, the URL begins with https rather than http. HTTP clients should connect using standard requests (i.e., https://domain_name). You can configure EFT Server to provide connecting clients with a certificate, and can require that the client provide a certificate upon connection (to validate the client's identity further). |