Re: Proposed Statement on "HTTPS everywhere for the IETF"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Small correction, July 2016, not July 2015, is the new TLS v1.1/1.2 compliant deadline for PCI v3.1. From the PCI/DSS reference below:

Removed SSL as an example of a secure
technology. Added note that SSL and early
TLS are no longer considered to be strong
cryptography and cannot be used as a security
control after June 30, 2016. Additional
guidance provided in Guidance column. Also
impacts Requirements 2.3 and 4.1.


--
HLS


On 6/7/2015 1:57 AM, Hector Santos wrote:
On 6/6/2015 11:08 PM, Xiaoyin Liu wrote:
Date: Sat, 6 Jun 2015 11:25:26 -0400
From: hsantos@xxxxxxxx
To: nd@xxxxxxxxxxxx; jari.arkko@xxxxxxxxx; ietf@xxxxxxxx
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.







[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]