Vic Lee wrote, On 03/18/2011 03:46 AM: > On 03/17/2011 07:26 PM, Mads Kiilerich wrote: >> crypto_* might just contain a set of crypto algorithms, but from another >> point of view they implement "methods" on different kinds of crypto >> "objects" (md5, sha1, rc4, x509 certificate). I don't think a nice >> encapsulation in tls_openssl is that different from that. > The major difference between crypto and tls is that the algorithms in > crypto is "stateless", but tls is "stateful" (that needs to be > maintained throughout of the entire session). > >> But after taking a closer look at tls_openssl I see that it currently is >> at a higher level than crypto_* - but I don't think it has to be. I >> don't think struct rdp_tls should contain a rdpSec *, and it shouldn't >> call ui_check_certificate directly. It would perhaps be better if there >> was a way to retrieve a CryptoCert from a rdpTls. > I agree, and this requires some more code arrangement. If we want to > keep tls_* separated, we need to further separate the struct definitions > into crypto_openssl.h, crypto_gnutls.h, etc, so that they can be > included in tls_openssl.c. Does this make sense?
Yes, I think it makes perfect sense _if_ the tls stuff has to live in its own c file. I still don't see the need for keeping tls in its own file. Just like other crypto "objects" they have a state that has to be maintained as long as they are alive. The rc4 state of non-tls connections has a lifetime that is comparable to the tls lifetime (at least for short-lived connections). But if you want to do it go ahead ;-) /Mads ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
