[aklug] Re: PSA: RC4 being disabled in IE and Edge on April 12

tl;dr: A corrected bare list of affected Alaskan servers is attached, and
remediation guidance is discussed in more detail.

I had incorrectly deduced in what circumstances sites will be affected. I
was filtering on sites without TLS 1.2 enabled. Enabling TLS 1.2 is
strongly recommended in order to use the expanded list of available ciphers
because this will ensure that after disabling RC4 ciphers, your clients
still have some ciphers that they can use. But TLS 1.2 status is not
directly related to your use of RC4-based ciphers, so my first list was not
filtered correctly. (My cached Qualys results were and are still fine; the
attached list was just a convenience).

The new, more accurate list is attached (readable in Notepad this time).
It lists my known Alaska sites with RC4 ciphers -- not only enabled, but
actively negotiated in at least one Qualys client handshake simulation.
This should be a better predictor of your potential risk.

Remediation on IIS: For those of you using IIS, use the free IISCrypto tool
[1] to activate the full list of good ciphers and put them in a solid
preferred order. If you're not sure what the user base is using, enable as
many modern ciphers as possible and take IISCrypto's advice about what
order to put them in.

Remediation on non-IIS servers: For those of you using non-IIS servers that
you can configure directly (non-appliances), the Mozilla config generator
[2] can help. You can pick exactly what version of Apache and OpenSSL
you're using to take advantage of any features available. Pay particular
attention to the "Modern|Intermediate|Old" radio button group. The "old"
setting leaves SSLv2 and SSLv3 enabled, so I do recommend overriding that
to explicitly disable SSLv2 and v3 as long as some TLS flavors are
available. Almost all of you should be able to use at least TLS 1.0 to
support almost all clients, but only your own logs can tell you for sure.

External verification: : You'll need to test the new TLS config, watch your
logs and call queues, and be ready to roll the changed back quickly if they
have unexpected impacts, of course. :) And run a fresh Qualys test [3]
directly yourself immediately afterwards (use the "CLEAR CACHE" link near
the top if needed to clear previous results) to verify that most client
simulations work (and are not using RC4).

Internal verification: If you have access to a Linux system or Cygwin, the
testssl.sh script [4] is useful for internal testing. Nmap's included
ssl-enum-ciphers script [5] will also identify RC4 ciphers, and there are
Windows binary distributions of Nmap.

Load balancers: Finally, remember that load balancers have their own TLS
configuration and may be where your public-facing TLS actually lives. If
you're using Citrix Netscalers, your options may be different depending on
code version, but a basic overview is at [6].

Royce

1. https://www.nartac.com/Products/IISCrypto
2. https://mozilla.github.io/server-side-tls/ssl-config-generator/
3. https://www.ssllabs.com/ssltest/index.html
4. https://testssl.sh/
5. https://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html
6.
https://discussions.citrix.com/topic/347711-pci-compliance-remove-rc4-ciphers/

On Sat, Mar 19, 2016 at 8:50 AM, Royce Williams <royce@tycho.org> wrote:

> tl;dr: My TLS cache data has been updated to show a count of RC4 clients.
> The higher your number, the more likely your users will be impacted.
>
>
> To make triage easier, I have updated my cached Qualys results to include
> a count of which clients are using RC4 (as predicted by Qualys client
> simulation).
>
> http://www.techsolvency.com/tls/
>
> If the number is non-zero, I'm now also giving that field a red/bad
> status, and adding 3 points to the risk score.
>
> But really, you probably don't need RC4. If you think that you do, move
> it to the very end of your cipher list, so that it is the last cipher
> offered by your server, and then re-run the Qualys test to see if any
> client simulations actually end up using it.
>
> If your RC4 number is non-zero, and your server is so old that you can't
> actually change the cipher order ... that's your root problem that will
> take lead time to fix. You'll probably need to upgrade or replace before
> April 12 ... or get your food chain to accept the risk/impact. If you can
> log which ciphers are actually being used, you can give them hard numbers
> of affected users to inform that decision, but you'll need to turn on such
> logging ASAP and keep the summarized results over time so that you can
> catch infrequent users.
>
> Here's one way to enable TLS logging in Apache:
>
> SSLOptions +StdEnvVars
> CustomLog /path/to/ssl.log "%t %h %{REMOTE_USER}x \"%{User-agent}i\"
> %{SSL_PROTOCOL}x %{SSL_CIPHER}x "
>
> For IIS, there appears to be no direct way to do this within some version
> of IIS, but this is a workaround using netsh:
>
>
> https://serverfault.com/questions/531830/logging-ssl-ciphersuite-used-in-windows-server-2008-r2
>
> The end goal to inform risk decisions is to log which clients are using
> which protocol and cipher over time, and at what volume. For low volume
> sites, you can do simple rotation and compression of the log (and keep a
> lot of history, as far back as you can manage (at least three months). If
> your logs are high-volume, you may need to summarize them instead of simply
> rotating and compressing them. You probably want to do this anyway,
> because you might need to aggregate the results in a big hurry if there's
> another Heartbleed.
>
> And if your results say "RC4 on (unused)", it's pretty likely that you can
> just disable your RC4-based cipher suites. Just make sure to enable some
> newer ones, too. :)
>
> As always, ping me if you have questions.
>
>

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.