4 ms·

Mozilla added SEED support to Gecko many years ago. Nothing has been done since then (on the Korean side) to implement support beyond that.

by gkanai 13y ago

viraptor 13y ago
But what exactly is needed? What is stopping someone from writing a FF extension that will capture all activex object tags and replace them with something doing the same operations in FF's chrome? Is the auth protocol completely unknown? Is the activex control obfuscated more than is possible to reverse-engineer?
- itsameta4 13y ago
  ActiveX is designed to hook directly into the Windows OS. That's what makes it so dangerous, but useful in this case, since you can add a cert to the trusted store. Firefox is designed to be secure and sand-boxed, especially its plugin architecture.
  - jlgreco 13y ago
    You don't need to replicate all of the functionality that activex has. You just need to emulate the behaviour from the banks point of view of whatever their particular activex does. Maybe the ActiveX rewrites a bunch of files with admin privileges "for security", and then negotiates some sort of key exchange... in that case just write JS that says it did the shit that requires admin privileges, then negotiates the key exchange). So the question is, if you are willing to ignore their activex and run your own custom JS instead, could these websites be made to work?
    - yongjik 13y ago
      A major online bookstore (www.aladdin.co.kr) actually tried that this year. They teamed up with another startup company (Paygate) and allowed users to use credit card with no plugins, on any browser. The few people who tried that loved it. And guess what happened? Major credit card companies pulled out one by one, because they "cannot ensure" that a page without Active-X is secure enough. Of course nobody's pulling any strings, no government officials are receiving unknown gifts, and nothing can be ever proved. So, there. You work for months to provide users with modern browsing experience, and those banking powers-that-be just pull the plug. The whole system is corrupt beyond imagination. Citation (sorry, in Korean): http://www.hankyung.com/news/app/newsview.php?aid=201309120399g http://www.hankyung.com/news/app/newsview.php?aid=2013091203... http://www.leejeonghwan.com/media/archives/002331.html http://www.leejeonghwan.com/media/archives/002331.html
      - viraptor 13y ago
        That's a solution from the provider's side though. I would have thought that it's much easier to handle it from the client side really... just pretend you did whatever verification was necessary and return the expected result. Noone should be able to shut it down, because it's on the client side, rather than the service provider, so the retailer shouldn't be blamed.
        yongjik 13y ago
        No no no, it doesn't work that way. These banking websites don't expose a well-defined API that you can emulate. Instead they force you to install a bunch of ActiveX plugins (usually with administrative privilege) and you have to just trust that they won't, say, read the whole content of your hard disk and stream it to a third-party site. A few years ago (when I was still in Korea), it was usually impossible to open two different bank's pages at the same time: I'd assume that's still the case now. As far as I know, the reason is that both banks will force you to install "anti-hacking" plugins, which hooks directly into your Windows Kernel and makes sure nobody else snoops on what you type. Yes, these webpages try to establish a direct connection between your keyboard and the website, completely bypassing every layer. Now imagine the fun when two such plugins try to run at the same time. And of course without these plugins you can't use the site. Hell, sometimes these sites spontaneously break just because you're accessing it from the US, because nobody had thought to test them from a client with ping time > 200ms. Now try emulating that in client. (I don't know if I should laugh or weep.) EDIT: Besides, if you seriously try to make a platform that can emulate these "security" plugins, sooner or later you will be arrested for making tools to circumvent security measures, and people will be reminded that they should never install anything from "suspicious" sites. (But of course install everything from banking sites.) As a bonus, some news media will claim you were paid by North Korea, and many will believe that.
        viraptor 13y ago
        Thanks, that's the part I haven't heard of before - good explanation of the issue. So if someone wanted to reimplement the client, they would have to reimplement a different one for every single site. Depending on the difficulty of working around the issue though, I wonder if it's a business opportunity: offer a web proxy which is transparent for all purposes, apart from the activex part - it would replace them with something that's either pretending to run the verification itself, or provides some replacement script. If you ran the company outside of Korea that took subscription money to bypass a number of the most popular services' auth, it would be hard to shut down. (but it would become a cat and mouse game of updating the algorithm until one side got bored...) Unfortunately this would have to be written in some interesting way that guarantees the passwords / tokens / sessions are never captured by this system, otherwise noone would use it. But that's a technical problem - should be doable in some way.
  - eevee 13y ago
    This is completely false. Firefox extensions have access to everything the browser does and can contain arbitrary native code. There's a reason Mozilla's addon repository has a review process. What makes addons better than ActiveX controls is that they're understood to extend the browser for the user's benefit, not merely make a crappy website work. Fewer people would buy that a bank website needs to install a Firefox extension before you can log in.
- flomo 13y ago
  Such a thing was created many years ago: http://www.adamlock.com/mozilla/plugin.htm http://www.adamlock.com/mozilla/plugin.htm One could guess that it was never included by default because Mozilla did not want to encourage the use of ActiveX controls.
  - viraptor 13y ago
    Oh $BABY_DEITY no! That's not what I was suggesting! Activex in FF? Scared the hell out of me... What I meant is either reverse-engineering the algorithm and reimplementing it in FF chrome in clean JS like jlgreco mentioned below, or including just the kernel of the important logic, the way ndiswrapper uses windows driver for communicating to the network cards without actually implementing whole windows kernel.
    - flomo 13y ago
      The security implications of requiring users to install Firefox add-ons are not any better than requiring them to install ActiveX plug-ins. (Other than pure vendor politics.) You still have the artificial requirement of some Win32 blob, which is the real issue.
      - jessaustin 13y ago
        It seems that being forced to use IE on Windows is more limiting than having to install an extension for whichever browser you choose on whichever OS you choose. If the security protocol were published or reverse-engineered, a clean re-implementation outside of Win32 could take place.
        flomo 13y ago
        It's still an undesirable result even if it compiled a portable Linux .so just for your CPU architecture. The requirements are so flawed the system should be junked, not hacked around. Also, I'm not sure why my post was dinged, but Firefox extensions/addons/plugins can call into native code and can do pretty much anything an ActiveX control can do. There is no "sandbox" as someone else implied.

Mozilla added SEED support to Gecko many years ago. Nothing has been done since then (on the Korean side) to implement support beyond that.

by gkanai 13y ago

Mozilla added SEED support to Gecko many years ago. Nothing has been done since then (on the Korean side) to implement support beyond that.

viraptor 13y ago

But what exactly is needed? What is stopping someone from writing a FF extension that will capture all activex object tags and replace them with something doing the same operations in FF's chrome? Is the auth protocol completely unknown? Is the activex control obfuscated more than is possible to reverse-engineer?

itsameta4 13y ago
ActiveX is designed to hook directly into the Windows OS. That's what makes it so dangerous, but useful in this case, since you can add a cert to the trusted store. Firefox is designed to be secure and sand-boxed, especially its plugin architecture.
- jlgreco 13y ago
  You don't need to replicate all of the functionality that activex has. You just need to emulate the behaviour from the banks point of view of whatever their particular activex does. Maybe the ActiveX rewrites a bunch of files with admin privileges "for security", and then negotiates some sort of key exchange... in that case just write JS that says it did the shit that requires admin privileges, then negotiates the key exchange). So the question is, if you are willing to ignore their activex and run your own custom JS instead, could these websites be made to work?
  - yongjik 13y ago
    A major online bookstore (www.aladdin.co.kr) actually tried that this year. They teamed up with another startup company (Paygate) and allowed users to use credit card with no plugins, on any browser. The few people who tried that loved it. And guess what happened? Major credit card companies pulled out one by one, because they "cannot ensure" that a page without Active-X is secure enough. Of course nobody's pulling any strings, no government officials are receiving unknown gifts, and nothing can be ever proved. So, there. You work for months to provide users with modern browsing experience, and those banking powers-that-be just pull the plug. The whole system is corrupt beyond imagination. Citation (sorry, in Korean): http://www.hankyung.com/news/app/newsview.php?aid=201309120399g http://www.hankyung.com/news/app/newsview.php?aid=2013091203... http://www.leejeonghwan.com/media/archives/002331.html http://www.leejeonghwan.com/media/archives/002331.html
    - viraptor 13y ago
      That's a solution from the provider's side though. I would have thought that it's much easier to handle it from the client side really... just pretend you did whatever verification was necessary and return the expected result. Noone should be able to shut it down, because it's on the client side, rather than the service provider, so the retailer shouldn't be blamed.
      - yongjik 13y ago
        No no no, it doesn't work that way. These banking websites don't expose a well-defined API that you can emulate. Instead they force you to install a bunch of ActiveX plugins (usually with administrative privilege) and you have to just trust that they won't, say, read the whole content of your hard disk and stream it to a third-party site. A few years ago (when I was still in Korea), it was usually impossible to open two different bank's pages at the same time: I'd assume that's still the case now. As far as I know, the reason is that both banks will force you to install "anti-hacking" plugins, which hooks directly into your Windows Kernel and makes sure nobody else snoops on what you type. Yes, these webpages try to establish a direct connection between your keyboard and the website, completely bypassing every layer. Now imagine the fun when two such plugins try to run at the same time. And of course without these plugins you can't use the site. Hell, sometimes these sites spontaneously break just because you're accessing it from the US, because nobody had thought to test them from a client with ping time > 200ms. Now try emulating that in client. (I don't know if I should laugh or weep.) EDIT: Besides, if you seriously try to make a platform that can emulate these "security" plugins, sooner or later you will be arrested for making tools to circumvent security measures, and people will be reminded that they should never install anything from "suspicious" sites. (But of course install everything from banking sites.) As a bonus, some news media will claim you were paid by North Korea, and many will believe that.
        viraptor 13y ago
        Thanks, that's the part I haven't heard of before - good explanation of the issue. So if someone wanted to reimplement the client, they would have to reimplement a different one for every single site. Depending on the difficulty of working around the issue though, I wonder if it's a business opportunity: offer a web proxy which is transparent for all purposes, apart from the activex part - it would replace them with something that's either pretending to run the verification itself, or provides some replacement script. If you ran the company outside of Korea that took subscription money to bypass a number of the most popular services' auth, it would be hard to shut down. (but it would become a cat and mouse game of updating the algorithm until one side got bored...) Unfortunately this would have to be written in some interesting way that guarantees the passwords / tokens / sessions are never captured by this system, otherwise noone would use it. But that's a technical problem - should be doable in some way.
- eevee 13y ago
  This is completely false. Firefox extensions have access to everything the browser does and can contain arbitrary native code. There's a reason Mozilla's addon repository has a review process. What makes addons better than ActiveX controls is that they're understood to extend the browser for the user's benefit, not merely make a crappy website work. Fewer people would buy that a bank website needs to install a Firefox extension before you can log in.
flomo 13y ago
Such a thing was created many years ago: http://www.adamlock.com/mozilla/plugin.htm http://www.adamlock.com/mozilla/plugin.htm One could guess that it was never included by default because Mozilla did not want to encourage the use of ActiveX controls.
- viraptor 13y ago
  Oh $BABY_DEITY no! That's not what I was suggesting! Activex in FF? Scared the hell out of me... What I meant is either reverse-engineering the algorithm and reimplementing it in FF chrome in clean JS like jlgreco mentioned below, or including just the kernel of the important logic, the way ndiswrapper uses windows driver for communicating to the network cards without actually implementing whole windows kernel.
  - flomo 13y ago
    The security implications of requiring users to install Firefox add-ons are not any better than requiring them to install ActiveX plug-ins. (Other than pure vendor politics.) You still have the artificial requirement of some Win32 blob, which is the real issue.
    - jessaustin 13y ago
      It seems that being forced to use IE on Windows is more limiting than having to install an extension for whichever browser you choose on whichever OS you choose. If the security protocol were published or reverse-engineered, a clean re-implementation outside of Win32 could take place.
      - flomo 13y ago
        It's still an undesirable result even if it compiled a portable Linux .so just for your CPU architecture. The requirements are so flawed the system should be junked, not hacked around. Also, I'm not sure why my post was dinged, but Firefox extensions/addons/plugins can call into native code and can do pretty much anything an ActiveX control can do. There is no "sandbox" as someone else implied.