This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

TLS 1.2 using Rumba 10 and .NET access

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.

Tags:

Labels:

Rumba
  • Verified Answer

    0  

    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é

     

     

  • 0 in reply to   

    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
    

  • 0   in reply to 

    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

  • 0 in reply to   

    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:

  • Suggested Answer

    0   in reply to 

    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
    

  • 0 in reply to   

    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

  • 0 in reply to 

    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)

  • Suggested Answer

    0   in reply to 

    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

  • 0 in reply to   

    (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

  • 0   in reply to 

    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