Re: openssl-0.9.8za fips compliance
Hi Jeffrey, I used openssl_fips 1.2 with openssl 0.9.8l. and planning to upgrade openssl-0.9.8l to 0.9.8za with -no-ec option. Please let me know is it break my fips compliance. Thanks, Gayathri On Fri, Aug 8, 2014 at 11:09 AM, Jeffrey Walton noloa...@gmail.com wrote: On Fri, Aug 8, 2014 at 1:11 AM, Gayathri Manoj gayathri.an...@gmail.com wrote: Please let me know openssl-0.9.8za with -no-ec option is fips compliant or not. No. If you want FIPS validated crypto, then you need one of the openssl-fips-*-tar.gz downloads. They produce the FIPS Object Module. openssl-0.9.8xxx is FIPS capable. It can use the validated cryptography if the FIPS Object Module is available. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL Security Advisory - CVE-2014-3508
Hi, Please can I enquire what the actual vulnerability is with... Information leak in pretty printing functions (CVE-2014-3508) = A flaw in OBJ_obj2txt may cause pretty printing functions such as X509_name_oneline, X509_name_print_ex et al. to leak some information from the stack. Applications may be affected if they echo pretty printing output to the attacker. OpenSSL SSL/TLS clients and servers themselves are not affected. OpenSSL 0.9.8 users should upgrade to 0.9.8zb OpenSSL 1.0.0 users should upgrade to 1.0.0n. OpenSSL 1.0.1 users should upgrade to 1.0.1i. Thanks to Ivan Fratric (Google) for discovering this issue. This issue was reported to OpenSSL on 19th June 2014. The fix was developed by Emilia Käsper and Stephen Henson of the OpenSSL development team. I have tried to look up CVE-2014-3508 and found it is not there yet. What is meant by echo pretty printing output to the attacker? Thank you for your assistance and look forward to your response. Thanks.. John [Unify: Harmonize your enterprise] John Simner BSc(Hons) MSc CEng. MIET Software Engineer, Devices Development Unify Enterprise Communications Ltd. Tel.: +44 (1908) 817378 (One Number Service) Email: john.sim...@unify.com mailto:vorname.n...@unify.com www.unify.co.ukhttp://www.unify.co.uk/ Follow us: [Social_media_icons] http://www.unify.com/social-media Unify Enterprise Communications Limited. Registered Office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ Registered No: 5903714, England. This email contains confidential information and is for the exclusive use of the addressee. If you are not the addressee then any distribution, copying, or use of this email is prohibited. If received in error, please advise the sender and delete immediately. We accept no liability for any loss or damage suffered by any person arising from use of this email.
RE: Query on X509 certificate validation- EVP_VerifyUpdate EVP_VerifyFinal
Hi Victor, Thanks for the response. We are digging further into how app1 is generating the signature. Problem seems to be pointing more towards app1. Regards, Rituparna Mitra -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Viktor Dukhovni Sent: Monday, August 04, 2014 8:51 PM To: openssl-users@openssl.org Subject: Re: Query on X509 certificate validation- EVP_VerifyUpdate EVP_VerifyFinal On Mon, Aug 04, 2014 at 05:43:47AM +, Mitra, Rituparna (STSD) wrote: 1. app1: sends a CGI POST request to app2 ? the POST request has the UN (username). 2. app2: does a CGI GET to receive the UN within app1?s POST request. 3. app2: has app1?s x509 certificate already stored, since it has to allow SSO from app1 ? gets verification ctx from here. 4. app2: uses the UN (containing ! character) to form a hashdata, 5. app2: passes hashdata to EVP_VerifyUpdate(ctx, .. ) 6. app2: calls EVP_VerifyFinal -- this eventually fails during public key check (EVP_PKEY_verify), due to the ! character in UN Sorry, that's not the reason. Your mistake is elsewhere. In particular the signature is likely incorrect or signed something other than what you expected. Also the SSO protocol design is deeply flawed. It is not sufficient to send a signature of the username alone. If the two applications are communicating directly, app1 should authenticate the channel with a client certificate, and can then just send the username unsigned in the request, since all the data sent is authenticated with app1's certificate. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Query on X509 certificate validation- EVP_VerifyUpdate EVP_VerifyFinal
Hi Dave,
If you mean app2 hashes UN and passes that hash to VerifyUpdate, that's wrong.
If you mean it passes the data *to be hashed*, that's good.
Thanks. Yes I meant the 2nd one, it passes the data to be hashed. We are
investigating further as problem seems to be leaning towards app1.
Regards,
Rituparna Mitra
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Dave Thompson
Sent: Friday, August 08, 2014 6:28 AM
To: openssl-users@openssl.org
Subject: RE: Query on X509 certificate validation- EVP_VerifyUpdate
EVP_VerifyFinal
From: owner-openssl-us...@openssl.org On Behalf Of Viktor Dukhovni
Sent: Monday, August 04, 2014 11:21
On Mon, Aug 04, 2014 at 05:43:47AM +, Mitra, Rituparna (STSD) wrote:
1. app1: sends a CGI POST request to app2 ? the POST request has
the
UN (username).
2. app2: does a CGI GET to receive the UN within app1?s POST
request.
3. app2: has app1?s x509 certificate already stored, since it has
to allow
SSO from app1 ? gets verification ctx from here.
4. app2: uses the UN (containing ! character) to form a hashdata,
5. app2: passes hashdata to EVP_VerifyUpdate(ctx, .. )
If you mean app2 hashes UN and passes that hash to VerifyUpdate, that's wrong.
If you mean it passes the data *to be hashed*, that's good.
EVP_Verify{Init,Update,Final} does the hash of the data as part of verifying a
signature just as EVP_Sign{Init,Update,Final} does the hash of the data to be
signed.
In fact {Sign,Verify}{Init,Update} are just macros for Digest{Init,Update}, the
PK operations are done only in Final.
6. app2: calls EVP_VerifyFinal -- this eventually fails during
public key
check (EVP_PKEY_verify), due to the ! character in UN
snip broader points
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
How to know that received data is HelloClient over an already established SSL?
Hi, I have an established/connected SSL instance acting as server (it is DTLS but I hope that does not matter). In my experiment, at some point the client sends a new HelloClient (which belongs to a new SSL session in the client side). Since the server just handles a single SSL instance what it happens is that SSL_read() returns SSL_ERROR_WANT_READ and nothing else occurs (there is no data to be sent to the peer in the network_bio). My question: how could I know that the received data is a HelloClient? I would like to know that because in that case I want to reset my SSL instance at server side. Thanks a lot. -- Iñaki Baz Castillo i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl 0.9.8 zb and DTLS reassemble fragment
On 07/08/14 20:42, Jaya Nageswar wrote: Hi All, The following vulnerability fixes in 0.9.8 zb seems to be related to the DTLS reassemble fragment functionality that is introduced from 0.9.8 o version. CVE-2014-3505 -Avoid double free when processing DTLS packets CVE-2014-3506 -Fix DTLS handshake message size checks CVE-2014-3507 -Fix memory leak from zero-length DTLS fragments As per the https://www.openssl.org/news/vulnerabilities.html, all the versions of openssl 0.9.8. This includes the versions before 0.9.8 o where the DTLS reassemble fragment is not present. Can some one confirm if it is updated by mistake or is all the versions of 0.9.8 are affected with the above vulnerabilities too.. appreciate your quick response on this. regards, -Jaya. Hi Jaya CVE-2014-3505 has two sites which are affected by the same problem (either of these can be present for the issue to occur). One of these is dtls1_reassemble_fragment, which you rightly say was not introduced until 0.9.8o. However the other site is in dtls1_process_out_of_seq_message. This issue was introduced in 0.9.8m. Therefore 0.9.8 - 0.9.8l are not affected. CVE-2014-3506 primarily addresses issues in dtls1_reassemble_fragment. However it does also address a problem in the non-fragmented case where there was no check for the maximum handshake message size, and this problem also exists in 0.9.8. Therefore 0.9.8 is still affected. CVE-2014-3507 deals with an issue where zero length fragments result in a memory leak due to a flaw in the logic regarding reassembling fragments. Since this logic does not exist in 0.9.8 - 0.9.8n, you are correct that they are not affected. I will correct the Security Advisory and the vulnerabilities page with regards to CVE-2014-3505 and CVE-2014-3507. Thank you for bringing this to our attention. Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl-0.9.8za fips compliance
Use of -no-ec when building the FIPS capable openssl doesn’t affect the FIPS module at all, and therefore doesn’t affect any statements you can make regarding FIPS 140 compliance. The -no-ec option will prevent elliptic curve cryptography from being used in OpenSSL when NOT using the FIPS module, and does not affect OpenSSL when using the FIPS module. The FIPS module is used only when FIPS mode is enabled by calling FIPS_mode_set(). I’m somewhat concerned, though, by your questions in a previous thread, so I’d like to clarify: elliptic curve cryptography cannot be used in FIPS mode (it’s not part of the FIPS module), no matter which version of OpenSSL you use with the 1.2 OpenSSL FIPS module. If you were previously using ECDSA keys in your application, you were not using the FIPS module, and any statements about the application being FIPS 140 compliant were mistaken, at best. TOM On Aug 8, 2014, at 1:59 AM, Gayathri Manoj gayathri.an...@gmail.com wrote: Hi Jeffrey, I used openssl_fips 1.2 with openssl 0.9.8l. and planning to upgrade openssl-0.9.8l to 0.9.8za with -no-ec option. Please let me know is it break my fips compliance. Thanks, Gayathri On Fri, Aug 8, 2014 at 11:09 AM, Jeffrey Walton noloa...@gmail.com wrote: On Fri, Aug 8, 2014 at 1:11 AM, Gayathri Manoj gayathri.an...@gmail.com wrote: Please let me know openssl-0.9.8za with -no-ec option is fips compliant or not. No. If you want FIPS validated crypto, then you need one of the openssl-fips-*-tar.gz downloads. They produce the FIPS Object Module. openssl-0.9.8xxx is FIPS capable. It can use the validated cryptography if the FIPS Object Module is available. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Is CVE-2014-5139 applicable if SRP ciphers were disabled from the cipherlist?
Hi, Reading the CVE-2014-5139 description, The issue affects OpenSSL clients and allows a malicious server to crash the client with a null pointer dereference (read) by specifying an SRP ciphersuite even though it was not properly negotiated with the client. This can be exploited through a Denial of Service attack. OpenSSL 1.0.1 SSL/TLS client users should upgrade to 1.0.1i. can someone please clarify whether or not this vulnerability affects 1.0.1 clients which explicitly disable SRP ciphers via SSL_CTX_set_cipher_list? I appreciate your help. Thanks and Best Regards, Henning __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: 1.0.1i breaks SRP
Hello Steve, Reverting the below commit is necessary but not sufficient. There are also references to aSRP in s3_clnt.c and ssl_lib.c that must be deleted to get OpenSSL to build. SRP functions correctly once that has been done. Norm On 8/7/14, 19:21, Dr. Stephen Henson wrote: On Thu, Aug 07, 2014, Norm Green wrote: Any idea where to begin debugging this? Any and all help is appreciated. The cause is incorrect handling of new SRP authentication type which was added to correct a bug where SRP authentication was incorrectly classified as NULL authhentication. A temporary workaround is to revert the addition of the SRP authentication type in commit 18c7f2fce8a82b13506cac7ca69fc333baf76408: https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=18c7f2fce8a82b13506cac7ca69fc333baf76408 I'm working on the proper 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl 0.9.8 zb and DTLS reassemble fragment
On 08/08/14 12:26, Matt Caswell wrote: Hi Jaya CVE-2014-3505 has two sites which are affected by the same problem (either of these can be present for the issue to occur). One of these is dtls1_reassemble_fragment, which you rightly say was not introduced until 0.9.8o. However the other site is in dtls1_process_out_of_seq_message. This issue was introduced in 0.9.8m. Therefore 0.9.8 - 0.9.8l are not affected. CVE-2014-3506 primarily addresses issues in dtls1_reassemble_fragment. However it does also address a problem in the non-fragmented case where there was no check for the maximum handshake message size, and this problem also exists in 0.9.8. Therefore 0.9.8 is still affected. CVE-2014-3507 deals with an issue where zero length fragments result in a memory leak due to a flaw in the logic regarding reassembling fragments. Since this logic does not exist in 0.9.8 - 0.9.8n, you are correct that they are not affected. I will correct the Security Advisory and the vulnerabilities page with regards to CVE-2014-3505 and CVE-2014-3507. I have updated the vulnerabilities page (should show on the web site soon). I haven't updated the Security Advisory as I think the advice is still correct (0.9.8 users are advised to upgrade to 0.9.8zb). As noted in another thread CVE-2014-3507 only applies to 0.9.8o onwards and 1.0.0a onwards (i.e. not 1.0.0). Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: 1.0.1i breaks SRP
On 08/08/14 19:33, Norm Green wrote: Hello Steve, Reverting the below commit is necessary but not sufficient. There are also references to aSRP in s3_clnt.c and ssl_lib.c that must be deleted to get OpenSSL to build. SRP functions correctly once that has been done. Those were introduced as part of the fix to CVE-2014-5139 (commit 83764a989)...deleting them may be unwise. Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: 1.0.1i breaks SRP
Then what would you suggest? SRP is completely broken for us with 1.0.1i Norm On 8/8/14, 11:51, Matt Caswell wrote: On 08/08/14 19:33, Norm Green wrote: Hello Steve, Reverting the below commit is necessary but not sufficient. There are also references to aSRP in s3_clnt.c and ssl_lib.c that must be deleted to get OpenSSL to build. SRP functions correctly once that has been done. Those were introduced as part of the fix to CVE-2014-5139 (commit 83764a989)...deleting them may be unwise. Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: 1.0.1i breaks SRP
On Fri, Aug 08, 2014, Norm Green wrote:
Then what would you suggest? SRP is completely broken for us with 1.0.1i
Please try the attached patch against 1.0.1i.
[BTW removing the aSRP references is fine as long as you don't delete the kSRP
references too]
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
diff --git a/ssl/s3_clnt.c b/ssl/s3_clnt.c
index ea0c82d..2ceaa1e 100644
--- a/ssl/s3_clnt.c
+++ b/ssl/s3_clnt.c
@@ -326,9 +326,9 @@ int ssl3_connect(SSL *s)
break;
}
#endif
- /* Check if it is anon DH/ECDH */
+ /* Check if it is anon DH/ECDH, SRP auth */
/* or PSK */
- if (!(s-s3-tmp.new_cipher-algorithm_auth
SSL_aNULL)
+ if (!(s-s3-tmp.new_cipher-algorithm_auth
(SSL_aNULL|SSL_aSRP))
!(s-s3-tmp.new_cipher-algorithm_mkey SSL_kPSK))
{
ret=ssl3_get_server_certificate(s);
@@ -1835,8 +1835,8 @@ fprintf(stderr, USING TLSv1.2 HASH %s\n,
EVP_MD_name(md));
}
else
{
- if (!(alg_a SSL_aNULL) !(alg_k SSL_kPSK))
- /* aNULL or kPSK do not need public keys */
+ /* aNULL, aSRP or kPSK do not need public keys */
+ if (!(alg_a (SSL_aNULL|SSL_aSRP)) !(alg_k SSL_kPSK))
{
SSLerr(SSL_F_SSL3_GET_KEY_EXCHANGE,ERR_R_INTERNAL_ERROR);
goto err;
diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
index 4835bef..c5f3e93 100644
--- a/ssl/s3_lib.c
+++ b/ssl/s3_lib.c
@@ -3824,6 +3824,8 @@ SSL_CIPHER *ssl3_choose_cipher(SSL *s,
STACK_OF(SSL_CIPHER) *clnt,
#ifndef OPENSSL_NO_SRP
mask_k=cert-mask_k | s-srp_ctx.srp_Mask;
emask_k=cert-export_mask_k | s-srp_ctx.srp_Mask;
+ mask_a=cert-mask_a | s-srp_ctx.srp_Mask;
+ emask_a=cert-export_mask_a | s-srp_ctx.srp_Mask;
#endif
#ifdef KSSL_DEBUG
diff --git a/ssl/s3_srvr.c b/ssl/s3_srvr.c
index 2867501..b0538d1 100644
--- a/ssl/s3_srvr.c
+++ b/ssl/s3_srvr.c
@@ -412,7 +412,7 @@ int ssl3_accept(SSL *s)
/* normal PSK or KRB5 or SRP */
if (!(s-s3-tmp.new_cipher-algorithm_auth SSL_aNULL)
!(s-s3-tmp.new_cipher-algorithm_mkey
SSL_kPSK)
-!(s-s3-tmp.new_cipher-algorithm_auth
SSL_aKRB5))
+!(s-s3-tmp.new_cipher-algorithm_auth
(SSL_aKRB5|SSL_aSRP)))
{
ret=ssl3_send_server_certificate(s);
if (ret = 0) goto end;
@@ -515,7 +515,9 @@ int ssl3_accept(SSL *s)
* (against the specs, but s3_clnt.c accepts
this for SSL 3) */
!(s-verify_mode
SSL_VERIFY_FAIL_IF_NO_PEER_CERT)) ||
/* never request cert in Kerberos ciphersuites
*/
- (s-s3-tmp.new_cipher-algorithm_auth
SSL_aKRB5)
+ (s-s3-tmp.new_cipher-algorithm_auth
SSL_aKRB5) ||
+ /* don't request certificate with SRP auth */
+ (s-s3-tmp.new_cipher-algorithm_auth
SSL_aSRP)
/* With normal PSK Certificates and
* Certificate Requests are omitted */
|| (s-s3-tmp.new_cipher-algorithm_mkey
SSL_kPSK))
@@ -1846,7 +1848,7 @@ int ssl3_send_server_key_exchange(SSL *s)
n+=2+nr[i];
}
- if (!(s-s3-tmp.new_cipher-algorithm_auth SSL_aNULL)
+ if (!(s-s3-tmp.new_cipher-algorithm_auth
(SSL_aNULL|SSL_aSRP))
!(s-s3-tmp.new_cipher-algorithm_mkey SSL_kPSK))
{
if
((pkey=ssl_get_sign_pkey(s,s-s3-tmp.new_cipher,md))
Re: Is CVE-2014-5139 applicable if SRP ciphers were disabled from the cipherlist?
On Fri, Aug 08, 2014, Henning Horst wrote: can someone please clarify whether or not this vulnerability affects 1.0.1 clients which explicitly disable SRP ciphers via SSL_CTX_set_cipher_list? Disabling them with the cipherlist will still leave you vulnerable. One of the bugs this fixed was that an SRP ciphersuites could be specified even if it was not present in ClientHello. If you disable SRP at compile time with no-srp you're OK though. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Is CVE-2014-5139 applicable if SRP ciphers were disabled from the cipherlist?
On 08/08/2014 03:27 PM, Dr. Stephen Henson wrote: Disabling them with the cipherlist will still leave you vulnerable. One of the bugs this fixed was that an SRP ciphersuites could be specified even if it was not present in ClientHello. If you disable SRP at compile time with no-srp you're OK though. Thank you very much for your swift response, Steve. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RST after close_notify
I have an issue with an FTP client issuing a DIR command to a Windows FTP server. A normal packet trace is shown in sequence 1 below. An Ack Fin is received from the Windows FTP server and the DIR command completes successfully. In the 2nd sequence, each side exchanges close_notify, but no Fin flags are set. Windows FTP server ends with an Ack Rst. After receiving the Reset packet, the FTP client issues a connection reset' message and sets an error code. Is that the correct thing to do? 1) Successful DIR command output being received: IN Ack IN Ack 536Bytes IN Ack 536B OUT Ack Psh IN Ack 536B IN Ack 536B IN Ack 536B IN Ack 536B IN Ack Psh 79B 42B 15 (close_notify alert) OUT Ack Psh IN Ack Fin OUT Ack Psh 37B 15 (close_notify alert) IN Ack Rst 2) DIR command fails with error: IN Ack IN Ack 536B IN Ack 536B OUT Ack Psh IN Ack 536B IN Ack 536B IN Ack 536B IN Ack 536B IN Ack Psh 42B OUT Ack Psh IN Ack Psh 37B 15 (close_notify alert) OUT Ack Psh OUT Ack Psh 37B 15 (close_notify alert) IN Ack Rst -- Donald J. dona...@4email.net -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: 1.0.1i breaks SRP
Hi Steve, That patch works! We will go with that one instead of rolling back the commit mentioned in your previous message. Thanks very much for your help!!! Norm On 8/8/14, 12:25, Dr. Stephen Henson wrote: On Fri, Aug 08, 2014, Norm Green wrote: Then what would you suggest? SRP is completely broken for us with 1.0.1i Please try the attached patch against 1.0.1i. [BTW removing the aSRP references is fine as long as you don't delete the kSRP references too] 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl 0.9.8 zb and DTLS reassemble fragment
Thank you very much for the update in a quick time. On Sat, Aug 9, 2014 at 12:09 AM, Matt Caswell m...@openssl.org wrote: On 08/08/14 12:26, Matt Caswell wrote: Hi Jaya CVE-2014-3505 has two sites which are affected by the same problem (either of these can be present for the issue to occur). One of these is dtls1_reassemble_fragment, which you rightly say was not introduced until 0.9.8o. However the other site is in dtls1_process_out_of_seq_message. This issue was introduced in 0.9.8m. Therefore 0.9.8 - 0.9.8l are not affected. CVE-2014-3506 primarily addresses issues in dtls1_reassemble_fragment. However it does also address a problem in the non-fragmented case where there was no check for the maximum handshake message size, and this problem also exists in 0.9.8. Therefore 0.9.8 is still affected. CVE-2014-3507 deals with an issue where zero length fragments result in a memory leak due to a flaw in the logic regarding reassembling fragments. Since this logic does not exist in 0.9.8 - 0.9.8n, you are correct that they are not affected. I will correct the Security Advisory and the vulnerabilities page with regards to CVE-2014-3505 and CVE-2014-3507. I have updated the vulnerabilities page (should show on the web site soon). I haven't updated the Security Advisory as I think the advice is still correct (0.9.8 users are advised to upgrade to 0.9.8zb). As noted in another thread CVE-2014-3507 only applies to 0.9.8o onwards and 1.0.0a onwards (i.e. not 1.0.0). Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: RST after close_notify
-Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Donald J. Sent: Friday, 08 August, 2014 15:34 To: openssl-users@openssl.org Subject: RST after close_notify I have an issue with an FTP client issuing a DIR command to a Windows FTP server. A normal packet trace is shown in sequence 1 below. An Ack Fin is received from the Windows FTP server and the DIR command completes successfully. Both of your traces below show an RST in the final packet, not a FIN. In the 2nd sequence, each side exchanges close_notify, but no Fin flags are set. Windows FTP server ends with an Ack Rst. After receiving the Reset packet, the FTP client issues a connection reset' message and sets an error code. Is that the correct thing to do? Are you questioning the server's behavior, or the client's? Probably what happened is the server sent its close_notify and then closed its end of the connection without waiting for the client's close_notify response. See Eric Rescorla's /SSL and TLS/ book, 8.10, for further discussion. This is unfriendly behavior by the server, in my opinion, but common enough for Rescorla to discuss it. It's also possible the server did an abortive close, which would be the Wrong Thing to do, but the former case is more likely. And in any event, your client couldn't distinguish between the two. (And what would you do about it anyway? If someone else's server behaves badly, you have to deal with it in some fashion.) How the client handles receiving a RST (generally manifests as a return code of -1 from send or recv, with errno set to ECONNRESET [1]; with OpenSSL you should get SSL_ERROR_SYSCALL and check errno) is a matter of taste. Often you do want to report that the connection was reset. In this case, though, since a reset is not unexpected AND you know you've received all the data from the server - you got its close_notify - it's better to silently ignore it. In short, the logic should be something like this: if RST-received if we were trying to send data check for a close_notify from the peer end-if if close_notify not already recevied from peer treat as failure end-if close socket and clean up end-if [1] This assumes the application, if it's running in a POSIX environment, has set the disposition of the SIGPIPE signal to ignore. SIGPIPE is a kluge for applications that don't check the result of the write/send family of system calls. Any well-written application should ignore it. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: RST after close_notify
The FTP client is a batch mainframe process which must get return code zero, or someone gets called in the middle of the night. I have been working with IBM support which claims that the server should return a Fin before Rst. So I will probably turn this problem over to our PC server group. I don't really understand why in the successful sequence, the client sends Ack PSh and waits to receive the Ack Fin before sending the close_notify. But in the failing sequence the client sends Ack Psh, then immediately sends lose_notify without any waiting. If the server is closing its connection after sending the close_notify, it probably wouldn't send the Ack Fin in the successful sequence? I guess IBM is saying the server should send Ack Fin, wait for Ack from client, and server then would send the AckRst? -- Donald J. dona...@4email.net On Fri, Aug 8, 2014, at 02:03 PM, Michael Wojcik wrote: -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Donald J. Sent: Friday, 08 August, 2014 15:34 To: openssl-users@openssl.org Subject: RST after close_notify I have an issue with an FTP client issuing a DIR command to a Windows FTP server. A normal packet trace is shown in sequence 1 below. An Ack Fin is received from the Windows FTP server and the DIR command completes successfully. Both of your traces below show an RST in the final packet, not a FIN. In the 2nd sequence, each side exchanges close_notify, but no Fin flags are set. Windows FTP server ends with an Ack Rst. After receiving the Reset packet, the FTP client issues a connection reset' message and sets an error code. Is that the correct thing to do? Are you questioning the server's behavior, or the client's? Probably what happened is the server sent its close_notify and then closed its end of the connection without waiting for the client's close_notify response. See Eric Rescorla's /SSL and TLS/ book, 8.10, for further discussion. This is unfriendly behavior by the server, in my opinion, but common enough for Rescorla to discuss it. It's also possible the server did an abortive close, which would be the Wrong Thing to do, but the former case is more likely. And in any event, your client couldn't distinguish between the two. (And what would you do about it anyway? If someone else's server behaves badly, you have to deal with it in some fashion.) How the client handles receiving a RST (generally manifests as a return code of -1 from send or recv, with errno set to ECONNRESET [1]; with OpenSSL you should get SSL_ERROR_SYSCALL and check errno) is a matter of taste. Often you do want to report that the connection was reset. In this case, though, since a reset is not unexpected AND you know you've received all the data from the server - you got its close_notify - it's better to silently ignore it. In short, the logic should be something like this: if RST-received if we were trying to send data check for a close_notify from the peer end-if if close_notify not already recevied from peer treat as failure end-if close socket and clean up end-if [1] This assumes the application, if it's running in a POSIX environment, has set the disposition of the SIGPIPE signal to ignore. SIGPIPE is a kluge for applications that don't check the result of the write/send family of system calls. Any well-written application should ignore it. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- http://www.fastmail.fm - Same, same, but different... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
