Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Danilo Bargen
    @dbrgn
    saltyrtc-client-java 0.11.2 is released, with support for 'disconnected' messages: https://github.com/saltyrtc/saltyrtc-client-java/
    Lennart Grahl
    @lgrahl
    :+1:
    Danilo Bargen
    @dbrgn
    website is updated with rust implementations, relayed data task and some styling fixes: https://saltyrtc.org/
    Danilo Bargen
    @dbrgn
    and saltyrtc-client-rs 0.5.0-beta.1 is published :sparkles: https://crates.io/crates/saltyrtc-client
    Lennart Grahl
    @lgrahl
    At least one of us makes progress :smirk_cat:
    Danilo Bargen
    @dbrgn
    https://github.com/saltyrtc/chunked-dc-swift saltyrtc chunking implemented in swift :)
    writing it went pretty swift (scnr) to be honest, especially if you know rust.
    Lennart Grahl
    @lgrahl
    :+1:
    Lennart Grahl
    @lgrahl
    (But I'm not a fan of languages that are tied to products.)
    Danilo Bargen
    @dbrgn
    I wrote everything on Linux, so it's not all too bad.
    But I prefer Rust by a wide margin, much more safety features.
    Danilo Bargen
    @dbrgn
    Java WebRTC task 0.14 is out, with a new WebRTC build (M71): https://bintray.com/saltyrtc/maven/saltyrtc-task-webrtc/0.14.0
    Lennart Grahl
    @lgrahl
    :tada:
    Danilo Bargen
    @dbrgn
    Java client 0.12 is out, with some nice new features and optimizations: https://github.com/saltyrtc/saltyrtc-client-java/blob/master/CHANGELOG.md
    Danilo Bargen
    @dbrgn
    Java WebRTC task 0.16 is out, with a new WebRTC build (M72): https://bintray.com/saltyrtc/maven/saltyrtc-task-webrtc/0.16.0
    Lennart Grahl
    @lgrahl
    Meanwhile, the SaltyRTC server has been bumped to 3.0 with dozens of improvements to the task queue and client handling. There were a few bugs that impact the client's experience, so upgrading is highly recommended.
    https://github.com/saltyrtc/saltyrtc-server-python/releases
    Lennart Grahl
    @lgrahl
    The Demo finally gets some love: saltyrtc/saltyrtc-demo#6
    Most memorable new features: Sending arbitrary amounts of binary data and a violently flickering progress bar showing the buffer fill status. :smirk_cat:
    umbri
    @umbri
    Hi ALL, thank you for sharing saltyrtc
    umbri
    @umbri
    Currently I am working on SaltyRTC-Swift-Client, and I have some remarks about SaltyRTC Signaling Protocol, implementing it, I found that code 3003 is not used anywhere in the code, but is used only in Tasks, as I understand SaltyRTC Signaling Protocol can work without ex: WebRTC Task Protocol or ORTC Task Protocol and I am supposing that this extensions are supersets of Signaling Protocol, I think that this code 3003 should not be defined in Main Signaling Protocol
    umbri
    @umbri
    I think that server-auth used in Responder and in Initiator should be 2 different types of messages, if you take a look at this and this you can see here 2 Classes InitiatorServerAuth and ResponderServerAuth (same with auth).
    Lennart Grahl
    @lgrahl
    o/
    Having 3003 in the main protocol is fine from my perspective since both the WebRTC and the ORTC task use it.
    Lennart Grahl
    @lgrahl
    Furthermore, since 3003 is being reflected to the server (which has no concept of tasks) on handover it makes sense to keep it in the main protocol.
    Lennart Grahl
    @lgrahl
    The server allows to gather statistics on why a client has closed a connection in which case 3003 plays a special role.
    Lennart Grahl
    @lgrahl

    I think that server-auth used in Responder and in Initiator should be 2 different types of messages [...]

    You mean in the protocol? What is the rationale? Also, be aware that the specification is mostly done at this point and clients are being used in production. The only breaking change we currently plan on doing is to remove send-error (but that would be nowhere near as breaking as a change to server-auth).

    umbri
    @umbri
    @lgrahl I understand that v1 is already used in production, all current remarks are for future protocol upgrades (if you are interested). I take in consideration security and simplicity of implementation (talking about client side).
    umbri
    @umbri
    1 - About security, as is written here Moreover, it is able to protect the clients' signaling data even in case the underlying TLS encryption of the WebSocket protocol has been completely broken., I hope you mean that somehow TLS is configured wrong or there are some 0 days of serving software (like: nginx) or maybe hardware, this make sense only in this case, otherwise if somehow third party can decrypt TLS traffic (that in fact is using ~ same encryption that is used in NaCl, if properly configured) this make no sense it only add overhead.
    umbri
    @umbri
    2 - About security, If third party can intercept traffic (MiTM), then without padding, third party can understand what message is sent. I understand that even third party can understand what message is sent, this will not allow him to decrypt the client-2-client traffic, but from the written above, it makes no sense to hide the message type, that only makes it more difficult cu implement de protocol.
    umbri
    @umbri

    I think that server-auth used in Responder and in Initiator should be 2 different types of messages [...]

    You mean in the protocol? What is the rationale? Also, be aware that the specification is mostly done at this point and clients are being used in production. The only breaking change we currently plan on doing is to remove send-error (but that would be nowhere near as breaking as a change to server-auth).

    Looking in implementation of available clients on github it seems like protocol was written in some non strict type language and then implemented in Java and added hacks like this https://github.com/saltyrtc/saltyrtc-client-java/blob/master/src/main/java/org/saltyrtc/client/helpers/MessageReader.java#L82-L87 that from my point of view it makes no sense.

    Lennart Grahl
    @lgrahl

    1 - About security, as is written here Moreover, it is able to protect the clients' signaling data even in case the underlying TLS encryption of the WebSocket protocol has been completely broken., I hope you mean that somehow TLS is configured wrong or there are some 0 days of serving software (like: nginx) or maybe hardware, this make sense only in this case, otherwise if somehow third party can decrypt TLS traffic (that in fact is using ~ same encryption that is used in NaCl, if properly configured) this make no sense it only add overhead.

    This was written at a time shortly after heartbleed. The fact that TLS may use NaCl is not a viable argument since heartbleed, and many other TLS bugs, were a protocol or implementation problem. The additional overhead is acceptable for a signalling protocol. This was never meant for high-performant data transmission.

    The additional implementation overhead is also very low since the crypto needs to be there for authentication purposes anyway.
    umbri
    @umbri

    1 - About security, as is written here Moreover, it is able to protect the clients' signaling data even in case the underlying TLS encryption of the WebSocket protocol has been completely broken., I hope you mean that somehow TLS is configured wrong or there are some 0 days of serving software (like: nginx) or maybe hardware, this make sense only in this case, otherwise if somehow third party can decrypt TLS traffic (that in fact is using ~ same encryption that is used in NaCl, if properly configured) this make no sense it only add overhead.

    This was written at a time shortly after heartbleed. The fact that TLS may use NaCl is not a viable argument since heartbleed, and many other TLS bugs, were a protocol or implementation problem. The additional overhead is acceptable for a signalling protocol. This was never meant for high-performant data transmission.

    fully agree with this

    Lennart Grahl
    @lgrahl

    2 - About security, If third party can intercept traffic (MiTM), then without padding, third party can understand what message is sent. I understand that even third party can understand what message is sent, this will not allow him to decrypt the client-2-client traffic, but from the written above, it makes no sense to hide the message type, that only makes it more difficult cu implement de protocol.

    Paddings almost never work to cover up payloads unless you have a fixed and low maximum message size. In fact, the protocol flow is pretty fixed and thus the payload types can be inferred from looking at timings and directions.

    So, the protection is more in regards to the actual content.
    When it comes to application data, the application can of course pad itself.
    Lennart Grahl
    @lgrahl

    I think that server-auth used in Responder and in Initiator should be 2 different types of messages [...]

    You mean in the protocol? What is the rationale? Also, be aware that the specification is mostly done at this point and clients are being used in production. The only breaking change we currently plan on doing is to remove send-error (but that would be nowhere near as breaking as a change to server-auth).

    Looking in implementation of available clients on github it seems like protocol was written in some non strict type language and then implemented in Java and added hacks like this https://github.com/saltyrtc/saltyrtc-client-java/blob/master/src/main/java/org/saltyrtc/client/helpers/MessageReader.java#L82-L87 that from my point of view it makes no sense.

    I don't consider that a hack. I think it only looks that weird because the code doesn't factor in the role (which would have been less ugly).

    umbri
    @umbri
    To be clear, I try to understand the motivation and the reasonability, and not to offense or critic someone
    Lennart Grahl
    @lgrahl
    No worries. :slight_smile:
    umbri
    @umbri
    I want to thank all that have designed and shared SaltyRTC.
    Lennart Grahl
    @lgrahl
    When it comes to the next version of the protocol, we have gathered some thoughts in a Gist: https://gist.github.com/lgrahl/bc5a715b835e82ecc4fcea8d0443e420
    We have not posted that on the GH page because we don't want to give the intention that v1 is already dead and that we're already working on v2. To be clear, at the moment, we are just gathering ideas and trying to list design flaws that should be mitigated in v2. If and when v2 will happen is uncertain.
    umbri
    @umbri
    @lgrahl Thank you for sharing this. I will take a look.
    One more thing about v1.
    umbri
    @umbri
    For me, it seems like SaltyRTC Relayed Data Task Protocol should be included in Main Protocol. It use no data from auth, and is using same message structure, more then this, it use same WebSocket channel.
    I know that there is application message too :)
    umbri
    @umbri
    @lgrahl After taking a fast look at shared gist I find some answers :) of some other questions
    Lennart Grahl
    @lgrahl
    The relayed data task is a bit of a hack to have a task whose only purpose is to relay data. It cannot be moved into the main protocol because then you wouldn't have any task to negotiate.
    I guess it could have been written to do nothing and just allow for application messages. Not sure why we haven't done this, I guess @dbrgn wanted to save some bytes.
    But it would be better to not require encapsulation inside of a MsgPack object because of the encoding and decoding overhead. This unfortunately cannot be resolved in v1.
    umbri
    @umbri

    @lgrahl You just read my thoughts :) I guess it could have been written to do nothing and just allow for application messages. Not sure why we haven't done this

    When I start implementing SaltyRTC, My first question was why encoding is not separated from main protocol, in our company we use protobuff, and from gist (v2) i see that you are moving in right direction ;)

    Lennart Grahl
    @lgrahl
    Well, Protobuf & co are also encoding formats.
    umbri
    @umbri
    Yep! But you have strong typing out of the box, and don't have to send keys names on every message, plus you have Code Generator Plugin (supported by Google, Apple) that are really helpful, with a clean code style!