from:"Carl Heyendal"

Re: [openssl-users] cipher suite list

2016-09-28 Thread Carl Heyendal

Thanks Michael.

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Michael Wojcik
Sent: September-28-16 2:58 PM
To: openssl-users@openssl.org
Subject: [Newsletter] Re: [openssl-users] cipher suite list

Ivan Ristic's free OpenSSL Cookbook has a long section on cipher suite 
selection. It's available on 
feistyduck.

Michael Wojcik
Distinguished Engineer, Micro Focus

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Salz, Rich
Sent: Wednesday, September 28, 2016 13:29
To: openssl-users@openssl.org
Subject: Re: [openssl-users] cipher suite list

Some places to look include:
https://wiki.mozilla.org/Security/Server_Side_TLS
https://bettercrypto.org/static/applied-crypto-hardening.pdf
ssllabs.com
observatory.mozilla.org

And, by the way, the silly huge email disclaimer is obnoxious.
--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz

***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are 
hereby notified that any review, use, disclosure, dissemination, distribution 
or copying of this message and any attachments is strictly prohibited. If you 
have received this email in error, please immediately notify the sender and 
destroy this e-mail and any attachments and all copies, whether electronic or 
printed. Please also note that any views, opinions, conclusions or commitments 
expressed in this message are those of the individual sender and do not 
necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are 
not binding on Fortinet and only a writing manually signed by Fortinet's 
General Counsel can be a binding commitment of Fortinet to Fortinet's customers 
or partners. Thank you. ***

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

Re: [openssl-users] cipher suite list

2016-09-28 Thread Carl Heyendal

Thanks for the pointers.

As for the silly disclaimer I have no control over adding it or not. My company 
must append it to the email when it sends it. :)

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Salz, Rich
Sent: September-28-16 1:29 PM
To: openssl-users@openssl.org
Subject: [Newsletter] Re: [openssl-users] cipher suite list

Some places to look include:
https://wiki.mozilla.org/Security/Server_Side_TLS
https://bettercrypto.org/static/applied-crypto-hardening.pdf
ssllabs.com
observatory.mozilla.org

And, by the way, the silly huge email disclaimer is obnoxious.
--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz

***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are 
hereby notified that any review, use, disclosure, dissemination, distribution 
or copying of this message and any attachments is strictly prohibited. If you 
have received this email in error, please immediately notify the sender and 
destroy this e-mail and any attachments and all copies, whether electronic or 
printed. Please also note that any views, opinions, conclusions or commitments 
expressed in this message are those of the individual sender and do not 
necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are 
not binding on Fortinet and only a writing manually signed by Fortinet's 
General Counsel can be a binding commitment of Fortinet to Fortinet's customers 
or partners. Thank you. ***

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

[openssl-users] cipher suite list

2016-09-28 Thread Carl Heyendal

Hi, being somewhat of a newb to the security I thought I would ask the security 
community about the current best practices/guidelines for configuring the list 
of cipher suites that I should use in my client app. It seems like some cipher 
suites fall out of favour over time and I would like to use the most safe and 
reliable cipher suites that are currently known as of today.

Appreciate any advice.

/carl h.




***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are 
hereby notified that any review, use, disclosure, dissemination, distribution 
or copying of this message and any attachments is strictly prohibited. If you 
have received this email in error, please immediately notify the sender and 
destroy this e-mail and any attachments and all copies, whether electronic or 
printed. Please also note that any views, opinions, conclusions or commitments 
expressed in this message are those of the individual sender and do not 
necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are 
not binding on Fortinet and only a writing manually signed by Fortinet's 
General Counsel can be a binding commitment of Fortinet to Fortinet's customers 
or partners. Thank you. ***

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

Re: [openssl-users] [Newsletter] Re: Same openssl app behaves differently depending on platform

2016-07-21 Thread Carl Heyendal

Turned out to be optimization as you suggested. Once I turned it off the app 
connected on the embedded target.

Good one Steve. I had forgotten how optimization mucks things up from time to 
time.

Thanks
/carl h.

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Dr. 
Stephen Henson
Sent: July-21-16 10:34 AM
To: openssl-users@openssl.org
Subject: [Newsletter] Re: [openssl-users] Same openssl app behaves differently 
depending on platform

On Thu, Jul 21, 2016, Carl Heyendal wrote:

