PxPlus User Forum

Twitter Twitter Twitter

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Loren Doornek

Pages: 1 ... 4 5 [6]
76
Programming / Re: [TCP] open fails, but curl works
« on: August 19, 2019, 05:47:49 PM »
The server is running OpenSSL 1.0.1e, but I don't think the site requires TLS1.2.  We have an identical server, using the same RedHat version and OpenSSL library, and we can connect without a problem using OpenSSL 1.0.1e.  I'm starting to suspect that there is some device/firewall on their network that is blocking the ssl negotiation, either because it doesn't recognize or has removed a certain cipher, or only allows certain SSL/TLS versions. 

But really, I'm just grasping at straws at this point.   It works on every other server and PXPlus version we've tried outside of their network.  "Works for me" is the default programmer answer :-)

The big question for me is 'why does curl work'?  I think is uses the same libraries as PXPlus, but I'm not certain.  At this point, I might just need to switch the connections to use curl until we figure out the cause of the problem, but that's quite a bit of coding to change and test.


77
Programming / Re: [TCP] open fails, but curl works
« on: August 19, 2019, 05:15:03 PM »
We have a version 12 on our in-house dev system that is the exact same version as the client (tcb(29)=1250000), and it works fine from our dev system, so I suspect that v12 is not an issue.  We originally suspected that there is some network device that changed (since firewalls can block ssl/tls connections based on ciphers and versions).  But, the fact that we can connect every time via curl seems to rule out that possibility.  At this point, our only thought is that somehow PXPlus is using a different/out-dated SSL library, but I have no ideas on how to check that.

78
Programming / [TCP] open fails, but curl works
« on: August 19, 2019, 04:15:29 PM »
We have a client where a certain program just quit working in the middle of the night last week.  A Secure TCP connection can no longer connect, and return MSG(-1) as 'cannot connect securely'.  This has been working fine for months, and there were no changes to any of our programs.  We aren't aware of any changes to the Linux server either, and have no insight into any network changes since it's a huge company with an extensive network. 

We updated everything on the OS, but still can't connect.

So, I tried using 'curl' instead of a PXPlus [TCP] channel.   I *CAN* connect using in PXPlus using a Linux input from curl (ie: OPEN (1)"< curl -X ….."), but trying to open the same site using PXPlus (ie: OPEN (1)"[TCP]some.server;443;SECURE;NODELAY;STREAM") fails ever time. 

PXPlus version is 12.50, and I've tried using NOSSLV2 and other options, but no luck.  I'm assuming that PXPlus is using the same SSL libraries as the Linux OS, so it makes no sense to me why curl can open the connection, but PXPlus cannot.

Any suggestions on what I can look for?

79
Language / Re: PXPlus support for SNI with TLS1.2
« on: July 22, 2019, 01:30:54 PM »
Thanks for the confirmation about the server name, Mike, and the /etc/hosts workaround.  I don't need to change the servername from what I'm using to open the channel as far as I know, but it's good to have that workaround in my back pocket just in case!  And kudos to you and your staff for already having this solution built into PXPlus!

