Skip to main content
Solved

11.32 JAVA GUI connecting to ipm.commvault.com

  • 20 June 2024
  • 9 replies
  • 121 views

Hi,

 

after upgrading from CV 11.28.100 to 11.32.56, my customer noticed that the JAVA GUI is suddenly trying to connect to: ipm.commvault.com. From a security perspective, they would like to know:

 

  • Why is it trying to connect to that host?
  • What data is being sent?
  • Can this be disabled somehow?

 

Any suggestions?

Thanks in advance!

9 replies

B
Rank
Userlevel 5
Badge +13

Hi @Patrick Dijkgraaf,

 

How are you accessing the Java GUI?  Is this a locally installed Commcell Console package?  If not and you’re using web-based access, are you leveraging netx.jar, or using the galaxy.jnlp file with Java Web Start?

 

I am trying to reproduce this in my lab and at this moment I am not seeing an external connection attempt.  If you can share how you are accessing the Java Console, and let me know exactly where you are seeing that connection attempt to ipm.commvault.com I can get some more details on how to remediate this for you.

 

Thanks,

 

-Brian Bruno

Patrick Dijkgraaf
Rank
Userlevel 3
Badge +9

Hi Brian,

 

Thanks for your response!

 

Customer is launching the Java GUI via “https://<commserve>/console”, which downloads and launhes the galaxy.jnlp.

 

After the GUI is lanched and the user is logged in, they get the following message:

 

 

We know how to fix the certificate issue (it’s caused by the HTTPS Proxy in between), but why would the GUI be “phoning home”? And this customer does not like that idea.

 

The next.jar won’t work for this customer as it tries to get the application via HTTP (port 80) from the CommServe/WebServer, and the customer says (and I quote): “We are not allowing HTTP, it’s not the 90’s)”.

 

Hope this helps!

:wq!
B
Rank
Userlevel 5
Badge +13

Thanks @Patrick Dijkgraaf,

 

I’ll need to look into this more and get back to you as I can’t seem to reproduce this.

 

That being said, connecting via netx.jar will use HTTPS so long as the site has a valid SSL certificate.  It will only fall back to port 80 / HTTP if there is no trusted certificate.

 

-Brian Bruno

Patrick Dijkgraaf
Rank
Userlevel 3
Badge +9

@Brian Bruno Thanks for looking into this.

 

About the netx.jar method, we are seeing different behaviour. We believe a valid certificate and we are downloading netx.jar via HTTPS. When it launches, we saw it connecting to the CommServe via port 80.

 

I’ll see if I can get some logging/evidence… ;-)

 

EDIT: Might be that it tries via 443 first, and fails for some other reason. Let’s stay on-topic here and figure out what the connection to ipm.commvault.com is coming from… :-)

:wq!
J
Rank

Hi Patrick,

With 11.32.54 we added the framework for IPM (In-Product Messaging) to Java GUI. As far as I understand, the feature as such is not used yet but will be ie. to deliver security advisories.

Patrick Dijkgraaf
Rank
Userlevel 3
Badge +9

Thanks, @Jacek Piechucki !

:wq!
Onno van den Berg
Rank
Userlevel 7
Badge +19

Interesting to hear that they are still putting development efforts in the Java-based CommCell console...

Fredski
Rank
Badge

Hi, I encountered the same issue. To resolve it, simply bypass SSL interception for this URL in the proxy you're using. In our case, the Java applet is downloaded locally onto our laptops. We use a different proxy on the laptop, which is configured on the Commcell server.

Scott Moseman
Rank
Userlevel 6
Badge +18

Interesting to hear that they are still putting development efforts in the Java-based CommCell console...


I’m assuming you shouldn’t get your hopes up.  :)

Thanks,
Scott
​​​​​​​

Commvault Enterprise Success

Reply


Terms & ConditionsCookie settings