Cipher names available in OpenSSL 1.0.0d for SSL-TLS

[ml.vladimbelov]

some corrections...
I mean “ciphersuites” under “ciphers”.

Cipher names available in OpenSSL 1.0.0d for SSL-TLS

[ml.vladimbelov]

I have run test-file ssltest.exe and got next results:


Available compression methods:
  NONE
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 512 bit RSA
1 handshakes of 256 bytes done


On the page http://www.openssl.org/docs/apps/ciphers.html there is no such 
cipher. Why? Seems it is supported, but is absent in documentation.

But in the file tls1.h it is present. Can we assume that all ciphers that 
listed in the tls1.h are supported? 

Re: Compile OpenSSL for debug and release in Windows with Visual C++

[Mounir IDRASSI]

Yes, this the target configuration for debug under Windows VC++.

Cheers,
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr

On 6/22/2011 7:38 AM, ml.vladimbe...@gmail.com wrote:

Is “debug-VC-WIN32” option of configuration an answer to my question?


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Compile OpenSSL for debug and release in Windows with Visual C++

[ml.vladimbelov]

Is “debug-VC-WIN32” option of configuration an answer to my question?

Compile OpenSSL for debug and release in Windows with Visual C++

[ml.vladimbelov]

Hello.

Is OpenSSL configured by default for Release? I think so.

How can I configure it to compile for Debug build in Windows with Visual C++? 
What changes must I make in ntdll.mak/nt.mak?

Re: Replacement of functions that operate with sockets

[ml.vladimbelov]

Some corrections of SSL_EncryptApplicationData function. By SSL/TLS protocol 
data is send in packets not more than defined value(as i know 16Kb). That's why 
we must define this function differently and add one function for freeing 
buffers:

typedef struct TBUFS
{
 char *buf;
 int buf_len;
};

int SSL_EncryptApplicationData(char *buf_in, int buf_in_len, TBUFS 
*bufs_out, int bufs_out_count);
void SSL_FreeEncryptBuffes(TBUFS *buf, int bufs_out_count);

So this function must allocate memory for output buffers and fill them with 
encrypted data. After that I must only send these buffers over net through the 
socket.

RSA-OAEP with SHA-2?

[Cantor, Scott E.]

It appears that the padding functions for RSA PKCS1v2 assume SHA-1 as the
digest algorithm. Are there any plans to extend that, or is it the case
that the use of SHA-1 in this context doesn't cause concerns that other
usage does?

-- Scott

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: cross compiling for ARM running Android

[Nahid Alam]

OK, so finally it worked :)
Just download Android source, compile it targeting the ARM architecture.
Android has openssl in PATH_TO_ANDROID_BUILD/external/openssl
put you code in the appropriate place, compile, push it to your android
device and run

No need for Code Sourcery
Also, I don't think NDK is useful in this case as it doesn't include OpenSSL
support at this point.

On Mon, Jun 20, 2011 at 2:35 PM, Nahid Alam  wrote:

>
>
> On Mon, Jun 20, 2011 at 2:17 PM, Dave Thompson wrote:
>
>> >   From: owner-openssl-us...@openssl.org On Behalf Of Nahid Alam
>> >   Sent: Saturday, 18 June, 2011 19:00
>>
>> >   So I cross compiled OpenSSL following the link
>> > http://www.crosscompile.org/static/pages/OpenSSL.html
>>
>> That uses the 'dist' config with minimal tool changes,
>> which does static libraries (presumably) because there
>> is no single portable way to do shared libraries.
>> The only Configure case I see for ARM is linux-armv4
>> and it does do linux-shared, but I have no idea if that
>> works correctly on your target, or if you even want it.
>>
>
> >Can you please share how to do it?
>
>>
>> >   And used the following command
>> >   $ arm-none-linux-gnueabi-gcc -Wall -I/PATH_TO_INCLUDE_HEADER
>> > -L/PATH_TO_CROSS_COMPILED_OpenSSL_LIB  -lssl -lcrypto -o test test.c
>> >   But getting the errors:
>> >   openssl-arm-aes.c: In function 'main':
>> >   openssl-arm-aes.c:44:10: warning: unused variable 'e'
>> >   /tmp/ccaF9kYf.o: In function `time_aes':
>> >   openssl-arm-aes.c:(.text+0x1cc): undefined reference to
>> `EVP_CIPHER_CTX_init'
>> 
>> >   Looks like I am missing something really silly. Any suggestion?
>>
>> And most C implementations including gcc at least for
>> a static library, the library must be in the (linker)
>> command line AFTER the module(s) that reference it.
>> Also you don't need -lssl for EVP_* (but it doesn't hurt).
>>
>> But gcc (and binutils) should display your actual source
>> filename, allegedly 'test.c'. Unless you just changed
>> 'openssl-arm-aes.c' to 'test.c' for posting.
>>
>
> > Yes, I just put test.c to reduce the length of the command :)
>
>>
>>
>>
>> __
>> OpenSSL Project http://www.openssl.org
>> User Support Mailing Listopenssl-users@openssl.org
>> Automated List Manager   majord...@openssl.org
>>
>
>
>
> --
> Regards
> Nahid
>
>
>


