[Mono-dev] X509Chain
Miguel, you said We have implemented TLS 1.1 and 1.2 on top of the not yet open sourced networking stack and will be publishing it as soon as Microsoft open sources the .NET networking stack. Have there been unpublished changes to Mono.Security.X509.X509Chain? Something I think I could reasonably do, if it's not a waste of time, is to improve the Build() method, so it will build a chain using both the roots store, and the intermediates store. And come up with a way of populating the intermediates store. (Such as improvement on mozroots.) I wouldn't want to work on that, if it's obsoleted by code that will hopefully be published soon... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] X509Chain
Hello Edward, I do not believe we have made changes to X509Chain. The only thing we have been doing is reimplementing chunks of the protocol (as it does not exist in the referecesource) Miguel On Wed, Jan 7, 2015 at 3:57 AM, Edward Ned Harvey (mono) edward.harvey.m...@clevertrove.com wrote: Miguel, you said We have implemented TLS 1.1 and 1.2 on top of the not yet open sourced networking stack and will be publishing it as soon as Microsoft open sources the .NET networking stack. Have there been unpublished changes to Mono.Security.X509.X509Chain? Something I think I could reasonably do, if it's not a waste of time, is to improve the Build() method, so it will build a chain using both the roots store, and the intermediates store. And come up with a way of populating the intermediates store. (Such as improvement on mozroots.) I wouldn't want to work on that, if it's obsoleted by code that will hopefully be published soon... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono.Posix Cross Compiling
Sorry the question was already answered above but let me restate the issue. The issue is compiling between ms build and xbuild as the mono.posix reference should only be there in Unix (windows uses win api calls) Above is a good solution (conditional reference) which works. I know we could manually add a binary reference to mono.posix.dll and then not use it but that just feels wrong. The conditional reference is exactly what we were looking for and works like a charm now! The alternative we were looking at was copy/pasting syscalls.cs which is also ugly :) Greg On Wednesday, January 7, 2015, Jonathan Pryor jonpr...@vt.edu wrote: On Jan 5, 2015, at 6:08 PM, Greg Young gregoryyou...@gmail.com javascript:; wrote: Have anyone used mono.posix or mono.unix.native in a cross compiling scenario where you have to support visual studio builds? How did you handle this? I don't seem to be able to do a platform specific reference. What's the problem? Mono.Posix.dll is MIT/X11; simply bundle the assembly with your code, along with MonoPosixHelper.dll (just copy from the Mono install). Furthermore, Mono.Unix.Native.Stdlib should work as-is on Windows (it uses MSVCRT.dll). You will need to be careful not to actually use Syscall/etc. on Windows, but due to the lazy nature of the JIT this should be reasonably straightforward: if (running on Unix) MethodWhichUsesSyscall (); ... MethodWhichUsesSyscall() won't be JIT'd unless executed, so any references to e.g. Syscall will be lazily evaluated, allowing things to work on Windows. - Jon -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] X509Chain
From: Miguel de Icaza [mailto:mig...@xamarin.com] I do not believe we have made changes to X509Chain. Ok, thank you. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono.Posix Cross Compiling
On Jan 5, 2015, at 6:08 PM, Greg Young gregoryyou...@gmail.com wrote: Have anyone used mono.posix or mono.unix.native in a cross compiling scenario where you have to support visual studio builds? How did you handle this? I don't seem to be able to do a platform specific reference. What's the problem? Mono.Posix.dll is MIT/X11; simply bundle the assembly with your code, along with MonoPosixHelper.dll (just copy from the Mono install). Furthermore, Mono.Unix.Native.Stdlib should work as-is on Windows (it uses MSVCRT.dll). You will need to be careful not to actually use Syscall/etc. on Windows, but due to the lazy nature of the JIT this should be reasonably straightforward: if (running on Unix) MethodWhichUsesSyscall (); ... MethodWhichUsesSyscall() won't be JIT'd unless executed, so any references to e.g. Syscall will be lazily evaluated, allowing things to work on Windows. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Request for comments: mozroots, msroots, X509Chain
Is Sebastien on this list? I'm just guessing he'll have an opinion, or at least a passing interest. I guess Miguel, too. When a client application makes a SSL/TLS connection to a server, the application must validate the server cert, validate any chain of intermediate signing certs, and conclude by validating a trusted CA root cert that terminates the chain, or else the connection is considered untrusted/insecure. No matter what, the server cert (leaf cert) is provided by the server. No matter what, the root cert must exist in a predefined list of roots trusted by the client. This leaves a little bit of ambiguity around the process of building the chain of intermediates - The server may send the chain to the client, or the client may construct a chain any way it can, but if it fails to build a valid chain, the connection is considered untrusted/insecure. It is well known that mono ships with no trusted CA roots. If a user wants to use a mono-based application to connect to any type of SSL/TLS server (including https), they are typically required to use the mozroots command (part of mono) to populate the root list. There are several things wrong with this - #1, it's not user friendly to require users to manually run a command on the terminal before they can use standard internet resources. #2, application developers are very likely to automate the mozroots process into their applications (I know I do). This is cumbersome to developers, particularly because mozroots is a console application, not a class that can be called programatically. #3, Although people generally know about the empty mono root CA list, most people don't know there is a separate list of intermediates (also empty). Both lists are empty by default, but mozroots populates the root list by downloading from mozilla. The intermediate list remains empty. There is nothing strictly *wrong* with populating the root list and leaving the intermediate list empty, but it means the mono client is fragile. If the SSL server fails to send the chain to the client for any reason, then the client has no other recourse, and will fail to construct a chain. The client could be more robust, if the intermediate list were populated too. Then, the client could usually build a valid chain, even if the server fails to send the chain. To validate this concept, I'd like to point out that Microsoft ships Windows with a list of roots *and* a list of intermediates populated by default. side note There is a bug in mono that prevents a mono server from sending the chain to the client. This bug is being worked on independently of this email. Since a mono client has no intermediates, it means a mono client is doomed whenever it tries to connect to a mono server signed by an intermediate, which is unfortunately the real world norm. Interestingly, if you run a .Net client and mono server, then the connection succeeds because the client is able to construct the chain from the MS list of intermediates. Also, if you run a .Net server and mono client, the connection succeeds because the .Net server successfully sends the chain to the client. The incompatibility problem occurs strictly when a mono client connects to a mono server signed by intermediate. This lends even more validity to the concept of populating a list of intermediates on the client, to make the client more robust. /side note As a final piece of background information here, I need to point out that mono X509Chain currently does not attempt to use the intermediate store to build a chain. So even if the intermediate list were populated, the mono client would still fail to build the chain. So finally, I get to the meat of this email: 1- I would like to introduce a new way of populating the root list. I would like to create a new MSRoots class, and corresponding msroots wrapper console application, that can be used instead of, or in addition to mozroots. Users can run msroots from the terminal, just as they are accustomed to do with mozroots. But application developers can also use the MSRoots class to perform the same job programatically - very easy. MSRoots will follow the Microsoft practice of populating roots and intermediates, instead of following the mozilla practice of populating roots without intermediates. Also, MSRoots will follow the MS selection of roots (currently 43 roots) and will not follow the mozilla list (currently over 140 roots). Copyright and license terms are a sticky subject when distributing CA certs. To avoid any difficulty, I support the current approach of *not* distributing certs, but instead, automating the download. It is absolutely legal (fair use) to distribute URL's that refer to potentially copyrighted material; since the URL is only a reference, the URL is legal to distribute under fair use. I hereby volunteer to maintain a list of references, and to automate the process of updating that
