You are viewing limited content. For full access, please sign in.

Discussion

Discussion

There is a ghost in the machines with STS servers

Directory Server
Updated June 18, 2021
posted on June 17, 2021

The following box is getting checked on server's in the STSEndpointUtility on it's own and it breaks the Laserfiche login page. I know this has been reported but it is still a concern since it is a full system outage.

Most of these servers do not even use a secure socket layer for STS because all services are on the same system. It is impossible to setup a socket layer without a network socket.

0 0
replied on June 17, 2021

All that checkbox does is make STS communicate with LFDS over HTTPS on port 5049. You can easily bind an appropriate certificate (valid for the LFDS FQDN hostname value set in STSEndpointUtility) in the LFDS XmlEndpointUtility. During install/upgrade, I believe STS will preferentially select the secure default of the HTTPS option. If you have LFDS and STS on the same machine and aren't concerned with encrypting localhost traffic (which to be clear is still happening over HTTP/S), uncheck "Use SSL" in the STSEndpointUtility during install/upgrade.

I'm not personally aware of any open bug where STS sets this option of its own accord, without user interaction, outside the install/upgrade scenarios outlined above. If you are, please let me know the bug or support case # and I'd be happy to follow up.

Re:

Most of these servers do not even use a secure socket layer for STS because all services are on the same system. It is impossible to setup a socket layer without a network socket.

As described above, this statement misunderstands the communication type and path in question. Checking "Use SSL" makes STS attempt to communicate with the LFDS service on port 5049 using the HTTPS protocol over TCP, secured with TLS 1.2 (and enforced X.509 certificate validation), instead of on port 5048 over HTTP. None of these elements changes depending on whether the destination IP is the local machine's or a remote one.

1 0
View 3 previous replies
replied on June 18, 2021 • Show version history

This is correct, on clean install of 10.4.3+ and upgrade from older LFDS versions to 10.4.3+ we intentionally check that box because it is important to have STS default to encrypting sensitive data out of the box. If you perform an upgrade later or a reinstall, your preference will be preserved. This document (point #2) outlines the certificate requirements if you would like to secure the channel between STS and LFDS.

1 0
replied on June 18, 2021

How would I view these service to service packets in Wireshark? Is it using the network interface to talk to itself, like a loopback? Even so no one would ever be able to capture it without direct access to the OS.

I would like to provide more information on how to reproduce this, but here is all I know so far.

A system will go down, and we find this box is checked. This box is inside of a hidden utility buried in the program files folders. I can not imagine any IT personnel finding and opening this utility on so many systems across the board. That is why I call it a ghost, it just seems improbable. These are not new installations, they are systems that have been running for months to years.

As soon as I get any more information on this to re-produce I will provide it, but I know something is off with this utility.

0 0
replied on June 18, 2021

I have revised my above statement, this can happen on upgrade from pre-10.4.3 to 10.4.3 or above. This is because pre-10.4.3 utilized WCF which included encryption out of the box whereas 10.4.3+ uses HTTP (requires configuration for HTTPS), and we need to ensure customers do not have their systems become less secure upon upgrade.

This should explain how this box gets checked on long running systems.

1 0
replied on June 18, 2021

Ok well 10.4.3 is the latest non-11 package, so it has likely been installed on a lot of systems.

I am still confused as to the security concerns of local service to service connections.

I am personally more concerned with encrypting network traffic first, for example with Laserfiche installations we are still using the old registry hack to enable encryption (there is no feature for it in the administration console) on the Laserfiche service, because when the client or administration console connects it is sending network traffic.

0 0
replied on June 18, 2021

When LFDS and STS are installed on the same machine, there are no security concerns with using plain HTTP for LFDS <-> STS communication unless someone has done something very strange with their machine's networking that exposes loopback traffic to the network.

We check this "Use SSL" box (more accurately labeled "Use TLS" in LFDS 11) automatically regardless due to Laserfiche's policy of establishing secure defaults.

1 0
replied on June 18, 2021

STS doesn't know if it's local to LFDS, and standalone STS instances in network DMZs are quite common. Laserfiche applications moving to use more secure defaults isn't a bug. And general FYI that as of 10.4.3, all Laserfiche applications are using .NET 4.7.1 or higher and no longer need the registry hack to use TLS 1.2.

In any event, I don't see what useful information Wireshark would provide at this stage. The call STS is making is essentially "https://lfds.example.com:5049/stuff".  

Start by checking the WebSTS event logs and see why it reports it can't connect to LFDS over HTTPS. I'll bet a beverage of choice that there's something missing/wrong with the certificate binding on port 5049, which you can set via the LFDS XmlConfigurationUtility. Chase has clarified when the change can happen, so decide if you want to turn the setting off at install/upgrade time, or get the cert straightened out so HTTPS works even if it's less important to encrypt local traffic.

There's a reason the LFDS and STS endpoint config utilities are automatically launched as part of the install/upgrade process, which is so you can review configurations like this. 

The STS EndpointConfigUtility is nothing but a small WinForms app that provides a GUI to set three endpoint address values in the WebSTS web.config file's <client> node:

<client>
  <endpoint address="https://lfds.example.com:5049/LicenseManager/service" binding="ws2007HttpBinding" bindingConfiguration="WS2007HttpBinding_ILicenseManager" contract="LicenseManagerService.ILicenseManager" name="LicenseManagerService">
	<identity>
	</identity>
  </endpoint>
  <endpoint address="https://lfds.example.com:5049/LicenseManager/service" binding="ws2007HttpBinding" bindingConfiguration="WS2007HttpBinding_ILicenseManager" contract="LicenseManagerService.ILicenseManager2" name="LicenseManagerService2">
	<identity>
	</identity>
  </endpoint>
  <endpoint address="https://lfds.example.com:5049/LicenseManager/sts" binding="ws2007HttpBinding" bindingConfiguration="WS2007HttpBinding_ILFSecurityTokenService" contract="LicenseManagerSTS.ILFSecurityTokenService" name="LicenseManagerSTS">
	<identity>
	</identity>
  </endpoint>
</client>

 

1 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...