-- 
Regards
Nahid

Re: Client Hello too large ?

[Lutz Jaenicke]

Am 21.06.2011 20:38, schrieb Alban Diquet:
> Yes, strange isn't it ?
> I guess it doesn't matter for 99% of the SSL clients, but for what I'm
> doing (a SSL scanner) it's kind of annoying.
> Well it's probably not going to change anytime soon, but now I want to
> know what's going on.
>
> > > When sending a Client Hello message that's larger than 270
> bytes (not sure
> > > what the exact limit is, 255 maybe?), lots of servers on the
> internet don't
> > > send back any Server Hello, but keep the connection open, so
> my client ends
> > > up returning a timeout.
> > > It's really weird, has anyone seen that behavior ?
> > > You can get to a 275 byte client hello for example by using
> OpenSSL 1.0.0.d
> > > with a TLS1 hello, all the cipher suites explicitly enabled
> > > 'ALL:NULL:@STRENGTH', and a non empty session ID field.
> > >
> >
> > Is that session ID still valid on the server when this happens?
> > Is it a session ID that the server issued to your client?
>
> I can reproduce this problem, perhaps it is an issue with the load
> balancers that terminate TLS at many large-scale HTTPS-enabled sites.
>
> For facebook, try:
>
>$ openssl s_client -msg -cipher 'ALL:NULL:@STRENGTH' -tls1
> -reconnect -connect 69.171.224.40:443 
>
> The above hangs on the reconnect client hello, while:
>
>$ openssl s_client -msg -cipher 'RC4-MD5:NULL:@STRENGTH' -tls1
> -reconnect -connect 69.171.224.40:443 
>
> yields:
>

It may actually be worth connecting the respective system administrator(s).

Finally you are not just wasting your system's rescources. You are also
wasting theirs.
We don't know what kind of resources you are wasting. It will most
likely only be a file descriptor
on the other side (hopefully for a service like facebook they have
plenty of these :-).
If you are triggering more resource hungry effects (memory, CPU cycles)
while you
see no response, you might have found a DoS on their side.

Best regards,
Lutz

Re: Client Hello too large ?

[Alban Diquet]

Yes, strange isn't it ?
I guess it doesn't matter for 99% of the SSL clients, but for what I'm doing
(a SSL scanner) it's kind of annoying.
Well it's probably not going to change anytime soon, but now I want to know
what's going on.

Alban


2011/6/21 Victor Duchovni 

