I’ve noticed a few of my favorite websites failing with some odd error from Firefox.
The Firefox error message is a bit misleading. It actually has nothing to do with the website supporting SSL 3.0 but the advanced info is spot on. The error “ssl_error_no_cypher_overlap” means that the client didn’t offer any ciphers that the server also supports. Generally when I see this I assume that the server has been setup poorly and only supports unsafe ciphers. In this case the website only supports the RC4 cipher. I wondered why I was starting to see a reversal of removing RC4 from so many websites recently (especially since RC4 is very weak and is on the way out). Apparently these websites all use the F5 load balancer that had a bad implementation of the TLS 1.0 standard causing a POODLE-like vulnerability.
Stepping back for a moment, back in October the POODLE vulnerability hit the streets and a mass exodus from SSL 3.0 happened around the world. I was happy to see so many people running away from the broken cryptographic protocol and very happy to see the big push to implementing the latest version of TLS, TLS 1.2. So with SSL 3.0 out of the way and the POODLE vulnerability being squelched why are we seeing problems in TLS 1.0 now?
Well, simply put, F5 load balancers don’t implement TLS 1.0 correctly. The problem with SSL 3.0 is that the padding format isn’t checked. Apparently in the F5 devices it’s still a problem in TLS 1.0. And while the company did offer up patches to fix the issue, some really bad advice has been circulating the Internetz telling people to only support RC4, again. Sigh.
When RC4 finally dies a fiery death I’ll likely throw a party. I’m sure I won’t be the only one…
Due to a bug in mod_ssl, the ability to remove TLS 1.0 (and only support TLS 1.1 and/or TLS 1.2) has not been available. The fix has now made it to CentOS 6 and you can now fine-tune your cryptographic protocols with ease.
Before the fix my /etc/httpd/conf.d/ssl.conf file had this line:
SSLProtocol all -SSLv2 -SSLv3
This allows all SSL protocols except SSLv2 and SSLv3 to be used with httpd. This isn’t a bad solution but there are a couple of sites that I’d prefer to further lock down by removing TLS 1.0 and TLS
1.2 1.1. With the fix now in mod_ssl my settings can now look like this:
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
…and I’ll only support TLS 1.2 and beyond. Of course doing this will significantly reduce the number of clients that can connect to my server. According to SSLLabs I’m blocking all IE users before IE 11, Android before 4.4.2, Java 7, and Firefox 24.2.0 ESR. But luckily I really don’t have a problem with any of these browsers for a couple of things I do so I’ll likely tighten up security there and leave my more public sites alone.
NSS and mod_nss for httpd wasn’t discussed because it’s not in use on my systems. it should be noted that mod_nss can be similarly configured as mod_ssl however mod_nss does not support TLS 1.2 and you’ll max out at TLS 1.1.
My friend Hubert has been doing a lot of work to make better the world a little safer. Glad he’s getting some recognition. Here’s a great article on testing your server for proper SSL/TLS configurations.
I’ve been enjoying watching these trends.
Originally posted on securitypitfalls:
This time the results are not really different from past month’s ones. About two percent of servers more use SHA-256 signed certificates and 1% more has configuration that allows negotiation of PFS suites.
Small change to reported results: I’ve added “Insecure” entry which counts the number of servers that will use completely insecure cipher suite like single DES, RC2 or export grade ciphers. It doesn’t include the “controversial but not broken” IDEA and SEED ciphers.
SSL/TLS survey of 402742 websites from Alexa's top 1 million Stats only from connections that did provide valid certificates (or anonymous DH from servers that do also have valid certificate installed) Supported Ciphers Count Percent -------------------------+---------+------- 3DES 349454 86.7687 3DES Only 164 0.0407 AES 374868 93.0789 AES Only 1017 0.2525 AES-CBC Only 553 0.1373 AES-GCM 172322 42.7872 AES-GCM Only 7 0.0017 CAMELLIA 170577 42.3539 CHACHA20 15137 3.7585 Insecure 79666 19.7809 RC4 355750 88.332 RC4…
View original 1,216 more words
This morning I received an email from my “administrator” saying that I needed to validate my email address within the next 48 hours or my email account would be suspended. Seeing as how I’m my own email administrator, I couldn’t remember sending out such a message, I decided that this was likely spam. I’m always interested in seeing how these attacks are actually going to be played out so I clicked on the link.
Neat, Microsoft-y looking screen! And it looks like the backend is WordPress! It looks like the attacker is using the account system in WordPress to collect the information. When you submit your information for validation you get this response:
Your information was successfully submitted, please ensure that you entered your email details correctly; to enable us complete your security updates. If you have entered your details wrongly kindly click back and refill in details correctly.
N.B Please be informed that filling in the wrong details will be resulting to the deactivation of your email address.
I’m guessing my address will not be closed down, since I did not provide my correct email information. I don’t know, maybe I’ll disable my own email… you know, just for the weekend.
Wow, I had no idea that people would care about the start of this project. There seems to be a few questions out there that I’d like to address here to clarify what we are doing and why.
OMG! Fedora is just getting a security team? Does this mean Fedora has been insecure this entire time?!?
Umm, no, it doesn’t mean that Fedora has been insecure this entire time. In all actuality Fedora is in pretty good shape overall. There is always room for improvement and so we’re organizing a team to help facilitate that improvement.
What exactly is the security team responsible for?
We here to help packagers get the patches or new releases that fix vulnerabilities into the Fedora repositories faster. Most of our packagers are very good at shipping fixes for bugs when upstream rolls a new version of their software. Bug fixes can usually wait a few days, though, as most aren’t critical. Security vulnerabilities are a bit different and fixes should be made available as soon as possible. A little helping hand is never a bad thing and that’s what we’re here to do… help.
Can the security team audit package x?
No. This may become a service a different team (also falling under the Security SIG) can provide but I/we haven’t gotten there yet.
I read where Fedora has 566 vulnerabilities! How can you say that Fedora isn’t insecure?
Well, it’s actually 573 right this second. That’s down from 577 last week. 566 was Monday’s number. It’s important to not get caught up in the numbers cause they are, well, just numbers. The numbers only deal specifically with the number of tickets open. Many of the tickets are duplicates in that the same vulnerability might have several tickets opened for it if the finding is in only certain Fedora versions and EPEL versions. Since the same packager is likely responsible for all versions and the same fix can be made we can likely close several bugs at a time with minimal work.
I should also point out that the majority of these bugs fall well below the “world is on fire” level of Critical and the “this isn’t good” level of Important. This doesn’t mean we should just ignore these lower vulnerabilities but rather we should understand that they aren’t something that is likely to be exploited without many other bad things happening. Should they be fixed? Yes, but we should probably be more concerned with the Critical and Important vulnerabilities first. If you’d like to know more about the process for coming up with the severity rating my friend Vincent wrote an excellent article that you should read.
“6. Close bug when vulnerability is shipped in Fedora repos.”
Yeah, that isn’t correct. This is what happens when I try to multi-task. Glad I don’t get paid to write…. err… never mind. Luckily it’s a wiki and someone fixed it for me. Whew!
(We try to not deliberately release a package with a vulnerability. It seems people don’t appreciate vulnerabilities in the same way they like other features. Who would have thought?)
I’d like to help! How can I join up?
Go to the Security Team wiki page and look for the link to the mailing list and IRC channels, sign up, join up, and use the work flow to start digging in. Questions? Feel free to ask in the IRC channel or on the mailing list. You can also contact me directly if can’t otherwise find the answer to your question.
“You’re not allowed to join this video call.” was the greeting I found while trying to log into my astronomy class tonight. Thanks to Google and their Hangout app I’ve missed my last night of classes. Fantastic.
I blame Google for this, honestly, but I wonder if they are really the problem. They provide a service that has complex relationships with their other “products” and they provide this all for “free” to anyone that is willing to sign up (and allow them to track your every move). I’m sure they never said the thing would have certain availability (how could they, they are utilizing the Internet as a transport layer) so I have no expectation of this thing working… ever. And this is what happens when, as a society, we continue to embrace proprietary services that are completely out of our control. Even if there was some sort of agreement that this stuff would work all the time I would still be sitting here unable to join my class. Even from my FOSS software-running computer I am at the mercy of our proprietary overlords. It’s sad.