Re: Help with SSL 8152 SEC_ERROR_INVALID_KEY Intermittent Error (first post please be kind!)

[Benjamin Kaduk via openssl-users]

Hi Craig,

On Wed, Dec 09, 2020 at 08:35:46PM +0900, Craig Henry wrote:
> Hi,
> 
> This is my first post to this list so please be kind!
> 
> Environment - Linux Centos
> SSL - 1.0.2k19-el7
> 
> Connection - CURL (via PHP) with public / private key auth + http basic auth
> 
> We're having an issue where we are seeing intermittent behavior connecting
> to a 3rd party of the key being rejected with a 8152 error - "The key does
> not support the requested operation". Other times it works OK.
> 
> We have another user who is using this 3rd party and same connection type
> but not reported this issue.
> 
> Has anyone got any clue as to what might be causing this type of
> intermittent connection issue ?

As was already noted, this is not an error generated by OpenSSL.
More concretely, RFC 8152 is for CBOR Object Signing and Encryption (COSE), 
which is not really
related to TLS at all.  I suspect the error is not from NSS or CURL either but
rather from a COSE implementation.

-Ben

Re: Help with SSL 8152 SEC_ERROR_INVALID_KEY Intermittent Error (first post please be kind!)

[Matt Caswell]

On 09/12/2020 11:35, Craig Henry wrote:
> Hi,
> 
> This is my first post to this list so please be kind!
> 
> Environment - Linux Centos
> SSL - 1.0.2k19-el7
> 
> Connection - CURL (via PHP) with public / private key auth + http basic auth
> 
> We're having an issue where we are seeing intermittent behavior
> connecting to a 3rd party of the key being rejected with a 8152 error -
> "The key does not support the requested operation". Other times it works
> OK.

That error does not come from OpenSSL. It appears to be an NSS error. So
I'd suggest asking on an NSS or CURL forum.

Matt



