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. On Fri, July 17, 2015 10:14 am, Randy Bush wrote:

many web sites are gonna have to upgrade ciphers and get rid of flash. this will take vastly longer than prudence would dictate.

randy

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. ---- Matthew Huff             | 1 Manhattanville Rd Director of Operations   | Purchase, NY 10577 OTA Management LLC       | Phone: 914-460-4039 aim: matthewbhuff        | Fax:   914-694-5669 -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Robert Drake Sent: Friday, July 17, 2015 8:42 AM To: nanog@nanog.org Subject: Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers On 7/17/2015 4:26 AM, Alexander Maassen wrote:

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

On 07/17/2015 08:41 AM, Robert Drake wrote:

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.

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/6da9e8952e7f81b0b863da93add684c5e9... -jeff

Robert Drake <rdrake@direcpath.com> writes:

On 7/17/2015 4:26 AM, Alexander Maassen wrote:

...

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.

* 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.

On Fri, Jul 17, 2015 at 07:14:17PM +0000, Michael O Holstein wrote:

...

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 -- aren't they getting rarer than amigas now? just without all that fuzzy "good times" nostalgia? -- Ron Lee, in #debian-devel, on Itanic

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 10:50 PM, <tqr2813d376cjozqap1l@tutanota.com> wrote:

Weak ciphers? Old (insecure) protocol versions? Open security issues? Vendor will never provide a patch? Trash goes in the trash bin, no exceptions.