This is a discussion on Re: [openssl.org #1276] [PATCH] TLS Extensions - RFC 3546 (Try 2) - Openssl ; 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 ...
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.
On 2/2/06, Peter Sylvester
> The problem is that extensions may require modification of the internal
> 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.
> 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
> 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
OpenSSL Project http://www.openssl.org
Development Mailing List email@example.com
Automated List Manager firstname.lastname@example.org