3 ms·
This looks like it could be pretty useful. The main argument against crypto in the browser is that if you send crypto js over a non encrypted channel it's vulne
by zrail 14y ago
This looks like it could be pretty useful. The main argument against crypto in the browser is that if you send crypto js over a non encrypted channel it's vulnerable to MITM, and if you're going over HTTPS you might as well just send it plaintext. If the browsers themselves implemented secure crypto it could be a boon to certain types of applications, for example S/MIME in webmail.
- daeken 14y agoI don't see this adequately defending against MITMs or XSS. You can still hook all the crypto primitives, inject new keys, or pull out existing keys from the same origin. This scares me; a lot of people are going to assume this is secure against attacks that it simply isn't there to defend against.
- jlgreco 14y agoI could see this being useful/safe iff the browser refuses to allow it to be used unless everything is already using HTTPS.
- tptacek 14y agoIt could be useful if it was nailed to HTTPS. But it wouldn't be safe; it leaves too much to content-controlled Javascript. When you've got HTTPS working, the threat model left to solve is, "can I trust the server not to fuck me with a subtly broken cryptosystem". This API doesn't address that problem; it admits to more broken cryptosystems than sound ones.
- jlgreco 14y agoFair point. I would say locking it down to HTTPS is required, but not sufficient.
- morroccomole 14y agoIndeed, browser also implement things like CSP - and we need browser to also support additional security measures that enhance the API