- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 19 Jan 2015 11:15:55 +0100
- To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
- Cc: Mark Nottingham <mnot@mnot.net>, Henri Sivonen <hsivonen@hsivonen.fi>, Chris Palmer <palmer@google.com>, Noah Mendelsohn <nrm@arcanedomain.com>, "Michael[tm] Smith" <mike@w3.org>, Tim Berners-Lee <timbl@w3.org>, Public TAG List <www-tag@w3.org>
On Mon, Jan 19, 2015 at 10:56 AM, Henry S. Thompson <ht@inf.ed.ac.uk> wrote: > I'll bite -- what _should_ the UX say? That is, what _is_ the risk > (and what is the alternative that MIT should be using)? You're giving an entity that is not vetted by browsers (see https://wiki.mozilla.org/CA for what Mozilla requires) full control over signing certificates for domain names. So e.g. MIT employees with access can create certificates for your bank and spoof you while you're on a network under their control (or a network of their friends). (An extra problem here is that MIT hosts this information on a page that itself can easily be man-in-the-middled putting those who trust MIT in danger of downloading the wrong certificate. That the certificate itself is hosted over TLS does not much as the link to it can easily be adjusted to point elsewhere.) > The alternative an entity not a million miles away from my desk > uses is to just self-sign and expect us to click through the resulting > warnings. . . That has the risk of getting man-in-the-middled for that particular service and might lead to users clicking through such warnings when they absolutely shouldn't, but at least you're not giving an unvetted entity control. -- https://annevankesteren.nl/
Received on Monday, 19 January 2015 10:16:19 UTC