> I have an app that uses openssl to connect to a server on a different 
> machine. In one case on my Ubuntu machine the app has no problem getting a 
> secure connection. But when I recompile the same app for an embedded target 
> board and run it I get this error:
> 
> # ./client3 192.168.1.99
> Enter PEM pass phrase:
> connecting to 192.168.1.99:16001
> ** client3.c:77 Error connecting SSL object 1024:error:04091068:rsa 
> routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
> 1024:error:1408D07B:SSL routines:ssl3_get_key_exchange:bad 
> signature:s3_clnt.c:2004:
> 
> The app uses the same private key and certificate in both cases.
> 

It could be a compiler bug on the embedded platform. Does it pass "make test"?

Have you tried it with optimisation turned off?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are 
hereby notified that any review, use, disclosure, dissemination, distribution 
or copying of this message and any attachments is strictly prohibited. If you 
have received this email in error, please immediately notify the sender and 
destroy this e-mail and any attachments and all copies, whether electronic or 
printed. Please also note that any views, opinions, conclusions or commitments 
expressed in this message are those of the individual sender and do not 
necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are 
not binding on Fortinet and only a writing manually signed by Fortinet's 
General Counsel can be a binding commitment of Fortinet to Fortinet's customers 
or partners. Thank you. *** 

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

[openssl-users] Same openssl app behaves differently depending on platform

2016-07-21 Thread Carl Heyendal

I have an app that uses openssl to connect to a server on a different machine. 
In one case on my Ubuntu machine the app has no problem getting a secure 
connection. But when I recompile the same app for an embedded target board and 
run it I get this error:

# ./client3 192.168.1.99
Enter PEM pass phrase:
connecting to 192.168.1.99:16001
** client3.c:77 Error connecting SSL object
1024:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
1024:error:1408D07B:SSL routines:ssl3_get_key_exchange:bad 
signature:s3_clnt.c:2004:

The app uses the same private key and certificate in both cases.

As a test I used s_client on both platforms to see whether it's a problem with 
the app, and it too fails with the same error on the embedded target but makes 
a connection on the Ubuntu machinejust like the app.

Something I observed on a wireshark trace is that depending on what platform 
the app is running on, in the 'Client Hello' exchange the app advertises a much 
smaller set of cipher suites on the Ubuntu machine than on the embedded target 
app. Consequently the server chooses a different cipher suite in both 
situations. This puzzles me and not sure if it's related to my problem.

Worth noting the version of openssl on the Ubuntu machine which is the platform 
that works, is older than the version for the embedded target board.

Not using TLSv2.

Appreciate any help or a nudge on how to debug this.

/carl h.



***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are 
hereby notified that any review, use, disclosure, dissemination, distribution 
or copying of this message and any attachments is strictly prohibited. If you 
have received this email in error, please immediately notify the sender and 
destroy this e-mail and any attachments and all copies, whether electronic or 
printed. Please also note that any views, opinions, conclusions or commitments 
expressed in this message are those of the individual sender and do not 
necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are 
not binding on Fortinet and only a writing manually signed by Fortinet's 
General Counsel can be a binding commitment of Fortinet to Fortinet's customers 
or partners. Thank you. *** 


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

Re: [openssl-users] [Newsletter] Re: self-signed certificate won't work in my app but works with s_client

2016-07-04 Thread Carl Heyendal

Thanks Matthew.

However the problem seems to be occurring before the processing of the return 
codes you mentioned.

The problem occurs from a bad return value from:
if(SSL_connect(ssl) <= 0)
int_error("Error connecting SSL object");

A Wireshark trace reveals that the client shuts  down the handshake connection 
with the reason ‘Unknown CA’.

So if the client knows that the cert is self-signed as indicated by the debug 
logs, why would it issue the above reason for failure when it doesn’t need to 
know the CA?

Carl

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Matthew Donald
Sent: July-01-16 12:09 AM
To: openssl-users@openssl.org
Subject: [Newsletter] Re: [openssl-users] self-signed certificate won't work in 
my app but works with s_client

"error 18:self signed certificate" is the expected result if you are validating 
a self-signed cert.

In certificate verification, the code needs to check for X509_V_OK, 
X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT and  
X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY.

