Wednesday, October 18, 2017

Here´s my presentation I gave at Social Connections 12 in Vienna 17. October 2017.

Vienna was such a beautiful venue for the Social Connections 12 conference. Thanks to the #soccnx team for putting it all together!!

I´ve put my presentation up on SlideShare, and here it is:



Social Connections 12. We hired hackers to hack us from Robert Farstad

A small warning:
The section I talk about regarding tightening Header Security, setting the "Header set X-Frame-Options SAMEORIGIN". This might break your Sametime Awareness inside of IBM Connections. There is a X-Frame-Option "Allow From", where you can set the Sametime Proxy´s hostname to be allowed, but this one is not supported by Chrome. So, setting the "Header set X-Frame-Options SAMEORIGIN" will work for IBM Connections and IBM Docs, but not if you have Sametime Proxy integration into Connections.

6 comments:

Gunleif said...

Hei, jeg får ikke ta en fullscreen og dermed ikke fått lest presentasjonen

Unknown said...

Heisann. Den er nedlastbar hvis du har en slideshare konto. Se her: https://www.slideshare.net/rockbert77/social-connections-12-we-hired-hackers-to-hack-us/1

Giannandrea said...

Hi Robert,
I started to study your recommended settings about headers to clearly understand their features, but now I kindly ask your help for a better understanding...

The following directives are (now) clear:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header set Referrer-Policy "same-origin"
Header set X-Content-Type-Options "nosniff"
Header set X-XSS-Protection "1; mode=block"

Instead the following 2 lines:
Header set X-Frame-Options "DENY”
Header set X-Frame-Options SAMEORIGIN

left me uncertain because:
- they appear to me as 2 different settings for the same directive
- from what I learned DENY is the most restrictive (the page cannot be included in an IFRAME)
- while SAMEORIGIN is less restrictive (the page can be included in the IFRAME if the parent is from the same domain)

So I suppose that only this one:
Header set X-Frame-Options DENY
(maybe without "..." as for SAMEORIGIN) should be enough... but surely I'm wrong :-)
Please could you help me to solve these doubts?
Thanks again for posting so precious information.

Giannandrea

Giannandrea said...

Hi Robert,
I performed some additional tests and I would like to share them with you :-)

Using the following settings:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header set Referrer-Policy "same-origin"
Header set X-Content-Type-Options "nosniff"
Header set X-XSS-Protection "1; mode=block"
Header set X-Frame-Options SAMEORIGIN
(I removed -> X-Frame-Options "DENY")

In this way I reached an "A" with SecurityHeaders.io
I read your warning about awareness connectivity broken when using SAMEORIGIN directive, but Sametime integration it's not present in my scenario, so it's not an issue.

After that, as recommended from SecurityHeaders.io I added also the following directive:
Header set Content-Security-Policy "default-src 'self';"
and I performed a new test, which has given me an "A+"

Needless to say, this setting breaks something important because I've not been able anymore to reach my Connections login page, so I had to remove this last setting.

An "A" is definitely a good score, but I think it would be interesting to discover which instructions Connections "loads" which are not compliant with this last setting.

Again a big thank you for sharing these information!

Giannandrea

Unknown said...

Hi Giannandrea.
Thank you for sharing your testing result as well.

I agree, an "A" is a good score and I, as you, would like to know what exactly "breaks" Connections here.

I did create a PMR to IBM Support on this, where I asked if they have any suggested settings. After they asked the developers about it, the answer was that IBM does not have any recommended settings to share with us.

Which is weird, because if you test the site "apps.na.collabserv.com" which is the IBM Collab Cloud Address for North America, you get the grade "D" and not the default "F". Which means that IBM in fact has put in some of the header security stuff into the front-end servers they are running.

Giannandrea said...

Hi Robert,
things are changing quickly and, as you probably already know, with the mentioned cipher list from few months SSLLab assigns a "B".

I started to troubleshoot this evaluation and I discovered that the grade "B" comes for the following issues:
- with IE 8-10 / Win 7 (a reference browser) and TLS 1.0 the used cipher is TLS_RSA_WITH_AES_128_CBC_SHA (which doesn't support "Forward Secrecy")
- with issue with Safari 6.0.4 / OS X 10.8.4 (another reference browser) and TLS 1.0 the used cipher is (again) TLS_RSA_WITH_AES_128_CBC_SHA

I dug deeper and I found the missing cipher was this one: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

This cipher should support TLS 1.0 and "Forward Secrecy", inexplicably in the IBM gskit implementation this cipher is available only for TLS 1.2.
This link is extremely valuable to understand this "non standard choice":
https://developer.ibm.com/answers/questions/418169/how-to-enable-forward-secrecy-for-tlsv10-in-ihs.html

To cut a long story short, the only way I found to receive (again) a better evaluation from SSLLab is to configure IHS to support only TLS 1.2 (so removing from IHS the support for TLS and TLS 1.1).
Needless to say I'm definitely not sure that going only TLS 1.2 is the right decision, maybe the SSLLab mentioned/referenced browsers (IE8/10 and Safari 6.0.4) are still around in a meaningful number...

So I would be happy to know your opinion on this point.

Giannandrea