Jump to content
Snow?
Local
Radar
Cold?

unixmaven

Members
  • Posts

    2
  • Joined

  • Last visited

Everything posted by unixmaven

  1. It's still the same problem I explained a few pages back. NOAA have misconfigured their server and are not sending the chain of intermediate certificates needed to establish a chain of trust back to a mutually trusted root certificate.
  2. Yes, but this is wildly, wildly off topic. We will start with the easy bit. When a post is created containing an image, the software takes its own local copy of a scaled down version and serves that up, and links to the full sized one elsewhere on the internet. The image in the post was linked to the "curnow" (that is, most up to date) version of the snow+ice map. The snapshot was taken on the day of the post, while clicking through gets you the actual, current version for right now. To avoid this, the archived version with a datestamp in its name should be preferred. Now the harder to understand bit. In order to ensure the security and authenticity of a website, we use a system called TLS (Transport layer Security), built on a system called Public Key Cryptography. Public Key Cryptography allows us to break keys down into a secret and a non-secret component, which are effectively interchangeable. Anything encrypted using a public (nonsecret) key may be decrypted using the secret key, and anything encrypted using the secret key may be decrypted using the public key. For encryption purposes, you would normally encrypt with the public key, and the recipient would decrypt using their secret (or private) key. However, if you turn this on its head, and encrypt something with your private key, so that ther people can decrypt it with your public key, then you arrive in a situation where the payload is not secret (everyone can decrypt it) but they can be confident that it genuinely came from you, because only you know your secret key, and therefore nobody else could possibly have used it for encryption. HOWEVER, how do you know that the secret key actually belongs to www.natice.noaa.gov? I mean, anybody could create a key pair claiming to be them, and serve up anything. There is no assurance of identity. To solve this problem, we use a system of signed keys, which terminate with a trusted third party, The www.natice.noaa.gov public key is signed by the private key of the certificate issuer. The certificate issuer's public key is then signed by a more "trusted" key, until in the end you arrive at the root key. Now, if everybody trusts this root key (we all do: our web browsers ship with a list of trusted keys), then we can validate each public key in turn from the root right down to www.natice.noaa.gov But, how do we get our hands on that chain of keys? Simple, www.natice.noaa.gov sends them to us. Yep. All of the public keys in that whole chain. This is the only way to be sure that browsers can authenticate the trust relationship and be sure their encrypted traffic really is going to www.natice.noaa.gov.uk. So, what do you think happens if it turns out that NOAA screwed up and are either not serving up this chain, or are serving up the wrong chain? Yep, you guessed it: if your browser doesn't trust the key which signed www.natice.noaa.gov, then it craps out and asks you what you want to do. And that is exactly what is happening here (it looks to me like they aren't serving the chain at all, but I might be wrong; it's gone 1am here ...).
×
×
  • Create New...