> On Tue, Jun 21, 2011 at 05:43:57AM -0500, Michael S. Zick wrote:
>
> > > I've encountered a strange issue. It might not be related to OpenSSL
> itself,
> > > but maybe it is.
> > >
> > > When sending a Client Hello message that's larger than 270 bytes (not
> sure
> > > what the exact limit is, 255 maybe?), lots of servers on the internet
> don't
> > > send back any Server Hello, but keep the connection open, so my client
> ends
> > > up returning a timeout.
> > > It's really weird, has anyone seen that behavior ?
> > > You can get to a 275 byte client hello for example by using OpenSSL
> 1.0.0.d
> > > with a TLS1 hello, all the cipher suites explicitly enabled
> > > 'ALL:NULL:@STRENGTH', and a non empty session ID field.
> > >
> >
> > Is that session ID still valid on the server when this happens?
> > Is it a session ID that the server issued to your client?
>
> I can reproduce this problem, perhaps it is an issue with the load
> balancers that terminate TLS at many large-scale HTTPS-enabled sites.
>
> For facebook, try:
>
>$ openssl s_client -msg -cipher 'ALL:NULL:@STRENGTH' -tls1 -reconnect
> -connect 69.171.224.40:443
>
> The above hangs on the reconnect client hello, while:
>
>$ openssl s_client -msg -cipher 'RC4-MD5:NULL:@STRENGTH' -tls1
> -reconnect -connect 69.171.224.40:443
>
> yields:
>
> Reused, TLSv1/SSLv3, Cipher is RC4-MD5
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
>Protocol  : TLSv1
>Cipher: RC4-MD5
>Session-ID:
> 197E266EAC6CDD1CA9BAFD0AFB6EDB9CB63407EC1046131A59F33766BF3BB5E9
>Session-ID-ctx:
>Master-Key: ...
>Key-Arg   : None
>PSK identity: None
>PSK identity hint: None
>Start Time: 1308667111
>Timeout   : 7200 (sec)
>Verify return code: 20 (unable to get local issuer certificate)
>
> So session re-use works, but not when the hello is:
>
> >>> TLS 1.0 Handshake [length 0118], ClientHello
>01 00 01 14 03 01 4e 00 ad 60 11 e7 93 d1 b3 46
>8f be 77 1d 68 c5 dd c0 d2 94 60 f5 32 b3 e5 ee
>68 a6 e4 c5 0a da 20 19 7e 26 6e ac 6c a4 43 a9
>ba fd 0a fb 6e dd 9d da dd af f4 4c d9 d5 56 59
>f3 37 66 bf 3b b4 70 00 86 c0 14 c0 0a 00 39 00
>38 00 88 00 87 c0 19 00 3a 00 89 c0 0f c0 05 00
>35 00 84 c0 12 c0 08 00 16 00 13 c0 17 00 1b c0
>0d c0 03 00 0a c0 13 c0 09 00 33 00 32 00 9a 00
>99 00 45 00 44 c0 18 00 34 00 9b 00 46 c0 0e c0
>04 00 2f 00 96 00 41 00 07 c0 11 c0 07 c0 16 00
>18 c0 0c c0 02 00 05 00 04 00 15 00 12 00 1a 00
>09 00 14 00 11 00 19 00 08 00 06 00 17 00 03 c0
>10 c0 06 c0 15 c0 0b c0 01 00 02 00 01 00 ff 02
>01 00 00 44 00 0b 00 04 03 00 01 02 00 0a 00 34
>00 32 00 01 00 02 00 03 00 04 00 05 00 06 00 07
>00 08 00 09 00 0a 00 0b 00 0c 00 0d 00 0e 00 0f
>00 10 00 11 00 12 00 13 00 14 00 15 00 16 00 17
>00 18 00 19 00 23 00 00
>
> as with 'ALL:NULL:@STRENGTH'.
>
> --
>Viktor.
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager   majord...@openssl.org
>

Re: ext session cache issues

[Mark Ellzey]

Ignore this - was not using v3, sorry.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

ext session cache issues

[Mark Ellzey]

Greetings,
 
I recently ran into an issue where the user-defined session cache
functions are not being called. I had a look at latest snapshot running
openssl s_server -ext_cache which also seems to exhibit the problem.  

The problem seems to be in ssl/ssl_sess.c around line 457:

r = tls1_process_ticket(s, session_id, len, limit, &ret);
if (r == -1)
{
fatal = 1; 
goto err; 
}   
 
else if (r == 0 || (!ret && !len))
goto err; 

In the case of s_server: len is > 0 and ret is 0 and it takes this
branch, never executing the get callback. Should this be "((!ret &&
!len) || (r == 0 && !len))"? 
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Client Hello too large ?

[Victor Duchovni]

On Tue, Jun 21, 2011 at 05:43:57AM -0500, Michael S. Zick wrote:

> > I've encountered a strange issue. It might not be related to OpenSSL itself,
> > but maybe it is.
> > 
> > When sending a Client Hello message that's larger than 270 bytes (not sure
> > what the exact limit is, 255 maybe?), lots of servers on the internet don't
> > send back any Server Hello, but keep the connection open, so my client ends
> > up returning a timeout.
> > It's really weird, has anyone seen that behavior ?
> > You can get to a 275 byte client hello for example by using OpenSSL 1.0.0.d
> > with a TLS1 hello, all the cipher suites explicitly enabled
> > 'ALL:NULL:@STRENGTH', and a non empty session ID field.
> >
> 
> Is that session ID still valid on the server when this happens?
> Is it a session ID that the server issued to your client?

I can reproduce this problem, perhaps it is an issue with the load
balancers that terminate TLS at many large-scale HTTPS-enabled sites.

For facebook, try:

$ openssl s_client -msg -cipher 'ALL:NULL:@STRENGTH' -tls1 -reconnect 
-connect 69.171.224.40:443

The above hangs on the reconnect client hello, while:

$ openssl s_client -msg -cipher 'RC4-MD5:NULL:@STRENGTH' -tls1 -reconnect 
-connect 69.171.224.40:443

yields:

