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
On using a 2048 certs
We have upgraded our TCP app to use OpenSSL to communicate with the server. Just want to confirm whether there will be any changes to the app code due to the 2048 certs updation by verisign ? I understand that the format of Key generation needs a change from our side, but how about the app code ? Please clarify. Do i need to check anything else ? Thanks Regards Karthikeyan Thirumal
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 #1794] [PATCH] SRP ciphersuites in 1.0.1 and 1.1.0 (updated)
Hi Thomas, [...@openssl.org email corrected] Looking at the latest SRP patch [1], I noticed the use of RAND_bytes: lines 5047 and 5222. Bytes acquired at 5047 are subsequently used in a call to generate B's key pair, while the call at 5222 is later used for A's key pair generation. According to the OpenSSL documentation on RAND_bytes [2], RAND_bytes returns 1 on success, 0 otherwise. But it appears the current implementation does not detect a possible failure, which might get a user into trouble under [presumably] a narrowly limited set of circumstances. I understand the documentation is not always up to date (the dev team is usually busy doing what they do best - developing), so I might be wrong on the whole return value/failure thing. OT: I look forward to seeing SRP incorporated into OpenSSL (both RFC 2945 and RFC 5054). They are both very helpful when needed. Jeffrey Walton [1] http://rt.openssl.org/Ticket/Attachment/25682/12416/srp-openssl-20100208-patch.txt [2] RAND_bytes, http://www.openssl.org/docs/crypto/RAND_bytes.html __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1794] [PATCH] SRP ciphersuites in 1.0.1 and 1.1.0 (updated)
Hi Thomas, Looking at the latest SRP patch [1], I noticed the use of RAND_pseudo_bytes. I believe RAND_pseudo_bytes is sufficient for salts and other public values. But it does appear that RAND_pseudo_bytes is being used for keying material at lines 3171 and 3187. The bytes acquired at 3171 and 3187 are then used to generate A's and B's key pairs. According to the OpenSSL documentation on RAND_pseudo_bytes [2], RAND_pseudo_bytes might not be suitable for keying material: RAND_pseudo_bytes() will be unique if they are of sufficient length, but are not necessarily unpredictable. They can be used for non-cryptographic purposes and for certain purposes in cryptographic protocols, but usually not for key generation etc. I understand the documentation is not always up to date (the dev team is usually busy doing what they do best - developing), so I might be wrong on the use of RAND_pseudo_bytes. Jeffrey Walton [1] http://rt.openssl.org/Ticket/Attachment/25682/12416/srp-openssl-20100208-patch.txt [2] RAND_bytes, http://www.openssl.org/docs/crypto/RAND_bytes.html __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1794] [PATCH] SRP ciphersuites in 1.0.1 and 1.1.0 (updated)
Hi Thomas, Looking at the latest SRP patch [1], I noticed the patch was not zeroizing all keying buffers used with RAND_bytes [and perhaps erroneously RAND_pseudo_bytes]. For example, a particular buffer is last used in routine run_srp(const char *username, ...) at line 3171. But the buffer is not zeroized on exit even though due diligence is applied to the subsequent BIGNUM (which is cleared with BN_clear_free). Jeffrey Walton [1] http://rt.openssl.org/Ticket/Attachment/25682/12416/srp-openssl-20100208-patch.txt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
