SSL handshake with a web server using Memory BIOs?

[doa379]

Suppose the TLS layer is initialized in the form:

  SSL_CTX *ctx = SSL_CTX_new(TLS_client_method());
  BIO *r = BIO_new(BIO_s_mem());
  BIO *w = BIO_new(BIO_s_mem());
  SSL *ssl = SSL_new(ctx);
  SSL_set_bio(ssl, r, w);
  SSL_set_connect_state(ssl);

I want to use BIO so that I can control IO to/from the TCP layer 
underneath using standard system-esque calls (connect(), 
read(), write() on a socket fd).

The transfer itself is carried out through SSL_write() then followed by 
BIO_read(), and BIO_write() followed by SSL_read() in/from the 
respective BIO *w, *r.

This is all fine and dandy but how should the manual handshake be 
implemented?

Something akin to:

{
  char buffer[1024];
  while (!SSL_is_init_finished(ssl))
  {
SSL_do_handshake(ssl);
int nbytes;
if ((nbytes = BIO_read(w, buffer, sizeof buffer)) > 0)
  write(fd, buffer, nbytes);
else if ((nbytes = read(fd, buffer, sizeof buffer)) > 0)
  BIO_write(r, buffer, nbytes);
  }
}

Such a handshake can be put in wherever the server/client needs to 
connect, eg called during initialization.

The handshake works fine when the client-server is on a localhost. 
However when connecting to a web server the handshake takes long to 
return and doesn't do the handshake either. So the question is, what 
further provisions need to be made to connect to a non-local web server? 
Or perhaps the above handshake should be integral to BIO_write() and 
BIO_read() calls. I'm not sure, I have not looked at the actual 
library sources as what SSL_() precisely does. Anyone care to send some 
info my way in this particular case..?

Re: Decrypt error when using openssl 1.1.1b during SSL handshake

[Matt Caswell]

On 02/11/2020 09:00, Mahendra SP wrote:
> Hi Matt,
> 
> Error is reported from this:
> FILE:../openssl-1.1.1b/ssl/statem/statem_srvr.c, FUNCTION:415,
> LINE:3055, reason=147, alert=51
> 
> We see that hardware is returning 48 bytes. Even if the decrypted
> premaster data is correct, openssl is expecting more than 48 bytes in
> return.
> This check fails as decrypt_len is 48.
> decrypt_len < 11 + SSL_MAX_MASTER_KEY_LENGTH 

Just above this line we call RSA_private_decrypt() with padding set to
RSA_NO_PADDING.

We expect the output *once padding is removed* to be 48 bytes. But
RSA_private_decrypt() should be returning the data *with the padding
included* (because we called it with RSA_NO_PADDING). The minimum valid
padding length is 11 bytes (hence the check above). So it looks to me
like the engine is incorrectly ignoring the RSA_NO_PADDING, and
stripping the padding anyway.

Matt

> 
> We compared the data returned when software is used. Decrypt_len is 256
> bytes and the last 48 bytes are actual premaster secret. Also, openssl
> checks for if the first byte is 0 and second byte is 2. 
> We are trying to rectify this issue in hardware and return the correct data.
> 
> Please suggest if you have any comments for the above info.
> 
> Thanks
> Mahendra
> 
> On Fri, Oct 30, 2020 at 7:50 PM Matt Caswell  <mailto:m...@openssl.org>> wrote:
> 
> 
> 
> On 30/10/2020 11:22, Mahendra SP wrote:
> > Hi Matt,
> >
> > Thank you for the inputs.
> > Yes, we had encountered the padding issue initially. But we added
> > support for RSA_NO_PADDING in our hardware. That's why we are able to
> > successfully decrypt the premaster secret in the hardware.
> > Hence the issue does not seem to be related to padding. We have
> > confirmed this by comparing the premaster secret on both client and
> > server and they are the same.
> 
> Ok, good.
> 
> >
> > We suspect in this case, verification of "encrypted handshake message"
> > failure is happening.
> 
> It's possible. It would be helpful if you can get more information from
> the error stack on the server, e.g. by using ERR_print_errors_fp() or
> something similar. I'm particularly interested in identifying the source
> file and line number where the decrypt_error is coming from. Printing
> the error stack should give us that information. There are a number of
> places that a "decrypt error" can occur and it would be helpful to
> identify which one is the cause of the problem.
> 
> 
> > We understand constant_time_xx APIs get used for CBC padding
> validation.
> > Will this have  any dependency on the compiler optimization or asm
> > flags?
> 
> CBC padding validation is fairly independent of anything to do with RSA,
> so I think its unlikely to be the culprit here. Of course sometimes
> compiler optimization/asm issues do occur so it can't be ruled out
> entirely - but it's not where I would start looking.
> 
> > Will this issue be seen if hardware takes more time for the
> > operation?
> >
> 
> No. Constant time here just means that we implement the code without any
> branching based on secret data (e.g. no "if" statements/while loops etc
> based on secret dependent data). It has very little to do with how long
> something actually takes to process.
> 
> 
> > Here is the snippet of the wireshark where our device acting as server
> > closes the connection with decryption failure.
> 
> Thanks. To narrow it down further I need to figure out which line of
> code the decrypt_error is coming from as described above.
> 
> Matt
> 
> 
> 
> > If you need any further info, please let us know. 
> > image.png
> > Thanks
> > Mahendra
> >
> > Please suggest.
> >
> >
> >
>     > On Fri, Oct 30, 2020 at 3:32 PM Matt Caswell  <mailto:m...@openssl.org>
> > <mailto:m...@openssl.org <mailto:m...@openssl.org>>> wrote:
> >
> >
> >
> >     On 30/10/2020 09:18, Mahendra SP wrote:
> >     > Hi All.
> >     >
> >     > We have upgraded openssl version to 1.1.1b
> >     >
> >     > With this, we are seeing decryption error during SSL
> handshake for the
> >     > below explained scenario. Our device acts as an SSL server.
> >     >
> >     > We have external hardware to offload RSA private key
> operations us

Re: Decrypt error when using openssl 1.1.1b during SSL handshake

[Mahendra SP]

Hi Matt,

Error is reported from this:
FILE:../openssl-1.1.1b/ssl/statem/statem_srvr.c, FUNCTION:415, LINE:3055,
reason=147, alert=51

We see that hardware is returning 48 bytes. Even if the decrypted premaster
data is correct, openssl is expecting more than 48 bytes in return.
This check fails as decrypt_len is 48.
decrypt_len < 11 + SSL_MAX_MASTER_KEY_LENGTH

We compared the data returned when software is used. Decrypt_len is 256
bytes and the last 48 bytes are actual premaster secret. Also, openssl
checks for if the first byte is 0 and second byte is 2.
We are trying to rectify this issue in hardware and return the correct data.

Please suggest if you have any comments for the above info.

Thanks
Mahendra

On Fri, Oct 30, 2020 at 7:50 PM Matt Caswell  wrote:

>
>
> On 30/10/2020 11:22, Mahendra SP wrote:
> > Hi Matt,
> >
> > Thank you for the inputs.
> > Yes, we had encountered the padding issue initially. But we added
> > support for RSA_NO_PADDING in our hardware. That's why we are able to
> > successfully decrypt the premaster secret in the hardware.
> > Hence the issue does not seem to be related to padding. We have
> > confirmed this by comparing the premaster secret on both client and
> > server and they are the same.
>
> Ok, good.
>
> >
> > We suspect in this case, verification of "encrypted handshake message"
> > failure is happening.
>
> It's possible. It would be helpful if you can get more information from
> the error stack on the server, e.g. by using ERR_print_errors_fp() or
> something similar. I'm particularly interested in identifying the source
> file and line number where the decrypt_error is coming from. Printing
> the error stack should give us that information. There are a number of
> places that a "decrypt error" can occur and it would be helpful to
> identify which one is the cause of the problem.
>
>
> > We understand constant_time_xx APIs get used for CBC padding validation.
> > Will this have  any dependency on the compiler optimization or asm
> > flags?
>
> CBC padding validation is fairly independent of anything to do with RSA,
> so I think its unlikely to be the culprit here. Of course sometimes
> compiler optimization/asm issues do occur so it can't be ruled out
> entirely - but it's not where I would start looking.
>
> > Will this issue be seen if hardware takes more time for the
> > operation?
> >
>
> No. Constant time here just means that we implement the code without any
> branching based on secret data (e.g. no "if" statements/while loops etc
> based on secret dependent data). It has very little to do with how long
> something actually takes to process.
>
>
> > Here is the snippet of the wireshark where our device acting as server
> > closes the connection with decryption failure.
>
> Thanks. To narrow it down further I need to figure out which line of
> code the decrypt_error is coming from as described above.
>
> Matt
>
>
>
> > If you need any further info, please let us know.
> > image.png
> > Thanks
> > Mahendra
> >
> > Please suggest.
> >
> >
> >
> > On Fri, Oct 30, 2020 at 3:32 PM Matt Caswell  > <mailto:m...@openssl.org>> wrote:
> >
> >
> >
> > On 30/10/2020 09:18, Mahendra SP wrote:
> > > Hi All.
> > >
> > > We have upgraded openssl version to 1.1.1b
> > >
> > > With this, we are seeing decryption error during SSL handshake for
> the
> > > below explained scenario. Our device acts as an SSL server.
> > >
> > > We have external hardware to offload RSA private key operations
> using
> > > the engine.
> > > Decryption of pre-master secret is done using hardware and is
> > > successful. We compared the pre-master secret on both server and
> > client
> > > and they match.
> > > However, we see that SSL handshake fails with "decrypt error (51)"
> > with
> > > an alert number 21. Verifying the encrypted finish message on the
> > server
> > > side fails.
> > >
> > > This issue does not happen with software performing RSA private key
> > > operations.
> > >
> > > Can someone help with the reason for decryption failure? Below is
> the
> > > compiler and processor details. It is 64 bit.
> > > arm-linux-gnueabihf-gcc  -march=armv7ve -mthumb -mfpu=neon
> > -mfloat-abi=hard
> >
> > Potentially this is related to the use of PSS padding in libssl
> w

Re: Decrypt error when using openssl 1.1.1b during SSL handshake

[Matt Caswell]

On 30/10/2020 11:22, Mahendra SP wrote:
> Hi Matt,
> 
> Thank you for the inputs.
> Yes, we had encountered the padding issue initially. But we added
> support for RSA_NO_PADDING in our hardware. That's why we are able to
> successfully decrypt the premaster secret in the hardware.
> Hence the issue does not seem to be related to padding. We have
> confirmed this by comparing the premaster secret on both client and
> server and they are the same.

Ok, good.

> 
> We suspect in this case, verification of "encrypted handshake message"
> failure is happening.

It's possible. It would be helpful if you can get more information from
the error stack on the server, e.g. by using ERR_print_errors_fp() or
something similar. I'm particularly interested in identifying the source
file and line number where the decrypt_error is coming from. Printing
the error stack should give us that information. There are a number of
places that a "decrypt error" can occur and it would be helpful to
identify which one is the cause of the problem.


> We understand constant_time_xx APIs get used for CBC padding validation.
> Will this have  any dependency on the compiler optimization or asm
> flags?

CBC padding validation is fairly independent of anything to do with RSA,
so I think its unlikely to be the culprit here. Of course sometimes
compiler optimization/asm issues do occur so it can't be ruled out
entirely - but it's not where I would start looking.

> Will this issue be seen if hardware takes more time for the
> operation?
> 

No. Constant time here just means that we implement the code without any
branching based on secret data (e.g. no "if" statements/while loops etc
based on secret dependent data). It has very little to do with how long
something actually takes to process.


> Here is the snippet of the wireshark where our device acting as server
> closes the connection with decryption failure.

Thanks. To narrow it down further I need to figure out which line of
code the decrypt_error is coming from as described above.

Matt



