Question OPenEdge OpenEdge.Net.HTTP performance issue

JamesBowen

JamesBowen

19+ years progress programming and still learning.
I have some connectivity and performance issues with my latest development.
I'm using the OpenEdge HTTP client which I have used many times before and I have not experienced an issue quite like this before.

I'm developing on 11.7.18 as OE11.7 is going to be the target version that is going to be deployed at the clients location.

This is issue I'm having is that 11.7.18 fails to connect after 20 seconds and I get this error:

1723172912677.png

As a proof of concept, I've also tried OE 12.8 to see if I get the same issue and I don't. It connects but not lighting fast.
  • OE 12.8.0 takes about 5 to 6 seconds
  • OE 12.8.3 takes about 2 to 3 seconds
I've also tried using the ABL dojo but unfortunately, their is currently a licensing issue.
Code: 
OpenEdge V. 12.7.0
Platform: Linux (x86_64)
The license for the client executable has expired. (4399)

Code: 
OpenEdge V. 12.2.12
Platform: Linux (x86_64)
https://xxxx.xxxx.com/oauth/token
1
Client socket not connected
0

Unfortunately, due to an NDA etc. I can't share the URL endpoint that I'm trying to access (POST request).

If I use cURL from the command line, the result is almost instant.

Using openSSL experience the same performance as the ABL session which is to be expected.
Code: 
echo QUIT | proenv>sslc s_client -debug -host xxxx.xxxx.com -port 443 -CApath %DLC%\certs -showcerts

Here is a fragment of the cert.client.log (11.7.18) file. Notice the time difference between 14:26:38 and 14:26:57.
Code: 
[Fri Aug  9 14:26:38 2024] ID-0xa8dda460 CTX-0xa8e8b880 BIO-0x8e97b590 BIO   --- contents of a BIO dump:
[Fri Aug  9 14:26:38 2024] INTERNAL STATE OPERATION --- SSL_connect:SSL negotiation finished successfully
[Fri Aug  9 14:26:38 2024] INTERNAL STATE OPERATION --- SSL_connect:SSL negotiation finished successfully
<<< ??? [length 0109]
    04 00 01 05 00 01 44 9c fa ea 39 25 08 00 00 00
    00 00 00 00 01 00 f0 00 00 16 06 20 ff cb 21 c7
    07 7f 01 c6 20 54 a3 f0 e5 36 61 07 19 5a 9c 7a
    57 e8 a8 76 4c d4 f7 8b 17 2c 26 7f ac b7 92 f7
    5c b8 60 b8 c9 b5 6e f8 82 47 77 ba 9e 32 a2 cc
    07 3e 74 70 87 8d b3 e4 84 40 3a b5 30 e7 0a 47
    eb 61 d5 af e0 2a 08 37 d1 6e 2f 47 2a 67 10 09
    85 60 8a b6 1d 2b b5 53 4f 12 a6 ce 44 66 1b 44
    74 67 91 94 27 3a 17 8b d0 e7 7c 53 55 7a a9 98
    c6 90 5e 28 c8 12 e6 77 dd 5d 95 98 0a c0 6e f0
    03 5c fc d2 80 0c 75 da e4 38 2b d2 15 39 b4 ff
    af e1 6f 80 7f 9d c5 87 93 52 5a 94 67 bf af 06
    61 6f fc 5a 08 b7 b8 0c 14 9e 20 cf 5c 30 ae 66
    02 b0 31 7e bf dd f2 81 62 84 f2 2a 21 bb 7a 0f
    6f b7 a9 02 fe 3e 6a 76 3a e7 90 04 be 2a 3d b7
    83 f4 9a 4b 45 25 1f ca bf b8 2a 45 07 81 fb 75
    0e 4c cb 0e 1a 00 fd 00 00
[Fri Aug  9 14:26:38 2024] INTERNAL STATE OPERATION --- SSL_connect:/TLS read server session ticket
[Fri Aug  9 14:26:38 2024] ID-0xa8dda460 CTX-0xa8e8b880 BIO-0x8e97b590 BIO   --- ctrl to 8E97B590 [A8F3F7D0] (7 bytes => 0 (0x0))

[Fri Aug  9 14:26:38 2024] ID-0xa8dda460 CTX-0xa8e8b880 BIO-0x8e97b590 BIO   --- contents of a BIO dump:
[Fri Aug  9 14:26:57 2024] ID-0xa8dda460 CTX-0xa8e8b880 BIO-0x8e97b590 BIO   --- read to 8E97B590 [A901C4A3] (5 bytes => 5 (0x5))

[Fri Aug  9 14:26:57 2024] ID-0xa8dda460 CTX-0xa8e8b880 BIO-0x8e97b590 BIO   --- contents of a BIO dump:
0000 - 17 03 03 00 13                                    .....
<<< ??? [length 0005]
    17 03 03 00 13
[Fri Aug  9 14:26:57 2024] ID-0xa8dda460 CTX-0xa8e8b880 BIO-0x8e97b590 BIO   --- read to 8E97B590 [A901C4A8] (19 bytes => 19 (0x13))

