[Mono-dev] SSL Channel implementation and SslServerStream

pablosantosluac pablosantosluac at terra.es
Tue Dec 18 02:28:46 EST 2007


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 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
>>
> 




More information about the Mono-devel-list mailing list