TLS: Risks of using a NULL cipher with encryption implemented in application? We have a browser-launched JNLP/WebStart application that is no longer able to establish client-server CORBA/IIOP communications across TLS 1.0/1.1 due to relying on a cipher suite that uses an obsolete encryption algorithm for confidentiality, now disabled in Java 8u171.  Client is Java.  Server is C++ on Solaris.

The TLS connection that relies on the compromised cipher suite is coming from inside the guts of an antiquated, unsupported ORB implementation (Visibroker 5.2.1).  It's source code is not available.  It does NOT support a stronger cipher suite.

Unfortunately, we are not able to replace/upgrade the ORB at this time, so we are looking for a safe, near-term workaround that allows for secure communication.

The ORB does support some cipher suites with a NULL EncryptionAlg where the KeyExchangeAlg and MacAlg are still considered approved in section 3.3.1 of NIST SP 800-52 Rev 2 (Draft 1/2018).

My idea is to configure the ORB to use one of these cipher suites and then rely on our application to provide confidentiality with a NIST-approved encryption algorithm.

What additional security risks exist, if any, with such an approach compared to having the cipher done by the TLS implementation?

Am I opening up a gaping hole in security by doing so or are they equally secure assuming the application code is implemented correctly?

I'm considering using the same technique described in RFC5246 (TLS 1.2) in our app's code to establish a shared secret between client and server.

Please let me know if you have any advice or suggestions.

Thank you!

EDIT 5/26/2018 attempting to provide more detail and some clarification of what I was considering:

My idea was to configure the ORB to use a cipher suite with a NULL encryption algorithm, such as TLS_ECDH_ECDSA_WITH_NULL_SHA.

I would then change our application code to encrypt any data to be sent across the ORB's unencrypted TLS socket with a NIST-approved algorithm such as AES_256_CBC.  Since our application does not directly use the ORB's TLS socket, it would encrypt fields of distributed objects before allowing the ORB to transmit them across the socket.  Likewise, it would decrypt those fields on the receiving side.

Am I losing any of the ORB's TLS session-provided guarantees besides confidentiality (i.e. client/server authentication, message integrity, replay protection)?  Here's a stackexchange answer that suggests the 1st two are kept: TLS: Is Integrity assured when using NULL cipher

If the non-confidentiality guarantees still hold, is there any security risk in sharing a symmetric key if the Java client generates the key, encrypts it with the server's public key, and then transmits that to the server across the unencrypted TLS socket (via ORB vendor API)?  The server of course is the only place that has the matching private key.

I'm unclear on the specific risks associated with this approach beyond the potential for bugs in our application logic to encrypt and decrypt every distributed object field.  Clearly this is ugly and not a long-term solution by any means, but I hoped it could be used in the short-term while we work on replacing/upgrading the ORB.  If it isn't a viable approach, then I need to find an alternative such as the tunneling that Maarten suggested.
The problem is that the session keys within TLS are bound to the TLS session. If you just generate your own keys then that particular binding is lost. You might be able to hack or retrieve information from the TLS session to bind it again, but that would be rather like hacking.

Establishing the keys yourself will very likely lead to a significantly worse protocol than using TLS itself; you'll be bound to make all mistakes in SSL 1.0 to TLS 1.2 all over again.

Instead I propose that you keep to the current TLS to the server. However, that TLS session itself can be tunneled though a much more secure TLS session, possibly using an intermediate node on the server side. Some networking tricks may be necessary of course (e.g. to allow for reverse DNS checking by the original server).