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

From: Royce Williams <royce@tycho.org>
Date: Sat Mar 19 2016 - 08:50:06 AKDT

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.

Royce

On Thu, Mar 17, 2016 at 7:56 AM, Royce Williams <royce@tycho.org> wrote:

> For those of you trapped in operating systems written by a company
> that decided to arbitrarily reinvent the record separator, that
> attachment can be opened in Wordpad to be read. ;)
>
> Royce
>
> On Thu, Mar 17, 2016 at 7:53 AM, Royce Williams <royce@tycho.org> wrote:
> > tl;dr: If IE can't get to your site on April 12, this is why; act now. :)
> >
> >
> > Summary post:
> >
> https://blogs.windows.com/msedgedev/2016/03/16/rc4-will-no-longer-be-supported-in-microsoft-edge-and-ie11-beginning-in-april/
> >
> > Technical post:
> >
> https://blogs.technet.microsoft.com/srd/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4/
> >
> > Depending on your cipher order, this may make your largest
> > customer/visitor base unable to reach your sites. You are more likely
> > to be impacted if your site shows as "RC4 on" here, and no TLS 1.2
> > support:
> >
> > http://www.techsolvency.com/tls/
> >
> > ... but you'll need to check your own config and your Qualys results
> > (linked from each record in my results).
> >
> > The first MS post above has guidance for evaluation methods and fixes.
> >
> > From my cached results, ~1600 Alaskan sites are potentially affected.
> > List attached (I hope). These are all the sites that appear to A) not
> > support TLS 1.2, and B) still use RC4-based ciphers. The actual list
> > of affected sites is probably lower, but these are the sites that
> > should be checked more closely.
> >
> > Royce
>

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Sat Mar 19 07:08:16 2016

This archive was generated by hypermail 2.1.8 : Sat Mar 19 2016 - 07:08:17 AKDT