Reused, TLSv1/SSLv3, Cipher is RC4-MD5
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1
Cipher: RC4-MD5
Session-ID: 197E266EAC6CDD1CA9BAFD0AFB6EDB9CB63407EC1046131A59F33766BF3BB5E9
Session-ID-ctx: 
Master-Key: ...
Key-Arg   : None
PSK identity: None
PSK identity hint: None
Start Time: 1308667111
Timeout   : 7200 (sec)
Verify return code: 20 (unable to get local issuer certificate)

So session re-use works, but not when the hello is:

>>> TLS 1.0 Handshake [length 0118], ClientHello
01 00 01 14 03 01 4e 00 ad 60 11 e7 93 d1 b3 46
8f be 77 1d 68 c5 dd c0 d2 94 60 f5 32 b3 e5 ee
68 a6 e4 c5 0a da 20 19 7e 26 6e ac 6c a4 43 a9
ba fd 0a fb 6e dd 9d da dd af f4 4c d9 d5 56 59
f3 37 66 bf 3b b4 70 00 86 c0 14 c0 0a 00 39 00
38 00 88 00 87 c0 19 00 3a 00 89 c0 0f c0 05 00
35 00 84 c0 12 c0 08 00 16 00 13 c0 17 00 1b c0
0d c0 03 00 0a c0 13 c0 09 00 33 00 32 00 9a 00
99 00 45 00 44 c0 18 00 34 00 9b 00 46 c0 0e c0
04 00 2f 00 96 00 41 00 07 c0 11 c0 07 c0 16 00
18 c0 0c c0 02 00 05 00 04 00 15 00 12 00 1a 00
09 00 14 00 11 00 19 00 08 00 06 00 17 00 03 c0
10 c0 06 c0 15 c0 0b c0 01 00 02 00 01 00 ff 02
01 00 00 44 00 0b 00 04 03 00 01 02 00 0a 00 34
00 32 00 01 00 02 00 03 00 04 00 05 00 06 00 07
00 08 00 09 00 0a 00 0b 00 0c 00 0d 00 0e 00 0f
00 10 00 11 00 12 00 13 00 14 00 15 00 16 00 17
00 18 00 19 00 23 00 00

as with 'ALL:NULL:@STRENGTH'.

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Client Hello too large ?

[Michael S. Zick]

On Mon June 20 2011, Alban Diquet wrote:
> Hi all,
> 
> I've encountered a strange issue. It might not be related to OpenSSL itself,
> but maybe it is.
> 
> When sending a Client Hello message that's larger than 270 bytes (not sure
> what the exact limit is, 255 maybe?), lots of servers on the internet don't
> send back any Server Hello, but keep the connection open, so my client ends
> up returning a timeout.
> It's really weird, has anyone seen that behavior ?
> You can get to a 275 byte client hello for example by using OpenSSL 1.0.0.d
> with a TLS1 hello, all the cipher suites explicitly enabled
> 'ALL:NULL:@STRENGTH', and a non empty session ID field.
>

Is that session ID still valid on the server when this happens?
Is it a session ID that the server issued to your client?

Mike
> Then feel free to test it on Facebook.
> Does anyone know what's going on there ?
> 
> Thanks,
> 
> 
> Alban Diquet
> 


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Replacement of functions that operate with sockets

[ml.vladimbelov]

Jim Segrave wrote:


Why not simply create a second socket - your app reads from that, does
whatever is needed and writes to the openssl socket. When openssl
writes to its socket, you read it, do whatever, then write it out your
socket?


Jim, for me  the main goal to replace functions that operate with sockets is 
performance. I want to use OpenSSL with Windows IO Completion ports. The 
method that you suggest is very interesting but the main is not achieved - 
OpenSSL is still writing to the socket. Besides we got so-called "double 
buffering" and also more memory usage because of 2 sockets.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Replacement of functions that operate with sockets

[ml.vladimbelov]

David Schwartz wrote:
Well that wouldn't work as stated. How would OpenSSL know when it was time 
to call WriteSocket? You will have to call into OpenSSL when you want to 
see if has any data it needs to write to the socket.


In fact, you will have to manage *four* I/O streams to and from OpenSSL. 
When you receive encrypted data from the socket, you will have to hand it 
to OpenSSL. When you know it is safe to write to the socket, you will need 
to check if OpenSSL has any encrypted data to send and if so, read it from 
OpenSSL and send it to the other side. When anything changes, you will 
also need to check if OpenSSL has any decrypted plaintext to deliver to 
your application. And you will have to pass any plaintext your application 
wish to send to OpenSSL.



