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
...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
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
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
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
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
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
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
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
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
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
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
(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
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
Weak ciphers? Old (insecure) protocol versions? Open security issues? Vendor
will never provide a patch? Trash goes in the trash bin, no exceptions.
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.
* 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
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.
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
20 matches
Mail list logo
