Is there another way to avoid the 502 bad gateway ...

Report Inappropriate Content · 02-07-2018 11:58 PM

I was trying to connect to Back end server which has a TLSv1.0 requirement.

My client server logs shows that the server hello is successful , but my proxy(client) is not able to select the ciphers offered by the BE server. I guess the ciphers offered by BE server are stronger than TLSv1.0 default ciphers .

So I hard coded the cipher (TLS_RSA_WITH_AES_256_CBC_SHA) in my HTTPTarget connection configs.

This worked for me and I was able to connect to BE server. But I guess this is not a correct approach and may fail if the cipher changes.

Java upgrade would be one solution to resolve this, but at my platform its impossible for some time.

So I need help, to get it fixed at my platform or server level without any JAVA upgrade requirement.

Or any other suggestions.

DChiesa

I don't understand the problem.

You have a backend that uses TLS v1.0.

(This in itself is a serious problem, and you should upgrade immediately. But that seems to not be a concern of yours. )

You have configured Apigee Edge to connect to that backend, using the appropriate Cipher.

... And?

what's the problem?

You said, "I guess this is not a correct approach and may fail if the cipher changes."

Probably true. But ... you yourself said the backend will not be changing any time soon.

so... ?

what's the problem?

plamenstoyanov

Hello @Dino,

I was helping Sumit with this investigation, so I can give some input.

You are absolutely correct that the backend should change their supported protocols, but that's out of our hands.

As for the issue we've faced:

target server SSL:
PORT STATE SERVICE

443/tcp open https

Message processor:

java -version
java version "1.8.0_112"
Java(TM) SE Runtime Environment (build 1.8.0_112-b15)Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)

When EDGE was trying to establish backend connection it failed with:

ASYNC_EXCEPTION: Could not generate DH keypair
com.apigee.errors.http.server.ServiceUnavailableException

we've established the reason for that is Policy is trying to use strongest available cipher, i.e.

TLS_DHE_RSA_WITH_AES_256_CBC_SHA

as you can see from the ssldump below:

# ssldump -i eth1 host <target backend>
New TCP connection #1: <message_processor_host>(20872) <-> <target backend>(443)
1 1 0.0327 (0.0327) C>S Handshake
ClientHello
Version 3.3 
cipher suites

... list of client supported ciphers...

compression methods
NULL
1 2 0.2502 (0.2175) S>C Handshake
ServerHello
Version 3.1 
session_id[32]=
03 5c 10 15 59 a5 c9 a0 06 c1 9c 06 36 97 6e 73 
49 1a e4 08 23 22 85 cb 20 a0 eb 13 f3 2a 8c 99 
cipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA
compressionMethod NULL
1 3 0.2503 (0.0000) S>C Handshake
Certificate
1 4 0.2737 (0.0233) S>C Handshake
ServerKeyExchange1 
5 0.2737 (0.0000) S>C Handshake
ServerHelloDone
1 6 0.2808 (0.0071) C>S Alert
level fatal
value internal_error
1 0.2812 (0.0003) C>S TCP FIN
1 0.3044 (0.0231) S>C TCP FIN

The workaround was to hardcode the ciphers in the target server configuration:

<HTTPTargetConnection>
   <URL>https://default.com</URL>
   <SSLInfo>
     <Enabled>{ROUTING.target_ssl_enabled}</Enabled>
     <ClientAuthEnabled>{ROUTING.target_ssl.client.auth.enabled}
    </ClientAuthEnabled>
       <Ciphers>
          <Cipher>TLS_RSA_WITH_AES_256_CBC_SHA</Cipher>
       </Ciphers>
     <KeyStore>{ROUTING.target.ssl.key.store}</KeyStore>
     <KeyAlias>{ROUTING.target.ssl.key.alias}</KeyAlias>
     <TrustStore>{ROUTING.target.ssl.trust.store}</TrustStore>
   </SSLInfo>
</HTTPTargetConnection>

The downside of this approach is that if backend changes cipher support, we'll need to reconfigure/redeploy the API.

Any idea what might cause this error:

ASYNC_EXCEPTION: Could not generate DH keypair
com.apigee.errors.http.server.ServiceUnavailableException

and how to fix it?

Is there another way to avoid the 502 bad gateway response from BE, aside from hardcoding the cipher in target connection config?