Posts Tagged ‘ssl’

Cool Tools 24: SSLLabs.com

Sunday, March 10th, 2013

A couple months back, the security team at a client reported that they used a scanner to generate a security report of their SSL-enabled portal, and the results included this little gem:

The SSL protocol encrypts data by using CBC mode with chained initialization vectors. This allows an attacker, which is has gotten access to an HTTPS session via man-in-the-middle (MITM) attacks or other means, to obtain plain text HTTP headers via a blockwise chosen-boundary attack (BCBA) in conjunction with Javascript code that uses the HTML5 WebSocket API, the Java URLConnection API, or the Silverlight WebClient API. This vulnerability is more commonly referred to as Browser Exploit Against SSL/TLS or “BEAST”.

I knew we were using SSL at the site, and because of that, we were infinitely more secure than our peers who weren’t using SSL. But, I never really focused on the fact that SSL is a complicated “beast”, and there are different grades of security. Enter Qualys SSL Labs’ Analysis Tool, which taught me more than I’d ever known about SSL certificates. It started by giving us a big fat “F”:

ssl-labs

A full analysis of WHY we were getting an “F” is beyond the scope of this post, but if you’re using SSL, I definitely suggest you check out SSL Labs to see how secure you are. The links and recommendations by SSL Lab’s report are phenomenal and it didn’t take much time at all to resolve all of the discovered issues.

In our case, two major things were counting against us:
Certificate Chain
We didn’t have the complete certificate chain installed. Using SSL Shopper’s SSL Checker, we could see where the chain was broken. Because it was a Verisign certificate, the path led use to Verisign’s Certificate Checker. The below screen shot shows a GoDaddy certificate with the proper chain installed.
ssl-checker

Weak Ciphers
Apparently not all SSL is created equally; there are different ciphers that can be used for encryption and transport. And because we were using the default BigIP configuration, we were supporting legacy ciphers that dated back to the IE6 days. By tweaking the Cipher configuration to exclude the less-secure ciphers, we were able to get that SSL Labs report back up to an “A” where it belongs…

big-ip-ssl

Add SSL Certificate to Plumtree Publisher JRE

Tuesday, November 15th, 2011

Publisher has a configuration setting in content.properties that allows it to connect directly to the imageserver. Why? Well, the comment in the file describes it appropriately enough:


# JSComponents need to directly access the imageserver from the Publisher
# machine in order to obtain some configuration information. By default it uses
# the image server URL which is provided by the portal for portal end-users,
# but you may also specify an alternate image server URL to be tried first instead,
# such as in the case where the system topography prevents the Publisher
# from accessing that end-user URL.
#JSComponents.AlternateImageServerUrl=http://machinehost:port/imageserver

Problem is, it doesn’t seem to work for the diagnostic tool, and may not work when Publisher needs to load community-themes.txt (which it needs in order to provide the style sheet drop-down for header portlets). So Publisher still needs to connect to the image server – but if the image server is configured to only use SSL, you’re likely going to see an error like this:



Exception Message: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

The solution – import the SSL certificate from the imageserver – is after the break.
(more…)

SSL Portlets can’t be accessed in WebCenter Interaction

Sunday, October 10th, 2010

If you had asked me last month if you should install Windows Updates, I’d have said, “without hesitation, it’s a Best Practice to install Windows Updates as soon as possible; I’ve never seen one break portal functionality – whether it was in the Plumtree days, ALUI days, or lately with WebCenter”. 

This month, the answer is: “without hesitation, it’s a Best Practice to install Windows Updates as soon as possible, but make sure to keep track of those updates and keep an eye out for problems when you’re done”.  Generally, I still think they’re safe and don’t warrant a full regression test once you’re done, but for the first time, I’ve come across a Windows Update that breaks a piece of the WCI portal – specifically, portlet requests to SSL-protected Remote Servers.

Fortunately, Oracle’s support center came through on this one, and clearly documents the problem in KB article 1131443.1: “SSL Portlet Communication Fails After Installing Microsoft Recommended Security Update KB968389 [ID 1131443.1]“.  In summary, there are a certain combination of hotfixes that cause SSL connections from the portal to the remote tier, as documented in the KB article and reproduced after the break.

The thing is, the KB article talks about one “real” Microsoft hotfix [KB968389] interacting with two other “unsupported” hotfixes [KB973667 and KB942636].  It talks about removing the two unsupported fixes, but on the system I was experiencing the problems on, those two weren’t actually installed.  But I did see the one hotfix in there, and once I uninstalled that one (and rebooted), the problem went away.

My best guess at this point is that those two hotfixes from Microsoft (unsupported ones that “are intended to be installed only for customers experiencing this problem”) eventually got rolled into an official, supported hotfix with a different number since the Oracle article was published in June 2010.  And Oracle will eventually update the above KB article listing that “official” hotfix number as well.

(more…)