SROS2 leaks node information, regardless of rtps_protection_kind setup

[vmayoral]

Bug report

Connected to https://github.com/ros2/sros2/pull/171/files. After this patch one wold expect that node information isn't disclosed anymore but testing led to a different result. I'm not that experienced with sros2 at this point so I might be missing something? Ping to @mikaelarguedas and @ruffsl.

• Operating System:
  • OS X 10.14.3
  • Ubuntu 18.04
• Installation type:
  • from sources
• Version or commit hash:
  • dashing
  • eloquent
  • master (https://github.com/ros2/ros2/)
• DDS implementation:
  • FastRTPS
• Client library (if applicable):
  • rclpy

Steps to reproduce issue

Change defaults set rtps_protection_kind to encrypt and recreate keys.

https://asciinema.org/a/yuGkBlaPC33wqL4qABRlgxBkd

Expected behavior

Communications are encrypted for third parties (without credentials) in the network, node information isn't disclosed.

Actual behavior

Node information is still disclosed. Even after applying https://github.com/ros2/sros2/pull/171/files , rebuilding sros2 and regenerating the keys.

Additional information

• Connected to Set rtps_protection_kind to ENCRYPT by default #171

[wjwwood]

@mikaelarguedas and @ruffsl can you guys handle this one (and the related pull request)? If you need support from someone at Open Robotics to move this forward please ping me. I can assign someone randomly, but you guys are probably just as well suited to handle it. We can assist with CI and specific questions though.

[mikaelarguedas]

I'd expect the type / relevance of information leaked at discovery time to be heavily impacted by the ongoing change of doing discovery per context instead of per node. So it may be worth wait for that change to land to reassess the impact of this issue.

Can't say the bandwidth or support I'll have to work on this at that point in time.

Feedback from @vmayoral's investigation would also be valuable to move this forward.

[vmayoral]

Feedback from @vmayoral's investigation would also be valuable to move this forward.

Unfortunately, I didn't manage to allocate time to this just yet.

I'd expect the type / relevance of information leaked at discovery time to be heavily impacted by the ongoing change of doing discovery per context instead of per node. So it may be worth wait for that change to land to reassess the impact of this issue.

What's the timeline for this? Do we have any expectation by "when"?

[ruffsl]

Can you verify the governance.p7s files in the generated keystore reflect the changed default?

Node information is still disclosed.

Could you be more specific as to what "Node information" means in this scenario? Are we talking about node names, advertised topics, or GUIDs? Are we talking about observable information from say the ros2 node info CLI (aka ros2 graph API) or sniffing DDS packets via wire-shark?

If where talking about DDS packets, then there are already known issues in the secure DDS spec that leak info on access control policies granted during the handshake exchange between participants:

• https://doi.org/10.1109/EuroSPW.2019.00013
• https://arxiv.org/abs/1908.05310
• https://issues.omg.org/issues/DDSSEC12-13

---

Edit: Ok, digging through the rabbit whole links to other PR to issues to other issues, I found your asciinema session that demonstrates your aztarna tool. Looks to be exacting the message type info, so I guess this is agnostic to the leaking of policy documents.

https://asciinema.org/a/SSnSAMlOEoHfqhAuzC1R98STF

Is this repeatable for all rwm implementations that support Secure DDS, or just FastRTPS?