[openssl-dev] [openssl.org #3914] Library on Windows does not export SSL_CTX_set_options or SSL_set_options

2015-06-17 Thread noloa...@gmail.com via RT
I was kind of surprised to learn this... The SSL library on Windows
does not export SSL_CTX_set_options or SSL_set_options.

Below is a dumpbin /exports of ssleay.dll.

*

543E8F47 time date stamp Wed Oct 15 11:14:15 2014
0.00 version
   1 ordinal base
 362 number of functions
 281 number of names
ordinal hint RVA  name
1210 00038190 BIO_f_ssl
1731 00038CE0 BIO_new_buffer_ssl_connect
1222 00038AD0 BIO_new_ssl
1743 00038C30 BIO_new_ssl_connect
1244 00038B70 BIO_ssl_copy_session_id
1315 00038BF0 BIO_ssl_shutdown
2686 00023910 DTLSv1_client_method
2737 0001F780 DTLSv1_method
2758 00021BB0 DTLSv1_server_method
  19 00038D50 ERR_load_SSL_strings
301A 0002F8A0 PEM_read_SSL_SESSION
302B 0002F860 PEM_read_bio_SSL_SESSION
305C 0002F930 PEM_write_SSL_SESSION
296D 0002F8E0 PEM_write_bio_SSL_SESSION
332E 00039AD0 SRP_Calc_A_param
335F 000397F0 SRP_generate_client_master_secret
333   10 000396A0 SRP_generate_server_master_secret
  2   11 00032730 SSL_CIPHER_description
128   12 00032D60 SSL_CIPHER_get_bits
349   13 00032D80 SSL_CIPHER_get_id
130   14 00032D40 SSL_CIPHER_get_name
129   15 00032D00 SSL_CIPHER_get_version
184   16 00032E30 SSL_COMP_add_compression_method
276   17 00032E10 SSL_COMP_get_compression_methods
271   18 00032FD0 SSL_COMP_get_name
334   19 00038D90 SSL_CTX_SRP_CTX_free
330   1A 00039260 SSL_CTX_SRP_CTX_init
  3   1B 0002E9A0 SSL_CTX_add_client_CA
  4   1C 0003 SSL_CTX_add_session
243   1D 0002A690 SSL_CTX_callback_ctrl
  5   1E 0002A0B0 SSL_CTX_check_private_key
  6   1F 0002A440 SSL_CTX_ctrl
  7   20 0002FF60 SSL_CTX_flush_sessions
  8   21 0002ADB0 SSL_CTX_free
180   22 00029AB0 SSL_CTX_get_cert_store
  9   23 0002E8A0 SSL_CTX_get_client_CA_list
288   24 0002F470 SSL_CTX_get_client_cert_cb
138   25 0002C0F0 SSL_CTX_get_ex_data
167   26 0002C090 SSL_CTX_get_ex_new_index
282   27 0002F770 SSL_CTX_get_info_callback
140   28 0002BDB0 SSL_CTX_get_quiet_shutdown
179   29 0002F4F0 SSL_CTX_get_timeout
 10   2A 00029E70 SSL_CTX_get_verify_callback
228   2B 00029E50 SSL_CTX_get_verify_depth
 11   2C 00029E40 SSL_CTX_get_verify_mode
141   2D 0002BF90 SSL_CTX_load_verify_locations
 12   2E 0002D210 SSL_CTX_new
 13   2F 00030220 SSL_CTX_remove_session
279   30 0002F750 SSL_CTX_sess_get_get_cb
287   31 0002F710 SSL_CTX_sess_get_new_cb
289   32 0002F730 SSL_CTX_sess_get_remove_cb
280   33 0002F740 SSL_CTX_sess_set_get_cb
278   34 0002F700 SSL_CTX_sess_set_new_cb
285   35 0002F720 SSL_CTX_sess_set_remove_cb
245   36 0002A430 SSL_CTX_sessions
310   37 000299D0 SSL_CTX_set1_param
181   38 0002C120 SSL_CTX_set_cert_store
232   39 0002AF40 SSL_CTX_set_cert_verify_callback
 15   3A 0002A7D0 SSL_CTX_set_cipher_list
 16   3B 0002E840 SSL_CTX_set_client_CA_list
284   3C 0002F780 SSL_CTX_set_client_cert_cb
293   3D 0002F790 SSL_CTX_set_client_cert_engine
283   3E 0002F840 SSL_CTX_set_cookie_generate_cb
281   3F 0002F850 SSL_CTX_set_cookie_verify_cb
 17   40 0002AF20 SSL_CTX_set_default_passwd_cb
235   41 0002AF30 SSL_CTX_set_default_passwd_cb_userdata
142   42 0002BF70 SSL_CTX_set_default_verify_paths
143   43 0002C0D0 SSL_CTX_set_ex_data
264   44 00029770 SSL_CTX_set_generate_session_id
286   45 0002F760 SSL_CTX_set_info_callback
266   46 0002C4F0 SSL_CTX_set_msg_callback
361   47 0002AC90 SSL_CTX_set_next_proto_select_cb
355   48 0002AC80 SSL_CTX_set_next_protos_advertised_cb
295   49 0002C4C0 SSL_CTX_set_psk_client_callback
303   4A 0002C4E0 SSL_CTX_set_psk_server_callback
238   4B 00029950 SSL_CTX_set_purpose
145   4C 0002BDA0 SSL_CTX_set_quiet_shutdown
231   4D 000296B0 SSL_CTX_set_session_id_context
328   4E 00039C70 SSL_CTX_set_srp_cb_arg
316   4F 00039CB0 SSL_CTX_set_srp_client_pwd_callback
324   50 00039C10 SSL_CTX_set_srp_password
325   51 00039C30 SSL_CTX_set_srp_strength
329   52 00039BF0 SSL_CTX_set_srp_username
318   53 00039C90 SSL_CTX_set_srp_username_callback
326   54 00039C50 SSL_CTX_set_srp_verify_param_callback
 19   55 00029630 SSL_CTX_set_ssl_version
178   56 0002F4E0 SSL_CTX_set_timeout
358   57 00028FD0 SSL_CTX_set_tlsext_use_srtp
176   58 0002C1E0 SSL_CTX_set_tmp_dh_callback
269   59 0002C240 SSL_CTX_set_tmp_ecdh_callback
177   5A 0002C180 

Re: [openssl-dev] [openssl.org #3914] Library on Windows does not export SSL_CTX_set_options or SSL_set_options

2015-06-17 Thread Joey Yandle

I was kind of surprised to learn this... The SSL library on Windows
does not export SSL_CTX_set_options or SSL_set_options.


That's because it's a macro:

grep -r SSL_CTX_set_options | grep define

ssl/ssl.h:# define SSL_CTX_set_options(ctx,op) \

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3914] Library on Windows does not export SSL_CTX_set_options or SSL_set_options

2015-06-17 Thread Joey Yandle via RT
 I was kind of surprised to learn this... The SSL library on Windows
 does not export SSL_CTX_set_options or SSL_set_options.

That's because it's a macro:

grep -r SSL_CTX_set_options | grep define

ssl/ssl.h:# define SSL_CTX_set_options(ctx,op) \


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] 32 bit compilation of armv8 assembly support(openssl-1.0.2a)

