On 13/12/2017 18:38, Nick Lamb wrote:
On Wed, 13 Dec 2017 12:29:40 +0100
Jakob Bohm via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
What is *programmatically* enforced is too little for human safety.
believing that computers can replace human judgement is a big mistake.
Most of the world knows this.
That's a massive and probably insurmountable problem then since the
design of HTTPS in particular and the way web browsers are normally
used is _only_ compatible with programmatic enforcement.
Allow me to illustrate:
Suppose you visit your bank's web site. There is a lovely "Green
Bar" EV certificate, and you, as a vocal enthusiast for the value of
Extended Validation, examine this certificate in considerable detail,
verifying that the business identified by the certificate is indeed
your bank. You are doubtless proud that this capability was available
to you.
You fill in your username and password and press "Submit". What happens?
Maybe your web browser finds that the connection it had before to
the bank's web site has gone, maybe it timed out, or there was a
transient network problem or a million other things. But no worry, you
don't run a web browser in order to be bothered with technical minutiae
- the browser will just make a new connection. This sort of thing
happens all the time without any trouble.
This new connection involves a fresh TLS setup, the server and browser
must begin again, the server will present its certificate to establish
identity. The web browser examines this certificate programmatically to
decide that it's OK, and if it is, the HTTPS form POST operation for
the log in form is completed by sending your username and password over
the new TLS connection.
You did NOT get to examine this certificate. Maybe it's the same one as
before, maybe it's slightly different, maybe completely different, the
hardware (let alone software) answering needn't be the same as last
time and the certificate needn't have any EV data in it. Your web
browser was happy with it, so that's where your bank username and
password were sent.
I would be sorely disappointed and consider it a security bug if a
browser shows one validated certificate then submits a posted form to a
connection with a substantially different certificate. There may be a
(very short) list of permitted variations for cases such as server farms
with separate private keys per server. But any real change of
certificate mid-transaction should be blocked the same way cross-domain
posting is usually blocked.
Checking for certificate equality is an easy programmatic task, deciding
if a real world entity is trustworthy is not.
Even IF you decide now, with the new connection, that you don't trust
this certificate, it's too late. Your credentials were already
delivered to whoever had that certificate.
Software makes these trust decisions constantly, they take only the
blink of an eye, and require no human attention, so we can safely build
a world that requires millions of them. The moment you demand human
attention, you not only introduce lots of failure modes, you also use
up a very limited resource.
Perhaps you feel that when browsing the web you make a conscious
decision about trust for each site you visit. Maybe, if you are
extraordinarily cautious, you make the decision for individual web
pages. Alas, to be of any use the decisions must be taken for every
single HTTP operation, and most pages will use dozens (some hundreds)
of such operations.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
