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.=20
(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

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 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 applicatio=

> Example, treating the maximum packet size. It would mean that an applicat=

> 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 be=

> attempted in the current snapshot is to concentrate the
> encoding/decoding stuff
> in one place where the appropriate encoding/decoding would be added for n=

> 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 snapsho=

> 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 majordomo@openssl.org