Config Harden - Gadreel/divconq GitHub Wiki
In config set the Hub wide hardening settings by adding a Harden section. I typically add it after Clock like this:
<Clock ... />
<Harden>
<TLS
Mode="Strict|Loose|Custom"
Protocols="[comma list of protocols]"
Suites="[comma list of suites]"
/>
<Http>
<ContentSecurityPolicy
Mode="Strict|Loose"
ReportOnly="True|False"
Override="True|False"
/>
<Hsts
Mode="Strict|Self"
Age="[ISO 8601 duration]"
Override="True|False"
/>
<Header Name="[name]" Override="True|False" Value="[literal]" />
</Http>
...TODO which ports can listen...
<AuthorizedListeners
SecurePorts="[comma list]"
UnsecurePorts="[comma list]"
/>
</Harden>
In the security field its a good idea to support as few protocols and suites as possible, while still supporting your target audience. Here is what web browsers support:
http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers
So while ideally we would support only TLSv1.2
and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
, it isn't practical to support only these if a web browser is involved.
Notes about testing and grading TLS support https://www.ssllabs.com/projects/index.html
If set to Required then all listeners are required to be secure. If any are found to be insecure then the Hub will not start and config must be corrected.
If left to default settings in Java, Chrome 36 will start with TLSv1.2
and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
.
If left to default settings in Java, FireFox 31 will start with TLSv1.2
and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
.
If left to default settings in Java, IE 11 will start with TLSv1.2
and TLS_RSA_WITH_AES_128_CBC_SHA256
. If forced by the server though, IE will use TLS_RSA_WITH_AES_256_CBC_SHA256
instead.
Seems to require TLSv1
and uses TLS_RSA_WITH_AES_128_CBC_SHA
. Fiddler would not be considered a properly patched client for BEAST
.
Use this tool to view the supported protocols and suites https://www.ssllabs.com/ssltest/viewMyClient.html of a given browser.
Strict Mode is the default mode for DivConq, you must specify the Harden setting if you want to use something other than Strict mode.
- TLSv1.2
- AES 256 GCM
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
- TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- AES 256 CBC
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
- TLS_RSA_WITH_AES_256_CBC_SHA256
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
- AES 128 GCM
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
- TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Non-modern browsers need TLSv1
as TLSv1.1
support was more or less skipped by most browser vendors. Along with TLSv1
is a need for RC4
which is crap but necessary to cover the BEAST
attack. ``BEASTattacks
CBC` and `GCM` is not available in `TLSv1`. So that leaves only `RC4` as an option. To protected from `BEAST` originally servers had to disable `CBC` (in other words disable `AES`) and leave only `RC4` enabled. However, nearly all the old browsers still in use are patched and automatically use `RC4` with `TLSv1`. So now the servers may offer `CBC` as well as `RC4` - the `CBC` being appropriate for `TLSv1.1` or `TLSv1.2`. It would be better to turn off `CBC` and use only `GCM` and `RC4` for Loose but IE needs the `CBC` option.
Loose supports all that Strict does but adds:
- TLSv1.1
- TLSv1
- RC4 128
- TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
- TLS_ECDHE_RSA_WITH_RC4_128_SHA
- TLS_ECDH_ECDSA_WITH_RC4_128_SHA
- TLS_ECDH_RSA_WITH_RC4_128_SHA
If using Custom
mode DivConq will look in the Protocols
and Suites
attributes for comma lists to enable. For example:
<Harden>
<TLS Mode="Custom" Protocols="SSLv2Hello,SSLv3,TLSv1"
Suites="TLS_RSA_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_MD5" />
</Harden>
How do you read names like TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
or TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
?
TLS or SSL is the transport protocol applicable to the suite.
DHE_RSA
is Ephemeral Diffie Hellman signed using RSA keys. Where DH is used for forward secrecy and RSA guards against MITM. ECDHE_RSA
is Elliptic Curve Ephemeral Diffie Hellman signed using RSA keys.
More info on forward secrecy: http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html
Once key exchange is complete the transport switches to using symmetrical encryption. AES 256 is the best available for TLS. AES will use either CBC or GCM block modes, the later being newer and faster and hopefully more secure. So AES_256_GCM
or RC4_128
are examples of the encryption mode. With modern x64 processors AES_256_GCM
can be hardware accelerated and, therefore, there seems little reason to use anything less.
SHA384
, SHA256
, SHA
(aka SHA-128) and MD5
are all examples of TLS message integrity mechanisms.
- SSLv2Hello
- SSLv3
- TLSv1
- TLSv1.1
- TLSv1.2
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_RSA_WITH_AES_256_CBC_SHA256
- TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
- TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
- TLS_ECDHE_RSA_WITH_RC4_128_SHA
- SSL_RSA_WITH_RC4_128_SHA
- TLS_ECDH_ECDSA_WITH_RC4_128_SHA
- TLS_ECDH_RSA_WITH_RC4_128_SHA
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
- TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
- SSL_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
- TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
- SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
- SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
- SSL_RSA_WITH_RC4_128_MD5
- TLS_EMPTY_RENEGOTIATION_INFO_SCSV
- TLS_DH_anon_WITH_AES_256_GCM_SHA384
- TLS_DH_anon_WITH_AES_128_GCM_SHA256
- TLS_DH_anon_WITH_AES_256_CBC_SHA256
- TLS_ECDH_anon_WITH_AES_256_CBC_SHA
- TLS_DH_anon_WITH_AES_256_CBC_SHA
- TLS_DH_anon_WITH_AES_128_CBC_SHA256
- TLS_ECDH_anon_WITH_AES_128_CBC_SHA
- TLS_DH_anon_WITH_AES_128_CBC_SHA
- TLS_ECDH_anon_WITH_RC4_128_SHA
- SSL_DH_anon_WITH_RC4_128_MD5
- TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
- SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
- TLS_RSA_WITH_NULL_SHA256
- TLS_ECDHE_ECDSA_WITH_NULL_SHA
- TLS_ECDHE_RSA_WITH_NULL_SHA
- SSL_RSA_WITH_NULL_SHA
- TLS_ECDH_ECDSA_WITH_NULL_SHA
- TLS_ECDH_RSA_WITH_NULL_SHA
- TLS_ECDH_anon_WITH_NULL_SHA
- SSL_RSA_WITH_NULL_MD5
- SSL_RSA_WITH_DES_CBC_SHA
- SSL_DHE_RSA_WITH_DES_CBC_SHA
- SSL_DHE_DSS_WITH_DES_CBC_SHA
- SSL_DH_anon_WITH_DES_CBC_SHA
- SSL_RSA_EXPORT_WITH_RC4_40_MD5
- SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
- SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
- SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
- SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
- SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
- TLS_KRB5_WITH_RC4_128_SHA
- TLS_KRB5_WITH_RC4_128_MD5
- TLS_KRB5_WITH_3DES_EDE_CBC_SHA
- TLS_KRB5_WITH_3DES_EDE_CBC_MD5
- TLS_KRB5_WITH_DES_CBC_SHA
- TLS_KRB5_WITH_DES_CBC_MD5
- TLS_KRB5_EXPORT_WITH_RC4_40_SHA
- TLS_KRB5_EXPORT_WITH_RC4_40_MD5
- TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
- TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
https://www.ssllabs.com/ssltest/
[Example of before any hardening is done to Java 8] (Docs/Harden Before.pdf)
<Http>
<Hsts
Mode="Strict|Self"
Age="[ISO 8601 duration]"
Override="True|False"
/>
</Http>
- Mode
- Strict = self plus subdomains
- Self = just self
- Override = Override the header even if set in code
- Age = ISO 8601 duration - for example "P3Y" would be three years, defaults to 5 years
<Http>
<ContentSecurityPolicy
Mode="Strict|Loose"
ReportOnly="True|False"
Override="True|False"
/>
</Http>
- Mode = Strict: Self for everything except connections, Loose: Self for script/html but unsafe Style
- Strict: default-src 'self'; img-src 'self' data:; media-src mediastream:; frame-ancestors 'self'; connect-src *;
- Loose: default-src 'self'; img-src *; media-src *; font-src *; style-src 'unsafe-inline' *; frame-ancestors 'self'; connect-src *;
- Override = Override the header even if set in code
- ReportOnly = report the errors but don't block content that fails the policy
Rational: The most important thing for CSP is that Script and Html are only loaded from SELF domain. Many dcWeb applications are single page applications (like AngularJS) and therefore the number of places where XSS attacks are possible is low. We can carefully monitor those. The likely hood of successful XSS in this arrangement is very low and the fact that no script can be injected (no 'unsafe' allowed) also greatly reduces the footprint for issues.
The allowance of data:
URLs is the only vulnerable spot in Strict. And those are only an issue in a CMS style application that allows users to contribute page content or if an unlikely injection bug exists. Keeping to web development best practices will effectively eliminate those issues.
<Http>
<Header Name="[name]" Override="True|False" Value="[literal]" />
</Http>
- Name = name of the header
- Override = Override the header even if set in code
- Value = literal value of the header. if no value given then remove the header.
<Http>
<Header Name="X-Content-Type-Options" Value="nosniff" />
</Http>
<Http>
<Header Name="X-Content-Type-Options" Override="True" />
</Http>