[openssl-dev] [openssl.org #1833] [PATCH] Abbreviated Renegotiations
This doesn't seem to be the case any more. Closing. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1833 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl.org #1833] [PATCH] Abbreviated Renegotiations
Stephen Henson via RT wrote: SSL structures should only ever be initialised by calling SSL_new(). Allocating and initialising an SSL structure manually in an application is itself a very non-portable thing to do and requires setting of many undocumented internal fields which will change across major versions. Are you aware of any applications that do that? Yes I agree with this too. In the case of (struct ssl_st) from what I have seen the storage and initialization of it is managed wholly by libssl. But given the choice of using some unused bits of ssl_st.new_session or extending the size of the struct. Maybe some guidelines should be stated in the ssl(3) man page (where types are discussed). * That storage of the X,Y and Z struct types should be managed by libssl. A portable application should not attempt to allocate storage, initialize types, modify types or deallocate storage directly from bespoke application code. A portable application is expected to make use of the OpenSSL API for these purposes. * However should an application find itself needing to access data from internal OpenSSL types directly. That application should not expect other versions of OpenSSL to be compatible and must review that access with every OpenSSL release they consume. It would be desirable if such application developers could submit a usage case to the openssl-dev mailing list so that wider understanding of this behavior with a view that additional API coverage to support that case. Darryl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1833] [PATCH] Abbreviated Renegotiations
Robin Seggelmann via RT wrote:
The latest patch was modified to maintain the previous values of new_session
for legacy applications. We can either break compatibility of a few
applications, if any, by adding a new field or by adding new values. I don't
see any possibility to avoid this at all.
What legacy applications require the previous values of new_session to
be preserved ? How are those applications able to access new_session
without indirecting usage, access and interpretation of new_session via
the libssl.so library itself ?
The only user of these field(s) is libssl.so itself. The exact meaning,
usage and interpretation of the field(s) is a matter of implementation
detail which is encapsulated and presented to the application via the
document OpenSSL APIs.
Doing:
struct ssl_st *ssl;
ssl = SSL_new();
printf(ssl.foobar=%d\n, ssl-foobar);/* Read access is illegal */
ssl-foobar = 1; /* Write access is illegal */
Illegal on the basis that it is not a documented approach to use the
library.
There would be no compatibility issue if you change the meaning of the
ssl_st.new_session (if this is a tri-state, then use bit-0 and bit-1 to
mean the value it needs).
Move the variable renegotiate into bit-2 and bit-3 of
ssl_st.new_session to get the tri-state you need.
Then fixup all the code that uses ssl_st.new_session as well as your new
code that want a tri-state variable (ssl_st.renegotiate).
#define SSL_B_NEW_SESSION_0 0x00
#define SSL_B_NEW_SESSION_1 0x01
#define SSL_B_NEW_SESSION_2 0x02
#define SSL_M_NEW_SESSION 0x03
#define SSL_SET_NEW_SESSION(s) (((s)-new_session) =
(((s)-new_session) (~SSL_M_NEW_SESSION)) | ((v) SSL_M_NEW_SESSION))
#define SSL_TEST_EQUAL_NEW_SESSION(s, v) (((s)-new_session)
SSL_M_NEW_SESSION) == (v))
#define SSL_TEST_NOTEQUAL_NEW_SESSION(s, v) (((s)-new_session)
SSL_M_NEW_SESSION) != (v))
ssl-new_session = 0; /* SSL_SET_NEW_SESSION(ssl, SSL_B_NEW_SESSION_0); */
if(ssl-new_session) {} /* if(SSL_TEST_NOTEQUAL_NEW_SESSION(ssl,
SSL_B_NEW_SESSION_0)) { } */
if(!ssl-new_session) {} /* if(SSL_TEST_EQUAL_NEW_SESSION(ssl,
SSL_B_NEW_SESSION_0)) { } */
if(ssl-new_session == 2) {} /* if(SSL_TEST_EQUAL_NEW_SESSION(ssl,
SSL_B_NEW_SESSION_2)) { } */
#define SSL_B_RENEGOTIATE_0 0x00
#define SSL_B_RENEGOTIATE_1 0x04
#define SSL_B_RENEGOTIATE_2 0x08
#define SSL_M_RENEGOTIATE 0x0c
/* The rest is the same as the NEW_SESSION example
s/NEW_SESSION/RENEGOTIATE/ */
Obviously triple check the logic, make it look prettier, there are a few
extra paranoid parentesis thrown in for good measure (and to
clarify/document precedence intent), also you'd hope the ((v)
SSL_M_NEW_SESSION)) would be optimized out by the compiler due to 2
constants being involved.
Darryl
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #1833] [PATCH] Abbreviated Renegotiations
On Sep 6, 2010, at 10:39 AM, Darryl Miles wrote: The only user of these field(s) is libssl.so itself. The exact meaning, usage and interpretation of the field(s) is a matter of implementation detail which is encapsulated and presented to the application via the document OpenSSL APIs. Ideally this would be true, but in practice various applications do access some fields directly. The big change to stop that would be to move all the struct details completely out of the externally visible header files. Of course, that change too would be rather painful for such applications. Bodo __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1833] [PATCH] Abbreviated Renegotiations
On Sep 6, 2010, at 10:39 AM, Darryl Miles wrote: The only user of these field(s) is libssl.so itself. The exact meaning, usage and interpretation of the field(s) is a matter of implementation detail which is encapsulated and presented to the application via the document OpenSSL APIs. Ideally this would be true, but in practice various applications do access some fields directly. The big change to stop that would be to move all the struct details completely out of the externally visible header files. Of course, that change too would be rather painful for such applications. Bodo __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1833] [PATCH] Abbreviated Renegotiations
Bodo Moeller wrote: Ideally this would be true, but in practice various applications do access some fields directly. The big change to stop that would be to move all the struct details completely out of the externally visible header files. Of course, that change too would be rather painful for such applications. Which applications do you know about doing this ? are they public ? Shouldn't there be something to take from that, if the existing APIs do not provide enough feature coverage shouldn't those users be encouraged to document their use case and provide application code test cases where information is needed to allow somebody to understand and implement suitable API. The suggestion I have thrown in, will not alter the meaning of the lowest 2 bits of ssl_st.new_session (between older versions of OpenSSL and future versions of OpenSSL). So it would be possible for a user doing this to write code that works for all versions of OpenSSL alike (all versions that have ssl_st.new_session at least). The suggestion I have thrown in will not affect anybody who is using OpenSSL in a portable way (I think we should have more consideration for those users, than those who access internal structures directly). The choice: * Enlarge the structure and cause breakage for all users of OpenSSL that allocate a storage in the application for struct ssl_st (affecting both: the group that uses the documented APIs and the group that uses undocumented direct access to internal structure) * Modify the purpose of some of the bits in ssl_st.new_session. This change only affects the group of users that access internal structures directly and only if they happen to access the new_session member itself. However the proposed way forward will allow them to fix their code in such a way that same code will work with version 1.0.0 at runtime alike. I see the modify the purpose option as affecting the least number of users. Darryl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1833] [PATCH] Abbreviated Renegotiations
[darryl-mailingli...@netbauds.net - Mon Sep 06 13:48:47 2010]: The suggestion I have thrown in, will not alter the meaning of the lowest 2 bits of ssl_st.new_session (between older versions of OpenSSL and future versions of OpenSSL). So it would be possible for a user doing this to write code that works for all versions of OpenSSL alike (all versions that have ssl_st.new_session at least). The suggestion I have thrown in will not affect anybody who is using OpenSSL in a portable way (I think we should have more consideration for those users, than those who access internal structures directly). The choice: * Enlarge the structure and cause breakage for all users of OpenSSL that allocate a storage in the application for struct ssl_st (affecting both: the group that uses the documented APIs and the group that uses undocumented direct access to internal structure) * Modify the purpose of some of the bits in ssl_st.new_session. This change only affects the group of users that access internal structures directly and only if they happen to access the new_session member itself. However the proposed way forward will allow them to fix their code in such a way that same code will work with version 1.0.0 at runtime alike. I see the modify the purpose option as affecting the least number of users. SSL structures should only ever be initialised by calling SSL_new(). Allocating and initialising an SSL structure manually in an application is itself a very non-portable thing to do and requires setting of many undocumented internal fields which will change across major versions. Are you aware of any applications that do that? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1833] [PATCH] Abbreviated Renegotiations
[seggelm...@fh-muenster.de - Sun Sep 05 19:44:26 2010]: The latest patch was modified to maintain the previous values of new_session for legacy applications. We can either break compatibility of a few applications, if any, by adding a new field or by adding new values. I don't see any possibility to avoid this at all. Well as long as the meaning of new_session is retained by default there is no compatibility issue. No existing applications will call SSL_renegotiate_abbreviated() so there are no problems with enabling additional functionality after that call. As I understand it currently the problem is that if new_session is set to 0 it will renegotiate and always create a new session. Could we have a new value set by SSL_renegotiate_abbreviated(), for example 4, which means renegotiate and resume if possible. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1833] [PATCH] Abbreviated Renegotiations
On 05.09.2010, at 02:08, Stephen Henson via RT wrote: [seggelm...@fh-muenster.de - Mon Aug 30 16:26:24 2010]: On Aug 27, 2010, at 2:32 PM, Stephen Henson via RT wrote: [seggelm...@fh-muenster.de - Fri Aug 27 11:34:17 2010]: Unfortunately, there was newer code which was not yet covered by the patch. This caused an abbreviated handshake to fail. Applied now, thanks. Note that since we need to retain binary compatibility between 1.0.0 and 1.0.1 we will need to either avoid having to add a new field to ssl.h or move it to the end of the structure. As things are any application accessing a field after the new member would misbehave. Do you need a patch which moves the int renegotiate; to the end of the struct for 1.0.1? No, I was just wondering if it was possible to achieve the same functionality without adding any new fields to the SSL structure? For example by adding flags or new values to the existing new_session field? The latest patch was modified to maintain the previous values of new_session for legacy applications. We can either break compatibility of a few applications, if any, by adding a new field or by adding new values. I don't see any possibility to avoid this at all. -Robin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1833] [PATCH] Abbreviated Renegotiations
[seggelm...@fh-muenster.de - Mon Aug 30 16:26:24 2010]: On Aug 27, 2010, at 2:32 PM, Stephen Henson via RT wrote: [seggelm...@fh-muenster.de - Fri Aug 27 11:34:17 2010]: Unfortunately, there was newer code which was not yet covered by the patch. This caused an abbreviated handshake to fail. Applied now, thanks. Note that since we need to retain binary compatibility between 1.0.0 and 1.0.1 we will need to either avoid having to add a new field to ssl.h or move it to the end of the structure. As things are any application accessing a field after the new member would misbehave. Do you need a patch which moves the int renegotiate; to the end of the struct for 1.0.1? No, I was just wondering if it was possible to achieve the same functionality without adding any new fields to the SSL structure? For example by adding flags or new values to the existing new_session field? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1833] [PATCH] Abbreviated Renegotiations
On Aug 27, 2010, at 2:32 PM, Stephen Henson via RT wrote: [seggelm...@fh-muenster.de - Fri Aug 27 11:34:17 2010]: Unfortunately, there was newer code which was not yet covered by the patch. This caused an abbreviated handshake to fail. Applied now, thanks. Note that since we need to retain binary compatibility between 1.0.0 and 1.0.1 we will need to either avoid having to add a new field to ssl.h or move it to the end of the structure. As things are any application accessing a field after the new member would misbehave. Do you need a patch which moves the int renegotiate; to the end of the struct for 1.0.1? -Robin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1833] [PATCH] Abbreviated Renegotiations
Robin Seggelmann via RT wrote: Note that since we need to retain binary compatibility between 1.0.0 and 1.0.1 we will need to either avoid having to add a new field to ssl.h or move it to the end of the structure. As things are any application accessing a field after the new member would misbehave. Can you cite the mechanism via which an application achieves this (misbehaving) ? Do you need a patch which moves the int renegotiate; to the end of the struct for 1.0.1? Which internal members of the openssl/ssl.h (struct ssl_st) are visible outside of the OpenSSL implementation (i.e. by the application) ? My understanding is that providing there are no macro's directly accessing members of the struct from application code the order issue is moot. If the application programmer has read ssl.h and decided he is going to access internal members of (struct ssl_st) directly, when it has not been documented as safe to do so; should he not be left to burn ? If there are functions/macros/mechanisms that can be compiled into application code which do access and expect structure members to be at specific offsets, WHY IS THIS THE DEFAULT ANYWAY ? i.e. why doesn't the application programmer have to define some -DOPENSSL_UNSAFE_DIRECT_ACCESS disable those accesses that indirect through a function (inside the OpenSSL implementation library) to those implemented as macros and therefore embedded inside applications. But first please confirm the API calls put at risk with you concern with this patch/feature. A larger concern to me is the increasing of the size of the (struct ssl_st) a matter you seem to place at a lower priority than struct member order. If it is possible and accepted usage that an application might allocate a fixed amount of storage, such as static global variables, local stack variables, embedding the (SSL) inside another application defined struct and use of sizeof(SSL). If this is a concern might it be useful to both: * Implement an API call that allows an application program to check the sizeof(SSL) it was compiled with against the runtime libraries implementation size (preferably in a convenient way, mostly assisted by header files and man page copy'n'paste snippet with a view of being future proof). * Reserve some extra headroom in the struct, if you think you need to increase the size during the lifetime of the ABI compatibility you wish to retain. * Document any restriction placed on the programmer when using the library. For example if storage for a specific type is not to be allocated statically (at compiled time). If you increase the size of the struct those applications that do allocate a fixed amount of storage based on openssl-1.0.0 will find that the OpenSSL library is scribbling on memory when it accesses the locations at the highest offsets of the new larger structure. The application will not have allocated quite enough memory and so random problems will occur. Can I suggest you combine the storage area used by these flags so no size increase is necessary. The extra instruction Logical And/Or masking of a register value can be done very cheaply and the patch does not appear to affect any critical performance path with bulk transfer. Darryl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1833] [PATCH] Abbreviated Renegotiations
Robin Seggelmann via RT wrote: Note that since we need to retain binary compatibility between 1.0.0 and 1.0.1 we will need to either avoid having to add a new field to ssl.h or move it to the end of the structure. As things are any application accessing a field after the new member would misbehave. Can you cite the mechanism via which an application achieves this (misbehaving) ? Do you need a patch which moves the int renegotiate; to the end of the struct for 1.0.1? Which internal members of the openssl/ssl.h (struct ssl_st) are visible outside of the OpenSSL implementation (i.e. by the application) ? My understanding is that providing there are no macro's directly accessing members of the struct from application code the order issue is moot. If the application programmer has read ssl.h and decided he is going to access internal members of (struct ssl_st) directly, when it has not been documented as safe to do so; should he not be left to burn ? If there are functions/macros/mechanisms that can be compiled into application code which do access and expect structure members to be at specific offsets, WHY IS THIS THE DEFAULT ANYWAY ? i.e. why doesn't the application programmer have to define some -DOPENSSL_UNSAFE_DIRECT_ACCESS disable those accesses that indirect through a function (inside the OpenSSL implementation library) to those implemented as macros and therefore embedded inside applications. But first please confirm the API calls put at risk with you concern with this patch/feature. A larger concern to me is the increasing of the size of the (struct ssl_st) a matter you seem to place at a lower priority than struct member order. If it is possible and accepted usage that an application might allocate a fixed amount of storage, such as static global variables, local stack variables, embedding the (SSL) inside another application defined struct and use of sizeof(SSL). If this is a concern might it be useful to both: * Implement an API call that allows an application program to check the sizeof(SSL) it was compiled with against the runtime libraries implementation size (preferably in a convenient way, mostly assisted by header files and man page copy'n'paste snippet with a view of being future proof). * Reserve some extra headroom in the struct, if you think you need to increase the size during the lifetime of the ABI compatibility you wish to retain. * Document any restriction placed on the programmer when using the library. For example if storage for a specific type is not to be allocated statically (at compiled time). If you increase the size of the struct those applications that do allocate a fixed amount of storage based on openssl-1.0.0 will find that the OpenSSL library is scribbling on memory when it accesses the locations at the highest offsets of the new larger structure. The application will not have allocated quite enough memory and so random problems will occur. Can I suggest you combine the storage area used by these flags so no size increase is necessary. The extra instruction Logical And/Or masking of a register value can be done very cheaply and the patch does not appear to affect any critical performance path with bulk transfer. Darryl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1833] [PATCH] Abbreviated Renegotiations
[seggelm...@fh-muenster.de - Fri Aug 27 11:34:17 2010]: Unfortunately, there was newer code which was not yet covered by the patch. This caused an abbreviated handshake to fail. Applied now, thanks. Note that since we need to retain binary compatibility between 1.0.0 and 1.0.1 we will need to either avoid having to add a new field to ssl.h or move it to the end of the structure. As things are any application accessing a field after the new member would misbehave. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1833] [PATCH] Abbreviated Renegotiations
Updated version. The variable new_session is now set during a full handshake as
before, to avoid breaking applications which access it directly instead using
SSL_renegotiate_pending() to determine whether a handshake is in progress.
--- ssl/d1_clnt.c 26 Jan 2010 19:46:29 - 1.16.2.15
+++ ssl/d1_clnt.c 26 Aug 2010 13:04:39 -
@@ -171,7 +171,7 @@
switch(s-state)
{
case SSL_ST_RENEGOTIATE:
- s-new_session=1;
+ s-renegotiate=1;
s-state=SSL_ST_CONNECT;
s-ctx-stats.sess_connect_renegotiate++;
/* break */
@@ -539,6 +539,7 @@
/* else do it later in ssl3_write */
s-init_num=0;
+ s-renegotiate=0;
s-new_session=0;
ssl_update_cache(s,SSL_SESS_CACHE_CLIENT);
--- ssl/d1_pkt.c15 Jun 2010 17:25:13 - 1.27.2.25
+++ ssl/d1_pkt.c26 Aug 2010 13:04:39 -
@@ -957,6 +957,7 @@
!(s-s3-flags SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS)
!s-s3-renegotiate)
{
+ s-new_session = 1;
ssl3_renegotiate(s);
if (ssl3_renegotiate_check(s))
{
@@ -1163,6 +1164,7 @@
#else
s-state = s-server ? SSL_ST_ACCEPT : SSL_ST_CONNECT;
#endif
+ s-renegotiate=1;
s-new_session=1;
}
i=s-handshake_func(s);
--- ssl/d1_srvr.c 1 Feb 2010 16:49:42 - 1.20.2.16
+++ ssl/d1_srvr.c 26 Aug 2010 13:04:39 -
@@ -177,7 +177,7 @@
switch (s-state)
{
case SSL_ST_RENEGOTIATE:
- s-new_session=1;
+ s-renegotiate=1;
/* s-state=SSL_ST_ACCEPT; */
case SSL_ST_BEFORE:
@@ -299,7 +299,7 @@
case SSL3_ST_SW_SRVR_HELLO_A:
case SSL3_ST_SW_SRVR_HELLO_B:
- s-new_session = 2;
+ s-renegotiate = 2;
dtls1_start_timer(s);
ret=dtls1_send_server_hello(s);
if (ret = 0) goto end;
@@ -620,11 +620,12 @@
s-init_num=0;
- if (s-new_session == 2) /* skipped if we just sent a
HelloRequest */
+ if (s-renegotiate == 2) /* skipped if we just sent a
HelloRequest */
{
/* actually not necessarily a 'new' session
unless
*
SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION is set */
+ s-renegotiate=0;
s-new_session=0;
ssl_update_cache(s,SSL_SESS_CACHE_SERVER);
--- ssl/s3_clnt.c 28 Feb 2010 00:24:24 - 1.129.2.15
+++ ssl/s3_clnt.c 26 Aug 2010 13:04:39 -
@@ -207,7 +207,7 @@
switch(s-state)
{
case SSL_ST_RENEGOTIATE:
- s-new_session=1;
+ s-renegotiate=1;
s-state=SSL_ST_CONNECT;
s-ctx-stats.sess_connect_renegotiate++;
/* break */
@@ -546,6 +546,7 @@
/* else do it later in ssl3_write */
s-init_num=0;
+ s-renegotiate=0;
s-new_session=0;
ssl_update_cache(s,SSL_SESS_CACHE_CLIENT);
--- ssl/s3_lib.c16 Oct 2009 15:24:19 - 1.126.2.4
+++ ssl/s3_lib.c26 Aug 2010 13:04:39 -
@@ -2226,6 +2226,7 @@
s-packet_length=0;
s-s3-renegotiate=0;
+ s-s3-new_session=0;
s-s3-total_renegotiations=0;
s-s3-num_renegotiations=0;
s-s3-in_read_app_data=0;
--- ssl/s3_pkt.c27 Jun 2010 14:22:10 - 1.72.2.7.2.1
+++ ssl/s3_pkt.c26 Aug 2010 13:04:39 -
@@ -1280,6 +1280,7 @@
#else
s-state = s-server ? SSL_ST_ACCEPT : SSL_ST_CONNECT;
#endif
+ s-renegotiate=1;
s-new_session=1;
}
i=s-handshake_func(s);
--- ssl/s3_srvr.c 27 Feb 2010 23:04:10 - 1.171.2.21
+++ ssl/s3_srvr.c 26 Aug 2010 13:04:39 -
@@ -218,7 +218,7 @@
switch (s-state)
{
case SSL_ST_RENEGOTIATE:
- s-new_session=1;
+ s-renegotiate=1;
/*
Re: [openssl.org #1833] [PATCH] Abbreviated Renegotiations
Here is an up to date version of the patch for OpenSSL 1.0.1.
This patch adds the new variable 'renegotiate' to the SSL struct. Until now the
variable 'new_session' is used to indicate if a renegotiation is in progress
AND if a new session has to be created, i.e. a full handshake has to be
performed. This has the severe disadvantage that it is not possible to perform
an abbreviated handshake and keep the current session. With this patch the new
variable 'renegotiate' is used to determine whether a renegotiation is in
progress and 'new_session' is set whether a new session should be negotiated or
not. This allows to perform abbreviated handshakes and to do so, the function
SSL_renegotiate_abbreviated(SSL *s) is added, while SSL_renegotiate(SSL *s)
remains unchanged and still performs full handshakes.
--- ssl/d1_clnt.c 26 Jan 2010 19:46:29 - 1.16.2.15
+++ ssl/d1_clnt.c 17 Jun 2010 12:47:40 -
@@ -171,7 +171,7 @@
switch(s-state)
{
case SSL_ST_RENEGOTIATE:
- s-new_session=1;
+ s-renegotiate=1;
s-state=SSL_ST_CONNECT;
s-ctx-stats.sess_connect_renegotiate++;
/* break */
@@ -539,7 +539,7 @@
/* else do it later in ssl3_write */
s-init_num=0;
- s-new_session=0;
+ s-renegotiate=0;
ssl_update_cache(s,SSL_SESS_CACHE_CLIENT);
if (s-hit) s-ctx-stats.sess_hit++;
--- ssl/d1_pkt.c15 Jun 2010 17:25:13 - 1.27.2.25
+++ ssl/d1_pkt.c17 Jun 2010 12:47:40 -
@@ -957,6 +957,7 @@
!(s-s3-flags SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS)
!s-s3-renegotiate)
{
+ s-new_session = 1;
ssl3_renegotiate(s);
if (ssl3_renegotiate_check(s))
{
@@ -1163,7 +1164,7 @@
#else
s-state = s-server ? SSL_ST_ACCEPT : SSL_ST_CONNECT;
#endif
- s-new_session=1;
+ s-renegotiate=1;
}
i=s-handshake_func(s);
if (i 0) return(i);
--- ssl/d1_srvr.c 1 Feb 2010 16:49:42 - 1.20.2.16
+++ ssl/d1_srvr.c 17 Jun 2010 12:47:40 -
@@ -177,7 +177,7 @@
switch (s-state)
{
case SSL_ST_RENEGOTIATE:
- s-new_session=1;
+ s-renegotiate=1;
/* s-state=SSL_ST_ACCEPT; */
case SSL_ST_BEFORE:
@@ -299,7 +299,7 @@
case SSL3_ST_SW_SRVR_HELLO_A:
case SSL3_ST_SW_SRVR_HELLO_B:
- s-new_session = 2;
+ s-renegotiate = 2;
dtls1_start_timer(s);
ret=dtls1_send_server_hello(s);
if (ret = 0) goto end;
@@ -620,12 +620,12 @@
s-init_num=0;
- if (s-new_session == 2) /* skipped if we just sent a
HelloRequest */
+ if (s-renegotiate == 2) /* skipped if we just sent a
HelloRequest */
{
/* actually not necessarily a 'new' session
unless
*
SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION is set */
- s-new_session=0;
+ s-renegotiate=0;
ssl_update_cache(s,SSL_SESS_CACHE_SERVER);
--- ssl/s3_clnt.c 28 Feb 2010 00:24:24 - 1.129.2.15
+++ ssl/s3_clnt.c 17 Jun 2010 12:47:40 -
@@ -207,7 +207,7 @@
switch(s-state)
{
case SSL_ST_RENEGOTIATE:
- s-new_session=1;
+ s-renegotiate=1;
s-state=SSL_ST_CONNECT;
s-ctx-stats.sess_connect_renegotiate++;
/* break */
@@ -546,7 +546,7 @@
/* else do it later in ssl3_write */
s-init_num=0;
- s-new_session=0;
+ s-renegotiate=0;
ssl_update_cache(s,SSL_SESS_CACHE_CLIENT);
if (s-hit) s-ctx-stats.sess_hit++;
--- ssl/s3_pkt.c25 Mar 2010 11:22:42 - 1.72.2.7
+++ ssl/s3_pkt.c17 Jun 2010 12:47:41 -
@@ -1261,7 +1261,7 @@
#else
s-state = s-server ? SSL_ST_ACCEPT : SSL_ST_CONNECT;
#endif
- s-new_session=1;
+
[openssl.org #1833] [PATCH] Abbreviated Renegotiations
Updated version for compatibility with 1.0.0beta1:
--- ssl/d1_clnt.c 2008-06-02 00:33:24.0 +0200
+++ ssl/d1_clnt.c 2009-04-16 09:41:59.0 +0200
@@ -169,7 +169,7 @@
switch(s-state)
{
case SSL_ST_RENEGOTIATE:
- s-new_session=1;
+ s-renegotiate=1;
s-state=SSL_ST_CONNECT;
s-ctx-stats.sess_connect_renegotiate++;
/* break */
@@ -476,7 +476,7 @@
/* else do it later in ssl3_write */
s-init_num=0;
- s-new_session=0;
+ s-renegotiate=0;
ssl_update_cache(s,SSL_SESS_CACHE_CLIENT);
if (s-hit) s-ctx-stats.sess_hit++;
--- ssl/d1_pkt.c2008-12-29 17:11:57.0 +0100
+++ ssl/d1_pkt.c2009-04-16 09:41:59.0 +0200
@@ -1086,7 +1086,7 @@
#else
s-state = s-server ? SSL_ST_ACCEPT : SSL_ST_CONNECT;
#endif
- s-new_session=1;
+ s-renegotiate=1;
}
i=s-handshake_func(s);
if (i 0) return(i);
--- ssl/d1_srvr.c 2008-09-14 16:02:07.0 +0200
+++ ssl/d1_srvr.c 2009-04-16 09:41:59.0 +0200
@@ -178,7 +178,7 @@
switch (s-state)
{
case SSL_ST_RENEGOTIATE:
- s-new_session=1;
+ s-renegotiate=1;
/* s-state=SSL_ST_ACCEPT; */
case SSL_ST_BEFORE:
@@ -269,7 +269,7 @@
s-shutdown=0;
ret=ssl3_get_client_hello(s);
if (ret = 0) goto end;
- s-new_session = 2;
+ s-renegotiate = 2;
if (s-d1-send_cookie)
s-state = DTLS1_ST_SW_HELLO_VERIFY_REQUEST_A;
@@ -533,12 +533,12 @@
s-init_num=0;
- if (s-new_session == 2) /* skipped if we just sent a
HelloRequest
*/
+ if (s-renegotiate == 2) /* skipped if we just sent a
HelloRequest
*/
{
/* actually not necessarily a 'new' session
unless
*
SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION is set */
- s-new_session=0;
+ s-renegotiate=0;
ssl_update_cache(s,SSL_SESS_CACHE_SERVER);
--- ssl/s3_clnt.c 2009-02-14 22:49:38.0 +0100
+++ ssl/s3_clnt.c 2009-04-16 09:41:59.0 +0200
@@ -211,7 +211,7 @@
switch(s-state)
{
case SSL_ST_RENEGOTIATE:
- s-new_session=1;
+ s-renegotiate=1;
s-state=SSL_ST_CONNECT;
s-ctx-stats.sess_connect_renegotiate++;
/* break */
@@ -548,7 +548,7 @@
/* else do it later in ssl3_write */
s-init_num=0;
- s-new_session=0;
+ s-renegotiate=0;
ssl_update_cache(s,SSL_SESS_CACHE_CLIENT);
if (s-hit) s-ctx-stats.sess_hit++;
--- ssl/s3_pkt.c2009-01-28 08:09:23.0 +0100
+++ ssl/s3_pkt.c2009-04-16 09:41:59.0 +0200
@@ -1212,7 +1212,7 @@
#else
s-state = s-server ? SSL_ST_ACCEPT : SSL_ST_CONNECT;
#endif
- s-new_session=1;
+ s-renegotiate=1;
}
i=s-handshake_func(s);
if (i 0) return(i);
--- ssl/s3_srvr.c 2009-01-08 00:44:27.0 +0100
+++ ssl/s3_srvr.c 2009-04-16 09:43:34.0 +0200
@@ -219,7 +219,7 @@
switch (s-state)
{
case SSL_ST_RENEGOTIATE:
- s-new_session=1;
+ s-renegotiate=1;
/* s-state=SSL_ST_ACCEPT; */
case SSL_ST_BEFORE:
@@ -305,7 +305,7 @@
ret=ssl3_get_client_hello(s);
if (ret = 0) goto end;
- s-new_session = 2;
+ s-renegotiate = 2;
s-state=SSL3_ST_SW_SRVR_HELLO_A;
s-init_num=0;
break;
@@ -650,12 +650,12 @@
s-init_num=0;
- if (s-new_session == 2) /* skipped if we just sent a
HelloRequest
*/
+ if (s-renegotiate == 2) /*
[openssl.org #1833] [PATCH] Abbreviated Renegotiations
Whenever a handshake is initiated, the variable s-new_session is set
to indicate that a handshake is being performed. This is not the
correct context because a handshake can also be abbreviated and will
not create a new session then. This variable is also used in the right
context to determine whether or not the current Session ID is sent
with a ClientHello. The result is that renegotiations always create a
new session because the handshake state has to be set. There is no
possibility to perform an abbreviated handshake for renegotiation
conform to the TLS specification. This patch adds the variable s-
renegotiate to indicate handshakes, so that s-new_session only
indicates if a new session should be created, that is a full handshake
should be performed. The patch also adds the function
SSL_renegotiate_abbreviated(SSL* ssl) which can be used to trigger an
abbreviated handshake. The functionality of SSL_renegotiate(SSL* ssl)
remains the same and always performs a full handshake.
--- ssl/d1_clnt.c 2008-06-04 20:35:25.0 +0200
+++ ssl/d1_clnt.c 2009-01-30 11:31:23.0 +0100
@@ -169,7 +169,7 @@
switch(s-state)
{
case SSL_ST_RENEGOTIATE:
- s-new_session=1;
+ s-renegotiate=1;
s-state=SSL_ST_CONNECT;
s-ctx-stats.sess_connect_renegotiate++;
/* break */
@@ -478,7 +478,7 @@
/* else do it later in ssl3_write */
s-init_num=0;
- s-new_session=0;
+ s-renegotiate=0;
ssl_update_cache(s,SSL_SESS_CACHE_CLIENT);
if (s-hit) s-ctx-stats.sess_hit++;
--- ssl/d1_pkt.c2008-10-13 08:43:06.0 +0200
+++ ssl/d1_pkt.c2009-01-30 11:32:30.0 +0100
@@ -1047,7 +1047,7 @@
#else
s-state = s-server ? SSL_ST_ACCEPT : SSL_ST_CONNECT;
#endif
- s-new_session=1;
+ s-renegotiate=1;
}
i=s-handshake_func(s);
if (i 0) return(i);
--- ssl/d1_srvr.c 2008-09-14 16:02:01.0 +0200
+++ ssl/d1_srvr.c 2009-01-30 14:05:35.0 +0100
@@ -176,7 +176,7 @@
switch (s-state)
{
case SSL_ST_RENEGOTIATE:
- s-new_session=1;
+ s-renegotiate=1;
/* s-state=SSL_ST_ACCEPT; */
case SSL_ST_BEFORE:
@@ -267,7 +267,7 @@
s-shutdown=0;
ret=ssl3_get_client_hello(s);
if (ret = 0) goto end;
- s-new_session = 2;
+ s-renegotiate = 2;
if ( s-d1-send_cookie)
s-state = DTLS1_ST_SW_HELLO_VERIFY_REQUEST_A;
@@ -532,12 +532,12 @@
s-init_num=0;
- if (s-new_session == 2) /* skipped if we just sent a
HelloRequest
*/
+ if (s-renegotiate == 2) /* skipped if we just sent a
HelloRequest
*/
{
/* actually not necessarily a 'new' session
unless
*
SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION is set */
- s-new_session=0;
+ s-renegotiate=0;
ssl_update_cache(s,SSL_SESS_CACHE_SERVER);
--- ssl/s3_clnt.c 2009-01-07 11:48:23.0 +0100
+++ ssl/s3_clnt.c 2009-01-30 14:07:32.0 +0100
@@ -194,7 +194,7 @@
switch(s-state)
{
case SSL_ST_RENEGOTIATE:
- s-new_session=1;
+ s-renegotiate=1;
s-state=SSL_ST_CONNECT;
s-ctx-stats.sess_connect_renegotiate++;
/* break */
@@ -529,7 +529,7 @@
/* else do it later in ssl3_write */
s-init_num=0;
- s-new_session=0;
+ s-renegotiate=0;
ssl_update_cache(s,SSL_SESS_CACHE_CLIENT);
if (s-hit) s-ctx-stats.sess_hit++;
--- ssl/s3_pkt.c2008-10-10 12:41:32.0 +0200
+++ ssl/s3_pkt.c2009-01-29 14:25:53.0 +0100
@@ -1128,7 +1128,7 @@
#else
s-state = s-server ? SSL_ST_ACCEPT : SSL_ST_CONNECT;
#endif
- s-new_session=1;
+ s-renegotiate=1;
}
i=s-handshake_func(s);
if (i 0) return(i);
---
