[Mono-dev] Status of SslStream and Related Classes

[Sebastien Pouliot]

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>