2015-06-17 Thread Andy Polyakov
First of all let's establish ground rule. In order for something to be
supported we ought to have access to platform, hardware is preferred,
emulator can be acceptable. It naturally also includes tool chain and
minimal ecosystem in form of working run-time. You refer to
releases.linaro.org, but is there mabi=ilp32 libc? I don't see one. I
have Debian jessie on 96board, but is there ilp32 libc available? I
don't see one. Is executable format in question widely supported by
kernel? Mine says exec format error... In other words to me ilp32 is
not viable option, which makes it impossible to support at this point.

 I am compiling using the linaro aarch64 compiler for ILP32 ABI.
 *linux-armv4 *compilation
 with option -march =armv8_a  giving lots of compilation errors as
 compiler does not
 supports mnemonics  . So I have tried to compile with new configuration
 for ilp32
 with aarch64_asm.
 
 linux-armilp32,gcc: -O3 -mabi=ilp32 -Wall::-D_REENTRANT::-ldl:
 SIXTY_FOUR_BIT RC4_CHAR RC4_CHUNK  DES_INT DES_UNROLL BF_PTR:
 ${aarch64_asm}::dlfcn:linux-shared:-fPIC:-mabi=ilp32:
 .so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
 
 In compilation with this configuration getting error* cannot represent 
 BFD_RELOC_64 relocation in this object file format *in sha1-armv8.s.  

