How do you enforce SSL connections per repository or per server rather than giving the client an option?
Hi Chad,
The only way to force SSL connections on the server side is by disabling port 80. That way, when a user tries to connect through a non-SSL connection they will be unable to do so. I believe they are also working on a more user-friendly way of allowing for this configuration, but at the moment this is your best bet.
Thanks Kelsey! Is this something I can disable from the Administration Console?
Are you talking about the client as in the Laserfiche Client or one of the web products?
If it's the web products, IIS can force SSL connections if you select the application and open up the SSL feature module:
For the client, I am looking for that exact same setting we use in IIS for Web Access but for those using the Client application.
See this forum thread.
On the workstation, go to HKEY_LOCAL_MACHINE\SOFTWARE\Laserfiche\Client8\Profile\Settings (or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Laserfiche\Client8\Profile\Settings for x64 computers) and create a new string called UseSSL and set it to Yes.
This will force all users from the workstation to log into any repository on any server using SSL.
Thanks Alex, in this case we have no access to the workstations. It is a SAAS deployment. How do I configure this server side?
The option in Devin's screenshot encrypts the traffic between the browser and the web server. IIS takes care of that for you. If you want to encrypt the traffic between the web server and the Laserfiche server, that would be a separate configuration.
Since the Laserfiche Server has multiple types of clients and not all of them support connecting over SSL, there isn't a master switch in the server that would only allow it to accept SSL traffic. So it has to be done per client machine as Alex mentioned above, and even in that case, older versions of Laserfiche software may ignore the setting.
I feel like the security risk it too high to not restrict at a server level. User names and passwords are readily available in the network traffic.
I think if I could disable the port 80 like Kelsey recommended that would work, as long as QF has an SSL option. I am not worried about older client versions, we would require newer versions in secure implementations.
Quick Fields 8.3 and higher will work.
Blocking port 80 works fine for ensuring an LF Desktop Client doesn't connect over an unencrypted connection when you don't have the option to enforce that through the available registry values on client workstations.
However, this breaks the ability to connect with LF Admin Console. Even when you tell LF Admin to connect to an LF Server using SSL, 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, 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 ===> 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, works fine, as 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 then make custom FW rules to accommodate this solution.
Is there solution (other than what I've painted above) that meets the requirements?:
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.
The above comment has been responded to in a separate thread. Further comments on that topic should be directed there.