NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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 fromESGF, NASA, and NOAA regarding issues with the TDS when https is forced. Wevery 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 issuesince it was likely a change in a third party library that allows things towork, and we don't run older versions of the TDS.
thredds
archives: