Monthly Archives: November 2013

Link

FLOSS Survey 2013

Ten years after the successful FLOSS survey with over 2500 respondents, which had a major impact in community, academia and even politics, we want to recreate the survey with the goal of seeing how the community is nowadays and how it has changed.

If you are a contributor of any type (not only a developer!) to FLOSS, we encourage you to participate in the survey. It takes around 10-15 minutes.

We would also be grateful if you disseminate this announcement among your community and peers. More information about the survey, including privacy, results, authors and publications, can be found at http://floss2013.libresoft.es.

Kicking RC4 out the door

I’ve been arguing with my web hosting company about their use of RC4.  Like many enterprise networks they aren’t consistent across all their servers with respect to available ciphers and such.  It appears that all customer servers support TLS_RSA_WITH_CAMELLIA_256_CBC_SHA and TLS_RSA_WITH_CAMELLIA_128_CBC_SHA, in addition to TLS_RSA_WITH_RC4_128_SHA (although the latter is preferred over the other two) but their backend controlling web servers only support RC4.  This is a problem if you are handling crypto (keys) (and other settings) over a weak encryption path to better secure your web service as you have essentially failed due to using the weak encryption to begin with.

So what’s wrong with RC4?

It’s been known for a while (years!) that RC4 is not a good encryption cipher.  It’s broken and there are several attacks that are available.  So why is it being used so frequently?  In a word: BEAST.  RC4 was the only stream cipher available that can combat BEAST and so it became the standard for all TLS connections.  It’s not clear which attack vector is worse: BEAST or the weak RC4.

In recent months most Internet browsers have implemented the workaround n/n-1 to fix the BEAST vulnerability.  With the fix in place it should, once again, be safe to use block ciphers and, thus, get better encryption ciphers (better protection).  There have been many people and organizations talking about the need to get rid of RC4 now since it is a bigger threat to web security.  Yesterday Microsoft released a security bulletin discussing the problem and urged all developers to stop using RC4.  (Oh yeah, and they also want to stop using SHA-1 as well.)  I usually think of Microsoft as trailing in the security field (lets face it, their products aren’t known for being secure ever since that whole network thing happened) so when they say that this mess with RC4 must stop it’s gotten to a point where we should have already done so.

So what are we waiting for?

I think, simply, we’re waiting for TLSv1.1 and TLSv1.2 to become mainstream.  It’s not as if these technologies have just popped up on our radar screens, however, (they’ve been out since April 2006 and August 2008, respectfully) but there has been slow adoption of the two flavors of TLS.  According to Microsoft, their products are ready for TLSv1.1 and TLSv1.2 (both IIS on and IE 11+).  Firefox supports up to TLSv1.2 in 25.0 but you have to manually turn it on (it’s for testing) and OpenSSL (used for Apache) should support TLSv1.2 in its 1.0.1e release.  It’s time to start pushing these better encryption mechanisms into operation… now.

Updates

What Google has to say on the subject.