On item F (debugging), I don?t think we should add a way to disable encryption for debugging, because there is a risk that encryption gets disabled in production. On debugging encrypted communication
- If you control both endpoints of the connection, it?s usually possible to inspect the data just before encryption or just after decryption - In my experience, the need to debug with packet captures is rare - If you really need to debug encrypted network traffic, the preferred way is to use an interception proxy tool that is trusted by one endpoint. Fiddler one such tool web developers use to debug HTTPS traffic (http://www.telerik.com/fiddler/security-testing). I?m in favor of making SECURED=1 the default and removing the SECURED=0 behavior altogether. Greg From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Gregg Reynolds Sent: Thursday, September 22, 2016 3:48 PM To: iotivity-dev at lists.iotivity.org Subject: [dev] security A) the concensus seems to be that SECURED=1 should be the default. question: why should SECURED=0 even be an option? why not remove this option altogether? B) creating a resource without OC_SECURED apparently causes problems if SECURED=1. this strikes me as a bug that should be fixed, not something to be worked around. how hard can it be? C) this has been around for approximately forever: https://jira.iotivity.org/plugins/servlet/mobile#issue/IOT-693<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fjira.iotivity.org%2fplugins%2fservlet%2fmobile%23issue%2fIOT-693&data=02%7c01%7cgregz%40microsoft.com%7c260a3c4e17e247f9902708d3e33a82e4%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636101812856194381&sdata=AVgN7rh%2bCxG%2fniPqWGSeIQ39tnVlFx4xEp2rMdgnjNM%3d> but the solution seems very simple to me: initResources should always be called as part of stack initialization. C2) here's another one: https://jira.iotivity.org/plugins/servlet/mobile#issue/IOT-920<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fjira.iotivity.org%2fplugins%2fservlet%2fmobile%23issue%2fIOT-920&data=02%7c01%7cgregz%40microsoft.com%7c260a3c4e17e247f9902708d3e33a82e4%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636101812856194381&sdata=FutROV2iW4Ilp19z1fIUPzRUwezSwLJpg3yPDRtZBTA%3d> the recommendation is to bypass security, on grounds that it is unintuitive to provide a wildcard ACL for "unsecured" resources. fwiw I strongly disagree - there should be no such thing as an unsecured resource, and providing an ACL for every resource should be considered standard pactice. There's a big difference between "unsecured" and "freely accessible. More below. D) security is a house of many mansions. encryption, authentication, and authorization are just three. IMHO an audit trail is another: we all know that any system can be compromised, so a complete security solution must support after-the-fact forensics. if we just *disable* security (e.g. ACLs) for some resource, what does that do to our audit trail? E) it follows that it should not be possible to create an unsecured resource. there should be no OC_SECURED flag for resource creation. auth/auth should be entirely controlled by the config file with ACLs etc. if you want a resource to be accessible to anybody, the way to do that is to allow it, not to disable security. this is not an unendurable burden for developers; it's just a bit of configuration. F) for debugging we may need to disable encryption. we should be able to do that without affecting any other security mechanisms. as far as I can tell, encryption, authentication and authorization are orthogonal. G) Any or all of the above may be wrong. ;) gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160926/cc196cf0/attachment.html>
