Sunday, December 7, 2014

Securing OHS environments with latest SSL TLS protocols and SHA-2 certificates

Customer case

A while ago I was contacted by a customer about their old Oracle Application and Weblogic Server environment.
They were receiving complaints from users that they can't connect to the secure site any longer. Most of the complaints came from users that just recently updated their tablet or smartphone.
After a quick look in the logs of the OHS servers, I found out that the problem had to do with the SSL protocols being used.
The servers were providing connections through either SSLv3 or TLSv1.0, while the devices requested at least TLSv1.1.
The environment comprises of an Oracle HTTP server 10.1.x, for SSO, in front of their Application Server.
For the applications they are using OHS 11.1.1.x. in front of a mix of applications. Varying from oc4j 10.1.2 all the way up to 11.1.1, including Oracle Forms and Reports.
Unfortunately, due to this complexity of components, they were not able to upgrade the environment in time.

SSL Current Situation
 SSL Current Situation

Requirements

The customer asked to provide a solution with the following requirements.

  • Disable the old, insecure, SSLv3
  • Enable TLSv1.1 and TLSv1.2 for all sites
  • Current hostnames for the url’s must not change
  • Support SHA-2 SSL certificates for all sites

Circumstances I had to take into account

  • Oracle HTTP Server (OHS) 10.1.x and 11.1.1.x do not support TLS 1.1 and TLS 1.2.
    This is due to the Oracle NZ layer used by OHS 10g/11g for its SSL implementation which doesn't support TLS 1.1/1.2.
  • There is no support for SHA2 certificates (SHA256 or SHA512) or algorithms in Oracle Application Server 10g (10.1.2.X.X/10.1.3.X.X)
  • SHA2 is certified for Fusion Middleware 11g (11.1.1.X) with caveats
  • As part of their SHA-2 migration plan, Microsoft, Google, and Mozilla have announced that they will stop trusting SHA-1 certificates.
    Google will begin phasing out trust in SHA-1 certificates in November 2014.
  • Replacing the old 11.1.1.x OHS with FMW Webtier 12.1.3.0. is not an option.
    OSSO from the 10.1.x appserver is being used and in FMW Webtier 12.1.x the mod_osso module is no longer supported.
note. Oracle Traffic Director on Exalogic is also based on FMW 11.1.1.x !!


Solution

There are several options to meet the requirements set by the customer.
Unfortunately the best solution, upgrading the environment, cannot yet be implemented.

In this case the requirements were met by placing a reverse proxy in front of the entire environment.
The reverse proxy acts as an SSL terminator for client connections using the latest SHA-2 SSL Certificates.
To encrypt the connection, using TLSv1.0, between the reverse proxy and the backend OHS, I generated Self-Signed SHA-1 certificates compatible with the old servers .

As a reverse proxy I had the choice between using Oracle Fusion Middleware 12c 12.1.3 Webtier or the plain Apache HTTP Server.
I decided to go with Apache HTTP Server.

The reasons for this choice were.

(Security) Updates - (Security) updates are released more frequent for plain Apache than for Webtier
Easier to maintain - The server will be managed by Linux engineers, not the Oracle Engineers
Smaller footprint - I only need the reverse proxy functionality, not all the fancy stuff that comes with Oracle Webtier.

SSL Installed Solution

SSL Installed Solution

Pretty much all requirements were met by using the latest Apache with the correct SSL settings and new SSL Certificates.

For one requirement we needed to play a little trick:

Current hostnames for the url's must not change
After setup of the reverse proxy, all DNS entries for the url's hostnames where changed to the IP-addresses of the reverse proxy.
For the reverse proxy to be able to do its work, I placed the old IP-addresses in the local hosts file of the server running Apache HTTP Server.
So the clients browsers are accessing the url's via DNS resolving to the reverse proxy which on his turn resolves the hostsnames on the backend using /etc/hosts.

Final thoughts

It was not my intension to describe the complete setup of an Apache based reverse proxy here.
There are tons of how-to’s, blogs, etc. that describe all the setups and features.
The main purpose of this article is to make people aware of the fact that there are some changes in SSL security upcoming that can have a direct impact on your environment.

In the case described above, users were already experiencing problems with mobile devices and tablets. And as I finished the setup, their developers discovered that Java 1.8 uses TLSv1.2 by default.
So a problem, they did not yet relate to SSL protocols, was solved in the process.

As reminder

Oracle supports the use of TLSv1.1 and TLSv1.2 as of version FMW 12.1.x
Oracle supports the use of SHA-2 as of FMW 11.1.1.x (with caveats)

Related Oracle support notes:

Does Oracle HTTP Server (OHS) 10g Or Higher Support TLS 1.1 and TLS 1.2? (Doc ID 1503476.1)
Using OHS 12c With TLS 1.1 and 1.2 Protocols as an SSL Reverse-Proxy to OHS 11g (Doc ID 1920143.1)
Is SSLHonorCipherOrder and TLS 1.1/1.2 Supported for Oracle HTTP Server? (Doc ID 1485047.1)
How to Change SSL Protocols (to Disable SSL 3.0) in Oracle Fusion Middleware Products (Doc ID 1936300.1)

6 comments:

  1. HI Jaap,

    We have a similar requirement as above.

    Would you mind elaborating on the following
    "After setup of the reverse proxy, all DNS entries for the url's hostnames were changed to the IP-addresses of the reverse proxy.
    For the reverse proxy to be able to do its work, I placed the old IP-addresses in the local hosts file of the server running Apache HTTP Server."

    Specifically, how does your hosts entry look like?

    Thanks!

    ReplyDelete
    Replies
    1. Hi Raj,
      In the hostfile of the reverse rpoxy I just put in the same hostname of the url, but with the internal ip-address.

      For example app.foo.bar resolves to the public address (via DNS) which routes to teh reverse proxy.

      On the reverse proxy I put in the /etc/hosts file

      192.168.1.1 app.foo.bar

      Where 192.168.1.1 is the internal IP address of the backend OHS server.
      So the reverse proxy kan route traffic to the backend OHS server.

      Regards
      Jaap

      Delete
  2. hi Jaap

    We also have a similar requirement, only in our case it's all oracle application server 10g rel 2 (latest patches) - we succeeded with all the setups, with the exception of the ORACLE Forms, we're getting java.lang.ClassNotFoundException:oracle.forms.engine.Main and from the Jinitator console: java.io.IOException: javax.net.ssl.SSLException: SSL handshake failed: SSLSessionNotFoundErr.
    it seems that for the oracle forms, the sha256 ssl is not terminating. tried to look everywhere for a solution - but we're running out time.
    Hoping you had same situation
    Thanks for any insight
    Yafa

    ReplyDelete
    Replies
    1. Hi Yafa, I don't terminate ssl at forms itself. I put a ohs in front of it. This ohs is behind a reverse proxy which terminates the ssl with sha256 ssl.

      Jaap

      Delete
  3. I would like to thank you for the efforts you have made in writing this article. I am hoping the same best work from you in the future as well.

    ReplyDelete
  4. The article looks magnificent, but it would be beneficial if you can share more about the suchlike subjects in the future. Keep posting. Wildcard SSL

    ReplyDelete