This is an update on our efforts to upgrade the TLS stack in Mono.
You can skip to the summary at the end if you do not care about the sausage making details.
Currently, TLS is surfaced in a few places in the .NET APIs:
- By the
SslStreamclass, which is a general purpose class that can be used to turn any bidirectional stream into an TLS-powered stream. This class is what currently powers the web client in Mono.
- By the
HttpWebRequestclass, which provides .NET's HTTP client. This in turn is the foundation for the modern
HttpClient, both the WCF and WebServices stacks as well as the quick and dirty
HttpClient is in particular interesting, as it
allows for different transports to be provided for it. The
default implementation in .NET 4.5 and Mono today is to use
HttpWebRequest-based implementation. But on
Windows 10, the implementation is replaced with one that uses
WinRT's HTTP client.
Microsoft is encouraging developers to
HttpWebRequest and instead
HttpClient as it both async-friendly and
can use the best available transport given on a specific
platform. More on this in a second.
Mono's Managed TLS
Mono currently only supports TLS 1.0.
This is the stack that powers
Last year we started an effort to bring managed implementations of TLS 1.2 and TLS 1.1. Given how serious security has become and how many holes have been found in existing implementation, we built this with an extensive test suite to check for conformance and to avoid common exploits found in implementation mistakes of TLS. This effort is currently under development and you can see where it currently lives at mono-tls module.
This will give us complete TLS support for the entire stack, but this work is still going to take a few months to audit.
Platform Specific HttpClients
Most of the uses for TLS today is via the HTTP protocol,
and not over custom TLS streams. This means that it is more
important to get an HTTP client that supports a brand new TLS
stack, than it is to provide the
We want to provide native
for all of Mono's supported platforms: Android, iOS, Mac,
Linux, BSD, Unix and Windows.
On iOS: Today Xamarin.iOS already ships a native
This one is powered by Apple's CFNetwork stack. In recent
years, Apple has improved their networking stack, and we now I
strongly recommend using Paul Bett's
which uses iOS' brand new NSUrlSession and uses OkHttp on
On Android: in the short term, we recommend adopting ModernHttpClient from Paul Betts (bonus points: the same component works on iOS with no changes). In the long term, we will change the default handler to use the Android Java client.
In both cases, you end up with HTTP 2.0 capable clients for free.
But this still leaves Linux, Windows and other assorted operating systems without a regular transport.
For those platforms, we will be adopting the CoreFX handlers, which on Unix are powered by the libcurl library.
This still leaves
everything built on top of it running on top of our TLS
Bringing Microsoft's SslStream and HttpWebRequest to Mono
While this is not really TLS related, we wanted to bring Microsoft's implementations of those two classes to Mono, as they would fix many odd corner cases in the API, and address limitations in our stack that do not exist in Microsoft's implementation.
But the code is tightly coupled to native Windows APIs which makes the adoption of this code difficult.
We have built an adaptation layer that will allow us to bring Microsoft's code and use Mono's Managed TLS implementation.
Our original effort focused on a pure managed implementation of TLS because we want to ensure that the TLS stack would work on all available platforms in the same way. This also means that all of the .NET code that expects to control every knob of your secure connection to work (pinning certificates or validating your own chains for example).
That said, in many cases developers do not need this capabilities, and in fact, on Xamarin.iOS, we can not even provide the functionality, as the OS does not give users access to the certificate chains.
So we are going to be developing at least two
SslStream implementations. For Apple
systems, we will be implementing a version on top of Apple's
SSL stack, and for other systems we will be developing an
implementation on top of Amazon's new SSL library, or the
popular OpenSSL variant of the day.
These have the advantage that we would not need to maintain the code, and we benefit from third parties doing all the hard security work and will be suitable for most uses.
Android, Mac and iOS users can get the latest TLS for HTTP
Mac/iOS users can use the
CFNetworkHandler as well.
Soon: OpenSSL/AppleSSL based transports to be available in Mono (post Mono 4.2).
Soon: Advanced .NET SSL use case scenarios will be supported with Mono's new mono-tls stack
SslStream stacks will be replaced in Mono
with Microsoft's implementations.