> If you need any further info, please let us know. 
> image.png
> Thanks
> Mahendra
> 
> Please suggest.
> 
> 
> 
> On Fri, Oct 30, 2020 at 3:32 PM Matt Caswell  <mailto:m...@openssl.org>> wrote:
> 
> 
> 
> On 30/10/2020 09:18, Mahendra SP wrote:
> > Hi All.
> >
> > We have upgraded openssl version to 1.1.1b
> >
> > With this, we are seeing decryption error during SSL handshake for the
> > below explained scenario. Our device acts as an SSL server.
> >
> > We have external hardware to offload RSA private key operations using
> > the engine.
> > Decryption of pre-master secret is done using hardware and is
> > successful. We compared the pre-master secret on both server and
> client
> > and they match.
> > However, we see that SSL handshake fails with "decrypt error (51)"
> with
> > an alert number 21. Verifying the encrypted finish message on the
> server
> > side fails.
> >
> > This issue does not happen with software performing RSA private key
> > operations.
> >
> > Can someone help with the reason for decryption failure? Below is the
> > compiler and processor details. It is 64 bit.
> > arm-linux-gnueabihf-gcc  -march=armv7ve -mthumb -mfpu=neon
> -mfloat-abi=hard
> 
> Potentially this is related to the use of PSS padding in libssl which is
> mandated in TLSv1.3. The TLSv1.3 spec also requires its use even in
> TLSv1.2.
> 
> The PSS padding is implemented within the EVP layer. Ultimately EVP
> calls the function RSA_private_encrypt() with padding set to
> RSA_NO_PADDING.
> 
> Assuming your engine is implemented via a custom RSA_METHOD does it
> support RSA_private_encrypt(() with RSA_NO_PADDING? If not this is
> likely to be the problem.
> 
> More discussion of this is here:
> 
> https://github.com/openssl/openssl/issues/7968
> 
> Also related is the recent discussion on this list about the CAPI engine
> and this issue:
> 
> https://github.com/openssl/openssl/issues/8872
> 
> Matt
> 

Re: Decrypt error when using openssl 1.1.1b during SSL handshake

[Mahendra SP]

Hi Matt,

Thank you for the inputs.
Yes, we had encountered the padding issue initially. But we added support
for RSA_NO_PADDING in our hardware. That's why we are able to successfully
decrypt the premaster secret in the hardware.
Hence the issue does not seem to be related to padding. We have confirmed
this by comparing the premaster secret on both client and server and they
are the same.

We suspect in this case, verification of "encrypted handshake message"
failure is happening.
We understand constant_time_xx APIs get used for CBC padding validation.
Will this have  any dependency on the compiler optimization or asm flags?
Will this issue be seen if hardware takes more time for the operation?

Here is the snippet of the wireshark where our device acting as server
closes the connection with decryption failure.
If you need any further info, please let us know.
[image: image.png]
Thanks
Mahendra

Please suggest.



On Fri, Oct 30, 2020 at 3:32 PM Matt Caswell  wrote:

>
>
> On 30/10/2020 09:18, Mahendra SP wrote:
> > Hi All.
> >
> > We have upgraded openssl version to 1.1.1b
> >
> > With this, we are seeing decryption error during SSL handshake for the
> > below explained scenario. Our device acts as an SSL server.
> >
> > We have external hardware to offload RSA private key operations using
> > the engine.
> > Decryption of pre-master secret is done using hardware and is
> > successful. We compared the pre-master secret on both server and client
> > and they match.
> > However, we see that SSL handshake fails with "decrypt error (51)" with
> > an alert number 21. Verifying the encrypted finish message on the server
> > side fails.
> >
> > This issue does not happen with software performing RSA private key
> > operations.
> >
> > Can someone help with the reason for decryption failure? Below is the
> > compiler and processor details. It is 64 bit.
> > arm-linux-gnueabihf-gcc  -march=armv7ve -mthumb -mfpu=neon
> -mfloat-abi=hard
>
> Potentially this is related to the use of PSS padding in libssl which is
> mandated in TLSv1.3. The TLSv1.3 spec also requires its use even in
> TLSv1.2.
>
> The PSS padding is implemented within the EVP layer. Ultimately EVP
> calls the function RSA_private_encrypt() with padding set to
> RSA_NO_PADDING.
>
> Assuming your engine is implemented via a custom RSA_METHOD does it
> support RSA_private_encrypt(() with RSA_NO_PADDING? If not this is
> likely to be the problem.
>
> More discussion of this is here:
>
> https://github.com/openssl/openssl/issues/7968
>
> Also related is the recent discussion on this list about the CAPI engine
> and this issue:
>
> https://github.com/openssl/openssl/issues/8872
>
> Matt
>

Re: Decrypt error when using openssl 1.1.1b during SSL handshake

[Matt Caswell]

On 30/10/2020 09:18, Mahendra SP wrote:
> Hi All.
> 
> We have upgraded openssl version to 1.1.1b
> 
> With this, we are seeing decryption error during SSL handshake for the
> below explained scenario. Our device acts as an SSL server.
> 
> We have external hardware to offload RSA private key operations using
> the engine.
> Decryption of pre-master secret is done using hardware and is
> successful. We compared the pre-master secret on both server and client
> and they match.
> However, we see that SSL handshake fails with "decrypt error (51)" with
> an alert number 21. Verifying the encrypted finish message on the server
> side fails.
> 
> This issue does not happen with software performing RSA private key
> operations.
> 
> Can someone help with the reason for decryption failure? Below is the
> compiler and processor details. It is 64 bit.
> arm-linux-gnueabihf-gcc  -march=armv7ve -mthumb -mfpu=neon -mfloat-abi=hard

Potentially this is related to the use of PSS padding in libssl which is
mandated in TLSv1.3. The TLSv1.3 spec also requires its use even in TLSv1.2.

The PSS padding is implemented within the EVP layer. Ultimately EVP
calls the function RSA_private_encrypt() with padding set to RSA_NO_PADDING.

Assuming your engine is implemented via a custom RSA_METHOD does it
support RSA_private_encrypt(() with RSA_NO_PADDING? If not this is
likely to be the problem.

More discussion of this is here:

https://github.com/openssl/openssl/issues/7968

Also related is the recent discussion on this list about the CAPI engine
and this issue:

https://github.com/openssl/openssl/issues/8872

Matt

Decrypt error when using openssl 1.1.1b during SSL handshake

[Mahendra SP]

Hi All.

We have upgraded openssl version to 1.1.1b

With this, we are seeing decryption error during SSL handshake for the
below explained scenario. Our device acts as an SSL server.

We have external hardware to offload RSA private key operations using the
engine.
Decryption of pre-master secret is done using hardware and is successful.
We compared the pre-master secret on both server and client and they match.
However, we see that SSL handshake fails with "decrypt error (51)" with an
alert number 21. Verifying the encrypted finish message on the server side
fails.

This issue does not happen with software performing RSA private key
operations.

Can someone help with the reason for decryption failure? Below is the
compiler and processor details. It is 64 bit.
arm-linux-gnueabihf-gcc  -march=armv7ve -mthumb -mfpu=neon -mfloat-abi=hard

Thanks
Mahendra

Re: Query regarding SSL_ERROR_SSL during SSL handshake

[Matt Caswell]

On 24/02/2020 03:49, Mahendra SP wrote:
> Hi Matt,
> 
> Thank you for the inputs. 
> I have one more query. Is it appropriate to check for the errno in this
> case and take action based on the errno values ?

No, errno should not be checked unless SSL_get_error returns
SSL_ERROR_SYSCALL.

Matt


> 
> Thanks
> Mahendra
> 
> On Wed, Feb 19, 2020 at 3:09 PM Matt Caswell  > wrote:
> 
> 
> 
> On 19/02/2020 05:16, Mahendra SP wrote:
> > Hi All,
> >
> > We are using Openssl version 1.0.2h. When we call SSL_do_handshake,
> > sometimes we notice that handshake fails with error SSL_ERROR_SSL. 
> > As per the documentation for this error, it is non recoverable and
> fatal
> > error.  Documentation also mentions to check the error queue for
> further
> > details. Does it mean, calling SSL_get_error after SSL_ERROR_SSL will
> > give exact reason for this failure?
> 
> OpenSSL has its own error stack. SSL_ERROR_SSL means that you should
> look at that error stack for further details about what caused the
> problem. For example you can use ERR_print_errors_fp() to print all the
> error descriptions to stdout/stderr:
> 
> https://www.openssl.org/docs/man1.1.1/man3/ERR_print_errors_fp.html
> 
> You can get more fine grained control of the error stack using the
> various ERR_* functions available. See:
> 
> https://www.openssl.org/docs/man1.1.1/man3/
> 
> Matt
> 

Re: Query regarding SSL_ERROR_SSL during SSL handshake

[Mahendra SP]

Hi Matt,

Thank you for the inputs.
I have one more query. Is it appropriate to check for the errno in this
case and take action based on the errno values ?

Thanks
Mahendra

On Wed, Feb 19, 2020 at 3:09 PM Matt Caswell  wrote:

>
>
> On 19/02/2020 05:16, Mahendra SP wrote:
> > Hi All,
> >
> > We are using Openssl version 1.0.2h. When we call SSL_do_handshake,
> > sometimes we notice that handshake fails with error SSL_ERROR_SSL.
> > As per the documentation for this error, it is non recoverable and fatal
> > error.  Documentation also mentions to check the error queue for further
> > details. Does it mean, calling SSL_get_error after SSL_ERROR_SSL will
> > give exact reason for this failure?
>
> OpenSSL has its own error stack. SSL_ERROR_SSL means that you should
> look at that error stack for further details about what caused the
> problem. For example you can use ERR_print_errors_fp() to print all the
> error descriptions to stdout/stderr:
>
> https://www.openssl.org/docs/man1.1.1/man3/ERR_print_errors_fp.html
>
> You can get more fine grained control of the error stack using the
> various ERR_* functions available. See:
>
> https://www.openssl.org/docs/man1.1.1/man3/
>
> Matt
>

Re: Query regarding SSL_ERROR_SSL during SSL handshake

[Matt Caswell]

On 19/02/2020 05:16, Mahendra SP wrote:
> Hi All,
> 
> We are using Openssl version 1.0.2h. When we call SSL_do_handshake,
> sometimes we notice that handshake fails with error SSL_ERROR_SSL. 
> As per the documentation for this error, it is non recoverable and fatal
> error.  Documentation also mentions to check the error queue for further
> details. Does it mean, calling SSL_get_error after SSL_ERROR_SSL will
> give exact reason for this failure? 

OpenSSL has its own error stack. SSL_ERROR_SSL means that you should
look at that error stack for further details about what caused the
problem. For example you can use ERR_print_errors_fp() to print all the
error descriptions to stdout/stderr:

https://www.openssl.org/docs/man1.1.1/man3/ERR_print_errors_fp.html

You can get more fine grained control of the error stack using the
various ERR_* functions available. See:

https://www.openssl.org/docs/man1.1.1/man3/

Matt

Query regarding SSL_ERROR_SSL during SSL handshake

[Mahendra SP]

Hi All,

We are using Openssl version 1.0.2h. When we call SSL_do_handshake,
sometimes we notice that handshake fails with error SSL_ERROR_SSL.
As per the documentation for this error, it is non recoverable and fatal
error.  Documentation also mentions to check the error queue for further
details. Does it mean, calling SSL_get_error after SSL_ERROR_SSL will give
exact reason for this failure?

Could you please let me know ways to identify the cause of this error?

Thanks
Mahendra

Re: [openssl-users] How to form a proper hash after writing somethinginto SSL handshake.(Revised)

[Sai Teja Chowdary]

Hi,

Happy 2018 everyone.

I figured out this issue, I think it would be good to share it here in case if 
anyone is interested in knowing. The right way to make a hash is by calculating 
hash individually for the messages client certificate, client key exchange and 
store the message buffer in an array before calculating the signature in 
certificate verify message. later after forming the certificate verify message 
append this to the previous array and write the whole buffer into the wire with 
ssl3_write_bytes().This way all three message CC, CKE and CV goes in a single 
record as multiple handshake messages.

The function ssl3_finish_mac() is the one that does the hash (Digest) of bytes 
which ever are to be written to or read from wire.

Regards
Saiteja.
From: Viktor Dukhovni
Sent: Saturday, December 30, 2017 10:48 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] How to form a proper hash after writing 
somethinginto SSL handshake.(Revised)



> On Dec 29, 2017, at 10:18 PM, Sai Teja Chowdary 
> <asteja.chowdary.ec...@iitbhu.ac.in> wrote:
> 
> I want to send client certificate, client key exchange and client verify in a 
> single handshake message which appears as multiple handshake messages in a 
> single record. But to sent the client verify I need to first make a hash of 
> previous messages(client certificate and client key exchange) to create the 
> signature. I tried framing the record with above three messages and then 
> directly sending the record in the wire using SSL3_write_machine() which is 
> giving me Bad signature error. So i thought of doing a hash of client 
> certificate and client key exchange messages that go before client verify.
> 
> Can anyone help me to find the function in OpenSSL 1.1.1-dev  xx XXX  (or 
> right procedure that needs to be done before creating a certificate verify 
> message)that can do a proper transcript(digest or hash not clear). I tried 
> using ssl3_finish_mac() on the message containing client certificate and 
> client key exchange and then tried to generate the signature in certificate 
> verify message.

There is no such feature, and none is likely to ever be offered.
The reason is that you're essentially trying to write your own
TLS implementation, and SSL library in OpenSSL is provides public
interfaces for SSL users, not for new SSL implementations.

You can of course build your OpenSSL implementation based on the
OpenSSL source code, but figuring out how the code works is then
up to you. :-(

-- 
Viktor.

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

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

Re: [openssl-users] How to form a proper hash after writing somethinginto SSL handshake.

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Sai Teja Chowdary
> Sent: Friday, December 29, 2017 21:44

> I am using OpenSSL client to create a custom TLS client which can send or 
> manipulate the default TLS handshake
> messages so that i can test for any bugs in our TLS server implementation. I 
> spent about 4 months in reading OpenSSL
> code and making changes and adding new arguments to modify the default 
> client. So in that process i came across the
> WPACKET API. For framing SSL records I had to use it. 

I can't help with your specific issue. I don't know the 1.1.x codebase (my 
teams are still using 1.0.2). But I'd suggest that perhaps OpenSSL is not the 
ideal starting point for this.

When security researchers do this sort of thing - generate specific TLS 
messages to test a peer implementation - they often use a scripting language 
with suitable add-on modules, such as Python with the ssl, cryptography, and 
gmpy2 modules. While these scripts are often quick-and-dirty, they're probably 
easier to modify. So you might look at various open-source TLS test scripts, 
such as the one Hanno Böck wrote for ROBOT (see robotattack.org).

There are also various open-source test frameworks for TLS, such as 
TLSPretense. I don't have any experience with them myself, but it's worth 
taking a look.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 



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

Re: [openssl-users] How to form a proper hash after writing something into SSL handshake.(Revised)

[Viktor Dukhovni]

> On Dec 29, 2017, at 10:18 PM, Sai Teja Chowdary 
>  wrote:
> 
> I want to send client certificate, client key exchange and client verify in a 
> single handshake message which appears as multiple handshake messages in a 
> single record. But to sent the client verify I need to first make a hash of 
> previous messages(client certificate and client key exchange) to create the 
> signature. I tried framing the record with above three messages and then 
> directly sending the record in the wire using SSL3_write_machine() which is 
> giving me Bad signature error. So i thought of doing a hash of client 
> certificate and client key exchange messages that go before client verify.
> 
> Can anyone help me to find the function in OpenSSL 1.1.1-dev  xx XXX  (or 
> right procedure that needs to be done before creating a certificate verify 
> message)that can do a proper transcript(digest or hash not clear). I tried 
> using ssl3_finish_mac() on the message containing client certificate and 
> client key exchange and then tried to generate the signature in certificate 
> verify message.

There is no such feature, and none is likely to ever be offered.
The reason is that you're essentially trying to write your own
TLS implementation, and SSL library in OpenSSL is provides public
interfaces for SSL users, not for new SSL implementations.

You can of course build your OpenSSL implementation based on the
OpenSSL source code, but figuring out how the code works is then
up to you. :-(

-- 
Viktor.

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

[openssl-users] How to form a proper hash after writing something into SSL handshake.(Revised)

[Sai Teja Chowdary]

Hi everyone,

I want to send client certificate, client key exchange and client verify in
a single handshake message which appears as multiple handshake messages in
a single record. But to sent the client verify I need to first make a hash
of previous messages(client certificate and client key exchange) to create
the signature. I tried framing the record with above three messages and
then directly sending the record in the wire using SSL3_write_machine()
which is giving me Bad signature error. So i thought of doing a hash of
client certificate and client key exchange messages that go before client
verify.

Can anyone help me to find the function in OpenSSL 1.1.1-dev  xx XXX 
(or right procedure that needs to be done before creating a certificate
verify message)that can do a proper transcript(digest or hash not clear). I
tried using ssl3_finish_mac() on the message containing client certificate
and client key exchange and then tried to generate the signature in
certificate verify message.

But it is giving me a digest check error. I am new to the mailing list want
a bit of help to proceed forward stuck here. Please reply in case if
anything is not clear.

Here is a code snippet, how I am forming the data containing all client
certificate , client key exchange and certificate verify messages inside
write_state_machine().

*if(WPACKET_init(, s->init_buf)){*
*//Client certificate formation*
* if(!ssl_set_handshake_header(s,,mt) || confunc != NULL &&
!confunc(s,) || !ssl_close_construct_packet(s,,mt)){*
*  printf("PROBLEM 1\n");*
*}*
* transition(s);  //transition to next state i.e client key
exchange*
* get_construct_message_f(s, , , );*
*//client key exchange formation*
* if(!ssl_set_handshake_header(s,,mt) || confunc != NULL &&
!confunc(s,) || !ssl_close_construct_packet(s,,mt)){*
*   printf("PROBLEM 2\n");*
*}*
*//ssl3_finish_mac(s, >init_buf->data[s->init_off], s->init_num);*
* st->write_state_work = post_work(s, st->write_state_work);*
* transition(s);  // transition to next state i.e  certificate
verify*
* get_construct_message_f(s, , , );*
*//certificate verify message formation.*
* if(!ssl_set_handshake_header(s,,mt) || confunc != NULL &&
!confunc(s,) ||
!ssl_close_construct_packet(s,,mt)){*
*   printf("PROBLEM 3\n");*
*}*
* WPACKET_finish();*
*}*

I also tried to do a ssl3_finish_mac() individually after forming Client
certificate and client key exchange (this part is not there in the code but
that way also gave me digest check error.)

Here is the stackoverflow link that i posted the question in. Take a look
at it for the trace snapshot for handshake message that I am trying to form.

Please take a look at it, appreciate every bit of help.

Jordan, thanks for the suggestion i will definitely try to state the error
now on. I am not sure whether SSL_get_error() logs these errors, i tried to
print SSL_get_error() it is returning NULL.

Regards
Saiteja.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to form a proper hash after writing somethinginto SSL handshake.

[Sai Teja Chowdary]

Hi everyone,

I apologize for Comic Sans. And honestly I didn't know using it implies
this many impressions. As I said my other subscription named "Ananthaneni
Saiteja Chowdary" is my outlook account that i use for my office
work(because I am using a QHD resolution my fonts are so small so i
selected the font that looks good for me to read.)  I actually posted two
questions one from this email and other from outlook account. This question
was actually posted through my outlook account in the beginning, and just
as a followup and to include some more information in my question I thought
of asking the question again. So I copied the contents of my previous mail
and added few more info at the end in my Mail app, unfortunately the font
got changed to comic sans. Its not that i knowingly changed the font to
impress or insult. I am a non native English speaker and I sometimes don't
understand the exact emotion or feeling in non-technical conversation.

I am using OpenSSL client to create a custom TLS client which can send or
manipulate the default TLS handshake messages so that i can test for any
bugs in our TLS server implementation. I spent about 4 months in reading
OpenSSL code and making changes and adding new arguments to modify the
default client. So in that process i came across the WPACKET API. For
framing SSL records I had to use it.

I will post the question again in a new thread. Please take a look at it
and help me out.

Regards

Saiteja.

On Sat, Dec 30, 2017 at 12:17 AM, Viktor Dukhovni <
openssl-us...@dukhovni.org> wrote:

>
>
> > On Dec 29, 2017, at 1:34 PM, Michael Wojcik <
> michael.woj...@microfocus.com> wrote:
> >
> > That said, I suspect the larger reason why Saiteja has not had a
> technical response to the original query is that few people on
> openssl-users have experience with using the WPACKET API and other
> low-level operations in the 1.1 codebase. It still might be worth reposting
> without the controversial styling.
>
> More importantly, what problem is the OP really trying to solve?
>
> The WPACKET interface is an internal interface that does not
> appear in any public OpenSSL headers.  It is undocumented and
> subject to change without notice.  The OP should not be using
> this interface, except as part of a code contribution to improve
> the implementation of TLS in the OpenSSL library.
>
> --
> Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to form a proper hash after writing somethinginto SSL handshake.

[Viktor Dukhovni]

> On Dec 29, 2017, at 1:34 PM, Michael Wojcik  
> wrote:
> 
> That said, I suspect the larger reason why Saiteja has not had a technical 
> response to the original query is that few people on openssl-users have 
> experience with using the WPACKET API and other low-level operations in the 
> 1.1 codebase. It still might be worth reposting without the controversial 
> styling.

More importantly, what problem is the OP really trying to solve?

The WPACKET interface is an internal interface that does not
appear in any public OpenSSL headers.  It is undocumented and
subject to change without notice.  The OP should not be using
this interface, except as part of a code contribution to improve
the implementation of TLS in the OpenSSL library.

-- 
Viktor.

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

Re: [openssl-users] How to form a proper hash after writing somethinginto SSL handshake.

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Viktor Dukhovni
> Sent: Friday, December 29, 2017 13:04
> 
> > On Dec 29, 2017, at 12:34 PM, Richard Levitte  wrote:
> >
> > Marty, you might want to consider that the values of western society
> > are hardly universal.  Comic Sans isn't as badly seen everywhere, and
> > there's no reason why western society biases should trump any other.
> 
> My issue with the post was that it was just too difficult to read,
> largely as a result of the font.  So I just deleted it and moved on.
> So this has little to do with Western vs. non-Western values.  Written
> communication is most clear when the fonts don't get in the way of the
> content.  Decorative fonts are for party announcements and the like,
> usually in large print on physical posters.

Indeed. This has little to do with "the values of western society", or the 
values of any other community. (Nor, with apologies to Richard, does it have 
much to do with the OpenSSL mailing-list code of conduct; the messages on this 
topic have ranged from curt to civil, but none have been abusive under any 
reasonable definition.)

It has to do with appealing to the intended audience, which of course is one of 
the most critical aspects of writing. I could cite thousands of years of 
rhetorical theory - from cultures European and otherwise - but this is such a 
commonplace that there's no need. Marty's message was a useful, generous, and 
polite response to Saiteja's query. And while his examples were culturally 
specific, his argument was not.

That said, I suspect the larger reason why Saiteja has not had a technical 
response to the original query is that few people on openssl-users have 
experience with using the WPACKET API and other low-level operations in the 1.1 
codebase. It still might be worth reposting without the controversial styling.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 



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

Re: [openssl-users] How to form a proper hash after writing somethinginto SSL handshake.

[Jordan Brown]

On 12/29/2017 6:00 AM, Marty G wrote:
> For the same reason one doesn't wear a halloween costume to a
> technical meeting, Comic Sans is looked down upon when used outside
> comics and day-care centers.  It is considered a snub to use it in
> non-trivial settings.
>
> Much as lifting up your middle finger has no inherent meaning per se,
> but once one realizes that it definitely has meaning to others and one
> lifts one's middle finger to others anyway, it can only be assumed
> that one has intended to send the message others have assigned to it. 
> So, for whatever vague societal reasons, comic sans has become
> equivalent to wearing a speedo to a formal wedding, giggling
> hysterically during one's performance review, or skipping around the
> track in a tu-tu and clownface during the 440 meter track event at the
> Olympics.  Those are the breaks!  Sorry for your loss of a connotation
> free comic sans.  I feel your pain.  Herd dynamics can be brutal and
> bleak.
>
> http://knowyourmeme.com/memes/comic-sans
> "...While adequate for certain industry sectors like childcare and
> entertainment, its usage in business or professional settings has been
> criticized by many aesthetic-conscious Internet users, who say Comic
> Sans conveys silliness and irreverence that is hardly suitable for
> serious matters:

Committing a fashion faux pas may be gauche, but pointing and laughing
is even more so.  If you think that somebody's choice of fashion is
inappropriate, keep it to yourself or an appropriate gossip forum. 
Congratulations, you've just convinced this newcomer that the
openssl-users group is populated by fashionistas rather than serious
technical people.

The original poster had a technical question.  I don't know enough to
answer it, or I would.  Could somebody who *does* know enough please
take a stab?

Saiteja, one suggestion:  when an error occurs, don't just report that
there was a problem.  Report what the problem was.  Don't these
functions set the results that SSL_get_error( ) returns?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to form a proper hash after writing somethinginto SSL handshake.

[Viktor Dukhovni]

> On Dec 29, 2017, at 12:34 PM, Richard Levitte  wrote:
> 
> Marty, you might want to consider that the values of western society
> are hardly universal.  Comic Sans isn't as badly seen everywhere, and
> there's no reason why western society biases should trump any other.

My issue with the post was that it was just too difficult to read,
largely as a result of the font.  So I just deleted it and moved on.
So this has little to do with Western vs. non-Western values.  Written
communication is most clear when the fonts don't get in the way of the
content.  Decorative fonts are for party announcements and the like,
usually in large print on physical posters.

-- 
Viktor.

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

Re: [openssl-users] How to form a proper hash after writing somethinginto SSL handshake.

[Richard Levitte]

Marty, you might want to consider that the values of western society
are hardly universal.  Comic Sans isn't as badly seen everywhere, and
there's no reason why western society biases should trump any other.

Also, I'd like to remind everyone that we have a code of conduct,
https://www.openssl.org/community/conduct.html

Cordially,
Richard

In message <7d7e5da5-7ddb-4278-987b-21ce9f7b3...@gmail.com> on Fri, 29 Dec 2017 
09:00:00 -0500, Marty G  said:

martygalyean> For the same reason one doesn't wear a halloween costume to a 
technical meeting, Comic Sans is
martygalyean> looked down upon when used outside comics and day-care centers. 
It is considered a snub to use
martygalyean> it in non-trivial settings.
martygalyean> 
martygalyean> Much as lifting up your middle finger has no inherent meaning per 
se, but once one realizes that it
martygalyean> definitely has meaning to others and one lifts one's middle 
finger to others anyway, it can only be
martygalyean> assumed that one has intended to send the message others have 
assigned to it. So, for whatever
martygalyean> vague societal reasons, comic sans has become equivalent to 
wearing a speedo to a formal
martygalyean> wedding, giggling hysterically during one's performance review, 
or skipping around the track in a
martygalyean> tu-tu and clownface during the 440 meter track event at the 
Olympics. Those are the breaks!
martygalyean> Sorry for your loss of a connotation free comic sans. I feel your 
pain. Herd dynamics can be brutal
martygalyean> and bleak.
martygalyean> 
martygalyean> http://knowyourmeme.com/memes/comic-sans
martygalyean> "...While adequate for certain industry sectors like childcare 
and entertainment, its usage in
martygalyean> business or professional settings has been criticized by many 
aesthetic-conscious Internet users,
martygalyean> who say Comic Sans conveys silliness and irreverence that is 
hardly suitable for serious
martygalyean> matters:
martygalyean> 
martygalyean> On 12/29/2017 08:14 AM, Sai Teja Chowdary wrote:
martygalyean> 
martygalyean>  Why? What is the problem with Comic Sans. I like it!
martygalyean> 
martygalyean>  You can say more if you have something useful.
martygalyean> 
martygalyean>  Thanks
martygalyean> 
martygalyean>  Saiteja.
martygalyean> 
martygalyean>  From: Michael Sierchio
martygalyean>  Sent: Friday, December 29, 2017 10:38 AM
martygalyean>  To: openssl-users@openssl.org
martygalyean>  Subject: Re: [openssl-users] How to form a proper hash after 
writing somethinginto SSL
martygalyean>  handshake.
martygalyean> 
martygalyean>  Comic Sans. Need I say more?
martygalyean> 
martygalyean>  On Tue, Dec 26, 2017 at 4:53 AM, Sai Teja Chowdary 

martygalyean>  wrote:
martygalyean> 
martygalyean>  Hi,
martygalyean> 
martygalyean>  Happy Holidays everyone.
martygalyean> 
martygalyean>  I want to send client certificate, client key exchange and 
client verify in a single handshake
martygalyean>  message which appears as multiple handshake messages in a single 
record. But to sent
martygalyean>  the client verify I need to first make a hash of previous 
messages(client certificate and
martygalyean>  client key exchange) to create the signature.
martygalyean> 
martygalyean>  Can anyone help me to find the function in OpenSSL 1.1.1-dev xx 
XXX  (or right
martygalyean>  procedure that needs to be done before creating a certificate 
verify message)that can do
martygalyean>  a proper transcript(digest or hash not clear). I tried using 
ssl3_finish_mac() on the
martygalyean>  message containing client certificate and client key exchange 
and then tried to generate
martygalyean>  the signature in certificate verify message.
martygalyean> 
martygalyean>  But it is giving me a digest error. I am new to the mailing list 
want a bit of help to proceed
martygalyean>  forward stuck here. Please reply in case if anything is not 
clear.
martygalyean> 
martygalyean>  Here is a code snippet, how I am forming the data containing all 
client certificate , client
martygalyean>  key exchange and certificate verify messages inside 
write_state_machine().
martygalyean> 
martygalyean>  if(WPACKET_init(, s->init_buf)){
martygalyean> 
martygalyean>  //Client certificate formation
martygalyean> 
martygalyean>  if(!ssl_set_handshake_header(s,,mt) || confunc != NULL && 
!confunc(s,) ||
martygalyean>  !ssl_close_construct_packet(s,,mt)){
martygalyean> 
martygalyean>  printf("PROBLEM\n");
martygalyean> 
martygalyean>  }
martygalyean> 
martygalyean>  transition(s); //transition to next state i.e client key exchange
martygalyean> 
martygalyean>  get_construct_message_f(s, , , );
martygalyean> 
martygalyean>  //client key exchange formation
martygalyean> 
martygalyean>  if(!ssl_set_handshake_header(s,,mt) || confunc != NULL && 
!confunc(s,) ||
martygalyean>  !ssl_close_construct_packet(s,,mt)){
martygalyean> 
martygalyean>  printf("AGAIN A PROBLEMO\n");
martygalyean> 

Re: [openssl-users] How to form a proper hash after writing somethinginto SSL handshake.

[Michael Wojcik]

And to be honest, specifying any font for a technical or business email message 
(rather than simply letting the MUA use the user's default) is suspect. It says 
that you believe your stylistic preferences are more important than the 
reader's. That's a poor footing to begin a request for assistance or 
cooperation.

Personally, due to Outlook's terrible handling of HTML email (particularly in 
formatting replies), I am considerably more likely to reply to a plain-text 
message posted to openssl-users than I am to an HTML one. That may well be a 
personal idiosyncrasy, but the general principle of not making your message any 
more complicated than it needs to be is worth keeping in mind.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 


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

Re: [openssl-users] How to form a proper hash after writing somethinginto SSL handshake.

[Marty G]

For the same reason one doesn't wear a halloween costume to a technical 
meeting, Comic Sans is looked down upon when used outside comics and 
day-care centers.  It is considered a snub to use it in non-trivial 
settings.


Much as lifting up your middle finger has no inherent meaning per se, 
but once one realizes that it definitely has meaning to others and one 
lifts one's middle finger to others anyway, it can only be assumed that 
one has intended to send the message others have assigned to it.  So, 
for whatever vague societal reasons, comic sans has become equivalent to 
wearing a speedo to a formal wedding, giggling hysterically during one's 
performance review, or skipping around the track in a tu-tu and 
clownface during the 440 meter track event at the Olympics.  Those are 
the breaks!  Sorry for your loss of a connotation free comic sans.  I 
feel your pain.  Herd dynamics can be brutal and bleak.


http://knowyourmeme.com/memes/comic-sans
"...While adequate for certain industry sectors like childcare and 
entertainment, its usage in business or professional settings has been 
criticized by many aesthetic-conscious Internet users, who say Comic 
Sans conveys silliness and irreverence that is hardly suitable for 
serious matters:


On 12/29/2017 08:14 AM, Sai Teja Chowdary wrote:


Why? What is the problem with Comic Sans. I like it!

You can say more if you have something useful.

Thanks

Saiteja.

*From: *Michael Sierchio <mailto:ku...@tenebras.com>
*Sent: *Friday, December 29, 2017 10:38 AM
*To: *openssl-users@openssl.org <mailto:openssl-users@openssl.org>
*Subject: *Re: [openssl-users] How to form a proper hash after writing 
somethinginto SSL handshake.


Comic Sans. Need I say more?

On Tue, Dec 26, 2017 at 4:53 AM, Sai Teja Chowdary 
<asteja.chowdary.ec...@itbhu.ac.in 
<mailto:asteja.chowdary.ec...@itbhu.ac.in>> wrote:


Hi,

Happy Holidays everyone.

I want to send client certificate, client key exchange and client
verify in a single handshake message which appears as multiple
handshake messages in a single record. But to sent the client
verify I need to first make a hash of previous messages(client
certificate and client key exchange) to create the signature.

Can anyone help me to find the function in OpenSSL 1.1.1-dev  xx
XXX  (or right procedure that needs to be done before creating
a certificate verify message)that can do a proper
transcript(digest or hash not clear). I tried using
*ssl3_finish_mac() *on the message containing client certificate
and client key exchange and then tried to generate the signature
in certificate verify message.

But it is giving me a digest error. I am new to the mailing list
want a bit of help to proceed forward stuck here. Please reply in
case if anything is not clear.

Here is a code snippet, how I am forming the data containing all
client certificate , client key exchange and certificate verify
messages inside write_state_machine().

if(WPACKET_init(, s->init_buf)){

//Client certificate formation

if(!ssl_set_handshake_header(s,,mt) || confunc != NULL &&
!confunc(s,) || !ssl_close_construct_packet(s,,mt)){

printf("PROBLEM\n");

    }

 transition(s); //transition to next state i.e client
key exchange

get_construct_message_f(s, , , );

//client key exchange formation

if(!ssl_set_handshake_header(s,,mt) || confunc != NULL &&
!confunc(s,) || !ssl_close_construct_packet(s,,mt)){

   printf("AGAIN A PROBLEMO\n");

    }

//ssl3_finish_mac(s, >init_buf->data[s->init_off], s->init_num);

st->write_state_work = post_work(s, st->write_state_work);

 transition(s);  // transition to next state i.e
 certificate verify

get_construct_message_f(s, , , );

//certificate verify message formation.

if(!ssl_set_handshake_header(s,,mt) || confunc != NULL &&
!confunc(s,) || !ssl_close_construct_packet(s,,mt)){

   printf("AGAIN A PROBLEMO\n");

    }

WPACKET_finish();

Please take a look at it, appreciate every bit of help.

Regards,

Saiteja


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



--

"Well," Brahma said, "even after ten thousand explanations, a fool is 
no wiser, but an intelligent person requires only two thousand five 
hundred."



- The Mahābhārata





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

Re: [openssl-users] How to form a proper hash after writing somethinginto SSL handshake.

[Sai Teja Chowdary]

Why? What is the problem with Comic Sans. I like it!

You can say more if you have something useful.

Thanks

Saiteja.

From: Michael Sierchio
Sent: Friday, December 29, 2017 10:38 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] How to form a proper hash after writing 
somethinginto SSL handshake.


Comic Sans. Need I say more?

On Tue, Dec 26, 2017 at 4:53 AM, Sai Teja Chowdary 
<asteja.chowdary.ec...@itbhu.ac.in> wrote:
 
Hi,
 
Happy Holidays everyone.
 
I want to send client certificate, client key exchange and client verify in a 
single handshake message which appears as multiple handshake messages in a 
single record. But to sent the client verify I need to first make a hash of 
previous messages(client certificate and client key exchange) to create the 
signature.
 
Can anyone help me to find the function in OpenSSL 1.1.1-dev  xx XXX  (or 
right procedure that needs to be done before creating a certificate verify 
message)that can do a proper transcript(digest or hash not clear). I tried 
using ssl3_finish_mac() on the message containing client certificate and client 
key exchange and then tried to generate the signature in certificate verify 
message.
But it is giving me a digest error. I am new to the mailing list want a bit of 
help to proceed forward stuck here. Please reply in case if anything is not 
clear.
 
Here is a code snippet, how I am forming the data containing all client 
certificate , client key exchange and certificate verify messages inside 
write_state_machine().
 
if(WPACKET_init(, s->init_buf)){
//Client certificate formation
 if(!ssl_set_handshake_header(s,,mt) || confunc != NULL && 
!confunc(s,) ||     !ssl_close_construct_packet(s,,mt)){
  printf("PROBLEM\n");
    }
 transition(s);  //transition to next state i.e client key exchange
 
 get_construct_message_f(s, , , );
//client key exchange formation
 if(!ssl_set_handshake_header(s,,mt) || confunc != NULL && 
!confunc(s,) ||     !ssl_close_construct_packet(s,,mt)){
   printf("AGAIN A PROBLEMO\n");
    }
 
//ssl3_finish_mac(s, >init_buf->data[s->init_off], s->init_num);
 st->write_state_work = post_work(s, st->write_state_work);
 transition(s);  // transition to next state i.e  certificate verify
 
 get_construct_message_f(s, , , );
//certificate verify message formation.
 if(!ssl_set_handshake_header(s,,mt) || confunc != NULL && 
!confunc(s,) ||          
!ssl_close_construct_packet(s,,mt)){
   printf("AGAIN A PROBLEMO\n");
    }
 WPACKET_finish();
 
 
Please take a look at it, appreciate every bit of help.
 
Regards,
Saiteja
 

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




-- 
"Well," Brahma said, "even after ten thousand explanations, a fool is no wiser, 
but an intelligent person requires only two thousand five hundred."

- The Mahābhārata

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

Re: [openssl-users] How to form a proper hash after writing something into SSL handshake.

[Michael Sierchio]

Comic Sans. Need I say more?

On Tue, Dec 26, 2017 at 4:53 AM, Sai Teja Chowdary <
asteja.chowdary.ec...@itbhu.ac.in> wrote:

>
>
> Hi,
>
>
>
> Happy Holidays everyone.
>
>
>
> I want to send client certificate, client key exchange and client verify
> in a single handshake message which appears as multiple handshake messages
> in a single record. But to sent the client verify I need to first make a
> hash of previous messages(client certificate and client key exchange) to
> create the signature.
>
>
>
> Can anyone help me to find the function in OpenSSL 1.1.1-dev  xx XXX 
> (or right procedure that needs to be done before creating a certificate
> verify message)that can do a proper transcript(digest or hash not clear). I
> tried using *ssl3_finish_mac() *on the message containing client
> certificate and client key exchange and then tried to generate the
> signature in certificate verify message.
>
> But it is giving me a digest error. I am new to the mailing list want a
> bit of help to proceed forward stuck here. Please reply in case if anything
> is not clear.
>
>
>
> Here is a code snippet, how I am forming the data containing all client
> certificate , client key exchange and certificate verify messages inside
> write_state_machine().
>
>
>
> if(WPACKET_init(, s->init_buf)){
>
> //Client certificate formation
>
>  if(!ssl_set_handshake_header(s,,mt) || confunc != NULL
> && !confunc(s,) || !ssl_close_construct_packet(s,,mt)){
>
>   printf("PROBLEM\n");
>
> }
>
>  transition(s);  //transition to next state i.e client key
> exchange
>
>
>
>  get_construct_message_f(s, , , );
>
> //client key exchange formation
>
>  if(!ssl_set_handshake_header(s,,mt) || confunc != NULL
> && !confunc(s,) || !ssl_close_construct_packet(s,,mt)){
>
>printf("AGAIN A PROBLEMO\n");
>
> }
>
>
>
> //ssl3_finish_mac(s, >init_buf->data[s->init_off], s->init_num);
>
>  st->write_state_work = post_work(s, st->write_state_work);
>
>  transition(s);  // transition to next state i.e  certificate
> verify
>
>
>
>  get_construct_message_f(s, , , );
>
> //certificate verify message formation.
>
>  if(!ssl_set_handshake_header(s,,mt) || confunc != NULL
> && !confunc(s,) ||
> !ssl_close_construct_packet(s,,mt)){
>
>printf("AGAIN A PROBLEMO\n");
>
> }
>
>  WPACKET_finish();
>
>
>
>
>
> Please take a look at it, appreciate every bit of help.
>
>
>
> Regards,
>
> Saiteja
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


-- 
"Well," Brahma said, "even after ten thousand explanations, a fool is no
wiser, but an intelligent person requires only two thousand five hundred."

- The Mahābhārata
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] How to form a proper hash after writing something into SSL handshake.

[Sai Teja Chowdary]

Hi,

Happy Holidays everyone.

I want to send client certificate, client key exchange and client verify in a 
single handshake message which appears as multiple handshake messages in a 
single record. But to sent the client verify I need to first make a hash of 
previous messages(client certificate and client key exchange) to create the 
signature.

Can anyone help me to find the function in OpenSSL 1.1.1-dev  xx XXX  (or 
right procedure that needs to be done before creating a certificate verify 
message)that can do a proper transcript(digest or hash not clear). I tried 
using ssl3_finish_mac() on the message containing client certificate and client 
key exchange and then tried to generate the signature in certificate verify 
message.
But it is giving me a digest error. I am new to the mailing list want a bit of 
help to proceed forward stuck here. Please reply in case if anything is not 
clear.

Here is a code snippet, how I am forming the data containing all client 
certificate , client key exchange and certificate verify messages inside 
write_state_machine().

if(WPACKET_init(, s->init_buf)){
//Client certificate formation
 if(!ssl_set_handshake_header(s,,mt) || confunc != NULL && 
!confunc(s,) ||  !ssl_close_construct_packet(s,,mt)){
  printf("PROBLEM\n");
}
 transition(s);  //transition to next state i.e client key exchange

 get_construct_message_f(s, , , );
//client key exchange formation
 if(!ssl_set_handshake_header(s,,mt) || confunc != NULL && 
!confunc(s,) ||  !ssl_close_construct_packet(s,,mt)){
   printf("AGAIN A PROBLEMO\n");
}

//ssl3_finish_mac(s, >init_buf->data[s->init_off], s->init_num);
 st->write_state_work = post_work(s, st->write_state_work);
 transition(s);  // transition to next state i.e  certificate verify

 get_construct_message_f(s, , , );
//certificate verify message formation.
 if(!ssl_set_handshake_header(s,,mt) || confunc != NULL && 
!confunc(s,) ||  
!ssl_close_construct_packet(s,,mt)){
   printf("AGAIN A PROBLEMO\n");
}
 WPACKET_finish();


Please take a look at it, appreciate every bit of help.

Regards,
Saiteja

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

[openssl-users] SSL Handshake with TPM using TPM Engine

[Devang Kubavat]

Hi All,



*SSL handshake with TPM using TPM Engine: *I am generating the RSA keys in
TPM and private key will never come out from TPM

I want to do SSL handshake with this scenario.
Can you please point out me in SSL handshake which functions are using the
RSA private key? So that, I can register those functions in TPM Engine to
perform RSA private key related operation.

Is there any reference implementation for SSL handshake using TPM via TPM
Engine?

Regards,
Digant
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] While ssl handshake happens, getting error Operation not allowed in fips mode

[Jakob Bohm]

On 04/05/2016 08:15, mani kanta wrote:


Hello,

   While the SSL handshake is happening,I am getting the error as below
SSL_connect error:0408E09E:rsa routines:PKEY_RSA_SIGN:operation not 
allowed in fips mode.
ssl handshake went well up to client sending key exchange to server 
and failing in the process of send client verify. Why this error 
happens ? and How to overcome this ?


Background:
 1.  I built Openssl in FIPS mode. From the supplicant (application) I 
called FIPS_mode_set(1) API. In my use-case I am trying to connect 
WPA2 Enterprise Wi-Fi network which has EAP-TLS configured (used 
radius server to setup EAP-TLS).


2. From the network packets it is confirmed that the client and the 
server agreed on to use TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 cipher 
suit. Also found that if in case TLS_RSA_WITH_AES_256_CBC_SHA256 
cipher suit is selected  then also it throws the same above mentioned 
error.


3. I am using openssl verson 1.0.2f(client side). radius 
server(3.0.11) . Server is running in ubuntu 14.04




Is your RSA key too short (FIPS mode imposes a minimum key
length by refusing to use shorter keys).



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

[openssl-users] While ssl handshake happens, getting error Operation not allowed in fips mode

[mani kanta]

Hello,

   While the SSL handshake is happening,I am getting the error as below
SSL_connect error:0408E09E:rsa routines:PKEY_RSA_SIGN:operation not allowed
in fips mode.
ssl handshake went well up to client sending key exchange to server and
failing in the process of send client verify. Why this error happens ? and
How to overcome this ?

Background:
 1.  I built Openssl in FIPS mode. From the supplicant (application) I
called FIPS_mode_set(1) API. In my use-case I am trying to connect WPA2
Enterprise Wi-Fi network which has EAP-TLS configured (used radius server
to setup EAP-TLS).

2. From the network packets it is confirmed that the client and the server
agreed on to use TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 cipher suit. Also
found that if in case TLS_RSA_WITH_AES_256_CBC_SHA256 cipher suit is
selected  then also it throws the same above mentioned error.

3. I am using openssl verson 1.0.2f(client side). radius server(3.0.11) .
Server is running in ubuntu 14.04

  Please let me know if you need any further information.

  Thank you in advance.

Regards,
Venkat.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Browsers SSL handshake issues with https://wiki.openssl.org

[Bubnov Dmitriy]

Hello, All.

I have met an issue with different browsers behavior when opening a link 
https://wiki.openssl.org/. Investigations shows that it is SSL handshake issues.

Is it possible to correct situation for Safari browser?

Below is 'ssldump's and 'openssl version -a' logs.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

>>> osx10.6.8 + chrome 45.0.2454.101; SSL session is OK
>>>
New TCP connection #1: 192.168.0.1(59718) <-> 194.97.150.234(443)
1 1  0.0506 (0.0506)  C>S V3.1(512)  Handshake
  ClientHello
Version 3.3 
random[32]=
  d2 e1 13 ee 12 ed 4a cd 48 ab 9a 84 89 5e 68 65 
  6c 74 d1 47 16 b6 a8 59 20 78 1e 73 1c 29 08 40 
resume [32]=
  96 63 75 db a1 7d 41 71 5c 80 22 ae b0 2f 5d 8e 
  3c fc e8 0a d3 1d 0e 16 ea 17 17 de 30 29 f1 6d 
cipher suites
Unknown value 0xcc14
Unknown value 0xcc13
Unknown value 0xcc15
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
compression methods
  NULL
1 2  0.1002 (0.0496)  S>C V3.3(81)  Handshake
  ServerHello
Version 3.3 
random[32]=
  25 b5 71 fa 69 9c 64 26 91 48 e5 c1 6f 07 6c 4b 
  12 b7 22 a6 20 e6 fb 6d 80 00 dd a1 99 43 70 dc 
session_id[32]=
  96 63 75 db a1 7d 41 71 5c 80 22 ae b0 2f 5d 8e 
  3c fc e8 0a d3 1d 0e 16 ea 17 17 de 30 29 f1 6d 
cipherSuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
compressionMethod   NULL
1 3  0.1002 (0.)  S>C V3.3(1)  ChangeCipherSpec
1 4  0.1002 (0.)  S>C V3.3(40)  Handshake
1 5  0.1017 (0.0014)  C>S V3.3(1)  ChangeCipherSpec
1 6  0.1017 (0.)  C>S V3.3(40)  Handshake
1 7  0.1024 (0.0006)  C>S V3.3(521)  application_data
1 8  0.2268 (0.1244)  S>C V3.3(299)  application_data
1 9  4.0905 (3.8636)  C>S V3.3(426)  application_data
1 10 4.1691 (0.0786)  S>C V3.3(598)  application_data
1 11 4.1737 (0.0046)  C>S V3.3(495)  application_data
1 12 4.2673 (0.0935)  S>C V3.3(298)  application_data
19.2750 (5.0077)  S>C  TCP FIN
1   14.2687 (4.9936)  C>S  TCP FIN


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


>>> osx10.6.8 safari5.1.10(6534.59.10); SSL session is BROKEN
>>>
New TCP connection #1: 192.168.0.1(59771) <-> 194.97.150.234(443)
1 1  0.0598 (0.0598)  C>S V3.1(158)  Handshake
  ClientHello
Version 3.1 
random[32]=
  56 05 6d 21 f6 ef c5 31 be 10 7d ef e8 b4 78 cf 
  a5 47 61 7a 23 42 29 30 a2 6e c3 dc e3 0f 67 4b 
cipher suites
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_DES_CB

Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails

[Jakob Bohm]

On 10/08/2015 20:12, Salz, Rich wrote:

Specifically, a number of decisions have the feel of a project that has been
co-opted or taken over by someone eager to make sweeping changes for
little apparent reason, someone with lots of idle lawyers on hand, like
Microsoft, various corporate partners, the CII, and/or the SFLC (using a list
from the latest public blog post)

Do you mean me?  Or did you make a typo, and mean members rather than 
someone ?

No, I meant someone like the examples at the end of the sentence.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails

[Salz, Rich]

 Specifically, a number of decisions have the feel of a project that has been
 co-opted or taken over by someone eager to make sweeping changes for
 little apparent reason, someone with lots of idle lawyers on hand, like
 Microsoft, various corporate partners, the CII, and/or the SFLC (using a 
 list
 from the latest public blog post)

Do you mean me?  Or did you make a typo, and mean members rather than 
someone ?

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

Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails

[Jakob Bohm]

On 01/08/2015 08:00, Viktor Dukhovni wrote:

The Windows 2003 TLS stack became unsupported for most
(but /not all/) users less than 20 days ago.  Treating
it as marginal and not as something that any core
networking library needs to be compatible (even *tested*
with) out of the box is another symptom of the useless
attitudes that permeate the new OpenSSL leadership.

You should apologize, I resent that remark.  Behind the scenes I
am working to ensure that we maintain reasonable compatibility with
that stack while it still exists in the field, and have helped many
users craft sensible work-arounds for the bugs in that platform.

It is not so easy to work around the rather severe limitations of
Schannel in Windows 2003.  OpenSSL would have to by default disable
many of the new ciphers in TLS 1.2.  Are you suggesting that the
exclusions I am recommending should have been on by default? To
accommodate a relatively rare and clearly broken peer?

We could consider such an accommodation, but I think that the wiser
course of action is to document the work-around for those who need
it.  This is the first report of this problem I've seen for an
application protocol other SMTP.  It was however immediately
recognizable.


The old OpenSSL project belonged to the long standing
tradition of making sure that Internet software needs to
work with the quirks of anything it could reasonably
encounter on any real world network, including both the
Internet, the US military networks (which have allegedly
paid a boatload of money for continued Win2003 support)
and any closed site networks that reuse Internet protocols
for their internal operations.

You seem to be pining for the project that lacked any resources to
pay attention to documentation or code quality.  I think on the
whole more sensible trade-offs are being made now.  And compatibility
is still important.


It would have been a serious brown bag moment for the old
maintainers to discover this in a release made that close
to (if not even overlapping) the vendor support period for
such a widely deployed system.  There is a lot of utility
software which is linked to OpenSSL libraries with very
little user configurability and which is simply expected
to just work when transferring data off a (not so) old
Windows computer.

Who are these old maintainers who aren't around any more?


I have taken my time to answer this, as it deserved
some careful thinking.

The problem over the past year or so is not as much
that any old maintainers have left, as that the entire
project seems to have given off a vibe of being
under new management.

Specifically, a number of decisions have the feel of
a project that has been co-opted or taken over by
someone eager to make sweeping changes for little
apparent reason, someone with lots of idle lawyers
on hand, like Microsoft, various corporate partners,
the CII, and/or the SFLC (using a list from the latest
public blog post), yet seemingly unaware of the dangers
of combining a UK jurisdiction with phrases such as
the public benefit in an area of technology which
has historically been subject to much UK government
interference over the past 70 years.

I also see a tendency to throw historical decisions
overboard with little effort to understand why such
decisions might actually be or have been good
decisions.  For instance, in the penultimate blog
post, most of the things removed under dynamic
memory cleanup actually serve real purposes:
protective parameter validation against future code
bugs, thus by definition not counted in automated
coverage tools (NULL checking before free),
making malloc calls compile with C++ compilers
(casting the return value of malloc to specific
pointer type), forcing compiler errors if variable
types change (that same cast!).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails

[Viktor Dukhovni]

On Sat, Aug 01, 2015 at 06:56:16AM +0200, Jakob Bohm wrote:

 Or configure a cipherlist more compatible with a long obsolete and
 no longer supported Windows 2003 TLS stack.

Note, I am suggesting compatibility.  Yes while the obsolescence
is long-standing, I was aware that the support status changed just
recently.  The problem with 3DES (for Exchange) is known since
2007, but the fix was never made mainstream, you had to request an
obscure Hotfix (no longer available).


 The Windows 2003 TLS stack became unsupported for most
 (but /not all/) users less than 20 days ago.  Treating
 it as marginal and not as something that any core
 networking library needs to be compatible (even *tested*
 with) out of the box is another symptom of the useless
 attitudes that permeate the new OpenSSL leadership.

You should apologize, I resent that remark.  Behind the scenes I
am working to ensure that we maintain reasonable compatibility with
that stack while it still exists in the field, and have helped many
users craft sensible work-arounds for the bugs in that platform.

It is not so easy to work around the rather severe limitations of
Schannel in Windows 2003.  OpenSSL would have to by default disable
many of the new ciphers in TLS 1.2.  Are you suggesting that the
exclusions I am recommending should have been on by default? To
accommodate a relatively rare and clearly broken peer?

We could consider such an accommodation, but I think that the wiser
course of action is to document the work-around for those who need
it.  This is the first report of this problem I've seen for an
application protocol other SMTP.  It was however immediately
recognizable.

 The old OpenSSL project belonged to the long standing
 tradition of making sure that Internet software needs to
 work with the quirks of anything it could reasonably
 encounter on any real world network, including both the
 Internet, the US military networks (which have allegedly
 paid a boatload of money for continued Win2003 support)
 and any closed site networks that reuse Internet protocols
 for their internal operations.

You seem to be pining for the project that lacked any resources to
pay attention to documentation or code quality.  I think on the
whole more sensible trade-offs are being made now.  And compatibility
is still important.

 It would have been a serious brown bag moment for the old
 maintainers to discover this in a release made that close
 to (if not even overlapping) the vendor support period for
 such a widely deployed system.  There is a lot of utility
 software which is linked to OpenSSL libraries with very
 little user configurability and which is simply expected
 to just work when transferring data off a (not so) old
 Windows computer.

Who are these old maintainers who aren't around any more?

 The old team would have gone out of their way to make sure
 the standard OpenSSL code would generate backward compatible
 hello records by default, e.g. by ensuring that the
 strongest enabled Win 5.x compatible cipher was within the
 first 64 ciphers if that is indeed the technical solution.

The technical solution is correct, and can be deployed by users
who need it.  By default radical trimming of the cipherlist in new
OpenSSL releases to accommodate a rather obsolete and already
relatively rare platform is likely not the right call.  Perhaps
some of that old team you pine for might speak up as to what
they would like to see done.

Keep in mind that users who want to keep running legacy servers,
can also keep running legacy clients, they don't need to uprade to
anything beyond 1.0.1, that's still supported, and interoperates
with Schannel from 2003 by default.

$ for r in *; do echo === $r ===; $r/bin/openssl ciphers -v 
'DEFAULT:!PSK:!SRP' | grep -n '^RC4-SHA'; done
=== OpenSSL_0_9_8 ===
11:RC4-SHA SSLv3 Kx=RSA  Au=RSA  Enc=RC4(128)  Mac=SHA1
=== OpenSSL_1_0_0 ===
29:RC4-SHA SSLv3 Kx=RSA  Au=RSA  Enc=RC4(128)  Mac=SHA1
=== OpenSSL_1_0_1 ===
57:RC4-SHA SSLv3 Kx=RSA  Au=RSA  Enc=RC4(128)  Mac=SHA1
=== OpenSSL_1_0_2 ===
75:RC4-SHA SSLv3 Kx=RSA  Au=RSA  Enc=RC4(128)  Mac=SHA1
=== OpenSSL_master ===
93:RC4-SHA SSLv3 Kx=RSA  Au=RSA  Enc=RC4(128)  Mac=SHA1

[ The reason I'm excluding PSK and SRP is that IIRC the client only
actually includes these in the HELLO cipher list when an appropriate
password callback is enabled). ]

 OpenSSL is supposed to make sure that practical tools such
 as wget, curl, fetchmail etc. etc. can talk to almost any
 old SSL/TLS implementation that might be found in a dusty
 basement or on an old backup tape somewhere.  Talking to an
 old Netscape Navigator 3.x or a clunky old printer should
 have a high chance of working, while talking to anything
 popular that was up to date with official security updates
 less than 2 years ago (let alone a month) is a simple must.

Yes, open source 

Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails

[Viktor Dukhovni]

On Sat, Aug 01, 2015 at 04:23:54PM +0200, Kurt Roeckx wrote:


  The old team would have gone out of their way to make sure
  the standard OpenSSL code would generate backward compatible
  hello records by default
 
 So it's my understanding that you suggest the default OpenSSL
 client should:

 - Only support SSLv2, SSLv3 and TLS1.0 because things break when
   we we try to talk to some sites indicating we support TLS 1.1
   and/or 1.2?  Maybe we should even disable TLS 1.0 and SSLv3?
 - Don't send any TLS extentions, since some sites don't support
   it?
 - Don't send any cipher strings with the first byte different from
   0 because some implemantation don't look at the first byte and
   might then select a cipher we didn't announce?
 - Enable all the work arounds for broken implementations again,
   even when they can be exploited?
 - Give RC4 such a priority by default that it's in the list before
   much stronger ciphers because that's the only cipher from our
   default list that works with some implementations, even when the
   RFCs say we should disable RC4 by default?
 
 I guess we should just stop trying to improve in general.

There is a pragmatic middle-ground that I think we're actually
largely successful at achieving.  Nobody will adopt all the cool
new stuff if it significantly breaks interoperability with the old.

So we have, for example, the padding extension for the client HELLO
to work around F5 problems, and various bug work-arounds are still
enabled via SSL_OP_ALL.

Neither full-steam ahead, nor maintaining compatibility crutches
forever is the right answer.

It turns out that the Windows 2003 stack issue has not received
much attention outside the Postfix user community (Postfix enables
anon_DH and anon_ECDH ciphers and so ran into this sooner than
other applications).  But even with Postfix, the impact has been
rather modest, these systems are not that common.

Should I have a made a greater fuss about ensuring interop with
Windows 2003, I don't know.  I certainly mentioned it on various
non-Postfix lists at various times.  Various members of the old
team were on some of those lists.  Perhaps more effort should
have been made to accommodate such systems for a longer time,
by enabling fewer new ciphers by default, but that's not what
happened, and there have not been very many problem reports.

All this I think points to a reasonably responsible process, with
a largely reasonable outcome.  If a consensus emerges around a
concise cipherlist (note that to get there I had to disable DSS,
which might not be popular in .gov circles, where perhaps it was
actually used), I'd support that, but it is not clear to me that
there's a compelling case to make this a default configuration.

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

Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails

[Kurt Roeckx]

On Sat, Aug 01, 2015 at 06:56:16AM +0200, Jakob Bohm wrote:
 
 The old team would have gone out of their way to make sure
 the standard OpenSSL code would generate backward compatible
 hello records by default

So it's my understanding that you suggest the default OpenSSL
client should:
- Only support SSLv2, SSLv3 and TLS1.0 because things break when
  we we try to talk to some sites indicating we support TLS 1.1
  and/or 1.2?  Maybe we should even disable TLS 1.0 and SSLv3?
- Don't send any TLS extentions, since some sites don't support
  it?
- Don't send any cipher strings with the first byte different from
  0 because some implemantation don't look at the first byte and
  might then select a cipher we didn't announce?
- Enable all the work arounds for broken implementations again,
  even when they can be exploited?
- Give RC4 such a priority by default that it's in the list before
  much stronger ciphers because that's the only cipher from our
  default list that works with some implementations, even when the
  RFCs say we should disable RC4 by default?

I guess we should just stop trying to improve in general.


Kurt

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

Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails

[Jakob Bohm]

On 31-07-2015 23:06, Viktor Dukhovni wrote:

On Fri, Jul 31, 2015 at 08:47:45PM +, Felix Almeida wrote:


I've tested other OpenSSL versions and everything goes well up to version
1.0.1o, starting from 1.0.2 I see this handshake error.

It seems you're posting follow-ups without checking whether your
original post was answered.


I also tried to disable TLS on 1.0.2d by passing no-tls to the config
script, but this broke the building process (make stopped with an error).
So I believe I will stick with version 1.0.1o for now. :-\

Or configure a cipherlist more compatible with a long obsolete and
no longer supported Windows 2003 TLS stack.


The Windows 2003 TLS stack became unsupported for most
(but /not all/) users less than 20 days ago.  Treating
it as marginal and not as something that any core
networking library needs to be compatible (even *tested*
with) out of the box is another symptom of the useless
attitudes that permeate the new OpenSSL leadership.

The old OpenSSL project belonged to the long standing
tradition of making sure that Internet software needs to
work with the quirks of anything it could reasonably
encounter on any real world network, including both the
Internet, the US military networks (which have allegedly
paid a boatload of money for continued Win2003 support)
and any closed site networks that reuse Internet protocols
for their internal operations.

It would have been a serious brown bag moment for the old
maintainers to discover this in a release made that close
to (if not even overlapping) the vendor support period for
such a widely deployed system.  There is a lot of utility
software which is linked to OpenSSL libraries with very
little user configurability and which is simply expected
to just work when transferring data off a (not so) old
Windows computer.

The old team would have gone out of their way to make sure
the standard OpenSSL code would generate backward compatible
hello records by default, e.g. by ensuring that the
strongest enabled Win 5.x compatible cipher was within the
first 64 ciphers if that is indeed the technical solution.

Such real world quality issues are much more important than
making sure broken test tools don't complain that code to
prevent accidental heap corruption is not being called by
the current test suite because the relevant coding errors
have not yet happened.

OpenSSL is supposed to make sure that practical tools such
as wget, curl, fetchmail etc. etc. can talk to almost any
old SSL/TLS implementation that might be found in a dusty
basement or on an old backup tape somewhere.  Talking to an
old Netscape Navigator 3.x or a clunky old printer should
have a high chance of working, while talking to anything
popular that was up to date with official security updates
less than 2 years ago (let alone a month) is a simple must.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Soborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

[openssl-users] [openssl-1.0.2d] default SSL handshake fails

[Felix Almeida]

Hello,

I was trying to establish a secure connection from an old Linux box to an 
internal AD server (via LDAPS) but it was failing during the handshake. The AD 
server accepts SSL2, SSL3 and TLS1.
See below the output:

$ openssl s_client -connect myserver.rogers.com:636 -CAfile 
/home/myuser/openssl/certs/myserver_cert.pem
CONNECTED(0003)
182899955200:error:140790E5:SSL routines:ssl23_write:ssl handshake 
failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 318 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
---

However, if I add any of the following command line options then it works: 
-ssl2, -ssl3, -tls1, -no_tls1, -no_tls1_1, -no_tls1_2.
See below the output:

$ openssl s_client -connect myserver.rogers.com:636 -CAfile 
/home/myuser/openssl/certs/myserver_cert.pem -tls1
CONNECTED(0003)
depth=1 C = CA, O = Rogers Inc., OU = Security, CN = Architecture
verify return:1
depth=0 CN = MYSERVER.rogers.com
verify return:1
---
Certificate chain
 0 s:/CN=MSERVER.rogers.com
   i:/C=CA/O=Rogers Inc./OU=Security/CN=Architecture
---
Server certificate
-BEGIN CERTIFICATE-
...
-END CERTIFICATE-
subject=/CN=MYSERVER.rogers.com
issuer=/C=CA/O=Rogers Inc./OU=Security/CN=Architecture
---
Acceptable client certificate CA names
...
Client Certificate Types: RSA sign, DSA sign
---
SSL handshake has read 4746 bytes and written 404 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1
Cipher: RC4-MD5
Session-ID: 6D055CFB1BC5194D8B3BD939EADFD5AFF2E19D92CA010A54696403E63E99
Session-ID-ctx:
Master-Key: 
707D5B10E21FF30B29238D6637C19ACC79382208DBE8F72A05C605424B63258B1B1C4A83C67F17B8E0A62EF67B2B6703
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1438364635
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
---

This is the OpenSSL version I'm using:

$ openssl version -a
OpenSSL 1.0.2d 9 Jul 2015
built on: reproducible build, date unspecified
platform: linux-x86_64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx)
compiler: gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DZLIB 
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack 
-m64 -DL_ENDIAN -O3 -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 -DECP_NISTZ256_ASM
OPENSSLDIR: /home/myuser/openssl

My client box is an old Red Hat Enterprise Linux AS release 4 (Nahant Update 
9). Below is a little extra info on it, in case it helps:

$ uname -a
Linux elxin009 2.6.9-100.ELsmp #1 SMP Tue Feb 1 12:04:42 EST 2011 x86_64 x86_64 
x86_64 GNU/Linux

$ ldd ~/bin/openssl
libssl.so.1.0.0 = /home/myuser/lib/libssl.so.1.0.0 (0x002a95558000)
libcrypto.so.1.0.0 = /home/myuser/lib/libcrypto.so.1.0.0 
(0x002a956c9000)
libdl.so.2 = /lib64/libdl.so.2 (0x0035ebe0)
libz.so.1 = /home/myuser/lib/libz.so.1 (0x002a959e2000)
libc.so.6 = /lib64/tls/libc.so.6 (0x0035eb90)
/lib64/ld-linux-x86-64.so.2 (0x00552000)

One final additional information is that I tried to do the exact same thing 
from a CentOS 6.6 client server and it just worked without any issues using 
CentOS standard RPMs. However the OpenSSL version there is the following:

$ openssl version -a
OpenSSL 1.0.1e-fips 11 Feb 2013
built on: Mon Jun 15 18:29:40 UTC 2015
platform: linux-x86_64
options:  bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) 
blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT 
-DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -DTERMIO -Wall -O2 -g 
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m64 -mtune=generic -Wa,--noexecstack -DPURIFY 
-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
OPENSSLDIR: /etc/pki/tls
engines:  dynamic

Since my ultimate goal is to connect to the server via LDAPS but apparently 
OpenLDAP doesn't let me force a particular protocol (TLS1) then I feel I'm 
stuck. Perhaps I will recompile OpenSSL without TLS to see if it works, but I 
really don't want to this way.

Any ideas how I can make this work? Is this a bug during the handshake phase?

Thank you,
Felix






This communication is confidential. We only send and receive email on the basis 
of the terms set out at 
www.rogers.com/web/content

Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails

[Viktor Dukhovni]

On Fri, Jul 31, 2015 at 06:43:18PM +, Felix Almeida wrote:

 I was trying to establish a secure connection from an old Linux box to an
 internal AD server (via LDAPS) but it was failing during the handshake.
 The AD server accepts SSL2, SSL3 and TLS1.

Is it Windows server 2003?  It likely only supports RC4 and 3DES, and only
if these appear in the first 64 elements of the client's cipherlist.
When a TLS 1.2 handshake is sent, may newer ciphers appear before the server's
RC4 and 3DES (the latter is broken in Microsoft Exchange on Windows 2003, but
may work with LDAP).

 However, if I add any of the following command line options then it works: 
 -ssl2, -ssl3, -tls1, -no_tls1, -no_tls1_1, -no_tls1_2.

All these disable TLS 1.2 (and perhaps other protocol versions), and result
in a shorter cipherlist.

 SSL-Session:
 Protocol  : TLSv1
 Cipher: RC4-MD5

Bingo: RC4-MD5, it likely also supports RSA-SHA.  Here's a sensibly
trimmed, but widely interoperable cipherlist:

$ 
c='HIGH:MEDIUM:@STRENGTH:+3DES:+RC4:!aNULL:!MD5:!SRP:!PSK:!aDSS:!kECDH:!kDH:!SEED,!IDEA:!RC2:!RC5'
$ openssl s_client -cipher $c ...

The resulting cipherlist with OpenSSL 1.0.2 is:

1:ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA  Enc=AESGCM(256) 
Mac=AEAD
2:ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA 
Enc=AESGCM(256) Mac=AEAD
3:ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA  Enc=AES(256)  
Mac=SHA384
4:ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256)  
Mac=SHA384
5:ECDHE-RSA-AES256-SHASSLv3 Kx=ECDH Au=RSA  Enc=AES(256)  Mac=SHA1
6:ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256)  Mac=SHA1
7:DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH   Au=RSA  Enc=AESGCM(256) 
Mac=AEAD
8:DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH   Au=RSA  Enc=AES(256)  
Mac=SHA256
9:DHE-RSA-AES256-SHA  SSLv3 Kx=DH   Au=RSA  Enc=AES(256)  Mac=SHA1
10:DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH   Au=RSA  Enc=Camellia(256) 
Mac=SHA1
11:AES256-GCM-SHA384   TLSv1.2 Kx=RSA  Au=RSA  Enc=AESGCM(256) 
Mac=AEAD
12:AES256-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AES(256)  
Mac=SHA256
13:AES256-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA1
14:CAMELLIA256-SHA SSLv3 Kx=RSA  Au=RSA  Enc=Camellia(256) 
Mac=SHA1
15:ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA  Enc=AESGCM(128) 
Mac=AEAD
16:ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA 
Enc=AESGCM(128) Mac=AEAD
17:ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA  Enc=AES(128)  
Mac=SHA256
18:ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128)  
Mac=SHA256
19:ECDHE-RSA-AES128-SHASSLv3 Kx=ECDH Au=RSA  Enc=AES(128)  Mac=SHA1
20:ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128)  Mac=SHA1
21:DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH   Au=RSA  Enc=AESGCM(128) 
Mac=AEAD
22:DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH   Au=RSA  Enc=AES(128)  
Mac=SHA256
23:DHE-RSA-AES128-SHA  SSLv3 Kx=DH   Au=RSA  Enc=AES(128)  Mac=SHA1
24:DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH   Au=RSA  Enc=Camellia(128) 
Mac=SHA1
25:AES128-GCM-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AESGCM(128) 
Mac=AEAD
26:AES128-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AES(128)  
Mac=SHA256
27:AES128-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(128)  Mac=SHA1
28:CAMELLIA128-SHA SSLv3 Kx=RSA  Au=RSA  Enc=Camellia(128) 
Mac=SHA1
29:ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH Au=RSA  Enc=3DES(168) Mac=SHA1
30:ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) 
Mac=SHA1
31:EDH-RSA-DES-CBC3-SHASSLv3 Kx=DH   Au=RSA  Enc=3DES(168) Mac=SHA1
32:DES-CBC3-SHASSLv3 Kx=RSA  Au=RSA  Enc=3DES(168) Mac=SHA1
33:ECDHE-RSA-RC4-SHA   SSLv3 Kx=ECDH Au=RSA  Enc=RC4(128)  Mac=SHA1
34:ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128)  Mac=SHA1
35:RC4-SHA SSLv3 Kx=RSA  Au=RSA  Enc=RC4(128)  Mac=SHA1

