[Mono-dev] SSL Channel implementation and SslServerStream

Tue Dec 18 08:20:56 EST 2007

Hello Pablo,

On Tue, 2007-12-18 at 08:28 +0100, pablosantosluac wrote:
> Hi Sebastien,
> 
> Ok, understood.
> 
> Well, I'll run it with the profiler under mono and let you know where I'm 
> loosing the time.
> 
> So, yes, I have a big problem when running on .net then... :-(
> 
> Ok, so, if I understand correctly, this RSA property at X509Certificate 
> class shouldn't take time when running under the mono framework, should it? 

It shouldn't take much time - unless the property is used before a
keypair is being loaded into it. In this case Mono would have to
generate a new keypair (an heavy process) to be compatible with MS
implementation. However such thing *should* not be happening.

> It should be invoked anyway, but wouldn't waste time because the 
> CryptoServiceProvider is better implemented...
> 
> Thanks,
> 
> pablo
> 
> ----- Original Message ----- 
> From: "Sebastien Pouliot" <sebastien.pouliot at gmail.com>
> To: "pablosantosluac" <pablosantosluac at terra.es>
> Cc: "mono-devel-list" <mono-devel-list at lists.ximian.com>
> Sent: Tuesday, December 18, 2007 1:07 AM
> Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream
> 
> 
> > Hey,
> >
> > On Mon, 2007-12-17 at 22:49 +0100, pablosantosluac wrote:
> >> Hi again,
> >>
> >> >> Well, the line which is actually consuming 50% of the time is
> >> >> new MonoX509.X509Certificate(serverCertificate.GetRawCertData());
> >> >> inside the ServerContext constructor.
> >> >
> >> > Are you running this under Mono or MS runtime ?
> >>
> >> MS.
> >
> > well wrong mailing list ;-)
> >
> > Seriously 1.x frameworks* has a serious design flaw wrt to [RSA|
> > DSA]CryptoServiceProvider classes (the former used by the SSL code).
> > Each time one you create an instance of it then it *always* creates a
> > new keypair - even if it is created to load an existing keypair. This
> > makes the classes unusable for server applications.
> >
> > Mono design is different and a keypair is only created if (and when)
> > required.
> >
> >
> > * at least I think it was fixed in 2.0 - I've been bugging them to fix
> > this since 1.0 beta2.
> >
> >> Running with a profiler. Mono results are currently slower, but it could
> >> be related to something else.
> >
> > If Mono is slower then this is probably elsewhere.
> >
> >> I'm having problems when creating more than 80
> >> threads/sockets. Don't know why yet.
> >>
> >>
> >> >> Of course it is related to the RSA calculation inside the MonoX509
> >> >> certificate.
> >> >
> >> > Please provide additional details as there is no RSA computation
> >> > required in the mentioned ctor.
> >> >
> >> >> I guess it could be catched
> >> >
> >> > you mean "cached" ?
> >>
> >> Yes, sorry, cached!
> >>
> >>
> >> >> when attending different clients
> >> >> with the same server certificate, which would improve overall 
> >> >> performance
> >> >> (in my previous email I said it was only local to one client, but I 
> >> >> was
> >> >> wrong).
> >> >
> >> > As I said this CANNOT be cached between a server and multiple clients 
> >> > (a
> >> > little long to explain but it's how SSL is designed).
> >>
> >> Ok, whatever, there's a property called RSA inside the Mono X509
> >> certificate. This property gets invoked once per SSL connection, actually
> >> calculating the same for each connection,
> >
> > Well it's not the same since this is a new key pair each time ;-) but
> > yes it's unneeded
> >
> >> because it is just "completing"
> >> (AFAIK) the server's certificate, if I'm not wrong, of course. I mean, 
> >> the
> >> certificate you pass to the SSLServerStream gets converted again and 
> >> again,
> >> and consuming time. If this can be cached, then the performance can be
> >> really boosted. I think this is *just* the server's certificate, nothing 
> >> to
> >> do with the client (I guess). And yes, maybe it is not RSA calculation, 
> >> but
> >> this is the name of the property where the time is being spent... at 
> >> least
> >> under MS runtime.
> >
> > No, as I said, this is probably time "lost" doing unneeded keypair
> > generation (but this is not the case for Mono).
> >
> >> pablo
> >>
> >>
> >>
> >> >>
> >> >>
> >> >> Regards,
> >> >>
> >> >>
> >> >>
> >> >> pablo
> >> >>
> >> >>
> >> >>
> >> >> ----- Original Message ----- 
> >> >> From: "Sebastien Pouliot" <sebastien.pouliot at gmail.com>
> >> >> To: "pablosantosluac" <pablosantosluac at terra.es>
> >> >> Cc: <mono-devel-list at lists.ximian.com>
> >> >> Sent: Monday, December 17, 2007 7:50 PM
> >> >> Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream
> >> >>
> >> >>
> >> >> > Hello Pablo,
> >> >> >
> >> >> > On Mon, 2007-12-17 at 17:21 +0100, pablosantosluac wrote:
> >> >> >> Hi again,
> >> >> >>
> >> >> >> Well, looking into the ServerContext constructor: the code converts
> >> >> >> between
> >> >> >> the System.Security cert to a Mono cert. Ok, this calculation could 
> >> >> >> be
> >> >> >> skipped if a server is launching threads with the same certificate.
> >> >> >> The
> >> >> >> performance hit "caching" this one is about a 50% (launching 350
> >> >> >> client
> >> >> >> threads simultaneously).
> >> >> >
> >> >> > Sorry but this is confusing. Let me clear this up a bit so the 
> >> >> > answer
> >> >> > will be meaningful when goggled in the future ;-)
> >> >> >
> >> >> > Converting the certificate between the minimal MS X509Certificate 
> >> >> > and
> >> >> > the Mono.Security X509Certificate is a very simple process. This 
> >> >> > could
> >> >> > be cached but this, alone, won't influence much performance.
> >> >> >
> >> >> > The key exchange does an expensive RSA operation, but it cannot be
> >> >> > cached in ServerContext.
> >> >> >
> >> >> > Now what *could* help is implementing a session cache in the
> >> >> > server[1][2]. However this helps only caching a session between the
> >> >> > server and a single client - you cannot share a session between
> >> >> > multiple
> >> >> > clients.
> >> >> >
> >> >> > That being said the server code won't scale to support, efficiently,
> >> >> > 350
> >> >> > sessions. If you need high performance SSL code don't look at a 
> >> >> > managed
> >> >> > implementation (and IMO consider hardware acceleration).
> >> >> >
> >> >> > [1] the SslClientStream already support session caching
> >> >> > [2] contributions welcome
> >> >> >
> >> >> >>
> >> >> >> I'll try to locate the next bottleneck
> >> >> >
> >> >> > All cryptographic operations, like key exchange, encryption, 
> >> >> > integrity,
> >> >> > will show as a "bottleneck" - but they are exactly what you (should)
> >> >> > seek by choosing SSL.
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> pablo
> >> >> >>
> >> >> >>
> >> >> >> ----- Original Message ----- 
> >> >> >> From: "pablosantosluac" <pablosantosluac at terra.es>
> >> >> >> To: <mono-devel-list at lists.ximian.com>
> >> >> >> Sent: Monday, December 17, 2007 4:23 PM
> >> >> >> Subject: [Mono-dev] SSL Channel implementation and SslServerStream
> >> >> >>
> >> >> >>
> >> >> >> > Hi all,
> >> >> >> >
> >> >> >> > I'm implemented a secured TCP remoting channel. I took the 
> >> >> >> > current
> >> >> >> > TCP
> >> >> >> > Channel as starting point, and used Ssl{Client|Server}Stream to
> >> >> >> > implement
> >> >> >> > communication, as Robert Jordan suggested.
> >> >> >> >
> >> >> >> > Well, it seems it works correctly but I've found the following
> >> >> >> > issue:
> >> >> >> > creating each new connection takes time (obviously), but it is
> >> >> >> > basically
> >> >> >> > due
> >> >> >> > to a call to "new ServerContext" inside the SslServerStream
> >> >> >> > constructor.
> >> >> >> >
> >> >> >> > The problem, in fact, seems related with the property
> >> >> >> > X509Certificate::RSA.
> >> >> >> > Each time a new connection is opened, a new certificate is given,
> >> >> >> > and
> >> >> >> > the
> >> >> >> > private key used.
> >> >> >> >
> >> >> >> > Is there a way to actually make all this initialization just 
> >> >> >> > once?
> >> >> >> > It
> >> >> >> > would
> >> >> >> > greatly improve performance both in Mono and .NET.
> >> >> >> >
> >> >> >> > Any idea?
> >> >> >> >
> >> >> >> > thanks
> >> >> >> >
> >> >> >> > pablo
> >> >> >> >
> >> >> >> > _______________________________________________
> >> >> >> > Mono-devel-list mailing list
> >> >> >> > Mono-devel-list at lists.ximian.com
> >> >> >> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> Mono-devel-list mailing list
> >> >> >> Mono-devel-list at lists.ximian.com
> >> >> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >> >> >
> >> >>
> >> >
> >> > _______________________________________________
> >> > Mono-devel-list mailing list
> >> > Mono-devel-list at lists.ximian.com
> >> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >>
> > 
> 