Obviously it would require some adjustments, because mabi=ilp32 was not
considered when it was written. It might be sufficient to replace .quad
with .long, but there is no way for me to tell for reasons discussed in
the beginning. So that if there is some serious interest, then you have
to explain yourself better than providing reference to releases.linaro.org.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3914] Library on Windows does not export SSL_CTX_set_options or SSL_set_options

2015-06-17 Thread noloa...@gmail.com via RT
Dooh I should have known :(

Sorry about the extra noise.

On Wed, Jun 17, 2015 at 5:10 PM, Joey Yandle via RT r...@openssl.org wrote:
 I was kind of surprised to learn this... The SSL library on Windows
 does not export SSL_CTX_set_options or SSL_set_options.

 That's because it's a macro:

 grep -r SSL_CTX_set_options | grep define

 ssl/ssl.h:# define SSL_CTX_set_options(ctx,op) \



___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] [openssl.org #3912] OpenSSL 0.9.8zg crashes with s_client param.

2015-06-17 Thread Rich Salz via RT
0.9.8 only gets security fixes; this seems like a crashed caused by incorrect
arguments.
closing.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] ARM optimised montgomery multiplication (armv4-mont)

2015-06-17 Thread Andy Polyakov
Hi,

 When using on armv8 architecture, does this mont mul ASM code have
 any optimization with linux-aarch64 configuration?

There is ambiguity in posed question. In direct context of this
discussion this as in this mont mul ASM code ought to refer to
armv4-mont. And then the answer would have to be no, ARMv4 code can not
used in aarch64 build. But it's also possible to generalize and
consider this more like this thing, Montgomery multiplication module,
you are talking about, is there aarch64 equivalent? And answer to such
question would be yes, there is corresponding armv8-mont module in
development branch.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] SNI/ALPN ordering

2015-06-17 Thread Stefan Eissing
*NOT A SECURITY ISSUE*

That our of the way: while debugging my HTTP/2 module for Apache httpd, I see 
that the callback for SNI seems to be invoked *after* the callback for ALPN had 
been called (OpenSSL 1.0.2c). Can this be correct? Is there anything to 
influence this ordering?

My issue is that the proposed ALPN protocols depend on the virtual host the 
client wants to talk to. So, the observed order poses a bit of a problem. The 
code *can* check the server name via SSL_get_servername() and the correct name 
is reported. However this is not how it is supposed to work, right?

Again, if there is anything influencing the order of the callback invocation, 
I'd be willing to adapt. Otherwise, I think, the order needs to be defined in 
the OpenSSL API and it should be SNI before ALPN. 

Cheers,

  Stefan


green/bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782



___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] ARM optimised montgomery multiplication (armv4-mont)

2015-06-17 Thread Ravichandra
Hi Andy,
When using on armv8 architecture, does this mont mul ASM code have any
optimization with linux-aarch64 configuration?

Thanks
Ravichandra