X509_V_OK is a normal cert verification and the connection can proceed.  
X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY indicates that an otherwise valid 
cert has been processed, but the issuer is unknown.  
X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT indicates that a self-signed cert was 
read.  Any other return value is a fatal error (signature failure etc).

Matthew

On 1 July 2016 at 05:34, Carl Heyendal 
<cheyen...@fortinet.com<mailto:cheyen...@fortinet.com>> wrote:
I am working with the example apps in the "Networking Security with OpenSSL" 
book and up until now have been able to get client/server examples 1,2,3 to 
work. But now I'm trying to connect to an in-house tool but I'm getting the 
error "error 18:self signed certificate". Despite this error when I run my app 
(essentially client3), when I use s_client with the very same credentials...it 
works.

I suspect that it has something to do with the ssl/tls api combination that I 
use in my 'client3' app.

Here's the command and output for s_client that connects to the in-house tool 
which works:

> openssl s_client -connect 192.168.1.99:16001<http://192.168.1.99:16001> 
-CAfile ../_security/SipInspector/certificate.pem -key ../_security/client.pem
  Enter pass phrase for ../_security/client.pem:
  CONNECTED(0003)
  depth=0 C = CA, ST = Ontario, L = Ottawa, O = SIP Inspector Ltd, OU   =   
  Development, CN = 192.168.1.99
  verify return:1
  ---
  Certificate chain
   0 s:/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
 i:/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
  ---
  Server certificate
  -BEGIN CERTIFICATE-
  MIIFxTCCA62gAwIBAgIJALKQ3J5SEyjPMA0GCSqGSIb3DQEBCwUAMHkxCzAJBgNV
  BAYTAkNBMRAwDgYDVQQIDAdPbnRhcmlvMQ8wDQYDVQQHDAZPdHRhd2ExGjAYBgNV
(snip)
  pt/q5/gKqRFbjyL0LDNz49vaSUYvbu3mgF2480Or4X+GPwemwdxJaF1pQw4C1WaF
  RyfVjDrLNhTvv+zKCbEPyrjXCweNVRVcp8lZ8R0HmXwfgevlCNz/GQo=
  -END CERTIFICATE-
  subject=/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
  issuer=/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 2309 bytes and written 509 bytes
  ---
  New, TLSv1/SSLv3, Cipher is ECDHE-RSA-DES-CBC3-SHA
  Server public key is 4096 bit
  Secure Renegotiation IS supported
  Compression: NONE
  Expansion: NONE
  SSL-Session:
  Protocol  : TLSv1.2
  Cipher: ECDHE-RSA-DES-CBC3-SHA
  Session-ID:   
5755C781D91CF3177DF624EA3599EE430DAB4790F325FAD9378FEAE7731C4497
  Session-ID-ctx:
  Master-Key: 
D149008E43E29D658D29418C9F770B3D6018B1D7CA2F493027B0AC7C3BA8E53B572B68C371153568B8988A1E5F351839
  Key-Arg   : None
  PSK identity: None
  PSK identity hint: None
  SRP username: None
  Start Time: 1465239425
  Timeout   : 300 (sec)
  Verify return code: 0 (ok)
   ---

Here's the command and output when I run my app that tries to connect to the 
same in-house tool which fails:

> ./client3 192.168.1.99
Enter PEM pass phrase:
connecting to 192.168.1.99:16001<http://192.168.1.99:16001>
 -Error with certificate at depth: 0
   issuer   = /C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector Ltd/OU=Development  
 /CN=192.168.1.99
   subject  = /C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
   err 18:self signed certificate
 ** client3.c:94 Error connecting SSL object
139788992993088:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:1180:
>

Here are the api's I call in the my app that utilize the

[openssl-users] self-signed certificate won't work in my app but works with s_client

2016-06-30 Thread Carl Heyendal

I am working with the example apps in the "Networking Security with OpenSSL" 
book and up until now have been able to get client/server examples 1,2,3 to 
work. But now I'm trying to connect to an in-house tool but I'm getting the 
error "error 18:self signed certificate". Despite this error when I run my app 
(essentially client3), when I use s_client with the very same credentials...it 
works.

I suspect that it has something to do with the ssl/tls api combination that I 
use in my 'client3' app.

Here's the command and output for s_client that connects to the in-house tool 
which works:

