Trireme Error: Socket Hung Up error

ccovney
Participant V

Hi everyone,

Apigee Edge OPDK (aka Private Cloud) 4.14.04.03

When I run my Apigee API Proxy node server locally using node, everything runs fine; however, when I use Apigee/Trireme (even running Trireme locally) I get a Trireme error when I send an https message to our remote service:

Error: Socket Hung Up

I believe when node is running, it uses OpenSSL for its https support; however, Trireme uses the Java SSLEngine. This is the only difference I can deduce between running node vs trireme.

One thing I've noticed is that the error only happens for the following cipher config on our remote service:

TLS 1.2 connection using TLS_RSA_WITH_AES_128_GCM_SHA256

The error does not occur when the remote service has the following cipher config:

TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

The fact that even the latest version of Trireme run on my local exhibits this error behavior is worrisome. Any idea why this is happening and how to mitigate this? Thanks in advance for any help or insight!

Best,

Chris

Solved Solved
0 2 747
1 ACCEPTED SOLUTION

adas
Participant V

@Chris Covney you are right about the fact that node uses OpenSSL whereas Trireme uses Java's SSLEngine. Which means that trireme would restrict few ciphers which are not supported by Java itself, since the Java 7 upgrade. This is already documented in the trireme github page: https://github.com/apigee/trireme

Refer to the section called: "TLS/SSL and HTTPS"

Most notably, especially with Java 7, SSLEngine supports a different set of cipher suites, particularly the various elliptical curve ciphers. There are ciphers in common (otherwise almost everything will break) but there are many that are not. Many Node.js tests that rely on older cipher suites using DES or RC4 will not run on Trireme because many of these older and weaker cipher suites are disabled by default in Java

That explains why TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 works for you but TLS_RSA_WITH_AES_128_GCM_SHA256 doesn't. I don't think there's a way to mitigate this since trireme is just relying on Java's SSLEngine.

View solution in original post

2 REPLIES 2

adas
Participant V

@Chris Covney you are right about the fact that node uses OpenSSL whereas Trireme uses Java's SSLEngine. Which means that trireme would restrict few ciphers which are not supported by Java itself, since the Java 7 upgrade. This is already documented in the trireme github page: https://github.com/apigee/trireme

Refer to the section called: "TLS/SSL and HTTPS"

Most notably, especially with Java 7, SSLEngine supports a different set of cipher suites, particularly the various elliptical curve ciphers. There are ciphers in common (otherwise almost everything will break) but there are many that are not. Many Node.js tests that rely on older cipher suites using DES or RC4 will not run on Trireme because many of these older and weaker cipher suites are disabled by default in Java

That explains why TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 works for you but TLS_RSA_WITH_AES_128_GCM_SHA256 doesn't. I don't think there's a way to mitigate this since trireme is just relying on Java's SSLEngine.

Hi Arghya,

Ah ok. This makes sense. So we have no choice but to upgrade the cipher suite on the DNS. I'll get that started then. Thanks!

Best,

Chris