Your LDAP server will choose #35: RC4-SHA.  Other servers will make
better choices, and nothing remotely mainstream or required for
interoperability is excluded.

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

Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails

[Felix Almeida]

I've tested other OpenSSL versions and everything goes well up to version 
1.0.1o, starting from 1.0.2 I see this handshake error.

I also tried to disable TLS on 1.0.2d by passing no-tls to the config script, 
but this broke the building process (make stopped with an error). So I believe 
I will stick with version 1.0.1o for now. :-\


-Original Message-
From: Felix Almeida
Sent: Friday, July 31, 2015 2:43 PM
To: 'openssl-users@openssl.org'
Subject: [openssl-1.0.2d] default SSL handshake fails

Hello,

I was trying to establish a secure connection from an old Linux box to an 
internal AD server (via LDAPS) but it was failing during the handshake. The AD 
server accepts SSL2, SSL3 and TLS1.
See below the output:

$ openssl s_client -connect myserver.rogers.com:636 -CAfile 
/home/myuser/openssl/certs/myserver_cert.pem
CONNECTED(0003)
182899955200:error:140790E5:SSL routines:ssl23_write:ssl handshake 
failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 318 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
---

However, if I add any of the following command line options then it works: 
-ssl2, -ssl3, -tls1, -no_tls1, -no_tls1_1, -no_tls1_2.
See below the output:

