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
(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: the same way but only permitted strong ciphers.
My $0.02
Michael Holstein Cleveland State University
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
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-bounces@nanog.org> on behalf of Alexander Maassen <outsider@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: the same way but only permitted strong ciphers.
My $0.02
Michael Holstein Cleveland State University
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-bounces@nanog.org> on behalf of Alexander Maassen <outsider@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'
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
On Fri, July 17, 2015 9:14 pm, Michael O Holstein wrote: the same way but only permitted strong ciphers.
My $0.02
Michael Holstein Cleveland State University
17. Jul 2015 21:06 by will.mcdermott@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
Is this also why you can't login to wells fargo online using firefox? Neat. =) -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of tqr2813d376cjozqap1l@tutanota.com Sent: Sunday, July 19, 2015 11:03 PM To: Will M. <will.mcdermott@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.mcdermott@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
participants (5)
-
Alexander Maassen -
Drew Weaver -
Michael O Holstein -
tqr2813d376cjozqap1l＠tutanota.com -
Will M.