Bug 52508 - TLS SignalR Self-host Hang
Summary: TLS SignalR Self-host Hang
Status: CONFIRMED
Alias: None
Product: Class Libraries
Classification: Mono
Component: Mono.Security (show other bugs)
Version: 4.8.0 (C9)
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Martin Baulig
URL:
Depends on:
Blocks:
 
Reported: 2017-02-14 17:22 UTC by Rusty
Modified: 2017-06-13 18:38 UTC (History)
5 users (show)

See Also:
Tags: xamexttriage
Is this bug a regression?: ---
Last known good build:


Attachments
Attachment contains a SignalR self-host console app, a .NET SignalR client console app, and a self-signed certificate to test TLS (5.95 MB, application/x-zip-compressed)
2017-02-14 17:22 UTC, Rusty
Details

Description Rusty 2017-02-14 17:22:56 UTC
Created attachment 19815 [details]
Attachment contains a SignalR self-host console app, a .NET SignalR client console app, and a self-signed certificate to test TLS

Attached is a slightly modified version of the SignalR solution normally found here: http://signalr.net/

I modified the solution to provide TLS support.  HTTP works fine.  When you attempt to use TLS, the SignalR negotiation hangs.  It does not matter if you are using BTLS or the Legacy provider.

INSTALL CERTS - Perform either A or B
A. Use self-signed certificate already generated via openssl that comes in the attachment.
 1. Copy localhost.crt and localhost.key to the below directory and rename to 37921.cer and 37921.pvk respectively.
   1a. localhost.crt -> ~/.config/.mono/httplistener/37921.cer
   2b. localhost.key -> ~/.config/.mono/httplistener/37921.pvk
 2. Place localhost.p12 into your login certificate keychain.  Certificate password is tst123.  Open up the certificate trust and select 'Always Trust' for the SSL Trust setting.

B. Run the below commands
 1. openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:2048 -subj "/C=US/ST=Texas/L=Dallas/O=TST/CN=localhost" -keyout localhost1.key -out localhost1.crt -passin pass:tst123
 2. security add-trusted-cert -r trustRoot -p ssl -k $HOME/Library/Keychains/login.keychain localhost1.crt
 3. security import localhost1.key -k $HOME/Library/Keychains/login.keychain -P tst123 -A
 4. openssl pkcs12 -name "Test Company Name" -nodes -export -inkey localhost1.key -in localhost1.crt -out localhost1.p12 -passout pass:tst123
 5. httpcfg -add -port 37921 -p12 localhost1.p12 -pwd tst123

TESTING
Open the below solution
SignalR-Dev\Microsoft.AspNet.SignalR.Mono.sln

Run the Self-host Console Sample
SignalR-dev\samples\Microsoft.AspNet.SelfHost.Samples\

- Program.cs: I added a TestTls preprocessor.  To test normal HTTP, comment out.

To ensure your self-host application is working you can navigate to the below via chrome and it should load the javascript proxy file:
1. With TLS: https://localhost:37921/SignalR/hubs
2. Without TLS: http://localhost:37921/SignalR/hubs

Run the .NET Client Console Sample
SignalR-dev\samples\Microsoft.AspNet.SignalR.Client40.Samples\

- Program.cs: I added a TestTls preprocessor.  To test normal HTTP, comment out.
- Client.cs: When testing with TLS, execution will hang in the RunChatHub method when the connection attempts to start.

Although we have a JavaScript client that experiences the same issue, I thought it was best to create a test solution with a .NET client to bypass any potential CORS, mixed content, or any other browser related issues that could come up with a SignalR client running from within the browser. 

This issue does NOT happen with Mono version 4.2.3.
Comment 1 Ammar Mheir 2017-03-08 21:24:39 UTC
Setting status to CONRIMED as was able to successfully replicate the issue after adding certificates indicated above using Mono 4.8 on Xamarin Studio Cycle 9.

Error still occurring when downgrading Xamarin Studio to Cycle 8 which subsequently downgraded Mono to 4.6.2.
Comment 2 Martin Baulig 2017-04-06 20:09:25 UTC
I _may_ have a fix for this.

This HttpConnection.Init() method here
https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/HttpConnection.cs#L114
is called from Close().

This throws because you must not call SslStream.AuthenticateAsServer() while having an active connection.

Note You need to log in before you can comment on or make changes to this bug.