Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST
);
if (s-tls_session_secret_cb(s, s-session-master_key,
s-session-master_key_length,
NULL, pref_cipher,
s-tls_session_secret_cb_arg))
{
s-session-cipher = pref_cipher ?
pref_cipher : ssl_get_cipher_by_char(s, p+j);
}
}
#endif /* OPENSSL_NO_TLSEXT */
This is surely wrong as it's just ignoring the failure?
Thanks,
Emilia
From: openssl-dev [openssl-dev-boun...@openssl.org
mailto:openssl-dev-boun...@openssl.org] on behalf of Dr. Stephen Henson
[st...@openssl.org mailto:st...@openssl.org]
Sent: Thursday, March 19, 2015 11:49 AM
To: openssl-dev@openssl.org mailto:openssl-dev@openssl.org
Subject: Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared
secret seem to break EAP-FAST
On Thu, Mar 19, 2015, Erik Tkal wrote:
If I do not send a sessionID in the clientHello but do send a valid
sessionTicket extension, the server goes straight to changeCipherSpec and
the client generates an UnexpectedMessage alert.
Does the server send back an empty session ticket extension?
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
http://www.openssl.org/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
https://mta.openssl.org/mailman/listinfo/openssl-dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
https://mta.openssl.org/mailman/listinfo/openssl-dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
https://mta.openssl.org/mailman/listinfo/openssl-dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
https://mta.openssl.org/mailman/listinfo/openssl-dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST
pre-shared
secret */
if (s-version = TLS1_VERSION s-tls_session_secret_cb)
{
SSL_CIPHER *pref_cipher=NULL;
s-session-master_key_length=sizeof(s-session-master_key);
if (s-tls_session_secret_cb(s, s-session-master_key,
s-session-master_key_length,
NULL, pref_cipher,
s-tls_session_secret_cb_arg))
{
s-session-cipher = pref_cipher ?
pref_cipher : ssl_get_cipher_by_char(s, p+j);
}
}
#endif /* OPENSSL_NO_TLSEXT */
This is surely wrong as it's just ignoring the failure?
Thanks,
Emilia
From: openssl-dev [openssl-dev-boun...@openssl.org
mailto:openssl-dev-boun...@openssl.org] on behalf of Dr. Stephen Henson
[st...@openssl.org mailto:st...@openssl.org]
Sent: Thursday, March 19, 2015 11:49 AM
To: openssl-dev@openssl.org mailto:openssl-dev@openssl.org
Subject: Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared
secret seem to break EAP-FAST
On Thu, Mar 19, 2015, Erik Tkal wrote:
If I do not send a sessionID in the clientHello but do send a valid
sessionTicket extension, the server goes straight to changeCipherSpec and
the client generates an UnexpectedMessage alert.
Does the server send back an empty session ticket extension?
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
http://www.openssl.org/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
https://mta.openssl.org/mailman/listinfo/openssl-dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
https://mta.openssl.org/mailman/listinfo/openssl-dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
https://mta.openssl.org/mailman/listinfo/openssl-dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
https://mta.openssl.org/mailman/listinfo/openssl-dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST
[0x7fafcc801000] (7 bytes = 7 (0x7)) - 15 03 03 00 02 02 0a ... 140735260517200:error:14094085:SSL routines:SSL3_READ_BYTES:ccs received early:s3_pkt.c:1340: --- On 17 Mar 2015, at 4:16 PM, Erik Tkal etks...@gmail.com wrote: I don’t disagree, but I’m looking for independent confirmation that the changes are not correct. They do not appear to specifically have been made for any vulnerabilities. In looking at RFC 5077 (the generic non-EAP-FAST scenario) section 3.1 shows that the server may send a certificate message to continue the handshake after receiving a sessionTicket from the client. With the first change I noted below the possession of a tls_session_secret now implies by the setting of s-hit on the client that the session *will* be resumed, which is not the case. The resumption requires determination of the next message. In the case of a pure sessionID resumption that is the case since the server confirms it in the serverHello, but not when using the sessionTicket extension. Erik On 17 Mar 2015, at 2:59 PM, Karthikeyan Bhargavan karthikeyan.bharga...@inria.fr mailto:karthikeyan.bharga...@inria.fr wrote: I would be very careful about this code. When we ran our tests on OpenSSL (www.smacktls.com http://www.smacktls.com/), we found a bunch of issues that were narrowly prevented by a combination of flags (s-hit, SSL3_FLAGS_OK, s-s3-change_cipher_spec). Let’s carefully test any change here, so we do not re-enable CVE-2014-0224 (Early CCS Attack) On 17 Mar 2015, at 18:53, Erik Tkal etks...@gmail.com mailto:etks...@gmail.com wrote: In upgrading from 1.0.1i to 1.0.1l I found an issue in the behaviour of a non-resumed EAP-FAST session. RFC 4851 indicates that the server can go straight from the serverHello to changeCipherSpec to resume a session but can also fall back to a full handshake. With 1.0.1l the client ends up issuing an unexpected message alert if the server continues with its certificate message. I traced this to the following change: Set s-hit when resuming from external pre-shared secret. https://github.com/openssl/openssl/commit/7b3ba508af5c86afe43e28174aa3c53a0a24f4d9 https://github.com/openssl/openssl/commit/7b3ba508af5c86afe43e28174aa3c53a0a24f4d9 When processing the serverHello s-tls_session_secret_cb() is called to see if the client has a session secret, and if so the old code would set the flag that a CCS was acceptable at that point. However, the above change now also sets s-hit, which then “requires* that a finished message is expected next, triggering the alert otherwise. Also, another change is suspect in that the latest code no longer sets the flag that a CCS is acceptable at that point: Ensure SSL3_FLAGS_CCS_OK (or d1-change_cipher_spec_ok for DTLS) is reset https://github.com/openssl/openssl/commit/e94a6c0ede623960728415b68650a595e48f5a43 https://github.com/openssl/openssl/commit/e94a6c0ede623960728415b68650a595e48f5a43 In order for EAP-FAST to work it seems that if the client does have a tls_session_secret that s-hit must NOT be set since there is no indication in the serverHello as to whether the session_ticket sent by the client is accepted by the server (the sessionTicket extension is not sent by the server in EAP-FAST), and that SSL3_FLAGS_CCS_OK has to be set since the server MAY continue immediately with a changeCipherSpec. Thanks, Erik Erik Tkal et...@cisco.com mailto:et...@cisco.com ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST
I don’t disagree, but I’m looking for independent confirmation that the changes are not correct. They do not appear to specifically have been made for any vulnerabilities. In looking at RFC 5077 (the generic non-EAP-FAST scenario) section 3.1 shows that the server may send a certificate message to continue the handshake after receiving a sessionTicket from the client. With the first change I noted below the possession of a tls_session_secret now implies by the setting of s-hit on the client that the session *will* be resumed, which is not the case. The resumption requires determination of the next message. In the case of a pure sessionID resumption that is the case since the server confirms it in the serverHello, but not when using the sessionTicket extension. Erik On 17 Mar 2015, at 2:59 PM, Karthikeyan Bhargavan karthikeyan.bharga...@inria.fr wrote: I would be very careful about this code. When we ran our tests on OpenSSL (www.smacktls.com http://www.smacktls.com/), we found a bunch of issues that were narrowly prevented by a combination of flags (s-hit, SSL3_FLAGS_OK, s-s3-change_cipher_spec). Let’s carefully test any change here, so we do not re-enable CVE-2014-0224 (Early CCS Attack) On 17 Mar 2015, at 18:53, Erik Tkal etks...@gmail.com mailto:etks...@gmail.com wrote: In upgrading from 1.0.1i to 1.0.1l I found an issue in the behaviour of a non-resumed EAP-FAST session. RFC 4851 indicates that the server can go straight from the serverHello to changeCipherSpec to resume a session but can also fall back to a full handshake. With 1.0.1l the client ends up issuing an unexpected message alert if the server continues with its certificate message. I traced this to the following change: Set s-hit when resuming from external pre-shared secret. https://github.com/openssl/openssl/commit/7b3ba508af5c86afe43e28174aa3c53a0a24f4d9 https://github.com/openssl/openssl/commit/7b3ba508af5c86afe43e28174aa3c53a0a24f4d9 When processing the serverHello s-tls_session_secret_cb() is called to see if the client has a session secret, and if so the old code would set the flag that a CCS was acceptable at that point. However, the above change now also sets s-hit, which then “requires* that a finished message is expected next, triggering the alert otherwise. Also, another change is suspect in that the latest code no longer sets the flag that a CCS is acceptable at that point: Ensure SSL3_FLAGS_CCS_OK (or d1-change_cipher_spec_ok for DTLS) is reset https://github.com/openssl/openssl/commit/e94a6c0ede623960728415b68650a595e48f5a43 https://github.com/openssl/openssl/commit/e94a6c0ede623960728415b68650a595e48f5a43 In order for EAP-FAST to work it seems that if the client does have a tls_session_secret that s-hit must NOT be set since there is no indication in the serverHello as to whether the session_ticket sent by the client is accepted by the server (the sessionTicket extension is not sent by the server in EAP-FAST), and that SSL3_FLAGS_CCS_OK has to be set since the server MAY continue immediately with a changeCipherSpec. Thanks, Erik Erik Tkal et...@cisco.com mailto:et...@cisco.com ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST
In upgrading from 1.0.1i to 1.0.1l I found an issue in the behaviour of a non-resumed EAP-FAST session. RFC 4851 indicates that the server can go straight from the serverHello to changeCipherSpec to resume a session but can also fall back to a full handshake. With 1.0.1l the client ends up issuing an unexpected message alert if the server continues with its certificate message. I traced this to the following change: Set s-hit when resuming from external pre-shared secret. https://github.com/openssl/openssl/commit/7b3ba508af5c86afe43e28174aa3c53a0a24f4d9 https://github.com/openssl/openssl/commit/7b3ba508af5c86afe43e28174aa3c53a0a24f4d9 When processing the serverHello s-tls_session_secret_cb() is called to see if the client has a session secret, and if so the old code would set the flag that a CCS was acceptable at that point. However, the above change now also sets s-hit, which then “requires* that a finished message is expected next, triggering the alert otherwise. Also, another change is suspect in that the latest code no longer sets the flag that a CCS is acceptable at that point: Ensure SSL3_FLAGS_CCS_OK (or d1-change_cipher_spec_ok for DTLS) is reset https://github.com/openssl/openssl/commit/e94a6c0ede623960728415b68650a595e48f5a43 https://github.com/openssl/openssl/commit/e94a6c0ede623960728415b68650a595e48f5a43 In order for EAP-FAST to work it seems that if the client does have a tls_session_secret that s-hit must NOT be set since there is no indication in the serverHello as to whether the session_ticket sent by the client is accepted by the server (the sessionTicket extension is not sent by the server in EAP-FAST), and that SSL3_FLAGS_CCS_OK has to be set since the server MAY continue immediately with a changeCipherSpec. Thanks, Erik Erik Tkal et...@cisco.com mailto:et...@cisco.com ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: OpenSSL version 1.0.1f released
Also, the release notes list: Fix for TLS record tampering bug CVE-2013-4353 But the list of OpenSSL vulnerabilities linked from there does not mention this anywhere... Erik Tkal et...@me.com uʍop ǝpısdn ǝɹɐ noʎ sıɥʇ pɐǝɹ uɐɔ noʎ ɟı On 06 Jan 2014, at 10:27 AM, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On 01/06/2014 09:49 AM, OpenSSL wrote: OpenSSL version 1.0.1f released === [...] The OpenSSL project team is pleased to announce the release of version 1.0.1f of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.1-notes.html Looking at the source on github, i see that Nick Mathewson's no_gmt_unix_time branch was also merged between 1.0.1e and 1.0.1f, but it is not mentioned in the release notes.
Performing ECDSA signing outside of OpenSSL
For RSA and DSA signing operations I use an ENGINE that registers for RSA and DSA and intercepts the private key operations in order to call out to CAPI. I'm now trying to add support for ECDSA but the method structure for this is private. What is the expected mechanism to utilize an engine implementation for ECDSA signing? Erik Tkal Juniper OAC/UAC/Pulse Development
OpenSSL choosing inappropriate signature algorithm
Using OpenSSL 1.0.1c I notice that the client always sends the full set of supported signature algorithms in the clientHello, with no option to limit this at runtime. However, if using callbacks to choose a certificate and perform the private key operation via callback (the certificate is accessed via CAPI and may be on a smart card), a certificate may be chosen whose CSP does not allow signing using the selected algorithm. Is this a fundamental problem with the protocol? It seems the signature algorithm should be negotiated along with the client certificate selection, as opposed to forcing it up front. Or am I missing some option here? Erik Tkal Juniper OAC/UAC/Pulse Development
RE: OpenSSL choosing inappropriate signature algorithm
It appears that the clientHello only indicates overall what the client supports. The server sends another such list in its certificateRequest message. I'm trying to find where in the client code the determination is made as to which algorithm to use... Erik Tkal Juniper OAC/UAC/Pulse Development From: John Foley [mailto:fol...@cisco.com] Sent: Monday, October 22, 2012 3:02 PM To: openssl-dev@openssl.org Cc: Erik Tkal Subject: Re: OpenSSL choosing inappropriate signature algorithm Agreed. This does raise an interesting design dilemma. The client has no way to know in advance whether the server will be sending the CertificateRequest message. If the server is not doing client auth, then the client certificate will never be needed. Hence, offering all the signature algorithms in the ClientHello isn't a problem. However, as you indicated, when the server does implement client authentication, then limiting the supported signature algorithms in the ClientHello would make sense. The TLS protocol simply doesn't provide any mechanism to make the optimal decision when sending the ClientHello. It'll be interesting to hear the comments from the OpenSSL experts. On 10/22/2012 02:27 PM, Erik Tkal wrote: Using OpenSSL 1.0.1c I notice that the client always sends the full set of supported signature algorithms in the clientHello, with no option to limit this at runtime. However, if using callbacks to choose a certificate and perform the private key operation via callback (the certificate is accessed via CAPI and may be on a smart card), a certificate may be chosen whose CSP does not allow signing using the selected algorithm. Is this a fundamental problem with the protocol? It seems the signature algorithm should be negotiated along with the client certificate selection, as opposed to forcing it up front. Or am I missing some option here? Erik Tkal Juniper OAC/UAC/Pulse Development
RE: OpenSSL choosing inappropriate signature algorithm
It looks like the client sets the hash to use for each key type to the first matching algorithm sent by the server in the certificateRequest. These values are stored in a private structure with no apparent way for client code to modify this, and it seems both the client and server always send the full list regardless. So in the case where CAPI is utilized for certificate access, if OpenSSL is built to support SHA512, then that is the hash algorithm that will always be chosen, even if the CSP for the selected certificate cannot perform that function. I don't see any solution other than to manually manipulate the data in cert_st, even though that is in ssl_locl.h. Anyone have any better ideas? Erik Tkal Juniper OAC/UAC/Pulse Development From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Erik Tkal Sent: Monday, October 22, 2012 3:12 PM To: John Foley; openssl-dev@openssl.org Subject: RE: OpenSSL choosing inappropriate signature algorithm It appears that the clientHello only indicates overall what the client supports. The server sends another such list in its certificateRequest message. I'm trying to find where in the client code the determination is made as to which algorithm to use... Erik Tkal Juniper OAC/UAC/Pulse Development From: John Foley [mailto:fol...@cisco.com] Sent: Monday, October 22, 2012 3:02 PM To: openssl-dev@openssl.orgmailto:openssl-dev@openssl.org Cc: Erik Tkal Subject: Re: OpenSSL choosing inappropriate signature algorithm Agreed. This does raise an interesting design dilemma. The client has no way to know in advance whether the server will be sending the CertificateRequest message. If the server is not doing client auth, then the client certificate will never be needed. Hence, offering all the signature algorithms in the ClientHello isn't a problem. However, as you indicated, when the server does implement client authentication, then limiting the supported signature algorithms in the ClientHello would make sense. The TLS protocol simply doesn't provide any mechanism to make the optimal decision when sending the ClientHello. It'll be interesting to hear the comments from the OpenSSL experts. On 10/22/2012 02:27 PM, Erik Tkal wrote: Using OpenSSL 1.0.1c I notice that the client always sends the full set of supported signature algorithms in the clientHello, with no option to limit this at runtime. However, if using callbacks to choose a certificate and perform the private key operation via callback (the certificate is accessed via CAPI and may be on a smart card), a certificate may be chosen whose CSP does not allow signing using the selected algorithm. Is this a fundamental problem with the protocol? It seems the signature algorithm should be negotiated along with the client certificate selection, as opposed to forcing it up front. Or am I missing some option here? Erik Tkal Juniper OAC/UAC/Pulse Development
DLL naming
Is it easy/possible to tell the OpenSSL build process to name the generated DLLs (and corresponding LIBs) differently than ssleay32 and libeay32? I don't see anything obvious other than by manually renaming them after the fact (and not sure how that would affect DLLs/EXEs linking with the LIBs that then need to locate the DLL). Erik Tkal Juniper OAC/UAC/Pulse Development __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
FW: Negotiating TLS 1.0 from 1.2
Reposting in openssl-dev. Is this a bug or an oversight or an intentional
omission? Or am I just not doing something right? If I modify s3_pkt.c in
ssl3_get_record() to not fail out but to just change the version in the SSL
session then it seems to work ok.
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Erik Tkal
Sent: Wednesday, August 29, 2012 2:48 PM
To: openssl-us...@openssl.org
Subject: RE: Negotiating TLS 1.0 from 1.2
TLS 1.1 would be acceptable, but the server is 1.0 (we don't have any
implementing 1.1). The server sends a TLS 1.0 ServerHello, which per the RFC
should work:
A TLS 1.2 client who wishes to negotiate with such older servers will
send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
ClientHello.client_version. If the server does not support this
version, it will respond with a ServerHello containing an older
version number. If the client agrees to use this version, the
negotiation will proceed as appropriate for the negotiated protocol.
What I'm trying to figure out is how to tell OpenSSL that the client agrees to
use this version, whereas now it generates a fatal alert. I cannot use an
SSLv2 handshake, as this is inside EAP-TLS.
Erik Tkal
Juniper OAC/UAC/Pulse Development
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Abhiram Shandilya
Sent: Wednesday, August 29, 2012 2:38 PM
To: openssl-us...@openssl.org
Subject: RE: Negotiating TLS 1.0 from 1.2
Hi Erik:
If you only want to allow TLSv1.2 and TLSv1.0 handshakes you will need to try a
connection with the TLSv1_2_client_method and then by TLSv1_client_method. You
can also use SSLv23_client_method to negotiate only TLSv1.2 and TLSv1.0 using
an SSLv2 handshake by explicitly disabling SSLv2, SSLv3 and TLSv1.1 using
SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3|SSL_OP_NO_TLSv1_1). At
least that's my understanding.
Regards
Abhi
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Erik Tkal
Sent: Wednesday, August 29, 2012 10:47 AM
To: openssl-us...@openssl.org
Subject: Negotiating TLS 1.0 from 1.2
I have a client that I want to attempt to negotiate TLS 1.2 but will accept TLS
1.0. What is the magic incantation (e.g. TLSv1_client_method() vs
TLSv1_2_client_method() in conjunction with what options)?
Specifying TLSv1_client_method() seems to only offer TLS 1.0 {3,1}. Specifying
TLSv1_2_client_method() offers TLS 1.2 {3,3}, but then when the server returns
a TLS 1.0 {3,1} ServerHello, the client generates a Protocol Version alert.
How do I tell the client that this is acceptable? Appendix E of RFC 5246
indicates this should be possible.
I am using OpenSSL 1.0.1c.
Erik Tkal
Juniper OAC/UAC/Pulse Development
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
RE: Negotiating TLS 1.0 from 1.2
After experimenting some more I think I resolved this. It seems that
specifying SSLv23_client_method(), in conjunction with SSL_OP_NO_SSLv2 and
SSL_OP_NO_SSLv3, actually does send a TLSv1 handshake record, with {3,3} in the
ClientHello.
What confused me was that the docs for SSLv23_client_method() say A client
will send out SSLv2 client hello messages. It does not say that when you use
SSL_OP_NO_SSLv2 that it actually sends a TLS 1.0 handshake message (as long as
any TLS version is allowed but even if SSLv3 is enabled). So in my case
SSLv23_client_method() with SSL_OP_NO_SSLv2 and SSL_OP_NO_SSLv3 does the trick.
Erik Tkal
Juniper OAC/UAC/Pulse Development
-Original Message-
From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On
Behalf Of Erik Tkal
Sent: Thursday, August 30, 2012 4:02 PM
To: openssl-dev@openssl.org
Subject: FW: Negotiating TLS 1.0 from 1.2
Reposting in openssl-dev. Is this a bug or an oversight or an intentional
omission? Or am I just not doing something right? If I modify s3_pkt.c in
ssl3_get_record() to not fail out but to just change the version in the SSL
session then it seems to work ok.
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Erik Tkal
Sent: Wednesday, August 29, 2012 2:48 PM
To: openssl-us...@openssl.org
Subject: RE: Negotiating TLS 1.0 from 1.2
TLS 1.1 would be acceptable, but the server is 1.0 (we don't have any
implementing 1.1). The server sends a TLS 1.0 ServerHello, which per the RFC
should work:
A TLS 1.2 client who wishes to negotiate with such older servers will
send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
ClientHello.client_version. If the server does not support this
version, it will respond with a ServerHello containing an older
version number. If the client agrees to use this version, the
negotiation will proceed as appropriate for the negotiated protocol.
What I'm trying to figure out is how to tell OpenSSL that the client agrees to
use this version, whereas now it generates a fatal alert. I cannot use an
SSLv2 handshake, as this is inside EAP-TLS.
Erik Tkal
Juniper OAC/UAC/Pulse Development
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Abhiram Shandilya
Sent: Wednesday, August 29, 2012 2:38 PM
To: openssl-us...@openssl.org
Subject: RE: Negotiating TLS 1.0 from 1.2
Hi Erik:
If you only want to allow TLSv1.2 and TLSv1.0 handshakes you will need to try a
connection with the TLSv1_2_client_method and then by TLSv1_client_method. You
can also use SSLv23_client_method to negotiate only TLSv1.2 and TLSv1.0 using
an SSLv2 handshake by explicitly disabling SSLv2, SSLv3 and TLSv1.1 using
SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3|SSL_OP_NO_TLSv1_1). At
least that's my understanding.
Regards
Abhi
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Erik Tkal
Sent: Wednesday, August 29, 2012 10:47 AM
To: openssl-us...@openssl.org
Subject: Negotiating TLS 1.0 from 1.2
I have a client that I want to attempt to negotiate TLS 1.2 but will accept TLS
1.0. What is the magic incantation (e.g. TLSv1_client_method() vs
TLSv1_2_client_method() in conjunction with what options)?
Specifying TLSv1_client_method() seems to only offer TLS 1.0 {3,1}. Specifying
TLSv1_2_client_method() offers TLS 1.2 {3,3}, but then when the server returns
a TLS 1.0 {3,1} ServerHello, the client generates a Protocol Version alert.
How do I tell the client that this is acceptable? Appendix E of RFC 5246
indicates this should be possible.
I am using OpenSSL 1.0.1c.
Erik Tkal
Juniper OAC/UAC/Pulse Development
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
RE: [RFC] OpenSSL accepts invalid server cert chain
If the actual issuing CA is in your trust store and can be shown to have validly issued the server certificate, then by definition you trust that server. Erik Tkal Juniper OAC/UAC/Pulse Development -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of David Woodhouse Sent: Thursday, July 12, 2012 9:36 AM To: openssl-dev@openssl.org Subject: [RFC] OpenSSL accepts invalid server cert chain I have encountered a server which presents an invalid set of certificates in its TLS handshake. It's presenting four certificates, where the second cert is *not* the issuer of the first cert in the list. The chain from #2-#3-#4 is fine, but #2 isn't actually the issuer of #1. (It just happens to have the same *name* as the issuer of #1; cf. RT#1942). This violates RFC5246 §7.4.2, which says of the certificate_list that: This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. However, the missing intermediate CA *is* found in my local trust database, and OpenSSL verifies the server quite happily using *that*. This seems wrong — surely the handshake should be rejected? Should I submit a patch? I note that GnuTLS *does* reject the server's handshake — and rightly so, as far as I can tell from the RFC. -- dwmw2
RE: [openssl.org #2825] Bug: Unable to connect to WPA enterprise wireless
SBR uses OpenSSL 0.9.7e and has its own extension parsing code (0.9.7e base code just ignores anything after the base ClientHello). SBR only explicitly handles the SessionTicket extension (for EAP-FAST), all others appear to be properly skipped, and SBR certainly knows nothing about the heartbeat extension. For the case where SBR is failing it would be useful to see the data stream being sent. I have built our Odyssey Access Client with OpenSSL 1.0.1 and have not had this issue negotiating with SBR but maybe I did not explicitly try PEAP. Since this code in SBR has been present for several years and I know I've seen it ignore other extensions, perhaps it is a client side issue that enabling the heartbeat extension is having some other side effect? BCCing Robert D, you can send me logs at etkal at juniper dot net if you like and I'll take a look. Erik Erik Tkal Juniper OAC/UAC/Pulse Development -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Stephen Henson via RT Sent: Thursday, June 07, 2012 6:35 PM To: openssl...@trk.nickurak.ca Cc: openssl-dev@openssl.org Subject: [openssl.org #2825] Bug: Unable to connect to WPA enterprise wireless [openssl-dev@openssl.org - Fri Jun 08 00:27:27 2012]: This is almost identical to an issue we found with openssl 1.0.1b and Juniper SBR version v6.13.4949 In our case we traced it to the heartbeat extension. When the extension is sent in the ClientHello PEAP negotiation fails with fatal bad certificate alert. By adding # define OPENSSL_NO_HEARTBEATS to opensslconf.h we disabled the extension and PEAP negotiation is successful. There really should be an API to disable this extension so that it can be enabled in use cases where it is needed and disabled in use cases where it breaks negotiation. That's rather strange behaviour, the presence of a (presumably unsupported) extension causes a bad certificate alert? Is it just the heartbeat extension that triggers this or would the presence of any unknown extension cause a similar problem? 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: ENGINE reference leak using FIPS-capable OpenSSL
Hi Steve, thank you very much, that fixed it!
Erik
Erik Tkal
Juniper OAC/UAC/Pulse Development
-Original Message-
From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On
Behalf Of Dr. Stephen Henson
Sent: Thursday, April 19, 2012 8:10 PM
To: openssl-dev@openssl.org
Subject: Re: ENGINE reference leak using FIPS-capable OpenSSL
On Fri, Apr 20, 2012, Roumen Petrov wrote:
Dr. Stephen Henson wrote:
On Wed, Apr 18, 2012, Erik Tkal wrote:
Any takers? Should I be able to build a FIPS-capable OpenSSL and have some
of the implementation be provided via an ENGINE (e.g. let's say I have a
hardware module to perform AES) but some by the OpenSSL FIPS canister? Or
is it truly all or nothing?
Yes the FIPS capable OpenSSL should behave in a manner similar to
non-FIPS capable OpenSSL when not in FIPS mode, though it currently
use the algorithm implementations in the FIPS module even when not in FIPS
mode.
I'll look into it.
Openssl test start to fail after only call FIPS_cipherinit in FIPS
mode - 1.0.{1|2}_stable fips build:
aes-128-cbc
Error setting cipher AES-128-CBC
Error setting cipher AES-128-CBC
cmp: EOF on ./p.aes-128-cbc.clear
Ooops! This should fix it:
http://cvs.openssl.org/chngview?cn=22456
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 Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Questions re: OpenSSL Security Advisory CVE-2012-2110
The detailed analysis for CVE-2012-2110 implies issues with truncation, specifically int vs long vs size_t. Is the problem limited to platforms where these are different sizes? The analysis says not limited to I32LP64, but does not rule out any platforms where it is not an issue. Can it occur on ILP32 or ILP32LL64 platforms? Thanks! Erik Tkal Juniper OAC/UAC/Pulse Development
RE: ENGINE reference leak using FIPS-capable OpenSSL
Any takers? Should I be able to build a FIPS-capable OpenSSL and have some of
the implementation be provided via an ENGINE (e.g. let's say I have a hardware
module to perform AES) but some by the OpenSSL FIPS canister? Or is it truly
all or nothing?
Thanks.
Erik Tkal
Juniper OAC/UAC/Pulse Development
From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On
Behalf Of Erik Tkal
Sent: Monday, April 16, 2012 10:02 AM
To: openssl-dev@openssl.org
Subject: ENGINE reference leak using FIPS-capable OpenSSL
I've been investigating a memory leak in using a FIPS-capable OpenSSL in
non-FIPS mode.
For example, the following code does not seem to be correct in evp_enc.c:
int EVP_CipherInit_ex(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *cipher, ENGINE
*impl,
...
#ifndef OPENSSL_NO_ENGINE
if(impl)
{
if (!ENGINE_init(impl))
{
EVPerr(EVP_F_EVP_CIPHERINIT_EX,
EVP_R_INITIALIZATION_ERROR);
return 0;
}
}
else
/* Ask if an ENGINE is reserved for this job */
impl = ENGINE_get_cipher_engine(cipher-nid);
if(impl)
{
/* There's an ENGINE for this job ... (apparently) */
const EVP_CIPHER *c = ENGINE_get_cipher(impl, cipher-nid);
if(!c)
{
/* One positive side-effect of US's export
* control history, is that we should at least
* be able to avoid using US mispellings of
* initialisation? */
EVPerr(EVP_F_EVP_CIPHERINIT_EX,
EVP_R_INITIALIZATION_ERROR);
return 0;
}
/* We'll use the ENGINE's private cipher definition */
cipher = c;
/* Store the ENGINE functional reference so we know
* 'cipher' came from an ENGINE and we need to release
* it when done. */
ctx-engine = impl;
}
else
ctx-engine = NULL;
#endif
#ifdef OPENSSL_FIPS
return FIPS_cipherinit(ctx, cipher, key, iv, enc);
#else
So the code goes through all the motions of honoring the engine that exists and
incrementing reference counts, etc, but then blindly calls FIPS_cipherinit(),
which ends up removing the engine pointer from the context. I see in some
cases this behaviour, yet in others the call is wrapped with a test for FIPS
mode. E.g.:
int EVP_DigestInit_ex(EVP_MD_CTX *ctx, const EVP_MD *type, ENGINE *impl)
...
#ifdef OPENSSL_FIPS
if (FIPS_mode())
{
if (FIPS_digestinit(ctx, type))
return 1;
OPENSSL_free(ctx-md_data);
ctx-md_data = NULL;
return 0;
}
#endif
return ctx-digest-init(ctx);
}
Note that the Update call however has:
int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *data, size_t count)
{
#ifdef OPENSSL_FIPS
return FIPS_digestupdate(ctx, data, count);
#else
return ctx-update(ctx,data,count);
#endif
}
Should *all* calls be protected with a test for FIPS_mode()? Or is it
documented that a FIPS-capable OpenSSL is not compatible with the usage of
engines, even in non-FIPS mode?
Erik Tkal
Juniper OAC/UAC/Pulse Development
ENGINE reference leak using FIPS-capable OpenSSL
I've been investigating a memory leak in using a FIPS-capable OpenSSL in
non-FIPS mode.
For example, the following code does not seem to be correct in evp_enc.c:
int EVP_CipherInit_ex(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *cipher, ENGINE
*impl,
...
#ifndef OPENSSL_NO_ENGINE
if(impl)
{
if (!ENGINE_init(impl))
{
EVPerr(EVP_F_EVP_CIPHERINIT_EX,
EVP_R_INITIALIZATION_ERROR);
return 0;
}
}
else
/* Ask if an ENGINE is reserved for this job */
impl = ENGINE_get_cipher_engine(cipher-nid);
if(impl)
{
/* There's an ENGINE for this job ... (apparently) */
const EVP_CIPHER *c = ENGINE_get_cipher(impl, cipher-nid);
if(!c)
{
/* One positive side-effect of US's export
* control history, is that we should at least
* be able to avoid using US mispellings of
* initialisation? */
EVPerr(EVP_F_EVP_CIPHERINIT_EX,
EVP_R_INITIALIZATION_ERROR);
return 0;
}
/* We'll use the ENGINE's private cipher definition */
cipher = c;
/* Store the ENGINE functional reference so we know
* 'cipher' came from an ENGINE and we need to release
* it when done. */
ctx-engine = impl;
}
else
ctx-engine = NULL;
#endif
#ifdef OPENSSL_FIPS
return FIPS_cipherinit(ctx, cipher, key, iv, enc);
#else
So the code goes through all the motions of honoring the engine that exists and
incrementing reference counts, etc, but then blindly calls FIPS_cipherinit(),
which ends up removing the engine pointer from the context. I see in some
cases this behaviour, yet in others the call is wrapped with a test for FIPS
mode. E.g.:
int EVP_DigestInit_ex(EVP_MD_CTX *ctx, const EVP_MD *type, ENGINE *impl)
...
#ifdef OPENSSL_FIPS
if (FIPS_mode())
{
if (FIPS_digestinit(ctx, type))
return 1;
OPENSSL_free(ctx-md_data);
ctx-md_data = NULL;
return 0;
}
#endif
return ctx-digest-init(ctx);
}
Note that the Update call however has:
int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *data, size_t count)
{
#ifdef OPENSSL_FIPS
return FIPS_digestupdate(ctx, data, count);
#else
return ctx-update(ctx,data,count);
#endif
}
Should *all* calls be protected with a test for FIPS_mode()? Or is it
documented that a FIPS-capable OpenSSL is not compatible with the usage of
engines, even in non-FIPS mode?
Erik Tkal
Juniper OAC/UAC/Pulse Development
ENGINE reference leak using EVP_Digest*
I have some code that uses the following sequence of calls (e.g.): EVP_MD_CTX ctx; EVP_MD_CTX_init(ctx); EVP_DigestInit_ex(ctx, EVP_sha1, NULL); EVP_DigestUpdate(ctx, pData, nSize); EVP_DigestFinal_ex(ctx, pOut, NULL); EVP_DigestInit_ex(ctx, EVP_sha1, NULL); EVP_DigestUpdate(ctx, pData, nSize); EVP_DigestFinal_ex(ctx, pOut, NULL); EVP_DigestInit_ex(ctx, EVP_sha1, NULL); EVP_DigestUpdate(ctx, pData, nSize); EVP_DigestFinal_ex(ctx, pOut, NULL); EVP_MD_CTX_cleanup(ctx); The docs say that After calling EVP_DigestFinal_ex() no additional calls to EVP_DigestUpdate() can be made, but EVP_DigestInit_ex() can be called to initialize a new digest operation. In my case, there is an ENGINE registered to perform the SHA1 operations. What happens, though is that EVP_DigestInit_ex() increments the ENGINE reference, but EVP_DigestFinal_ex() does not decrement it. Only the EVP_MD_CTX_cleanup() call is decrementing the reference count, and thus my ENGINE never ends up being actually freed on the ENGINE_finish() call. Is this a known issue? Do I really need to cleanup/reinit my CTX around each hash sequence? Erik Tkal Juniper OAC/UAC/Pulse Development
RE: ENGINE reference leak using EVP_Digest*
BTW, this is with OpenSSL 1.0.1; I did not try an older version. Sent: Tuesday, March 27, 2012 10:20 AM To: openssl-dev@openssl.org Subject: ENGINE reference leak using EVP_Digest* I have some code that uses the following sequence of calls (e.g.): EVP_MD_CTX ctx; EVP_MD_CTX_init(ctx); EVP_DigestInit_ex(ctx, EVP_sha1(), NULL); EVP_DigestUpdate(ctx, pData, nSize); EVP_DigestFinal_ex(ctx, pOut, NULL); EVP_DigestInit_ex(ctx, EVP_sha1(), NULL); EVP_DigestUpdate(ctx, pData, nSize); EVP_DigestFinal_ex(ctx, pOut, NULL); EVP_DigestInit_ex(ctx, EVP_sha1(), NULL); EVP_DigestUpdate(ctx, pData, nSize); EVP_DigestFinal_ex(ctx, pOut, NULL); EVP_MD_CTX_cleanup(ctx); The docs say that After calling EVP_DigestFinal_ex() no additional calls to EVP_DigestUpdate() can be made, but EVP_DigestInit_ex() can be called to initialize a new digest operation. In my case, there is an ENGINE registered to perform the SHA1 operations. What happens, though is that EVP_DigestInit_ex() increments the ENGINE reference, but EVP_DigestFinal_ex() does not decrement it. Only the EVP_MD_CTX_cleanup() call is decrementing the reference count, and thus my ENGINE never ends up being actually freed on the ENGINE_finish() call. Is this a known issue? Do I really need to cleanup/reinit my CTX around each hash sequence? Erik Tkal Juniper OAC/UAC/Pulse Development
RE: ENGINE reference leak using EVP_Digest*
In addition, I find that EVP_DigestInit_ex ends up bumping the reference count
*twice*...
In eng_table.c:
/* Try to initialise the ENGINE? */
if((ret-funct_ref 0) || !(table_flags ENGINE_TABLE_FLAG_NOINIT))
initres = engine_unlocked_init(ret);
else
initres = 0;
if(initres)
{
/* Update 'funct' */
if((fnd-funct != ret) engine_unlocked_init(ret))
{
/* If there was a previous default we release it. */
if(fnd-funct)
engine_unlocked_finish(fnd-funct, 0);
To clarify the version, it's 1.0.1 built as FIPS-capable, but OpenSSL FIPS is
not enabled during this usage.
Erik Tkal
Juniper OAC/UAC/Pulse Development
Sent: Tuesday, March 27, 2012 10:45 AM
To: openssl-dev@openssl.org
Subject: RE: ENGINE reference leak using EVP_Digest*
BTW, this is with OpenSSL 1.0.1; I did not try an older version.
Sent: Tuesday, March 27, 2012 10:20 AM
To: openssl-dev@openssl.orgmailto:openssl-dev@openssl.org
Subject: ENGINE reference leak using EVP_Digest*
I have some code that uses the following sequence of calls (e.g.):
EVP_MD_CTX ctx;
EVP_MD_CTX_init(ctx);
EVP_DigestInit_ex(ctx, EVP_sha1(), NULL);
EVP_DigestUpdate(ctx, pData, nSize);
EVP_DigestFinal_ex(ctx, pOut, NULL);
EVP_DigestInit_ex(ctx, EVP_sha1(), NULL);
EVP_DigestUpdate(ctx, pData, nSize);
EVP_DigestFinal_ex(ctx, pOut, NULL);
EVP_DigestInit_ex(ctx, EVP_sha1(), NULL);
EVP_DigestUpdate(ctx, pData, nSize);
EVP_DigestFinal_ex(ctx, pOut, NULL);
EVP_MD_CTX_cleanup(ctx);
The docs say that After calling EVP_DigestFinal_ex() no additional calls to
EVP_DigestUpdate() can be made, but EVP_DigestInit_ex() can be called to
initialize a new digest operation.
In my case, there is an ENGINE registered to perform the SHA1 operations.
What happens, though is that EVP_DigestInit_ex() increments the ENGINE
reference, but EVP_DigestFinal_ex() does not decrement it. Only the
EVP_MD_CTX_cleanup() call is decrementing the reference count, and thus my
ENGINE never ends up being actually freed on the ENGINE_finish() call.
Is this a known issue? Do I really need to cleanup/reinit my CTX around each
hash sequence?
Erik Tkal
Juniper OAC/UAC/Pulse Development
Re: Limiting EC curves in ClientHello
I looked around and found RFC 5430 - Suite B Profile for Transport Layer Security (TLS), which states: RFC 4492 defines a variety of elliptic curves. For cipher suites defined in this specification, only secp256r1(23) or secp384r1(24) may be used. … Clients desiring to negotiate only a Suite B compliant connection MUST generate a Supported Elliptic Curves Extension containing only the allowed curves. So does this mean that OpenSSL will not support RFC 5430 / Suite B in 1.0.1? Thanks, Erik From: Bodo Moeller bmoel...@acm.orgmailto:bmoel...@acm.org Reply-To: openssl-dev@openssl.orgmailto:openssl-dev@openssl.org openssl-dev@openssl.orgmailto:openssl-dev@openssl.org Date: Wed, 29 Feb 2012 18:52:11 -0500 To: openssl-dev@openssl.orgmailto:openssl-dev@openssl.org openssl-dev@openssl.orgmailto:openssl-dev@openssl.org Subject: Re: Limiting EC curves in ClientHello It appears there is no way to specify that only a subset should be used? Yes, this is a know deficiency in the current code. I'm more familiar with the server side, but I think it's similar: if you set up *one* curve, then negotiation should happen accordingly; if you use a callback to provide curves, it will be expected to be able to handle any curve, which is fundamentally broken (a peer could be using a named curve that's not even defined yet). So technically, there is a way to specific that only a subset should be used -- it's just that the subset needs to be of size 0 or 1, which isn't utterly flexible. We should get around to fixing that at some point. Bodo __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Need EAP-FAST support in 0.9.8 openssl
I think the changes to support the session ticket extension and session secret callback were not trivial, and such features would never be ported back to previous releases (unless it addressed a security vulnerability). I migrated my code to use 1.0.0 in order to take advantage of this (previously we had a heavily modified 0.9.7 that added basically the same functionality). Erik From: Muneer pasha munirpa...@gmail.commailto:munirpa...@gmail.com Reply-To: openssl-dev@openssl.orgmailto:openssl-dev@openssl.org openssl-dev@openssl.orgmailto:openssl-dev@openssl.org Date: Thu, 1 Mar 2012 02:17:19 -0500 To: openssl-dev@openssl.orgmailto:openssl-dev@openssl.org openssl-dev@openssl.orgmailto:openssl-dev@openssl.org Subject: Need EAP-FAST support in 0.9.8 openssl Hi, The changes to support EAP-FAST is included in changes between 0.9.8n and 1.0.0. Can this change be made available also in 0.9.8 tree? Thanks, Muneer __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: Limiting EC curves in ClientHello
You mentioned previously that you can get it to specify none or one curve? I don't see how you would specify this, as it appears the client hello preparation adds all of them is any EC cipher suite is specified? Erik Tkal Juniper OAC/UAC/Pulse Development From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Bodo Moeller Sent: Thursday, March 01, 2012 11:52 AM To: openssl-dev@openssl.org Subject: Re: Limiting EC curves in ClientHello On Thu, Mar 1, 2012 at 11:16 AM, Erik Tkal et...@juniper.netmailto:et...@juniper.net wrote: I looked around and found RFC 5430 - Suite B Profile for Transport Layer Security (TLS), which states: RFC 4492 defines a variety of elliptic curves. For cipher suites defined in this specification, only secp256r1(23) or secp384r1(24) may be used. ... Clients desiring to negotiate only a Suite B compliant connection MUST generate a Supported Elliptic Curves Extension containing only the allowed curves. So does this mean that OpenSSL will not support RFC 5430 / Suite B in 1.0.1? RFC 5430 specifies that A Suite B compliant TLS server MUST be configured to support the 128-bit security level, the 192-bit security level, or both security levels. OpenSSL can be configured for the 128-bit security level (using secp256r1) or for the 192-bit security level (using secp384r1), but it currently can't be configured to cleanly support both. (The section from which you quoted also says that Clients that are willing to do both Suite B compliant and non-Suite B compliant connections MAY omit the extension or send the extension but offer other curves as well as the appropriate Suite B ones. I don't think that supporting Suite B means that you can't also allow non-Suite B compliant connections, with clients that don't support Suite B.) So without having checked all of the formal requirements, I think that OpenSSL 1.0.1 will support Suite B as specified by RFC 5430, even though there's not yet a good way to enable two or more explicitly chosen elliptic curves while disabling all the others. Bodo
Re: Limiting EC curves in ClientHello
So then the question is will this be addressed in 1.0.1 or later? Erik Tkal et...@me.com On Mar 1, 2012, at 5:35 PM, Bodo Moeller wrote: On Thu, Mar 1, 2012 at 4:06 PM, Erik Tkal et...@juniper.net wrote: You mentioned previously that you can get it to specify none or one curve? I don’t see how you would specify this, as it appears the client hello preparation adds all of them is any EC cipher suite is specified? Oh, sorry, you are right. Setting up negotiation for one specific curve is possible for the *server*-side implementation, but the *client*-side code isn't even quite there yet. Bodo
Limiting EC curves in ClientHello
In t1_lib.c if any EC Cipher Suites are specified then TLS extensions are generated that indicate the client supports all three point compression formats and all 25 curves (I noticed the order changes between 1.0.0 and 1.0.1). It appears there is no way to specify that only a subset should be used? E.g. doesn't Suite B specify two specific ones? Or does Suite B really mean the application MUST implement those two but that any of them are acceptable? Are they all FIPS compliant? Would there be any reason for the client (or server) to restrict these? Also, are there any good references on the relationship between the certificate and usable cipher suites, especially regarding the usage of EC suites with non-EC certs or vice versa? Thanks, Erik __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
FIPS Module 2.0 -- using non-FIPS ciphers
I am experimenting with the OpenSSL FIPS Module 2.0, but am encountering some
difficulty.
I need to perform some RC4 calculations in code that does not need to be FIPS
compliant, even though I want all FIPS ciphers to be performed in FIPS mode.
I'm trying to use the EVP_CIPH_FLAG_NON_FIPS_ALLOW flag, but no matter what I
do it is ignored. If I set the flag via
EVP_CIPHER_CTX_set_flags(m_ctx, EVP_CIPH_FLAG_NON_FIPS_ALLOW);
then calling
EVP_CipherInit(m_ctx, EVP_rc4(), NULL, NULL, 1);
first wipes out my context via the following in evp_enc.c:
int EVP_CipherInit(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *cipher,
const unsigned char *key, const unsigned char *iv, int enc)
{
if (cipher)
EVP_CIPHER_CTX_init(ctx);
return EVP_CipherInit_ex(ctx,cipher,NULL,key,iv,enc);
}
Even if I use the _ex version to avoid this
EVP_CipherInit_ex(m_ctx, EVP_rc4(), NULL, NULL, NULL, 1);
then the following code in evp_enc.c / EVP_CipherInit_ex() also ends up wiping
the flags out:
if (cipher)
{
/* Ensure a context left lying around from last time is cleared
* (the previous check attempted to avoid this if the same
* ENGINE and EVP_CIPHER could be used). */
EVP_CIPHER_CTX_cleanup(ctx);
Since all paths seem to cause the code to wipe out my
EVP_CIPH_FLAG_NON_FIPS_ALLOW flags setting before the call to
FIPS_cipherinit(ctx, cipher, key, iv, enc) gets a chance to test it in order to
allow it, what is the proper mechanism for creating an EVP_CIPHER usage that
will be allowed in FIPS mode?
Thanks,
Erik
Erik Tkal
Juniper OAC/UAC/Pulse Development
RE: FIPS Module 2.0 -- using non-FIPS ciphers
Yes, I understand all that; we currently have our own certified FIPS module that I wired into OpenSSL via the engine APIs. Assuming that the module boundary is the code in the FIPS canister, I want that module to perform all FIPS-compliant operations, but still need the outer OpenSSL to perform other operations. For example, authentication with EAP-TTLS can use weaker inner authentication protected by the stronger outer tunnel. MS-CHAPv2, e.g. uses NT password hashing. It seems the purpose of these NON_FIPS_ALLOW flags is for exactly this reason - that a developer can decide what is allowable for a FIPS-capable OpenSSL in FIPS mode based on the context of the actual crypto operations relative to what is required to be truly FIPS compliant. It just seems in this case that the implementation is not correct in order to allow this (the FIPS_cipherinit in fipscanister checks this flag, but the FIPS-capable implementation around it happens to clear the flag before it can be analyzed). Erik Tkal Juniper OAC/UAC/Pulse Development -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Thor Lancelot Simon Sent: Friday, February 10, 2012 9:52 AM To: openssl-dev@openssl.org Subject: Re: FIPS Module 2.0 -- using non-FIPS ciphers On Fri, Feb 10, 2012 at 09:39:20AM -0500, Erik Tkal wrote: I am experimenting with the OpenSSL FIPS Module 2.0, but am encountering some difficulty. I need to perform some RC4 calculations in code that does not need to be FIPS compliant, even though I want all FIPS ciphers to be performed in FIPS mode. You should talk to whoever wrote the security policy for your device or application. To do this without compromising your FIPS validation, you likely need to move the code in question -- the code that uses a non-FIPS cipher -- outside the module boundary. It is probably a good rule of thumb that if symbols in the same instance of the OpenSSL library used within the boundary are visible to your code that is using a non-Approved algorithm, the code using the non-Approved algorithm is (improperly) within the module boundary. If you move the code outside the module boundary, you should be able to link it to a different copy of OpenSSL, and the problem should go away. I suppose you might be using RC4 to generate initialization vectors. I cannot remember whether that is allowed. If it is, you likely need a constrained, standalone RC4 implementation (which would only be about 10 lines of code) that you can prove to the test lab validating your device or application is actually never used (or not usable) for any purpose other than IV generation. If you are relying on OpenSSL's certificate in order to claim FIPS 140 compliance for your application or device, it is definitely improper to have other implementations of cryptographic algorithms floating around unless you can clearly establish (and advertise) that they are part of a separate application which is _not_ FIPS 140 compliant. Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: FIPS Module 2.0 -- using non-FIPS ciphers
I'm just saying that there are options to allow this and it just doesn't seem to work. #define EVP_MD_CTX_FLAG_NON_FIPS_ALLOW 0x0008 /* Allow use of non FIPS digest * in FIPS mode */ /* Allow non FIPS cipher in FIPS mode */ #define EVP_CIPH_FLAG_NON_FIPS_ALLOW0x8000 Obviously the EVP_MD_CTX_FLAG_NON_FIPS_ALLOW flag handling works, since the SSL/TLS processing uses this to allow MD5 during the handshake. Erik -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Thor Lancelot Simon Sent: Friday, February 10, 2012 10:08 AM To: openssl-dev@openssl.org Subject: Re: FIPS Module 2.0 -- using non-FIPS ciphers On Fri, Feb 10, 2012 at 10:01:43AM -0500, Erik Tkal wrote: Yes, I understand all that; we currently have our own certified FIPS module that I wired into OpenSSL via the engine APIs. Assuming that the module boundary is the code in the FIPS canister, I want that module to perform all FIPS-compliant operations, but still need the outer OpenSSL to perform other operations. Personally, I think if they're in the same address space (or, at least, namespace) this is dubious. But you probably have people advising you (or available to advise you) who know a lot better than I do! Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: FIPS Module 2.0 -- using non-FIPS ciphers
Hi Steve, thanks. This also seems to be a general issue with setting other
fields in the context, for example to override the key length (even in non-FIPS
mode) you have to initialize the cipher context with the cipher, then set the
fields in the context, then reinitialize it without specifying the cipher (I
found via googling that you had to do this):
EVP_CIPHER_CTX_init(m_ctx);
EVP_CipherInit_ex(m_ctx, EVP_rc4(), NULL, NULL, NULL, 1); // first
time don't pass key
EVP_CIPHER_CTX_set_key_length(m_ctx, (int)nKeySize); // specify
key length
EVP_CipherInit_ex(m_ctx, NULL, NULL, pKey, NULL, 1); // now set
the key
Ideally one should be able to omit the extra step, since I thought one of the
points of the _ex form was to assume the CTX is already set up?
EVP_CIPHER_CTX_init(m_ctx);
EVP_CIPHER_CTX_set_key_length(m_ctx, (int)nKeySize);
EVP_CipherInit_ex(m_ctx, EVP_rc4(), NULL, pKey, NULL, 1);
I think the following in evp_enc.c at line 123 might work to only clean up the
CTX if you were specifying a cipher and one was already present:
if (cipher)
{
/* Ensure a context left lying around from last time is cleared
* (the previous check attempted to avoid this if the same
* ENGINE and EVP_CIPHER could be used). */
+++if (ctx-cipher)
EVP_CIPHER_CTX_cleanup(ctx);
Thanks,
Erik
Erik Tkal
Juniper OAC/UAC/Pulse Development
-Original Message-
From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On
Behalf Of Dr. Stephen Henson
Sent: Friday, February 10, 2012 11:15 AM
To: openssl-dev@openssl.org
Subject: Re: FIPS Module 2.0 -- using non-FIPS ciphers
On Fri, Feb 10, 2012, Erik Tkal wrote:
I'm just saying that there are options to allow this and it just doesn't seem
to work.
#define EVP_MD_CTX_FLAG_NON_FIPS_ALLOW0x0008 /* Allow use of non
FIPS digest
* in FIPS mode */
/* Allow non FIPS cipher in FIPS mode */
#define EVP_CIPH_FLAG_NON_FIPS_ALLOW0x8000
Obviously the EVP_MD_CTX_FLAG_NON_FIPS_ALLOW flag handling works, since the
SSL/TLS processing uses this to allow MD5 during the handshake.
That's a bug. Looking into a fix.
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 Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
RE: [openssl.org #2707] Build failure
Hi Ajit, It's not clear whether you need FIPS support or not, but it looks like you are attempting to build a FIPS-capable 1.0.1. When you pass the fips configuration flag that causes fipssyms.h to override the entry point names in order to link with the ones built into fipscanister. Either you need to build the fipscanister as Steve indicated, or not build 1.0.1 with the fips flag. I cannot say whether the DRBG functionality can easily be backported to 0.9.8, as that is two releases back and internal API changes might require an effort to do that. Is there a reason you would not move to 1.0.1 once available? Erik Tkal Juniper OAC/UAC/Pulse Development -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Ajit Sarnaik via RT Sent: Wednesday, February 08, 2012 11:55 AM Cc: openssl-dev@openssl.org Subject: RE: [openssl.org #2707] Build failure Hello Steve, Thanks for the quick response. Are the functions auto-generated? We are using 0.9.8 at present and wanted to incorporate DRBG support into it, that is why I was trying to compile some of the DRBG files, when I encountered the problem and was looking for the function body. Can you point me to the functions please. Regards, Ajit X4146 -Original Message- From: Stephen Henson via RT [mailto:r...@openssl.org] Sent: Wednesday, February 08, 2012 5:28 AM To: Ajit Sarnaik Cc: openssl-dev@openssl.org Subject: [openssl.org #2707] Build failure [asarn...@paloaltonetworks.com - Wed Feb 08 10:21:27 2012]: Hello, I have been trying to build openssl from the source tar ball that I down loaded from the web site. Noticed a bug in one of the perl scripts. Below is the context diff. Encountering undefined symbols from the file fips/utl/fips_enc.c with respect to functions used in FIPS_get_cipherbynid. A few of the symbols are listed below, ../libcrypto.so: undefined reference to `FIPS_evp_aes_128_cfb128' ../libcrypto.so: undefined reference to `FIPS_evp_aes_192_cfb128' ../libcrypto.so: undefined reference to `FIPS_evp_aes_256_xts' ../libcrypto.so: undefined reference to `FIPS_evp_aes_128_cfb1' ../libcrypto.so: undefined reference to `FIPS_evp_aes_192_ccm' ../libcrypto.so: undefined reference to `FIPS_evp_des_ede_cbc' ../libcrypto.so: undefined reference to `FIPS_evp_des_ede_ofb' ../libcrypto.so: undefined reference to `FIPS_evp_aes_192_ctr' ../libcrypto.so: undefined reference to `FIPS_evp_aes_192_ecb' Are these functions auto-generated please. The functions are part of the test 2.0 FIPS module. You need to build and install it from a fips snapshot and follow the instructions in README.FIPS to generate a FIPS capable OpenSSL 1.0.1 if that is what you want to do. Has DRBG been ported to openssl-09.9.8 please. If not are there any plans on doing that? It wont happen as new features cannot be added to stable branches. 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: API to set rekey limit?
I think BIO_set_ssl_renegotiate_bytes should do what you are asking (assuming you enable SSL renegotiation). You could also trigger the renegotiation via your application using SSL_renegotiate. Erik Tkal Juniper OAC/UAC/Pulse Development -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of no_spam...@yahoo.com Sent: Saturday, December 03, 2011 2:11 PM To: openssl-dev@openssl.org Subject: API to set rekey limit? Hello. Is there an API call to configure a SSL session such that it will initiate a rekey after n number of bytes? Or is it always set to a fixed amount based on the length of the key? (I believe it is 2^(L/4) where L is the length of the key.) Thank you. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
memory leak in engine cleanup
I have an engine implementation that overrides some basic functionality (RAND, RSA, DSA). However, after calling ENGINE_Cleanup() I notice I have memory leak. The stack has ENGINE_Cleanup() calling up to the following: CRYPTO_free_ex_data(CRYPTO_EX_INDEX_ENGINE, e, e-ex_data); which then ends up in the static int_free_ex_data function, which sets: item = def_get_class(class_index) where def_get_class returns the result of: OPENSSL_malloc(sizeof(EX_CLASS_ITEM)); However, in int_free_ex_data, item is never freed. I do not use ex_data in my engine, so is this a bug in OpenSSL, or is there something I need to do to make this behave properly? Thanks! Erik Tkal Juniper OAC/UAC/Pulse Development
RE: memory leak in engine cleanup
Never mind, a little more experimentation answered my question. I was unloading the engine after calling CRYPTO_cleanup_all_ex_data, so the engine unload must leave some global ex stuff that is handled later. Erik Tkal Juniper OAC/UAC/Pulse Development From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Erik Tkal Sent: Wednesday, November 30, 2011 2:12 PM To: openssl-dev@openssl.org Subject: memory leak in engine cleanup I have an engine implementation that overrides some basic functionality (RAND, RSA, DSA). However, after calling ENGINE_Cleanup() I notice I have memory leak. The stack has ENGINE_Cleanup() calling up to the following: CRYPTO_free_ex_data(CRYPTO_EX_INDEX_ENGINE, e, e-ex_data); which then ends up in the static int_free_ex_data function, which sets: item = def_get_class(class_index) where def_get_class returns the result of: OPENSSL_malloc(sizeof(EX_CLASS_ITEM)); However, in int_free_ex_data, item is never freed. I do not use ex_data in my engine, so is this a bug in OpenSSL, or is there something I need to do to make this behave properly? Thanks! Erik Tkal Juniper OAC/UAC/Pulse Development
RE: FWD: Enhancement Request: 64bit BIO API
Hi Andy, The specific concern is that (e.g.) the BIO seek and tell operations use long for parameters, which on some 64-bit systems is still 32 bits. They need to use size_t or a specific 64-bit type. Erik Erik Tkal Juniper OAC/UAC/Pulse Development -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Andy Polyakov Sent: Thursday, October 21, 2010 1:19 PM To: openssl-dev@openssl.org Subject: Re: FWD: Enhancement Request: 64bit BIO API [...] Are we talking about file BIO? It should be 64-bit on 64-bit [Unix] platforms. Should be refers to the fact that I've looked at it some point and reckoned that it is and as far as 32-bit platforms go best one can do is to ensure that large files can be accessed sequentially (see comment in bss_file.c). [Unix] refers to the fact that it would be a problem on Win64, because long is 32 bits wide and it's problematic to pass 64-bit values in file_ctrl, pass by value. In other words what is specific concern? A. -- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2194] Unwanted dependencies to user32.dll
Doesn't UuidCreate create a dependency to rpcrt4.dll then? Erik Tkal Juniper OAC/UAC/Pulse Development -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Kees Dekker via RT Sent: Thursday, September 16, 2010 8:46 AM Cc: openssl-dev@openssl.org Subject: RE: [openssl.org #2194] Unwanted dependencies to user32.dll Just one idea, which popped up today. What about of using UuidCreate() function, see: http://msdn.microsoft.com/en-us/library/aa379205(VS.85).aspx In our case, our software runs as a service, in its own desktop/winstation. That desktop does not have a bitmap at all, or if it has one, it is always identical. You may like to use UuidCreate() to generate a unique/random number, not dependent on user32.dll/gdi32.dll. Regards, Kees -Original Message- From: Kees Dekker Sent: Monday, 12 April, 2010 12:27 To: 'r...@openssl.org' Cc: openssl-dev@openssl.org Subject: RE: [openssl.org #2194] Unwanted dependencies to user32.dll -Original Message- From: Andy Polyakov via RT [mailto:r...@openssl.org] Sent: Monday, April 12, 2010 12:08 To: Kees Dekker Cc: openssl-dev@openssl.org Subject: Re: [openssl.org #2194] Unwanted dependencies to user32.dll May be there is another method to check wether a windows process is a service, without using user32.dll. As mentioned one can do it with Native NT API, but it's quite special and belongs rather in [your] application than in openssl. Yes and no. As soon as there is any openSSL code, using APIs from user32.dll, my application still have a dependency to user32.dll. Once again, if you /delayload user32 and never make the call, you're safe. OpenSSL never calls RAND_screen, your application can, make sure it doesn't. OPENSSL_isservice doesn't make user32.dll calls if you redirect stderr. If called as service start your application with redirected stderr. The function app_RAND_load_file() calls RAND_screen. And app_RAND_load_file() is called from many places. app_RAND_load_file is in openssl.exe application. Do you invoke openssl.exe from your application??? I was under impression that *your* application is *linked* with OpenSSL *library*... So that when I referred to OpenSSL I referred to the *library*, not openssl.exe. Or you might compile one of apps/*.c modules with your application. In which case http://cvs.openssl.org/chngview?cn=19557 would still do the trick... You are right. I cannot oversee whether OpenSSL (library) really Never calls this function. Most probably, the library will not. When I said it doesn't call it there was no probably. This implies that you a) take my word for it; b) verify the statement and tell that it's wrong in case it is. In latter case, if the statement will be proven wrong, it will be considered as bug and will be fixed. But there is nothing one can do about I cannot oversee. I only use the static lib. Rules of conversation imply that you either try to refute the statement or confirm it. As opposite to ignoring it and tell what would you *like* to do over and over:-):-):-) Ok you can close this request. It was not intended by me to move the 'difficult part' to openSSL. I only suggested - if the code was not used by OpenSSL at all, like you said - just to put it within #ifdef NEED_OLD_FUNCTIONALITY or so. ??? RAND_screen would be the *only* candidate for NEED_OLD_FUNCTIONALITY, but it's not the only place where user32 calls are made... Only one or two others left, or am I wrong? The problem with delayed loading of user32.dll is that developers of our code **can** use user32.dll functionality, while I prefer to forbid it, i.e. explicitly disable linking to user32.dll. What are the means of forbidding? Not having user32.lib on link command line you tell developers to use? How do you link with openssl library? Statically or dynamically? If statically, then add stub module of own design with handful of empty functions called by OpenSSL library and exclude gdi32/user32 from link command line. Or consider switching to dynamic link, i.e. with OpenSSL *dlls*, because if linked dynamically, then you don't need user32.lib on *your* link command line at all. Statically. Dynamic linking has its own merits. I will try what I can do in this region. However, it is ok to close this request. I would like not to use user32.dll at all in our code. Then don't. Just demand discipline from your developers. Tell them why it's important, they'll understand. From development/compile/link perspective there is no difference in using user32.lib/dll with regular flags, or with delayed load flags. By using delayed loading, the risc is high that user32.dll is used (either by accident, or by intention of one of our developers). What is real risk/concern here? That product is shipped to end
FW: No CAs in CertificateRequest message
Can anyone answer this? How do I tell if this is a known problem with OpenSSL or if
the RFC is incorrect, or if this is just a accepted deviation?
Erik Tkal
Principal Software Engineer
Funk Software, Inc.
[EMAIL PROTECTED] 978-371-3980x123
Out the Token Ring, through the router, down the fiber, off
a switch, past the firewall, down the T1 ... nothing but Net.
---
A customer performing interoperability testing sent me a message and indicated that
our TLS server was sending a CertificateRequest message with a CAs length of 0,
followed by no additional data. This appears to be in violation of section 7.4.4 of
RFC 2246, which implies that the certificate_authorities must be at least 3 bytes.
struct {
ClientCertificateType certificate_types1..2^8-1;
DistinguishedName certificate_authorities3..2^16-1;
} CertificateRequest;
Is this a bug, and if so, what is the correct way to indicate that you do not wish to
hint to the client what CAs to use in selecting a certificate?
BTW, I tried changing the server code to send a 2-byte CAs length of 3, followed by a
2-byte CA1 length of 1, followed by a null byte, but the client didn't like that at
all.
Erik Tkal
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
RE: No CAs in CertificateRequest message
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Levitte - VMS Whacker on Thu, 6 May 2004 08:24:57 -0400, Erik Tkal said: etssl Can anyone answer this? How do I tell if this is a known etssl problem with OpenSSL or if the RFC is incorrect, or if this is etssl just a accepted deviation? I can't really say, as that's not my forte in OpenSSL, so what I say is just a guess. There are several places in OpenSSL (some ASN.1 stuff among others, IIRC) where the standards aren't entirely followed to the letter (you could say that the standards have been expanded a little bit, to be kind), so as not to break with some other software (I think Microsoft is often mentioned at this point...) that deviates from standards a little bit. My guess is that this possibility to generate an empty list of ceritificate requests may be that kind of deviation. I would love it if those in the team that really know the SSL parts could give an accurate response... - Richard, Thanks, that is what I suspect. And that's exactly why I posted it here in openssl-dev, hoping someone who actually works on the code could give a definitive answer. I don't know where else to determine this. Erik Tkal __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: No CAs in CertificateRequest message
Jeff, Look ins3_srvr.c - ssl3_send_certificate_requestcalls SSL_get_client_CA_list to get the stack of CA names(assumedly set by other code having called SSL_set_client_CA_list). However, if the server side code has not set this then the stack is empty, so the code ends up setting the 2-byte length field to 0x and appending no further data to the message. So the questions that remain are: 1) Is this ok and should clients be required to handle this, and if so where is this documented? 2) If it is required for the server implementation to call SSL_set_client_CA_list, shouldan error be surfaced at some point when this is detected? 3) If a server implementation is to call SSL_set_client_CA_list how should it specify that it does not care what the client sends (assuming it will check against trusted roots later)? I could contend that a server implementation may not want to give such hints to a client and assume that clients it trusts will present proper credentials based on proper configuration. Erik Tkal From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey AltmanSubject: Re: No CAs in CertificateRequest message Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Thu, 6 May 2004 08:24:57 -0400, "Erik Tkal" said: etssl Can anyone answer this? How do I tell if this is a known etssl problem with OpenSSL or if the RFC is incorrect, or if this is etssl just a accepted deviation? I can't really say, as that's not my forte in OpenSSL, so what I say is just a guess. There are several places in OpenSSL (some ASN.1 stuff among others, IIRC) where the standards aren't entirely followed to the letter (you could say that the standards have been expanded a little bit, to be kind), so as not to break with some other software (I think Microsoft is often mentioned at this point...) that deviates from standards a little bit. My guess is that this possibility to generate an empty list of ceritificate requests may be that kind of deviation. I would love it if those in the team that really know the SSL parts could give an accurate response... I am certainly not an expert, but I thought the bending of the rules was on the side of accepting things that werenot standard; not generating things which were not standard.At least anything that would result in generating non-standardoutput should have a SSL_OP flag associated with it.What code is being executed that is causing the zero lengthCA list?
RE: No CAs in CertificateRequest message
Jeff, thanks, I sent that info to my customer,
hopefully he'll be ok with "most implementations tolerate it, you probably
should too".
Erik
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey
Altman
I'm looking at the TLS 1.1
Internet-Draft and it reads:7.4.4. Certificate request
When this message will be sent:
A non-anonymous server can optionally request a certificate from
the client, if appropriate for the selected cipher suite. This
message, if sent, will immediately follow the Server Key Exchange
message (if it is sent; otherwise, the Server Certificate
message).
Structure of this message:
enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), |
fortezza_dms_RESERVED(20), |
(255)
} ClientCertificateType;
opaque DistinguishedName1..2^16-1;
struct {
ClientCertificateType certificate_types1..2^8-1;
DistinguishedName certificate_authorities0..2^16-1; |
} CertificateRequest;
certificate_types
This field is a list of the types of certificates requested, |
sorted in order of the server's preference. |
certificate_authorities
A list of the distinguished names of acceptable certificate
authorities. These distinguished names may specify a desired
distinguished name for a root CA or for a subordinate CA;
thus, this message can be used both to describe known roots |
and a desired authorization space. If the |
certificate_authorities list is empty then the client MAY |
send any certificate of the appropriate |
ClientCertificateType, unless there is some external |
arrangement to the contrary. |Reading
through the minutes and mailing lists of IETF TLS Working Group, it is
clear that this change was made because the vast majority of implementors
had already been allowing a certificate request to be sent without
acertificate authority name being specified. In TLS 1.0, according
to the specthere must be at least one certificate_authority specified in
the list.To be compliant with TLS 1.0 you must call
SSL_set_client_CA_list() withat least one certificate authority.
However, the general consensus as indicatedin TLS 1.1 is that the
specification of a certificate authority should not berequired.TLS
1.1 has passed last call and is currently being reviewed by the
IESG.Jeffrey AltmanErik Tkal wrote:
Jeff,
Look ins3_srvr.c -
ssl3_send_certificate_requestcalls SSL_get_client_CA_list to get the
stack of CA names(assumedly set by other code having called
SSL_set_client_CA_list). However, if the server side code has not set this
then the stack is empty, so the code ends up setting the 2-byte length field
to 0x and appending no further data to the message.
So the questions that remain
are:
1) Is this ok and should clients be required to
handle this, and if so where is this documented?
2) If it is required for the server implementation
to call SSL_set_client_CA_list, shouldan error be surfaced at some
point when this is detected?
3) If a server implementation is to call
SSL_set_client_CA_list how should it specify that it does not care what the
client sends (assuming it will check against trusted roots later)? I could
contend that a server implementation may not want to give such hints to a
client and assume that clients it trusts will present proper credentials
based on proper configuration.
Erik Tkal
FW: No CAs in CertificateRequest message
Can anyone answer this? How do I tell if this is a known problem with OpenSSL or if
the RFC is incorrect, or if this is just a accepted deviation?
Erik Tkal
Principal Software Engineer
Funk Software, Inc.
[EMAIL PROTECTED] 978-371-3980x123
Out the Token Ring, through the router, down the fiber, off
a switch, past the firewall, down the T1 ... nothing but Net.
---
A customer performing interoperability testing sent me a message and indicated that
our TLS server was sending a CertificateRequest message with a CAs length of 0,
followed by no additional data. This appears to be in violation of section 7.4.4 of
RFC 2246, which implies that the certificate_authorities must be at least 3 bytes.
struct {
ClientCertificateType certificate_types1..2^8-1;
DistinguishedName certificate_authorities3..2^16-1;
} CertificateRequest;
Is this a bug, and if so, what is the correct way to indicate that you do not wish to
hint to the client what CAs to use in selecting a certificate?
BTW, I tried changing the server code to send a 2-byte CAs length of 3, followed by a
2-byte CA1 length of 1, followed by a null byte, but the client didn't like that at
all.
Erik Tkal
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
No CAs in CertificateRequest message
A customer performing interoperability testing sent me a message and indicated that
our TLS server was sending a CertificateRequest message with a CAs length of 0,
followed by no additional data. This appears to be in violation of section 7.4.4 of
RFC 2246, which implies that the certificate_authorities must be at least 3 bytes.
struct {
ClientCertificateType certificate_types1..2^8-1;
DistinguishedName certificate_authorities3..2^16-1;
} CertificateRequest;
Is this a bug, and if so, what is the correct way to indicate that you do not wish to
hint to the client what CAs to use in selecting a certificate?
BTW, I tried changing the server code to send a 2-byte CAs length of 3, followed by a
2-byte CA1 length of 1, followed by a null byte, but the client didn't like that at
all.
Erik Tkal
[sorry for the repost, not sure if I was subscribed properly, if anyone replied,
please resend]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
No CAs in CertificateRequest message
A customer performing interoperability testing sent me a message and indicated that
our TLS server was sending a CertificateRequest message with a CAs length of 0,
followed by no additional data. This appears to be in violation of section 7.4.4 of
RFC 2246, which implies that the certificate_authorities must be at least 3 bytes.
struct {
ClientCertificateType certificate_types1..2^8-1;
DistinguishedName certificate_authorities3..2^16-1;
} CertificateRequest;
Is this a bug, and if so, what is the correct way to indicate that you do not wish to
hint to the client what CAs to use in selecting a certificate?
BTW, I tried changing the server code to send a 2-byte CAs length of 3, followed by a
2-byte CA1 length of 1, followed by a null byte, but the client didn't like that at
all.
Erik Tkal
[sorry for the repost, not sure if I was subscribed properly, if anyone replied,
please resend]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