> 
> We have another user who is using this 3rd party and same connection
> type but not reported this issue.
> 
> Has anyone got any clue as to what might be causing this type of
> intermittent connection issue ?
> 
> The CURL logs are below but altered for privacy reasons.
> 
> Thanks
> 
> 
> 
> -Craig
> 
> 
> 
> 
> 
> 
> 
> *Key blocked response*
> 
> * About to connect() to  port 443 (#96)
> *   Trying XX
> * Connected to XX (X) port 443 (#96)
> *   CAfile: /X_tlstrust.pem
> 
>   CApath: none
> * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> * Server certificate:
> * subject: CN=XXX
> ,O=,L=Atlanta,ST=Georgia,C=US
> * start date: Jun 17 00:00:00 2020 GMT
> * expire date: Jun 18 12:00:00 2022 GMT
> * common name:  
> * issuer: CN=DigiCert Global CA G2,O=DigiCert Inc,C=US
> * Server auth using Basic with user ''
>> POST /XX/services HTTP/1.1
> Authorization: Basic X
> Host:  
> Accept: */*
> Content-Type:text/xml
> Content-Length: 1019
> 
> * upload completely sent off: 1019 out of 1019 bytes
> * NSS: client certificate from file
> * subject: CN=,OU=Buntingford,O=XX,C=DE
> * start date: Dec 03 10:01:35 2020 GMT
> * expire date: Dec 01 10:01:35 2030 GMT
> * common name: 
> * issuer: CN=XX ,O= GmbH,L=Bad
> Vilbel,ST=Hessen,C=DE
> * SSL read: errno -8152 (SEC_ERROR_INVALID_KEY)
> * The key does not support the requested operation.
> * Closing connection 96
> 
> 
> *Successful response*
> 
> * About to connect() to XX port 443 (#81)
> *   Trying xxx...
> * Connected to   (XX) port 443 (#81)
> *   CAfile:
> /X
>   CApath: none
> * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> * Server certificate:
> * subject: CN=www.
> ,O=XXn,L=Atlanta,ST=Georgia,C=US
> * start date: Jun 17 00:00:00 2020 GMT
> * expire date: Jun 18 12:00:00 2022 GMT
> * common name: XXX
> * issuer: CN=DigiCert Global CA G2,O=DigiCert Inc,C=US
> * Server auth using Basic with user 'X'
>> POST /X/services HTTP/1.1
> Authorization: Basic 
> Host: X 
> Accept: */*
> Content-Type:text/xml
> Content-Length: 1019
> 
> * upload completely sent off: 1019 out of 1019 bytes
> * NSS: client certificate from file
> * subject: CN=,OU=Buntingford,O=XX Ltd,C=DE
> * start date: Dec 03 10:01:35 2020 GMT
> * expire date: Dec 01 10:01:35 2030 GMT
> * common name:X
> * issuer: CN=X ,O=,L=Bad
> Vilbel,ST=Hessen,C=DE
> < HTTP/1.1 500
> < Date: Tue, 08 Dec 2020 13:42:26 GMT
> < Server: Apache
> < Strict-Transport-Security: max-age=63072000; includeSubdomains
> < X-XSS-Protection: 1; mode=block
> < X-Content-Type-Options: nosniff
> < Cache-Control: no-cache, no-store, must-revalidate
> < Pragma: no-cache
> < X-Frame-Options: SAMEORIGIN
> < Content-Security-Policy: default-src 'self' *.googleapis.com
>  *.klarna.com 
> *.masterpass.com  *.mastercard.com
>  *.npci.org.in  'unsafe-eval'
> 'unsafe-inline'; frame-ancestors 'self'
> < X-Application-Context: application:spring-boot,node-global,node-api:8843
> < Accept: text/xml, text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
> < SOAPAction: ""
> < Expires: 0
> < Content-Type: text/xml;charset=utf-8
> < Content-Length: 1481
> < Set-Cookie: JSESSIONID=8778DF260AA5C9E0AAB3E1E4C572453D.ipg_api_k8s;
> Path=/X; Secure; HttpOnly;HttpOnly;Secure;SameSite=Lax
> < Connection: close
> <
> * Closing connection 81
> 
> 
> 
> 
> 
> *Development Team*
> 
> *tassolutions *
> the attic | south suite | fullbridge mill | maldon | essex | cm9 4le | UK
> 
> *tel:*   +44 (0)1621 857785   -
> *www.tas-solutions.co.uk *
> 
> *Our business | support hours are Monday - 

Re: Help with SSL 8152 SEC_ERROR_INVALID_KEY Intermittent Error (first post please be kind!)

[Tomas Mraz]

Hi,

curl on RHEL-7 and Centos 7 uses NSS and not OpenSSL as the TLS
backend. So this is unfortunately a wrong mailing list to ask.

Tomas Mraz

On Wed, 2020-12-09 at 20:35 +0900, Craig Henry wrote:
> Hi,
> 
> This is my first post to this list so please be kind!
> 
> Environment - Linux Centos 
> SSL - 1.0.2k19-el7
> 
> Connection - CURL (via PHP) with public / private key auth + http
> basic auth
> 
> We're having an issue where we are seeing intermittent behavior
> connecting to a 3rd party of the key being rejected with a 8152 error
> - "The key does not support the requested operation". Other times it
> works OK. 
> 
> We have another user who is using this 3rd party and same connection
> type but not reported this issue. 
> 
> Has anyone got any clue as to what might be causing this type of
> intermittent connection issue ?
> 
> The CURL logs are below but altered for privacy reasons. 
> 
> Thanks
> 
> 
> 
> -Craig
> 
> 
> 
> 
> 
> 
> 
> Key blocked response
> 
> * About to connect() to  port 443 (#96)
> *   Trying XX
> * Connected to XX (X) port 443 (#96)
> *   CAfile: /X_tlstrust.pem
>   CApath: none
> * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> * Server certificate:
> * subject: CN=XXX,O=,L=Atlanta,ST=Georgia,C=US
> * start date: Jun 17 00:00:00 2020 GMT
> * expire date: Jun 18 12:00:00 2022 GMT
> * common name: 
> * issuer: CN=DigiCert Global CA G2,O=DigiCert Inc,C=US
> * Server auth using Basic with user ''
> > POST /XX/services HTTP/1.1
> Authorization: Basic X
> Host: 
> Accept: */*
> Content-Type:text/xml
> Content-Length: 1019
> 
> * upload completely sent off: 1019 out of 1019 bytes
> * NSS: client certificate from file
> * subject: CN=,OU=Buntingford,O=XX,C=DE
> * start date: Dec 03 10:01:35 2020 GMT
> * expire date: Dec 01 10:01:35 2030 GMT
> * common name: 
> * issuer: CN=XX,O= GmbH,L=Bad Vilbel,ST=Hessen,C=DE
> * SSL read: errno -8152 (SEC_ERROR_INVALID_KEY)
> * The key does not support the requested operation.
> * Closing connection 96
> 
> 
> Successful response
> 
> * About to connect() to XX port 443 (#81)
> *   Trying xxx...
> * Connected to  (XX) port 443 (#81)
> *   CAfile: /X
>   CApath: none
> * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> * Server certificate:
> * subject: CN=www.,O=XXn,L=Atlanta,ST=Georgia,C=US
> * start date: Jun 17 00:00:00 2020 GMT
> * expire date: Jun 18 12:00:00 2022 GMT
> * common name: XXX
> * issuer: CN=DigiCert Global CA G2,O=DigiCert Inc,C=US
> * Server auth using Basic with user 'X'
> > POST /X/services HTTP/1.1
> Authorization: Basic 
> Host: X
> Accept: */*
> Content-Type:text/xml
> Content-Length: 1019
> 
> * upload completely sent off: 1019 out of 1019 bytes
> * NSS: client certificate from file
> * subject: CN=,OU=Buntingford,O=XX Ltd,C=DE
> * start date: Dec 03 10:01:35 2020 GMT
> * expire date: Dec 01 10:01:35 2030 GMT
> * common name:X
> * issuer: CN=X,O=,L=Bad Vilbel,ST=Hessen,C=DE
> < HTTP/1.1 500 
> < Date: Tue, 08 Dec 2020 13:42:26 GMT
> < Server: Apache
> < Strict-Transport-Security: max-age=63072000; includeSubdomains
> < X-XSS-Protection: 1; mode=block
> < X-Content-Type-Options: nosniff
> < Cache-Control: no-cache, no-store, must-revalidate
> < Pragma: no-cache
> < X-Frame-Options: SAMEORIGIN
> < Content-Security-Policy: default-src 'self' *.googleapis.com
> *.klarna.com *.masterpass.com *.mastercard.com *.npci.org.in 'unsafe-
> eval' 'unsafe-inline'; frame-ancestors 'self'
> < X-Application-Context: application:spring-boot,node-global,node-
> api:8843
> < Accept: text/xml, text/html, image/gif, image/jpeg, *; q=.2, */*;
> q=.2
> < SOAPAction: ""
> < Expires: 0
> < Content-Type: text/xml;charset=utf-8
> < Content-Length: 1481
> < Set-Cookie:
> JSESSIONID=8778DF260AA5C9E0AAB3E1E4C572453D.ipg_api_k8s; Path=/X;
> Secure; HttpOnly;HttpOnly;Secure;SameSite=Lax
> < Connection: close
> < 
> * Closing connection 81
> 
> 
> 
> 
> 
> Development Team
> 
> tassolutions
> the attic | south suite | fullbridge mill | maldon | essex | cm9 4le
> | UK
> 
> tel:   +44 (0)1621 857785  - www.tas-solutions.co.uk
> 
> Our business | support hours are Monday - Friday 9.00am to 5.30pm
> 
> Offices are closed on all UK Bank Holidays.
> 
> Support outside these hours can be arranged on request.
> 
>
> 
> This E-mail and any attachments contain confidential and proprietary
> information of TAS Solutions Ltd and are intended only for the use of
> the person/s to whom it is addressed. If you have received this E-
> mail in error please immediately notify support by telephone on +44
> (0)1621 857785. Although this e-mail and any attachments are believed
> to be free of any virus, or other defect which might affect any
> computer or system into which they are received and 

Help with SSL 8152 SEC_ERROR_INVALID_KEY Intermittent Error (first post please be kind!)

[Craig Henry]

Hi,

This is my first post to this list so please be kind!

Environment - Linux Centos
SSL - 1.0.2k19-el7

Connection - CURL (via PHP) with public / private key auth + http basic auth

We're having an issue where we are seeing intermittent behavior connecting
to a 3rd party of the key being rejected with a 8152 error - "The key does
not support the requested operation". Other times it works OK.

We have another user who is using this 3rd party and same connection type
but not reported this issue.

Has anyone got any clue as to what might be causing this type of
intermittent connection issue ?

The CURL logs are below but altered for privacy reasons.

Thanks



-Craig







*Key blocked response*

* About to connect() to   port 443 (#96)
*   Trying XX
* Connected to XX (X) port 443 (#96)
*   CAfile: /X_tlstrust.pem

  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* subject: CN=XXX 
,O=,L=Atlanta,ST=Georgia,C=US
* start date: Jun 17 00:00:00 2020 GMT
* expire date: Jun 18 12:00:00 2022 GMT
* common name:  
* issuer: CN=DigiCert Global CA G2,O=DigiCert Inc,C=US
* Server auth using Basic with user ''
> POST /XX/services HTTP/1.1
Authorization: Basic X
Host:  
Accept: */*
Content-Type:text/xml
Content-Length: 1019

* upload completely sent off: 1019 out of 1019 bytes
* NSS: client certificate from file
* subject: CN=,OU=Buntingford,O=XX,C=DE
* start date: Dec 03 10:01:35 2020 GMT
* expire date: Dec 01 10:01:35 2030 GMT
* common name: 
* issuer: CN=XX ,O= GmbH,L=Bad
Vilbel,ST=Hessen,C=DE
* SSL read: errno -8152 (SEC_ERROR_INVALID_KEY)
* The key does not support the requested operation.
* Closing connection 96


*Successful response*

* About to connect() to XX port 443 (#81)
*   Trying xxx...
* Connected to   (XX) port 443 (#81)
*   CAfile: /X

  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* subject: CN=www. 
,O=XXn,L=Atlanta,ST=Georgia,C=US
* start date: Jun 17 00:00:00 2020 GMT
* expire date: Jun 18 12:00:00 2022 GMT
* common name: XXX
* issuer: CN=DigiCert Global CA G2,O=DigiCert Inc,C=US
* Server auth using Basic with user 'X'
> POST /X/services HTTP/1.1
Authorization: Basic 
Host: X 
Accept: */*
Content-Type:text/xml
Content-Length: 1019

* upload completely sent off: 1019 out of 1019 bytes
* NSS: client certificate from file
* subject: CN=,OU=Buntingford,O=XX Ltd,C=DE
* start date: Dec 03 10:01:35 2020 GMT
* expire date: Dec 01 10:01:35 2030 GMT
* common name:X
* issuer: CN=X ,O=,L=Bad
Vilbel,ST=Hessen,C=DE
< HTTP/1.1 500
< Date: Tue, 08 Dec 2020 13:42:26 GMT
< Server: Apache
< Strict-Transport-Security: max-age=63072000; includeSubdomains
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< Cache-Control: no-cache, no-store, must-revalidate
< Pragma: no-cache
< X-Frame-Options: SAMEORIGIN
< Content-Security-Policy: default-src 'self' *.googleapis.com *.klarna.com
*.masterpass.com *.mastercard.com *.npci.org.in 'unsafe-eval'
'unsafe-inline'; frame-ancestors 'self'
< X-Application-Context: application:spring-boot,node-global,node-api:8843
< Accept: text/xml, text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
< SOAPAction: ""
< Expires: 0
< Content-Type: text/xml;charset=utf-8
< Content-Length: 1481
< Set-Cookie: JSESSIONID=8778DF260AA5C9E0AAB3E1E4C572453D.ipg_api_k8s;
Path=/X; Secure; HttpOnly;HttpOnly;Secure;SameSite=Lax
< Connection: close
<
* Closing connection 81





*Development Team*

*tassolutions *
the attic | south suite | fullbridge mill | maldon | essex | cm9 4le | UK

*tel:*   +44 (0)1621 857785 <+44%201621%20857785>  - *www.tas-solutions.co.uk
*

*Our business | support hours are Monday - Friday 9.00am to 5.30pm*

Offices are closed on all UK Bank Holidays.

Support outside these hours can be arranged on request.





This E-mail and any attachments contain confidential and proprietary
information of TAS Solutions Ltd and are intended only for the use of the
person/s to whom it is addressed. If you have received this E-mail in error
please immediately notify support by telephone on 

Re: [openssl-users] Help with ssl error

[Viktor Dukhovni]

> On Apr 19, 2017, at 12:48 PM, Joseph Southwell  
> wrote:
> 
> Sorry we did do that. It just didn’t look different so I didn’t send it 
> (pasted below). I also have asked for help from the server admin but it is a 
> non English speaking country and they don’t seem to be interested in talking 
> to me. I have another product supposedly using OpenSSL that is currently 
> working fine so it must be possible. That product is using 0.9.8something.

The "0.9.8something" releases support RC4, 3DES, export ciphers, ...
OpenSSL 1.1.0 does not by default include any of these.  You can
get RC4 and 3DES by compiling with weak ciphers enabled, the EXPORT
ciphers are expunged from the code.

> So specifying -cipher "AES128-SHA” will cause it to not use DHE?

Yes, it will offer just that single ciphersuite "0x002f" and nothing
else.  If that does not work, the claim that the server supports RSA
with AES-128-CBC is not credible.

To find out what it does support, build OpenSSL 1.0.2, and try connecting
with that version of "s_client".

Another thing to try is sending an SNI name (-servername ...), perhaps
the server wants to see that, though it seems very unlikely for FTP.

You could also try restricting the protocol to TLS 1.0, perhaps the
server mishandles TLS 1.2 and/or TLS 1.1:

... -no_tls1_2 -no_tls1_1

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

Re: [openssl-users] Help with ssl error

[Joseph Southwell]

Sorry we did do that. It just didn’t look different so I didn’t send it (pasted 
below). I also have asked for help from the server admin but it is a non 
English speaking country and they don’t seem to be interested in talking to me. 
I have another product supposedly using OpenSSL that is currently working fine 
so it must be possible. That product is using 0.9.8something. So specifying 
-cipher "AES128-SHA” will cause it to not use DHE?

openssl s_client -state -msg -cipher "ALL" -connect 
ftp.echannel.banksys.be:16370 -starttls ftp
CONNECTED(0104)
SSL_connect:before SSL initialization
>>> ??? [length 0005]
16 03 01 00 f7
>>> TLS 1.2Handshake [length 00f7], ClientHello
01 00 00 f3 03 03 da ac 89 55 94 51 e0 ce 4b 3b
ec ee 33 fd 31 1f 75 f1 50 1a 50 73 09 07 5a 0e
cf 7d c3 ac 54 03 00 00 84 c0 2c c0 30 00 a3 00
9f cc a9 cc a8 cc aa c0 af c0 ad c0 a3 c0 9f c0
2b c0 2f 00 a2 00 9e c0 ae c0 ac c0 a2 c0 9e c0
24 c0 28 00 6b 00 6a c0 73 c0 77 00 c4 00 c3 c0
23 c0 27 00 67 00 40 c0 72 c0 76 00 be 00 bd c0
0a c0 14 00 39 00 38 00 88 00 87 c0 09 c0 13 00
33 00 32 00 9a 00 99 00 45 00 44 00 9d c0 a1 c0
9d 00 9c c0 a0 c0 9c 00 3d 00 c0 00 3c 00 ba 00
35 00 84 00 2f 00 96 00 41 00 07 00 ff 01 00 00
46 00 0b 00 04 03 00 01 02 00 0a 00 0a 00 08 00
1d 00 17 00 19 00 18 00 23 00 00 00 0d 00 20 00
1e 06 01 06 02 06 03 05 01 05 02 05 03 04 01 04
02 04 03 03 01 03 02 03 03 02 01 02 02 02 03 00
16 00 00 00 17 00 00
SSL_connect:SSLv3/TLS write client hello
<<< ??? [length 0005]
15 03 02 00 02
<<< TLS 1.2Alert [length 0002], fatal insufficient_security
02 47
SSL3 alert read:fatal:insufficient security
SSL_connect:error in SSLv3/TLS write client hello
2152:error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient 
security:ssl\record\rec_layer_s3.c:1385:SSL alert number 71

> On Apr 19, 2017, at 11:43 AM, Viktor Dukhovni  
> wrote:
> 
> On Tue, Apr 18, 2017 at 05:06:40PM +, Viktor Dukhovni wrote:
> 
>> The ClientHello decodes via tshark as:
>> 
>> [...]
>>Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
>>Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
>>Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
>>Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
>> [...]
>> 
>> This is a modern ClientHello (OpenSSL 1.1.0 it seems) and should
>> be broadly interoperable.  The DEFAULT cipherlist includes only
>> AES, is there a chance that the server only supports RC4 and/or
>> 3DES?
>> 
>> Try:
>> 
>>$ openssl s_client -state -msg -cipher ALL \
>>-connect ftp.echannel.banksys.be:16370 -starttls ftp
>> 
>> Capture a PCAP file of the traffic with
>> 
>># tcpdump -s0 -w /some/file tcp port 16370
>> 
>> and post the the decode from:
>> 
>>$ tshark -r /tmp/p2 -d tcp.port==16370,ssl -V |
>>sed -ne '/^Secure Sockets Layer/,/^$/p'
>> 
>> Or just attach the PCAP file to your follow-up message.
> 
> On Wed, Apr 19, 2017 at 10:53:27AM -0400, Joseph Southwell wrote:
> 
>> Is there a way to enable one or both of those ciphers in OpenSSL?
>> 
>>> On Apr 18, 2017, at 1:28 PM, Jason Schultz  wrote:
>>> 
>>> RSA_With_AES_128_CBC_SHA and RSA_With_3DES_EDE_CBC_SHA
> 
> With so many different names for the underlying TLS ciphersuites
> one can only guess which ones are the same.  That said, I'd say
> that the first one on your list is enabled by default, and was used
> in your TLS ClientHello (TLS_RSA_WITH_AES_128_CBC_SHA 0x002f).
> 
> It is possible that (despite any claims to the contrary) the server
> only supports the 3DES ciphersuite above, in which case you need
> either OpenSSL 1.0.2 or a build of OpenSSL 1.1.0 with the Configure
> option "--enable-weak-ssl-ciphers".   The 3DES TLS ciphers are by
> default disabled at compile-time in OpenSSL 1.1.0 and later.
> 
> I did suggest the "-cipher ALL" option as a first place to start to
> find out what the server actually supports.  I'm puzzled as to why
> you've not tried that yet.
> 
> A more exotic scenario is that the server is configured with a weak
> DHE group and having chosen DHE decides that the group is too weak.
> In that case you could try just the purported AES cipher:
> 
>   -cipher "AES128-SHA"
> 
> The name was obtained via:
> 
>$ openssl ciphers -V ALL | grep 0x00,0x2F
>  0x00,0x2F - AES128-SHA  SSLv3 Kx=RSA  Au=RSA  
> Enc=AES(128)  Mac=SHA1
> 
> Finally, you really should ask for help from the server administrator
> they should have useful data in their logs.
> 
> -- 
>   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] Help with ssl error

[Viktor Dukhovni]

On Tue, Apr 18, 2017 at 05:06:40PM +, Viktor Dukhovni wrote:

> The ClientHello decodes via tshark as:
> 
> [...]
> Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
> Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
> Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
> Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
> [...]
> 
> This is a modern ClientHello (OpenSSL 1.1.0 it seems) and should
> be broadly interoperable.  The DEFAULT cipherlist includes only
> AES, is there a chance that the server only supports RC4 and/or
> 3DES?
> 
> Try:
> 
> $ openssl s_client -state -msg -cipher ALL \
> -connect ftp.echannel.banksys.be:16370 -starttls ftp
> 
> Capture a PCAP file of the traffic with
> 
> # tcpdump -s0 -w /some/file tcp port 16370
> 
> and post the the decode from:
> 
> $ tshark -r /tmp/p2 -d tcp.port==16370,ssl -V |
> sed -ne '/^Secure Sockets Layer/,/^$/p'
> 
> Or just attach the PCAP file to your follow-up message.

On Wed, Apr 19, 2017 at 10:53:27AM -0400, Joseph Southwell wrote:

> Is there a way to enable one or both of those ciphers in OpenSSL?
> 
> > On Apr 18, 2017, at 1:28 PM, Jason Schultz  wrote:
> > 
> > RSA_With_AES_128_CBC_SHA and RSA_With_3DES_EDE_CBC_SHA

With so many different names for the underlying TLS ciphersuites
one can only guess which ones are the same.  That said, I'd say
that the first one on your list is enabled by default, and was used
in your TLS ClientHello (TLS_RSA_WITH_AES_128_CBC_SHA 0x002f).

It is possible that (despite any claims to the contrary) the server
only supports the 3DES ciphersuite above, in which case you need
either OpenSSL 1.0.2 or a build of OpenSSL 1.1.0 with the Configure
option "--enable-weak-ssl-ciphers".   The 3DES TLS ciphers are by
default disabled at compile-time in OpenSSL 1.1.0 and later.

I did suggest the "-cipher ALL" option as a first place to start to
find out what the server actually supports.  I'm puzzled as to why
you've not tried that yet.

A more exotic scenario is that the server is configured with a weak
DHE group and having chosen DHE decides that the group is too weak.
In that case you could try just the purported AES cipher:

-cipher "AES128-SHA"

The name was obtained via:

$ openssl ciphers -V ALL | grep 0x00,0x2F
  0x00,0x2F - AES128-SHA  SSLv3 Kx=RSA  Au=RSA  
Enc=AES(128)  Mac=SHA1

Finally, you really should ask for help from the server administrator
they should have useful data in their logs.

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

Re: [openssl-users] Help with ssl error

[Joseph Southwell]

Is there a way to enable one or both of those ciphers in OpenSSL?

> On Apr 18, 2017, at 1:28 PM, Jason Schultz  wrote:
> 
> RSA_With_AES_128_CBC_SHA and RSA_With_3DES_EDE_CBC_SHA

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

Re: [openssl-users] Help with ssl error

[Jason Schultz]

>From the original question, it appears the server here only supports two 
>cipher suites:

RSA_With_AES_128_CBC_SHA and RSA_With_3DES_EDE_CBC_SHA

This would explain the alert 71, which is the sent because there are no cipher 
suites in common.


From: openssl-users <openssl-users-boun...@openssl.org> on behalf of Viktor 
Dukhovni <openssl-us...@dukhovni.org>
Sent: Tuesday, April 18, 2017 5:06 PM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Help with ssl error

On Tue, Apr 18, 2017 at 11:17:48AM -0400, Joseph Southwell wrote:

> It doesn’t look like it requested a client certificate to me.

Correct, the server alert was returned immediately in response
to the TLS ClientHello.

> $ openssl s_client -state -msg -connect ftp.echannel.banksys.be:16370 
> -starttls ftp
> CONNECTED(0104)
> SSL_connect:before SSL initialization
> >>> ??? [length 0005]
> 16 03 01 00 ab
> >>> TLS 1.2Handshake [length 00ab], ClientHello
> 01 00 00 a7 03 03 b1 9d 3b a7 9d c4 3f de 8a 20
> 59 07 1f d7 50 3e 20 cf 92 cb a6 7d 94 1d 2f b2
> 81 c0 d9 12 1c f9 00 00 38 c0 2c c0 30 00 9f cc
> a9 cc a8 cc aa c0 2b c0 2f 00 9e c0 24 c0 28 00
> 6b c0 23 c0 27 00 67 c0 0a c0 14 00 39 c0 09 c0
> 13 00 33 00 9d 00 9c 00 3d 00 3c 00 35 00 2f 00
> ff 01 00 00 46 00 0b 00 04 03 00 01 02 00 0a 00
> 0a 00 08 00 1d 00 17 00 19 00 18 00 23 00 00 00
> 0d 00 20 00 1e 06 01 06 02 06 03 05 01 05 02 05
> 03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02
> 02 02 03 00 16 00 00 00 17 00 00
> SSL_connect:SSLv3/TLS write client hello
> <<< ??? [length 0005]
> 15 03 02 00 02
> <<< TLS 1.2Alert [length 0002], fatal insufficient_security
> 02 47
> SSL3 alert read:fatal:insufficient security
> SSL_connect:error in SSLv3/TLS write client hello
> 3252:error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient 
> security:ssl\record\rec_layer_s3.c:1385:SSL alert number 71

The ClientHello decodes via tshark as:

Secure Sockets Layer
SSL Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 171
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 167
Version: TLS 1.2 (0x0303)
Random
GMT Unix Time: Jun  5, 2064 16:07:35.0 AEST
Random Bytes: 
9dc43fde8a2059071fd7503e20cf92cba67d941d2fb281c0...
Session ID Length: 0
Cipher Suites Length: 56
Cipher Suites (28 suites)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
Cipher Suite: Unknown (0xcca9)
Cipher Suite: Unknown (0xcca8)
Cipher Suite: Unknown (0xccaa)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)
Extensions Length: 70
Extension: ec_point_formats
Type: ec_point_formats (0x000b)
 

Re: [openssl-users] Help with ssl error

[Viktor Dukhovni]

On Tue, Apr 18, 2017 at 11:17:48AM -0400, Joseph Southwell wrote:

> It doesn’t look like it requested a client certificate to me.

Correct, the server alert was returned immediately in response
to the TLS ClientHello.

> $ openssl s_client -state -msg -connect ftp.echannel.banksys.be:16370 
> -starttls ftp
> CONNECTED(0104)
> SSL_connect:before SSL initialization
> >>> ??? [length 0005]
> 16 03 01 00 ab
> >>> TLS 1.2Handshake [length 00ab], ClientHello
> 01 00 00 a7 03 03 b1 9d 3b a7 9d c4 3f de 8a 20
> 59 07 1f d7 50 3e 20 cf 92 cb a6 7d 94 1d 2f b2
> 81 c0 d9 12 1c f9 00 00 38 c0 2c c0 30 00 9f cc
> a9 cc a8 cc aa c0 2b c0 2f 00 9e c0 24 c0 28 00
> 6b c0 23 c0 27 00 67 c0 0a c0 14 00 39 c0 09 c0
> 13 00 33 00 9d 00 9c 00 3d 00 3c 00 35 00 2f 00
> ff 01 00 00 46 00 0b 00 04 03 00 01 02 00 0a 00
> 0a 00 08 00 1d 00 17 00 19 00 18 00 23 00 00 00
> 0d 00 20 00 1e 06 01 06 02 06 03 05 01 05 02 05
> 03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02
> 02 02 03 00 16 00 00 00 17 00 00
> SSL_connect:SSLv3/TLS write client hello
> <<< ??? [length 0005]
> 15 03 02 00 02
> <<< TLS 1.2Alert [length 0002], fatal insufficient_security
> 02 47
> SSL3 alert read:fatal:insufficient security
> SSL_connect:error in SSLv3/TLS write client hello
> 3252:error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient 
> security:ssl\record\rec_layer_s3.c:1385:SSL alert number 71

The ClientHello decodes via tshark as:

Secure Sockets Layer
SSL Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 171
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 167
Version: TLS 1.2 (0x0303)
Random
GMT Unix Time: Jun  5, 2064 16:07:35.0 AEST
Random Bytes: 
9dc43fde8a2059071fd7503e20cf92cba67d941d2fb281c0...
Session ID Length: 0
Cipher Suites Length: 56
Cipher Suites (28 suites)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
Cipher Suite: Unknown (0xcca9)
Cipher Suite: Unknown (0xcca8)
Cipher Suite: Unknown (0xccaa)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)
Extensions Length: 70
Extension: ec_point_formats
Type: ec_point_formats (0x000b)
Length: 4
EC point formats Length: 3
Elliptic curves point formats (3)
EC point format: uncompressed (0)
EC point format: ansiX962_compressed_prime (1)
EC point format: ansiX962_compressed_char2 (2)
Extension: elliptic_curves
Type: elliptic_curves (0x000a)
Length: 10
Elliptic Curves Length: 8
Elliptic curves (4 curves)
Elliptic curve: Unknown (0x001d)
Elliptic curve: secp256r1 (0x0017)
Elliptic curve: secp521r1 

Re: [openssl-users] Help with ssl error

[Joseph Southwell]

It doesn’t look like it requested a client certificate to me.

openssl110e>openssl s_client -state -msg -connect ftp.echannel.banksys.be:16370 
-starttls ftp
CONNECTED(0104)
SSL_connect:before SSL initialization
>>> ??? [length 0005]
16 03 01 00 ab
>>> TLS 1.2Handshake [length 00ab], ClientHello
01 00 00 a7 03 03 b1 9d 3b a7 9d c4 3f de 8a 20
59 07 1f d7 50 3e 20 cf 92 cb a6 7d 94 1d 2f b2
81 c0 d9 12 1c f9 00 00 38 c0 2c c0 30 00 9f cc
a9 cc a8 cc aa c0 2b c0 2f 00 9e c0 24 c0 28 00
6b c0 23 c0 27 00 67 c0 0a c0 14 00 39 c0 09 c0
13 00 33 00 9d 00 9c 00 3d 00 3c 00 35 00 2f 00
ff 01 00 00 46 00 0b 00 04 03 00 01 02 00 0a 00
0a 00 08 00 1d 00 17 00 19 00 18 00 23 00 00 00
0d 00 20 00 1e 06 01 06 02 06 03 05 01 05 02 05
03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02
02 02 03 00 16 00 00 00 17 00 00
SSL_connect:SSLv3/TLS write client hello
<<< ??? [length 0005]
15 03 02 00 02
<<< TLS 1.2Alert [length 0002], fatal insufficient_security
02 47
SSL3 alert read:fatal:insufficient security
SSL_connect:error in SSLv3/TLS write client hello
3252:error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient 
security:ssl\record\rec_layer_s3.c:1385:SSL alert number 71
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 88 bytes and written 186 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: 
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1492518024
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
 
> On Apr 14, 2017, at 2:49 PM, Viktor Dukhovni  
> wrote:
> 
> 
>> On Apr 14, 2017, at 9:48 AM, Joseph Southwell  
>> wrote:
>> 
>> Version 1.1 openssl
>> 
>> openssl.exe s_client -connect hostname:16370 -starttls ftp
>> 877788:error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient 
>> security:ssl\record\rec_layer_s3.c:1385:SSL alert number 71
> 
> The remote host sent an "insufficient security" TLS alert.
> 
>> The host I am connecting to apparently only supports the following 2 ciphers:
>> RSA_With_AES_128_CBC_SHA and RSA_With_3DES_EDE_CBC_SHA
>> 
>> What should I do to make this work?
> 
> Perhaps it is expecting a client certificate?  Retry with:
> 
> $ openssl s_client -state -msg -connect hostname:16370 -starttls ftp
> 
> and see whether it solicited a client certificate.
> 
> -- 
>   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] Help with ssl error

[Viktor Dukhovni]

> On Apr 14, 2017, at 9:48 AM, Joseph Southwell  
> wrote:
> 
> Version 1.1 openssl
> 
> openssl.exe s_client -connect hostname:16370 -starttls ftp
> 877788:error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient 
> security:ssl\record\rec_layer_s3.c:1385:SSL alert number 71

The remote host sent an "insufficient security" TLS alert.

> The host I am connecting to apparently only supports the following 2 ciphers:
> RSA_With_AES_128_CBC_SHA and RSA_With_3DES_EDE_CBC_SHA
> 
> What should I do to make this work?

Perhaps it is expecting a client certificate?  Retry with:

 $ openssl s_client -state -msg -connect hostname:16370 -starttls ftp

and see whether it solicited a client certificate.

-- 
Viktor.

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

[openssl-users] Help with ssl error

[Joseph Southwell]

Version 1.1 openssl

openssl.exe s_client -connect hostname:16370 -starttls ftp
CONNECTED(0104)
877788:error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient 
security:ssl\record\rec_layer_s3.c:1385:SSL alert number 71

The host I am connecting to apparently only supports the following 2 ciphers:
RSA_With_AES_128_CBC_SHA and RSA_With_3DES_EDE_CBC_SHA

What should I do to make this work?-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: Help diagnosing SSL connection problem needed

[Kyle Hamilton]

Your client is saying that it's failing the certificate verification of
the server certificate.  It's probably not using the CAfile that you
passed to openssl s_client.

-Kyle H

On 8/5/2014 12:19 PM, Ted Byers wrote:
 I have Perl code, which uses a library that in turn uses openssl for
 HTTPS connections.  I have been trying to use Wireshark to diagnose
 this, but I have yet to find a way to have it tell me what steps in
 the SSL handshaking are happening at a given time (client hello,
 server hello, c.).  Thus, I am having trouble seeing whether the
 problem is in my client not doing something right or the server not
 doing something right.  I have not yet figured out how to have it
 export everything in a capture file in plain text so that I could
 copy/paste it in a note like this so you could see for yourself what
 is happening.

 I did get openssl s_client to connect properly, and here is the output
 from that (sanitized of the server operator's ID):

 ted@linux-jp04:~/Work/Projects/FirstData openssl s_client -CAfile
 server-test.pem -cert client_test.pem -key client_test.key -connect
 n.n.n.n:8443
 CONNECTED(0003)
 depth=1 C = LV, ST = Latvia, L = Riga, O = xx, CN =
 server-test, emailAddress = webmas...@xx.xxx
 verify return:1
 depth=0 C = LV, O = FDL, CN = lv-rtps-proxy-test.ne.1dc.com
 verify return:1
 ---
 Certificate chain
  0 s:/C=LV/O=FDL/CN=lv-rtps-proxy-test.ne.1dc.com

 i:/C=LV/ST=Latvia/L=Riga/O=xx/CN=server-test/emailAddress=webmas...@xx.xxx
  1 
 s:/C=LV/ST=Latvia/L=Riga/O=xx/CN=server-test/emailAddress=webmas...@xx.xxx

 i:/C=LV/ST=Latvia/L=Riga/O=xx/CN=server-test/emailAddress=webmas...@xx.xxx
 ---
 Server certificate
 -BEGIN CERTIFICATE-
 DELETED
 -END CERTIFICATE-
 subject=/C=LV/O=FDL/CN=lv-rtps-proxy-test.ne.1dc.com
 issuer=/C=LV/ST=Latvia/L=Riga/O=xx/CN=server-test/emailAddress=webmas...@xx.xxx
 ---
 Acceptable client certificate CA names
 /C=LV/ST=Latvia/L=Riga/O=xx/CN=server-test/emailAddress=webmas...@xx.xxx
 /C=LV/O=FDL/CN=lv-rtps-proxy-test.ne.1dc.com
 ---
 SSL handshake has read 3690 bytes and written 3700 bytes
 ---
 New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
 Server public key is 2048 bit
 Secure Renegotiation IS supported
 Compression: NONE
 Expansion: NONE
 SSL-Session:
 Protocol  : TLSv1
 Cipher: EDH-RSA-DES-CBC3-SHA
 Session-ID: 
 53E0DE54D7D7E928F177883E10447786C15133386DA3F0489796845673C70DEA
 Session-ID-ctx:
 Master-Key: DELETED
 Key-Arg   : None
 PSK identity: None
 PSK identity hint: None
 SRP username: None
 Start Time: 1407245906
 Timeout   : 300 (sec)
 Verify return code: 0 (ok)
 ---

 closed
 ted@linux-jp04:~/Work/Projects/FirstData


 Now, here is the output I get from my Perl client (also sanitized):

 $url = https://n.n.n.n:8443/
 $scheme = https
 $self-{ssl_set} = 0
 $self-{ca_cert_dir} = .
 $self-{ca_cert_file} = server-test.pem
 $LWP::VERSION = 6.05
 Setting cert dir and file if available
 $self-{ssl_set} = 1
 DEBUG: .../IO/Socket/SSL.pm:2503: new ctx 26349088
 DEBUG: .../IO/Socket/SSL.pm:526: socket not yet connected
 DEBUG: .../IO/Socket/SSL.pm:528: socket connected
 DEBUG: .../IO/Socket/SSL.pm:550: ssl handshake not started
 DEBUG: .../IO/Socket/SSL.pm:586: not using SNI because hostname is unknown
 DEBUG: .../IO/Socket/SSL.pm:634: set socket to non-blocking to enforce
 timeout=180
 DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect - -1
 DEBUG: .../IO/Socket/SSL.pm:657: ssl handshake in progress
 DEBUG: .../IO/Socket/SSL.pm:667: waiting for fd to become ready: SSL
 wants a read first
 DEBUG: .../IO/Socket/SSL.pm:687: socket ready, retrying connect
 DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect - -1
 DEBUG: .../IO/Socket/SSL.pm:657: ssl handshake in progress
 DEBUG: .../IO/Socket/SSL.pm:667: waiting for fd to become ready: SSL
 wants a read first
 DEBUG: .../IO/Socket/SSL.pm:687: socket ready, retrying connect
 DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect - -1
 DEBUG: .../IO/Socket/SSL.pm:657: ssl handshake in progress
 DEBUG: .../IO/Socket/SSL.pm:667: waiting for fd to become ready: SSL
 wants a read first
 DEBUG: .../IO/Socket/SSL.pm:687: socket ready, retrying connect
 DEBUG: .../IO/Socket/SSL.pm:2384: ok=1 cert=26317968
 DEBUG: .../IO/Socket/SSL.pm:2384: ok=1 cert=26323136
 DEBUG: .../IO/Socket/SSL.pm:1539: scheme=www cert=26323136
 DEBUG: .../IO/Socket/SSL.pm:1549: identity=n.n.n.n
 cn=lv-rtps-proxy-test.ne.1dc.com alt=
 DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect - -1
 DEBUG: .../IO/Socket/SSL.pm:1757: SSL connect attempt failed

 DEBUG: .../IO/Socket/SSL.pm:653: fatal SSL error: SSL connect attempt
 failed error:14090086:SSL
 

Re: Help diagnosing SSL connection problem needed

[Ted Byers]

Hi Kyle,

Thanks

See  below

On Thu, Aug 7, 2014 at 4:47 PM, Kyle Hamilton aerow...@gmail.com wrote:
 Your client is saying that it's failing the certificate verification of
 the server certificate.  It's probably not using the CAfile that you
 passed to openssl s_client.

 -Kyle H


Actually, I can confirm that it is using the same CAfile that is used
by my call to openssl s_client.  But, it doesn't get that far, as it
appears the server is not sending it's certificate.

I assume Wireshark can be helpful, but I an very new to using it.  Can
you tell me how to tell it to look at any traffic on port 8443 (or
between my workstation and a specific ip address), as well as to let
me see the data in plain text rather than hex?

Thanks

Ted

-- 
R.E.(Ted) Byers, Ph.D.,Ed.D.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Help diagnosing SSL connection problem needed

[Dave Thompson]

 From: owner-openssl-us...@openssl.org On Behalf Of Kyle Hamilton
 Sent: Thursday, August 07, 2014 16:48

 Your client is saying that it's failing the certificate verification of
 the server certificate.  It's probably not using the CAfile that you
 passed to openssl s_client.
 
 -Kyle H
 
 On 8/5/2014 12:19 PM, Ted Byers wrote:
  I have Perl code, which uses a library that in turn uses openssl for
  HTTPS connections.  I have been trying to use Wireshark to diagnose
  this, but I have yet to find a way to have it tell me what steps in
  the SSL handshaking are happening at a given time (client hello,
  server hello, c.).  Thus, I am having trouble seeing whether the
  problem is in my client not doing something right or the server not
  doing something right.  I have not yet figured out how to have it
  export everything in a capture file in plain text so that I could
  copy/paste it in a note like this so you could see for yourself what
  is happening.
 
About Wireshark: first make sure you have only the desired packets 
displayed: filter the display unless you previously filtered the capture 
or you were (very) lucky and nothing else happened during the capture.

For everything, which is a lot (usually too much), File / Print 
plainText toFile (and specify filename), range: Allpackets Displayed, 
format: summary on, details on all expanded, bytes off.

For just which handshake steps have occurred, same except details off.

  I did get openssl s_client to connect properly, and here is the output
  from that (sanitized of the server operator's ID):
 
  ted@linux-jp04:~/Work/Projects/FirstData openssl s_client -CAfile
  server-test.pem -cert client_test.pem -key client_test.key -connect
  n.n.n.n:8443
snip except
  Server certificate
  -BEGIN CERTIFICATE-
  DELETED
  -END CERTIFICATE-
  subject=/C=LV/O=FDL/CN=lv-rtps-proxy-test.ne.1dc.com

  Now, here is the output I get from my Perl client (also sanitized):
 
  $url = https://n.n.n.n:8443/
  $scheme = https
  $self-{ssl_set} = 0
  $self-{ca_cert_dir} = .
  $self-{ca_cert_file} = server-test.pem
  $LWP::VERSION = 6.05
  Setting cert dir and file if available
  $self-{ssl_set} = 1

Are you setting the client keycert/chain? This doesn't indicate it.
The s_client command did provide them, and the server did request 
a client cert; if the server *requires* client cert and client doesn't 
provide one, the server will normally reject the connection.

  DEBUG: .../IO/Socket/SSL.pm:2503: new ctx 26349088
  DEBUG: .../IO/Socket/SSL.pm:526: socket not yet connected
  DEBUG: .../IO/Socket/SSL.pm:528: socket connected
  DEBUG: .../IO/Socket/SSL.pm:550: ssl handshake not started
  DEBUG: .../IO/Socket/SSL.pm:586: not using SNI because hostname is
 unknown
  DEBUG: .../IO/Socket/SSL.pm:634: set socket to non-blocking to enforce
  timeout=180
  DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect - -1
  DEBUG: .../IO/Socket/SSL.pm:657: ssl handshake in progress
  DEBUG: .../IO/Socket/SSL.pm:667: waiting for fd to become ready: SSL
  wants a read first

This appears to be sent CHello, nonblocking expect SHello,Cert...SDone

  DEBUG: .../IO/Socket/SSL.pm:687: socket ready, retrying connect
  DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect - -1
  DEBUG: .../IO/Socket/SSL.pm:657: ssl handshake in progress
  DEBUG: .../IO/Socket/SSL.pm:667: waiting for fd to become ready: SSL
  wants a read first
  DEBUG: .../IO/Socket/SSL.pm:687: socket ready, retrying connect
  DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect - -1
  DEBUG: .../IO/Socket/SSL.pm:657: ssl handshake in progress
  DEBUG: .../IO/Socket/SSL.pm:667: waiting for fd to become ready: SSL
  wants a read first

These two look like partial reads therefore expecting more

  DEBUG: .../IO/Socket/SSL.pm:687: socket ready, retrying connect
  DEBUG: .../IO/Socket/SSL.pm:2384: ok=1 cert=26317968
  DEBUG: .../IO/Socket/SSL.pm:2384: ok=1 cert=26323136

Those look like verify-callback; verify of the cert looks okay.

  DEBUG: .../IO/Socket/SSL.pm:1539: scheme=www cert=26323136
  DEBUG: .../IO/Socket/SSL.pm:1549: identity=n.n.n.n
  cn=lv-rtps-proxy-test.ne.1dc.com alt=

Those look like hostname check, which openssl doesn't do yet 
(1.0.2 will) but your perl library probably adds. If you used an IP form 
URL as indicated above https://a.b.c.d:8443/ and the cert has only 
domainname as is common and indicated here, then this should fail.
It is requirement of HTTPS (and some other *S protocols but not 
SSL/TLS by itself) that the authority field in the URL matches *a* 
name in the cert. That doesn't necessarliy mean only one name;
the/a cert name can be a wildcard that matches multiple hostnames 
but yours isn't; there can be multiple names in the cert using Subject 
Alternative Names, but I take alt= here to mean yours doesn't.

  DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect - -1
  DEBUG: .../IO/Socket/SSL.pm:1757: SSL 

Help diagnosing SSL connection problem needed

[Ted Byers]

I have Perl code, which uses a library that in turn uses openssl for
HTTPS connections.  I have been trying to use Wireshark to diagnose
this, but I have yet to find a way to have it tell me what steps in
the SSL handshaking are happening at a given time (client hello,
server hello, c.).  Thus, I am having trouble seeing whether the
problem is in my client not doing something right or the server not
doing something right.  I have not yet figured out how to have it
export everything in a capture file in plain text so that I could
copy/paste it in a note like this so you could see for yourself what
is happening.

I did get openssl s_client to connect properly, and here is the output
from that (sanitized of the server operator's ID):

ted@linux-jp04:~/Work/Projects/FirstData openssl s_client -CAfile
server-test.pem -cert client_test.pem -key client_test.key -connect
n.n.n.n:8443
CONNECTED(0003)
depth=1 C = LV, ST = Latvia, L = Riga, O = xx, CN =
server-test, emailAddress = webmas...@xx.xxx
verify return:1
depth=0 C = LV, O = FDL, CN = lv-rtps-proxy-test.ne.1dc.com
verify return:1
---
Certificate chain
 0 s:/C=LV/O=FDL/CN=lv-rtps-proxy-test.ne.1dc.com
   
i:/C=LV/ST=Latvia/L=Riga/O=xx/CN=server-test/emailAddress=webmas...@xx.xxx
 1 
s:/C=LV/ST=Latvia/L=Riga/O=xx/CN=server-test/emailAddress=webmas...@xx.xxx
   
i:/C=LV/ST=Latvia/L=Riga/O=xx/CN=server-test/emailAddress=webmas...@xx.xxx
---
Server certificate
-BEGIN CERTIFICATE-
DELETED
-END CERTIFICATE-
subject=/C=LV/O=FDL/CN=lv-rtps-proxy-test.ne.1dc.com
issuer=/C=LV/ST=Latvia/L=Riga/O=xx/CN=server-test/emailAddress=webmas...@xx.xxx
---
Acceptable client certificate CA names
/C=LV/ST=Latvia/L=Riga/O=xx/CN=server-test/emailAddress=webmas...@xx.xxx
/C=LV/O=FDL/CN=lv-rtps-proxy-test.ne.1dc.com
---
SSL handshake has read 3690 bytes and written 3700 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1
Cipher: EDH-RSA-DES-CBC3-SHA
Session-ID: 53E0DE54D7D7E928F177883E10447786C15133386DA3F0489796845673C70DEA
Session-ID-ctx:
Master-Key: DELETED
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1407245906
Timeout   : 300 (sec)
Verify return code: 0 (ok)
---

closed
ted@linux-jp04:~/Work/Projects/FirstData


Now, here is the output I get from my Perl client (also sanitized):

$url = https://n.n.n.n:8443/
$scheme = https
$self-{ssl_set} = 0
$self-{ca_cert_dir} = .
$self-{ca_cert_file} = server-test.pem
$LWP::VERSION = 6.05
Setting cert dir and file if available
$self-{ssl_set} = 1
DEBUG: .../IO/Socket/SSL.pm:2503: new ctx 26349088
DEBUG: .../IO/Socket/SSL.pm:526: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:528: socket connected
DEBUG: .../IO/Socket/SSL.pm:550: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:586: not using SNI because hostname is unknown
DEBUG: .../IO/Socket/SSL.pm:634: set socket to non-blocking to enforce
timeout=180
DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect - -1
DEBUG: .../IO/Socket/SSL.pm:657: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:667: waiting for fd to become ready: SSL
wants a read first
DEBUG: .../IO/Socket/SSL.pm:687: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect - -1
DEBUG: .../IO/Socket/SSL.pm:657: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:667: waiting for fd to become ready: SSL
wants a read first
DEBUG: .../IO/Socket/SSL.pm:687: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect - -1
DEBUG: .../IO/Socket/SSL.pm:657: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:667: waiting for fd to become ready: SSL
wants a read first
DEBUG: .../IO/Socket/SSL.pm:687: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:2384: ok=1 cert=26317968
DEBUG: .../IO/Socket/SSL.pm:2384: ok=1 cert=26323136
DEBUG: .../IO/Socket/SSL.pm:1539: scheme=www cert=26323136
DEBUG: .../IO/Socket/SSL.pm:1549: identity=n.n.n.n
cn=lv-rtps-proxy-test.ne.1dc.com alt=
DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect - -1
DEBUG: .../IO/Socket/SSL.pm:1757: SSL connect attempt failed

DEBUG: .../IO/Socket/SSL.pm:653: fatal SSL error: SSL connect attempt
failed error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
DEBUG: .../IO/Socket/SSL.pm:2537: free ctx 26349088 open=26349088
DEBUG: .../IO/Socket/SSL.pm:2542: free ctx 26349088 callback
DEBUG: .../IO/Socket/SSL.pm:2549: OK free ctx 26349088
2014/08/05 10:03:05 [http client] communication error: 500 Can't
connect to n.n.n.n:8443 (certificate verify failed)
500 Can't 

Re: Help Needed: SSL Connect starting from a weird state

[Jeff Saremi]

My initial analysis of this was very misleading. I have to apologize for
that.
The problem was that during the first part of the handshake
(clienthello), the call failed without anything being written out.
Tracing ssl23_client_hello() in s23_clnt.c showed that the following
statement returned false and as a result -1 was returned as the error.
if (RAND_pseudo_bytes(...) =0)
  return -1;

And for any instances of error for which an internal OpenSSL ERR is not
set, SSL_ERROR_SYSCALL is used, which is further misleading.

I did a cursory search of anywhere that a call to RAND_pseudo_bytes can
fail and there are tens of such instances for which OpenSSL ERR is not
set. In fact, there's only one instance of a call to RANDerr which is
inside md_rand.c. I guess this would be something for OpenSSL guys to
ponder.

Another strange thing is no matter how many times we ran the
application, the call always failed on the same spot; the same call to
RAND_pseudo_byes each time, not before or after. This was regardless of
how many successful calls were made prior to.

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

Help Needed: SSL Connect starting from a weird state

[Jeff Saremi]

We've been running our SSL code for a while now with no issues. But
recently one of our developers started encountering this problem.
We did the best we could to troubleshoot to no avail. I know the 
problem is not OpenSSL and it's something we're doing incorrectly,
probably at the start up.

The problem:
SSL completed without having done a single send or receive during the
handshake.

What we get in the print out, after issuing SSL_connect() is this:

Printout:
18:13:56.925 [4228] connect
18:13:56.927 [4228] SSL nonblock rc:-1 shutdown:0 state:23WCHA
(from:UNKWN )
18:13:56.928 [4228] ssl_err:5 SSL_ERROR_SYSCALL

The rough version of the code printing the above is this:
printf(connect\n);
const char *fromState = SSL_state_string(mSsl);
rc = SSL_connect(mSsl);
printf(SSL nonblock rc:%d shutdown:%d state:%s (from:%s)\n,
rc,
SSL_get_shutdown(mSsl),
SSL_state_string(mSsl),
fromState);
int ssl_error = SSL_get_error(mSsl, rc);
switch(ssl_error)
{
case SSL_ERROR_SYSCALL:
  printf(%d SSL_ERROR_SYSCALL\n, SSL_ERROR_SYSCALL);
...


What I would expect to see would be something along the lines of the
following:

SSL nonblock rc:1 shutdown:0 state:SSLOK (from:UNKWN )

or
SSL nonblock rc:-1 shutdown:0 state:SSLOK (from:SSLOK )


For additional debugging I have enabled callbacks using the following
too:
SSL_set_msg_callback

And I see a lot of that happening but not in this case.
In this particular case, after switching the destination IP and port all
we get is what I showed you. Not even one single byte is exchanged
anywhere.

Looking inside ssl_stat.c I see the following:
case SSL23_ST_CW_CLNT_HELLO_A:  str=23WCHA; break;

Looking inside s23_clnt.c I see these lines near the beginning of
ssl23_client_hello():

buf=(unsigned char *)s-init_buf-data;
if (s-state == SSL23_ST_CW_CLNT_HELLO_A)

How can my code start in this state?

Any hints would be appreciated.
thanks
jeff

help about ssl access with openssl cert.

[Buddy wu]

I use openssl to sign the cert.
and I've setuped a ca
req a cert for my webserver, and sign with this ca, name with
server.crt(cert file) and server.key(key file)

configured the apache to use ssl, and the cert file.

now I can access this ssl web site with firefox 3.0
but I can't access this ssl web site with IE. after I select the
client cert,and agree to trust the server sert, the errors displays:
can't display the pages (this is transtlate by me, I don't know the
orginal english message should be)

but I can use a cert not sign with the new ca i just created,(create
by another program). both IE and Firefox can access the ssl site.

what's the problem?? and how to resolve it?
thanks
buddy
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Help in ssl

[Terry Richardson]

Hi,

 

I have hosting account with Powweb (call4save.com) and need to install
my own ssl certificate.

I have already signed certificate (CSR) from godaddy .

May you please help.

Tell me the price you'll take to configure my own ssl for me.

 

Regards

Terry Richardson

Re: Help in ssl

[Victor Duchovni]

On Sun, Mar 09, 2008 at 10:57:01PM -0400, Terry Richardson wrote:

 I have hosting account with Powweb (call4save.com) and need to install
 my own ssl certificate.
 
 I have already signed certificate (CSR) from godaddy .
 
 May you please help.
 
 Tell me the price you'll take to configure my own ssl for me.

You were directed here in error. This is not the right place to ask.
Good luck.

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

RE: Need help: Understanding SSL object in multi-threaded environment

[Mark]

Kyle,

Thanks for your long and detailed response. 

 OpenSSL can protect its internal state by employing locks on the
 things that are interface-opaque.  It cannot protect its transparent
 state, especially as things other than OpenSSL that just happen to
 know how the interface works may not use the same locking services.
 This is why the requirement is pushed to the user to do thread-safety
 in these situations.
 
 SSL_read() can update the write state.  SSL_write() can update the
 read state.  All of the SSL_*() functions are thread-unprotected
 within the library -- but, as long as you ensure that there's no
 concurrent access to the SSL object, you can make use of it in
 multiple threads.  You just have to make sure it's never used in
 multiple threads *simultaneously*, because if that occurs the SSL
 layer WILL throw a fatal alert (decryption failure, bad_hmac, or bad
 sequence).
 
 So, the condensed version is: If you don't use SSL objects in more
 than one thread, you don't need to lock them -- so why should OpenSSL
 take the time and waste the resources to lock them (and risk resource
 exhaustion for the entire application)?  If you do use SSL objects in
 more than one thread, you do need to lock them. That is the same type
 of requirement pushed onto EVERY multithreaded application that needs
 to directly access the same data from multiple threads -- which
 implies that you know that you need the locks, and thus must provide
 them.  (If there's a helper function that does the reading or writing
 itself, you can just do the lock and unlock there.)
 
 I hope this helps.

Yes.  Thanks.

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

Re: Need help: Understanding SSL object in multi-threaded environment

[Kyle Hamilton]

On 10/6/06, Mark [EMAIL PROTECTED] wrote:

David,

  I assume this a reason why OpenSSL has the locking callback
 functions.

 No. OpenSSL has the locking callback functions so it can
 protect internal
 structures. For example, if two SSL objects internally reference the
 objects.

I am still confused as to why the locking callbacks would protect
internal
structures but not allow access of the SSL objects from different
threads
at the same time (i.e. SSL_read() and SSL_write()).


Let's imagine the case of an SSL_CTX being called in two separate
threads to add certificates and keys -- one RSA, one DSA.  (this is,
of course, not currently implemented to my knowledge, but this is an
example.)  The SSL_CTX functions, since they access the certificate
chains and key structures internally, can lock the chains and key
structures.  They don't directly modify the state of the SSL_CTX,
since the SSL_CTX is merely a set of pointers to other objects.

The SSL object is a different matter.  The SSL object contains more
than just pointers, it contains information on what the sequence
numbers are for the incoming and outgoing streams.  While OpenSSL
/could/ theoretically lock these itself, it would be a huge waste of
time and resources (locks tend to be a 'limited resource').for every
multithreaded OpenSSL application to abuse the OS's locking system
when it's otherwise unnecessary.



  As long as you use these it is safe to share the object AFAIK.

 Then when wouldn't it be safe to share the object? The
 locking callback functions are required for all multithreaded
applications or
 else OpenSSL can't protect its internal state.

Sorry. I'm not sure what you are saying here.


OpenSSL can protect its internal state by employing locks on the
things that are interface-opaque.  It cannot protect its transparent
state, especially as things other than OpenSSL that just happen to
know how the interface works may not use the same locking services.
This is why the requirement is pushed to the user to do thread-safety
in these situations.

SSL_read() can update the write state.  SSL_write() can update the
read state.  All of the SSL_*() functions are thread-unprotected
within the library -- but, as long as you ensure that there's no
concurrent access to the SSL object, you can make use of it in
multiple threads.  You just have to make sure it's never used in
multiple threads *simultaneously*, because if that occurs the SSL
layer WILL throw a fatal alert (decryption failure, bad_hmac, or bad
sequence).

So, the condensed version is: If you don't use SSL objects in more
than one thread, you don't need to lock them -- so why should OpenSSL
take the time and waste the resources to lock them (and risk resource
exhaustion for the entire application)?  If you do use SSL objects in
more than one thread, you do need to lock them. That is the same type
of requirement pushed onto EVERY multithreaded application that needs
to directly access the same data from multiple threads -- which
implies that you know that you need the locks, and thus must provide
them.  (If there's a helper function that does the reading or writing
itself, you can just do the lock and unlock there.)

I hope this helps.

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

RE: Need help: Understanding SSL object in multi-threaded environment

[Mark]

David, 

  I assume this a reason why OpenSSL has the locking callback 
 functions.
 
 No. OpenSSL has the locking callback functions so it can 
 protect internal
 structures. For example, if two SSL objects internally reference the
 objects.

I am still confused as to why the locking callbacks would protect
internal
structures but not allow access of the SSL objects from different
threads
at the same time (i.e. SSL_read() and SSL_write()).  
 
  As long as you use these it is safe to share the object AFAIK.
 
 Then when wouldn't it be safe to share the object? The 
 locking callback functions are required for all multithreaded
applications or 
 else OpenSSL can't protect its internal state.

Sorry. I'm not sure what you are saying here.

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

RE: Need help: Understanding SSL object in multi-threaded environment

[Mark]

David,

 I'm not sure why more internal details of how OpenSSL works would be
 helpful. I've already explained the external interface.

I think it would be helpful for me.  If we need to prevent calling
SSL functions on the same object (i.e. SSL_read() and SSL_write())
from different threads then I would think that OpenSSL would not need
any internal synchronisation, unless it creates its own threads
internally.
 
Cheers,
Mark
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Need help: Understanding SSL object in multi-threaded environment

[Darryl Miles]

Mark wrote:

I think it would be helpful for me.  If we need to prevent calling
SSL functions on the same object (i.e. SSL_read() and SSL_write())
from different threads then I would think that OpenSSL would not need
any internal synchronisation, unless it creates its own threads
internally.


But you are allowed to have multiple threads each having their own SSL * 
instance.  You are allowed to make SSL_x() calls on two different 
SSL * handles at the same time.


The internal locking protects operations happening upon different 
handles simultaneously.  For example there is an SSL session cache that 
can be shared between multiple SSL handles.  Another example is the use 
of SSL_CTX being used to stamp out new SSL *.  It is allowed for your 
application to allocate SSL_new(SSL_CTX *) from two threads at the same 
time, yadda, yadda.


But the SSL_() API set is not re-entrant with respect of the same 
SSL * handle.  So you have to serialize all API calls upon the same SSL 
* handle.  This is why you can't mix SSL_read() with any other 
SSL_() API call on the same handle instance at the same time.


Darryl

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

RE: Need help: Understanding SSL object in multi-threaded environment

[Mark]

Darryl, 

 But the SSL_() API set is not re-entrant with respect of the same 
 SSL * handle.  So you have to serialize all API calls upon 
 the same SSL 
 * handle.  This is why you can't mix SSL_read() with any other 
 SSL_() API call on the same handle instance at the same time.

I think the confusion really lies (for me anyway) in the documentation,
which is not clear which API functions need synchronising from the
application.

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

Re: Need help: Understanding SSL object in multi-threaded environment

[Urjit Gokhale]

- Original Message - 
From: Darryl Miles [EMAIL PROTECTED]
To: openssl-users@openssl.org
Sent: Friday, October 06, 2006 4:50 PM
Subject: Re: Need help: Understanding SSL object in multi-threaded
environment


 Mark wrote:
  I think it would be helpful for me.  If we need to prevent calling
  SSL functions on the same object (i.e. SSL_read() and SSL_write())
  from different threads then I would think that OpenSSL would not need
  any internal synchronisation, unless it creates its own threads
  internally.

 But you are allowed to have multiple threads each having their own SSL *
 instance.  You are allowed to make SSL_x() calls on two different
 SSL * handles at the same time.

 The internal locking protects operations happening upon different
 handles simultaneously.  For example there is an SSL session cache that
 can be shared between multiple SSL handles.  Another example is the use
 of SSL_CTX being used to stamp out new SSL *.  It is allowed for your
 application to allocate SSL_new(SSL_CTX *) from two threads at the same
 time, yadda, yadda.

 But the SSL_() API set is not re-entrant with respect of the same
 SSL * handle.  So you have to serialize all API calls upon the same SSL
 * handle.  This is why you can't mix SSL_read() with any other
 SSL_() API call on the same handle instance at the same time.

 Darryl

Thank you very much everybody for your responses.
The things are becoming more clear with these discussions.

~ Urjit


DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Persistent Systems Pvt. Ltd. It is intended only for the use of the 
individual or entity to which it is addressed. If you are not the intended 
recipient, you are not authorized to read, retain, copy, print, distribute or 
use this message. If you have received this communication in error, please 
notify the sender and delete all copies of this message. Persistent Systems 
Pvt. Ltd. does not accept any liability for virus infected mails.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Need help: Understanding SSL object in multi-threaded environment

[David Schwartz]

 David,

   I assume this a reason why OpenSSL has the locking callback
   functions.

  No. OpenSSL has the locking callback functions so it can
  protect internal
  structures. For example, if two SSL objects internally reference the
  objects.

 I am still confused as to why the locking callbacks would protect
 internal
 structures but not allow access of the SSL objects from different
 threads
 at the same time (i.e. SSL_read() and SSL_write()).

Because that's how OpenSSL is coded. This is pretty much the same as every
other library.

   As long as you use these it is safe to share the object AFAIK.
 
  Then when wouldn't it be safe to share the object? The
  locking callback functions are required for all multithreaded
  applications or
  else OpenSSL can't protect its internal state.

 Sorry. I'm not sure what you are saying here.

I don't know how I can be clearer. OpenSSL uses the locking functions to
protect its own state from corruption that the application can't easily
anticipate.

This is the same as pretty much every other library, so I'm not sure why
it's so confusing. For example, a string library will typically not allow
you to modify a string in one thread while you're accessing that same string
in the other thread. However, if the string library internally uses a
private memory pool, it will use its own locks to make that safe, so you can
assign a new value to two different string objects at the same time and the
private memory pool won't be corrupted.

Every sophisticated library that supports multi-threaded access has to draw
the balance somewhere. The usual rule is that the caller has to lock
anything that's obviously visible to it (such as concurrent use of the same
high-level object) and the library handles locking on anything not visible
to the caller (such as concurrent use of some internal library detail the
caller isn't supposed to have to know about).

OpenSSL's session cache is an internal detail in this sense. The library
locks it all by itself (like a private memory pool in my string class
example). But the SSL object is a high-level object whose sanity is supposed
to be managed by the caller (like an individual string object in my string
class example).

DS


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

Need help: Understanding SSL object in multi-threaded environment

[Urjit Gokhale]

Hi all,

I have some doubts about openssl and
multithreaded environment. I will appreciate if you could help me understand
this better.
It is said that openssl is thread-safe with a
limitation that "an SSL connection may not
concurrently be used by multiple threads"
I am not clear on this point. What is meant by "using SSL connection concurrently by
multiple threads" ?

I read somewhere that anSSL object modifies
and maintains its state during reads and writes. So if the same object is used
in multiple threads concurrently, chances are that due to state mismatch, the
read/write may fail. Could someone explain this in more details. I believe that
multiple threads would share the sameSSL object. So in fact, they will be
using 'the sameSSL object'. Is this understanding correct? If yes, what is
the issue with using the same object in multiple threads?

I am struggling to understand this. Could someone
make the picture more clear?

Thank you,
~ Urjit
DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails.

RE: Need help: Understanding SSL object in multi-threaded environment

[André Ziermann]

Hi,

you may usethe sameH_SSL_CTX (handle to an SSL 
context) in concurrent threads. This structure serves as a factory of ssl 
connections. 
You use SSL_new to create SSL connection handles (H_SSL). 
These you can use only within one thread.
So, you may share H_SSL_CTX, you may not share 
H_SSL.
HTH
André

From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Urjit 
GokhaleSent: Donnerstag, 5. Oktober 2006 09:33To: 
openssl-users@openssl.orgSubject: Need help: Understanding SSL object 
in multi-threaded environment

Hi all,

I have some doubts about openssl and 
multithreaded environment. I will appreciate if you could help me understand 
this better.
It is said that openssl is thread-safe with a 
limitation that "an SSL connection may not 
concurrently be used by multiple threads"
I am not clear on this point. What is meant by "using SSL connection concurrently by 
multiple threads" ?

I read somewhere that anSSL object modifies 
and maintains its state during reads and writes. So if the same object is used 
in multiple threads concurrently, chances are that due to state mismatch, the 
read/write may fail. Could someone explain this in more details. I believe that 
multiple threads would share the sameSSL object. So in fact, they will be 
using 'the sameSSL object'. Is this understanding correct? If yes, what is 
the issue with using the same object in multiple threads?
I am struggling to understand this. Could someone 
make the picture more clear?

Thank you,
~ Urjit
DISCLAIMER == This 
e-mail may contain privileged and confidential information which is the property 
of Persistent Systems Pvt. Ltd. It is intended only for the use of the 
individual or entity to which it is addressed. If you are not the intended 
recipient, you are not authorized to read, retain, copy, print, distribute or 
use this message. If you have received this communication in error, please 
notify the sender and delete all copies of this message. Persistent Systems Pvt. 
Ltd. does not accept any liability for virus infected mails. 


smime.p7s
Description: S/MIME Cryptographic Signature

RE: Need help: Understanding SSL object in multi-threaded environment

[Mark]

 you may use the same H_SSL_CTX (handle to an SSL context) in 
 concurrent threads. This structure serves as a factory of ssl 
 connections. 
 You use SSL_new to create SSL connection handles (H_SSL). 
 These you can use only within one thread.
 So, you may share H_SSL_CTX, you may not share H_SSL.

I can't find anything in the documentation to suggest that you cannot
share a SSL object between threads.  The important thing is to implement
the locking callbacks [CRYPTO_set_locking_callback() etc.].

I have written applications that read on one thread and write on another
using the same SSL object and they work fine.

Please tell me if I am incorrect in my assumptions.

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

Re: Need help: Understanding SSL object in multi-threaded environment

[Urjit Gokhale]

- Original Message - 
From: Mark [EMAIL PROTECTED]
To: openssl-users@openssl.org
Sent: Thursday, October 05, 2006 2:49 PM
Subject: RE: Need help: Understanding SSL object in multi-threaded
environment


 you may use the same H_SSL_CTX (handle to an SSL context) in
 concurrent threads. This structure serves as a factory of ssl
 connections.
 You use SSL_new to create SSL connection handles (H_SSL).
 These you can use only within one thread.
 So, you may share H_SSL_CTX, you may not share H_SSL.

I can't find anything in the documentation to suggest that you cannot
share a SSL object between threads.  The important thing is to implement
the locking callbacks [CRYPTO_set_locking_callback() etc.].

[Urjit]: Correct. One should implement the locking callbacks. What I am
confused about is the
statement in openssl faq (http://www.openssl.org/support/faq.html#PROG1)
that reads:
---
1. Is OpenSSL thread-safe?
Yes (with limitations: an SSL connection may not concurrently be used by
multiple threads)
---

~ Urjit


DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Persistent Systems Pvt. Ltd. It is intended only for the use of the 
individual or entity to which it is addressed. If you are not the intended 
recipient, you are not authorized to read, retain, copy, print, distribute or 
use this message. If you have received this communication in error, please 
notify the sender and delete all copies of this message. Persistent Systems 
Pvt. Ltd. does not accept any liability for virus infected mails.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Need help: Understanding SSL object in multi-threaded environment

[David Schwartz]

 1. Is OpenSSL thread-safe?
 Yes (with limitations: an SSL connection may not concurrently be used by
 multiple threads)

This means exactly what it says. A single SSL connection may not be used
concurrently by multiple threads. This means it is illegal for one thread to
do a 'write' on the connection at the same time another thread might be
doing, say, a 'read'.

You can share an SSL connection object among threads, but you must protect
it yourself with a mutex or similar lock.

This is a semantic difference between SSL connections and normal TCP
connections. For example, with TCP, you call 'shutdown' in one thread,
'read' in another, and 'write' in a third all at the same time and you will
get sensible results.

This is, however, the usual rule for user-space objects. For example, even
if you have a plain old integer, you cannot write to it in one thread and
read from it another and get guaranteed results. (At least, not without some
special knowledge about your platform.)

DS


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

RE: Need help: Understanding SSL object in multi-threaded environment

[Mark]

David,

  1. Is OpenSSL thread-safe?
  Yes (with limitations: an SSL connection may not 
 concurrently be used by multiple threads)
 
 This means exactly what it says. A single SSL connection may 
 not be used concurrently by multiple threads. This means it is illegal

 for one thread to do a 'write' on the connection at the same time
another 
 thread might be doing, say, a 'read'.
 
 You can share an SSL connection object among threads, but you 
 must protect it yourself with a mutex or similar lock.

I assume this a reason why OpenSSL has the locking callback functions.
As long as you use these it is safe to share the object AFAIK.

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

RE: Need help: Understanding SSL object in multi-threaded environment

[David Schwartz]

 I assume this a reason why OpenSSL has the locking callback functions.

No. OpenSSL has the locking callback functions so it can protect internal
structures. For example, if two SSL objects internally reference the
objects.

 As long as you use these it is safe to share the object AFAIK.

Then when wouldn't it be safe to share the object? The locking callback
functions are required for all multithreaded applications or else OpenSSL
can't protect its internal state.

DS


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

RE: Need help: Understanding SSL object in multi-threaded environment

[David Schwartz]

 Is it the case that both SSL_read and SSL_write modify the same
 part of the
 SSL object ?

Yes, but that's not the issue.

 Could you give some more details about this? Could you throw some
 more light
 on the ssl state maintained
 by the SSL object during SSL_read and SSL_write?

I'm not sure why more internal details of how OpenSSL works would be
helpful. I've already explained the external interface.

 Is it safe if I programmatically make sure (say using mutex) that only one
 thread is accessing the SSL object at any time?

Yes.

 In that case, would it be okay to call SSL_read on one thread and
 SSL_write
 on other thread?

So long as you didn't call them both on the same SSL object at the same
time.

 Where exactly would the locking callback functions come into picture?

The locking callback functions are required to be properly implemented if
you are going to use OpenSSL on a multithreaded platform. OpenSSL uses them
internally to prevent conflicts.

Every sophisticated library that supports multiple threads strikes a balance
between thread-safety in the caller and thread-safety in the library itself.
This is OpenSSL's balance.

It's pretty much the same balance the vast majority of libraries takes.
Concurrent calls on the same upper-level object are prohibited. But calls
that internally happen to access the same lower-level objects are handled
by the library.

The only reason it's important to mention that you can't access the same SSL
object in multiple threads is that TCP allows this. Otherwise, it would be
what you would assume.

For example, a typical C++ string library is thread-safe, even if it
accesses global structures such as a private memory pool, but you can't
manipulate the same string at the same time in two threads.

DS


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

RE: Need help: Understanding SSL object in multi-threaded environment

[Edward Chan]

I'm sure David will have more to say about how the locking callbacks are
used in OpenSSL.  But my understanding is that just because you
implement these, you still cannot freely call SSL_read/SSL_write from
different threads without the proper locking.  The reason is because you
have direct access to the SSL* obj passed to these 2 functions.  The
locking callbacks probably provide the library with the locks necessary
for it to protect objects it uses internally that need syncrhonization.
But the SSL object is used in your code and it is totally up to you to
provide the necessary locking yourself.

At least that I my understanding, which so far seems to work in my
multi-threaded application.

Ed
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Mark
 Sent: Thursday, October 05, 2006 3:24 AM
 To: openssl-users@openssl.org
 Subject: RE: Need help: Understanding SSL object in 
 multi-threaded environment
 
 David,
 
   1. Is OpenSSL thread-safe?
   Yes (with limitations: an SSL connection may not
  concurrently be used by multiple threads)
  
  This means exactly what it says. A single SSL connection may not be 
  used concurrently by multiple threads. This means it is illegal
 
  for one thread to do a 'write' on the connection at the same time
 another 
  thread might be doing, say, a 'read'.
  
  You can share an SSL connection object among threads, but you must 
  protect it yourself with a mutex or similar lock.
 
 I assume this a reason why OpenSSL has the locking callback functions.
 As long as you use these it is safe to share the object AFAIK.
 
 Regards, Mark
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   [EMAIL PROTECTED]
 
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Need some help debugging SSL error thrown from STunnel using OpenSSL-FIPS

[Dr. Stephen Henson]

On Wed, Jun 07, 2006, David Gillingham wrote:

 Hello all,
 
 I've been tasked to internally investigate a system that utilizes
 STunnel and OpenSSL to create a secure wrapper for a propietary
 protocol.  Additionally, this solution must eventually be FIPS 140-2
 compliant.
 
 608008D: error:0608008D:digital envelope
 routines:EVP_DigestInit:disabled for fips
 

That's the problem. I'd guess that this is due to a certificate using an
algorithm that isn't allowed in FIPS mode: probably MD5.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Need some help debugging SSL error thrown from STunnel using OpenSSL-FIPS

[David Gillingham]

I was able to convert the key as you instructed, and I overwrote the
old RSA private key from my server.pem file with the new PKCS8 one.  I
am now a getting a different error message.  From these new messages,
I'm guessing OpenSSL is expecting a file in PKCS12 format, but that my
file does not match this format.  Is my understanding correct?  Error
log follows.

BEGIN STUNNEL LOG
2006.06.08 17:49:38 LOG7[1120:616]: Certificate: server.pem
2006.06.08 17:49:38 LOG7[1120:616]: Key file: server.pem
2006.06.08 17:49:42 LOG3[1120:616]: error stack: 140B3009 :
error:140B3009:SSL routines:SSL_CTX_use_RSAPrivateKey_file:PEM lib
2006.06.08 17:49:42 LOG3[1120:616]: error stack: 906700D :
error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib
2006.06.08 17:49:42 LOG3[1120:616]: error stack: 2306A075 :
error:2306A075:PKCS12 routines:PKCS12_DECRYPT_D2I:pkcs12 pbe crypt
error
2006.06.08 17:49:42 LOG3[1120:616]: error stack: 23077073 :
error:23077073:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 algor
cipherinit error
2006.06.08 17:49:42 LOG3[1120:616]: SSL_CTX_use_RSAPrivateKey_file:
6074079: error:06074079:digital envelope
routines:EVP_PBE_CipherInit:unknown pbe algorithm

2006.06.08 17:49:42 LOG3[1120:616]: Server is down
END STUNNEL LOG
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Need some help debugging SSL error thrown from STunnel using OpenSSL-FIPS

[Dr. Stephen Henson]

On Thu, Jun 08, 2006, David Gillingham wrote:

 I was able to convert the key as you instructed, and I overwrote the
 old RSA private key from my server.pem file with the new PKCS8 one.  I
 am now a getting a different error message.  From these new messages,
 I'm guessing OpenSSL is expecting a file in PKCS12 format, but that my
 file does not match this format.  Is my understanding correct?  Error
 log follows.
 
 BEGIN STUNNEL LOG
 2006.06.08 17:49:38 LOG7[1120:616]: Certificate: server.pem
 2006.06.08 17:49:38 LOG7[1120:616]: Key file: server.pem
 2006.06.08 17:49:42 LOG3[1120:616]: error stack: 140B3009 :
 error:140B3009:SSL routines:SSL_CTX_use_RSAPrivateKey_file:PEM lib
 2006.06.08 17:49:42 LOG3[1120:616]: error stack: 906700D :
 error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib
 2006.06.08 17:49:42 LOG3[1120:616]: error stack: 2306A075 :
 error:2306A075:PKCS12 routines:PKCS12_DECRYPT_D2I:pkcs12 pbe crypt
 error
 2006.06.08 17:49:42 LOG3[1120:616]: error stack: 23077073 :
 error:23077073:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 algor
 cipherinit error
 2006.06.08 17:49:42 LOG3[1120:616]: SSL_CTX_use_RSAPrivateKey_file:
 6074079: error:06074079:digital envelope
 routines:EVP_PBE_CipherInit:unknown pbe algorithm
 
 2006.06.08 17:49:42 LOG3[1120:616]: Server is down
 END STUNNEL LOG

That error means that the PBE table has not been initialized in the 
application. 

A call to OpenSSL_add_all_algorithms() would have automatically done that so
I'd guess that the table is being initialized in a customized way, possible to
reduce the number of algorithms added.

A call to PKCS5_PBE_add() is needed in any case in the application.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Need some help debugging SSL error thrown from STunnel using OpenSSL-FIPS

[David Gillingham]

Dr. Henson--

Adding in a call to OpenSSL_add_all_algorithms() fixed the error.
Thanks for the assistance.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Need some help debugging SSL error thrown from STunnel using OpenSSL-FIPS

[David Gillingham]

Hello all,

I've been tasked to internally investigate a system that utilizes
STunnel and OpenSSL to create a secure wrapper for a propietary
protocol.  Additionally, this solution must eventually be FIPS 140-2
compliant.

So, using instructions outlined in the OpenSSL FIPS Security Policy
and on this mailing list, I have been able to succesfully build a
FIPS-compliant distribution using MinGW and Visual Studio 2005.

Then, I took the STunnel source and modified its SSL initialization
function to invoke OpenSSL's FIPS mode (using FIPS_mode_set(1), as
outlined on page 45 of the security policy), along with changing a few
#includes to allow it build on VS2005.

It is important to note that I was able to succesfully use STunnel
prior to adding in the FIPS mode invocation.  However, after building
STunnel with the FIPS mode invocation, I'm encountering some program
errors (which seem to be SSL errors) that I'm having some trouble
deciphering.  I understand that the task of deciphering these errors
may be better directed at an STunnel mailing list, but I am unable to
access their page from work.

What follows is a STunnel program log that contains what appears to be
a stack trace of the SSL errors being thrown.  In line 8, STunnel
claims that one of the OpenSSL calls is being disabled for FIPS, but
it is not clear to me which call that was.  I was hoping that someone
more familiar with OpenSSL in FIPS mode may be able to lend a hand on
that one.  Also note that server.pem is a file that contains an RSA
private key and a password-protected, signed certificate in PKCS7
format.  Please be aware that I am definitely using the right password
for the cert as I have verified this in the copy of the code not using
OpenSSL's FIPS mode.

BEGIN STUNNEL LOG
2006.06.06 18:58:26 LOG7[592:1816]: RAND_status claims sufficient
entropy for the PRNG
2006.06.06 18:58:26 LOG6[592:1816]: PRNG seeded successfully
2006.06.06 18:58:26 LOG7[592:1816]: Certificate: server.pem
2006.06.06 18:58:26 LOG7[592:1816]: Key file: server.pem
2006.06.06 18:58:32 LOG3[592:1816]: error stack: 140B3009 :
error:140B3009:SSL routines:SSL_CTX_use_RSAPrivateKey_file:PEM lib
2006.06.06 18:58:32 LOG3[592:1816]: error stack: 906A065 :
error:0906A065:PEM routines:PEM_do_header:bad decrypt
2006.06.06 18:58:32 LOG3[592:1816]: error stack: 6065064 :
error:06065064:digital envelope routines:EVP_DecryptFinal:bad decrypt
2006.06.06 18:58:32 LOG3[592:1816]: SSL_CTX_use_RSAPrivateKey_file:
608008D: error:0608008D:digital envelope
routines:EVP_DigestInit:disabled for fips

2006.06.06 18:58:32 LOG3[592:1816]: Server is down
END STUNNEL LOG
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Need help troubleshooting SSL error

[kynn]

I'm running an OpenSSL-enabled application (nessus) that fails with
the following error message:

SSL_CTX_load_verify_locations[737]: error:06065064:digital envelope 
routines:EVP_DecryptFinal:bad decrypt

How can I determine the reason for this failure?

Thanks!

KJ

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

Help with SSL Certificate from Verisign

[Reed, Ken]

Hello,



I've searched the web regarding this issue but found
little to no information

that didn't cover what I've already tried.



Running Apache 1.3.26 with OpenSSL 0.9.6g on Solaris 2.7.



I was able to successfully test the initial configuration
with a test certificate but am now trying

to install a certificate recently received from Verisign.



I have performed the following steps:



 Sftpd
cert.cer from windows client to Solaris server

 Ran
"dos2unix cert.cer  dx04-t.cert" to strip out Windows ^M
characters

 Ran
"mv dx04-t.cert /usr/local/apache/SSLconf/conf/dx04-t.cert"

 Set
the following in httpsd.conf:



 SSLCertificateFile
/usr/local/apache/SSLconf/conf/dx04-t.cert

 SSLCertificateKeyFile
/usr/local/apache/SSLconf/conf/dx04-t.cert.key



When I attempt to start apache, I receive the following
messages in the https.error.log:



 [Tue
Sep 10 17:36:42
2002] [crit] Error reading server certificate  file
/usr/local/apache/SSLconf/conf/dx04-t.cert

 [Tue Sep 10 17:36:42
2002] [crit] error:0D0A2007:asn1 encoding  routines:d2i_X509_CINF:expecting
an asn1 sequence

 [Tue Sep 10 17:36:42
2002] [crit] error:0D09F004:asn1 encoding  routines:d2i_X509:nested
asn1 error

 [Tue
Sep 10 17:36:42
2002] [crit] error:0906700D:PEM  routines:PEM_ASN1_read_bio:ASN1
lib



I get the same messages when I run:



 openssl
x509 -noout -text -in dx04-t.cert



I have setup dozens of other Web Servers in the same fashion
(running various Apache and SSL configs)

but this is the first time I've run into this problem.



Any ideas or suggestions would be greatly appreciated.

--

Kenneth Reed,

Sr. UNIX Administrator

help, apache+ssl

[Shalu]

Hi I am sorry for this message it does not belongs completely fr 
this list but still people will be knowing here
I wanaa do something with openssl and ssl in my server
but I am stucked in the first step

I have a machine called jessus, a login called shalen
I have installed apache, the organization i work in is lest say
abc.fr
its site is let say www.abc.fr

so i ran apache and made a pubic directory in my home/shalen
and than put a resume.html in my pubic directory

when i write
netscape http://www.jesus.abc.fr/shalen/resume.html
netscape is unable to locate

can someone tell which files and what to edit

Thanks a lot
Shalen
_
There is always a better job for you at Monsterindia.com.
Go now http://monsterindia.com/rediffin/
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: help, apache+ssl

[Silvex Security Team]

Try this in your httpd.conf

DocumentRoot /var/www/html

Directory /
Options Indexes Includes FollowSymLinks MultiViews
AllowOverride All
/Directory


Directory /var/www/html


 Hi I am sorry for this message it does not belongs completely fr
 this list but still people will be knowing here
 I wanaa do something with openssl and ssl in my server
 but I am stucked in the first step

 I have a machine called jessus, a login called shalen
 I have installed apache, the organization i work in is lest say
 abc.fr
 its site is let say www.abc.fr

 so i ran apache and made a pubic directory in my home/shalen
 and than put a resume.html in my pubic directory

 when i write
 netscape http://www.jesus.abc.fr/shalen/resume.html
 netscape is unable to locate

 can someone tell which files and what to edit

 Thanks a lot
 Shalen
 _
 There is always a better job for you at Monsterindia.com.
 Go now http://monsterindia.com/rediffin/
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing List[EMAIL PROTECTED]
 Automated List Manager   [EMAIL PROTECTED]



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

RE: Help with SSL Server on Solaris vs. Linux

[Albert Gallego]

That did it thanks :)

-Original Message-
From: John Denney [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 30, 2001 3:21 PM
To: [EMAIL PROTECTED]
Subject: Re: Help with SSL Server on Solaris vs. Linux


The data you read was part of the ssl connect/accept handshake, which is
now unavailable to SSL_accept.  Don't read; do SSL_accept instead.

Albert Gallego wrote:
 
  You must correctly evaluate the return value of SSL_get_error().
 The return value 2 means:
 #define SSL_ERROR_WANT_READ 2
 so it seems that you are using a non-blocking socket and you have to
 call SSL_accept() again and again until success was reached.
 ERR_print_errors* etc won't show you anything because this isn't error
 but just an intermediate state on the way to success. 
 
 Thanks a ton for the reply :)
 
 Unfortunatly I tried that, by polling that fd.  The first time through
poll
 told me that indeed there was information to be read from the socket, so I
 read all the data.  Then I tried accept again.  From there is fails with
the
 same error, and I poll again.  This time however poll timed out (with a
 timeout of 10 seconds) because there wasn't any data left to be read from
 the socket, I then try SSL_accept again, and still no dice.  Here's the
code
 
 temp_ret = SSL_accept(p_ssl);
 if (temp_ret != 1)
 {
 char str_read[2048];
 int poll_ret;
 struct pollfd mypollfd;
 int n_read;
 int error_code = SSL_get_error(p_ssl, temp_ret);
 
 mypollfd.fd = connfd;
 mypollfd.events = POLLIN;
 
 while (temp_ret != 1  (error_code == SSL_ERROR_WANT_READ ||
 error_code == SSL_ERROR_WANT_WRITE))
 {
 poll_ret = poll(mypollfd, 1, 1);
 
 if (poll_ret == 1)
 {
 n_read = read(connfd, str_read, 2047);
 str_read[n_read] = '\0';
 }
 temp_ret = SSL_accept(p_ssl);
 
 if (poll_ret == 1  temp_ret != 1)
 error_code = SSL_get_error(p_ssl, temp_ret);
 else
 error_code = 0;
 }
 
 }
 
 Thanks
 Albert Gallego
 
 -Original Message-
 From: Lutz Jaenicke [mailto:[EMAIL PROTECTED]]
 Sent: Friday, March 30, 2001 2:47 AM
 To: '[EMAIL PROTECTED]'
 Subject: Re: Help with SSL Server on Solaris vs. Linux
 
 On Tue, Mar 27, 2001 at 04:08:49PM -0700, Albert Gallego wrote:
  The error I get from SSL_get_error is 2 and ERR_print_errors_fp(stderr)
  doesn't print out anything :(
 ...
  temp_ret = SSL_accept(p_ssl);
  if (temp_ret != 1)
  {
  log_error(ZONE, "Unable to do the accept phase of the SSL
  connection, %d", SSL_get_error(p_ssl, temp_ret));
  ERR_print_errors_fp(stderr);
 
  SSL_free(p_ssl);
  return;
  }
 ...
 
 You must correctly evaluate the return value of SSL_get_error().
 The return value 2 means:
 #define SSL_ERROR_WANT_READ 2
 so it seems that you are using a non-blocking socket and you have to
 call SSL_accept() again and again until success was reached.
 ERR_print_errors* etc won't show you anything because this isn't error
 but just an intermediate state on the way to success.
 
 Best regards,
 Lutz
 --
 Lutz Jaenicke [EMAIL PROTECTED]
 BTU Cottbus   http://www.aet.TU-Cottbus.DE/personen/jaenicke/
 Lehrstuhl Allgemeine Elektrotechnik  Tel. +49 355 69-4129
 Universitaetsplatz 3-4, D-03044 Cottbus  Fax. +49 355 69-4153
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing List[EMAIL PROTECTED]
 Automated List Manager   [EMAIL PROTECTED]
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing List[EMAIL PROTECTED]
 Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Help with SSL Server on Solaris vs. Linux

[Lutz Jaenicke]

On Fri, Mar 30, 2001 at 02:21:11PM -0800, John Denney wrote:
 The data you read was part of the ssl connect/accept handshake, which is
 now unavailable to SSL_accept.  Don't read; do SSL_accept instead.

Yes, that is already 95% (and the most important part of the problem in
the example).

Additionally:

  mypollfd.fd = connfd;
  mypollfd.events = POLLIN;
  
  while (temp_ret != 1  (error_code == SSL_ERROR_WANT_READ ||
  error_code == SSL_ERROR_WANT_WRITE))
  {
  poll_ret = poll(mypollfd, 1, 1);

Here you additionally must take care, that WANT_READ indicates that more
data must be read from the socket (POLLIN) while WANT_WRITE indicates
that more data must be written to the socket (POLLOUT).
  while ((temp_ret = SSL_accept(p_ssl)) == -1) {
switch (SSL_get_error(p_ssl, temp_ret)) {
case SSL_ERROR_WANT_READ:
  poll for POLLIN;
case SSL_ERROR_WANT_WRITE:
  poll for POLLOUT:
default:
  hard_failure...
}
  }

Best regards,
Lutz
-- 
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus   http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus  Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

please help apache-ssl

[Christoph Hubmann]

Hello all
i am new on this list. linux machine redhat 
6.2.
i compiled openssl-0.9.6.
then patch and compiled apache-1.3.14 with no 
problems.

after that i have make certs with the following 
commands:
cd /usr/local/ssl/private
openssl genrsa -des3 -out MyCA.key
openssl genrsa -des3 -out ServerCA.key
openssl genrsa -des3 -out ClientCA.key
cd ../certs
openssl req -new x509 -days 90 -key 
../private/MyCA.key -out MyCA.crt
openssl req -new -key ../private/ServerCA.key -out 
ServerCA.csr
openssl req -new -key ../privateClientCA.key -out 
ClientCA.csr
openssl ca -cert MyCA.crt -in ServerCA.csr -keyfile 
../private/MyCA.key -out ServerCA.crt

openssl ca -cert MyCA.crt -in ClientCA.csr -keyfile 
../private/MyCA.key -out ClientCA.crt
openssl pkcs12 -export -in MyCA.crt -inkey 
../private/MyCA.key -out MyCA.pfx

in httpd.conf:
SSLCACertificatePath 
/usr/local/ssl/certs
SSLCACertificateFile 
/usr/local/ssl/certs/ClientCA.crt
SSLCertificateFile 
/usr/local/ssl/certs/ServerCA.crt
SSLCertificateKeyFile 
/usr/local/ssl/private/ServerCA.key
SSLVerifyClient 1
SSLVerifyDepth 1

with SSLVerifyClient0 there is no 
problem
with SSLVerifyClient 1, i cant cennoct to the 
server in the error_log is the following message:
[Tue Feb 20 16:01:14 2001] 
/usr/local/src/apache_1.3.14/src/modules/ssl/gcache started[Tue Feb 20 
16:01:14 2001] [debug] apache_ssl.c(369): Random input /dev/urandom(1024) 
- 1024[Tue Feb 20 16:01:14 2001] [info] created shared memory segment 
#118657[Tue Feb 20 16:01:14 2001] 
/usr/local/src/apache_1.3.14/src/modules/ssl/gcache started[Tue Feb 20 
16:01:14 2001] [notice] Apache/1.3.14 Ben-SSL/1.42 (Unix) configured-- 
resuming normal operations[Tue Feb 20 16:01:14 2001] [info] Server built: 
Feb 16 2001 16:46:27[Tue Feb 20 16:01:27 2001] [debug] apache_ssl.c(369): 
Random input /dev/urandom(1024) - 1024[Tue Feb 20 16:01:29 2001] 
[error] SSL_accept failed[Tue Feb 20 16:01:29 2001] [error] 
error:140890B0:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificates 
returned

what is wrong? i use netscape 4.75

please help

christoph hubmann

Re: please help apache-ssl

[Jorge Olmos]

I dont know much about modssl, but
If you set SSLVerifyClient to 1 you are telling the server
to authenticate its clients (criptographically verify the
clients identity).

An entitity (lets say somebody connecting to your server)
needs a certificate in order to be athenticated, but hardly any
web user has his own certificate (You have to buy it or
make your own certification authority and make the
server trust it). And thats is your error message: your
browser does not have a certificate.

Just dont set SSLVerifyClient to 1, if you want usual people
(99% of web users) to be able to get into your web.

Christoph Hubmann wrote:

  in httpd.conf:SSLCACertificatePath
 /usr/local/ssl/certsSSLCACertificateFile
 /usr/local/ssl/certs/ClientCA.crtSSLCertificateFile
 /usr/local/ssl/certs/ServerCA.crtSSLCertificateKeyFile
 /usr/local/ssl/private/ServerCA.keySSLVerifyClient 1SSLVerifyDepth
 1 with SSLVerifyClient 0 there is no problemwith SSLVerifyClient 1, i
 cant cennoct to the server in the error_log is the following
 message:[Tue Feb 20 16:01:14 2001]
 /usr/local/src/apache_1.3.14/src/modules/ssl/gcache s
 tarted
 [Tue Feb 20 16:01:14 2001] [debug] apache_ssl.c(369): Random input
 /dev/urandom(
 1024) - 1024
 [Tue Feb 20 16:01:14 2001] [info] created shared memory segment
 #118657
 [Tue Feb 20 16:01:14 2001]
 /usr/local/src/apache_1.3.14/src/modules/ssl/gcache s
 tarted
 [Tue Feb 20 16:01:14 2001] [notice] Apache/1.3.14 Ben-SSL/1.42 (Unix)
 configured
  -- resuming normal operations
 [Tue Feb 20 16:01:14 2001] [info] Server built: Feb 16 2001 16:46:27
 [Tue Feb 20 16:01:27 2001] [debug] apache_ssl.c(369): Random input
 /dev/urandom(
 1024) - 1024
 [Tue Feb 20 16:01:29 2001] [error] SSL_accept failed
 [Tue Feb 20 16:01:29 2001] [error] error:140890B0:SSL
 routines:SSL3_GET_CLIENT_C
 ERTIFICATE:no certificates returned what is wrong? i use netscape
 4.75 please help christoph hubmann

--

Jorge Olmos Fors


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

RE: need help putting ssl into win32 web server

[Wade L. Scholine]

I am going to write a FAQ on this.

To see source for a minimal SSL client and server, see the demos/ssl
directory. 

To see source for a program that does lots more, including client cert
authentication, look at the s_client and s_server programs in the apps
directory. 

You will want to build the package and be able to play around with the
openssl command, which implements the s_client and s_server commands.

 -Original Message-
 From: Michael Sandler [mailto:[EMAIL PROTECTED]]
 Sent: Monday, March 27, 2000 2:39 PM
 To: [EMAIL PROTECTED]
 Subject: need help putting ssl into win32 web server
 
 
 I am new to SSL, and was wondering if someone could point me 
 to some literature to help with my project.
 
 Basically, I have been tasked with integrating SSL into my 
 company's custom web server.  I want to use OpenSSL, but 
 unfortunately don't know where to start.  I assume that it 
 should be pretty easy, just replacing the connect, listen, 
 and other calls with SSL enabled counterparts, or just adding 
 SSL wrappers.  Unfotunately, at this point I know little 
 about SSL, and so have no idea which functions I would need 
 to use (the API is pretty substantial, so i will need to 
 narrow it down :).
 From the archives of this list, it looks like at least a few 
 people have needed to do this, so I was hoping that someone 
 could either give me some pointers, or at least tell me where 
 I can obtain this info.
 
 My project is being developed in Visual C++ 6.0, and when 
 finished needs to be able to talk to MS IE over SSL.
 
 Any help will be greately appreciated.
  Thanks
  
  -Mike Sandler
   
 
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing List[EMAIL PROTECTED]
 Automated List Manager   [EMAIL PROTECTED]
 
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: need help putting ssl into win32 web server

[Dr Stephen Henson]

Wade L. Scholine wrote:
 
 I am going to write a FAQ on this.
 
 To see source for a minimal SSL client and server, see the demos/ssl
 directory.
 

Also for an even simpler example that hides some of the socket yuckiness
round BIOs try demos/bio. 

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.


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

help with SSL error response

[Anonymous]

I get the error message "curl: SSL: couldn't get peer certificate!" when
I attempt
to access a web site via https. I'm using this with the curl tool as you
can see. I have had success
fetching https pages fron another web site, but this particular one
requires a user password handshake.
Being a novice with this library I'm unsure what to try next. Any
suggestions as to what
I may need to look into?

Thanks,
Craig


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

Re: config, compile, install help - php3, ssl, apache 1.3.x

[William X. Walsh]

  I installed the apapche 1.3.4+mod_SSL rpm that is floating around on
  Ralph's site - it works wonderfuly by itself, but it appears that no
  other redhat modules can be installed on top of that installation. This
  appears to be due to apache+mod_ssl is using some EAPI, which is not
  compatible with the standard apache API - or something to that effect.
  
  Long story short - it doesn't work.

Download the sources and compile with all the modules you list. I run that
exact setup here (apache+mod_ssl/PHP3/mod_perl) and it works perfectly, and
yes, SSL can use PHP/mod_perl with this setup.

It is really not that difficult to do, the INSTALL docs on all these packages
are pretty straightforward and simple (or if you are really hard pressed on
doing this contact me offlist and I or one of my staff can possibly assist you).

This seems like a popular combination, perhaps it would be worth someone doing
up an rpm combining these particular modules (but might be a lot of work
keeping a package with all the latest versions after each upgrade).

--
E-Mail: William X. Walsh [EMAIL PROTECTED]
Date: 02-Mar-99
Time: 02:11:54
--
"We may well be on our way to a society overrun by hordes
of lawyers, hungry as locusts."
- Chief Justice Warren Burger, US Supreme Court, 1977

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