[Mono-devel-list] XSP updates

Sébastien Pouliot spouliot at videotron.ca
Wed Apr 6 08:44:54 EDT 2005


Hello Brian,

> > > 1) HTTPS support.  I successfully integrated the Mono.Security
> > Without much thinking, I'd like this to be disabled by default and have
> > and option (--https?) to enable HTTPS support.
>
> We'd also need options to specify the cert file, private key file, and
> optionally the private key password.  Carlos or Sebastien may have
> more input on what kinds of options we should support for loading
> these.

For testing purpose you may want an option to specify (well restrict) the
supported protocol - i.e. SSLv3 or TLSv1
(Mono.Security.Protocol.Tls.SecurityProtocolType SecurityProtocol), the
default being accepting both types of clients.

Another "nice" feature would be to restrict the cryptographic algorithms
that can be used. By default SSL/TLS negotiate the "best" cipher suite based
on what the server and client both support. In real-life you may want to:
* remove algorithm too costly (performance wise) to support more clients,
e.g. AES 256 bits;
* remove weak algorithms, e.g. the 40/56/64 bits DES/RC2; and
* export restrictions may only allow someone to use the weak algorithms
anyway;
But there is no public API to do so (reflection would be required).

Then there is the support for client side certificates but that may be
outside your current goals ;-).

> > > 2) Turn the core of XSP into a library.  I'd like to make a
> > Awesome. This is on my TODO list, but I have not got there yet. Probably
>
> Excellent. Do you think the configuration file access code should go
> into the assembly or xsp.exe?  For example, my project doesn't use the
> configuration file support provided by xsp since it has its own.
> However, it may be handy for others to have this in the library.

> I've attached some <initial> patches for https, OnCreateHost delegate,
> and some method accessibility changes. (needed by external apps)
> Please review to make sure I'm headed in the right direction.  I'll
> begin work on the configuration and assembly changes.  Once this is
> completed, I'll send around final patches for review.


+		public XSPWebSource(IPAddress address, int port,
+			Mono.Security.Protocol.Tls.SecurityProtocolType securityProtocol,
+			System.Security.Cryptography.X509Certificates.X509Certificate cert,
+			Mono.Security.Authenticode.PrivateKey key,
+			bool RequireClientCert)
+		{
...
+		public XSPWorker (Socket client, EndPoint localEP,
Mono.ASPNET.ApplicationServer server,
+			bool SecureConnection,
+			Mono.Security.Protocol.Tls.SecurityProtocolType SecurityProtocol,
+			X509Certificate Cert,
+			PrivateKey key,
+			bool RequireClientCert)

For many reasons you shouldn't use a specific key format for the private key
(e.g. Mono.Security.Authenticode.PrivateKey) but instead use the
AsymmetricAlgorithm class. E.g.

* the PVK format is old and weak (but well supported by makecert tool);
* many people will have a hard time to convert other (more secure) formats
(e.g. PKCS#12) to PVK;
* it's possible (but not supported today in Mono) to use non-RSA keypairs
(e.g. DSA and DH) for SSL/TLS. Which is why the
PrivateKeyCertSelectionDelegate returns a AsymmetricAlgorithm.

So for the moment I think you should write a basic helper ImportKey method
that takes the PrivateKey (and optionally a password) and return an
AsymmetricAlgorithm instance. That way anyone can easily extends the
supported data format (or hardware support) in the future without touching
the core XSP code.

Thanks

Sebastien Pouliot
home: spouliot at videotron.ca
blog: http://pages.infinit.net/ctech/poupou.html




More information about the Mono-devel-list mailing list