In a default installation, the Pentana client is configured to connect to its service via http (rather than https).  On first inspection this seems insecure, and the natural response is to change the system so that the connection is via https. 

Is it necessary to switch?

We are trained to see https as desirable, and http as undesirable.

Under 'normal' circumstances, i.e. where a Web browser is used, this is good - with http, traffic between the browser and the Web server is transmitted unencrypted and so if intercepted can be read quite easily.  Https encrypts the connection.

However, there is a still a risk here, which is what's called the 'man in the middle' attack - someone sat in the right place on the network can intercept the traffic and decrypt it without the system noticing.

As Ideagen Internal Audit (Aura) is not a browser application we are able to encrypt the traffic in a different way, using message security.  With this, each individual message is encrypted (rather than the connection carrying the messages), and the way that this is done means that even if an attacker is able to steal the traffic they can't decrypt the messages. 

The framework that we use for this is Microsoft's WCF, and they document the situation as follows:

Transport security, such as Secure Sockets Layer (SSL) only secures messages when the communication is point-to-point. If the message is routed to one or more SOAP intermediaries (for example a router) before reaching the ultimate receiver, the message itself is not protected once an intermediary reads it from the wire. Additionally, the client authentication information is available only to the first intermediary and must be re-transmitted to the ultimate receiver in out-of-band fashion, if necessary. This applies even if the entire route uses SSL security between individual hops. Because message security works directly with the message and secures the XML in it, the security stays with the message regardless of how many intermediaries are involved before it reaches the ultimate receiver. This enables a true end-to-end security scenario.

 (From:  https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/message-security-in-wcf)

In summary - even though the connection from client to service is via http, the data is encrypted before it is transmitted and can be more secure then if relying on https for encryption.

Switching from http to https - why it can break an existing implementation

While it is possible to make config changes such that the service end point listens on https, there can be knock-on effects: 

• Where the client is deployed via ClickOnce, the location used for the initial download is checked for updates.  This means that if a client is installed from http://server.domain.com, but then the URL changes to https://server.domain.com, the client will not find the distribution location and will not automatically update.  The workaround to this is to uninstall the client and then reinstall from https://server.domain.com

Making the change

We can convert the configuration such that the main service connects via https if requested to.  

Note that changing the service requires numerous configuration changes.  The http:// endpoint appears in most of the service configuration files, but it is not enough to just change these references - each also has to contain additional XML to support transport security.  Reference files are attached to this article.

The server must already have an SSL certificate installed.

The procedure below assumes:

• Default paths were used during the install
• There is a correctly configured App Manager and instance file on the server
• That ClickOnce is used (if Xcopy or MSI deployment, then the file vision.exe.config within the deployment is the one that must be updated).

The steps are as follows: 

• Stop the Pentana Robot service
• Stop the Pentana and PentanaWeb application pools
• Back up the following files:
•  from the application instance in IIS:
  ClickOnce\XtraDeploy\vision.exe.config.xml
  FBA\Web.config
  Service\Web.config
  WebService\Web.config
  WebUI\Web.config
  
  
• From Program Files (x86)ServerRobot\[pentana instance name]\:
  Pentana.Tng.ServerRobot.RobotService.exe.config 

• The reference zip file contains a set of config files.  Replace each on the server with its equivalent in the zip file
• Open App Manager, and open the correct instance
• Go to the [config] tab and click [Replace Variables]
• This will update the configuration but will not rebuild the ClickOnce package, so click [Rebuild LocalDB] - this will rebuild the local database but will coincidentally rehash the package, which is what we're needing to do
• Restart the application pools
• Restart the Robot service

 Test:

• In the Robot application folder, open the log file and check that the startup tests passed
• Open the Pentana client - it should update and login without error
• Open the WebUI - it should login without error