Hi again, While checking on how to solve this problem, i saw a couple of things. 1 ================== in the same file and function (tls/tls_init.c, function init_ssl_ctx_behavior), there are a couple of log( 2, "CESC: TLS ... statements which i forgot to clean up :D You may want to remove the CESC: ... and maybe turn them into DBG calls .... Aaaaahhh ... if we had a CVS :D 2 ================== I added a feature that allows you to restrict what ciphers are to be used for TLS. I see two main uses for this. First, to allow only highly secure, non-anonymous ciphers (AES with RSA/DSA auth). Or second, for testing purposes, using a NULL encryption algorithm (this way user data can be read ... not in a very nice way in ethereal, but at least read). How to configure this? In my config file i have: listen=tls:IP_LOCAL_SERtcp_accept_aliases = yes tls_certificate="INSTALL_PATH/certs/ser_cert.pem"tls_private_key="INSTALL_PATH/private/ser_prik.pem"tls_ca_list="INSTALL_PATH/certs/ca_list.pem" tls_ciphers_list="NULL-SHA:NULL-MD5:AES256-SHA:AES128-SHA" Note the "tls_ciphers_list" variable. I have set it to use NULL-SHA, so traffic gets authenticated but not encrypted (i do testing). Other possible lists are: SSL_CIPHERS_DEFAULT (this are the ones that are allowed if no tls_ciphers_list is specified, they are the default ones used by OpenSSL). "DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:RC2-CBC-MD5:DHE-DSS-RC4-SHA:RC4-SHA:RC4-MD5:RC4-MD5:RC4-64-MD5:EXP1024-DHE-DSS-DES-CBC-SHA:EXP1024-DES-CBC-SHA:EXP1024-RC2-CBC-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:DES-CBC-MD5:EXP1024-DHE-DSS-RC4-SHA:EXP1024-RC4-SHA:EXP1024-RC4-MD5:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC2-CBC-MD5:EXP-RC4-MD5:EXP-RC4-MD5" SSL_CIPHERS_AES_HIGH_MEDIUM (this are AES only ciphers, not anonymous, with high and medium security level) "DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA" SSL_CIPHERS_TESTING (of course ... the testing list! the NULL ones are usually not available, so depends on the phone, u won't be able to do this) "NULL-SHA:NULL-MD5:AES256-SHA:AES128-SHA" YET_ANOTHER_LIST (this includes high and medium security algorithms, some without authentication, and a variety of ciphers, not just AES) "ADH-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:ADH-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:DHE-DSS-RC4-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:RC4-SHA:RC4-MD5:ADH-DES-CBC3-SHA:ADH-RC4-MD5:DES-CBC3-MD5:RC2-CBC-MD5:RC4-MD5" Regards, Cesc >Hi everybody, > >The last i sent is a replacement as a whole for the original code sent by P. Griffiths. Sorry i forgot to mention that. > >The patches for cfg.y and cfg.lex are both in the same file (patch.core.cfg..files.diff) within the zip. I was lazy :) >I resent it as a whole, and not as a diff, because i indented all the code with tabs, instead of spaces (so a diff would be bigger than just sending all the files). > >As for the CVS thing ... i agree with Juha. Either gets into the "official" cvs or we do something about it. The code i think is rather stable as it is (i only tested on my debian linux box, soon i will try on an ARM linux and i will report back on that too). For me, as long as it gets into a CVS, i don't care if it is mantained against HEAD or 0.9.0 (i use 0.9.0 .... so all my patches are against it). > >On a more philosophical level, i understand the "quietness" on iptel's side ... they have their own version, and make money on it. But the thing is that this free version is here to stay ... it is the "problem" of opensource. >Another option would be for them to release their proprietary implementation if they feel that it is a better, more tested one. >In any case, i think that this whole thing needs to be decided fast. > >Regards! > >Cesc > > > > >>>>Alex Mack <amack(a)fhm.edu> 05/03/05 01:26PM >>> >>>> >Hi Cesc! > >Nice to have those fixes in a package. > >Is your cfg.y-patch to be applied *after* cfg.y.patch was applied or >*instead* of cfg.y.patch? > >Or is your version a patched one which replaces the original >implementation as a whole? In that case where's cfg.lex.patch? > >Alex Mack > > > >>Hi, >> >>I really hate to be so pushy, but i dont understand how such an important piece of code as TLS is not moving on into CVS ... or anywhere else by this matter. I will keep sending patches till i get tired (soon). >> >>Anyway ... i thought someone may be interested in a compilation fix for cfg.y introduced with the tls_domains (it would not compile if the cfg.y file had been patched but the tls-core files were not there); a bug fix for the session caching (fixed by turning session caching and resumption off); and an extension (the ability to choose the list of allowed ciphers from the config file). Oh, and all the files have been tabbed, instead of spaced (for indentation). >> >>Enjoy! >> >>Cesc >> >> Unclassified