[Fri Aug  9 14:26:57 2024] ID-0xa8dda460 CTX-0xa8e8b880 BIO-0x8e97b590 BIO   --- contents of a BIO dump:
0000 - d6 9d 04 6b ac ce ad eb-23 20 44 c4 1c 24 65 4c   ...k....# D..$eL
0010 - d4 f3 15                                          ...
<<< ??? [length 0001]
    15
<<< ??? [length 0002]
    01 00
[Fri Aug  9 14:26:57 2024] INTERNAL STATE OPERATION ---  read:warning:close notify
[Fri Aug  9 14:26:57 2024] ID-0xa8dda460 CTX-0xa8e8b880 BIO-0x8e97b590 INFO  --- Terminated SSL Client session

Currently upgrading to 12.8.x is not on the roadmap until next year.

The only options are to shell out to use cURL or implement .NET HTTP client.
Any ideas on what I can do?
 
Check ciphers and transport protocols. These can be restricted by code or by environment variables - see Progress Customer Community

There have been mismatches between what sslc supports and what the ABL socket supports. TLS 1.3 being an earlier troublemaker.
 
Just to try something. I placed the PSC_SSLCLIENT_PROTOCOLS environment variable and I get a whole new error message. I think this is something to do with Ciphers.

1723176072803.png

1723175963623.png


1723176520224.png

In my code I'm not specifying any ciphers.
 

Attachments

  • 1723176513187.png
    1723176513187.png
    31.3 KB · Views: 1
This is a working solution (so far). I don't like that is limiting itself to a single cipher. Performance has increased to 900ms on 11.7.18, but slow on 12.8.0

Code: 
        DEFINE VARIABLE TLSCiphers   AS CHARACTER NO-UNDO EXTENT 1.
        DEFINE VARIABLE TLSProtocols AS CHARACTER NO-UNDO EXTENT 1.
                               
        ASSIGN                      
            TLSCiphers[1] = "ECDHE-ECDSA-AES256-GCM-SHA384"
            TLSProtocols[1] = "TLSv1.2".
                       
        oLib = ClientLibraryBuilder:Build()
                :SetSslCiphers(TLSCiphers)
                    :SetSslProtocols(TLSProtocols)
                    :ServerNameIndicator(OAuthTokenEndpoint:Host)
                    :Library.
 
Is this good practice to us the PROVERSION statement in this manor?:
C#: 
ASSIGN
    /* Only enable TLS1.3 if the Progress version is 12.8 or greater*/
    cSSLProtocols[1] = "TLSv1.2":U
    cSSLProtocols[2] = "TLSv1.3":U WHEN PROVERSION GE "12.8"
    chCiphers[1]     = "ECDHE-ECDSA-AES256-GCM-SHA384"
    chCiphers[2]     = "ECDHE-ECDSA-AES128-GCM-SHA256"
    chCiphers[3]     = "ECDHE-RSA-AES256-GCM-SHA384"
    chCiphers[4]     = "ECDHE-RSA-AES128-GCM-SHA256"
    chCiphers[5]     = "TLS_AES_256_GCM_SHA384"
    chCiphers[6]     = "TLS_AES_256_GCM_SHA384"
    chCiphers[7]     = "TLS_CHACHA20_POLY1305_SHA256"
    chCiphers[8]     = "TLS_AES_128_GCM_SHA256"
 
Are you deploying source code? We deploy 11.7, 12.2 and 12.8 r-code, so it would be:

Code: 
assign
   cSSLProtocols[1] = 'TLSv1.2':u
  &if proversion >= '12.8' &then
   cSSLProtocols[2] = 'TLSv1.3':u
  &endif

But I do have my doubts about the protocol order, I would want 1.3 first if it can be used.

Code: 
assign
  &if proversion >= '12.8' &then
   cSSLProtocols[ix] = 'TLSv1.3':u
   ix = ix + 1
  &endif
   cSSLProtocols[ix] = 'TLSv1.2':u

or

Code: 
def var cSSLProtocls as char no-undo extent [
  &if proversion >= '12.8' &then
   'TLSv1.3':u,
  &endif
   'TLSv1.2':u
].
[code]
 
Stefan said:
Are you deploying source code? We deploy 11.7, 12.2 and 12.8 r-code, so it would be:

Code: 
assign
   cSSLProtocols[1] = 'TLSv1.2':u
  &if proversion >= '12.8' &then
   cSSLProtocols[2] = 'TLSv1.3':u
  &endif

But I do have my doubts about the protocol order, I would want 1.3 first if it can be used.

Code: 
assign
  &if proversion >= '12.8' &then
   cSSLProtocols[ix] = 'TLSv1.3':u
   ix = ix + 1
  &endif
   cSSLProtocols[ix] = 'TLSv1.2':u

or

Code: 
def var cSSLProtocls as char no-undo extent [
  &if proversion >= '12.8' &then
   'TLSv1.3':u,
  &endif
   'TLSv1.2':u
].
[code]
Click to expand...
I won't be deploying the source code. At the moment it's a bit of a mixed bag of 11.7.x to 12.x.x.
 
mixed bag of 11.7.x to 12.x.x.

Sounds like an excellent way to get in all sorts of difficult trouble.
 
Anecdotally we've had the exact same issue in 11.7 with various REST calls. In the end I reverted back to cURL as there's just not enough hours in the day to fix this sort of thing.
 
You must log in or register to reply here.
Back
Top