On Mon, Sep 26, 2016 at 5:54 PM, Greg Zaverucha <gregz at microsoft.com> wrote:
> 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 discovered the following yesterday on page 86 of the OIC Security Candidate Specification V1.1.0. This is about the properties of /oic/sec/cred: <quote> 13.2.1.4 Credential Type ... The CredType of '0' ("no security mode") is reserved for testing and debugging circumstances. Production deployment should not allow provisioning of credentials of type '0'. The SRM should introduce checking code that prevents its use in production deployments. </quote> For this to work we need some kind of state that indicates deployment status. That could be static read-only state fixed at compile time or dynamic read-write state that can be toggled at run-time. I'm a little leery of the latter, but then again if the security mechanisms work as advertised it should not be a problem to have a resource like /oic/sec/deployment, or maybe a property on /oic/d or some such that would allow controlled access. Furthermore, insofar as remote in-situ debugging of deployed installations is needed, I think that would be the way to go. A compile-time state var has its own problems - how do you know that the debug version and the prod version are exactly the same? If an installation goes haywire, I would not want to substitute a dev version of a component and debug that rather than the thing that actually went haywire. In any case, what goes for CredType should go for DTLS, no? Ditto for ACL checking. If the one can be disabled based on deployment status, why not all three? -Gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160927/3dabd95b/attachment.html>
