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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > > -- Martin Hinks http://www.m-s-d.net _______________________________________________ Mono-devel-list mailing list [email protected] http://lists.ximian.com/mailman/listinfo/mono-devel-list