$ openssl s_client -connect myserver.rogers.com:636 -CAfile 
/home/myuser/openssl/certs/myserver_cert.pem -tls1
CONNECTED(0003)
depth=1 C = CA, O = Rogers Inc., OU = Security, CN = Architecture
verify return:1
depth=0 CN = MYSERVER.rogers.com
verify return:1
---
Certificate chain
 0 s:/CN=MSERVER.rogers.com
   i:/C=CA/O=Rogers Inc./OU=Security/CN=Architecture
---
Server certificate
-BEGIN CERTIFICATE-
...
-END CERTIFICATE-
subject=/CN=MYSERVER.rogers.com
issuer=/C=CA/O=Rogers Inc./OU=Security/CN=Architecture
---
Acceptable client certificate CA names
...
Client Certificate Types: RSA sign, DSA sign
---
SSL handshake has read 4746 bytes and written 404 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1
Cipher: RC4-MD5
Session-ID: 6D055CFB1BC5194D8B3BD939EADFD5AFF2E19D92CA010A54696403E63E99
Session-ID-ctx:
Master-Key: 
707D5B10E21FF30B29238D6637C19ACC79382208DBE8F72A05C605424B63258B1B1C4A83C67F17B8E0A62EF67B2B6703
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1438364635
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
---

This is the OpenSSL version I'm using:

$ openssl version -a
OpenSSL 1.0.2d 9 Jul 2015
built on: reproducible build, date unspecified
platform: linux-x86_64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx)
compiler: gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DZLIB 
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack 
-m64 -DL_ENDIAN -O3 -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 -DECP_NISTZ256_ASM
OPENSSLDIR: /home/myuser/openssl

My client box is an old Red Hat Enterprise Linux AS release 4 (Nahant Update 
9). Below is a little extra info on it, in case it helps:

$ uname -a
Linux elxin009 2.6.9-100.ELsmp #1 SMP Tue Feb 1 12:04:42 EST 2011 x86_64 x86_64 
x86_64 GNU/Linux

$ ldd ~/bin/openssl
libssl.so.1.0.0 = /home/myuser/lib/libssl.so.1.0.0 (0x002a95558000)
libcrypto.so.1.0.0 = /home/myuser/lib/libcrypto.so.1.0.0 
(0x002a956c9000)
libdl.so.2 = /lib64/libdl.so.2 (0x0035ebe0)
libz.so.1 = /home/myuser/lib/libz.so.1 (0x002a959e2000)
libc.so.6 = /lib64/tls/libc.so.6 (0x0035eb90)
/lib64/ld-linux-x86-64.so.2 (0x00552000)

One final additional information is that I tried to do the exact same thing 
from a CentOS 6.6 client server and it just worked without any issues using 
CentOS standard RPMs. However the OpenSSL version there is the following:

$ openssl version -a
OpenSSL 1.0.1e-fips 11 Feb 2013
built on: Mon Jun 15 18:29:40 UTC 2015
platform: linux-x86_64
options:  bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) 
blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT 
-DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -DTERMIO -Wall -O2 -g 
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m64 -mtune=generic -Wa,--noexecstack -DPURIFY 
-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
OPENSSLDIR: /etc/pki/tls
engines:  dynamic

Since my ultimate goal

Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails

[Viktor Dukhovni]

On Fri, Jul 31, 2015 at 08:47:45PM +, Felix Almeida wrote:

 I've tested other OpenSSL versions and everything goes well up to version
 1.0.1o, starting from 1.0.2 I see this handshake error.

It seems you're posting follow-ups without checking whether your
original post was answered.

 I also tried to disable TLS on 1.0.2d by passing no-tls to the config
 script, but this broke the building process (make stopped with an error).
 So I believe I will stick with version 1.0.1o for now. :-\

Or configure a cipherlist more compatible with a long obsolete and
no longer supported Windows 2003 TLS stack.

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

Re: [openssl-users] External hardware for SSL handshake (overriding PreMasterSecret decrypt)

[Pavel Abramov]

thanks! 

Unfortunately there is no pkcs11 wrapper for this device.
There are a few commands implementing RSA operations (generate keyPair, 
PreMaster decrypt) and I have to use them to perform server-side SSL handshake.



OpenSC looks very interesting for my task.




Pavel


- openssl-users openssl-users-boun...@openssl.org: -
Re: [openssl-users] External hardware for SSL handshake (overriding 
PreMasterSecret decrypt)

On 27/05/2015 15:26, Pavel Abramov wrote:
Hi, 

I have a task to use external Security Module to perform RSA functions in my 
WEB-server (nginx/httpd using OpenSSL for HTTPS).
The goal is to store Server private key components and establish SSL Handshake 
using Hardware module. It is not an SSL hardware accelerator.

