Avoiding documentation work

[Lowe, Phillip (DOH)]

One of our partners sends to multiple states.  We are slowly working towards moving to PHINMS 3.1 but it will be later in the fall.  They have a mandate to move to 3.1 for another state by June 30^th.  I am hoping someone has instructions for installing two copies of PHINMS on a single machine so they can add version 3.1 running on a separate TOMCAT instance.  That will allow them to send to both 2.9 (ours) and (3.1) until we get time to do the upgrade.

 

Thanks!

 

Phill Lowe – 360 236-4261

 

[Schneider, Edward (MNIT)]

I have a copy of some old ones that seem to have originated with New York State.  They're of early PHINMS v. 2.8.x vintage.  Unfortunately only in hard-copy, at this point.  The main points are to adjust port designations in Tomcat server.xml file after initial "finish the install and do nothing further," and adjust the corresponding port assignments in phinms.properties file, so as to avoid port duplications between the PHINMS instances.  Then modify the appserver\bin\service.bat to alter the SERVICE_NAME and PR_DESCRIPTION for the Tomcat instance, and the sc start Tomcat instruction to match the new SERVICE_NAME, and REM out the sc stop and sc delete line for old services.

Next, run the service.bat install as altered.

Then change the hsqldb 1_install_service.bat file:  REM out the sc stop and sc delete lines for the default database and save that file as changed.

Alter the wrapper.conf file in the hsqldb folder to give a new, unique description to the wrapper.ntservice.name, the wrapper.ntservice.displayname and the wrapper.ntservice.description.

Finally, return to the 1_install_service.bat: re-edit it to replace the sc start PHINMSDefaultDatabase with sc start [name change from the wrapper.ntservice.name designation], save the file, and run it.

Of course, those instructions assumed one was installing two instances of the same PHINMS version.  But the alterations needed for modifying port numbers and the like for different PHINMS installation versions would just entail making the changes in the second-install batch files identified above.

Edward A. Schneider

Information Technology Specialist/Middleware Administration | Application Data Services Unit

Minnesota IT Services | Partnering with Minnesota Department of Health
625 North Robert St.
P.O. Box 64975
St. Paul, MN 55164-0975
O: 651-201-4047
Information Technology for Minnesota Government | mn.gov/mnit

---

From: phi...@googlegroups.com <phi...@googlegroups.com> on behalf of Lowe, Phillip (DOH) <Philli...@DOH.WA.GOV>
Sent: Thursday, June 7, 2018 5:51:16 PM
To: phi...@googlegroups.com
Subject: Avoiding documentation work

 

One of our partners sends to multiple states.  We are slowly working towards moving to PHINMS 3.1 but it will be later in the fall.  They have a mandate to move to 3.1 for another state by June 30^th.  I am hoping someone has instructions for installing two copies of PHINMS on a single machine so they can add version 3.1 running on a separate TOMCAT instance.  That will allow them to send to both 2.9 (ours) and (3.1) until we get time to do the upgrade.

 

Thanks!

 

Phill Lowe – 360 236-4261

 

--

---
You received this message because you are subscribed to the Google Groups "PHINMS User Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phinms+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Frans de Wet]

If they are a sender there should be no mandate to upgrade that I am aware of. The receiver controls the supported TLS encryption. I see customers are still happily sending with PHINMS 2.7 to the AIMS Platform and we have only the most secure TLS layers enabled. 

It is odd that the state mandates 3.1. They may just be upgrading to 3.1 on that date. 

Thanks,

Frans

--

[Lowe, Phillip (DOH)]

This is not one of our more technically savvy partners but they were pretty clear on the point that they needed to upgrade by June 30^th  so they could continue to report.  Could be that Iowa is planning on requiring TLS 1.2 at that point.  Do we know who to talk to there?

 

 

 

Phill Lowe – 360 236-4261

[Francis de Wet]

I will get with our team to get the contact for Iowa.  They (Iowa) can upgrade to TLS1.2 any time, even without upgrading PHINMS by editing the Tomcat config ... although a newer Tomcat is probably always a good idea, which is what they are doing if they are going to 3.1.  The clients (aka senders) will just happily comply if they are not too old (would have to be very very old). 