> openssl s_client -connect 192.168.1.99:16001 -CAfile 
../_security/SipInspector/certificate.pem -key ../_security/client.pem
  Enter pass phrase for ../_security/client.pem:
  CONNECTED(0003)
  depth=0 C = CA, ST = Ontario, L = Ottawa, O = SIP Inspector Ltd, OU   =   
  Development, CN = 192.168.1.99
  verify return:1
  ---
  Certificate chain
   0 s:/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
 i:/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
  ---
  Server certificate
  -BEGIN CERTIFICATE-
  MIIFxTCCA62gAwIBAgIJALKQ3J5SEyjPMA0GCSqGSIb3DQEBCwUAMHkxCzAJBgNV
  BAYTAkNBMRAwDgYDVQQIDAdPbnRhcmlvMQ8wDQYDVQQHDAZPdHRhd2ExGjAYBgNV
(snip)
  pt/q5/gKqRFbjyL0LDNz49vaSUYvbu3mgF2480Or4X+GPwemwdxJaF1pQw4C1WaF
  RyfVjDrLNhTvv+zKCbEPyrjXCweNVRVcp8lZ8R0HmXwfgevlCNz/GQo=
  -END CERTIFICATE-
  subject=/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
  issuer=/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 2309 bytes and written 509 bytes
  ---
  New, TLSv1/SSLv3, Cipher is ECDHE-RSA-DES-CBC3-SHA
  Server public key is 4096 bit
  Secure Renegotiation IS supported
  Compression: NONE
  Expansion: NONE
  SSL-Session:
  Protocol  : TLSv1.2
  Cipher: ECDHE-RSA-DES-CBC3-SHA
  Session-ID:   
5755C781D91CF3177DF624EA3599EE430DAB4790F325FAD9378FEAE7731C4497
  Session-ID-ctx: 
  Master-Key: 
D149008E43E29D658D29418C9F770B3D6018B1D7CA2F493027B0AC7C3BA8E53B572B68C371153568B8988A1E5F351839
  Key-Arg   : None
  PSK identity: None
  PSK identity hint: None
  SRP username: None
  Start Time: 1465239425
  Timeout   : 300 (sec)
  Verify return code: 0 (ok)
   ---


Here's the command and output when I run my app that tries to connect to the 
same in-house tool which fails:

> ./client3 192.168.1.99
Enter PEM pass phrase:
connecting to 192.168.1.99:16001
 -Error with certificate at depth: 0
   issuer   = /C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector Ltd/OU=Development  
 /CN=192.168.1.99
   subject  = /C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
   err 18:self signed certificate
 ** client3.c:94 Error connecting SSL object
139788992993088:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:1180:
> 

Here are the api's I call in the my app that utilize the same credentials used 
by the s_client command:

 SSL_CTX_new(SSLv23_method());
 SSL_CTX_load_verify_locations(ctx, 
"../_security/SipInspector/certificate.pem", NULL)
 SSL_CTX_use_PrivateKey_file(ctx, "../_security/client.pem", SSL_FILETYPE_PEM)
 SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback);
 SSL_CTX_set_verify_depth(ctx, 4);
 SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2);

And also I used the openssl verify command to double check the certificate 
against itself (not sure if this really does anything).

Any help would be appreciated.



Carl Heyendal | Software Developer 
1826 Robertson Road | Ottawa, ON K2H 5Z6 | CANADA
Office: +1 613-725-2980 x149





***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are 
hereby notified that any review, use, disclosure, dissemination, distribution 
or copying of this message and any attachments is strictly prohibited. If you 
have received this email in error, please immediately notify the sender and 
destroy this e-mail and any attachments and all copies, whether electronic or 
printed. Please also note that any views, opinions, conclusions or commitments 
expressed in this message are those of the individual sender and do not 
necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are 
not binding on Fortinet and only a writing manually signed by Fortinet's 
General Counsel can be a binding commitment of Fortinet to Fortinet's customers

Re: [openssl-users] cipher suite list

Re: [openssl-users] cipher suite list

[openssl-users] cipher suite list

Re: [openssl-users] [Newsletter] Re: Same openssl app behaves differently depending on platform

[openssl-users] Same openssl app behaves differently depending on platform

Re: [openssl-users] [Newsletter] Re: self-signed certificate won't work in my app but works with s_client

[openssl-users] self-signed certificate won't work in my app but works with s_client

7 matches

Site Navigation

Mail list logo

Footer information