TLS everywhere has a major flaw and needs refining to the page level.

[Kevin Chadwick]

The cookies etc. should be SSL only. Particular pages enforced, sure.

Enforcing TLS with HSTS sitewide means that users with failed
bios/laptop batteries have to know to reset their clock or get used to
bypassing SSL warnings or use out of date browsers to access sites.
A fairly common problem, not good. Think real world, please. This hurts
the most vulnerable.

Another solution may be to remove the cert is not valid YET
restriction but that is a can of worms.

Thankyou

[R0b0t1]

I'm not sure this can be worked around. A setup where time is not
pulled from the network is abnormal now, and most people who have such
a system soon realize what the issue is. Some RTCs choose very poor
oscillators or resonators and will lose seconds a week in some cases.
Disregarding the intent of the certificates does not seem to be a good
idea.

The certificate warnings are a good reminder to update my clock
(seriously). Perhaps offer this information on the error page?

Cheers,
R0b0t1

[Frederik Braun]

On 15.02.2018 13:34, Kevin Chadwick wrote:
> Enforcing TLS with HSTS sitewide means that users with failed
> bios/laptop batteries have to know to reset their clock or get used to
> bypassing SSL warnings or use out of date browsers to access sites.

Firefox and many other browsers have their own way to determine and
remedy the impact of local clock skew.

[Kevin Chadwick]

On Thu, 15 Feb 2018 15:55:27 -0600

> I'm not sure this can be worked around. A setup where time is not
> pulled from the network is abnormal now, and most people who have such
> a system soon realize what the issue is.

OpenNTP has a constraint system but considering NTP is a latent,
insecure, untrusted server protocol, synchronising the clock in one go
is not the recommended default. Instead it used https constraints and 8
UDP server samples before skewing slightly.

I don't know if the windows version is a less latent but secured
protocol.

>
> The certificate warnings are a good reminder to update my clock
> (seriously). Perhaps offer this information on the error page?

Yeah, I don't think the messages are as clear these days as to what the
issue is. The idea being to reduce click through, perhaps they could
manually update their clock in that case but not understand the
messages otherwise or been taught to stop when strange things happen
or not to click on error boxes.

On that subject I think the chromium reported plan to label sites as
insecure should perhaps be revised to page insecured or something more
accurate?

Additionally it infers sites labelled secure or not labelled insecure
are secure when they may have terrible security but utilise TLS.

[Hanno Böck]

On Fri, 16 Feb 2018 11:34:03 +0000
Kevin Chadwick <m8il...@gmail.com> wrote:

> OpenNTP has a constraint system but considering NTP is a latent,
> insecure, untrusted server protocol, synchronising the clock in one go
> is not the recommended default.

This is a nice feature which unfortunately doesn't work on the majority
of systems.

OpenNTPD has decided to make this feature dependent on LibreSSL, thus
it's disabled on all systems that default to OpenSSL.


--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

[Peter Bowen]

On Fri, Feb 16, 2018 at 3:34 AM, Kevin Chadwick via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> On that subject I think the chromium reported plan to label sites as
> insecure should perhaps be revised to page insecured or something more
> accurate?

Given this group focused on Mozilla, it is likely out of scope to
discuss Chromium design. I do suggest you look at
https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html
It seems reasonably clear the marking is per top level page load.
This is very similar to the UI for Firefox which shows the lock (and
EV info) per top level page load.

[Kevin Chadwick]

On Fri, 16 Feb 2018 08:15:10 -0800

> Given this group focused on Mozilla, it is likely out of scope to
> discuss Chromium design. I do suggest you look at
> https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html
> It seems reasonably clear the marking is per top level page load.
> This is very similar to the UI for Firefox which shows the lock (and
> EV info) per top level page load.

"helped users understand that HTTP sites are not secure by gradually
marking a larger subset of HTTP pages as “not secure”.

not secure example.com
webpage not secured example.com - may be better?

To me it seems to be saying that the domain is "not secure" which is
incorrect. The page is "not secured" and the domain may be more secure
than another labelled secure (not not secure).

If the goal is to move everyone to https in fear of their sites
looking insecure rather than inform the user then I understand.