We require TLS 1.2 and we have no issues with even PHINMS 2.7 communicating with the AIMS Platform.   

Thanks,

Frans de Wet Founder | Ruvos fr...@ruvos.com | www.ruvos.com | c: 1-850-445-7696

[Eduardo Gonzalez Loumiet]

John Satre. I'll reach out. 

Eddie

[Schneider, Edward (MNIT)]

The original New York state instructions are attached.

Edward A. Schneider

Information Technology Specialist/Middleware Administration | Application Data Services Unit

Minnesota IT Services | Partnering with Minnesota Department of Health
625 North Robert St.
P.O. Box 64975
St. Paul, MN 55164-0975
O: 651-201-4047
Information Technology for Minnesota Government | mn.gov/mnit

---

From: phi...@googlegroups.com <phi...@googlegroups.com> on behalf of Schneider, Edward (MNIT) <edward.s...@state.mn.us>
Sent: Thursday, June 7, 2018 6:23:53 PM

To: phi...@googlegroups.com
Subject: Re: Avoiding documentation work

 

I have a copy of some old ones that seem to have originated with New York State.  They're of early PHINMS v. 2.8.x vintage.  Unfortunately only in hard-copy, at this point.  The main points are to adjust port designations in Tomcat server.xml file after initial "finish the install and do nothing further," and adjust the corresponding port assignments in phinms.properties file, so as to avoid port duplications between the PHINMS instances.  Then modify the appserver\bin\service.bat to alter the SERVICE_NAME and PR_DESCRIPTION for the Tomcat instance, and the sc start Tomcat instruction to match the new SERVICE_NAME, and REM out the sc stop and sc delete line for old services.

[Schneider, Edward (MNIT)]

I am going to invite the Ruvos participants (and any others who care) to address the issue of cipher suite usage, particularly in conjunction with PHINMS v. 2.7 and 2.8.

If one is not using a proxy for outbound PHINMS transmissions, in a situation where the proxy sets the available cipher suite(s) for use, I believe the level of Java's JDK is going to determine what ciphers are available for encrypting the outbound transmissions.  The default available cipher suites for Java 6 and Java 7, respectively, can be found at:

https://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider

https://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider;

If one reviews the lists, one quickly becomes aware, particularly with Java 6, that many of these are not state-of-the-art encryption capabilities; but even with Java 7, the JDK version used with PHINMS v. 2.9 and 3.x, the default choices consist in substantial part of ciphers with a CBC component (which has been shown to suffer potential compromise vulnerabilities).  With the default JDK that was distributed with PHINMS v. 2.8 (JDK6u3), cipher suites such as RC4 were still in the mix--RC4 has been deprecated for quite a while.   So there's an implicit limit on the security that is enforceable, even if the receiver selects the highest available cipher suite which the sending PHINMS is capable of using.  Moreover, if one is terminating with a Tomcat endpoint (which would again be the option if no intervening proxy sets SSL/TLS encryption for incoming transmissions), before Tomcat v. 8.5.x, capabilities for a receiver to set cipher suite preference are close to nonexistent if the default JSSE is used as a PHINMS connector.  (There may be more flexibility if the APR connector is used, but that's not the default.)

In a better world, we'd presumably be using forward secrecy in ciphers with GCM components.  An interesting discussion of the general interaction between Tomcat, Java, and available connectors--which discussion is still fairly current--can be found in Ivan Ristic's Bulletproof SSL and TLS, pages 440-451.

Edward A. Schneider

Information Technology Specialist/Middleware Administration | Application Data Services Unit

Minnesota IT Services | Partnering with Minnesota Department of Health
625 North Robert St.
P.O. Box 64975
St. Paul, MN 55164-0975
O: 651-201-4047
Information Technology for Minnesota Government | mn.gov/mnit

---

From: phi...@googlegroups.com <phi...@googlegroups.com> on behalf of Francis de Wet <fr...@ruvos.com>
Sent: Thursday, June 7, 2018 6:36:53 PM