On Wed, Jun 17, 2015 at 3:06 PM, Andy Polyakov ap...@openssl.org wrote:

 Hi,

  With some experimentation, it turns out that if I *stop* using the
  crypto/bn/asm/bn/armv4-mont.pl generated asm optimised version,
 the time for
  a simplish test to establish and close a simple SSL connection went
 from 28
  seconds to 18. (It's quite a slow target at any time).
 
  In other words, this optimised version has slowed things down
 dramatically.
  Has anyone queried the value of the asm of armv4-mont.pl any time
 in the last
  few years?
  [snip]
 
  I found the cause - although OPENSSL_BN_ASM_MONT was defined, I hadn't
 noticed
  that a colleague had put a #define OPENSSL_NO_ASM somewhere else (this
 isn't
  linux but a port to our own OS). It turns out that (surprisingly) this
  combination changes behaviour rather than barfing - it's even explicitly
  catered for in bn_asm.c.

 In other words sanity restored. Phew! Incidentally, as next step I was
 going to ask for copy of your bn_asm.o (yes, binary .o, yes, bn_asm.o,
 not armv4-mont.o), and bn_mul_mont should have shown up and presumably
 noticed as unexpected...

  Regardless, the effect is that a different bn_mul_mont implementation
 gets
  used, and the armv4-mont.pl implementation gets ignored entirely.

 Right. And as mentioned in commentary bn_mul_mont in bn_asm.c is just a
 template with no performance promises attached. Note that it still
 exhibits previously mentioned breaking point...

  With that fixed, I now have greatly improved performance as expected.

 So that with armv4-mont actually in the loop, the breaking point is
 still beyond practical key lengths, even on ARM9.

  An
  unfortunate waste of time for us both, but thanks for the assistance.

 Given that presented timings for ARM9 are kind of astronomic you might
 want to consider if it's possible to use other algorithms. EC is getting
 wider adoption now and can perform better. Not to mention that optimized
 NIST P-256 EC was recently added...

 Cheers.

 ___
 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] [openssl.org #3912] OpenSSL 0.9.8zg crashes with s_client param.

2015-06-17 Thread Matt Caswell via RT
On Wed Jun 17 07:00:12 2015, nore...@send-email.org wrote:
 OpenSSL 0.9.8ge crashes with the following parameter openssl.exe
 s_client on
 Win32 platoform. 1.0.0s does not have this bug. Event: BEX

I just looked into this. It seems s_client on 0.9.8 crashes if it is unable to
connect to open a socket to the server. It looks like this bug has been there
for a while. As Rich said, 0.9.8 is only receiving security fixes now so this
isn't going to be fixed - especially as there is an easy workaround (make sure
s_client connects!!!)

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] [openssl.org #3912] OpenSSL 0.9.8zg crashes with s_client param.

2015-06-17 Thread nore...@send-email.org via RT
OpenSSL 0.9.8ge crashes with the following parameter openssl.exe s_client on
Win32 platoform. 1.0.0s does not have this bug. Event: BEX Application:
openssl.exe TimeStamp: 557ae67e Offset: 0003fb70 ExceptionCode: c417
ExceptionData:  OS: 6.1.7601.2.1.0.256.48 LocaleID: 1041 Info1: 8d30
Info2: 8d30fe76231fde0d8591f9e28ccb5915 Info3: 7e30 Info4:
7e30565054b1b6b6911327a78f804968

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] [openssl.org #3913] [RFE] Add a way to application to know a minimum DH size allowed by the client

2015-06-17 Thread Tomas Mraz via RT
The current minimum DH size allowed by the client is 768 bits which is a
hardcoded constant. It would be nice if the constant was at least
#define in public headers or even better if there was an API to query
various minimum and maximum bit sizes that are checked in the library
such as the maximum supported key lengths, etc.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] ARM optimised montgomery multiplication (armv4-mont)

