Re: [openssl.org #1276] [PATCH] TLS Extensions - RFC 3546 (Try 2)

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
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 <Peter.Sylvester@edelweb.fr> wrote:[color=blue]
> 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=[/color]
n.[color=blue]
> Example, treating the maximum packet size. It would mean that an applicat=[/color]
ion[color=blue]
> 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=[/color]
en[color=blue]
> 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=[/color]
ew[color=blue]
> 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=[/color]
t[color=blue]
> 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[/color]
______________________________________________________________________
OpenSSL Project [url]http://www.openssl.org[/url]
Development Mailing List [email]openssl-dev@openssl.org[/email]
Automated List Manager [email]majordomo@openssl.org[/email]