[whatwg] meta="encrypt" tag is needed
and-py at doxdesk.com
Thu May 6 12:52:04 PDT 2010
On 05/06/2010 02:44 PM, juuso_html5 at tele3d.net wrote:
> browser submits a (session specific) 256bit elliptic curve public key
> to the server inside every URI-request AND if the target page has
> meta-encrypt tag, the server uses the browser's elliptic curve key
The server has to read and correctly parse each HTML page to decide
whether to encrypt it? (And how does the browser know that the page is
encrypted, vs. a legacy server that doesn't encrypt?)
This proposal is tackling the problem of encryption at entirely the
wrong level: it's nothing to do with HTML, it's to do with the
connection between the browser and the server. It is very likely that
sites would want to encrypt transfers of other files than HTML pages.
This is something that should be tackled at the HTTP level, not in HTML5.
And lo, there is already a quite suitable mechanism for deploying
encryption between the server and browser: HTTPS.
Whilst it is true that HTTPS has more organisational overhead in the
form of CAs, and more server overhead in the form of making virtual
hosting difficult, there are technical approaches to improve this
situation (DNSSEC-based certs, SNI), and, notably, this overhead is
Otherwise HTTPS would be vulnerable to active man-in-the-middle attacks,
just like your proposed protocol is. Without attestation that the site
receiving the `pubkey` token is who it says it is, the encryption
between the two is worthless. It would only protect against passive MitM
attacks, but in reality if you are in a position to MitM passively you
are very likely to be able to throw in an active attack just as easily.
> please don't say you instead you can use https / JS or some other thing
> that JUST DOESN'T WORK in real life.
HTTPS works fine. JS client-side-password-hashing approaches suffer from
the same problem as your proposal: they can only ever protect against
mailto:and at doxdesk.com
More information about the whatwg