With a cloud/internet hosted solution, it's critical to ensure that no end user accidentally connects to the LF server over the internet with an un-encrypted connection. When clients use WebAccess, this is easily enforceable at the server via IIS configuration for enforcing HTTPS connections and redirecting non-HTTPS’d connections. But for the LF desktop, there’s no server side enforcement mechanism.
This is discussed in other "answers" topics, and the recommendation is to implement a setting in the registry of client machines that enforces HTTPS/SSL’d connections only. But there are many scenarios where the client is unwilling or unable to manage that across their entire deployed base of LF desktop clients. In this event, the recommendation then is to block inbound TCP 80 to the LF server at your firewall.
While this works successfully to ensure LF Desktop Clients can't connect over an unencrypted connection, it then breaks the ability to use the desktop LF Admin Console… which we find users still prefer to use over the WebAdmin solution.
This is true EVEN when you tell LF Admin to connect to an LF Server using SSL, because as part of initializing the connection to a repository, the admin console still makes a connection over TCP 80.
Using Wireshark to analyze the traffic, I find this pattern of communication occurs before you actually get to the point of being prompted for a login to a repository:
1) admin console <=== TCP 443 ===> LF Server
2) admin console <=== TCP 80 ===> LF Server
3) admin console <=== TCP 443 ===> LF Server
The second communication appears to request data about the repository’s configuration, and the response is a MIME formatted response described as "application/vnd.laserfiche.report".
Without that data, the admin console fails to progress to step 3, which is where you get the prompt to log into your repository. So you get...
1) admin console <=== TCP 443 ===> LF Server
2) admin console <=== TCP 80 ===X (blocked) LF Server
... and never progresses to connecting to the repository
So... blocking port 80 to ensure no accidental unencrypted client connections works fine, but breaks admin console connectivity.
That communication in step two determines the destination port dynamically, so changing LF Server's "listening port" value from 80 to something non-standard, like port 81, you'll see:
1) admin console <=== TCP 443 ===> LF Server
2) admin console <=== TCP 81 ===> LF Server
3) admin console <=== TCP 443 ===> LF Server
This works fine, but requires you to deviate from common ports to non-standand ports, and make one-off FW rules to accommodate this solution.
That's all do-able, but the real question is.. why does the admin console make an HTTP/TCP80, non-SSL’d connection in the middle of a communication that it was told to use SSL for?
Am I missing something here? Or is there a solution (other than what I've described above with my port 81 example) that meets the requirements of:
a. ensuring no un-encrypted desktop client connections can occur
b. keeps the admin console working without switching LF server listening port to non-standard.
This becomes increasingly relevant with more users moving to cloud based hosting of their LF installations.