September 15 2015 Tuesday
Domino adds HSTS to it’s security arsenal
I didn't see this initially (RTFM Darren....RTFM....).
HTTPS Strict Transport Security (HSTS).....what's that? I call on the all knowing Wikipedia for a short answer......
Basically it prevents some downgrade attacks, some man in the middle attacks and some cookie hijacking attacks.
Now you've been able to add HSTS to Domino via web site rules, but like everything with web site rules, you had to remember. With security, if you have to remember, you probably won't remember to do it. But now the kindly folks at IBM have made it automatic.
I stumbled upon this during a Qualys SSL Labs test when I scanned a 9.0.1 FP4 server and saw this:
Humm, , that was not there before, it used to be disabled (and not green) unless I hacked around some.... so off I go to find out when IBM added it and I find Dave Kern's IBM article that states this was added in 9.0.1 FP3 IF2 and higher and also lists these notes.ini to control the behavior:
To fix the "TOO SHORT" warning in the SSL Labs test add the following to the notes.ini (also add the sub-domain one too for enhanced security):
Scanning a 9.0.1 FP3 IF1 server show that it was indeed not in that version of Domino:
So there you have it, Domino and automatic enablement of HSTS....who knew?
HTTPS Strict Transport Security (HSTS).....what's that? I call on the all knowing Wikipedia for a short answer......
It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections,and never via the insecure HTTP protocol
Basically it prevents some downgrade attacks, some man in the middle attacks and some cookie hijacking attacks.
Now you've been able to add HSTS to Domino via web site rules, but like everything with web site rules, you had to remember. With security, if you have to remember, you probably won't remember to do it. But now the kindly folks at IBM have made it automatic.
I stumbled upon this during a Qualys SSL Labs test when I scanned a 9.0.1 FP4 server and saw this:
Humm, , that was not there before, it used to be disabled (and not green) unless I hacked around some.... so off I go to find out when IBM added it and I find Dave Kern's IBM article that states this was added in 9.0.1 FP3 IF2 and higher and also lists these notes.ini to control the behavior:
Starting in Domino 9.0.1 FP3 IF2, when a Domino server is configured for SSL/TLS and the http port is disabled or set to "redirect only" the HSTS header will be sent by with a one week default setting. If the Domino server is not configured for SSL/TLS or the http port is active, the HSTS header will be sent with the max-age parameter set to zero, which disables the HSTS functionality.
- HTTP_HSTS_MAX_AGE allows the max-age header parameter to be changed, the default setting is 604800 seconds, 1 Week
- HTTP_HSTS_INCLUDE_SUBDOMAINS=1 indicates the "includeSubDomains" parameter should be added to the "Strict-Transport-Security" http header. This is off by default.
- HTTP_ENABLE_HSTS=0 can be used to disable HSTS and not send the Strict-Transport-Security header.
To fix the "TOO SHORT" warning in the SSL Labs test add the following to the notes.ini (also add the sub-domain one too for enhanced security):
HTTP_HSTS_INCLUDE_SUBDOMAINS=1
HTTP_HSTS_MAX_AGE=63072000
Scanning a 9.0.1 FP3 IF1 server show that it was indeed not in that version of Domino:
So there you have it, Domino and automatic enablement of HSTS....who knew?
Darren Duke
|
September 15 2015 07:53:45 AM
|
domino 901 ssl security
|
Discussion for this entry is now closed.
Comments (3)
Did I understand correctly that HSTS prohibits the browser to change from https to http on the same site in a redirect ?
@2, there is a warning in the IBM document about "mixed pages". If your server is set to redirect all HTTP traffic to HTTPS I do not see how would be an issue. Additionally my understanding (and this seems to be backed up by Wikipedia) is that a "conformant" user agent (in this case a browser) is supposed to change any none secure links to secure links. This assumption also looks to be correct if you look at the RFC and look at step 8.3.5, "The UA MUST replace the URI scheme with "https"...."
Oh hey, good on them - that's a clever, transparent implementation.