RE: Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
Is this also why you can't login to wells fargo online using firefox? Neat. =) -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of tqr2813d376cjozqa...@tutanota.com Sent: Sunday, July 19, 2015 11:03 PM To: Will M. will.mcderm...@sjsu.edu Cc: nanog@nanog.org Subject: Re: Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers 17. Jul 2015 21:06 by will.mcderm...@sjsu.edu: Load balancers can also be used like this, while maintaining redundancy (assuming HA LB config). Terminate SSL/TLS on the LB and run plain-text to the application/appliance. As long as the load balancer is in an acceptable part of the network. Hm, that seems familiar... https://i.imgur.com/ZhQLJmG.jpg
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
...on Fri, Jul 17, 2015 at 01:42:37PM +, 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.
Re: Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
17. Jul 2015 21:06 by will.mcderm...@sjsu.edu: Load balancers can also be used like this, while maintaining redundancy (assuming HA LB config). Terminate SSL/TLS on the LB and run plain-text to the application/appliance. As long as the load balancer is in an acceptable part of the network. Hm, that seems familiar... https://i.imgur.com/ZhQLJmG.jpg
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
Load balancers can also be used like this, while maintaining redundancy (assuming HA LB config). Terminate SSL/TLS on the LB and run plain-text to the application/appliance. As long as the load balancer is in an acceptable part of the network. --Will On 7/17/15 1:59 PM, Michael O Holstein wrote: Yes, the config option in FF is global .. I'm sure it could be done with an extension though. The 'el cheapo' solution that comes to mind is use a Rasberry Pi with dual ethernet (second via USB) and run Nginx on it .. secure out the front, insecure out the back. It'd cost you something like $50. I'm surprised SSL stupidifiers aren't on sale for $9 at Aliexpress or DX. -Mike From: NANOG nanog-boun...@nanog.org on behalf of Alexander Maassen outsi...@scarynet.org Sent: Friday, July 17, 2015 4:50 PM To: nanog@nanog.org Subject: Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers (Sorry Michael for the duplicate, forgot to press reply all :P) No problem making the web more secure, but in such cases I think it would have been better if you could set this behaviour per site, same as with 'invalid/self signed certs'. And in some cases, vendors use weak ciphers because they also utilize less resources. Everyone who has a DRAC knows about it's sluggish performance. Another backdraw of the DRAC's is, they are https only, and you cannot turn this behaviour off. Guess for that the only options would be to make your own interface and utilize the telnet/snmp interface. (Which is probably less secure then SSLv3), or some form of SSLv3 - strong cipher proxy. And needing to replace hardware that works perfectly fine for the purposes it's intended for just because a browser refuses to connect to it and denies you the option to make exceptions sounds just like the well known error 'Not enough money spend on hardware' On Fri, July 17, 2015 9:14 pm, 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. 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
Re: Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
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, tqr2813d376cjozqa...@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.
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
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/ On Fri, July 17, 2015 2:41 pm, Robert Drake wrote: 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
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
RE: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
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-boun...@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
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
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/6da9e8952e7f81b0b863da93add684c5e963e0ba -jeff signature.asc Description: OpenPGP digital signature
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
many web sites are gonna have to upgrade ciphers and get rid of flash. this will take vastly longer than prudence would dictate. randy
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
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
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
Robert Drake rdr...@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.
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
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
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
(Sorry Michael for the duplicate, forgot to press reply all :P) No problem making the web more secure, but in such cases I think it would have been better if you could set this behaviour per site, same as with 'invalid/self signed certs'. And in some cases, vendors use weak ciphers because they also utilize less resources. Everyone who has a DRAC knows about it's sluggish performance. Another backdraw of the DRAC's is, they are https only, and you cannot turn this behaviour off. Guess for that the only options would be to make your own interface and utilize the telnet/snmp interface. (Which is probably less secure then SSLv3), or some form of SSLv3 - strong cipher proxy. And needing to replace hardware that works perfectly fine for the purposes it's intended for just because a browser refuses to connect to it and denies you the option to make exceptions sounds just like the well known error 'Not enough money spend on hardware' On Fri, July 17, 2015 9:14 pm, 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. 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
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
On Fri, Jul 17, 2015 at 07:14:17PM +, 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
Re: Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
Weak ciphers? Old (insecure) protocol versions? Open security issues? Vendor will never provide a patch? Trash goes in the trash bin, no exceptions.
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
On Fri, Jul 17, 2015 at 10:26:22AM +0200, Alexander Maassen wrote: 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. 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
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
* michael.holst...@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.
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
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
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
Yes, the config option in FF is global .. I'm sure it could be done with an extension though. The 'el cheapo' solution that comes to mind is use a Rasberry Pi with dual ethernet (second via USB) and run Nginx on it .. secure out the front, insecure out the back. It'd cost you something like $50. I'm surprised SSL stupidifiers aren't on sale for $9 at Aliexpress or DX. -Mike From: NANOG nanog-boun...@nanog.org on behalf of Alexander Maassen outsi...@scarynet.org Sent: Friday, July 17, 2015 4:50 PM To: nanog@nanog.org Subject: Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers (Sorry Michael for the duplicate, forgot to press reply all :P) No problem making the web more secure, but in such cases I think it would have been better if you could set this behaviour per site, same as with 'invalid/self signed certs'. And in some cases, vendors use weak ciphers because they also utilize less resources. Everyone who has a DRAC knows about it's sluggish performance. Another backdraw of the DRAC's is, they are https only, and you cannot turn this behaviour off. Guess for that the only options would be to make your own interface and utilize the telnet/snmp interface. (Which is probably less secure then SSLv3), or some form of SSLv3 - strong cipher proxy. And needing to replace hardware that works perfectly fine for the purposes it's intended for just because a browser refuses to connect to it and denies you the option to make exceptions sounds just like the well known error 'Not enough money spend on hardware' On Fri, July 17, 2015 9:14 pm, 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. 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
