Security support for new .net 5 platforms #101
Conversation
|
adding @wfurt for TLS angle |
|
and @samsp-msft for boringssl background. |
| The current dependency on OpenSSL could work as there seems to be support for building on Android. This is nice because it would seemingly ‘just fit’ with what we already have. However, there are some things to take into consideration: | ||
|
|
||
| * Do we fork a copy of OpenSSL and build from that? | ||
| * What is our process for shipping security vulnerability updates? |
There was a problem hiding this comment.
If we have to ship something with an app, don't these questions/concerns apply to any choice?
There was a problem hiding this comment.
Yep - I'll try to restate.
There was a problem hiding this comment.
I was aware that Google Play Services includes cronet & boringSSL, but they seem to only be exposed via a Java cronet API - https://developer.android.com/guide/topics/connectivity/cronet - which probably doesn't help us.
There was a problem hiding this comment.
Last I knew, Google's documented stance on BoringSSL was that it was unsupported, could change its ABI at any time, etc... exactly what you want when taking a dependency on a security library ;-) If there's a supported/maintained variant, that's then more interesting.
There was a problem hiding this comment.
We really, really, really want to avoid shipping a cryptography library with the product. AFAIK, it adds a whole lot of government paperwork; and it creates a very complicated servicing model for both us and the applications built using it.
If there's any library in the box that we can reliably use, that's the best choice almost without regard to how painful it is to initially use it.
There was a problem hiding this comment.
I think you'd need to use the conscrypt APIs - which are higher level http APIs.
This may help: https://groups.google.com/forum/#!topic/conscrypt/T4c2YCY91qc.
|
|
||
| Do we: | ||
| * Investigate libgss further and flush out all the dependencies / challenges? | ||
| * Bring most / all functionality into a managed implementation? What does that look like? Who would do it? |
There was a problem hiding this comment.
What does Xamarin do today?
There was a problem hiding this comment.
We now use SocketsHttpHandler as the default, so the same as corefx. The previous way was a custom implementation that is pretty old.
There was a problem hiding this comment.
This isn't just about HttpClient, this is about NegotateStream as well (though maybe we don't care about it for these workloads?). More generally for this doc, it's about System.Security.Cryptography, System.Net.Security, etc.
The previous way was a custom implementation that is pretty old.
Is that would it would look like to bring it into a managed implementation? What are its dependencies? Is it doing cryptographic work?
accepted/2020/mono-convergence/security-support-new-platforms.md
Outdated
Show resolved
Hide resolved
accepted/2020/mono-convergence/security-support-new-platforms.md
Outdated
Show resolved
Hide resolved
|
cc @ericstj |
|
@steveisok who owns the next action here -- just checking we're not all waiting for each other 😺 |
|
@danmosemsft I think the doc is good to go. Unless determining what we're going to do about OpenSSL is a pre-requisite? |
|
What's the plan about this doc? Meanwhile the Android part was implemented through JNI calls and iOS through Apple APIs. Most of the text seems outdated in this regard. |
|
Hmm, thought this was in. Lost in the .NET 5 - 6 shuffle. It is a bit dated - I can give it some updates as we've made some progress. |
No description provided.