Default cipher suite selected by server

weblogic

We have Weblogic application server. Whenever a web browser sent a request, as part of tunnel creation process, it will send a list of preferred cipher suites.

Questions:

  1. How do I know which is the cipher suite or default cipher selected by WL server? I know I can use Fiddler to get that details; also I can right click on the browser HTTPS lock icon and get it. But I want to know from Weblogic server's end that which Cipher suit was selected, is it defined in some Weblogic environment .sh file?.

  2. Is there any way to change Cipher priority in Weblogic? I did some research and could find – Dweblogic.security.SSL.Ciphersuites=TLS_RSA_WITH_AES_256_CBC_SHA256".

  3. What happens if I configure Weblogic to use above mentioned Cipher, and this is not present in the cipher suit list sent by browser? My thought is that tunnel establishment will fail and some error like connection refused or failed will be shown to client/browser.

I would be much obliged if these answers can also be provided from Apache's perspective.

Best Answer

I think I can shed some light on some of the questions

  1. Weblogic uses a default Cipher suite based on the type of Security you are using(JSSE or not) and this varies from version to version. For example 10.3.0 will use a completely different suite than that of 10.3.6. You would need to look that up based on your version. To see that, please try enabling SSL debug on the console and it should tell you the details of every connection.

    1. SSL.Ciphersuites is the way to limit the ciphers that webloigc will use. If you use TLS_RSA_WITH_AES_256_CBC_SHA256, it will attempt a handshake using the Ciphers from left to right. Should it run out of algorithms that are mentioned, it will reject the SSL connection. This is a strict enforcement.

I would suggest using apache as a web front end end setting the cipher suite in that. You will see the simplicity in that and as an added bonus, you can set it to @STRENGTH which will try the handshake from the strongest to the weakest algorithm.

So if you setup an apache httpd server in front and force the restrictions there, you will not need to mess with weblogic and will not need to worry to upgrade java and weblogic quarterly when there are security updates or critical updates.

Addition:

  1. Security patching for weblogic does not end with weblogic alone but has to be done with java as well. But for apache, you would not always need to update apache, just the openssl and openssl mod that it depends on. This process makes it very very simple to security patch.

  2. Apache has a bunch of configuration options you could use to limit Ciphers.

SSLProtocol: Lets you manually specify Ciphers or remove them.

SSLCipherSuite: Lets you choose the Cipher Suite you want to allow. Also has the option to let you say +HIGH +MEDIUM +LOW for high-low strength cipher suite as defined by openssl. You can also say @STRENGTH and the client will connect to the server with the strongest cipher-protocol combination that it can perform a handshake with.

The crème de la crème is the logging options available to you for SSL and any other general purpose requirements that you would want to use to troubleshoot.

More on those here:

https://www.openssl.org/docs/manmaster/apps/ciphers.html

http://httpd.apache.org/docs/2.4/ssl/ssl_howto.html

Note: OpenSSL and apache are widely supported and tested by experts and is kind of the unwritten standard to have it(http server) as the internet facing application rather than any java based application.

Related Topic