This device has proprietary API (binary protocol over TCP/UDP, a few commands 
like generate RSA key pair, premaster decrypt using key#123).

What is the easiest way to do it? Will be very grateful for keywords/advices.
Should I write my ENGINE ? Or is there any other way? 

I need only 2 functions to perform using hardware: 
- RSA key generation (private component will be saved in hardware module)
- PreMaster decrypt from client during SSL handshake

How to override only these 2 functions?

---
If there is a generic engine wrapping pkcs11 or a similar 
API, it may or may not be easier to implement (or reuse 
if already provided) a hardware specific pkcs11 (or 
similar) driver.

I am unsure if there is or is not a well maintained 
pkcs11 engine for OpenSSL, either in the OpenSSL project
or elsewhere.  Maybe the opensc project has one, but I 
don't know if that would be general or specific to opensc 
pkcs11 drivers.

Keywords to search for: 
pkcs11, pkcs11 engine, opensc project, openssl engine.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: [openssl-users] External hardware for SSL handshake (overriding PreMasterSecret decrypt)

[Jakob Bohm]

On 27/05/2015 15:26, Pavel Abramov wrote:

Hi,

I have a task to use external Security Module to perform RSA functions in my 
WEB-server (nginx/httpd using OpenSSL for HTTPS).
The goal is to store Server private key components and establish SSL Handshake 
using Hardware module. It is not an SSL hardware accelerator.

This device has proprietary API (binary protocol over TCP/UDP, a few commands like generate 
RSA key pair, premaster decrypt using key#123).

What is the easiest way to do it? Will be very grateful for keywords/advices.
Should I write my ENGINE ? Or is there any other way?

I need only 2 functions to perform using hardware:
- RSA key generation (private component will be saved in hardware module)
- PreMaster decrypt from client during SSL handshake

How to override only these 2 functions?

If there is a generic engine wrapping pkcs11 or a similar
API, it may or may not be easier to implement (or reuse
if already provided) a hardware specific pkcs11 (or
similar) driver.

I am unsure if there is or is not a well maintained
pkcs11 engine for OpenSSL, either in the OpenSSL project
or elsewhere.  Maybe the opensc project has one, but I
don't know if that would be general or specific to opensc
pkcs11 drivers.

Keywords to search for:
pkcs11, pkcs11 engine, opensc project, openssl engine.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

[openssl-users] External hardware for SSL handshake (overriding PreMasterSecret decrypt)

[Pavel Abramov]

Hi, 

I have a task to use external Security Module to perform RSA functions in my 
WEB-server (nginx/httpd using OpenSSL for HTTPS).
The goal is to store Server private key components and establish SSL Handshake 
using Hardware module. It is not an SSL hardware accelerator.

This device has proprietary API (binary protocol over TCP/UDP, a few commands 
like generate RSA key pair, premaster decrypt using key#123).

What is the easiest way to do it? Will be very grateful for keywords/advices.
Should I write my ENGINE ? Or is there any other way? 

I need only 2 functions to perform using hardware: 
- RSA key generation (private component will be saved in hardware module)
- PreMaster decrypt from client during SSL handshake

How to override only these 2 functions?


Thanks in advance!



Pavel

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

SSL Handshake difference between 0.9.8g v/s 1.0.0e

[Rohit Bansal]

Hi,

I am migrating my application from 0.9.8g to 1.0.1e and using an external
session cache for ssl session renegotiation.

I notice slight performance degradation when running 1.0.1e

When i debug using ssldumo here is what i observe:
*0.9.8g*

New TCP connection #6: localhost.localdomain(59162) -
localhost.localdomain(12346)
6 1  0. (0.)  CSV3.1(81)  Handshake
  ClientHello
Version 3.1
random[32]=
  52 d8 8a 50 53 9a 04 32 dc 38 89 93 b1 ea b2 bb
  50 71 08 a4 02 44 6f 8e 12 fc cb 75 0a 64 cc b0
resume [32]=
  cf b7 4b 45 69 a1 72 7d cc 0f 0d 84 9d e7 c2 3d
  c0 e3 d8 70 06 80 02 71 71 16 9a bf da 99 2a 2d
cipher suites
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
compression methods
  NULL
6 2  0.0011 (0.0010)  SCV3.1(74)  Handshake
  ServerHello
Version 3.1
random[32]=
  52 d8 8a 50 22 5b 5c db 99 15 8f 57 3a 9c 3b 9d
  c3 bd 9b 9b a8 3f 7d 66 a3 fd a1 4e 2f 2e 3c a6
session_id[32]=
  cf b7 4b 45 69 a1 72 7d cc 0f 0d 84 9d e7 c2 3d
  c0 e3 d8 70 06 80 02 71 71 16 9a bf da 99 2a 2d
cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA
compressionMethod   NULL
6 3  0.0011 (0.)  SCV3.1(1)  ChangeCipherSpec
6 4  0.0011 (0.)  SCV3.1(40)  Handshake
6 5  0.0013 (0.0001)  CSV3.1(1)  ChangeCipherSpec
6 6  0.0013 (0.)  CSV3.1(40)  Handshake
6 7  0.0014 (0.0001)  CSV3.1(24)  application_data
6 8  0.0014 (0.)  CSV3.1(960)  application_data
6 9  0.0045 (0.0031)  SCV3.1(24)  application_data
6 10 0.0045 (0.)  SCV3.1(640)  application_data
6 11 0.0062 (0.0016)  CSV3.1(24)  Alert
6 12 0.0063 (0.)  SCV3.1(24)  Alert
60.0064 (0.0001)  CS  TCP RST


*1.0.1e*
New TCP connection #7: localhost.localdomain(59171) -
localhost.localdomain(12346)
7 1  0. (0.)  CSV3.1(94)  Handshake
  ClientHello
Version 3.1
random[32]=
  52 d8 8a a9 cf 2d eb 75 51 44 f8 3e 6a 55 03 4f
  5d a8 99 3e 4e ca 14 da a8 ea a0 8e 3c f0 45 48
resume [32]=
  cf b7 4b 45 69 a1 72 7d cc 0f 0d 84 9d e7 c2 3d
  c0 e3 d8 70 06 80 02 71 71 16 9a bf da 99 2a 2d
cipher suites
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Unknown value 0xff
compression methods
  NULL
7 2  0.0017 (0.0016)  SCV3.1(90)  Handshake
  ServerHello
Version 3.1
random[32]=
  52 d8 8a a9 b1 12 c9 db cc 61 cf fb e5 34 b5 4b
  c3 54 2a f7 19 9b b9 03 e8 65 36 70 c0 a0 fc 66
session_id[32]=
  cf b7 4b 45 69 a1 72 7d cc 0f 0d 84 9d e7 c2 3d
  c0 e3 d8 70 06 80 02 71 71 16 9a bf da 99 2a 2d
cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA
compressionMethod   NULL
*7 3  0.0017 (0.)  SCV3.1(1178)  Handshake*
*  TLS_RSA_WITH_RC4_128_MD5*
7 4  0.0017 (0.)  SCV3.1(1)  ChangeCipherSpec
7 5  0.0017 (0.)  SCV3.1(40)  Handshake
7 6  0.0019 (0.0002)  CSV3.1(1)  ChangeCipherSpec
7 7  0.0019 (0.)  CSV3.1(40)  Handshake
7 8  0.0021 (0.0001)  CSV3.1(24)  application_data
7 9  0.0021 (0.)  CSV3.1(960)  application_data
7 10 0.0052 (0.0030)  SCV3.1(24)  application_data
7 11 0.0052 (0.)  SCV3.1(640)  application_data
7 12 0.0069 (0.0017)  CSV3.1(24)  Alert
7 13 0.0070 (0.)  SCV3.1(24)  Alert
70.0071 (0.)  CS  TCP RST


I am wondering why ssldump is printing an extra handshake message with the
cipher which i have not enabled in my code. Any pointers on what could be
going on here?

-- 
Rohit Bansal

RE: ssl handshake failure in 1.0.1 but not 1.0.0

[Ben Arnold]

 From: Dave Thompson
 
  Yes, the server has a custom root cert that isn't installed on this
 machine.  I am happy that the server cert is correct.
 
 For testing that's okay, but I hope in real use you are verifying.
 Otherwise an active attacker may be able to MITM your connections.

Production environments do a peer verification.  I disabled that for 
development purposes.
 
 The ServerHello does indeed contain the secure-renegotiation extension in
 one pcap and not the other. Assuming there isn't some really weird logic on
 the server that supports 5746 only sometimes, this might be due to the
 (much) larger cipherlist -- OpenSSL puts ERI-SCSV at the end of the 
 cipherlist,
 so if the server can only handle maybe 32 or 50 or so entries in the 
 cipherlist it
 might not see ERI in the default-ciphers case.
 
 You could experiment with intermediate size cipherlists -- my suggestion of
 forcing -tls1 by itself takes you down from 80 to 52 (because it implicitly
 disables the TLSv1.2-only SHA2 and GCM suites), or so does explicit -cipher
 DEFAULT:!TLSv1.2 . Removing more things you shouldn't want anyway goes
 lower e.g. DEFAULT:!TLSv1.2:!EXPORT:!LOW:!SRP:!kECDH should be 30.
[snip]
 If the problem is the length of the ClientHello and/or cipherlist -- as is
 consistent with but not conclusively proven by what you've seen so far, and
 is somewhat similar to the fact that other servers have already been found to
 fail or hang *initial* negotiation when ClientHello = 256 bytes (although 
 this
 server did *not* fail there), just using a shorter cipherlist
 should work. A few akRSA, one or two DHE-RSA and ECDHE-RSA because a
 server with RSA can still do akRSA unless KU prohibits, a few ECDHE-ECDSA
 and perhaps a few DHE-DSS -- maybe 20 total -- should handle any sane
 server.

That's great, thank you for the detailed explanations.

Your hunch that the problem lies with the length of the cipherlist seems to 
bear out; I removed some of the ciphers you suggested and the server still 
happily connects.  It creates a Client Hello of 198 bytes which should also 
avoid the other problem you mention (that I haven't seen on this particular 
server).

Thanks for all the help,
Ben

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

RE: ssl handshake failure in 1.0.1 but not 1.0.0

[Dave Thompson]

 From: owner-openssl-users On Behalf Of Ben Arnold
 Sent: Friday, November 08, 2013 10:45
snip
 I have tried using s_client and it fails with the same handshake failure.
Please
 see below.
 
 
  Attaching a PCAP file of the traffic is much more useful than hex packet
  dumps.
 
 You're right of course, that is much more sensible.  I have attached two
pcap
 traces from s_connect, one success and one failure.
 
 
  From: Dave Thompson
snip: server cert
 Yes, the server has a custom root cert that isn't installed on this
machine.  I
 am happy that the server cert is correct.

For testing that's okay, but I hope in real use you are verifying.
Otherwise an active attacker may be able to MITM your connections.

  To OP: If you can try to reproduce with s_client default (which is
  TLSv1.2 or less) and again specifying -tls1 (or -no_tls1_2 -no_tls1_1).
  That might narrow it down pretty close.
 
 I can reproduce the failure with s_client in the same manner.  It looks
(to me)
 like the server only asks for the client certificate once the GET command
has
 been issued, the initial negotiation doesn't ask for it.  I don't know the
TLS
 protocol so that might be normal.  Once I send the GET ... command it
tries to

Yes. More exactly, on the initial negotiation the server does not request
client auth 
(and thus openssl doesn't obtain and send it). After curl or s_client/you
sends 
the GET request, the server initiates renegotiation and does request client
auth 
except in the case using 1.0.1 where it fails before getting to that point.

Renegotiation is a standard capability of SSL/TLS and can be initiated by
either 
client or server. Whether and when it is used depends on the applications 
using SSL/TLS. *For HTTPS*, it is not uncommon for webservers to allow 
connection without client auth that can access public resources but
require 
renegotiation with client auth for private resources, and it certainly
appears 
this particular webserver is doing that.

 renegotiate but fails.  Looking at the output from s_client -state I see
this
 during the first negotiation...
 
 ---
 No client certificate CA names sent
 ---
 SSL handshake has read 2884 bytes and written 639 bytes
 ---
 New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA
 Server public key is 2048 bit
 Secure Renegotiation IS NOT supported
 Compression: NONE
 Expansion: NONE
 
 And then I send GET /directory HTTP/1.1 and see...
 
 SSL_connect:SSL renegotiate ciphers
 SSL_connect:unknown state
 SSL_connect:failed in unknown state
 16444:error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake
 failure:.\ssl\s3_pkt.c:1156:
 
 
  From: Krzysztof Kwiatkowski
 
  Do you still see an error if you specify one cipher? f.e. AES256-SHA?
 
 I do get an error when using AES256-SHA, in fact a much earlier error as
the
 server does not support that cipher, nor does it support AES-128-SHA.
 
 However I took the idea and if I add -cipher DES-CBC3-SHA (as selected
by
 the server in the previous run) to s_connect then everything works OK, and
 if I add the same cipher selection to my program that that works too.
When I
 do specify DES-CBC3-SHA, s_client also reports
 
 Secure Renegotiation IS supported
 
 This sounds important to me! :)  Notice that the failure case reports
 renegotiation is NOT supported.
 
To be exact it reports *secure* renegotiation is not supported. There 
are two slightly different renegotiation protocols, the original one 
(now usually called legacy or unsafe) which was found to be somewhat 
vulnerable to a MITM-splicing attack, and the updated RFC5746 one 
(sometimes called by the RFC#, but often just called secure).
Client can detect from ServerHello whether the server supports RFC5746 
(or at least claims to) and the display tells you that. The client can't 
determine if legacy renegotiation is supported except by trying it, and 
even then can't be 100% certain because it could fail for another reason.

The ServerHello does indeed contain the secure-renegotiation extension 
in one pcap and not the other. Assuming there isn't some really weird 
logic on the server that supports 5746 only sometimes, this might be 
due to the (much) larger cipherlist -- OpenSSL puts ERI-SCSV at the end 
of the cipherlist, so if the server can only handle maybe 32 or 50 or so
entries 
in the cipherlist it might not see ERI in the default-ciphers case.

You could experiment with intermediate size cipherlists -- my suggestion 
of forcing -tls1 by itself takes you down from 80 to 52 (because it
implicitly 
disables the TLSv1.2-only SHA2 and GCM suites), or so does explicit -cipher 
DEFAULT:!TLSv1.2 . Removing more things you shouldn't want anyway 
goes lower e.g. DEFAULT:!TLSv1.2:!EXPORT:!LOW:!SRP:!kECDH should be 30.

Or you could try writing a Java SSL client, which allows you to position
ERI-SCSV 
anywhere you want in the list (i.e. end of 80, end of 40, 40th of 80, etc,
etc).

The renegotiation ClientHello is longer than the initial one because of the 
session-id and renegotiation

RE: ssl handshake failure in 1.0.1 but not 1.0.0

[Ben Arnold]

 From: Viktor Dukhovni

 You can test with s_client(1) and compare results.  Is your client 
 certificate an
 RSA certificate?  How many bits of public key?  Is its signature SHA1 or
 SHA256?

It's a 2048 bit RSA SHA1 certificate, but I think Dave Thompson's right and 
it's not getting that far.

I have tried using s_client and it fails with the same handshake failure.  
Please see below.


 Attaching a PCAP file of the traffic is much more useful than hex packet
 dumps. 

You're right of course, that is much more sensible.  I have attached two pcap 
traces from s_connect, one success and one failure.


 From: Dave Thompson
 
 To OP: is the logged server cert info true? I note the log shows the client
 verification of the server failed; did this website give you a custom root 
 to
 trust and did you simply not set that up (or perhaps not in the environment
 you're testing in)?
 

Yes, the server has a custom root cert that isn't installed on this machine.  I 
am happy that the server cert is correct.


 To OP: If you can try to reproduce with s_client default (which is
 TLSv1.2 or less) and again specifying -tls1 (or -no_tls1_2 -no_tls1_1).
 That might narrow it down pretty close.

I can reproduce the failure with s_client in the same manner.  It looks (to me) 
like the server only asks for the client certificate once the GET command has 
been issued, the initial negotiation doesn't ask for it.  I don't know the TLS 
protocol so that might be normal.  Once I send the GET ... command it tries to 
renegotiate but fails.  Looking at the output from s_client -state I see this 
during the first negotiation...

---
No client certificate CA names sent
---
SSL handshake has read 2884 bytes and written 639 bytes
---
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE

And then I send GET /directory HTTP/1.1 and see...

SSL_connect:SSL renegotiate ciphers
SSL_connect:unknown state
SSL_connect:failed in unknown state
16444:error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake 
failure:.\ssl\s3_pkt.c:1156:


 From: Krzysztof Kwiatkowski
 
 Do you still see an error if you specify one cipher? f.e. AES256-SHA?

I do get an error when using AES256-SHA, in fact a much earlier error as the 
server does not support that cipher, nor does it support AES-128-SHA.  

However I took the idea and if I add -cipher DES-CBC3-SHA (as selected by the 
server in the previous run) to s_connect then everything works OK, and if I add 
the same cipher selection to my program that that works too.  When I do specify 
DES-CBC3-SHA, s_client also reports

Secure Renegotiation IS supported

This sounds important to me! :)  Notice that the failure case reports 
renegotiation is NOT supported.

So the question now is, how come negotiation *is* supported when I manually 
specify DES-CBC3-SHA and *not* supported when I leave default ciphers, when the 
server ends up picking DES-CBC3-SHA anyway.

I have attached two pcap files, both captured using s_client - one with the 
default ciphers and one with -cipher DES_CBC3-SHA.  I notice that the Client 
Hello is slightly different, when using all ciphers there are two extra 
extensions: ec_point_formats and elliptic_curves.  Whether or not this is 
relevant I have no idea, I imagine not as they are likely omitted because DES 
isn't ECC.

For now all the servers I need to talk to support DES-CBC3-SHA, this may not 
always be the case.  Any idea how likely it is I will find a server that 
doesn't?  Or is there something else I can set to make renegotiation supported 
without specifying the cipher.

Thanks for all your suggestions so far,
Ben



s_client_default.pcap
Description: s_client_default.pcap


s_client_des_cbc3_sha.pcap
Description: s_client_des_cbc3_sha.pcap

Re: ssl handshake failure in 1.0.1 but not 1.0.0

[Viktor Dukhovni]

On Thu, Nov 07, 2013 at 12:29:13PM +, Ben Arnold wrote:

 I am using SSL_CTX_set_client_cert_cb to provide the client
 certificate when needed.  I have a problem in that OpenSSL 1.0.1e
 does not trigger this callback for all websites that I expect it
 to, only some.  Instead on the failing sites there is an SSL
 handshake failure after the client verifies the server certificate:

You can test with s_client(1) and compare results.  Is your client
certificate an RSA certificate?  How many bits of public key?  Is
its signature SHA1 or SHA256?

 SSL read: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake
 failure, errno 0
 
 Interestingly if I compile against 1.0.0k then there is no failure
 and the callback *is* triggered for all sites (that I have tried
 so far anyway).

Sounds like a problem with TLSv1.2.  If your client certificate is
only 512-bits it may not be wide enough to sign a SHA384 digest,
or some other TLSv1.2 parameter issue.

Attaching a PCAP file of the traffic is much more useful than hex
packet dumps.  Capture the traffic with tcpdump -s0 -w file ...
and look with wireshark -r file.  If you don't understand the
wireshark output, post the (binary) PCAP file containing just one
failed TLS handshake, perhaps also a PCAP file with a succesful
TLS handshake.

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

RE: ssl handshake failure in 1.0.1 but not 1.0.0

[Dave Thompson]

 From: owner-openssl-users On Behalf Of Viktor Dukhovni
 Sent: Thursday, November 07, 2013 11:02

 On Thu, Nov 07, 2013 at 12:29:13PM +, Ben Arnold wrote:
 
  I am using SSL_CTX_set_client_cert_cb to provide the client
  certificate when needed.  I have a problem in that OpenSSL 1.0.1e
  does not trigger this callback for all websites that I expect it
  to, only some.  Instead on the failing sites there is an SSL
  handshake failure after the client verifies the server certificate:
 
 You can test with s_client(1) and compare results.  Is your client
 certificate an RSA certificate?  How many bits of public key?  Is
 its signature SHA1 or SHA256?
 
OP's log shows protocol hasn't reached the CertReq - ClientCert steps 
so at this point nothing about the client cert should matter. (And in any 
case the signature *on* the cert is by the CA key, unless it's self signed,
in which case using it for client-auth would be really silly. From the log,
unless OP fixed it, the server cert looks like a DIY CA, and if someone 
does that for the server I would expect it for clients also.)

To OP: is the logged server cert info true? I note the log shows 
the client verification of the server failed; did this website give you 
a custom root to trust and did you simply not set that up 
(or perhaps not in the environment you're testing in)?

  SSL read: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake
  failure, errno 0
 
  Interestingly if I compile against 1.0.0k then there is no failure
  and the callback *is* triggered for all sites (that I have tried
  so far anyway).
 
 Sounds like a problem with TLSv1.2.  If your client certificate is
 only 512-bits it may not be wide enough to sign a SHA384 digest,
 or some other TLSv1.2 parameter issue.
 
Client hasn't even selected the cert yet. And although I agree 
a PCAP is better in general than a less-complete program log,
just looking at the headers in the log you can see the client 
offered TLSv1.2 (0303) but the server only accepted TLSv1 (0301) 
so there definitely isn't any SHA-2 issue.

But something else related to TLSv1.2 does seem likely. Possibly 
the new larger size (as OP observed), or the new extensions,
although the initial negotiation apparently worked fine with both.

 Attaching a PCAP file of the traffic is much more useful than hex
 packet dumps.  Capture the traffic with tcpdump -s0 -w file ...
 and look with wireshark -r file.  If you don't understand the
 wireshark output, post the (binary) PCAP file containing just one
 failed TLS handshake, perhaps also a PCAP file with a succesful
 TLS handshake.
 
I do notice the second ClientHello -- in response to server request -- 
using 1.0.1 re-offers TLSv1.2. I thought it was good practice when 
we know the server has previously rejected something not to re-offer it,
but I don't recall where I saw this and I might well be wrong. Even so 
the server should negotiate down (as it did initially) or at minimum 
send an alert, not just close. 

To OP: If you can try to reproduce with s_client default (which is 
TLSv1.2 or less) and again specifying -tls1 (or -no_tls1_2 -no_tls1_1).
That might narrow it down pretty close. 



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

RE: ssl handshake failure in 1.0.1 but not 1.0.0

[Krzysztof Kwiatkowski]

Do you still see an error if you specify one cipher? f.e. AES256-SHA?

On 2013-11-07 22:26, Dave Thompson wrote:

From: owner-openssl-users On Behalf Of Viktor Dukhovni
Sent: Thursday, November 07, 2013 11:02



On Thu, Nov 07, 2013 at 12:29:13PM +, Ben Arnold wrote:

 I am using SSL_CTX_set_client_cert_cb to provide the client
 certificate when needed.  I have a problem in that OpenSSL 1.0.1e
 does not trigger this callback for all websites that I expect it
 to, only some.  Instead on the failing sites there is an SSL
 handshake failure after the client verifies the server 
certificate:


You can test with s_client(1) and compare results.  Is your client
certificate an RSA certificate?  How many bits of public key?  Is
its signature SHA1 or SHA256?

OP's log shows protocol hasn't reached the CertReq - ClientCert 
steps
so at this point nothing about the client cert should matter. (And in 
any
case the signature *on* the cert is by the CA key, unless it's self 
signed,
in which case using it for client-auth would be really silly. From 
the log,
unless OP fixed it, the server cert looks like a DIY CA, and if 
someone

does that for the server I would expect it for clients also.)

To OP: is the logged server cert info true? I note the log shows
the client verification of the server failed; did this website give 
you

a custom root to trust and did you simply not set that up
(or perhaps not in the environment you're testing in)?

 SSL read: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl 
handshake

 failure, errno 0

 Interestingly if I compile against 1.0.0k then there is no failure
 and the callback *is* triggered for all sites (that I have tried
 so far anyway).

Sounds like a problem with TLSv1.2.  If your client certificate is
only 512-bits it may not be wide enough to sign a SHA384 digest,
or some other TLSv1.2 parameter issue.


Client hasn't even selected the cert yet. And although I agree
a PCAP is better in general than a less-complete program log,
just looking at the headers in the log you can see the client
offered TLSv1.2 (0303) but the server only accepted TLSv1 (0301)
so there definitely isn't any SHA-2 issue.

But something else related to TLSv1.2 does seem likely. Possibly
the new larger size (as OP observed), or the new extensions,
although the initial negotiation apparently worked fine with both.


Attaching a PCAP file of the traffic is much more useful than hex
packet dumps.  Capture the traffic with tcpdump -s0 -w file ...
and look with wireshark -r file.  If you don't understand the
wireshark output, post the (binary) PCAP file containing just one
failed TLS handshake, perhaps also a PCAP file with a succesful
TLS handshake.

I do notice the second ClientHello -- in response to server request 
--

using 1.0.1 re-offers TLSv1.2. I thought it was good practice when
we know the server has previously rejected something not to re-offer 
it,
but I don't recall where I saw this and I might well be wrong. Even 
so

the server should negotiate down (as it did initially) or at minimum
send an alert, not just close.

To OP: If you can try to reproduce with s_client default (which is
TLSv1.2 or less) and again specifying -tls1 (or -no_tls1_2 
-no_tls1_1).

That might narrow it down pretty close.




__
OpenSSL Project 
http://www.openssl.org
User Support Mailing List
openssl-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

openssl s_client: SSL handshake has read 0 bytes and written and no peer certificate available

[Jochen Hayek]

Hi, there! 


lengthy_introduction_that_you_may_skip_without_loss

  My problem started recently with a migration from openSUSE-12.1 to 
openSUSE-12.2. 
  openSUSE-12.2 comes with curl-7.25.0 resp. libcurl/7.25.0, 
  and they in turn use OpenSSL/1.0.1c 

  Until recently this worked for me 
  (and it still does on a different platform with *older* versions of 
everything), 
  but now it breaks: 

  $ curl --verbose --insecure 'https://banking.postbank.de/rai/login' 
  * About to connect() to banking.postbank.de port 443 (#0) 
  *   Trying 62.153.105.15... 
  * connected 
  * Connected to banking.postbank.de (62.153.105.15) port 443 (#0) 
  * successfully set certificate verify locations: 
  *   CAfile: none 
CApath: /etc/ssl/certs/ 
  * SSLv3, TLS handshake, Client hello (1): 
  * Unknown SSL protocol error in connection to banking.postbank.de:443 
  * Closing connection #0 
  curl: (35) Unknown SSL protocol error in connection to 
banking.postbank.de:443 

/lengthy_introduction_that_you_may_skip_without_loss

A web page on curl.haxx.se (http://curl.haxx.se/docs/sslcerts.html) teaches me, 
that I should try this, in order to find out, whether the problem is with 
openssl: 

$ openssl s_client -connect banking.postbank.de:443 

Alright, I did a binary search on the recent releases of openssl: 

  0.9.8x, 1.0.0, 1.0.0j, 1.0.1, 1.0.1c 

The last one, that did not break my request is 1.0.0j, 
the first one, that breaks my request is 1.0.1 .
(I skipped the betas.)

And the problem report looks like this
(SSL handshake has read 0 bytes and written ...): 

$ /usr/local/src/openssl-1.0.1/apps/openssl s_client -connect 
banking.postbank.de:443 
$ openssl s_client -connect banking.postbank.de:443 
WARNING: can't open config file: /usr/local/openssl-1.0.1/openssl.cnf 
CONNECTED(0003) 
write:errno=104 
--- 
no peer certificate available 
--- 
No client certificate CA names sent 
--- 
SSL handshake has read 0 bytes and written 321 bytes 
--- 
New, (NONE), Cipher is (NONE) 
Secure Renegotiation IS NOT supported 
Compression: NONE 
Expansion: NONE 
--- 

Here are the last few lines of make test for 1.0.0j and 1.0.1, 
just in case you want to see them: 

openssl-1.0.0j 

ALL TESTS SUCCESSFUL. 
make[1]: Leaving directory `/usr/local/src/openssl-1.0.0j/test' 
OPENSSL_CONF=apps/openssl.cnf util/opensslwrap.sh version -a 
OpenSSL 1.0.0j 10 May 2012 
built on: Tue Sep 18 14:21:04 CEST 2012 
platform: linux-elf 
options:  bn(64,32) rc4(4x,int) des(ptr,risc1,16,long) idea(int) 
blowfish(idx) 
compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer 
-Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM 
-DWHIRLPOOL_ASM 
OPENSSLDIR: /usr/local/openssl-1.0.0j 

openssl-1.0.1 

ALL TESTS SUCCESSFUL. 
make[1]: Leaving directory `/usr/local/src/openssl-1.0.1/test' 
OPENSSL_CONF=apps/openssl.cnf util/opensslwrap.sh version -a 
OpenSSL 1.0.1 14 Mar 2012 
built on: Tue Sep 18 14:29:57 CEST 2012 
platform: linux-elf 
options:  bn(64,32) rc4(8x,mmx) des(ptr,risc1,16,long) idea(int) 
blowfish(idx) 
compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer 
-Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
-DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM 
OPENSSLDIR: /usr/local/openssl-1.0.1 

Anybody any idea? 

Any specific details I can provide you with?

Is it a bug or a feature? 

A little lost ... 
Jochen


P.S.

I posted this already yesterday through Google Groups as

  
https://groups.google.com/forum/?fromgroups=hl=en#!topic/mailing.openssl.users/1bw48CGd5xQ
 ,

but it looks, as if this doesn't reach the mailing list,
so I post it here again.
I apologise for the redundancy.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: openssl s_client: SSL handshake has read 0 bytes and written and no peer certificate available

[Dr. Stephen Henson]

On Wed, Sep 19, 2012, Jochen Hayek wrote:

 
   Until recently this worked for me 
   (and it still does on a different platform with *older* versions of 
 everything), 
   but now it breaks: 
 
   $ curl --verbose --insecure 'https://banking.postbank.de/rai/login' 
   * About to connect() to banking.postbank.de port 443 (#0) 
   *   Trying 62.153.105.15... 
   * connected 
   * Connected to banking.postbank.de (62.153.105.15) port 443 (#0) 
   * successfully set certificate verify locations: 
   *   CAfile: none 
 CApath: /etc/ssl/certs/ 
   * SSLv3, TLS handshake, Client hello (1): 
   * Unknown SSL protocol error in connection to banking.postbank.de:443 
   * Closing connection #0 
   curl: (35) Unknown SSL protocol error in connection to 
 banking.postbank.de:443 
 

This is a problem with the server. OpenSSL 1.0.1 is the first release to
support TLS version 1.2 and some servers hang when connecting. The option
-no_tls1_2 or -tls1 should allow you to connect again.

This is discussed in PR#2771:

http://rt.openssl.org/Ticket/Display.html?id=2771user=guestpass=guest

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 s_client: SSL handshake has read 0 bytes and written and no peer certificate available

[Jochen Hayek]

 On Wed, 19 Sep 2012 12:39:33 +0200, Dr. Stephen Henson ... said:

 This is a problem with the server. OpenSSL 1.0.1 is the first release to
 support TLS version 1.2 and some servers hang when connecting. The option
 -no_tls1_2 or -tls1 should allow you to connect again.

 This is discussed in PR#2771:

 http://rt.openssl.org/Ticket/Display.html?id=2771user=guestpass=guest

 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core developer.

Your valuable advice solved my problem.
***Thanks*** a lot!

I would love to be able to sponsor you and the OpenSSL project, but right now I 
am not.
If thinks work out well, I will come back to this idea.

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

RE: Memory issues with ssl handshake

[Charles Mills]

Try plugging your code to exit after the first OpenSSL function, then after
the second, and so forth, and see if you can get down to the simplest case.

Charles

-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Thomas
Sent: Monday, September 17, 2012 11:36 AM
To: Michel
Cc: openssl-users@openssl.org
Subject: Re: Memory issues with ssl handshake

Hi again,

I've changed the code to reuse the SSL contexts but in terms of memory
consumption/release it did not change much - if anything at all. By the way,
is there a way to unload a certificate once it has been loaded into a SSL
context via SSL_CTX_use_certificate() ? I didn't find anything in the docs
and simply specifying NULL as cert parameter caused a crash in OpenSSL.

The only places left that cause memory leaks are reported inside OpenSSL as
in

at 0x68EAC8B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==27041==by 0x6C472DB: default_malloc_ex (mem.c:79)
==27041==by 0x6C4795F: CRYPTO_malloc (mem.c:306)
==27041==by 0x6C73940: bn_expand_internal (bn_lib.c:336)
==27041==by 0x6C73AE0: bn_expand2 (bn_lib.c:451)
==27041==by 0x6C73BB2: BN_set_bit (bn_lib.c:730)
==27041==by 0x6C7E16E: BN_MONT_CTX_set (bn_mont.c:514)
==27041==by 0x6C7E402: BN_MONT_CTX_set_locked (bn_mont.c:552)
==27041==by 0x6C95B56: RSA_eay_mod_exp (rsa_eay.c:782)
==27041==by 0x6C96422: RSA_eay_private_decrypt (rsa_eay.c:565)
==27041==by 0x6C97EDF: RSA_private_decrypt (rsa_lib.c:303)
==27041==by 0x6942918: ssl3_get_client_key_exchange (s3_srvr.c:2038)
==27041==by 0x6946693: ssl3_accept (s3_srvr.c:529)
==27041==by 0x69513CA: ssl3_read_bytes (s3_pkt.c:941)
==27041==by 0x694C688: ssl3_read_internal (s3_lib.c:3274)
==27041==by 0x69642E8: SSL_read (ssl_lib.c:954)

Sometimes these are flagged still reachable and sometimes indirectly
lost, usually both types are reported as I get a large amount of these
traces. One thing I noticed is that all goes well if I cause the code to run
sequentially (e.g. cause requests to come one ater another). Yet it starts
eating up memory like crazy if I cause several (HTTPS) requests to come at
once.

I'm at a loss here. Valgrind insists the leaks happen in OpenSSL code. 
I'll be happy to supply more information if anyone has an idea of how to
approach this.

Regards,
  Thomas

On 09/13/2012 12:30 PM, Michel wrote:
 Hi again Thomas,

 Do you really need to free your context each time you free your TLS 
 session ?
 I believe it is not needed and at least not usual.
 If you need several *DIFFERENT* contexts, implying different TLS 
 configurations/setup, wich, I think, is not so common, you can keep 
 them 'alive' during all your app 'run', even in multi-threaded 
 programs.
 It would allow you to access some activity informations like the ones 
 documented in :
 http://www.openssl.org/docs/ssl/SSL_CTX_sess_number.html

 Hope this helps,
 Regards

 Le 13/09/2012 10:39, Thomas a écrit :
 Hi Michel,

 Thanks for trying to help, I really appreciate it :-)

 Does your app setup and free a context each time a client is 
 connecting ?

 The context is created only when a client requests a HTTPS connection 
 and is destroyed together with the SSL session once the connection 
 goes down. It is rather related to connections then to clients since 
 one client can open several connections but I think you implied one 
 connection per client and then the answer is 'yes'.

 I will try freeing the session before the context and come back with 
 the results.

 Regards,
  Thomas


__
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: Memory issues with ssl handshake

[Thomas]

Hi again,

I've changed the code to reuse the SSL contexts but in terms of memory 
consumption/release it did not change much - if anything at all. By the 
way, is there a way to unload a certificate once it has been loaded 
into a SSL context via SSL_CTX_use_certificate() ? I didn't find 
anything in the docs and simply specifying NULL as cert parameter caused 
a crash in OpenSSL.


The only places left that cause memory leaks are reported inside OpenSSL 
as in


at 0x68EAC8B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==27041==by 0x6C472DB: default_malloc_ex (mem.c:79)
==27041==by 0x6C4795F: CRYPTO_malloc (mem.c:306)
==27041==by 0x6C73940: bn_expand_internal (bn_lib.c:336)
==27041==by 0x6C73AE0: bn_expand2 (bn_lib.c:451)
==27041==by 0x6C73BB2: BN_set_bit (bn_lib.c:730)
==27041==by 0x6C7E16E: BN_MONT_CTX_set (bn_mont.c:514)
==27041==by 0x6C7E402: BN_MONT_CTX_set_locked (bn_mont.c:552)
==27041==by 0x6C95B56: RSA_eay_mod_exp (rsa_eay.c:782)
==27041==by 0x6C96422: RSA_eay_private_decrypt (rsa_eay.c:565)
==27041==by 0x6C97EDF: RSA_private_decrypt (rsa_lib.c:303)
==27041==by 0x6942918: ssl3_get_client_key_exchange (s3_srvr.c:2038)
==27041==by 0x6946693: ssl3_accept (s3_srvr.c:529)
==27041==by 0x69513CA: ssl3_read_bytes (s3_pkt.c:941)
==27041==by 0x694C688: ssl3_read_internal (s3_lib.c:3274)
==27041==by 0x69642E8: SSL_read (ssl_lib.c:954)

Sometimes these are flagged still reachable and sometimes indirectly 
lost, usually both types are reported as I get a large amount of these 
traces. One thing I noticed is that all goes well if I cause the code to 
run sequentially (e.g. cause requests to come one ater another). Yet it 
starts eating up memory like crazy if I cause several (HTTPS) requests 
to come at once.


I'm at a loss here. Valgrind insists the leaks happen in OpenSSL code. 
I'll be happy to supply more information if anyone has an idea of how to 
approach this.


Regards,
 Thomas

On 09/13/2012 12:30 PM, Michel wrote:

Hi again Thomas,

Do you really need to free your context each time you free your TLS 
session ?

I believe it is not needed and at least not usual.
If you need several *DIFFERENT* contexts, implying different TLS 
configurations/setup, wich, I think, is not so common,
you can keep them 'alive' during all your app 'run', even in 
multi-threaded programs.
It would allow you to access some activity informations like the ones 
documented in :

http://www.openssl.org/docs/ssl/SSL_CTX_sess_number.html

Hope this helps,
Regards

Le 13/09/2012 10:39, Thomas a écrit :

Hi Michel,

Thanks for trying to help, I really appreciate it :-)

Does your app setup and free a context each time a client is 
connecting ?


The context is created only when a client requests a HTTPS connection 
and is destroyed together with the SSL session once the connection 
goes down. It is rather related to connections then to clients since 
one client can open several connections but I think you implied one 
connection per client and then the answer is 'yes'.


I will try freeing the session before the context and come back with 
the results.


Regards,
 Thomas




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

Re: Memory issues with ssl handshake

[Michel]

Hi Thomas,

I don't know if it makes a real difference concerning memory leaks,
but I would have freed the TLS session *BEFORE* freing the context :
   SSL_free(ssl);
   ...
   SSL_CTX_free(ssl-ctx);
Does your app setup and free a context each time a client is connecting ?

Le 12/09/2012 16:58, Thomas Eckert a écrit :

Hi,

Valgrind gives me a *lot* of messages like this

==19021== 2,056 bytes in 2 blocks are indirectly lost in loss record 
186 of 190
==19021==at 0x68EAC8B: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)

==19021==by 0x6C472DB: default_malloc_ex (mem.c:79)
==19021==by 0x6C4795F: CRYPTO_malloc (mem.c:306)
==19021==by 0x6C73940: bn_expand_internal (bn_lib.c:336)
==19021==by 0x6C73AE0: bn_expand2 (bn_lib.c:451)
==19021==by 0x6C73BB2: BN_set_bit (bn_lib.c:730)
==19021==by 0x6C7E16E: BN_MONT_CTX_set (bn_mont.c:514)
==19021==by 0x6C7E402: BN_MONT_CTX_set_locked (bn_mont.c:552)
==19021==by 0x6C97053: RSA_eay_public_decrypt (rsa_eay.c:693)
==19021==by 0x6C97F1F: RSA_public_decrypt (rsa_lib.c:309)
==19021==by 0x6C98BEB: int_rsa_verify (rsa_sign.c:182)
==19021==by 0x6C98F57: RSA_verify (rsa_sign.c:284)
==19021==by 0x6949E16: ssl3_get_key_exchange (s3_clnt.c:1562)
==19021==by 0x694BF5F: ssl3_connect (s3_clnt.c:335)
==19021==by 0x6964AB9: SSL_connect (ssl_lib.c:933)
==19021==by 0x6953FDD: ssl23_connect (s23_clnt.c:693)
==19021==by 0x6963FBC: SSL_do_handshake (ssl_lib.c:2368)
==19021==by 0x8060D14: ssl_connect (ssl.c:1078)

Compared to the above they vary only in one line, e.g.

==19021== 1,024 bytes in 2 blocks are indirectly lost in loss record 
181 of 190
==19021==at 0x68EAC8B: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)

==19021==by 0x6C472DB: default_malloc_ex (mem.c:79)
==19021==by 0x6C4795F: CRYPTO_malloc (mem.c:306)
==19021==by 0x6C73940: bn_expand_internal (bn_lib.c:336)
==19021==by 0x6C73AE0: bn_expand2 (bn_lib.c:451)
==19021==by 0x6C73D53: BN_copy (bn_lib.c:506)
==19021==by 0x6C7DFCA: BN_MONT_CTX_set (bn_mont.c:421)
==19021==by 0x6C7E402: BN_MONT_CTX_set_locked (bn_mont.c:552)
==19021==by 0x6C97053: RSA_eay_public_decrypt (rsa_eay.c:693)
==19021==by 0x6C97F1F: RSA_public_decrypt (rsa_lib.c:309)
==19021==by 0x6C98BEB: int_rsa_verify (rsa_sign.c:182)
==19021==by 0x6C98F57: RSA_verify (rsa_sign.c:284)
==19021==by 0x6949E16: ssl3_get_key_exchange (s3_clnt.c:1562)
==19021==by 0x694BF5F: ssl3_connect (s3_clnt.c:335)
==19021==by 0x6964AB9: SSL_connect (ssl_lib.c:933)
==19021==by 0x6953FDD: ssl23_connect (s23_clnt.c:693)
==19021==by 0x6963FBC: SSL_do_handshake (ssl_lib.c:2368)
==19021==by 0x8060D14: ssl_connect (ssl.c:1078)

The application in question is a http proxy and is leaking memory 
heavily. Actually, Valgrind also reports many entries as still 
reachable instead of indirectly lost but even those regions are 
mentioned by Valgrind like the above two blocks.


I doubt OpenSSL has such blatant memory leaks but I have been 
searching for the leaks for some time now and just cannot find 
anything - also due to the fact that Valgrind reports all the leaks 
like above, which is not really helpful. I do realize that for 
detailed help I would need to give some code on how the connections 
are set up but that code is pretty large. So best would be some hint 
as to where to look for or what regions of code to supply.


Looking for hints as to what is going wrong I went through some of the 
OpenSSL functions mentioned above and after leaving my code and 
entering OpenSSL code the only thing being passed around the functions 
is the actual SSL object - and no buffers of any kind. So I suppose 
the source of the problem lies in setting up the object, it's context 
or what ever is stuck to it.


The first thing I checked on was how the SSL connections are torn down 
in my application:

   ERR_remove_state(0);
   SSL_CTX_free(ssl-ctx);
   SSL_free(ssl);
The first line was added only after starting the search for the leaks 
and I'm still not sure if that line doesn't break anything.


I did find some minor leaks in my code along the way (e.g. a forgotten 
ASN1_INTEGER_free()) but they were neither easy to find - because 
Valgrind also reported them like the above two blocks, meaning in the 
wrong place! - nor did they change much.


Does anyone have some tips for me ?
__
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-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: Memory issues with ssl handshake

[Michel]

Hi again Thomas,

Do you really need to free your context each time you free your TLS 
session ?

I believe it is not needed and at least not usual.
If you need several *DIFFERENT* contexts, implying different TLS 
configurations/setup, wich, I think, is not so common,
you can keep them 'alive' during all your app 'run', even in 
multi-threaded programs.
It would allow you to access some activity informations like the ones 
documented in :

http://www.openssl.org/docs/ssl/SSL_CTX_sess_number.html

Hope this helps,
Regards

Le 13/09/2012 10:39, Thomas a écrit :

Hi Michel,

Thanks for trying to help, I really appreciate it :-)

Does your app setup and free a context each time a client is 
connecting ?


The context is created only when a client requests a HTTPS connection 
and is destroyed together with the SSL session once the connection 
goes down. It is rather related to connections then to clients since 
one client can open several connections but I think you implied one 
connection per client and then the answer is 'yes'.


I will try freeing the session before the context and come back with 
the results.


Regards,
 Thomas



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

Re: Memory issues with ssl handshake

[Thomas]

Hi Michel,

Thanks for trying to help, I really appreciate it :-)

Does your app setup and free a context each time a client is connecting ?

The context is created only when a client requests a HTTPS connection 
and is destroyed together with the SSL session once the connection goes 
down. It is rather related to connections then to clients since one 
client can open several connections but I think you implied one 
connection per client and then the answer is 'yes'.


I will try freeing the session before the context and come back with the 
results.


Regards,
 Thomas


On 09/13/2012 10:09 AM, Michel wrote:

Hi Thomas,

I don't know if it makes a real difference concerning memory leaks,
but I would have freed the TLS session *BEFORE* freing the context :
   SSL_free(ssl);
   ...
   SSL_CTX_free(ssl-ctx);
Does your app setup and free a context each time a client is connecting ?

Le 12/09/2012 16:58, Thomas a écrit :

Hi,

Valgrind gives me a *lot* of messages like this

==19021== 2,056 bytes in 2 blocks are indirectly lost in loss record 
186 of 190
==19021==at 0x68EAC8B: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)

==19021==by 0x6C472DB: default_malloc_ex (mem.c:79)
==19021==by 0x6C4795F: CRYPTO_malloc (mem.c:306)
==19021==by 0x6C73940: bn_expand_internal (bn_lib.c:336)
==19021==by 0x6C73AE0: bn_expand2 (bn_lib.c:451)
==19021==by 0x6C73BB2: BN_set_bit (bn_lib.c:730)
==19021==by 0x6C7E16E: BN_MONT_CTX_set (bn_mont.c:514)
==19021==by 0x6C7E402: BN_MONT_CTX_set_locked (bn_mont.c:552)
==19021==by 0x6C97053: RSA_eay_public_decrypt (rsa_eay.c:693)
==19021==by 0x6C97F1F: RSA_public_decrypt (rsa_lib.c:309)
==19021==by 0x6C98BEB: int_rsa_verify (rsa_sign.c:182)
==19021==by 0x6C98F57: RSA_verify (rsa_sign.c:284)
==19021==by 0x6949E16: ssl3_get_key_exchange (s3_clnt.c:1562)
==19021==by 0x694BF5F: ssl3_connect (s3_clnt.c:335)
==19021==by 0x6964AB9: SSL_connect (ssl_lib.c:933)
==19021==by 0x6953FDD: ssl23_connect (s23_clnt.c:693)
==19021==by 0x6963FBC: SSL_do_handshake (ssl_lib.c:2368)
==19021==by 0x8060D14: ssl_connect (ssl.c:1078)

Compared to the above they vary only in one line, e.g.

==19021== 1,024 bytes in 2 blocks are indirectly lost in loss record 
181 of 190
==19021==at 0x68EAC8B: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)

==19021==by 0x6C472DB: default_malloc_ex (mem.c:79)
==19021==by 0x6C4795F: CRYPTO_malloc (mem.c:306)
==19021==by 0x6C73940: bn_expand_internal (bn_lib.c:336)
==19021==by 0x6C73AE0: bn_expand2 (bn_lib.c:451)
==19021==by 0x6C73D53: BN_copy (bn_lib.c:506)
==19021==by 0x6C7DFCA: BN_MONT_CTX_set (bn_mont.c:421)
==19021==by 0x6C7E402: BN_MONT_CTX_set_locked (bn_mont.c:552)
==19021==by 0x6C97053: RSA_eay_public_decrypt (rsa_eay.c:693)
==19021==by 0x6C97F1F: RSA_public_decrypt (rsa_lib.c:309)
==19021==by 0x6C98BEB: int_rsa_verify (rsa_sign.c:182)
==19021==by 0x6C98F57: RSA_verify (rsa_sign.c:284)
==19021==by 0x6949E16: ssl3_get_key_exchange (s3_clnt.c:1562)
==19021==by 0x694BF5F: ssl3_connect (s3_clnt.c:335)
==19021==by 0x6964AB9: SSL_connect (ssl_lib.c:933)
==19021==by 0x6953FDD: ssl23_connect (s23_clnt.c:693)
==19021==by 0x6963FBC: SSL_do_handshake (ssl_lib.c:2368)
==19021==by 0x8060D14: ssl_connect (ssl.c:1078)

The application in question is a http proxy and is leaking memory 
heavily. Actually, Valgrind also reports many entries as still 
reachable instead of indirectly lost but even those regions are 
mentioned by Valgrind like the above two blocks.


I doubt OpenSSL has such blatant memory leaks but I have been 
searching for the leaks for some time now and just cannot find 
anything - also due to the fact that Valgrind reports all the leaks 
like above, which is not really helpful. I do realize that for 
detailed help I would need to give some code on how the connections 
are set up but that code is pretty large. So best would be some hint 
as to where to look for or what regions of code to supply.


Looking for hints as to what is going wrong I went through some of 
the OpenSSL functions mentioned above and after leaving my code and 
entering OpenSSL code the only thing being passed around the 
functions is the actual SSL object - and no buffers of any kind. So I 
suppose the source of the problem lies in setting up the object, it's 
context or what ever is stuck to it.


The first thing I checked on was how the SSL connections are torn 
down in my application:

   ERR_remove_state(0);
   SSL_CTX_free(ssl-ctx);
   SSL_free(ssl);
The first line was added only after starting the search for the leaks 
and I'm still not sure if that line doesn't break anything.


I did find some minor leaks in my code along the way (e.g. a 
forgotten ASN1_INTEGER_free()) but they were neither easy to find - 
because Valgrind also reported them like the above two blocks, 
meaning in the wrong place! - nor did they change much.

Re: Memory issues with ssl handshake

[Dominik Oepen]

On 12.09.2012 16:58, Thomas Eckert wrote:
 Hi,
 
 Valgrind gives me a *lot* of messages like this
[snip]
 Does anyone have some tips for me ?

Have you seen the FAQ entry regarding valgrind:
http://www.openssl.org/support/faq.html#PROG14 ?

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

Re: HTTPS connection hangs during SSL handshake

[Aleksandr Konstantinov]

On Tuesday 11 September 2012, Supratik Goswami wrote:
 Is there no one in the community who can help me to find the cause of
 the problem ?

Maybe You have firewall issues on office IP macine. Have You tried tcpdump or 
similar utility to check if there is something being sent/received?

Regards,

A.K.


 
 On Tue, Sep 4, 2012 at 7:21 PM, Supratik Goswami
 supratiksek...@gmail.com wrote:
  I am using OpenSSL version : openssl-1.0.0j in our production.
 
  I am facing a strange problem where the SSL connection simply hangs
  during initial handshake when requested from our office IP address.
  When I run the same command from another IP address it works fine.
 
  From office IP (Unsuccessful connection):
 
  [root@gateway ]# openssl s_client -connect test.mydomain.com:443
  CONNECTED(0003)
 
 
  From a different IP (Successful connection):
 
  ubuntu@ip-10-0-0-10 (Development):~$ openssl s_client -connect
  test.mydomain.com:443
  CONNECTED(0003)
  depth=3 /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert
  Class 2 Policy Validation
  Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
  verify error:num=19:self signed certificate in certificate chain
  verify return:0
  ---
  Certificate chain
   0 s:/O=*.mydomain.com/OU=Domain Control Validated/CN=*.mydomain.com
 i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
  Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
  Certification Authority/serialNumber=07969287
   1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
  Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
  Certification Authority/serialNumber=07969287
 i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2
  Certification Authority
   2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2
  Certification Authority
 i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class
  2 Policy Validation
  Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
   3 s:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class
  2 Policy Validation
  Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
 i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class
  2 Policy Validation
  Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
  ---
  Server certificate
  -BEGIN CERTIFICATE-
 
  REMOVED FOR SECURITY REASON
 
  -END CERTIFICATE-
  subject=/O=*.mydomain.com/OU=Domain Control Validated/CN=*.mydomain.com
  issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
  Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
  Certification Authority/serialNumber=07969287
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 4827 bytes and written 435 bytes
  ---
  New, TLSv1/SSLv3, Cipher is RC4-SHA
  Server public key is 2048 bit
  Secure Renegotiation IS supported
  Compression: NONE
  Expansion: NONE
  SSL-Session:
  Protocol  : TLSv1
  Cipher: RC4-SHA
  Session-ID: 
  276ADBFB75336E7E870C5E109B4C5F6AFB8328C8775029EF135C5DA6F8608533
  Session-ID-ctx:
  Master-Key:
  22B470A67XXXB50ED6237BE9
  Key-Arg   : None
  Start Time: 1346765613
  Timeout   : 300 (sec)
  Verify return code: 19 (self signed certificate in certificate chain
 
 
 
  Any ideas ?
 
 
  --
  Warm Regards
 
  Supratik
 
 
 
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: HTTPS connection hangs during SSL handshake

[Supratik Goswami]

It is not a firewall issue, I checked this from outside firewall. The
strange part of the problem is
it does not happen always, it works intermittently.

[root@gateway bin]# openssl s_client -bugs -connect
test.mydomain.com:443 -msg -state
CONNECTED(0003)
SSL_connect:before/connect initialization
 SSL 2.0 [length 0067], CLIENT-HELLO
01 03 01 00 4e 00 00 00 10 00 00 39 00 00 38 00
00 35 00 00 16 00 00 13 00 00 0a 07 00 c0 00 00
33 00 00 32 00 00 2f 03 00 80 00 00 05 00 00 04
01 00 80 00 00 15 00 00 12 00 00 09 06 00 40 00
00 14 00 00 11 00 00 08 00 00 06 04 00 80 00 00
03 02 00 80 00 00 ff c6 89 a6 e3 3e 51 4c 4b d9
e2 c4 29 01 63 54 06
SSL_connect:SSLv2/v3 write client hello A


It simply hangs after this.

* Here test.mydomain.com is not real it is used for posting.

On Tue, Sep 11, 2012 at 7:02 PM, Aleksandr Konstantinov
aleksandr.konstanti...@fys.uio.no wrote:
 On Tuesday 11 September 2012, Supratik Goswami wrote:
 Is there no one in the community who can help me to find the cause of
 the problem ?

 Maybe You have firewall issues on office IP macine. Have You tried tcpdump 
 or
 similar utility to check if there is something being sent/received?

 Regards,

 A.K.



 On Tue, Sep 4, 2012 at 7:21 PM, Supratik Goswami
 supratiksek...@gmail.com wrote:
  I am using OpenSSL version : openssl-1.0.0j in our production.
 
  I am facing a strange problem where the SSL connection simply hangs
  during initial handshake when requested from our office IP address.
  When I run the same command from another IP address it works fine.
 
  From office IP (Unsuccessful connection):
 
  [root@gateway ]# openssl s_client -connect test.mydomain.com:443
  CONNECTED(0003)
 
 
  From a different IP (Successful connection):
 
  ubuntu@ip-10-0-0-10 (Development):~$ openssl s_client -connect
  test.mydomain.com:443
  CONNECTED(0003)
  depth=3 /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert
  Class 2 Policy Validation
  Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
  verify error:num=19:self signed certificate in certificate chain
  verify return:0
  ---
  Certificate chain
   0 s:/O=*.mydomain.com/OU=Domain Control Validated/CN=*.mydomain.com
 i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
  Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
  Certification Authority/serialNumber=07969287
   1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
  Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
  Certification Authority/serialNumber=07969287
 i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2
  Certification Authority
   2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2
  Certification Authority
 i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class
  2 Policy Validation
  Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
   3 s:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class
  2 Policy Validation
  Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
 i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class
  2 Policy Validation
  Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
  ---
  Server certificate
  -BEGIN CERTIFICATE-
 
  REMOVED FOR SECURITY REASON
 
  -END CERTIFICATE-
  subject=/O=*.mydomain.com/OU=Domain Control Validated/CN=*.mydomain.com
  issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
  Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
  Certification Authority/serialNumber=07969287
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 4827 bytes and written 435 bytes
  ---
  New, TLSv1/SSLv3, Cipher is RC4-SHA
  Server public key is 2048 bit
  Secure Renegotiation IS supported
  Compression: NONE
  Expansion: NONE
  SSL-Session:
  Protocol  : TLSv1
  Cipher: RC4-SHA
  Session-ID: 
  276ADBFB75336E7E870C5E109B4C5F6AFB8328C8775029EF135C5DA6F8608533
  Session-ID-ctx:
  Master-Key:
  22B470A67XXXB50ED6237BE9
  Key-Arg   : None
  Start Time: 1346765613
  Timeout   : 300 (sec)
  Verify return code: 19 (self signed certificate in certificate chain
 
 
 
  Any ideas ?
 
 
  --
  Warm Regards
 
  Supratik



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



-- 
Warm Regards

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

Memory issues with ssl handshake

[Thomas Eckert]

Hi,

Valgrind gives me a *lot* of messages like this

==19021== 2,056 bytes in 2 blocks are indirectly lost in loss record 186 
of 190
==19021==at 0x68EAC8B: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)

==19021==by 0x6C472DB: default_malloc_ex (mem.c:79)
==19021==by 0x6C4795F: CRYPTO_malloc (mem.c:306)
==19021==by 0x6C73940: bn_expand_internal (bn_lib.c:336)
==19021==by 0x6C73AE0: bn_expand2 (bn_lib.c:451)
==19021==by 0x6C73BB2: BN_set_bit (bn_lib.c:730)
==19021==by 0x6C7E16E: BN_MONT_CTX_set (bn_mont.c:514)
==19021==by 0x6C7E402: BN_MONT_CTX_set_locked (bn_mont.c:552)
==19021==by 0x6C97053: RSA_eay_public_decrypt (rsa_eay.c:693)
==19021==by 0x6C97F1F: RSA_public_decrypt (rsa_lib.c:309)
==19021==by 0x6C98BEB: int_rsa_verify (rsa_sign.c:182)
==19021==by 0x6C98F57: RSA_verify (rsa_sign.c:284)
==19021==by 0x6949E16: ssl3_get_key_exchange (s3_clnt.c:1562)
==19021==by 0x694BF5F: ssl3_connect (s3_clnt.c:335)
==19021==by 0x6964AB9: SSL_connect (ssl_lib.c:933)
==19021==by 0x6953FDD: ssl23_connect (s23_clnt.c:693)
==19021==by 0x6963FBC: SSL_do_handshake (ssl_lib.c:2368)
==19021==by 0x8060D14: ssl_connect (ssl.c:1078)

Compared to the above they vary only in one line, e.g.

==19021== 1,024 bytes in 2 blocks are indirectly lost in loss record 181 
of 190
==19021==at 0x68EAC8B: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)

==19021==by 0x6C472DB: default_malloc_ex (mem.c:79)
==19021==by 0x6C4795F: CRYPTO_malloc (mem.c:306)
==19021==by 0x6C73940: bn_expand_internal (bn_lib.c:336)
==19021==by 0x6C73AE0: bn_expand2 (bn_lib.c:451)
==19021==by 0x6C73D53: BN_copy (bn_lib.c:506)
==19021==by 0x6C7DFCA: BN_MONT_CTX_set (bn_mont.c:421)
==19021==by 0x6C7E402: BN_MONT_CTX_set_locked (bn_mont.c:552)
==19021==by 0x6C97053: RSA_eay_public_decrypt (rsa_eay.c:693)
==19021==by 0x6C97F1F: RSA_public_decrypt (rsa_lib.c:309)
==19021==by 0x6C98BEB: int_rsa_verify (rsa_sign.c:182)
==19021==by 0x6C98F57: RSA_verify (rsa_sign.c:284)
==19021==by 0x6949E16: ssl3_get_key_exchange (s3_clnt.c:1562)
==19021==by 0x694BF5F: ssl3_connect (s3_clnt.c:335)
==19021==by 0x6964AB9: SSL_connect (ssl_lib.c:933)
==19021==by 0x6953FDD: ssl23_connect (s23_clnt.c:693)
==19021==by 0x6963FBC: SSL_do_handshake (ssl_lib.c:2368)
==19021==by 0x8060D14: ssl_connect (ssl.c:1078)

The application in question is a http proxy and is leaking memory 
heavily. Actually, Valgrind also reports many entries as still 
reachable instead of indirectly lost but even those regions are 
mentioned by Valgrind like the above two blocks.


I doubt OpenSSL has such blatant memory leaks but I have been searching 
for the leaks for some time now and just cannot find anything - also due 
to the fact that Valgrind reports all the leaks like above, which is not 
really helpful. I do realize that for detailed help I would need to give 
some code on how the connections are set up but that code is pretty 
large. So best would be some hint as to where to look for or what 
regions of code to supply.


Looking for hints as to what is going wrong I went through some of the 
OpenSSL functions mentioned above and after leaving my code and 
entering OpenSSL code the only thing being passed around the functions 
is the actual SSL object - and no buffers of any kind. So I suppose the 
source of the problem lies in setting up the object, it's context or 
what ever is stuck to it.


The first thing I checked on was how the SSL connections are torn down 
in my application:

   ERR_remove_state(0);
   SSL_CTX_free(ssl-ctx);
   SSL_free(ssl);
The first line was added only after starting the search for the leaks 
and I'm still not sure if that line doesn't break anything.


I did find some minor leaks in my code along the way (e.g. a forgotten 
ASN1_INTEGER_free()) but they were neither easy to find - because 
Valgrind also reported them like the above two blocks, meaning in the 
wrong place! - nor did they change much.


Does anyone have some tips for me ?
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Memory issues with ssl handshake

[Charles Mills]

Not sure if it help at all but FWIW I am using Windows pre-built OpenSSL
dll's with server  client certificates, CAs, DH keys, and a CRL, and I am
seeing no memory leaks whatsoever in Visual Studio 2010.

Charles

-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Thomas Eckert
Sent: Wednesday, September 12, 2012 7:59 AM
To: openssl-users@openssl.org
Subject: Memory issues with ssl handshake

Hi,

Valgrind gives me a *lot* of messages like this

==19021== 2,056 bytes in 2 blocks are indirectly lost in loss record 186 of
190
==19021==at 0x68EAC8B: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==19021==by 0x6C472DB: default_malloc_ex (mem.c:79)
==19021==by 0x6C4795F: CRYPTO_malloc (mem.c:306)
==19021==by 0x6C73940: bn_expand_internal (bn_lib.c:336)
==19021==by 0x6C73AE0: bn_expand2 (bn_lib.c:451)
==19021==by 0x6C73BB2: BN_set_bit (bn_lib.c:730)
==19021==by 0x6C7E16E: BN_MONT_CTX_set (bn_mont.c:514)
==19021==by 0x6C7E402: BN_MONT_CTX_set_locked (bn_mont.c:552)
==19021==by 0x6C97053: RSA_eay_public_decrypt (rsa_eay.c:693)
==19021==by 0x6C97F1F: RSA_public_decrypt (rsa_lib.c:309)
==19021==by 0x6C98BEB: int_rsa_verify (rsa_sign.c:182)
==19021==by 0x6C98F57: RSA_verify (rsa_sign.c:284)
==19021==by 0x6949E16: ssl3_get_key_exchange (s3_clnt.c:1562)
==19021==by 0x694BF5F: ssl3_connect (s3_clnt.c:335)
==19021==by 0x6964AB9: SSL_connect (ssl_lib.c:933)
==19021==by 0x6953FDD: ssl23_connect (s23_clnt.c:693)
==19021==by 0x6963FBC: SSL_do_handshake (ssl_lib.c:2368)
==19021==by 0x8060D14: ssl_connect (ssl.c:1078)

Compared to the above they vary only in one line, e.g.

==19021== 1,024 bytes in 2 blocks are indirectly lost in loss record 181 of
190
==19021==at 0x68EAC8B: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==19021==by 0x6C472DB: default_malloc_ex (mem.c:79)
==19021==by 0x6C4795F: CRYPTO_malloc (mem.c:306)
==19021==by 0x6C73940: bn_expand_internal (bn_lib.c:336)
==19021==by 0x6C73AE0: bn_expand2 (bn_lib.c:451)
==19021==by 0x6C73D53: BN_copy (bn_lib.c:506)
==19021==by 0x6C7DFCA: BN_MONT_CTX_set (bn_mont.c:421)
==19021==by 0x6C7E402: BN_MONT_CTX_set_locked (bn_mont.c:552)
==19021==by 0x6C97053: RSA_eay_public_decrypt (rsa_eay.c:693)
==19021==by 0x6C97F1F: RSA_public_decrypt (rsa_lib.c:309)
==19021==by 0x6C98BEB: int_rsa_verify (rsa_sign.c:182)
==19021==by 0x6C98F57: RSA_verify (rsa_sign.c:284)
==19021==by 0x6949E16: ssl3_get_key_exchange (s3_clnt.c:1562)
==19021==by 0x694BF5F: ssl3_connect (s3_clnt.c:335)
==19021==by 0x6964AB9: SSL_connect (ssl_lib.c:933)
==19021==by 0x6953FDD: ssl23_connect (s23_clnt.c:693)
==19021==by 0x6963FBC: SSL_do_handshake (ssl_lib.c:2368)
==19021==by 0x8060D14: ssl_connect (ssl.c:1078)

The application in question is a http proxy and is leaking memory heavily.
Actually, Valgrind also reports many entries as still reachable instead of
indirectly lost but even those regions are mentioned by Valgrind like the
above two blocks.

I doubt OpenSSL has such blatant memory leaks but I have been searching for
the leaks for some time now and just cannot find anything - also due to the
fact that Valgrind reports all the leaks like above, which is not really
helpful. I do realize that for detailed help I would need to give some code
on how the connections are set up but that code is pretty large. So best
would be some hint as to where to look for or what regions of code to
supply.

Looking for hints as to what is going wrong I went through some of the
OpenSSL functions mentioned above and after leaving my code and entering
OpenSSL code the only thing being passed around the functions is the actual
SSL object - and no buffers of any kind. So I suppose the source of the
problem lies in setting up the object, it's context or what ever is stuck to
it.

The first thing I checked on was how the SSL connections are torn down in my
application:
ERR_remove_state(0);
SSL_CTX_free(ssl-ctx);
SSL_free(ssl);
The first line was added only after starting the search for the leaks and
I'm still not sure if that line doesn't break anything.

I did find some minor leaks in my code along the way (e.g. a forgotten
ASN1_INTEGER_free()) but they were neither easy to find - because Valgrind
also reported them like the above two blocks, meaning in the wrong place! -
nor did they change much.

Does anyone have some tips for me ?

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

Re: HTTPS connection hangs during SSL handshake

[Supratik Goswami]

Is there no one in the community who can help me to find the cause of
the problem ?

On Tue, Sep 4, 2012 at 7:21 PM, Supratik Goswami
supratiksek...@gmail.com wrote:
 I am using OpenSSL version : openssl-1.0.0j in our production.

 I am facing a strange problem where the SSL connection simply hangs
 during initial handshake when requested from our office IP address.
 When I run the same command from another IP address it works fine.

 From office IP (Unsuccessful connection):

 [root@gateway ]# openssl s_client -connect test.mydomain.com:443
 CONNECTED(0003)


 From a different IP (Successful connection):

 ubuntu@ip-10-0-0-10 (Development):~$ openssl s_client -connect
 test.mydomain.com:443
 CONNECTED(0003)
 depth=3 /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert
 Class 2 Policy Validation
 Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
 verify error:num=19:self signed certificate in certificate chain
 verify return:0
 ---
 Certificate chain
  0 s:/O=*.mydomain.com/OU=Domain Control Validated/CN=*.mydomain.com
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
 Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
 Certification Authority/serialNumber=07969287
  1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
 Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
 Certification Authority/serialNumber=07969287
i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2
 Certification Authority
  2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2
 Certification Authority
i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class
 2 Policy Validation
 Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
  3 s:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class
 2 Policy Validation
 Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class
 2 Policy Validation
 Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
 ---
 Server certificate
 -BEGIN CERTIFICATE-

 REMOVED FOR SECURITY REASON

 -END CERTIFICATE-
 subject=/O=*.mydomain.com/OU=Domain Control Validated/CN=*.mydomain.com
 issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
 Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
 Certification Authority/serialNumber=07969287
 ---
 No client certificate CA names sent
 ---
 SSL handshake has read 4827 bytes and written 435 bytes
 ---
 New, TLSv1/SSLv3, Cipher is RC4-SHA
 Server public key is 2048 bit
 Secure Renegotiation IS supported
 Compression: NONE
 Expansion: NONE
 SSL-Session:
 Protocol  : TLSv1
 Cipher: RC4-SHA
 Session-ID: 
 276ADBFB75336E7E870C5E109B4C5F6AFB8328C8775029EF135C5DA6F8608533
 Session-ID-ctx:
 Master-Key:
 22B470A67XXXB50ED6237BE9
 Key-Arg   : None
 Start Time: 1346765613
 Timeout   : 300 (sec)
 Verify return code: 19 (self signed certificate in certificate chain



 Any ideas ?


 --
 Warm Regards

 Supratik



-- 
Warm Regards

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

RES: HTTPS connection hangs during SSL handshake

[Leonardo Laface de Almeida]

For any SSL connection, you have to assure that:

1- The cpu's can reach each other (the hostname test.mydomain.com must be 
also resolved). You may use ping, HTTP, FTP to check it out;
2- Certificates or CA chain from each endpoint must be inserted in the opposite 
side as trust cert; 
3- The both sides must have at least one cipher in common;
4- No NAT or Firewall is filtering the messages.  

I have never made a connection by openssl command line, so, I can't tell you 
how to check it out . 

I advice you to use some sniffer in at least one side, then you can reach the 
error, eg. where handshake is failuring, get the error code, etc... Using this 
you might be able to solve your problemm.

As I saw your logs, perhaps one side doesn't trust in the opposite cert 
received. That may happen for many reasons. I've already got some cases that 
the hostname (in your case test.mydomain.com) must match with certificate 
common name (CN).

I hope it helps.
Leonardo


-Mensagem original-
De: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] Em 
nome de Supratik Goswami
Enviada em: terça-feira, 11 de setembro de 2012 10:15
Para: openssl-users@openssl.org
Assunto: Re: HTTPS connection hangs during SSL handshake

Is there no one in the community who can help me to find the cause of
the problem ?

On Tue, Sep 4, 2012 at 7:21 PM, Supratik Goswami
supratiksek...@gmail.com wrote:
 I am using OpenSSL version : openssl-1.0.0j in our production.

 I am facing a strange problem where the SSL connection simply hangs
 during initial handshake when requested from our office IP address.
 When I run the same command from another IP address it works fine.

 From office IP (Unsuccessful connection):

 [root@gateway ]# openssl s_client -connect test.mydomain.com:443
 CONNECTED(0003)


 From a different IP (Successful connection):

 ubuntu@ip-10-0-0-10 (Development):~$ openssl s_client -connect
 test.mydomain.com:443
 CONNECTED(0003)
 depth=3 /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert
 Class 2 Policy Validation
 Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
 verify error:num=19:self signed certificate in certificate chain
 verify return:0
 ---
 Certificate chain
  0 s:/O=*.mydomain.com/OU=Domain Control Validated/CN=*.mydomain.com
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
 Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
 Certification Authority/serialNumber=07969287
  1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
 Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
 Certification Authority/serialNumber=07969287
i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2
 Certification Authority
  2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2
 Certification Authority
i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class
 2 Policy Validation
 Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
  3 s:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class
 2 Policy Validation
 Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class
 2 Policy Validation
 Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
 ---
 Server certificate
 -BEGIN CERTIFICATE-

 REMOVED FOR SECURITY REASON

 -END CERTIFICATE-
 subject=/O=*.mydomain.com/OU=Domain Control Validated/CN=*.mydomain.com
 issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
 Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
 Certification Authority/serialNumber=07969287
 ---
 No client certificate CA names sent
 ---
 SSL handshake has read 4827 bytes and written 435 bytes
 ---
 New, TLSv1/SSLv3, Cipher is RC4-SHA
 Server public key is 2048 bit
 Secure Renegotiation IS supported
 Compression: NONE
 Expansion: NONE
 SSL-Session:
 Protocol  : TLSv1
 Cipher: RC4-SHA
 Session-ID: 
 276ADBFB75336E7E870C5E109B4C5F6AFB8328C8775029EF135C5DA6F8608533
 Session-ID-ctx:
 Master-Key:
 22B470A67XXXB50ED6237BE9
 Key-Arg   : None
 Start Time: 1346765613
 Timeout   : 300 (sec)
 Verify return code: 19 (self signed certificate in certificate chain



 Any ideas ?


 --
 Warm Regards

 Supratik



-- 
Warm Regards

Supratik
__
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: HTTPS connection hangs during SSL handshake

[Dave Thompson]

 From: owner-openssl-us...@openssl.org On Behalf Of Leonardo Laface de
Almeida
 Sent: Tuesday, 11 September, 2012 10:08
 To: openssl-users@openssl.org

 For any SSL connection, you have to assure that:
 
 1- The cpu's can reach each other (the hostname 
 test.mydomain.com must be also resolved). You may use ping, 
 HTTP, FTP to check it out;

More exactly, the TCP stacks must be able to connect.
That requires slightly more than IP reachability -- 
not much more, but enough to be a problem in rare cases.
But CONNECTED(fd) from s_client means they *did* TCP 
connect, so that's not the problem here.

 2- Certificates or CA chain from each endpoint must be 
 inserted in the opposite side as trust cert; 

A problem here would cause a handshake error not a hang.

 3- The both sides must have at least one cipher in common;

A problem here would cause a handshake error not a hang.

 4- No NAT or Firewall is filtering the messages.  
 
Yes, or possibly other middlebox, see below.

 I have never made a connection by openssl command line, so, I 
 can't tell you how to check it out . 
 
 I advice you to use some sniffer in at least one side, then 
 you can reach the error, eg. where handshake is failuring, 
 get the error code, etc... Using this you might be able to 
 solve your problemm.
 
Maybe both sides, see below.

 As I saw your logs, perhaps one side doesn't trust in the 
 opposite cert received. That may happen for many reasons. 
 I've already got some cases that the hostname (in your case 
 test.mydomain.com) must match with certificate common name (CN).
 
According to the log posted, his host is www.mydomain.com and 
the cert is for *.mydomain.com . That is a valid wildcard match, 
and should be acceptable to any conforming client. But openssl 
library and s_client doesn't do hostname matching at all.
(*Apps* using openssl normally should, and at least some do.)

I don't know if mydomain is supposedly real or munged for posting.
mydomain.com is a real company and test.mydomain.com doesn't 
resolve publicly and the cert chain used for {www.,}mydomain.com 
publicly is wholly different from the OP's log.

OP's s_client fails to verify the received chain because it 
(apparently) doesn't have the ValiCert root in its truststore.
Official openssl does not distribute any default trusted roots,
although custom packages of it may, as may apps using it.
OP probably didn't install a default truststore (or possibly 
is using a build that has the default truststore wrong).

