On 6/6/2015 11:08 PM, Xiaoyin Liu wrote:
Date: Sat, 6 Jun 2015 11:25:26 -0400
From: hsantos(_at_)isdg(_dot_)net
To: nd(_at_)syndicat(_dot_)com; jari(_dot_)arkko(_at_)piuha(_dot_)net;
ietf(_at_)ietf(_dot_)org
Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"
It could not update because the
HTTPS URL was failing due the browser seeing an erroneous "Invalid
Certificate" display with no option to accept, temporary or otherwise.
You have to download via another browser that isn't so strict, yet.
Why does the IETF use invalid certificates in the first place? If this
is due to a wrong system clock, then the user probably cannot visit
Google, Facebook, GitHub, etc. as well, and at least Firefox and
Chrome advise users to fix the clock in such situation.
Xiaoyin
Most likely because the HTTPS server is now fully PCI/DSS v3.1
compliant which only supports TLS v1.1 or TLS v1.2. I believe PCI/DSS
v3.1 takes effects July 2015 so you are going to see a lot of this.
PCI/DSS (Payment Card Industry/Data Security Standard) v3.0 to
v3.1 changes
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1_Summary_of_Changes.pdf
If the HTTPS server only enables TLS v1.1/v1.2 as required by PCI/DSS
v3.1, this can fail older/current HTTPS clients which does not not
support TLS v1.1/v1.2. It could/may display an erroneous "invalid
certificate" display or even show an unknown site page because the
non-compliant HTTPS socket request was broken.
For product update scenarios, if the site forces HTTPS transactions
only, then its not possible for it to update itself via HTTPS.
This is more about implementations and how they need to learn how up
"update" users using any current secured frontend. For PCI/DSS, I
predict we will see many of these issues that in short will force
users to update their client software on their machines, whether they
like it or not.
--
HLS