This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

MTP/PTP blocking not allowing Apple devices to charge

I've found that this question has been asked before but I can't find a resolution.

We use MTP/PTP blocking on our network to prevent data transfer from a USB device to the PC. Since applying this block we have discovered it also prevents iPhones from charging via the USB port but other devices such as Android are still able to charge. Do you know if this is has been fixed, is likely to be fixed or whether there is a work around?

Thanks



This thread was automatically locked due to age.
Parents Reply Children
  • Hi Christian, I'd read that article and the community thread but wondered whether anyone had discovered a workaround since.

    Thanks for reply

  • Hello keiths,

    as you've read, not to charge is a decision the "other side" makes - thus it's not a question of allowing. In theory it should with a driver be possible to make a USB port appear as charging port but if you want to preserve its other functionality it's a chicken and egg problem. Even this could be overcome by simulating an unplug-plug sequence, this would be hardware-dependent though. Quite some effort to make it generally work and work reliably just to accommodate to a vendor's quirks. It'd probably cost Sophos less to give each affected user a power bank for free [:P]

    Christian 

  • Thanks again Christian, probably not worth us throwing too much effort at but food for thought.

  • This is unfortunate and I would say is a Sophos architecture issue. There are many other similar services where this works and still prevents data transfer...on the iPhone.

     

    -glen

  • I've not used it but I assume that wireless charging station would work :) 

    Do they enable data and power for charging or just charging?

    Regards,
    Jak

  • Hello glen,

    a Sophos architecture issue
    debatable - unless you question Device Control's overall design. It's deliberately "non-invasive" (except for the CD-Rom Filter Driver). As said, it seems to be a quirk of certain Apple/iOS devices.

    Christian

  • The "problem" is, when you write such software as device control, to gain coverage you have to write it in a generic way to cover all the devices, which means working as close to the OS and the available API calls.  Device Control has no knowledge of the particular device being Android, iOS a Sony Bluetooth headset and doing anything different.  If the device presents itself to Windows as mass storage or a CDROM or a Bluetooth or Net device, that's what the software will see.

    It's a bit like Web Protection/Control at the endpoint.  Sophos filters all traffic in an out of process proxy (swi_fc.exe) on Windows 8.1 and later, so all browser traffic is covered as all browser traffic is routed (WFP magic) through it over loopback.  It's just like any other web proxy really just that it's running locally listening on loopback.  The upside being, one solution fits all browsers, the downside is the limitations, i.e. you don't get to see the SSL traffic for example beyond the SSL handshake, so in effect all it sees is the domain the browser is connection to.  The solution also can't inject block/warning pages into SSL pages (as it does with HTTP) and therefore uses desktop messaging.  To do local SSL inspection out of the browser, you would have to crack open the connection, trust certificates etc which is seen by many as a security risk.  People like to know that the browser is establishing a straight pipe to the intended server.  If you wish to do full SSL inspection you have to use the XG or UTM appliance. 

    So to gain a higher level of browser integration, you would need to move further from the OS and closer to the browser, i.e. write a plugin for each browser.  As a result, rather than one generic proxy to maintain you require a plugin for every browser you want to support.  Of course as browsers update quite often these days and you need to test it.  

    I hope that adds some perspective regarding design decisions and both upfront and sustaining development costs to a feature.

    Regards,
    Jak