I'd like to see a generic callback mechanism in that I want to be able to write my own dispatcher for TLS extensions. I also want to be able to call something to put my own extension data in place per-SSL_CTX. (I want to be able to violate the TLS extension specification, if only to verify that my application is talking to another instance of itself, using a high-numbered extension. I'm surprised that the TLS extension authors didn't create an 'experimental' range of extension numbers -- it's going to take separate IETF action to reserve a small range.)
Just because a lot of applications don't want to know how SSL/TLS is done doesn't mean that all of them don't. -Kyle H On 2/2/06, Peter Sylvester <[EMAIL PROTECTED]> wrote: > Hello, > > The problem is that extensions may require modification of the internal > states > of openssl, or at least have to interfere with it in some cases. Or, in > other words, > extension doesn't mean that either all extensions are logically > equivalent because > they are indicated with some number in the hellos, some are extensions > of the > protocol which may be done with almost no interaction with the application. > Example, treating the maximum packet size. It would mean that an application > would call a SSL_set_hello_extension to set the value of the extension. > Well, > ok, but then openssl has to check first, whether it needs additional > logic to support > the required extension in any way, but how can it know this? > > I also have the feeling that applications don't really want to > understand how > the ssl protocols happens, and neither how encodings are done, but > rather just > interfere as either providing parameters or being called at an > appropriate instance. > > To me it seems too low level to allow applications to interfere with the > protocol data, I'd prefer an API for some abstract service with set/get > functions > and callbacks, i.e., following exactly the same logic as with > 'normal/standard' features. > > Thus, each "extension" is independant and needs support code. What has been > attempted in the current snapshot is to concentrate the > encoding/decoding stuff > in one place where the appropriate encoding/decoding would be added for new > extensions, and then, add the required logic where it has to be added. > The global compile option of whether tls extensions are supported may not > really be necessary unless one really has a small footprint problem. > > Well, this is my current state of thinking, the code in the devel snapshot > is experimental, and the core team may change it at any time. > > Am I right that your current patch only provides a callback for ONE > extension? > > Regards > Peter ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
