actual linux/non windows support?

[mitchcapper]

So using this in windows requires you adding the "textsecure-servicewhispersystemsorg.crt" certificate to "Trusted people" either at runtime (as the UWP app does) or manually otherwise.

The problem is there is no "Trusted People" equivalent in linux. You can add CA's to the locally approved list but "textsecure-servicewhispersystemsorg.crt" has no public CA certificate that signed it (as far as I can tell) that one could import if they wanted to.

dotnet/corefx#12038 addresses custom validation for ClientWebSocket but who knows how far out that is.

Open if anyone has additional thoughts on working around this issue to allow this code to work on other platforms:) The most obvious I see is moving to a 3rd party web socket library like https://github.com/sta/websocket-sharp that supports server certificate validation.

[Trolldemorted]

Does the ServicePointManager's ServerCertificateValidationCallback work in dotnet core apps/wine/whereever?

Iirc i originally wanted to use that, but it didn't work on uwp because uwp uses different socket implementations under the hood.

[mitchcapper]

@Trolldemorted
Correct that never has existed in .net core. The solution for httpClient is to init a HttpClientHandler and specify the callback handler there. It is more elegant than a global one as well. The problem is ClientWebSocket does not yet have anything similar. That is what dotnet/corefx#12038 addresses.

[Trolldemorted]

Damn. So there is no official workaround for custom certificates until ManagedWebSockets arrive?

Can we alter .net cores certificate validation with reflection?

[mitchcapper]

As far as I understand it there is no known work around and the WebSocket code is native (so just copying the .net core code would not work). In addition it seems officially it will not be making it in the next revision either.

Reflection may be a hacky option but im not sure would be best (and not sure of the reduced .net standard options for UWP compatability).

Moving to a 3rd party web socket library however could resolve this.

[Trolldemorted]

I found a stackoverflow answer where someone made his own ClientWebSocket to send cookies when opening the connection. It uses a HttpWebRequest to establish a connection, which has a ServerCertificateValidationCallback that can be used to manually accept/reject certificates.

Now the next problem is, when you use the ServerCertificateValidationCallback in an UWP app, you get a PlatformNotSupportedException. We could catch and silently ignore this on UWP though (since UWP can still use the TrustedPeople workaround), and it should™ work on all other platforms as far as i know.

I am visiting my family and having exams this and the next week, but after that i will have a look.

[mitchcapper]

I would agree with the proposed solution. Technically the work around of using the WinRT client instead is doable with a few #defines depending on the platform is doable. Given the existing work around for UWP of using the trusted people would simplify the code base to just use the native .net HTTPClient lib.

[mitchcapper]

@Trolldemorted plans on this? My primary target is non-windows so cannot use the lib with this blocker.

[Trolldemorted]

Sorry, i have an important exam in 2 weeks and thus been very busy.

Could you test https://github.com/signal-csharp/libsignal-service-dotnet/tree/certificates and see if the PushServiceSocket works?

[mitchcapper]

Per #28 if you want I can create the default handlers for this, update the package to target netapp2.1 and 1.4 or we can leave it without default handlers and just have users write their own. I just don't want to submit a PR that has to be rebased as it just sits if you don't want it.

[Trolldemorted]

Not sure if multitargeting is worth the hassle, but we could include a sample impl in the documentation (some documentation would be great anyway, now that I think of it). It could get outdated if we make changes to the interface and forget to update the doc, but I really hope we don't have to touch it every again.

Our previous ws impl automatically reconnected, do we want to maintain that behaviour? If so, addressing Turasa/libsignal-service-java#16 becomes more important.

[mitchcapper]

I would assume we want to reconnect still.
I took an initial wack at this and have it working for .net core. It is a good bit of code and I am not sure where I would suggest a PR for it (as it doesn't belong in the windows lib either). We could add it here just commented out (or consider retargetting). If someone had to do it from scratch would be somewhat annoying to figure out (and required for .net core 2.1 and higher per above).
https://gist.github.com/mitchcapper/1a40fd1b008f60aaf7c27ffa48dd2432

It would be less of an issue maintaining parity (or for someone to do their own .net core version) but the windows library switched to using MessageWebSocket which there is no .net standard version or library for.