But failure to verify should cause a real app to reject the 
connection, and s_client as a test tool overrides the verify 
error and continues. Neither of these is a hang.

In the other direction, s_client doesn't do client authentication 
and send a client cert unless explicitly specified, which the OP 
didn't. If the server wants client-auth and client doesn't provide 
it or provides a cert (chain) which server doesn't trust, that will 
give a handshake error, not a hang.

 -Mensagem original-
 De: owner-openssl-us...@openssl.org 
 [mailto:owner-openssl-us...@openssl.org] Em nome de Supratik Goswami
 Enviada em: terça-feira, 11 de setembro de 2012 10:15
 Para: openssl-users@openssl.org
 Assunto: Re: HTTPS connection hangs during SSL handshake
 
 Is there no one in the community who can help me to find the cause of
 the problem ?
 
 On Tue, Sep 4, 2012 at 7:21 PM, Supratik Goswami
 supratiksek...@gmail.com wrote:
  I am using OpenSSL version : openssl-1.0.0j in our production.
 
  I am facing a strange problem where the SSL connection simply hangs
  during initial handshake when requested from our office IP address.
  When I run the same command from another IP address it works fine.
 
  From office IP (Unsuccessful connection):
 
  [root@gateway ]# openssl s_client -connect test.mydomain.com:443
  CONNECTED(0003)
 