Ok. I'll try to explain my idea in details. Generally we'll need 4 main and 
3 additional functions. One of 4 main functions is callback function that is 
calling by OpenSSL library itself. There are two types of "socket IO". The 
first is that OpenSSL Library making by itself and programmer don't know 
about this IO, and must not to know, it's like a blackbox - SSL-TLS protocol 
specific IO. For this IO we need 2 functions SysWriteToSocket and 
SSL_ReadArrivedFromSocketData. SysWriteSocket is implemented by programmer, 
it is an asynchronous function and may be defined so:


   int SysWriteToSocket(char *buf,int buf_len);

and incorporates with OpenSSL by means of the following function:

   typedef int (*FSysWriteToSocket)(char *,int);
   void SSL_SetSysWriteToSocketFunction(FSysWriteToSocket fun);

When OpenSSL want to write some data to the socket it calls asynchronous 
SysWriteToSocket function.


When I(programmer) receive any data from socket I must call 
SSL_ReadArrivedFromSocketData and OpenSSL can process the arrived data. It 
may be defined so:


   int SSL_ReadArrivedFromSocketData(char *buf, int buf_len)

One of the returning values of this function may be the flag that indicates 
about existing decrypted application data that could be read.
After that and also at any time I can call SSL_GetApplicationData to read 
application data or determine if any application data is available for 
reading:


   int SSL_GetApplicationDataSize();
   int SSL_GetApplicationData(char *buf, int buf_len,int *need_buf_len);

The result of these functions is number of bytes of available and written 
application data accordingly, if success.
[need_buf_len] - the necessary size of the buffer if buf_len is not enough 
to contain all data


The fourth function is SSL_EncryptUserData, which encrypt our own 
application data before we can send their to secure channel:


   int SSL_EncryptApplicationData(char *buf_in, int buf_in_len, char 
buf_out, int buf_out_len, int *need_buf_out_len);


The result of this function is number of bytes written to the buf_out 
buffer, if success.
[need_buf_out_len] - the necessary size of the output buffer if buf_out_len 
is not enough to contain all data


When I(programmer) need to send any data to the secure socket I am calling 
SSL_EncryptUserData and after this I send encrypted data from buf_out to the 
socket.


Also we need to define one status function SSL_GetCurrentSocketIOState:

   int SSL_GetCurrentIOState();

This function would return such values as:
SSL_SYS_DATA_WRITING
SSL_SYS_WAITING_DATA_READING
SSL_SYS_DATA_READING
SSL_SYS_OPERATION_TIMEOUT
SSL_APPLICATION_DATA_READING
SSL_READY_TO_TRANSFER_APPLICATION_DATA
... and so on, all what we need.


These functions let us manipulate with sockets ourself, as we want.


David Schwartz wrote:

Look at the example code that uses BIO pairs.


Please say where can I find this example code? What is the name of c-file?



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Replacement of functions that operate with sockets

[Jim Segrave]

On Mon 20 Jun 2011 (11:00 -0700), David Schwartz wrote:
> On 6/15/2011 11:57 AM, ml.vladimbe...@gmail.com wrote:
>> Hello.
>> By default OpenSSL itself works with sockets. I would want to implement
>> operation with sockets without admitting it to OpenSSL. I.e. for
>> example, when OpenSSL wants to write down something in a socket, it
>> should cause my function and I will transfer data to the socket. And it
>> is exact also obtaining the data from a socket I cause a function of
>> OpenSSL, transferring to it the data accepted from a socket.
>> I.e. I implement function WriteSocket. When OpenSSL wants to write
>> something in a socket, it causes WriteSocket and nothing more it should
>> disturb.
>
> Well that wouldn't work as stated. How would OpenSSL know when it was time 
> to call WriteSocket? You will have to call into OpenSSL when you want to 
> see if has any data it needs to write to the socket.
>
> In fact, you will have to manage *four* I/O streams to and from OpenSSL. 
> When you receive encrypted data from the socket, you will have to hand it 
> to OpenSSL. When you know it is safe to write to the socket, you will need 
> to check if OpenSSL has any encrypted data to send and if so, read it from 
> OpenSSL and send it to the other side. When anything changes, you will also 
> need to check if OpenSSL has any decrypted plaintext to deliver to your 
> application. And you will have to pass any plaintext your application wish 
> to send to OpenSSL.

Why not simply create a second socket - your app reads from that, does
whatever is needed and writes to the openssl socket. When openssl
writes to its socket, you read it, do whatever, then write it out your
socket?

-- 
Jim Segrave   j...@j-e-s.net


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org