I think that the right approach is the one you suggest.
When our server gets an http: request, it should send back
the redirect to the client to handle. It should not be
the case that our server does the redirect itself.
=Dennis Heimbigner
Unidata
On 11/20/2017 3:57 PM, Ben Caradoc-Davies wrote:
There is no graceful way to do this. This is a chicken and egg problem.
Server-side changes are forcing library maintainers to apply fixes.
Support for insecure protocols enables connection downgrade and is a
proven attack vector. We have seen this before with the removal of
support for weak SSL ciphers and certificates: clients do not upgrade
until forced to do so. Some providers do not upgrade until clients
upgrade and complain.
That said, communication in advance is the key. I endorse Roy's request
that changes be announced in advance, something like "SECURITY: service
change in two weeks, upgrade to latest stable now" or similar. We will
be doing this again. Quantum computers are coming and we will be junking
our current public key algorithms. It is just a matter of time:
https://en.wikipedia.org/wiki/Post-quantum_cryptography
Kind regards,
Ben.
On 21/11/17 11:36, Sean Arms wrote:
As a somewhat related issue, many organizations are requiring all
connections go to https, and we have had several support questions from
ESGF, NASA, and NOAA regarding issues with the TDS when https is
forced. We
very recently setup our development TDS to have apache force https
everywhere to hopefully catch issues sooner rather than later.
Unfortunately, I don't think we could have caught this particular issue
since it was likely a change in a third party library that allows
things to
work, and we don't run older versions of the TDS.