Use s_client with at least -state and preferably -debug or -msg 
(you don't need both) to see how far it's getting in the handshake.

If you receive some handshake messages but not all, it practically 
must be the server; talk to the server operator(s). It would be 
unusual, but not impossible, for the server to mishandle connections 
from one IP while it works for another. If you receive no message 
at all, it might be server (try them) or it might be network 
weirdness as (Mr?) de Almeida suggests; try a sniffer on your client 
machine or near it (same LAN), and if that looks okay also try one 
on or near the server (you may need server operator(s) to do that).

For Windows or Mac, I recommend www.wireshark.org . Very capable, 
easy to install and use, well maintained. I don't know an equally 
good solution for Linux, but there may be one, or at minimum you can 
capture with tcpdump and if it's anything more complicated than 
no-response you can copy the capture and decode with wireshark.

One possibility -- some servers want to lookup in DNS the address 
of the client who connects to them (called reverse DNS or rDNS

HTTPS connection hangs during SSL handshake

[Supratik Goswami]

I am using OpenSSL version : openssl-1.0.0j in our production.

I am facing a strange problem where the SSL connection simply hangs
during initial handshake when requested from our office IP address.
When I run the same command from another IP address it works fine.

From office IP (Unsuccessful connection):

[root@gateway ]# openssl s_client -connect test.mydomain.com:443
CONNECTED(0003)


From a different IP (Successful connection):

ubuntu@ip-10-0-0-10 (Development):~$ openssl s_client -connect
test.mydomain.com:443
CONNECTED(0003)
depth=3 /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert
Class 2 Policy Validation
Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/O=*.mydomain.com/OU=Domain Control Validated/CN=*.mydomain.com
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
Certification Authority/serialNumber=07969287
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
Certification Authority/serialNumber=07969287
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2
Certification Authority
 2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2
Certification Authority
   i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class
2 Policy Validation
Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
 3 s:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class
2 Policy Validation
Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
   i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class
2 Policy Validation
Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
---
Server certificate
-BEGIN CERTIFICATE-

REMOVED FOR SECURITY REASON

-END CERTIFICATE-
subject=/O=*.mydomain.com/OU=Domain Control Validated/CN=*.mydomain.com
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
Certification Authority/serialNumber=07969287
---
No client certificate CA names sent
---
SSL handshake has read 4827 bytes and written 435 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1
Cipher: RC4-SHA
Session-ID: 276ADBFB75336E7E870C5E109B4C5F6AFB8328C8775029EF135C5DA6F8608533
Session-ID-ctx:
Master-Key:
22B470A67XXXB50ED6237BE9
Key-Arg   : None
Start Time: 1346765613
Timeout   : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain



Any ideas ?


-- 
Warm Regards

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

Secure WebSocket Server (using OpenSSL) Failing Client Connection During Initial SSL Handshake

[Jack Trades]

I have an asynchronous win32 websocket server (written in C/C++ using MSVS
2010) application that I now want to support WSS - a WebSocket Secure
connection.  To accomplish this, I added openssl to my application.
However, when the client tries to connect to my webserver, openssl is
rejecting the client during the initial handshake with the following error:

13500:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown
protocol:.\ssl\s23_clnt.c:683:

Here is some other info to help in uncovering the cause for this error:

* openssl version - OpenSSL 1.0.0d 8 Feb 2011
* I am testing locally using the latest Firefox/chrome browsers.
IP=127.0.0.1 Port=8181
* I created my own certificates for testing

Create the root CA
openssl req -newkey rsa:1024 -sha1 -keyout rootkey.pem -out
rootreq.pem
openssl x509 -req -in rootreq.pem -sha1 -extensions v3_ca -signkey
rootkey.pem -out rootcert.pem
cat rootcert.pem rootkey.pem   root.pem

Create the server's certificate and sign it with the root CA
openssl req -newkey rsa:1024 -sha1 -keyout serverkey.pem -out
serverreq.pem
openssl x509 -req -in serverreq.pem -sha1 -extensions usr_cert -CA
root.pem  -CAkey root.pem -CAcreateserial -out servercert.pem
cat servercert.pem serverkey.pem  rootcert.pem  server.pem

Create the client certificate  and sign it with the root CA
openssl req -newkey rsa:1024 -sha1 -keyout clientkey.pem -out
clientreq.pem
openssl x509 -req -in clientreq.pem -sha1 -extensions usr_cert -CA
root.pem  -CAkey root.pem -CAcreateserial -out clientcert.pem
cat clientcert.pem clientkey.pem  rootcert.pem  client.pem

Create the dh512.pem dh1024.pem
openssl dhparam -check -text -5 512 -out dh512.pem
openssl dhparam -check -text -5 1024  -out dh1024.pem


* I setup the SSL_CTX for the server as follows:

SSL_CTX *setup_server_ctx (void)
{
// Performs the necessary actions to provide certificate data
// to the client.
//

SSL_CTX *ctx;

// Specify the SSL protocol for the server to use.
ctx = SSL_CTX_new (SSLv23_method ());

if (ctx == NULL) {
int_error(Error creating a new SSL_CTX object);
return (NULL);
}

// Load the trusted certificates from rootcert.pem
if (SSL_CTX_load_verify_locations(ctx, CAFILE, CADIR) != 1) {
int_error(Error loading CA file and/or directory);
SSL_CTX_free (ctx);
return (NULL);
}

// Load the built-in certificate stores.
if (SSL_CTX_set_default_verify_paths(ctx) != 1) {
int_error(Error loading default CA file and/or directory);
SSL_CTX_free (ctx);
return (NULL);
}

// Incorporate certificate information into the SSL_CTX by
loading
// a chain of certificates from the specified file name
if (SSL_CTX_use_certificate_chain_file (ctx, SERVER_CERTFILE)
!= 1) {
int_error (Error loading certificate from file);
SSL_CTX_free (ctx);
return (NULL);
}

// Set password required to decrypt an encrypted private key
SSL_CTX_set_default_passwd_cb(ctx, passwd_cb);

// Load in the application's private key
if (SSL_CTX_use_PrivateKey_file (ctx, SERVER_CERTFILE,
SSL_FILETYPE_PEM) != 1) {
int_error (Error loading private key from file);
SSL_CTX_free (ctx);
return (NULL);
}

// Have the server request a certificate fom the client.
// or if no certificate supplied.
SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback);

// Set the maximum depth for verification.
SSL_CTX_set_verify_depth(ctx, 4);

// Enable all bug workarounds, disable SSL version 2, and
recompute the private
// part of the DH exchange for each client connecting.
SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 |
SSL_OP_SINGLE_DH_USE);

SSL_CTX_set_tmp_dh_callback(ctx, tmp_dh_callback);

if (SSL_CTX_set_cipher_list(ctx, CIPHER_LIST) != 1) {
int_error(Error setting cipher list (no valid ciphers));
SSL_CTX_free (ctx);
return (NULL);
}

return (ctx);

} // setup_server_ctx

* Since I am using a asynchronous winsock implementation (FD_READ,
FD_WRITE, etc) to handle TCP packets, I am using memory bios to process the
data.  I based some of my code off of the following implementation:
http://funcptr.net/2012/04/08/openssl-as-a-filter-%28or-non-blocking-openssl%29/

Can anyone help me figure out what is happening?  Any help would be
appreciated, especially since I am new to 

RE: Secure WebSocket Server (using OpenSSL) Failing Client Connection During Initial SSL Handshake

[Dave Thompson]

From: owner-openssl-us...@openssl.org On Behalf Of Jack Trades
Sent: Thursday, 14 June, 2012 16:18

I have an asynchronous win32 websocket server (written in C/C++ 
using MSVS 2010) application that I now want to support WSS - 
a WebSocket Secure connection.  To accomplish this, I added 
openssl to my application. However, when the client tries to 
connect to my webserver, openssl is rejecting the client 
during the initial handshake with the following error:

13500:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:
unknown protocol:.\ssl\s23_clnt.c:683:

This is a client-side error and should never occur on a server.
Are you doing SSL_accept or SSL_set_accept_state on the SSL 
object(s) you create for specific connections ?

Here is some other info to help in uncovering the cause for this error:
* openssl version - OpenSSL 1.0.0d 8 Feb 2011
* I am testing locally using the latest Firefox/chrome browsers.
IP=127.0.0.1 Port=8181

Note at the app level (not SSL level) browsers like IE FF Chrome, 
and some but not all other clients, want or require the host 
in the URL to match the subjectDN (or SAN) in the cert. 

* I created my own certificates for testing
snip: usual selfsign root,server,client; also
 openssl dhparam -check -text -5 512 -out dh512.pem
 openssl dhparam -check -text -5 1024  -out dh1024.pem

If you want/need actual security, don't use DH-512 except for 
old export suites and don't use old export suites at all.

* I setup the SSL_CTX for the server as follows:

 ctx = SSL_CTX_new (SSLv23_method ());
 if (ctx == NULL) {...
 // Load the trusted certificates from rootcert.pem
 if (SSL_CTX_load_verify_locations(ctx, CAFILE, CADIR) != 1) { ...
 // Load the built-in certificate stores.
 if (SSL_CTX_set_default_verify_paths(ctx) != 1) { ...

set_default_verify replaces the settings from load_verify, 
so OpenSSL will use only the default store and unless you 
have your root cert (or any other needed root(s)) there 
the server won't verify your client(s). Generally you should 
use set_default only if you have no app-specific truststore, 
or you supposedly have one but it gets an error and you want 
to proceed rather than demanding a fix.

 // Incorporate certificate information into the SSL_CTX by loading
 // a chain of certificates from the specified file name
 if (SSL_CTX_use_certificate_chain_file (ctx, SERVER_CERTFILE) != 1) { ...

The server cert you created above has no intermediate(s) and thus 
doesn't need _use_cert_chain, only _use_cert. But _use_chain works 
here, and also in other situations that do have real chains.

 // Set password required to decrypt an encrypted private key
 SSL_CTX_set_default_passwd_cb(ctx, passwd_cb);
 // Load in the application's private key
 if (SSL_CTX_use_PrivateKey_file (ctx, SERVER_CERTFILE, SSL_FILETYPE_PEM)
!= 1) { ...

 // Have the server request a certificate fom the client.  
 // or if no certificate supplied.
 SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback);
 // Set the maximum depth for verification.
 SSL_CTX_set_verify_depth(ctx, 4);

This setting requests client auth (cert plus proof), but 
accepts connection if none is supplied. Is that what you want?

 // Enable all bug workarounds, disable SSL version 2, and recompute the
private 
 // part of the DH exchange for each client connecting.
 SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 |
SSL_OP_SINGLE_DH_USE);
 SSL_CTX_set_tmp_dh_callback(ctx, tmp_dh_callback);

I assume this callback uses the dh-param files you created above.
If you prohibit export suites, you could set DH-1024 statically.

 if (SSL_CTX_set_cipher_list(ctx, CIPHER_LIST) != 1) { ...


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

OpenSSL0.9.8e-12.el5_4.6 Getting SSL3_GET_SERVER_HELLO:wrong cipher returned during SSL handshake

[ndipiazza]

We have experienced what appears to be a thread-safety issue with
ssl3_get_server_hello(). It works for the most part but then after traffic
starts to increase on the server utilizing OpenSSL... we get the error:

[Wed Feb 29 12:00:01 2012] [info] SSL Library Error: 336142597
error:14092105:SSL routines:SSL3_GET_SERVER_HELLO:wrong cipher returned

Here is our version of OpenSSL on this Rhel5 server:

rpm -qa | grep openssl
openssl-0.9.8e-12.el5_4.6
openssl-devel-0.9.8e-12.el5_4.6

What can we do to work-around this problem? 

More about our use case: We have Apache/2.2.21 (Unix) mod_ssl/2.2.21
OpenSSL/0.9.8e-fips-rhel5 configured.

The HTTPD Server has reverse proxy set up to communicate back and forth
between Apache and an VIP of an F5 load balancer. 

The server has good healthy operations until suddenly openSSL seems to break
down with the error above. 
-- 
View this message in context: 
http://old.nabble.com/OpenSSL0.9.8e-12.el5_4.6-Getting-SSL3_GET_SERVER_HELLO%3Awrong-cipher-returned-during-SSL-handshake-tp33416364p33416364.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: how to see the SSL handshake

[BharadwajNS]

You can use wireshark to analyse ssl packets.
-- 
View this message in context: 
http://old.nabble.com/how-to-see-the-SSL-handshake-tp33046057p33125719.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: how to see the SSL handshake

[tq jia]

Hello, You can use the tool -SSLdump to get the SSL handshake tracing!
Thanks

2011/12/28 Mithun Kumar mithunsi...@gmail.com

 Hello Forum,

 I am currently running the samples(client1,server1) , is there any
 environmental variables that i need to export so that i can get the SSL
 handshake tracing?

 -Thanks
  mithun

how to see the SSL handshake

[Mithun Kumar]

Hello Forum,

I am currently running the samples(client1,server1) , is there any
environmental variables that i need to export so that i can get the SSL
handshake tracing?

-Thanks
 mithun

Re: ssl handshake with multiple tcp connect?

[David Schwartz]

On 8/25/2011 6:04 AM, Arjan Filius wrote:


Hello,

today i ran into a situation, where i notice firefox/chrome and
gnutls-cli use 3 tcp sessions to get a single ssl session, where openssl
s_client takes only one.

one tcp session is what i expect, and i hope someone may have an
explanation.

compared the gnutls-cli with openssl s_client as thay would do no http
interpretation, and are easely reproduced by commandline:

gnutls-cli --insecure -V -r www.xs4all.nl /dev/null
uses 3 tcp sessions to complete
openssl s_client -connect www.xs4all.nl:443  /dev/null
uses 1 tcp session to complete


Any idea how that may come? until now, i was under the impression a ssl
session setup should only use 1 tcp session (apart from ocsp/crl checks)


Why are you passing '-r' to gnutls-cli? You are asking it to try to 
resume the session on a new TCP connection. (I count two connections.)


DS



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

Re: ssl handshake with multiple tcp connect?

[Arjan Filius]

Hello David,

thanks for your reply, and that's correct. that was it for gnutls-cli.
after a confusing day, one of the original item triggered my firefox
browser, i thought reproduced with gnutls-cli.
In the end it was a simpel favicon issue, which kept connecting (no
cache).

regards,

On Thu, 2011-08-25 at 23:00 -0700, David Schwartz wrote:

 On 8/25/2011 6:04 AM, Arjan Filius wrote:
 
  Hello,
 
  today i ran into a situation, where i notice firefox/chrome and
  gnutls-cli use 3 tcp sessions to get a single ssl session, where openssl
  s_client takes only one.
 
  one tcp session is what i expect, and i hope someone may have an
  explanation.
 
  compared the gnutls-cli with openssl s_client as thay would do no http
  interpretation, and are easely reproduced by commandline:
 
  gnutls-cli --insecure -V -r www.xs4all.nl /dev/null
  uses 3 tcp sessions to complete
  openssl s_client -connect www.xs4all.nl:443  /dev/null
  uses 1 tcp session to complete
 
 
  Any idea how that may come? until now, i was under the impression a ssl
  session setup should only use 1 tcp session (apart from ocsp/crl checks)
 
 Why are you passing '-r' to gnutls-cli? You are asking it to try to 
 resume the session on a new TCP connection. (I count two connections.)
 
 DS
 
 
 

ssl handshake with multiple tcp connect?

[Arjan Filius]

Hello,

today i ran into a situation, where i notice firefox/chrome and 
gnutls-cli use 3 tcp sessions to get a single ssl session, where openssl 
s_client takes only one.


one tcp session is what i expect, and i hope someone may have an 
explanation.


compared the gnutls-cli with openssl s_client as thay would do no http 
interpretation, and are easely reproduced by commandline:


gnutls-cli  --insecure -V -r www.xs4all.nl /dev/null
 uses 3 tcp sessions to complete
openssl s_client -connect www.xs4all.nl:443  /dev/null
 uses 1 tcp session to complete


Any idea how that may come? until now, i was under the impression a ssl 
session setup should only use 1 tcp session (apart from ocsp/crl checks)


Thanks in advance

Regards,
--
Arjan Filius
mailto:iafil...@xs4all.nl
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Trouble with SSL handshake

[CoachDom]

Good Morning,

My situation is very strange, i guess.

At work we use a CFT server, which is very popular in Europe for File
transfert between corporation, like bank.

In my case one of our customer is a bank, and they want that our file
transfert to be securised over SSL.

CFT include SSL support based on Openssl library and internal library.

My CFT server run under linux, an old debian i cannot upgrade due to
operationnal environment.

We need to play each other client/server role, so on both side we configured
CFT with our respective Authority certificate, and created local certificate
signed for the ssl connexion.

when i play the role of server, and our customer play the role of client,
everything runs fines and file transfert is ok.

When i play the role of client, trying to connect to our customer server, it
doesnt work.

The handshake doesnt finish.

i run an strace on my process wich manage the ssl handshake, and here is
what i got :

fcntl64(8, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0},
0xbfdef720) = 0
_llseek(8, 512, [512], SEEK_SET)= 0
fcntl64(8, F_SETLKW64, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0},
0xbfdef6e0) = 0
read(8, \7\0\0\0\0\0\0\0\6\0\0\0REFRCA\0\0\0\0\0\0\0\0\0\0\0\0..., 512) =
512
fcntl64(8, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0},
0xbfdef6e0) = 0
_llseek(7, 32814, [32814], SEEK_SET)= 0
read(7, \0UEFRLCLUS\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 8193)
= 8193
time([1305131804])  = 1305131804
time([1305131804])  = 1305131804
time([1305131804])  = 1305131804
time([1305131804])  = 1305131804
time([1305131804])  = 1305131804
time([1305131804])  = 1305131804
time([1305131804])  = 1305131804
time([1305131804])  = 1305131804
time([1305131804])  = 1305131804
time([1305131804])  = 1305131804
time([1305131804])  = 1305131804
time([1305131804])  = 1305131804
time([1305131804])  = 1305131804
time([1305131804])  = 1305131804
time([1305131804])  = 1305131804
write(1, OPNSSL.text_error(PKI2CRY:803)=e..., 98) = 98
gettimeofday({1305131804, 420297}, NULL) = 0
gettimeofday({1305131804, 420316}, NULL) = 0
semop(2031638, 0xbfdf0fc0, 1)   = 0
semop(2031638, 0xbfdf0fc0, 1)   = 0
msgsnd(32769, {2, \34pg\265}, 4, 0)


But im unable to find to what error it is related !

that is why i write here, in case someone has an idea !

Regards.

--
Carrel Dominique

SSL handshake failure

[Timur Elzhov]

Hi, openssl experts!

It's required to transfer data to Apple Push service that is located at
gateway.sandbox.push.apple.com:2195. I'm given the certificate and private
key both included in Certificate_and_key.pem. Trying to connect:

$ openssl s_client -connect gateway.sandbox.push.apple.com:2195 -CAfile
 EntrustCA.pem -cert Certificate_and_key.pem


Server's certificate is passed successfully (with CA included in
EntrustCA.pem) but the error is following:

140735074831484:error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
 certificate unknown:s3_pkt.c:1193:SSL alert number 46

140735074831484:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
 failure:s23_lib.c:184:


I tried to google about alert 46, but found only that something wrong with
client's certificate. Is it possible to get more details about failure?

Below is some info that might probably be helpful. I read about X509v3
extensions just tonight, and it's not clear for me by far if extensions
could relate to my problem:

$ openssl verify -CAfile AppleCA.pem Certificate_and_key.pem

 . . .
error 34 at 0 depth lookup:unhandled critical extension
OK

$ openssl x509 -in Certificate_and_key.pem -text -noout -purpose


here are all extensions marked as critical:

   X509v3 extensions:

   X509v3 Basic Constraints: critical

   CA:FALSE

   X509v3 Extended Key Usage: critical

   Code Signing

   X509v3 Key Usage: critical

   Digital Signature

. . .

Certificate purposes:

SSL client : No

SSL client CA : No

SSL server : No

SSL server CA : No

Netscape SSL server : No

Netscape SSL server CA : No

S/MIME signing : No

S/MIME signing CA : No

S/MIME encryption : No

S/MIME encryption CA : No

CRL signing : No

CRL signing CA : No

Any Purpose : Yes

Any Purpose CA : Yes

OCSP helper : Yes

OCSP helper CA : No

Time Stamp signing : No

Time Stamp signing CA : No


maybe, the SSL client : No line is related to connection failure?

Much thanks in advance!

--
WBR,
Timur

Re: SSL handshake failure

[Dr. Stephen Henson]

On Sun, Nov 14, 2010, Timur Elzhov wrote:

 Hi, openssl experts!
 
 It's required to transfer data to Apple Push service that is located at
 gateway.sandbox.push.apple.com:2195. I'm given the certificate and private
 key both included in Certificate_and_key.pem. Trying to connect:
 
 $ openssl s_client -connect gateway.sandbox.push.apple.com:2195 -CAfile
  EntrustCA.pem -cert Certificate_and_key.pem
 
 
 Server's certificate is passed successfully (with CA included in
 EntrustCA.pem) but the error is following:
 
 140735074831484:error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
  certificate unknown:s3_pkt.c:1193:SSL alert number 46
 
 140735074831484:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
  failure:s23_lib.c:184:
 
 
 I tried to google about alert 46, but found only that something wrong with
 client's certificate. Is it possible to get more details about failure?
 