2015-06-17 Thread Andy Polyakov
Hi,

 With some experimentation, it turns out that if I *stop* using the
 crypto/bn/asm/bn/armv4-mont.pl generated asm optimised version, the 
 time for
 a simplish test to establish and close a simple SSL connection went from 
 28
 seconds to 18. (It's quite a slow target at any time).

 In other words, this optimised version has slowed things down 
 dramatically.
 Has anyone queried the value of the asm of armv4-mont.pl any time in the 
 last
 few years?
 [snip]
 
 I found the cause - although OPENSSL_BN_ASM_MONT was defined, I hadn't noticed
 that a colleague had put a #define OPENSSL_NO_ASM somewhere else (this isn't
 linux but a port to our own OS). It turns out that (surprisingly) this
 combination changes behaviour rather than barfing - it's even explicitly
 catered for in bn_asm.c.

In other words sanity restored. Phew! Incidentally, as next step I was
going to ask for copy of your bn_asm.o (yes, binary .o, yes, bn_asm.o,
not armv4-mont.o), and bn_mul_mont should have shown up and presumably
noticed as unexpected...

 Regardless, the effect is that a different bn_mul_mont implementation gets
 used, and the armv4-mont.pl implementation gets ignored entirely.

Right. And as mentioned in commentary bn_mul_mont in bn_asm.c is just a
template with no performance promises attached. Note that it still
exhibits previously mentioned breaking point...

 With that fixed, I now have greatly improved performance as expected.

So that with armv4-mont actually in the loop, the breaking point is
still beyond practical key lengths, even on ARM9.

 An
 unfortunate waste of time for us both, but thanks for the assistance.

Given that presented timings for ARM9 are kind of astronomic you might
want to consider if it's possible to use other algorithms. EC is getting
wider adoption now and can perform better. Not to mention that optimized
NIST P-256 EC was recently added...

Cheers.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] ARM optimised montgomery multiplication (armv4-mont)

2015-06-17 Thread Ravichandra
I meant armv4-mont code. As the answer to that question is no, i would have
asked if we have a support for armv8-mont. Your response answers both of my
questions.

Thanks
Ravichandra

On Wed, Jun 17, 2015 at 5:41 PM, Andy Polyakov ap...@openssl.org wrote:

 Hi,

  When using on armv8 architecture, does this mont mul ASM code have
  any optimization with linux-aarch64 configuration?

 There is ambiguity in posed question. In direct context of this
 discussion this as in this mont mul ASM code ought to refer to
 armv4-mont. And then the answer would have to be no, ARMv4 code can not
 used in aarch64 build. But it's also possible to generalize and
 consider this more like this thing, Montgomery multiplication module,
 you are talking about, is there aarch64 equivalent? And answer to such
 question would be yes, there is corresponding armv8-mont module in
 development branch.

 ___
 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] 32 bit compilation of armv8 assembly support(openssl-1.0.2a)

2015-06-17 Thread gaurav maheshwari
I am compiling using the linaro aarch64 compiler for ILP32 ABI. *linux-armv4
*compilation
with option -march =armv8_a  giving lots of compilation errors as compiler
does not
supports mnemonics  . So I have tried to compile with new configuration for
ilp32
with aarch64_asm.

linux-armilp32,gcc: -O3 -mabi=ilp32 -Wall::-D_REENTRANT::-ldl:
SIXTY_FOUR_BIT RC4_CHAR RC4_CHUNK  DES_INT DES_UNROLL BF_PTR:
${aarch64_asm}::dlfcn:linux-shared:-fPIC:-mabi=ilp32:
.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),

In compilation with this configuration getting error
* cannot represent BFD_RELOC_64 relocation in this object file
format *in sha1-armv8.s.


linaro compiler path (
http://releases.linaro.org/14.11/components/toolchain/binaries/aarch64-linux-gnu
).

On Thu, Jun 11, 2015 at 1:52 PM, Andy Polyakov ap...@openssl.org wrote:

 Hi,

 Can we use armv8 assembly support provided in openssl-1.0.2a for
  32 bit mode compilation.

 It *is* used in 32-bit compilation as-is. aesv8-armx and ghashv8-armx
 are included in armv4_asm, and sha1-armv4-large and sha256-armv4 modules
 incorporate support for ARMv8 SHA instructions. But don't miss
 commentary in Configure prior linux-armv4 line.

 ___
 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