[
https://issues.apache.org/jira/browse/TINKERPOP-2682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485617#comment-17485617
]
ASF GitHub Bot commented on TINKERPOP-2682:
-------------------------------------------
FlorianHockmann opened a new pull request #1559:
URL: https://github.com/apache/tinkerpop/pull/1559
https://issues.apache.org/jira/browse/TINKERPOP-2695
WebSocket support was only added in .NET 6 which made it necessary to
explicitly add .NET 6 as an additional target framework. Compression will now
be enabled by default on .NET 6 as it's only available there. This made it
necessary to add conditional compilation based on the target framework.
### Package validation
I also enabled [package
validation](https://docs.microsoft.com/en-us/dotnet/fundamentals/package-validation/overview)
so we a) notice if we introduce breaking changes by accident and b) ensure
that our code compiled against .NET Standard 2.0 can also be run against .NET
6. This already helped me to keep the breaking change here to a minimum. It's
just an added optional parameter here to be able to disable compression. We
could refactor the `GremlinClient` constructors in the future in a way to avoid
this problem of having to add optional parameters for new config options which
is always a breaking change. The validation is executed on `dotnet pack` which
gets already executed via `mvn verify` and is therefore also part of our GH
actions.
Compatibility errors that we know about and that we accept should be added
to the `CompatibilitySuppressions.xml` file which can also be generated via
```
dotnet pack Gremlin.Net.csproj /p:GenerateCompatibilitySuppressionFile=true
```
### Possibly vulnerable to attacks (CRIME / BREACH)
WebSocket compression can be problematic due to attacks like CRIME/BREACH as
noted in TINKERPOP-2682. So, I added an option to easily disable it for
applications that might be vulnerable and added docs to make users aware of
this.
I guess we should discuss how we want to deal with this in general as it's
not specific to .NET. So, should we simply add similar notes to the Java/Python
docs?
### Benchmarks
Lastly, some quick benchmarks I ran on my machine:
**GraphBinary:**
Without compression:
Packets transmitted: 3594
Bytes transmitted: 7MB
Runtime: 1min 1.5sec
With compression:
Packets transmitted: 62 (1.7%)
Bytes transmitted: 34KB (0.5%)
Runtime: 1.3sec
**GraphSON 3:**
Without compression:
Packets transmitted: 12029
Bytes transmitted: 25MB
Runtime: 1min 40sec
With compression:
Packets transmitted: 116 (1.0%)
Bytes transmitted: 103KB (0.4%)
Runtime: 1min 39sec
So, both for GraphSON as well as for GraphBinary the network traffic shrinks
by a factor of ~100 while the total runtime is not affected. Note that this was
just a very simple benchmark (I used the same traversal as @spmallette used in
the PRs for Python and Java, just with a smaller number of iterations to keep
the runtime to a minimum). The results will of course vary for different
traversals / graphs.
VOTE +1
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
> Enable WebSocket compression in .NET by default
> -----------------------------------------------
>
> Key: TINKERPOP-2682
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2682
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
> Affects Versions: 3.5.1
> Reporter: Florian Hockmann
> Assignee: Florian Hockmann
> Priority: Minor
>
> .NET 6 added support for WebSocket compression to .NET:
> [https://devblogs.microsoft.com/dotnet/announcing-net-6/#websocket-compression]
> Users can already enable that by themselves as it has been added as a
> property {{DangerousDeflate}} to the {{ClientWebSocketOptions}} which can be
> configured via the {{webSocketConfiguration}} of the {{GremlinClient}}
> constructor in Gremlin.Net.
> Since we have enabled compression by default in Python and Java, it makes
> sense to also enable it by default in .NET. We can of course only do that for
> .NET 6 which is why we'll have to add that as an additional target framework
> to Gremlin.Net.
> The .NET 6 announcement mentions that WebSocket compression together with
> encrypted content is susceptible to attacks like CRIME and BREACH that can
> reveal the encrypted content if an attacker is able to control data that is
> sent together with the encrypted content over the same WebSocket connection.
> That is why the property to enable compression is called
> {_}Dangerous{_}Deflate and why compression can also be disabled on a
> per-message basis
> ([source|https://github.com/dotnet/runtime/issues/31088#issuecomment-804359919]).
> I suggest we can account for these possible attacks by disabling compression
> for the authentication messages we send to the server which contain
> credentials and by adding a note to the docs about this with a recommendation
> to disable compression if an application needs to send sensitive data, but
> also data controlled by (potentially untrusted) users to the server.
> Since the attacker additionally needs to be able to monitor the network
> traffic between the client and the server, I guess >99% of applications are
> not affected by this and will therefore benefit from enabling compression by
> default.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