That's all the server sends back. Is that the correct certificate for that
server?

 
X509v3 Extended Key Usage: critical
 
Code Signing
 

Well the above extension would mean that certificate can only be used for code
signing, not SSL client authentication.

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: Getting detailed ssl-handshake debug output

[Jeff Saremi]

 I received the answer in a direct email and just wanted to share it
here too:

- command line:

openssl s_client -state -debug -connect host:port

- programmatic:

One can look in the callback mechanism used in the above, specifically in 
apps/s_cb.c
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Getting detailed ssl-handshake debug output

[Jeff Saremi]

 I'd like to know if there's a way -- programmatic, config, environment
-- that I can get detailed print of what goes on during a handshake at
the client or the server? Below is the output from Apache Tomcat as an
example of the level of details i'm looking for:

http-442-1, READ: TLSv1 Handshake, length = 73
*** ClientHello, TLSv1
RandomCookie:  GMT: 1269551866 bytes = { 178, 23, 135, 211, 154, 110,
144, 59, 9
9, 139, 224, 45, 156, 231, 232, 123, 36, 95, 187, 165, 56, 121, 211, 63,
117, 43
, 7, 82 }
Session ID:  {}
Cipher Suites: [TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_S
HA, TLS_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_DSS
_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_
CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,
SSL_RSA
_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, Unknown 0x0:0xff]
Compression Methods:  { 0 }
Unsupported extension type_35, data:
***
%% Created:  [Session-1, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA]
*** ServerHello, TLSv1
RandomCookie:  GMT: 1269551766 bytes = { 32, 121, 10, 209, 123, 137,
160, 183, 1
86, 107, 255, 108, 79, 16, 190, 91, 180, 86, 18, 136, 232, 108, 249,
191, 90, 17
6, 87, 231 }
Session ID:  {76, 172, 211, 150, 251, 114, 230, 220, 75, 218, 174, 105,
134, 185
, 144, 119, 92, 182, 1, 58, 247, 172, 121, 90, 212, 100, 58, 220, 93,
76, 97, 11
1}
Cipher Suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
Compression Method: 0
***
Cipher suite:  SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
*** Certificate chain
chain [0] = [
[
  Version: V1
  Subject: OU=Tomcat, O=ACME, emailaddress=tom...@acme.com, C=CA,
CN=localhost
  Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
 
  Key:  Sun RSA public key, 512 bits
  modulus:
973285574783538290665814718553460486271776249697428968977460338357983
...
  public exponent: 65537
  Validity: [From: Mon Jun 21 14:33:25 EDT 2010,
   To: Tue Jun 21 14:33:25 EDT 2011]
  Issuer: OU=Root CA, O=ACME Systems Inc., L=TEST PURPOSES ONLY, C=CA,
CN=ACME Systems Root CA
  SerialNumber: [02]
 
]
  Algorithm: [SHA1withRSA]
  Signature:
: A5 A9 E6 5F BE 51 75 E5   E3 25 9D 92 AB 45 FA 1E  ..._.Qu..%...E..
...
 
]
***
*** Diffie-Hellman ServerKeyExchange
DH Modulus:  { 233, 230, 66, 89, 157, 53, 95, 55, 201, 127, 253, 53,
103, 18, 11
... }
DH Base:  { 48, 71, 10, 213, 160, 5, 251, 20, 206, 45, 157, 205, 135,
227, 139,
... }
Server DH Public Key:  { 159, 193, 69, 114, 138, 167, 128, 50, 5, 51,
77, 127, 2
...}
Signed with a DSA or RSA public key
*** CertificateRequest
Cert Types: RSA, DSS
Cert Authorities:
OU=Root CA, O=ACME Systems Inc., C=CA, CN=ACME Systems Root CA
OU=Root CA, O=ACME Systems Inc., L=TEST PURPOSES ONLY, C=CA,
CN=ACME Systems Root CA
CN=TESTCA, OU=CA, O=TEST
*** ServerHelloDone
http-442-1, WRITE: TLSv1 Handshake, length = 1544
http-442-1, READ: TLSv1 Handshake, length = 3309
*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: CN=fd0172c2-3f02-432e-8317-097b8fabff7d, OU=Windows/1.00,
O=instance
  Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
 
  Key:  Sun RSA public key, 1024 bits
  modulus:
128531339772544414974300233324968135333513753311766363920169114394683
...
 
  public exponent: 65537
  Validity: [From: Tue Oct 05 17:49:02 EDT 2010,
   To: Wed Oct 05 17:49:02 EDT 2011]
  Issuer: CN=TESTActivationCA, OU=Activation CA, O=TEST ACTIVATION
  SerialNumber: [012b7e5e 79df]

[2]: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
  CN=guest, OU=ACME PC Client, O=instance
]
 
[3]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  DigitalSignature
  Key_Encipherment
  Key_Agreement
]
 
[4]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:false
  PathLen: undefined
]
 
]
  Algorithm: [SHA256withRSA]
  Signature:
: 97 32 64 63 D4 DA ED AF   CD 7F EC 77 A6 7C 72 85  .2dc...w..r.
...
 
]
chain [1] = [
[
  Version: V3
  Subject: CN=TESTActivationCA, OU=Activation CA, O=TEST ACTIVATION
  Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
 
  Key:  Sun RSA public key, 2048 bits
  modulus:
241401315179803415263681113133745704037912047640810783616090692543408
...
  public exponent: 65537
  Validity: [From: Wed Jun 09 14:04:45 EDT 2010,
   To: Thu Jun 09 14:04:45 EDT 2011]
  Issuer: OU=Root CA, O=ACME Systems Inc., L=TEST PURPOSES ONLY, C=CA,
CN=ACME Systems Root CA
  SerialNumber: [01]
 
Certificate Extensions: 6
[1]: ObjectId: 2.5.29.30 Criticality=true
NameConstraints: [
Permitted:   GeneralSubtrees:
[
   GeneralSubtree: [
GeneralName: O=instance
Minimum: 0  Maximum: undefined]
]
   ]
 
[2]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
: 7C FB 2B 96 C9 0D 37 89   01 83 D9 5A 67 41 3B 3C  ..+...7ZgA;
0010: E7 45 81 43.E.C
]
]
 
[3]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
: 70 8F 22 BC D7 55 20 6E   

RE: Getting detailed ssl-handshake debug output

[Dave Thompson]

 From: owner-openssl-us...@openssl.org On Behalf Of Jeff Saremi
 Sent: Thursday, 07 October, 2010 15:15

  I'd like to know if there's a way -- programmatic, config, 
 environment
 -- that I can get detailed print of what goes on during a handshake at
 the client or the server? Below is the output from Apache Tomcat as an
 example of the level of details i'm looking for:
 
Not in OpenSSL, I'm pretty sure.

If you can install other software on the same machine, 
or (usually?) another machine on the same LAN, WireShark from 
www.wireshark.org can display it on screen, or save a trace file 
which you can open and re-display later. I haven't found a way to 
capture the formatted display (except screen print on Windows).

This will only work for initial negotiation, since renegotiation 
is encrypted (unless the initial/current ciphersuite is eNULL). 
ssldump might work in that case, but I haven't tried it.



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

Modifying SSL Handshake messages

[sandeep kiran p]

Hi,

Can someone tell me if there is any tool to modify the handshake messages
between client and server on the fly? For example, changing the list of
cipher suites offered by the client, changing the trusted CA names sent by
server etc. I understand that such a change would be caught by the
finished message, but I would like to know if any such tool really exists
that can help me modify the contents of the messages on the wire.

I know there are some tools that can capture packets on the wire, modify
them and then resend it, but thats not what I am looking for. I am looking
for something that would drop the original message and replace it
(completely or partially) with a new message.

Thanks,
Sandeep

RNG in SSL handshake

[Paul Ohmart]

Can anyone tell me what RNG is used in the SSL handshake in FIPS mode? 
Also what OpenSSL functions are called to get the random number. The 
Security Policy 1.1.1 documentation states that it is X9.31 but I am 
unable to locate where that happens in the source.


I am trying to use OpenSSL to generate random numbers that are X9.31 
compliant.


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

Re: RNG in SSL handshake

[Dr. Stephen Henson]

On Tue, May 18, 2010, Paul Ohmart wrote:

 Can anyone tell me what RNG is used in the SSL handshake in FIPS mode? Also 
 what OpenSSL functions are called to get the random number. The Security 
 Policy 1.1.1 documentation states that it is X9.31 but I am unable to 
 locate where that happens in the source.

 I am trying to use OpenSSL to generate random numbers that are X9.31 
 compliant.


OpenSSL uses the default PRNG implementation for all operations including
SSL/TLS, though in FIPS mode only TLS is permissible.

When you enter FIPS mode the default PRNG is set to the FIPS PRNG so TLS uses
the FIPS PRNG.

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

SSL Handshake - Server/Client Write Keys

[Steffan, Nate]

Hello,

 

I need to access the server write key and client write key that is generated
during the SSL Handshake and I am struggling on how one might do this.  I am
wondering if anyone has either done this or knows where I should be looking?
It looks like they get passed into the cipher, but I do not know how they
are stored. 

 

Thanks,

Nate Steffan 



smime.p7s
Description: S/MIME cryptographic signature

SSL Handshake - Server/Client Write Keys

[Steffan, Nate]

Hello,

 

I need to access the server write key and client write key that is generated
during the SSL Handshake and I am struggling on how one might do this.  I am
wondering if anyone has either done this or knows where I should be looking?
It looks like they get passed into the cipher, but I do not know how they
are stored. 

 

Thanks,

Nate Steffan 



smime.p7s
Description: S/MIME cryptographic signature

SSL Handshake question - SOLVED

[Steve Gallivan]

Flaky intermediate CA not being served up on the failed handshakes.

From: Steve Gallivan
Sent: Monday, June 01, 2009 5:51 PM
To: openssl-users@openssl.org
Subject: SSL Handshake question

Hello,

I apologize if this is an obvious NOOB question - my Google-Fu is not up to 
snuff on this one:

We're running  OpenSSL 0.9.8j 07 Jan 2009 and Server version: Apache/2.0.63 on 
a  Sunfire 280R running Solaris 9.

Clients are having intermittent problems successfully completing the SSL 
Handshake.

Running a trace on the wire revealed that the successful handshakes looked like 
this:
Client - Server: Client Hello
Server - Client: Server Hello
Server - Client: Certificate
Client - Server: Client Key Exchange
And so on, all good.

On the failures the exchange looks like this:
Client - Server:  Client Hello
Server - Client: Server Hello, Certificate, Server Hello Done
Client - Server: Fatal, Description: Certificate Unknown

In running repeated tests using a java test client, we have many successful 
handshakes ( we close the socket after each one ) and then we'll hit a series 
of several failed ones, say 4-10 in a row, then it's all good again.
I'm trying to understand why the server would answer some requests with a 
Server Hello, Certificate, Server Hello Done all wrapped up in one packet ( 
the ones that are failing ), where most of the time it splits that out over 
several packets. The test Client Hello requests seem identical.

Any insights would be much appreciated.

Thanks,
Steve

SSL Handshake question

[Steve Gallivan]

Hello,

I apologize if this is an obvious NOOB question - my Google-Fu is not up to 
snuff on this one:

We're running  OpenSSL 0.9.8j 07 Jan 2009 and Server version: Apache/2.0.63 on 
a  Sunfire 280R running Solaris 9.

Clients are having intermittent problems successfully completing the SSL 
Handshake.

Running a trace on the wire revealed that the successful handshakes looked like 
this:
Client - Server: Client Hello
Server - Client: Server Hello
Server - Client: Certificate
Client - Server: Client Key Exchange
And so on, all good.

On the failures the exchange looks like this:
Client - Server:  Client Hello
Server - Client: Server Hello, Certificate, Server Hello Done
Client - Server: Fatal, Description: Certificate Unknown

In running repeated tests using a java test client, we have many successful 
handshakes ( we close the socket after each one ) and then we'll hit a series 
of several failed ones, say 4-10 in a row, then it's all good again.
I'm trying to understand why the server would answer some requests with a 
Server Hello, Certificate, Server Hello Done all wrapped up in one packet ( 
the ones that are failing ), where most of the time it splits that out over 
several packets. The test Client Hello requests seem identical.

Any insights would be much appreciated.

Thanks,
Steve

Client Puzzle during SSL handshake

[neha gupta]

Hello I want to implement ssl with client puzzle ( After the client hello
and server hello , server will send puzzle req and further step will take
place if server would get correct puzzle reply from client)
Till now i have directly used ssl_connect function but now i need to support
client puzzle. But i m not getting actually how ssl_connect code is
implemented ( i didnt find its code) and how introduce puuzle steps in it.
so any suggestion how to do ?

RE: [FWD] DNS Error while doing SSL handshake - bad gethostbyaddr

[Byju Joy]

Thank you Dave and Lutz. Good to know that I can ignore the error message
bad gethostbyaddr. Real problem is that Client hello B is not coming
through. Yes, there is a firewall in between client and server. Since the
SSL client was able to send in a few bytes (cient hello A?) successfully,
firewall connection in this direction looks ok. It might be that firewall
doesn't allow communication in opposite direction (from server to client)
and hence client not receiving server hello? I will look into the firewall
side...

Thanks,
Byju Joy



Dave Thompson-4 wrote:
 
 -Original Message-
 From: [EMAIL PROTECTED] On Behalf Of Lutz Jaenicke
 Sent: Friday, 10 October, 2008 09:03
 - Forwarded message from Joy, Byju (GE Healthcare,
 consultant) [EMAIL PROTECTED] -

 Subject: DNS Error while doing SSL handshake - bad gethostbyaddr
 Date: Fri, 10 Oct 2008 15:00:51 +0200
 Thread-Topic: DNS Error while doing SSL handshake - bad gethostbyaddr
 thread-index: Ackq2DkNLX4Go5QUSQWx6NJWZ9B4Hw==
 From: Joy, Byju (GE Healthcare, consultant) [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]

 Dear OpenSSL experts,

 I am trying to run OpenSSL version OpenSSL 0.9.8i 15 Sep 2008 on
 Windows Server 2003 Standard Edition Version 5.2.3790. Could you please
 help me with bad gethostbyaddr error message while doing SSL
 handshake? Log is given below:

 s_server calls do_server calls do_accept which, after the actual (TCP)
 accept,
 calls gethostbyaddr to try to get the client host's name. If your
 system/network
 doesn't have DNS set up to do reverse-mapping for that host, you get this
 printed.
 (That would include DNS not set up at all, but I don't think Svr03 can do
 that.
 It could include using a bad/wrong nameserver, or zone; or
 unreachable/down
 one;
 or using a good nameserver but the zone admin doesn't do reverse-mapping
 at
 all
 -- some don't; or didn't do it for that host -- particularly if it's a
 dynamic
 host e.g. a(nother) PC many admins don't consider it worth the trouble.)
 
 But it causes no harm; it just passes back a nullptr for the hostname
 string,
 which the actual logic (sv_body or www_body) never uses. The connection
 can
 still
 be completed and used, at least through 0.9.8g and I doubt this would be
 changed.
 (If you actually want to fix the revlookup, you need to say more about the
 type
 and relative network location of the client machine, and if it's not
 something
 simple you'll probably need to go elsewhere to a network-mgt
 group/list/forum.)
 

 D:\OpenSSL2\binopenssl
 OpenSSL s_server -accept 443 -verify 2 -cert D:\my_crt.pem -key
 D:\my_key.pem -debug -msg -state -CAfile D:\CAcerts.pem -ssl3
 verify depth is 2
 Enter pass phrase for D:\my_key.pem: my_pass_phrase
 Loading 'screen' into random state - done
 Using default temp DH parameters
 Using default temp ECDH parameters
 ACCEPT
 bad gethostbyaddr
 SSL_accept:before/accept initialization
 read from 0xa533d0 [0xa6fc10] (5 bytes = 0 (0x0))
 SSL_accept:failed in SSLv3 read client hello B
 
 This is your actual problem: you are not receiving the client hello.
 You appear to be getting a normal TCP shutdown instead i.e. FIN not RST.
 This might mean the client deliberately closed; on some system types
 it also occurs if the client fails e.g. segfault; it might also occur
 if something between you in the network like a firewall dislikes you.
 
 ERROR
 shutting down SSL
 CONNECTION CLOSED
 ACCEPT
 
 
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   [EMAIL PROTECTED]
 
 

-- 
View this message in context: 
http://www.nabble.com/-FWD--DNS-Error-while-doing-SSL-handshake---bad-gethostbyaddr-tp19918981p19950564.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

[FWD] DNS Error while doing SSL handshake - bad gethostbyaddr

[Lutz Jaenicke]

Forwarded to openssl-users for public discussion.

Best regards,
Lutz
- Forwarded message from Joy, Byju (GE Healthcare, consultant) [EMAIL 
PROTECTED] -

Subject: DNS Error while doing SSL handshake - bad gethostbyaddr
Date: Fri, 10 Oct 2008 15:00:51 +0200
Thread-Topic: DNS Error while doing SSL handshake - bad gethostbyaddr
thread-index: Ackq2DkNLX4Go5QUSQWx6NJWZ9B4Hw==
From: Joy, Byju (GE Healthcare, consultant) [EMAIL PROTECTED]
To: [EMAIL PROTECTED]

Dear OpenSSL experts,
 
I am trying to run OpenSSL version OpenSSL 0.9.8i 15 Sep 2008 on
Windows Server 2003 Standard Edition Version 5.2.3790. Could you please
help me with bad gethostbyaddr error message while doing SSL
handshake? Log is given below:
 
 
D:\OpenSSL2\binopenssl
OpenSSL s_server -accept 443 -verify 2 -cert D:\my_crt.pem -key
D:\my_key.pem -debug -msg -state -CAfile D:\CAcerts.pem -ssl3
verify depth is 2
Enter pass phrase for D:\my_key.pem: my_pass_phrase
Loading 'screen' into random state - done
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
bad gethostbyaddr
SSL_accept:before/accept initialization
read from 0xa533d0 [0xa6fc10] (5 bytes = 0 (0x0))
SSL_accept:failed in SSLv3 read client hello B
ERROR
shutting down SSL
CONNECTION CLOSED
ACCEPT
bad gethostbyaddr
SSL_accept:before/accept initialization
read from 0xa533d0 [0xa6fc10] (5 bytes = 0 (0x0))
SSL_accept:failed in SSLv3 read client hello B
ERROR
shutting down SSL
CONNECTION CLOSED
ACCEPT
bad gethostbyaddr
 
 
Thanks  Regards, 
Byju Joy 
+91-9902511344, +91-80-67245657, *7098068
 

- End forwarded message -
--
Lutz Jaenicke   [EMAIL PROTECTED]
OpenSSL Project http://www.openssl.org/~jaenicke/
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: [FWD] DNS Error while doing SSL handshake - bad gethostbyaddr

[Dave Thompson]

 -Original Message-
 From: [EMAIL PROTECTED] On Behalf Of Lutz Jaenicke
 Sent: Friday, 10 October, 2008 09:03
 - Forwarded message from Joy, Byju (GE Healthcare,
 consultant) [EMAIL PROTECTED] -

 Subject: DNS Error while doing SSL handshake - bad gethostbyaddr
 Date: Fri, 10 Oct 2008 15:00:51 +0200
 Thread-Topic: DNS Error while doing SSL handshake - bad gethostbyaddr
 thread-index: Ackq2DkNLX4Go5QUSQWx6NJWZ9B4Hw==
 From: Joy, Byju (GE Healthcare, consultant) [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]

 Dear OpenSSL experts,

 I am trying to run OpenSSL version OpenSSL 0.9.8i 15 Sep 2008 on
 Windows Server 2003 Standard Edition Version 5.2.3790. Could you please
 help me with bad gethostbyaddr error message while doing SSL
 handshake? Log is given below:

s_server calls do_server calls do_accept which, after the actual (TCP)
accept,
calls gethostbyaddr to try to get the client host's name. If your
system/network
doesn't have DNS set up to do reverse-mapping for that host, you get this
printed.
(That would include DNS not set up at all, but I don't think Svr03 can do
that.
It could include using a bad/wrong nameserver, or zone; or unreachable/down
one;
or using a good nameserver but the zone admin doesn't do reverse-mapping at
all
-- some don't; or didn't do it for that host -- particularly if it's a
dynamic
host e.g. a(nother) PC many admins don't consider it worth the trouble.)

But it causes no harm; it just passes back a nullptr for the hostname
string,
which the actual logic (sv_body or www_body) never uses. The connection can
still
be completed and used, at least through 0.9.8g and I doubt this would be
changed.
(If you actually want to fix the revlookup, you need to say more about the
type
and relative network location of the client machine, and if it's not
something
simple you'll probably need to go elsewhere to a network-mgt
group/list/forum.)


 D:\OpenSSL2\binopenssl
 OpenSSL s_server -accept 443 -verify 2 -cert D:\my_crt.pem -key
 D:\my_key.pem -debug -msg -state -CAfile D:\CAcerts.pem -ssl3
 verify depth is 2
 Enter pass phrase for D:\my_key.pem: my_pass_phrase
 Loading 'screen' into random state - done
 Using default temp DH parameters
 Using default temp ECDH parameters
 ACCEPT
 bad gethostbyaddr
 SSL_accept:before/accept initialization
 read from 0xa533d0 [0xa6fc10] (5 bytes = 0 (0x0))
 SSL_accept:failed in SSLv3 read client hello B

This is your actual problem: you are not receiving the client hello.
You appear to be getting a normal TCP shutdown instead i.e. FIN not RST.
This might mean the client deliberately closed; on some system types
it also occurs if the client fails e.g. segfault; it might also occur
if something between you in the network like a firewall dislikes you.

 ERROR
 shutting down SSL
 CONNECTION CLOSED
 ACCEPT


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

problems with BIO pairs and SSL handshake

[Vladimir Sabanov]

Hi!

I have some server and async. transport on WINSOCK. Send and receive do with 
next
operations:

DWORD CSSLTLSLayer::Receive(IN OVERLAPPED *pOverlapped,
IN WSABUF *pBuffer, 
OUT PDWORD pdwWasRecv)
{
DWORD dwRet = __super::Receive(pOverlapped, pBuffer, pdwWasRecv);

BIO_write(m_pNetworkBIO, pBuffer-buf, *pdwWasRecv);
BIO_flush(m_pNetworkBIO);

size_t iBuffered = BIO_ctrl_pending(m_pSSLBIO);

if (iBuffered = 0){
return(WSA_IO_PENDING);
}

m_vcLayeredBuffer.clear();
m_vcLayeredBuffer.resize(iBuffered);
iBuffered = BIO_read(m_pSSLBIO, m_vcLayeredBuffer.front(), 
(int)iBuffered);

pBuffer-buf = m_vcLayeredBuffer.front();
pBuffer-len = (u_long)m_vcLayeredBuffer.size();

return(dwRet);
}

DWORD CSSLTLSLayer::Send(IN OVERLAPPED *pOverlapped, 
 IN WSABUF *pBuffer, 
 OUT PDWORD pdwWasSend)
{
size_t iBuffered = BIO_write(m_pSSLBIO, pBuffer-buf, pBuffer-len);

BIO_flush(m_pSSLBIO);
iBuffered = (int)BIO_ctrl_pending(m_pNetworkBIO);

if (iBuffered = 0){
return(WSA_IO_PENDING);
}

m_vcLayeredBuffer.clear();
m_vcLayeredBuffer.resize(iBuffered);

iBuffered = BIO_read(m_pNetworkBIO, 
 m_vcLayeredBuffer.front(), 
 (int)iBuffered);

pBuffer-buf = m_vcLayeredBuffer.front();
pBuffer-len = (u_long)m_vcLayeredBuffer.size();

return(__super::Send(pOverlapped, pBuffer, pdwWasSend));
}

But i have a problem with handshake. How can i do SSL handshake using
BIO and without SSL_accept or SSL_set_accept_state()+SSL_do_handshake.

Thanks for support!;)

--
Best regards, 
Vladimir Sabanov mailto:[EMAIL PROTECTED]
Software Developer of ApriorIT - A PriorITy choice!

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

Can't free BIO after ssl handshake fails

[Roman Aspetsberger]

Hello.

I have got a big problem in my application:

My application is connecting webservers over ssl. Therefore, I use a bio 
chain bufferBIO - sslBIO - socketBIO. I use certificate verification, 
but when a cert verification fails, I have a problem with freeing the 
ssl BIO.
My thread is hanging at BIO_free(serverTlsBIO) with full CPU load. But 
if I don't free the ssl BIO, I have a big memory leak. The interesting 
thing is, that this doesen't happen always, but always with the same 
websites/certificates.


if (BIO_do_handshake(serverTlsBIO) = 0)
{
BIO_pop(serverTlsBIO);
BIO_free(serverTlsBIO);
return TLS_SERVER_HANDSHAKE_ERR;
}

Has anyone a solution or is anything wrong in my consideration?

Thanks in advance,
Roman

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

Re: How to dump SSL Handshake messages?

[G.W. Haywood]

Hi there,

On Fri, 11 Jan 2008, Vicky Ven wrote:

 I need to the capture the SSL handshake messages between my client
 application and server.
 How do we dump detailed SSL Handshake messages? Does OpenSSL offer some
 means?

Depends on your platform.

Try tcpdump if you have something that offers it - almost all Unix-like
systems do.  Wireshark is very much better but takes a little effort to
install if you don't already have it.

--

73,
Ged.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

How to dump SSL Handshake messages?

[Vicky Ven]

Hi,

I need to the capture the SSL handshake messages between my client
application and server.
How do we dump detailed SSL Handshake messages? Does OpenSSL offer some
means?

Thanks,
Vicky

Re: How to dump SSL Handshake messages?

[Vicky Ven]

Hi,

 I have used ssldump tool. However I need to implement the logging
 capability in my application. For example, if  the application recieves a
particular Alert message , the application should dump all the messages that
were exchanged for that particular handshake.


Thanks,
Vicky



On 1/11/08, Vicky Ven [EMAIL PROTECTED] wrote:

 Hi,

 I need to the capture the SSL handshake messages between my client
 application and server.
 How do we dump detailed SSL Handshake messages? Does OpenSSL offer some
 means?

 Thanks,
 Vicky

Re: How to dump SSL Handshake messages?

[Marek . Marcola]

Hello, 
  I have used ssldump tool. However I need to implement the logging 
capability in my 
 application. For example, if  the application recieves a particular 
Alert message , the 
 application should dump all the messages that were exchanged for that 
particular handshake. 
You may set message peek callback with SSL_set_msg_callback() function.
Look at examples in apps/ directory.

Best regards,
--
Marek Marcola [EMAIL PROTECTED]

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