Just ran into this issue this morning. The SEC requires companies to file EDGAR reports on https://edgarfiling.sec.gov. The newer versions of Firefox won't let you access the webpages without manually going into about:config and re-enabling the weak ciphers. Given the recent issue with the OPM, I would think this would be a very bad follow-up if the SEC got hacked.
SSLLabs gives the website an "F". IE 11 won't work either (for other reasons). https://www.ssllabs.com/ssltest/analyze.html?d=edgarfiling.sec.gov
The website looks like it was designed in the '90s. I've tried to reach out to their contacts (webmaster, oig, etc...) but haven't gotten a reply yet. It's possible that I might get a reply eventually, but does anyone have any direct contacts at the SEC?
many web sites are gonna have to upgrade ciphers and get rid of flash.
this will take vastly longer than prudence would dictate.
randy
Well, this block also affects people who have old management hardware
around using such ciphers that are for example no longer supported. In my
case for example the old Dell DRAC's. And it seems there is no way to
disable this block.
Ok, it is good to think about security, but not giving you any chance to
make exceptions is simply forcing users to use another browser in order to
manage those devices, or to keep an old machine around that not gets
updated.
Or just fallback to no SSL in some cases 
We have some old vendor things that were chugging along until everyone upgraded firefox and then suddenly they stopped working. The "fix" was to use the alternate non-SSL web port rather than upgrade because even though the software is old, it's too critical to upgrade it in-line.
The long term fix is to get new hardware and run it all in virtual machines with new software on top, but that may be in next years budget. I've also got a jetty server (opennms) that broke due to this, so I upgraded and fixed the SSL options and it's still broken in some way that won't log errors. I have no time to track that down so the workaround is to use the unencrypted version until I can figure it out.
Having said that, it seems that there is a workaround in Firefox if people need it. about:config and re-enabling the weak ciphers. Hopefully turning them on leaves you with a even bigger warning than normal saying it's a bad cert, but you could get back in. This doesn't help my coworkers. I'm not going to advise a bunch of people with varying levels of technical competency to turn on weak ciphers, but it does help with a situation like yours where you absolutely can't update old DRAC stuff.
https://support.mozilla.org/en-US/questions/1042061
After making the about:config changes, no warning is given to the user about the bad ciphers. Even if you click the SSL lock icon, no warning is given. Only if you know that the connection being made with "TLS_RSA_WITH_AES_128_CBC_SHA,128 bit keys, TLS 1.0" is a bad thing would you have any clue.
We had a ticket about this a couple weeks ago from a support client who
was catching flak from a PCI-DSS audit team. Here's the changeset that
should address the problem:
https://github.com/OpenNMS/opennms/commit/6da9e8952e7f81b0b863da93add684c5e963e0ba
-jeff
As of 38.0.5, this no longer is even an option, as they removed sslv3
support, see the reviews at
https://addons.mozilla.org/en-US/firefox/addon/ssl-version-control/
Robert Drake <rdrake@direcpath.com> writes:
> Well, this block also affects people who have old management hardware
> around using such ciphers that are for example no longer supported. In my
> case for example the old Dell DRAC's. And it seems there is no way to
> disable this block.
>
> Ok, it is good to think about security, but not giving you any chance to
> make exceptions is simply forcing users to use another browser in order to
> manage those devices, or to keep an old machine around that not gets
> updated.
>
Or just fallback to no SSL in some cases 
We have some old vendor
things that were chugging along until everyone upgraded firefox and
then suddenly they stopped working. The "fix" was to use the
alternate non-SSL web port rather than upgrade because even though the
software is old, it's too critical to upgrade it in-line.
This is going to happen, probably more and more in the future.
There's a point where making 99% of the web secure is better than
keeping an old 1% working; so if you have hardware that's in the 1% or
.1%, one day you'll wake up and there'll be an update out and that
update will break your old stuff. Worse, in the future the update
might have already been applied overnight.
The next one of these that I know is coming, and just don't know
exactly when, is RC4. Somewhere on the horizon is SHA-1. Also:
<2048-bit RSA keys, <2048-bit DH, TLS 1.0. There's probably others I
have forgotten.
making 99% of the web secure is better than keeping an old 1% working
A fine idea, unless for $reason your application is among the 1% .. nevermind the arrogance of the "I'm sorry Dave" sort of attitude.
As an example .. we have a vendor who, in the current release (last 3 months) still requires "weak" ciphers in authentication responses. That was mostly okay until another vendor (with more sense) wanted to auth the same way but only permitted strong ciphers.
My $0.02
Michael Holstein
Cleveland State University
* michael.holstein@csuohio.edu (Michael O Holstein) [Fri 17 Jul 2015, 21:14 CEST]:
making 99% of the web secure is better than keeping an old 1% working
A fine idea, unless for $reason your application is among the 1% .. nevermind the arrogance of the "I'm sorry Dave" sort of attitude.
Why do you upgrade your management systems asynchronously to your applications? You bring this on yourself.
As an example .. we have a vendor who, in the current release (last 3 months) still requires "weak" ciphers in authentication responses.
That was mostly okay until another vendor (with more sense) wanted to auth the same way but only permitted strong ciphers.
Why do you access mission-critical systems that are provably insecure from systems that also have internet access?
If it's not mission-critical, then you should explain why you haven't dumped that vendor yet for shipping insecure software - an insecurity that is very easy to mitigate by them, should they have chosen to.
-- Niels.
Why do you upgrade your management systems asynchronously to your
applications? You bring this on yourself.
Perhaps, but SaaS "management systems" are out of our control. They TELL us when they upgrade, they do not ASK. A web browser isn't really an application, you can't wait to upgrade.
Related head-shaker .. the premier vendor of time management (who shall remain nameless) requires an outdated version of java that has a number of known vulnerabilities. They have been doing this for several years now.
Why do you access mission-critical systems that are provably insecure
from systems that also have internet access?
Because they are "hosted" magical unicorn "cloud services" .. they ARE ON the Internet.
If it's not mission-critical, then you should explain why you haven't
dumped that vendor yet for shipping insecure software - an insecurity
that is very easy to mitigate by them, should they have chosen to.
Contracts, that's why. And it's not "shipping" anything .. these are "enterprise" cloud services that cost on the order of $50k-$100k per year.
My $0.02 .. any reference to a company fictional or not is purely coincidental, etc.
Michael Holstein
Cleveland State University
Hey, if those DRACs can't get updated to not use piss-weak ciphers, what's
the problem with having one more machine laying around unpatched to manage
them?
- Matt
>making 99% of the web secure is better than keeping an old 1% working
A fine idea, unless for $reason your application is among the 1% ..
nevermind the arrogance of the "I'm sorry Dave" sort of attitude.
First they came for SSLv2, and I said nothing because...
As an example .. we have a vendor who, in the current release (last 3
months) still requires "weak" ciphers in authentication responses. That
was mostly okay until another vendor (with more sense) wanted to auth the
same way but only permitted strong ciphers.
So get up your vendors to update their stuff, and *preferably* before a
super-critical hole is found in protocols that should have ideally died a
natural death years ago. TLS 1.2, AES, and SHA-256 aren't exactly "OMFG
new!" at this stage of the game.
Also, take this as a learning experience: next time, make sure RFPs and
contracts include an undertaking to maintain compatibility with reasonably
recent standards, and financial penalties for the vendor if their failure to
do so results in operational problems for you.
- Matt
Weak ciphers? Old (insecure) protocol versions? Open security issues? Vendor
will never provide a patch? Trash goes in the trash bin, no exceptions.
Federal government lands on you like a sack of bricks if you don't provide
this information through their (in)secure website. No exceptions.
Sometimes you can't fire the vendor because they're not a vendor, they're a
freaking regulatory agency with the power to crush you like a bug, and a 5
year approval process to get anything done, never mind a month turnaround
for a recently discovered exploit.
...on Fri, Jul 17, 2015 at 01:42:37PM +0000, Matthew Huff wrote:
> After making the about:config changes, no warning is given to the user about the bad ciphers. Even if you click the SSL lock icon, no warning is given. Only if you know that the connection being made with "TLS_RSA_WITH_AES_128_CBC_SHA,128 bit keys, TLS 1.0" is a bad thing would you have any clue.
I've found the Calomel SSL Validation Add-on to be quite useful in that
regard. It adds some controls to access FF encryptions settings, as well
as a quick overview on the quality of a TLS connection:
https://calomel.org/firefox_ssl_validation.html
https://addons.mozilla.org/en-us/firefox/addon/calomel-ssl-validation/
In general, an old version of Firefox Portable seems a must-have item in
the admin toolchest right now - there's just too much stuff still out
there that can't be accessed with either current Firefox or IE anymore.
Alex.