Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
HttpListener crashes application on Linux when SSL connection fails #27391
When I create HttpListener for https (using reflection since it is not supported yet - #19752) and connect to it via http (or client just does not trust the certificate), the exception is thrown from thread outside my control and crashes whole application.
This bug is known from mono https://bugzilla.xamarin.com/show_bug.cgi?id=52675 and was fixed there mono/mono@c1ddee1. But it reappeared here.
Attached is test project, just run with "dotnet run SslConnectionCrashBugDemo.csproj". If you connect via SSL and trust the certificate (curl -k -D - -s https://localhost:4040/), it works fine - returns response and exists. But if you connect via plain HTTP, the application crashes (curl -D - -s http://localhost:4040/):
Yes, you will because I did. All you need to get SSL working is to set the certificate. Currently the only way to do that is to use reflection as I did. Then it works but using this bug anyone can crash the server.
When not fixing SSL bugs before it is implemented, why have you fixed dotnet/corefx#19487? That's also SSL only.
Voting for a fix of this bug.
We have a larger project written in C# and we added an ability to run it on Mono about 2 years ago. Now we started a migration from Mono to .net core to get better performance (especially GC), stability and use of live and fresh runtime. Unfortunately, it is sometimes a little bit fresher than we wish :-) Anyway, we are early adopters and such hits are part of the accepted game.
Of course, the proposed way is to use Kestrel instead of "hacked" SSL in this way. Unfortunately, our existing code uses HttpListeners in many places and we are not able to replace all of them in the first release supporting .net core.
This bug is currently the main blocker to use our product in production on .net core. A release of a product which can be killed by a single wget call is not possible :-(
The proposed fix is simple. It just catches an unexpected exception and makes a proper cleanup instead of a crash of the whole runtime. There is no side effect. It was tested and accepted by Mono and we use it in Mono for more than one year.
As SSL is not officially supported in HttpListener, there is no regression risk for you. But it will be a big help for us. Please consider this during the planning of the fix of this bug.
@martin-frydl we didn't fix dotnet/corefx#19487, we took contribution from Mono team to ease their way of reusing our libraries. cc @baulig as he may be interested in porting this fix from Mono to CoreFX as well.
@pavelchuchma technically, there is always risk for regression from any change. No matter how harmless it seems.
In general, I would be more interested in proper overall SSL support in HttpListener (#14691) which is useful e.g. for IoT scenarios. This bug fix will likely be part of that work (based on information from @martin-frydl).
I really don't know why fixing this is so problematic. Looking at your code https://github.com/dotnet/corefx/blob/master/src/System.Net.HttpListener/src/System/Net/Managed/HttpEndPointListener.cs#L119, it is more or less the same as Mono code https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointListener.cs#L117. The only difference is that try catch with accepted.Close(). The SSL seems to work fine, only this bug causes the server vulnerable to attack because all the attacker has to do to kill the server is to connect to it via plain HTTP. It throws exception from thread I cannot handle and it stops whole application.
The fix is in Mono for some time now, you surely have tests for HttpListener so why not to make this minor fix? You should see if it break something in tests. The problem is that we have to spend lot of time learning Kestrel, hoping it supports what we need and then spend another time implementing it on every place it currently uses HttpListener. We have lot of work porting other parts from .NET Framework to .NET Core since there are many problems with APIs behaving differently on Linux/Core and Windows/Fwk and this would really help us a lot.
@martin-frydl I think we're running in circles here.
Learning Kestrel and using Kestrel is a good future investment, given the status of
That is a valid concern. From that perspective I would count it as +1 on proper SSL support in
That said, I believe we would be ok with community contribution, assuming it is straight port of the Mono change and assuming the contributor is willing to test it locally (using the hacky Reflection way). Is it something you are interested in @martin-frydl?