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>

TLS Settings

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

SecureListeners Attribute

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.

Browsers/Clients

Chrome

If left to default settings in Java, Chrome 36 will start with TLSv1.2 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.

FireFox

If left to default settings in Java, FireFox 31 will start with TLSv1.2 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.

IE

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.

Fiddler v4.4.9.3

Seems to require TLSv1 and uses TLS_RSA_WITH_AES_128_CBC_SHA. Fiddler would not be considered a properly patched client for BEAST.

Testing

Use this tool to view the supported protocols and suites https://www.ssllabs.com/ssltest/viewMyClient.html of a given browser.

Strict Mode

Strict Mode is the default mode for DivConq, you must specify the Harden setting if you want to use something other than Strict mode.

Protocol

  • TLSv1.2

Suites

  • 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

Loose Mode

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. ``BEASTattacksCBC` 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:

Protocols

  • TLSv1.1
  • TLSv1

Suites

  • 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

Custom Mode

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>

Suite Name

How do you read names like TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 or TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384?

TLS

TLS or SSL is the transport protocol applicable to the suite.

Key Exchange

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

Encryption

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.

Integrity

SHA384, SHA256, SHA (aka SHA-128) and MD5 are all examples of TLS message integrity mechanisms.

Java 8 Complete List

Protocols

  • SSLv2Hello
  • SSLv3
  • TLSv1
  • TLSv1.1
  • TLSv1.2

Cipher Suites

  • 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

Testing a Server

SSL Labs

https://www.ssllabs.com/ssltest/

[Example of before any hardening is done to Java 8] (Docs/Harden Before.pdf)

HSTS

<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

Content Security Policy

<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.

Custom Literal Headers

<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.

Example 1 - Set Header if not present

<Http>
	<Header Name="X-Content-Type-Options" Value="nosniff" />
</Http>

Example 2 - Remove Header no matter what

<Http>
	<Header Name="X-Content-Type-Options" Override="True" />
</Http>
⚠️ **GitHub.com Fallback** ⚠️