[openssl.org #3030] openssl 1.0.1 doesn't get response when negotiating connection to server needing TLSv1

[Stephen Henson via RT]

On Fri May 03 18:52:49 2013, fromopen...@homelinkcs.com wrote:
> With openssl 1.0.0j, I could connect to www.energydirect.com using:
>
> openssl s_client -connect www.energydirect.com:443
>
> But since my distribution upgraded to 1.0.1c, that command just shows
> "CONNECTED(0003)", hangs for a while, then eventually outputs:
>
> write:errno=104
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 369 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> ---
>
>
> If the -tls1 switch is used the connection will work, but unless this
> new
> behavior is intentional, this appears to be a regression. Using -tls1
> is okay
> for simple command-line use, but for higher level scripts which use
> openssl
> underneath, having to explicitly specify TLSv1 for this host is
> problematic.
>
> This problem seems to still be present in the master and
> OpenSSL_1_0_1-stable
> git branchs. By bisecting, I found that this change appears to have
> occured
> with commit 9472baae.
>

This is a known bug in some servers, see PR#2771 for more details.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3036] openssl-0.9.8y config removes symbolic link /dev/null on Solaris

[Mike Frysinger via RT]

On Friday 03 May 2013 12:56:41 Mitch Halmu via RT wrote:
> When running the config script on Solaris 9 (sparc), the symbolic link
> /dev/null -> /devices/pseudo/mm@0:null is destroyed. You will notice it
> happened by the error messages that start spewing. To repair:
> 
> # ln -s /devices/pseudo/mm@0:null /dev/null
> 
> Workaround: comment out the following lines before running config:
> 
> #($CC -Wa,--help -c -o /dev/null -x assembler /dev/null 2>&1 | \
> # grep \\--noexecstack) 2>&1 > /dev/null && \
> #  options="$options -Wa,--noexecstack"

that is a bug in the compiler/assembler.  it should only unlink ordinary files.
-mike


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: [openssl.org #3039] AutoReply: Can't Compile openssl-fips-1.1.2: collect2: ld returned 1 exit status

[Smith, Burton via RT]

Thanks, but after playing with this puzzle for a while I combined the 
configuration options that were supposed to correct it individually.  It 
worked.  The proper command is:

sh config no-shared \
fips

Persistence pays off.

---
Thanks,
Burton L. Smith
w:801-584-6164
c:801-201-2897

-Original Message-
From: The default queue via RT [mailto:r...@openssl.org] 
Sent: Friday, May 03, 2013 10:58 AM
To: Smith, Burton
Subject: [openssl.org #3039] AutoReply: Can't Compile openssl-fips-1.1.2: 
collect2: ld returned 1 exit status 


Greetings,

This message has been automatically generated in response to the creation of a 
trouble ticket regarding:
"Can't Compile openssl-fips-1.1.2: collect2: ld returned 1 exit 
status", a summary of which appears below.

There is no need to reply to this message right now.  Your ticket has been 
assigned an ID of [openssl.org #3039].

Please include the string:

 [openssl.org #3039]

in the subject line of all future correspondence about this issue. To do so, 
you may reply to this message.

Thank you,
r...@openssl.org

-
Why wouldn't openSsl compile in Santiago?  I get a stream of undefined 
references that seem to only count as one error.

fips_desmovs.o: In function `DESTest':
fips_desmovs.c:(.text+0x45b): undefined reference to `EVP_des_ede3_cfb1'
fips_desmovs.c:(.text+0x49b): undefined reference to `EVP_des_cfb64'
fips_desmovs.c:(.text+0x57d): undefined reference to `EVP_des_ede3_cbc'
fips_desmovs.c:(.text+0x595): undefined reference to `EVP_CipherInit'
fips_desmovs.c:(.text+0x5e1): undefined reference to `EVP_des_ecb'
fips_desmovs.c:(.text+0x5f1): undefined reference to `EVP_des_ede3_ecb'
fips_desmovs.c:(.text+0x601): undefined reference to `EVP_des_cfb1'
fips_desmovs.c:(.text+0x611): undefined reference to `EVP_des_ede3_ofb'
fips_desmovs.c:(.text+0x621): undefined reference to `EVP_des_ofb'
fips_desmovs.c:(.text+0x631): undefined reference to `EVP_des_ede3_cfb64'
fips_desmovs.c:(.text+0x641): undefined reference to `EVP_des_cbc'
fips_desmovs.c:(.text+0x651): undefined reference to `EVP_des_ede3_cfb8'
fips_desmovs.c:(.text+0x661): undefined reference to `EVP_des_cfb8'
fips_desmovs.c:(.text+0x69b): undefined reference to `ERR_print_errors_fp'
fips_desmovs.o: In function `do_mct':
fips_desmovs.c:(.text+0xe89): undefined reference to `DES_set_odd_parity'
fips_desmovs.c:(.text+0xe96): undefined reference to `DES_set_odd_parity'
fips_desmovs.c:(.text+0xea3): undefined reference to `DES_set_odd_parity'
fips_desmovs.o: In function `main':
fips_desmovs.c:(.text+0x1db6): undefined reference to `ERR_load_crypto_strings'
collect2: ld returned 1 exit status
make[1]: *** [fips_desmovs] Error 1
make[1]: Leaving directory `/opt/apache/openssl-fips-1.1.2/test'
make: *** [sub_all] Error 1

---
Thanks,
Burton L. Smith
w:801-584-6164
c:801-201-2897



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #2895] AutoReply: Sendmail v8.14.4 is not working with OpenSSL 0.9.8m onwards on AIX

[vikas vicky via RT]

Hello Guys ,

Any help / suggestion/work-around is greatly appreciated for this issue.

Thank you all for your help & time .


=

Thanks
Vikas K Vicky



On Thu, Oct 11, 2012 at 7:41 PM, The default queue via RT 
wrote:

>
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "Sendmail v8.14.4 is not working with OpenSSL 0.9.8m onwards on
> AIX",
> a summary of which appears below.
>
> There is no need to reply to this message right now.  Your ticket has been
> assigned an ID of [openssl.org #2895].
>
> Please include the string:
>
>  [openssl.org #2895]
>
> in the subject line of all future correspondence about this issue. To do
> so,
> you may reply to this message.
>
> Thank you,
> r...@openssl.org
>
> -
> Hello OpenSSL Developers,
>
> I have an issue related to OpenSSL & Sendmail, in which sendmail is not
> working  with  OpenSSL 0.9.8m onwards and so, I want to report this bug.
>
> Though, it works fine with OpenSSL 0.9.8k &  OpenSSL 0.9.8l but fails with
> OpenSSL 0.9.8m ,0.9.8n etc ( till the latest 0.9.8x ) .
> Please note that nothing has been changed from the configuration point of
> view ( for both OpenSSL as well as Sendmail ) while updating from
> OpenSSL 0.9.8k to  a version >= 0.9.8m .
>
> *I am using TLS version of sendmail compiled with STARTTLS & the Operating
> System being used is AIX*.
> *The Sendmail version is - 8.14.4 .*
>
> The steps to reproduce the issue are as below -
>
> 1. *stopsrc -s sendmail*
>
> 2.* ln -sf /usr/sbin/sendmail_ssl /usr/lib/sendmail * ( to make
> sure the sendmail binary compiled with STARTTLS  i.e /usr/sbin/sendmail_ssl
> will be used )
>
> 3. *startsrc -s sendmail -a "-bd -q30" *
>
>
> 4.Now execute the below command on the same machine -
>
> # *openssl s_client -starttls smtp -connect localhost:25 -CApath
> /etc/mail/certs*
> CONNECTED(0004)
> 5243082:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
> failure:s23_lib.c:182:   <== Error message.
>
> Also , the following error is beoing logged in the syslog file -
>
> *Oct 11 02:07:12 vayu10 mail:warn|warning sendmail[5767316]:
> STARTTLS=server, error: accept failed=0, SSL_error=1, errno=0, retry=-1,
> relay=localhost [127.0.0.1]
> Oct 11 02:07:12 vayu10 mail:warn|warning sendmail[5767316]:
> STARTTLS=server: 5767316:error:140B6044:SSL
> routines:SSL_GET_SERVER_SEND_CERT:internal error:ssl_lib.c:1991:
> Oct 11 02:07:12 vayu10 mail:warn|warning sendmail[5767316]:
> STARTTLS=server: 5767316:error:1409A044:SSL
> routines:SSL3_SEND_SERVER_CERTIFICATE:internal error:s3_srvr.c:2657:
> Oct 11 02:07:12 vayu10 mail:info sendmail[5767316]: q9B77C475767316:
> localhost [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection
> to MTA
> *
> The same setup is working with older OpenSSL versions 0.9.8k & 0.9.8l .I
> noticed  some major changes in OpenSSL 0.9.8.m from renegotiation point of
> view due to *CVE-2009-3555* .
>
> I debugged this quite a few times & found that  *value of*
> *s->s3->tmp.new_cipher
> is NULL* which should contain a selected Cipher value.
>
> Any help is much appreciated.
>
> =
>
> Thanks
> Vikas K Vicky
>
>

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #2996] PATCH: cygwin (and probably others) support broken by long time

[Andy Polyakov via RT]

>>> in the file crypto/sha/sha.h there is this line:
>>>
>>> #if (defined(_WIN32) || defined(_WIN64)) && !defined(__MINGW32__)
>>>
>>> used to conditionally declare SHA_LONG64 and U64 macros.
>>> Unfortunately, this causes OpenSSL to be unusable on Cygwin because, 
>>> obviously, __MINGW32__ is not declared.
>>> A fix could be made by appending "&& !defined(__CYGWIN__)" but in my 
>>> opinion 
>>> it is better to replace the last test with "&& defined(_MSC_VER)" because 
>>> things like "__int64" and "UI64" are not standard extensions and they 
>>> should 
>>> be 
>>> supported only if we are targetting to Microsoft VisualC++.
>>>
>>> Without this thing fixed, I was not able to make it working... for example, 
>>> if 
>>> you run an autoconf script that it checks the presence of openssl.h, you 
>>> will 
>>> get a message like "found but cannot be used. Missing pre-requisites?"
>>>
>>> Attached patch fixes this defect.
>>
>> Dunno what your problem exactly is, but openssl-1.0.1e is part of the
>> official Cygwin distro at cygwin.com.  Lots of packages in the distro
>> are built against OpenSSL.
>>
>> The problem you have here looks self-induced.  Neither _WIN32 nor _WIN64
>> are defined by default when building on Cygwin.  _WIN32 is not defined
>> either when including , at least not if you use the current
>> w32api headers of the mingw64 project.  _WIN64 is only defined when
>> including  and building for the 64 bit version of Cygwin,
>> which isn't released yet.
>>
>> So, bottom line is, I don't think that your patch is necessary.  You
>> should rather make sure that _WIN32 isn't defined accidentally in your
>> scenario.
>>
>>
>> Corinna
>>
> 
> Hello, sorry if I have not replied... I was expecting some changes in
> the bug tracker instead of in the mailing list, my mistake.

Well, it's not inappropriate to expect reply through RT, but it takes 
discipline to reply explicitly to r...@openssl.org instead of openssl-dev.

> Actually, in my opinion the bug is real: I believe you can't rely
> just on _WIN32 and on _WIN64 macro because, as you said, it is enough
> to include windows.h in the checked headers or to add -D_WIN32 to
> CFLAGS to fail autoconf, which may be required by other packages.

As Corinna implied it's inappropriate to define _WIN32 (or include 
windows.h) when compiling code with Cygwin compiler. So the key question 
is why do you insist on passing -D_WIN32? And correct solution should be 
to abstain from doing so.

> Alternatively, if you prefer, the patch could also be changed as:
> 
> #if (defined(_WIN32) || defined(_WIN64)) && !defined(__GNUC__)
> 
> because you simply can't use the following lines in a different
> environment than VisualC++

Not true. There are non-Microsoft compilers that [legitimately] 
pre-define _WIN32 but don't have long long, e.g. Borland. Of course one 
can argue that nobody is using it by now, but at least that's the 
original reason for why the condition looks they way it does.

> or something that it does not mimic
> exactly the compiler made by Microsoft: if  is included,
> somehow you may be able to use __int8/__int16/__int32/__int64 because
> they will be provided by its inclusion,

__int64 is internal type, it's not defined in windows.h.

> but anyways you won't be
> surely able to append UI64 to a long long type. By the way, this also
> breaks openssl on MSYS, for the same reason.

??? Where do you get your compilers? MSYS compiler *is* MINGW and
__MINGW32__ *is* defined by MSYS compiler. Even by mingw-w64 one. Well,
they might have changed the last part, but then you can't just say 
"breaks on MSYS" without stating the version.

Replacing !defined(__MINGW32__) with !defined(__GNUC__) might be 
sensible and it will be considered. *But* it doesn't change the fact 
that it's inappropriate to pass _WIN32 to Cygwin compiler. So that if 
condition will changed, it won't be for this report, but for more 
general reasons.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3040] [openssl-1.0.1e] MinGW compilation - Perl invocation failure - Perlbin/perl.exe: No such file or directory

[Albert via RT]

Hi,

** DESCRIPTION:
While compiling 'openssl-1.0.1e' with MinGW toolchain, compilation fails 
with following error message :
"/bin/sh: Perlbin/perl.exe: No such file or directory"
when building x86cpuid.s target.

** HOW TO REPRODUCE :
** PERL installed in D:\Perl (perl 5.14.2)
** MSYS (1.0) installed in C:\msys
** MinGW (TDM (tdm-gcc.tdragon.net) 4.7.1) installed in D:\Program 
Files\TDM_MinGW32
** Launch a DOS command prompt
** Change env var PATH to : set 
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\msys\1.0\bin;%MINGW_HOME%\bin;D:\Perl\bin
(MINGW_HOME=D:\Program Files\TDM_MinGW32)
** Call "sh configure"
** Call "make"

Error appears.

** WORKAROUND:
I changed in openssl-1.0.1e\makefile the line :
PERL= \Perl\bin/perl.exe
by
PERL=perl.exe

And then the compilation no more fails when invoking a perl script


** MY 2 CENTS
I am not very familiar with bash and perl script but I suspect that the 
line "PERL= \Perl\bin/perl.exe" is incorrect when PERL is not installed 
in C:\ which is my case.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3039] Can't Compile openssl-fips-1.1.2: collect2: ld returned 1 exit status

[Smith, Burton via RT]

Why wouldn't openSsl compile in Santiago?  I get a stream of undefined 
references that seem to only count as one error.

fips_desmovs.o: In function `DESTest':
fips_desmovs.c:(.text+0x45b): undefined reference to `EVP_des_ede3_cfb1'
fips_desmovs.c:(.text+0x49b): undefined reference to `EVP_des_cfb64'
fips_desmovs.c:(.text+0x57d): undefined reference to `EVP_des_ede3_cbc'
fips_desmovs.c:(.text+0x595): undefined reference to `EVP_CipherInit'
fips_desmovs.c:(.text+0x5e1): undefined reference to `EVP_des_ecb'
fips_desmovs.c:(.text+0x5f1): undefined reference to `EVP_des_ede3_ecb'
fips_desmovs.c:(.text+0x601): undefined reference to `EVP_des_cfb1'
fips_desmovs.c:(.text+0x611): undefined reference to `EVP_des_ede3_ofb'
fips_desmovs.c:(.text+0x621): undefined reference to `EVP_des_ofb'
fips_desmovs.c:(.text+0x631): undefined reference to `EVP_des_ede3_cfb64'
fips_desmovs.c:(.text+0x641): undefined reference to `EVP_des_cbc'
fips_desmovs.c:(.text+0x651): undefined reference to `EVP_des_ede3_cfb8'
fips_desmovs.c:(.text+0x661): undefined reference to `EVP_des_cfb8'
fips_desmovs.c:(.text+0x69b): undefined reference to `ERR_print_errors_fp'
fips_desmovs.o: In function `do_mct':
fips_desmovs.c:(.text+0xe89): undefined reference to `DES_set_odd_parity'
fips_desmovs.c:(.text+0xe96): undefined reference to `DES_set_odd_parity'
fips_desmovs.c:(.text+0xea3): undefined reference to `DES_set_odd_parity'
fips_desmovs.o: In function `main':
fips_desmovs.c:(.text+0x1db6): undefined reference to `ERR_load_crypto_strings'
collect2: ld returned 1 exit status
make[1]: *** [fips_desmovs] Error 1
make[1]: Leaving directory `/opt/apache/openssl-fips-1.1.2/test'
make: *** [sub_all] Error 1

---
Thanks,
Burton L. Smith
w:801-584-6164
c:801-201-2897


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3038] [PATCH]: Fix warning-level alert handling in 0.9.8

[manc...@hush.com via RT]

Hello.

OpenSSL 0.9.8y does not properly handle warning level
alerts in SSLv23 client method unlike OpensSSL 1.0.0+.

For example, when OpenSSL 0.9.8 initiates a connection
using TLS-SNI extensions in "SSLv23 mode" and the server
replies to client hello with an unrecognized_name warning
alert, the handshake terminates client-side.

This issue has been reported by many clients linked against
OpenSSL 0.9.8 (see footer links).

When connecting to a server that sends warning-level alerts
on hostname mismatch in TLS-SNI, eg.:

  $ openssl s_client -CApath /etc/ssl -connect \
$CorrectHostname:443 -servername $InvalidHostname \
-state < /dev/null 2>&1 | grep -E 'alert|error'

Current 0.9.8y behavior (output):
  SSL3 alert read:warning:unknown
  SSL_connect:error in SSLv2/v3 read server hello A
  7632:error:14077458:SSL 
routines:SSL23_GET_SERVER_HELLO:reason(1112):s23_clnt.c:602:

Desired behavior (output) [consistent with OpenSSL 1.0.1e]:
  SSL3 alert read:warning:unrecognized name
  SSL3 alert write:warning:close notify

Patch applies cleanly to OpenSSL_0_9_8-stable (HEAD@a44c9b9c)
and makes behavior consistent with OpenSSL 1.0.1e. Also, it
adds support for new alerts (RFC 6066 and RFC 4279).

Please consider its inclusion after appropriate code review.

--mancha

Note: A higher-level discussion is whether non-fatal
unrecognized_name alerts should be sent at all. Per RFC 6066,
"If a server name is provided but not recognized, the server
should either continue the handshake without an error or send
a fatal error. Sending a warning-level message is not
recommended because client behavior will be unpredictable."

=

[1] http://marc.info/?l=openssl-users&m=131736995412529&w=2
[2] http://sourceforge.net/p/curl/bugs/1037/
[3] https://bugs.php.net/bug.php?id=61276
[4] https://github.com/joyent/node/issues/3033


0001-Fix-handling-of-warning-level-alerts-in-SSL23-client.patch
Description: Binary data

[openssl.org #3037] [PATCH] so 1.0.1e will build with "no-tlsext" option specified

[geoff_l...@mcafee.com via RT]

These patches primarily move around a few #ifdefs so that 1.0.1e will compile 
when the "no-tlsext" option is specified.

Note that when "no-tlsext" is specified, "no-srtp" is forced now too in 
addition to "no-srp" and "no-heartbeats".

I'm not 100% confident in these changes, so I'd appreciate some level of review 
and comment before they are accepted, but I'm sure do that as a matter of 
course anyway.

Thanks,
Geoff


*** ./openssl-1.0.1e/Configure  Mon Feb 11 09:26:04 2013
--- ./openssl-1.0.1e-fixed/ConfigureFri Apr 26 10:53:38 2013
*** if (defined($disabled{"tlsext"}))
*** 1026,1031 
--- 1026,1032 
{
$disabled{"srp"} = "forced";
$disabled{"heartbeats"} = "forced";
+   $disabled{"srtp"} = "forced";
}
  
  if ($target eq "TABLE") {

*** ./openssl-1.0.1e/ssl/s3_clnt.c  Mon Feb 11 09:26:04 2013
--- ./openssl-1.0.1e-fixed/ssl/s3_clnt.cFri Apr 26 11:00:30 2013
*** int ssl3_get_server_hello(SSL *s)
*** 1068,1074 
--- 1068,1076 
return(1);
  f_err:
ssl3_send_alert(s,SSL3_AL_FATAL,al);
+ #ifndef OPENSSL_NO_TLSEXT
  err:
+ #endif
return(-1);
}
  
*** ./openssl-1.0.1e/ssl/s3_srvr.c  Mon Feb 11 09:26:04 2013
--- ./openssl-1.0.1e-fixed/ssl/s3_srvr.cFri Apr 26 14:28:00 2013
*** int ssl3_get_client_hello(SSL *s)
*** 1408,1413 
--- 1408,1414 
 * s->tmp.new_cipher- the new cipher to use.
 */
  
+ #ifndef OPENSSL_NO_TLSEXT
/* Handles TLS extensions that we couldn't check earlier */
if (s->version >= SSL3_VERSION)
{
*** int ssl3_get_client_hello(SSL *s)
*** 1417,1422 
--- 1418,1424 
goto err;
}
}
+ #endif
  
if (ret < 0) ret=1;
if (0)

*** ./openssl-1.0.1e/ssl/ssl_locl.h Mon Feb 11 09:26:04 2013
--- ./openssl-1.0.1e-fixed/ssl/ssl_locl.h   Fri Apr 26 11:00:02 2013
*** int dtls1_process_heartbeat(SSL *s);
*** 1117,1128 
  int tls1_process_ticket(SSL *s, unsigned char *session_id, int len,
const unsigned char *limit, SSL_SESSION **ret);
  
  int tls12_get_sigandhash(unsigned char *p, const EVP_PKEY *pk,
const EVP_MD *md);
  int tls12_get_sigid(const EVP_PKEY *pk);
  const EVP_MD *tls12_get_hash(unsigned char hash_alg);
  
- #endif
  EVP_MD_CTX* ssl_replace_hash(EVP_MD_CTX **hash,const EVP_MD *md) ;
  void ssl_clear_hash_ctx(EVP_MD_CTX **hash);
  int ssl_add_serverhello_renegotiate_ext(SSL *s, unsigned char *p, int *len,
--- 1117,1128 
  int tls1_process_ticket(SSL *s, unsigned char *session_id, int len,
const unsigned char *limit, SSL_SESSION **ret);
  
+ #endif
  int tls12_get_sigandhash(unsigned char *p, const EVP_PKEY *pk,
const EVP_MD *md);
  int tls12_get_sigid(const EVP_PKEY *pk);
  const EVP_MD *tls12_get_hash(unsigned char hash_alg);
  
  EVP_MD_CTX* ssl_replace_hash(EVP_MD_CTX **hash,const EVP_MD *md) ;
  void ssl_clear_hash_ctx(EVP_MD_CTX **hash);
  int ssl_add_serverhello_renegotiate_ext(SSL *s, unsigned char *p, int *len,

*** ./openssl-1.0.1e/ssl/t1_lib.c   Mon Feb 11 09:26:04 2013
--- ./openssl-1.0.1e-fixed/ssl/t1_lib.c Fri Apr 26 11:00:14 2013
*** static int nid_list[] =
*** 202,207 
--- 202,208 
NID_secp521r1  /* secp521r1 (25) */ 
};
  
+ #if !defined(OPENSSL_NO_TLSEXT) && !defined(OPENSSL_NO_EC)
  static int pref_list[] =
{
NID_sect571r1, /* sect571r1 (14) */ 
*** static int pref_list[] =
*** 230,235 
--- 231,237 
NID_secp160r1, /* secp160r1 (16) */ 
NID_secp160r2, /* secp160r2 (17) */ 
};
+ #endif
  
  int tls1_ec_curve_id2nid(int curve_id)
{
*** int tls1_ec_nid2curve_id(int nid)
*** 301,308 
}
  #endif /* OPENSSL_NO_EC */
  
- #ifndef OPENSSL_NO_TLSEXT
- 
  /* List of supported signature algorithms and hashes. Should make this
   * customisable at some point, for now include everything we support.
   */
--- 303,308 
*** int tls12_get_req_sig_algs(SSL *s, unsig
*** 360,365 
--- 360,367 
return (int)slen;
}
  
+ #ifndef OPENSSL_NO_TLSEXT
+ 
  unsigned char *ssl_add_clienthello_tlsext(SSL *s, unsigned char *p, unsigned 
char *limit)
{
int extdatalen=0;
*** static int tls_decrypt_ticket(SSL *s, co
*** 2276,2281 
--- 2278,2284 
 * ticket. */
return 2;
}
+ #endif /* OPENSSL_NO_TLSEXT */
  
  /* Tables to translate from NIDs to TLS v1.2 ids */
  
*** int tls1_process_sigalgs(SSL *s, const u
*** 2475,2482 
return 1;
}
  
- #endif
- 
  #ifndef OPENSSL_NO_HEARTBEATS
  int
  tls1_process_heartbeat(SSL *s)
--- 2478,2483 

___

[openssl.org #3036] openssl-0.9.8y config removes symbolic link /dev/null on Solaris

[Mitch Halmu via RT]

Greetings,

When running the config script on Solaris 9 (sparc), the symbolic link
/dev/null -> /devices/pseudo/mm@0:null is destroyed. You will notice it
happened by the error messages that start spewing. To repair:

# ln -s /devices/pseudo/mm@0:null /dev/null

Workaround: comment out the following lines before running config:

#($CC -Wa,--help -c -o /dev/null -x assembler /dev/null 2>&1 | \
# grep \\--noexecstack) 2>&1 > /dev/null && \
#  options="$options -Wa,--noexecstack"

Cheers,

Mitch Halmu

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3035] Patch to properly detect and default to 64bit on OSX

[Benjamin Black via RT]

openssl-1.0.1e-osx-64bit-build.patch
Description: Binary data

[openssl.org #3034] BUG REPORT: core dump when ssl renegociation

[Guillaume MULLER via RT]

Hi,

I had trouble accessing some https pages from Java, so I played with wget and 
got a core dump. Corentin (that I put in CC of this mail) from the "Loop" 
hackerspace in Paris, helped me trace this bug to come from OpenSSL. Please 
find more information below.

This bug occurs at least with an up-to-date ubuntu 12.10 with wget 1.13.4 and 
openssl 1.0.1c.

The exact commandline is:
$ wget --secure-protocol=sslv2 --no-check-certificate 
"https://web-ast.dsi.cnrs.fr/l3c/owa/annuaire.recherche/index.html";
--2013-04-18 13:53:51--  
https://web-ast.dsi.cnrs.fr/l3c/owa/annuaire.recherche/index.html
Aborted (core dumped)

If I remember correctly, the line that causes the error is:
mode[type] = 0
As a consequence, either 'mode' is uninitialized, or 'type' points to bad 
location.

--
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.10
DISTRIB_CODENAME=quantal
DISTRIB_DESCRIPTION="Ubuntu 12.10"

--
$ openssl
OpenSSL> version
OpenSSL 1.0.1c 10 May 2012

--
GNU Wget 1.13.4 built on linux-gnu.

+digest +https +ipv6 +iri +large-file +nls +ntlm +opie +ssl/openssl

Wgetrc:
 /etc/wgetrc (system)
Locale: /usr/share/locale
Compile: gcc -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/etc/wgetrc"
 -DLOCALEDIR="/usr/share/locale" -I. -I../../src -I../lib
 -I../../lib -D_FORTIFY_SOURCE=2 -Iyes/include -g -O2
 -fstack-protector --param=ssp-buffer-size=4 -Wformat
 -Wformat-security -Werror=format-security -DNO_SSLv2
 -D_FILE_OFFSET_BITS=64 -g -Wall
Link: gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
 -Wformat-security -Werror=format-security -DNO_SSLv2
 -D_FILE_OFFSET_BITS=64 -g -Wall -Wl,-Bsymbolic-functions
 -Wl,-z,relro -Lyes/lib -lssl -lcrypto -lz -ldl -lz -lidn -lrt
 ftp-opie.o openssl.o http-ntlm.o ../lib/libgnu.a

Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Originally written by Hrvoje Niksic .
Please send bug reports and questions to .

--
$ gdb ~/src/wget-1.13.4/src/wget
Reading symbols from ~/src/wget-1.13.4/src/wget...done.
(gdb) set args --secure-protocol=sslv2 --no-check-certificate 
"https://web-ast.dsi.cnrs.fr/l3c/owa/annuaire.recherche/index.html";
(gdb) break SSL_library_init
Breakpoint 1 at 0x404380
(gdb) run
Starting program: ~/src/wget-1.13.4/src/wget --secure-protocol=sslv2 
--no-check-certificate 
"https://web-ast.dsi.cnrs.fr/l3c/owa/annuaire.recherche/index.html";
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
--2013-04-17 22:24:27--
https://web-ast.dsi.cnrs.fr/l3c/owa/annuaire.recherche/index.html
...
Program received signal SIGABRT, Aborted.
0x76ff0425 in __GI_raise (sig=) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x76ff0425 in __GI_raise (sig=) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x76ff3b8b in __GI_abort () at abort.c:91
#2  0x0043c7c4 in ssl_init () at openssl.c:201
#3  0x0041da50 in gethttp (u=0x6750a0, hs=0x7fffdb10, 
dt=0x7fffe040, proxy=0x0, iri=0x675180, count=1) at http.c:1571
#4  0x00421060 in http_loop (u=0x6750a0, original_url=0x6750a0, 
newloc=0x7fffde20, local_file=0x7fffde28, referer=0x0, 
dt=0x7fffe040, proxy=0x0, iri=0x675180) at http.c:2769
#5  0x0042e76b in retrieve_url (orig_parsed=0x6750a0, origurl=0x675130 
"https://web-ast.dsi.cnrs.fr/l3c/owa/annuaire.recherche/index.html";, 
file=0x7fffdfb0, newloc=0x7fffdfb8, refurl=0x0, dt=0x7fffe040, 
recursive=false, iri=0x675180, register_status=true) at retr.c:736
#6  0x00428297 in main (argc=4, argv=0x7fffe178) at main.c:1394

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

FW: [openssl.org #3033] Bug Report: Make Error: can't encode register '%ch' in an instruction requiring REX prefix.

[Davis, Ellen via RT]

Never mind.  Updating to Xcode 4.6 fixed this.

Ellen Davis
UCit Instructional and Research Computing
P. O. Box 210088
Cincinnati OH 45221-0088
513-556-9013
ellen.da...@uc.edu

303 Zimmer Hall



-- Forwarded Message
From: Ellen Davis 
Date: Tue, 16 Apr 2013 11:55:37 -0400
To: 
Subject: Bug Report: Make Error: can't encode register '%ch' in an instruction 
requiring REX prefix.


Hello,

I am trying to build openssl.  The make does not complete because of the below 
error.

Operating system: Mac OSX 10.7.5
OpenSSL Version : openssl-1.0.1e

./Configure darwin64-x86_64-cc
make

...
cc -I../crypto -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM 
-DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM 
-DWHIRLPOOL_ASM -DGHASH_ASM   -c -o s3_clnt.o s3_clnt.c
/var/tmp//ccWABbwZ.s:869:can't encode register '%ch' in an instruction 
requiring REX prefix.




Ellen Davis
UCit Instructional and Research Computing
P. O. Box 210088
Cincinnati OH 45221-0088
513-556-9013
ellen.da...@uc.edu

303 Zimmer Hall




-- End of Forwarded Message

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3033] Bug Report: Make Error: can't encode register '%ch' in an instruction requiring REX prefix.

[Davis, Ellen via RT]

Hello,

I am trying to build openssl.  The make does not complete because of the below 
error.

Operating system: Mac OSX 10.7.5
OpenSSL Version : openssl-1.0.1e

./Configure darwin64-x86_64-cc
make

...
cc -I../crypto -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM 
-DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM 
-DWHIRLPOOL_ASM -DGHASH_ASM   -c -o s3_clnt.o s3_clnt.c
/var/tmp//ccWABbwZ.s:869:can't encode register '%ch' in an instruction 
requiring REX prefix.




Ellen Davis
UCit Instructional and Research Computing
P. O. Box 210088
Cincinnati OH 45221-0088
513-556-9013
ellen.da...@uc.edu

303 Zimmer Hall



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3032] Possible openssl bug - EVP_CIPHER_CTX_iv_length dont report correct value after EVP_CTRL_GCM_SET_IVLEN

[Bogdan via RT]

Hi

In my test program I noticed that EVP_CIPHER_CTX_iv_length dont report
correct value after EVP_CTRL_GCM_SET_IVLEN
The EVP_CIPHER_CTX_iv_length reports 12 instead of 16

The CTEXT changes as I change value from 12 to 16 in
EVP_CIPHER_CTX_ctrl(EVP_CTRL_GCM_SET_IVLEN) suggesting that the ivlen of 16
is active but is not reflected in the return from EVP_CIPHER_CTX_iv_length .

I am using following code.

EVP_CIPHER_CTX * ctx = new EVP_CIPHER_CTX;
EVP_CIPHER_CTX_init(ctx);
const EVP_CIPHER * cipher = EVP_aes_256_gcm();
printf("%-20s key.len=%2d iv.len=%2d bsize=%2d\n", "aes256gcm cipher",
EVP_CIPHER_key_length(cipher), EVP_CIPHER_iv_length(cipher),
EVP_CIPHER_block_size(cipher));

if(! EVP_CipherInit_ex(ctx, cipher, NULL, NULL, NULL, crypt_dir))
RPX_throw_opensslerror;
if(! EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_IVLEN, 16, NULL))
RPX_throw_opensslerror;
if(! EVP_CipherInit_ex(ctx, NULL, NULL, key, iv, crypt_dir))
RPX_throw_opensslerror;

printf("%-20s key.len=%2d iv.len=%2d bsize=%2d\n", "aes256gcm context",
EVP_CIPHER_CTX_key_length(ctx), EVP_CIPHER_CTX_iv_length(ctx),
EVP_CIPHER_CTX_block_size(ctx));


Cheers
Bog

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3031] [PATCH] Undef X509_NAME also in x509v3.h like x509.h

[Robin Lee via RT]

Hi, all.

Undef X509_NAME in x509_v3.h with the same codes in x509.h.

The following header file arrangement will make program fail to build with
MinGW:

#include 
#include   // Or any other header file that #define X509_NAME
#include 

int main(int argc, char *argv[]) {
return 0;
}


Undef X509_NAME again explicitly in x509_v3.h will make it compile.


Regards,
robin



OpenSSL_undef_X509_NAME_also_in_x509v3_h.diff
Description: Binary data

[openssl.org #3030] openssl 1.0.1 doesn't get response when negotiating connection to server needing TLSv1

[fromopen...@homelinkcs.com via RT]

With openssl 1.0.0j, I could connect to www.energydirect.com using:

openssl s_client -connect www.energydirect.com:443

But since my distribution upgraded to 1.0.1c, that command just shows 
"CONNECTED(0003)", hangs for a while, then eventually outputs:

write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 369 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---


If the -tls1 switch is used the connection will work, but unless this new 
behavior is intentional, this appears to be a regression.  Using -tls1 is okay 
for simple command-line use, but for higher level scripts which use openssl 
underneath, having to explicitly specify TLSv1 for this host is problematic.

This problem seems to still be present in the master and OpenSSL_1_0_1-stable 
git branchs.  By bisecting, I found that this change appears to have occured 
with commit 9472baae.

-- 
- Josh

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[PATCH]: Fix warning-level alert handling in OpenSSL 0.9.8

[mancha]

Hello.

OpenSSL 0.9.8y does not properly handle warning level
alerts in SSLv23 client method unlike OpensSSL 1.0.0+.

For example, when OpenSSL 0.9.8 initiates a connection
using TLS-SNI extensions in "SSLv23 mode" and the server
replies to client hello with an unrecognized_name warning
alert, the handshake terminates client-side.

This issue has been reported by many clients linked against
OpenSSL 0.9.8 (see footer links).

When connecting to a server that sends warning-level alerts
on hostname mismatch in TLS-SNI, eg.:

  $ openssl s_client -CApath /etc/ssl -connect \
$CorrectHostname:443 -servername $InvalidHostname \
-state < /dev/null 2>&1 | grep -E 'alert|error'

Current 0.9.8y behavior (output):
  SSL3 alert read:warning:unknown
  SSL_connect:error in SSLv2/v3 read server hello A
  7632:error:14077458:SSL
routines:SSL23_GET_SERVER_HELLO:reason(1112):s23_clnt.c:602:

Desired behavior (output) [consistent with OpenSSL 1.0.1e]:
  SSL3 alert read:warning:unrecognized name
  SSL3 alert write:warning:close notify

Patch applies cleanly to OpenSSL_0_9_8-stable (HEAD@a44c9b9c)
and makes behavior consistent with OpenSSL 1.0.1e. Also, it
adds support for new alerts (RFC 6066 and RFC 4279).

Please consider its inclusion after appropriate code review.

--mancha

Note: A higher-level discussion is whether non-fatal
unrecognized_name alerts should be sent at all. Per RFC 6066,
"If a server name is provided but not recognized, the server
should either continue the handshake without an error or send
a fatal error. Sending a warning-level message is not
recommended because client behavior will be unpredictable."

=

[1] http://marc.info/?l=openssl-users&m=131736995412529&w=2
[2] http://sourceforge.net/p/curl/bugs/1037/
[3] https://bugs.php.net/bug.php?id=61276
[4] https://github.com/joyent/node/issues/3033


0001-Fix-handling-of-warning-level-alerts-in-SSL23-client.patch
Description: Binary data