4
$\begingroup$

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.

Improve this question
$\endgroup$
4
  • 1
    $\begingroup$ How are you going to generate the session keys and bind them to the TLS session? $\endgroup$
    – Maarten Bodewes ♦
    May 26, 2018 at 2:53
  • $\begingroup$ They won't be bound to the TLS session. Rather, at each point in our application code where we send or receive data, I will explicitly add a call to encrypt or decrypt the data. As far as establishing the shared symmetric key between client and server, I'm thinking of having the client generate it and then encrypt with the public key of the server cert. Is that what you were asking? I really haven't looked into how best to create the key yet. I assume I'll use an approved secure PRNG of some kind. $\endgroup$
    – Tom Hood
    May 26, 2018 at 2:58
  • $\begingroup$ Yep, that's what I was asking :) $\endgroup$
    – Maarten Bodewes ♦
    May 26, 2018 at 2:59
  • 1
    $\begingroup$ An alternative, non-cryptographic (thus offtopic) solution might be a frontend that accepts the good TLS from Java and relays over horrible ugly bad TLS to the lame server, like HAProxy or nginx or socat or even back-to-back stunnel. $\endgroup$
    – dave_thompson_085
    May 27, 2018 at 1:32

1 Answer 1

Reset to default
4
$\begingroup$

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).

Improve this answer
$\endgroup$
3
  • $\begingroup$ Thank you for sharing your thoughts on this. I was about to post a followup, but as this is my first time on stackexchange it appears I'm maybe using it incorrectly. My followup is too long for a comment. It looks like the help recommends chat, but then the question and answer history is lost for others. Is it preferred if I post a bunch of comments, each one paragraph? or should I edit my original post and reference your answer? $\endgroup$
    – Tom Hood
    May 26, 2018 at 18:04
  • $\begingroup$ If you think there are missing requirements or details then yes, please adjust the question. Comment here if it is particular to my answer. Multiple comments are possible. $\endgroup$
    – Maarten Bodewes ♦
    May 26, 2018 at 18:47
  • 1
    $\begingroup$ I don't think I can "keep to the current TLS", because AFAIK there isn't a way to re-enable the old cipher suite in Java on a per-application basis for a JNLP app (i.e. no way to set the System property java.security.properties before JVM starts). The best cipher suites that remain supported in both Java and our ORB have an encryption algorithm of NULL or an insecure one (e.g. DES_CBC). So I would have to tunnel through a TLS configured with one of those. $\endgroup$
    – Tom Hood
    May 26, 2018 at 21:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.