reagrding extended hello on sess resumption

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

reagrding extended hello on sess resumption

jimmy-6
Hi,

Currently openssl-0.9.9 accepts a client hello (session resumption),
with or without the extended hello part. Why is this so?

Is it (or is it not) necessary to check if the extensions are the same
as previously negotiated? i.e., shouldn't the extensions be validated
w.r.t. previously negotiated values like the cipher & compression?


Thanks,
jimmy
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: reagrding extended hello on sess resumption

Peter Sylvester-3
Hm.

A correct client would not set a different one. There is
no requirement to check anything on session resume.

The only extension that is currently supported is the servername extension.
In order to use this effectively, you need an applictaion call back.
If you don't have a callback, the extension is simply ignored (and not
acknowledged.)
If you have an application level callback, then the callback can signal
several things, abort, warn, acknowledge.

The callback is also called on session resumption because the application
may need to swithch to a good application context.
The value for the servername obtained is the one from the saved session,
not from the client_hello, or in other words, the (new) client_hello
extension
is ignored on session resumption.

The current TLS extension texts defines only some good combinations of
this extension and the HTTP Host: header, and given some vague SHOULD NOTs
etc.

Does that make sense.

jimmy wrote:

> Hi,
>
> Currently openssl-0.9.9 accepts a client hello (session resumption),
> with or without the extended hello part. Why is this so?
>
> Is it (or is it not) necessary to check if the extensions are the same
> as previously negotiated? i.e., shouldn't the extensions be validated
> w.r.t. previously negotiated values like the cipher & compression?
>
>
> Thanks,
> jimmy
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
>

--
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: reagrding extended hello on sess resumption

Ambarish Mitra
In reply to this post by jimmy-6

This is the SSL protocol itself.

http://wp.netscape.com/eng/ssl3/traces/trc-clnt-us.html#ClientHello1



-----Original Message-----
From: [hidden email]
[mailto:[hidden email]]On Behalf Of jimmy
Sent: Monday, February 06, 2006 10:47 PM
To: [hidden email]
Subject: reagrding extended hello on sess resumption


Hi,

Currently openssl-0.9.9 accepts a client hello (session resumption),
with or without the extended hello part. Why is this so?

Is it (or is it not) necessary to check if the extensions are the same
as previously negotiated? i.e., shouldn't the extensions be validated
w.r.t. previously negotiated values like the cipher & compression?


Thanks,
jimmy
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: reagrding extended hello on sess resumption

jimmy-6
In reply to this post by Peter Sylvester-3
Peter Sylvester wrote:
> Hm.
>
> A correct client would not set a different one. There is
> no requirement to check anything on session resume.
>
Yes. in fact 3546 did specify this. i missed it :-)

> The only extension that is currently supported is the servername extension.
> In order to use this effectively, you need an applictaion call back.
> If you don't have a callback, the extension is simply ignored (and not
> acknowledged.)
> If you have an application level callback, then the callback can signal
> several things, abort, warn, acknowledge.
>
> The callback is also called on session resumption because the application
> may need to swithch to a good application context.
> The value for the servername obtained is the one from the saved session,
> not from the client_hello, or in other words, the (new) client_hello
> extension
> is ignored on session resumption.
>
> The current TLS extension texts defines only some good combinations of
> this extension and the HTTP Host: header, and given some vague SHOULD NOTs
> etc.
>
> Does that make sense.
Yes. it does. thanks!

>
> jimmy wrote:
>> Hi,
>>
>> Currently openssl-0.9.9 accepts a client hello (session resumption),
>> with or without the extended hello part. Why is this so?
>>
>> Is it (or is it not) necessary to check if the extensions are the same
>> as previously negotiated? i.e., shouldn't the extensions be validated
>> w.r.t. previously negotiated values like the cipher & compression?
>>
>>
>> Thanks,
>> jimmy
>> ______________________________________________________________________
>> OpenSSL Project                                 http://www.openssl.org
>> User Support Mailing List                    [hidden email]
>> Automated List Manager                           [hidden email]
>>
>>
>
>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]