Brian Smith (:briansmith, :bsmith, use NEEDINFO?) Reporter
	Description • 13 years ago

+++ This bug was initially created as a clone of Bug #713312 +++

Some sites, in particular banking and e-commerce sites in China, are using ActiveX controls and/or NPAPI plugins to improve security. One of the security features is an ActiveX/NPAPI plugin that seems to encrypt form fields before submitting them.

I actually do not know a lot about this. Using dumpbin /imports, I saw that the AliPay plugin was definitely doing some crypto stuff, but I have no idea what. I remember Wei or Feng Jiao telling me that AliPay and/or Chinese banks typically use such encryption, at least for password fields.

I am pretty dubious about the security benefits of this feature. I would like to understand exactly what the websites' security requirements are. Hopefully, we would be able to solve their problems in a different way.

Note that these sites (at least the Chinese ones) are doing this *in addition* to SSL, not instead of it. So, obviously they feel like SSL is not good enough.

I have heard that similar things happen in Korea, and that Korea may be doing this kind of thing instead of using SSL. That sounds like a much trickier problem.

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 1 • 13 years ago

Does DOMCrypt (perhaps with a JS library on top) address this use case?

https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest

	Brian Smith (:briansmith, :bsmith, use NEEDINFO?) Reporter
	Comment 2 • 13 years ago

(In reply to David Baron [:dbaron] from comment #1)
> Does DOMCrypt (perhaps with a JS library on top) address this use case?
> 
> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest

Maybe. But, scripts don't have access to the contents of password fields, typically, so something would need to change on that front, at least.

	Brian Smith (:briansmith, :bsmith, use NEEDINFO?) Reporter
	Comment 3 • 13 years ago

(In reply to Brian Smith (:bsmith) from comment #2)
> (In reply to David Baron [:dbaron] from comment #1)
> > Does DOMCrypt (perhaps with a JS library on top) address this use case?
> > 
> > https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
> 
> Maybe. But, scripts don't have access to the contents of password fields,
> typically, so something would need to change on that front, at least.

As dbaron pointed out in another thread, JS *DOES* of course have access to the contents of password fields. So, it seems likely that we could enable this functionality with a DOMCrypt-based library.

Perhaps, then, it makes sense to prioritize the implementation of the specific DOMCrypt APIs that would be needed for this functionality.

Regardless, the first step is finding out how and why these websites are encrypting things with their plugins currently.

	David Dahl :ddahl
	Comment 4 • 13 years ago

(In reply to Brian Smith (:bsmith) from comment #3)
> Perhaps, then, it makes sense to prioritize the implementation of the
> specific DOMCrypt APIs that would be needed for this functionality.
> 
> Regardless, the first step is finding out how and why these websites are
> encrypting things with their plugins currently.

So the idea is that the bank provides a public key, a script in the content then uses it to encrypt some (signed) transaction data which in turn is XHR posted to the bank's server. This data is then perhaps decrypted later on a more 'secure' host?

	Brian Smith (:briansmith, :bsmith, use NEEDINFO?) Reporter
	Comment 5 • 13 years ago

David, I have no idea what these plugins are doing w.r.t. the crypto yet. We should work with our Korean and Chinese friends to figure that out.

	Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]
	Comment 6 • 13 years ago

secteam triage, no action

	Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]
	Comment 7 • 13 years ago

still waiting