When using VB.Net to connect over TLS1.2 in Rumba 9.51, I used the following lines to establish the connection:

Dim SecParms As Object
Dim SecIface As Object
Dim SecSSL As Object
SecParms = CreateObject("NMSecurityBase.Factory4")
SecIface = SecParms.MFTelnet
SecIface.HostPort = 992
SecSSL = SecParms.SSL
SecIface.AttachSecurityProtocol(SecSSL.Serialized)

After upgrading to Rumba 10, I can't seem to get a connection.
Did the Interface/Object changed?
Do I need a different Factory object now?

Thanks,
Tal.

Hi Tal,

the Interface/Object did not change.
I added SecIface.HostName and I can connect fine with RUMBA10.

Set SecParms = CreateObject("NMSecurityBase.Factory4")
Set SecIface = SecParms.MFTelnet
SecIface.HostPort = 992
SecIface.HostName = "yourHostName"
Set SecSSL = SecParms.SSL

You may want to set the trace level

Property TraceLevel As Long
Member of ObjectXMFDisplay.ObjectXConfigureTn3270Link
Gets/Sets the SSL Trace Level

It should write a RSSProxy.log file. It should contain useful information or error about your TLS connection.

regards

/andré

Hi Andree - as a follow-up to the above discussion...

The code that you provided has and continues to work on the mainframe (MF) above (we'll call it "992" for its port #).  And when I run the code with Wireshark capturing traffic, and then I do a "Follow TCP Stream" I see that there is information about http://crl3.digicert.com ).

We have another MF (lets call it 12345), which until now has been working non-TLS.  Recently, the customer has turned on TLS capability on the same port 12345.  Once we confirm that our software handles TLS on that port, the non-TLS capability will be turned off.  I've modified our SW so that the same SecParms, etc as above are also used for 12345.  The SW runs fine. However! the Wireshark traffic is not showing any indication of SSL, "crl3.digicert.com", etc.  

If instead of our SW, we use Rumba+ Desktop, and modify the configuration for 12345 to be:

then in Wireshark I *do* see the digicert traffic, etc.

Any ideas what additions/changes to the settings (I've copied/pasted the snippet below) might also be needed?  I can't give the customer the go-ahead to turn off non-TLS access until I can verify this.

Thanks in advance!

Larry

=====================================  Snippet ========================================================

Dim SecParms As Object
Dim SecIface As Object
Dim SecSSL As Object

SecParms = CreateObject("NMSecurityBase.Factory4")  
SecIface = SecParms.MFTelnet    
SecIface.HostPort = mvarPort
SecIface.HostName = mvarHostName

SecSSL = SecParms.SSL
SecSSL.MatchHostNameInCert = False   
SecSSL.TrustAllIssuersInCert = False 
SecSSL.ValidDatesInCert = False      

SecIface.AttachSecurityProtocol(SecSSL.Serialized)
frmHostInterface.HostDisplay.HostInterface.Interface.SecurityString = SecIface.Serialized
frmHostInterface.HostDisplay.HostInterface.Interface.DisableDialogs = True

Hi Larry,
what Rumba+ Desktop version is the customer using ?
Can you confirm that RUMBA+ Desktop itself works when you configure the MF (port 12345) ?

/andree

Hi Andree,

a little clarification.  The customer owns/controls/configures the mainframes.  They also use our application - built with Rumba+ 10.1 - to access the MFs.  They do no actually use the Rumba+ desktop, though we - as developers - use it to verify that our application is behaving as expected.  

This is the version of the Desktop that we use and which works fine with port 12345 connecting in TLS mode:

Hi Larry,
thank you for the clarification provided.
If advanced security settings are required in 10.1 , such as SSL/TLS, Proxy than reference the NMSecComParams Type Library.
See below code snippet

...
emul.HostInterface.Name = "WallData.TN3270Link"
emul.HostInterface.Interface.InsertName2 "yourHostName.here"
emul.HostInterface.Interface.TelnetPort = 12345

Set SSL = New NMSECCOMPARAMSLib.SSL3 	'setup SSL
SSL.MatchHostNameInCert = False
SSL.TrustAllIssuersInCert = False
SSL.ValidDatesInCert = False

Set MFTelnet = New NMSECCOMPARAMSLib.MFTelnet4
MFTelnet.AttachSecurityProtocol SSL.Serialized
MFTelnet.UserInteractive = True

emul.HostInterface.Interface.SecurityString = MFTelnet.Serialized

Thanks Andree.

It seems to me that I already have (or had) all the above settings, although maybe in slightly different format/version.  (A few of your lines had equivalents in my code, in a different "SetDisplaySettings() method, so I hadn't included them ).

Here are some more details of what I had and what I now tried. (BTW - my code is in VB).

With frmHostInterface.HostDisplay.HostInterface
	.Name = "WallData.TN3270Link"
	.Interface.InsertName(Name:=mvarIPAddress, RetCode:=returnVal)
	.Interface.InsertName2(Name:=mvarIPAddress, RetCode:=returnVal)	' exception "Public member 'InsertName2' on type 'IObjectXConfigureTn3270Link6' not found."
	If mvarPort <> 23 Then
		.Interface.TelnetPort = mvarPort
	End If
	If mvarLUName <> "" Then .Interface.DeviceName = mvarLUName
	.Interface.Response = True
	.AutoConnect = "1"
End With

So I tried adding in the InsertName2 as you had but got an exception; though I don't imagine that this setting is crucial.

Instead of your NMSECCOMPARAMSLib.SSL3, I have:

SecSSL = SecParms.SSL3 -- (I had SSL before, but changing to SSL3 didn't make any difference)

I assume that is just syntactical difference, using SecParms instead of NMSECCOMPARAMSLib...

Instead of NMSECCOMPARAMSLib.MFTelnet4, I have:

SecIface = SecParms.MFTelnet4 

and then:

SecIface.AttachSecurityProtocol(SecSSL.Serialized)

So - do you see anything else of significant difference ?

Thanks,

Larry

Let me add one more piece if information, in case it is relevant in terms of TLS  (v1.2) settings in Rumba.  MF 992 does not have a devicename; 11003 does have a device name, which does get set using .Interface.DeviceName = "....:" (Seen in the snippet above)

Hi Larry,
I'm testing in Excel 32-bit with RUMBA 10.1 same patch level as indicated in your screenshot.
Below VBA code works for me, the code connects to a 3270 Host using a TLS 1.2 connection.
The Wireshark trace shows the right protocol see below screenshot, it shows CLIENT and SERVER Hello.

If your Device Name is wrong Rumba would show  a message like "The specified device name is unknown to the server."

Private Sub UserForm_Activate()
    Dim MFDsp As Object
    Dim TN3270 As Object
    Dim wrkSheet As Worksheet
    Dim index As Integer
    Dim lRC As Long
    Dim row As Integer
    Dim strBuf As String
   
    
    Set wrkSheet = Worksheets(1)
    Set MFDsp = MFForm.Dsp1
    
    Dim SecParms As Object
    Dim SecIface As Object
    Dim SecSSL As Object
   
  
    MFDsp.HostInterface.Name = "WallData.TN3270Link"
    MFDsp.HostInterface.StartupModelType = 2
    Set TN3270 = MFDsp.HostInterface.Interface
    
    TN3270.InsertName2 "YOURHOST"
    TN3270.TelnetPort = 12345
    TN3270.SslAuthentication = True
    TN3270.SslEnabled = True
    
    
    Set SecParms = CreateObject("NMSecurityBase.Factory4")
    Set SecIface = SecParms.MFTelnet
    
    'SecIface.HostName = "YYOURHOST"
    'SecIface.HostPort = 12345
    
 
    Set SecSSL = SecParms.SSL
    SecSSL.MatchHostNameInCert = False
    SecSSL.TrustAllIssuersInCert = False
    SecSSL.ValidDatesInCert = False
    
    'Enable SSL in the Security interface
    SecIface.AttachSecurityProtocol SecSSL.Serialized
    
    'Assign the encryption interface information to the Display interface
   TN3270.SecurityString = SecIface.Serialized
   

          
    lRC = MFForm.Dsp1.RDE_Connect_Hsynch(True, 2, 10000, "", 0, 0)
    If lRC > 6 Then
        MsgBox "Error - unable to connect to host"
        Exit Sub
    End If
    MFForm.Show
    
    
End Sub

(Just saw how to EDIT a reply :-) )
A little more information that I am adding following the below reply)

I just spoke to the customer (which actually just passes our traffic directly to the 3rd Party owners of the 2 Mainframes).  He said that the 12345 MF is configured with CONNTYPE=ANY

Is it possible that there is something in my Rumba setting in my code that needs to be set so that CONNTYPE of ANY is ignored, and I only send TLS 1.2 encrypted traffic?

======================================================================================================

Thanks Andree... I will try to compare line-by-line shortly, but what you wrote is not so surprising.  As I wrote in my original email, my code also works fine for 992, just not for 12345.  (And Rumba + Desktop also works fine for 12345.  )

So is there anything you can think of that might explain the different behavior?  In your test, does the server accept both TLS and non-TLS traffic?

Also - I know in the past we've tried unsuccessfully to get some type of Rumba trace logs.. can you send information how - given my code structure above - I can get rumba to log debug traces?  (Maybe that would help both of us see what the difference is?)

Thanks,

Larry

Hi Larry.
there is no further configuration needed in RUMBA. The Rumba Software seems to work fine.in your environment.
The CONNTYPE statement is  in the Telnet server configuration  an optional statement on secure ports that provides more control over how connections initiate the TLS handshake.
The CONNTYPE ANY Indicates that the connection can be either secure or basic.

If you add SecIface.TraceLevel = 5 to your code it should generate 2 log files in your %temp% folder.
RSSProxy.log and RSSClient.log together with a Wireshark trace will help to analyze the problem.

Please do not post the log files  here. I suggest you open a support case.

cheers

andree

Hi Andree - well the TraceLevel sort of works. Namely when I go to 992, I see the 2 files get created.  Unfortunately, when going to 12345 they are not created. :-(

Another 2 things I have seen while debugging through my code:

1. Keeping an eye on the Wireshark, I step through all the settings above (SecIFace, SecSSL, etc.) plus the call to:
            frmHostInterface.HostDisplay.Connect()

    However, I only start to Wireshark activity on the port (be it 992, or 12345) after I step over:

            System.Windows.Forms.Application.DoEvents()

I am not an experienced Windows/GUI/Forms programmer - this is largely code that I've inherited, so I do not understand the connection between the DoEvents() and the actual traffic beginning.

2. and maybe more interesting, after stepping over DoEvents, in the 92 case I see 5 frames in Wireshark:

• Client-to-server
• Server-to-Client
• Client-to-server
• Client-to-server - this one being the Client Hello, and follows previous frame immediately (< .01 seconds)

However, in the case of 12345 Wireshark shows:

• Client-to-server
• Server-to-Client
• Client-to-server
• Server-to-Client and this packet is > 4.2 seconds after frame 3.

Given all the 3 things above, It clearly looks like for some reason none of the rumba SSL-related settings are "taking" but I don't know why they are being effectively ignored.

Any ideas are welcome :-)

Also - aside from SecIFace.TraceLevel - are there other types of traces the I could add in that might highlights what is or isn't happening BEFORE I reach the DoEvent() stage?

Thanks!

Larry

For lack of any other ideas on my part...:-)

I see that there are some cache files (under C:\\Users\\LWeisberg\\AppData\\Roaming\\Micro Focus)... is it possible that some settings are "stuck" and causing unexpected behaviour?  Which files under AppData can be removed?  Is there anything that might be "cached" in memory? other folders? registry?  Is there a recommended best way to start totally clean?

Hi Larry,
It would be best if you contact support so that we can troubleshoot. We would be able to analyze the Wireshark traces.
A working trace vs. not working trace is always a good starting point.
The RumbaSecurityService (RSS) component writes cache files  into %appdata%\\Micro Focus\\RSS
It's save to remove %appdata%\\Micro Focus\\RSS and %appdata%\\Micro Focus\\Rumba. The files will be regenerated.
Can you  please try and add SecIface.UserInteractive = True to your code.
When this option is enabled, you have the ability to provide user input and change certain system defaults. It will also display eventually a error message.
best of luck

/andree