[Mono-dev] Status of SslStream and Related Classes

[Martin Hinks]

Hi Sebastien,

Ok, maybe the whole TLS cipher spec was a bit optimistic - hehe - just
reading up on some stuff now - I'll definetly try to do some of the DH
stuff though - some of the more common ones would be useful.

I've asked on the glftpd site about which ciphers they support -
otherwise I'm just going to have to force it to use the cipher I want
to test by removing all others from the cipher list.

I meant SSLClientStream and SSLServerStream - will be cool when we've
got SSLStream!

Sigh, I thought it wouldn't be good enough - bug in one, bug in the
other... don't want to give ourselves a false sense of security now do
we?!

Thanks for all the input, as I said, I'll have a blast at it some time
next week.

Martin

On 8/19/05, Sebastien Pouliot <sebastien.pouliot at gmail.com> wrote:
> Hello Martin,
> 
> On Fri, 2005-19-08 at 18:48 +0100, Martin Hinks wrote:
> > The servers that are causing me the most problems are glftpd servers,
> > which have a proprietary SSL implementation that is not open source.
> > Seems to be no intersect between their ciphers and monos on many
> > setups.
> 
> Sadly an SSL server doesn't show it's list of ciphers - but you could
> try to fool one by sending all known ciphers to it, check the selected
> cipher, remove it and continue...
> 
> > Sorry, I re-read the bit about DH....
> 
> np ;-)
> 
> > So basically, all I have to do is find the point in SSLStream where
> > the negotiation completes and crypto objects are initialised and
> > instead of creating, say an RSA object, create a DH (and so on for the
> > selected cipher spec.)
> 
> Yes, you have to replace the part after the cipher selection and before
> the symmetric keys are created.
> 
> Keep in mind that SslStream (2.0) doesn't work yet - but yes you can do
> this in SslClientStream (and that code will eventually moves to the new
> SslStream).
> 
> > I'll have a go on it next week when I have some time, thanks for the
> > info - I'd really like to extend the cipher suite to support
> > practically all the TLS cipher spec.
> 
> Well I admit that DH would be nice but *all* ciphers may be too much
> (e.g. you don't want to mess up with the fortezza stuff ;-).
> 
> > As for the testing, can I not create a hacked version of the Mono SSL
> > Server Stream (can't remember it's name)
> 
> SslServerStream
> 
> > which only supports the
> > cipher I want to test? Or is testing the Mono SSLClient against the
> > Mono SSLServer not good enough - ie. do I need to test against an
> > external component?
> 
> Not good enough - at least for development as you risk having interop
> problems (just like we had with client certificates).
> 
> Once both client and server are working with another implementation
> (e.g. openssl) you can use them, together, for regression testing (as
> long as you don't make changes in both of them before testing).
> 
> Ethereal is (or will be) your friend ;-)
> 
> > Thanks again,
> >
> > Martin
> >
> > On 8/18/05, Sebastien Pouliot <sebastien.pouliot at gmail.com> wrote:
> > > Hello Martin,
> > >
> > > On Thu, 2005-18-08 at 19:21 +0100, Martin Hinks wrote:
> > > > Ok, thanks for the answer - I may well have a look at adding some of
> > > > the ciphers when I get time...
> > >
> > > That would be nice :)
> > >
> > > > I know that it is not a requirement to support all ciphers, but many
> > > > servers that I am using also do not support all the ciphers - they
> > > > seem to support all the ones Mono doesn't currently support - great
> > > > lol!
> > >
> > > Mono supports the most common algorithms - at least from an HTTPS point
> > > of view. What are those servers running (software and protocol) ?
> > >
> > > > The error produced is could not negotiate a cipher or something
> > > > similar - which was "fixed" by adding a DH cipher to the list of
> > > > support ciphers (when I say fixed I mean it got a stage further - so
> > > > the exception was just unsupported ciphers.)
> > >
> > > Both normal.
> > >
> > > Negotiation is done by intersecting the list of ciphers available to
> > > both client and server and selecting (server) one of them. An alert is
> > > sent if the intersection is empty.
> > >
> > > Adding something, like DH, to the client list results in a non-empty
> > > intersection - but the client isn't capable to continue the handshake
> > > because it doesn't support DH.
> > >
> > > > When I said "problem" I meant the lack of support for, hence, is the
> > > > lack of support due to DH in Mono not being implemented or merely that
> > > > the SSLStream hasn't been tweaked to support DH?
> > >
> > > I answered that...
> > > > > * Mono.Security.dll supports DH (i.e. DH is present and working) so it
> > > > > isn't a cryptographic issue;
> > >
> > > > Thanks again, it's a great class as it is - would be great if I could
> > > > help add some ciphers!
> > >
> > > As I said it shouldn't too complex to add. It's even easier (test wise)
> > > if you have access to servers that only support algorithms not present
> > > in Mono.
> > > --
> > > Sebastien Pouliot <sebastien.pouliot at gmail.com>
> 
> 
> 


-- 
Martin Hinks
http://www.m-s-d.net