80
Language / Re: PXPlus support for SNI with TLS1.2
« on: July 22, 2019, 11:23:11 AM »
I see that the version 14 release notes (https://manual.pvxplus.com/PXPLUS/pxplus/vers1400.htm)  do note "Added: Support for SNI (Server Name Indication) with TLS 1.2", but no other documentation.  So, that confirms what version added the support for SNI.

Can you confirm that PXPlus will set the 'servername' as whatever server name is used in the [TCP] open?

81
Language / PXPlus support for SNI with TLS1.2
« on: July 22, 2019, 10:55:13 AM »
A web service that we use is switching to using SNI (Server Name Indication) for TLS1.2 connections.  In a nutshell, we need to specify the servername that we are trying to connect to when making a secure TCP connection.  I suspected that PXPlus was ahead of the game and already added support for this, and I wasn't disappointed! 

In testing this on Linux server with the latest OpenSSL libraries, I found that I can successfully make a connection using version 14 (ie: tcb(29)=14100000), but not when using version 12 (ie: tcb(29)=12500000). 

Can you confirm that SNI is supported by PXPlus, and what version it was added?  Also, is there any documentation on how it works or modifying how it works (for example, is there a method to specify a different servername using a tcp_opt with the [TCP] command, such as "SERVERNAME=xxxxx")?

82
The ciphers are the problem.  Or, more specifically, SSL3/TLSv1.  The server we are connecting to only offers a cipher using a SSL3/TLSv1 protocol.  SSL3/TLSv1 protocols are NOT included in the default builds of openssl after 1.0.2.f.  Our 'bad' server is a newly installed RHEL7, using openssl 1.0.2k, so SSL3/TLSv1 protocols are not supported, and thus we couldn't connect to the server.  Our 'good' server is using openssl 1.0.1e, so it still supports SSL3/TLSv1.  Those older protocols are not included by default because of the Heartbeat and Poodle vulnerabilities of a few years ago. 

FWIW, I wrote a small program to check what ciphers and protocols are accepted by a server that you're trying to connect to.  I'll post it here to hopefully save somebody all the hours that I spent trying to figure this out.

Thanks, Devon, for pointing me in the right direction!


0010 BEGIN
0020 INPUT "Enter HOST server IP/Name to connect to for testing ciphers: ",server$; IF NUL(server$) THEN END
0030 LET port$="443"; INPUT EDIT "Enter HOST port to connect to (default 443 for secure connection):",port$
0040 LET so$="Y"; INPUT EDIT "Display successful ciphers only (Y/N)? ",so$; LET so$=UCS(so$)
0050 LET sp$=server$+":"+port$
0060 OPEN (UNT,ERR=*NEXT)"<openssl ciphers"; LET cl=LFO
0070 IF NOT(cl) THEN END
0080 READ (cl,ERR=*NEXT)c$; LET cl$+=c$; GOTO *SAME
0090 CLOSE (cl)
0100 LET clc=POS(":"=cl$,1,0); IF NOT(clc) THEN END
0110 DIM d$[1:clc]; READ DATA FROM cl$,SEP=":" TO d${ALL}
0120 FOR i=1 TO clc
0130 LET cipher$=d$
0140 LET x$="< openssl s_client -cipher "+QUO+cipher$+QUO+" -connect "+sp$
0150 LET rr$=$$
0160 LET ct=0; OPEN (UNT,ERR=*NEXT)x$; LET ct=LFO
0170 IF NOT(ct) THEN PRINT "UNABLE: "+x$; GOTO 0250
0180 READ (ct,ERR=*NEXT)r$; LET rr$+=SEP+r$; GOTO *SAME
0190 CLOSE (ct)
0200 LET failed=POS("no peer certificate available"=rr$)
0210 LET p=POS("Protocol  :"=rr$),p$=$$; IF p THEN LET p$=MID(rr$,p),p$=MID(p$,1,POS(SEP=p$)-1)
0220 IF NOT(failed) THEN PRINT 'RED',"SUCCESS: "+cipher$+" "+p$,'BLACK'
0230 IF failed AND so$<>"Y" THEN PRINT "FAILED: "+cipher$+" "+p$
0240 WAIT 0
0250 NEXT

83
Ah!  You may be onto something there!  I'd forgotten that many ciphers have been disabled in newer versions of OpenSSL.  I ran a script to list the ciphers on my bad server, and it doesn't include the cipher listed when I connected using curl (TLS_RSA_WITH_3DES_EDE_CBC_SHA), so possibly I need to add that cipher. I had to do that once, and have largely blocked the pain from my memory, but I'll start Googling to see how to do that again, and let you know if it works.

84
1. The 'good' server is on PXP12, but the 'bad' server is on PXP14.  Regardless, I've tried on other servers using PXP12, and it fails, so I don't think it's a PXP version issue.
2. OS is RHEL7 on both servers, with only slight differences in the sub-versions.
3. OpenSSL is 1.0.1 on the 'good' server.  The 'bad' server has a new version (1.0.2).  I'm hesitant to update the 'good' server since this would cause problems if the newer version of OpenSSL is the problem.
4. I don't believe security software would be the problem.  I can make the connection to the port, but just the cert is not being 'recognized' in PXP for some reason.

85
We are having a problem making a secure [TCP] connection from one RedHat Linux server, but the same connection works elsewhere.  The problem server is new, and is running PXPlus 14. 

On the working server, we can open the [TCP] channel, then print the FIN(xx,"X509_Subject") to confirm that the certificate was found, as shown below:

-} open(1,tim=5)"[tcp]images.e-brandid.com;443;Secure"
-} print fin(1,"Secure")
1
-} print fin(1,"X509_Subject")
/C=US/postalCode=92626/ST=Costa Mesa/L=Costa Mesa/street=Building A/street=3185 Airway Ave/O=Brand ID/OU=IT/OU=Secure Link SSL/CN=images.e-brandid.com
-} write record(1)"test"
-} end

But, on the bad server, the connection opens, but the X509_Subject is blank, and writing to the channel results in an Error 15, as shown below:
-} open(1,tim=5)"[tcp]images.e-brandid.com;443;Secure"
-} print fin(1,"Secure")
1
-} print fin(1,"X509_Subject")
-}
-} write record(1)"test"
Error #15: Operating system command failed
Last IO to [tcp]images.e-brandid.com;443;Secure, channel 1
[TCP][Sockets]Error[0]:Success (5:<Unk>)

On the bad server, I can open secure connections to other https URL's, and they return a proper X509_Subject.  For example, a connection to the test Cybersource server is shown below:
-} open(1,tim=5)"[tcp]ics2wstesta.ic3.com;443;Secure"
-} print fin(1,"Secure")
1
-} print fin(1,"X509_Subject")
/C=US/ST=California/L=Foster City/O=VISA INTERNATIONAL SERVICE ASSOCIATION/CN=ics2wstesta.ic3.com
-}

The fact that I can open other secure connections leads me to believe that PXPlus is properly using the Linux certificate authorities, but nothing I've tried lets me connect to the problem URL. 

I was able to connect using curl, as shown below:

$ curl -i -v -X POST https://images.e-brandid.com:443/xml2/xmlreceiver.asmx   -H "Content-Type: text/xml"   -H "SOAPAction: https://images.e-brandid.com/xml2/XMLOrder" -d @/usr/common/test.xml

* About to connect() to images.e-brandid.com port 443 (#0)
*   Trying 64.79.171.67...
* Connected to images.e-brandid.com (64.79.171.67) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_RSA_WITH_3DES_EDE_CBC_SHA
* Server certificate:
*       subject: CN=images.e-brandid.com,OU=Secure Link SSL,OU=IT,O=Brand ID,STREET=3185 Airway Ave,STREET=Building A,L=Costa Mesa,ST=Costa Mesa,postalCode=92626,C=US
*       start date: May 24 00:00:00 2016 GMT
*       expire date: Aug 05 23:59:59 2019 GMT
*       common name: images.e-brandid.com
*       issuer: CN=Network Solutions OV Server CA 2,O=Network Solutions L.L.C.,L=Herndon,ST=VA,C=US

I was able to issue another command that retrieved the certificate chain from the server (attached file brandid.cer.txt), and I tried everything that I can find on Google to update the root CA's for RHEL and to get that specific certificate chain to be recognized, but nothing is working.  At this point, I'm at a loss as to what to do to make this work in PXPlus. 

Any suggestions?

Pages: 1 ... 4 5 [6]