Secure UPnP not a dream anymore
On last friday evening, while thinking about security and UPnP, I realized adding security might not be as hard as one might think. If HTTPS is used instead of HTTP together with authentication, Your neighbor should no longer be able to play his p0rn on your Media Renderer once he/she breaks into your wireless network. Giving it more thought, I then realized it might not be so hard to add this support into GUPnP and I was correct.
After a few hours of reading libsoup docs and hacking around this weekend, I managed to add support for HTTPS in GUPnP. Adding authorization doesn't need any changes in GUPnP since we expose both SoupSession and SoupServer so applications can very easily add that there. Also no changes were required in GUPnP for the control points to be able to deal with devices/services using HTTPS instead of HTTP, thanks to libsoup. Here is a bug that you can follow if you are interested in this topic.
WARNING: Use of HTTPS and/or authentication is not described in any existing UPnP specification that I know of so if you decide to use this in your device/service implementations, don't expect interoperability with other devices/services.
After a few hours of reading libsoup docs and hacking around this weekend, I managed to add support for HTTPS in GUPnP. Adding authorization doesn't need any changes in GUPnP since we expose both SoupSession and SoupServer so applications can very easily add that there. Also no changes were required in GUPnP for the control points to be able to deal with devices/services using HTTPS instead of HTTP, thanks to libsoup. Here is a bug that you can follow if you are interested in this topic.
WARNING: Use of HTTPS and/or authentication is not described in any existing UPnP specification that I know of so if you decide to use this in your device/service implementations, don't expect interoperability with other devices/services.
Comments
Thats your 'prior art'
when some little fker claims thats as there own,
patent