Might be a wrong assumption but, if you place those values into an HTML element, it is visible by simply doing a view source. I am jumping in the middle of the conversation here but, this strikes me as opening another problem.
Schalk -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of And Clover Sent: Thursday, May 06, 2010 9:52 PM To: [email protected] Subject: Re: [whatwg] meta="encrypt" tag is needed On 05/06/2010 02:44 PM, [email protected] 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 *necessary*. 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 passive attacks. -- And Clover mailto:[email protected] http://www.doxdesk.com/
