RE: [EXTERNAL] Re: SSL error (78c0100): malloc failure while implementing tls 1.3

[Ramaiah, Ravichandran Bagalur]

I was able to trace the failure to ssl/ssl_sess.c line 279.

I’m not sure what needs to done additionally in application code for this. 
Could someone please explain this error?

I’m just trying to add support for tls 1.3 in application which already 
supports tls 1.2.

(gdb) bt
#0  0x7fd5737051a0 in ssl_session_dup () from 
/lib/x86_64-linux-gnu/libssl.so.3
#1  0x7fd57373a931 in tls_construct_new_session_ticket () from 
/lib/x86_64-linux-gnu/libssl.so.3
#2  0x7fd57372aaff in state_machine.part () from 
/lib/x86_64-linux-gnu/libssl.so.3
#3  0x7fd573719e8e in ssl3_read_bytes () from 
/lib/x86_64-linux-gnu/libssl.so.3
#4  0x7fd5736edcc9 in ssl3_read () from /lib/x86_64-linux-gnu/libssl.so.3
#5  0x7fd5736fa6c0 in ssl_read_internal () from 
/lib/x86_64-linux-gnu/libssl.so.3
#6  0x7fd5736fa7f5 in SSL_read () from /lib/x86_64-linux-gnu/libssl.so.3



Regards,
Ravi


_
From: Ramaiah, Ravichandran Bagalur 
Sent: Wednesday, June 29, 2022 12:55 PM
To: Matt Caswell ; openssl-users@openssl.org
Subject: RE: [EXTERNAL] Re: SSL error (78c0100): malloc failure while 
implementing tls 1.3


Hi Matt,

Below is the error I got when I printed using ERR_error_string().


error:078C0100:common libcrypto routines::malloc failure

Any pointers on this?

Regards,
Ravi

-Original Message-
From: Matt Caswell mailto:m...@openssl.org>>
Sent: Tuesday, June 21, 2022 4:25 PM
To: Ramaiah, Ravichandran Bagalur 
mailto:rrama...@rbbn.com>>; 
openssl-users@openssl.org<mailto:openssl-users@openssl.org>
Subject: [EXTERNAL] Re: SSL error (78c0100): malloc failure while implementing 
tls 1.3



On 16/06/2022 05:52, Ramaiah, Ravichandran Bagalur wrote:
>
> *SSL error (78c0100): malloc failure

Do you get anything in the OpenSSL error stack for this (e.g. try 
"ERR_print_errors_fp(stdout);").

We need a bit more to go on to figure out where specifically the malloc failure 
is occurring.

Matt



Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

RE: [EXTERNAL] Re: SSL error (78c0100): malloc failure while implementing tls 1.3

[Ramaiah, Ravichandran Bagalur]

Hi Matt,

Below is the error I got when I printed using ERR_error_string().


error:078C0100:common libcrypto routines::malloc failure

Any pointers on this?

Regards,
Ravi

-Original Message-
From: Matt Caswell 
Sent: Tuesday, June 21, 2022 4:25 PM
To: Ramaiah, Ravichandran Bagalur ; openssl-users@openssl.org
Subject: [EXTERNAL] Re: SSL error (78c0100): malloc failure while implementing 
tls 1.3



On 16/06/2022 05:52, Ramaiah, Ravichandran Bagalur wrote:
>
> *SSL error (78c0100): malloc failure

Do you get anything in the OpenSSL error stack for this (e.g. try 
"ERR_print_errors_fp(stdout);").

We need a bit more to go on to figure out where specifically the malloc failure 
is occurring.

Matt



Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

Re: SSL error (78c0100): malloc failure while implementing tls 1.3

[Matt Caswell]

On 16/06/2022 05:52, Ramaiah, Ravichandran Bagalur wrote:


*SSL error (78c0100): malloc failure


Do you get anything in the OpenSSL error stack for this (e.g. try 
"ERR_print_errors_fp(stdout);").


We need a bit more to go on to figure out where specifically the malloc 
failure is occurring.


Matt

RE: SSL error (78c0100): malloc failure while implementing tls 1.3

[Ramaiah, Ravichandran Bagalur]

Hi All,

Could anyone tell me if this issue is caused due to application error or an 
openssl bug?

This malloc failure is happening when I try to establish TLS connection between 
2 SIP applications.

Regards,
Ravi

From: Ramaiah, Ravichandran Bagalur
Sent: Thursday, June 16, 2022 10:23 AM
To: openssl-users@openssl.org
Subject: SSL error (78c0100): malloc failure while implementing tls 1.3

Hi All,

I'm trying to implement tls 1.3 support in my application. But I'm facing 
malloc failure error.

Could you please help me understand why this error is happening? How to solve 
this issue?


*Set TLSv1.3 Cipher list TLS_AES_128_GCM_SHA256 ret 1
*SipCmOpenSSLNew: TLS, mutual auth, tlsSipAuthRequired = FALSE
*SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS for ssl is NOT set.
*SSL handshake started undefined:before SSL initialization 240
*SSL_accept:before SSL initialization
*SSL_accept:before SSL initialization
*SSL_accept:SSLv3/TLS read client hello
*SSL_accept:SSLv3/TLS write server hello
*SSL_accept:SSLv3/TLS write change cipher spec
*SSL_accept:TLSv1.3 early data
*SSL_accept:error in TLSv1.3 early data
*SipCmAcceptSocket, socketId 121, us 10.34.164.185, peer  protocol 8
*SSL_accept:TLSv1.3 early data
*SSL_accept:SSLv3/TLS read client hello
*SSL_accept:SSLv3/TLS write server hello
*SSL_accept:TLSv1.3 write encrypted extensions
*SSL_accept:SSLv3/TLS write certificate request
*SSL_accept:SSLv3/TLS write certificate
*SSL_accept:TLSv1.3 write server certificate verify
*SSL_accept:SSLv3/TLS write finished
*SSL_accept:TLSv1.3 early data
*SSL_accept:error in TLSv1.3 early data
*SSL_accept:TLSv1.3 early data
*SSL_accept:SSLv3/TLS read client certificate
*SSL_accept:SSLv3/TLS read certificate verify
*SSL_accept:SSLv3/TLS read finished
*SSL handshake done undefined:SSLv3/TLS write session ticket  240
*New session created on sigport 2
*SSL_accept:SSLv3/TLS write session ticket
*SSL_SESSION_free ref
 *Session deleted on 2
*SSL3 alert write:fatal:internal error
*SSL_accept:error in error
*SSL error (78c0100): malloc failure
*ERROR on SSL_read err=1 flag=0
*Initiating SSL shutdown





I generated client and server certificates using below commands. And I used 
TLS_AES_128_GCM_SHA256 cipher.

CA Certificate:

openssl_rbbn ecparam -name prime256v1 -genkey -noout -out ca.key

openssl_rbbn req -new -x509 -sha256 -key ca.key -out ca.crt

openssl_rbbn x509 -in ca.crt -inform PEM -out pk-ca.crt.der -outform DER


Server Certificate:

openssl_rbbn ecparam -name prime256v1 -genkey -noout -out server.key

openssl_rbbn req -new -sha256 -key server.key -out server.csr

openssl_rbbn x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial 
-out server.crt -days 1000 -sha256



Client Certificate:

openssl_rbbn ecparam -name prime256v1 -genkey -noout -out client1.key

openssl_rbbn req -new -sha256 -key client1.key -out client1.csr

openssl_rbbn x509 -req -in client1.csr -CA ca.crt -CAkey ca.key -CAcreateserial 
-out client1.crt -days 1000 -sha256

Regards,
Ravi


Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

SSL error (78c0100): malloc failure while implementing tls 1.3

[Ramaiah, Ravichandran Bagalur]

Hi All,

I'm trying to implement tls 1.3 support in my application. But I'm facing 
malloc failure error.

Could you please help me understand why this error is happening? How to solve 
this issue?


*Set TLSv1.3 Cipher list TLS_AES_128_GCM_SHA256 ret 1
*SipCmOpenSSLNew: TLS, mutual auth, tlsSipAuthRequired = FALSE
*SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS for ssl is NOT set.
*SSL handshake started undefined:before SSL initialization 240
*SSL_accept:before SSL initialization
*SSL_accept:before SSL initialization
*SSL_accept:SSLv3/TLS read client hello
*SSL_accept:SSLv3/TLS write server hello
*SSL_accept:SSLv3/TLS write change cipher spec
*SSL_accept:TLSv1.3 early data
*SSL_accept:error in TLSv1.3 early data
*SipCmAcceptSocket, socketId 121, us 10.34.164.185, peer  protocol 8
*SSL_accept:TLSv1.3 early data
*SSL_accept:SSLv3/TLS read client hello
*SSL_accept:SSLv3/TLS write server hello
*SSL_accept:TLSv1.3 write encrypted extensions
*SSL_accept:SSLv3/TLS write certificate request
*SSL_accept:SSLv3/TLS write certificate
*SSL_accept:TLSv1.3 write server certificate verify
*SSL_accept:SSLv3/TLS write finished
*SSL_accept:TLSv1.3 early data
*SSL_accept:error in TLSv1.3 early data
*SSL_accept:TLSv1.3 early data
*SSL_accept:SSLv3/TLS read client certificate
*SSL_accept:SSLv3/TLS read certificate verify
*SSL_accept:SSLv3/TLS read finished
*SSL handshake done undefined:SSLv3/TLS write session ticket  240
*New session created on sigport 2
*SSL_accept:SSLv3/TLS write session ticket
*SSL_SESSION_free ref
 *Session deleted on 2
*SSL3 alert write:fatal:internal error
*SSL_accept:error in error
*SSL error (78c0100): malloc failure
*ERROR on SSL_read err=1 flag=0
*Initiating SSL shutdown





I generated client and server certificates using below commands. And I used 
TLS_AES_128_GCM_SHA256 cipher.

CA Certificate:

openssl_rbbn ecparam -name prime256v1 -genkey -noout -out ca.key

openssl_rbbn req -new -x509 -sha256 -key ca.key -out ca.crt

openssl_rbbn x509 -in ca.crt -inform PEM -out pk-ca.crt.der -outform DER


Server Certificate:

openssl_rbbn ecparam -name prime256v1 -genkey -noout -out server.key

openssl_rbbn req -new -sha256 -key server.key -out server.csr

openssl_rbbn x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial 
-out server.crt -days 1000 -sha256



Client Certificate:

openssl_rbbn ecparam -name prime256v1 -genkey -noout -out client1.key

openssl_rbbn req -new -sha256 -key client1.key -out client1.csr

openssl_rbbn x509 -req -in client1.csr -CA ca.crt -CAkey ca.key -CAcreateserial 
-out client1.crt -days 1000 -sha256

Regards,
Ravi


Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

Re: [openssl-users] Is there any standard way of getting the error name from an SSL error?

[Salz, Rich via openssl-users]

>For example, I want the string "SSL_R_TOO_MANY_WARN_ALERTS" for an
error with that value, not just the "too many alerts" description.
  
You're correct, it's not done.

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

[openssl-users] Is there any standard way of getting the error name from an SSL error?

[Sam Roberts]

For example, I want the string "SSL_R_TOO_MANY_WARN_ALERTS" for an
error with that value, not just the "too many alerts" description.

I'm suspecting not, I don't see any use of #reason in ERR_REASON() or
the macros it uses.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Open ssl error "hex string is too long invalid hex key value"

[Matt Caswell]

On 12/04/18 07:05, shagun maheshwari wrote:
> Hi,
> 
> We are getting an error "OpenSSL error hex string is too long invalid hex key 
> value" . OpenSSL version we are using is openssl-1.0.2k-8.el7. We have solved 
> this issue by applying a patch in openssl package suggested by openssl 
> community 
> (https://clicktime.symantec.com/a/1/7Fg4lSHbjGfkPSCbaHTn0_5SA3g7jIxY1-VykXIdKu0=?d=xVjLv3Egby2iJQ8Pps44kijPDpVNeq--5cgHmJMSt7fSfApR2--2rIk1xvvBJSwGIglcjn61v6-JXGiiMB8XDbwUXh0ZdrcNxdLZpZ4iydtMyQvgDDeJdBqNF31hW_gGSt77P5_qmJ2yJH6Z5ycJqZO-sUXRgdvObuqYlAKoqdLqFCSzKnR5BTUYw7C8JvfSp3kLE-Zbr3DSGCEz0KwUBfdYWjeH8n10a4bsKfA8cgMmRr6o9pBR66fciTOnTNJISKm5XTy6SWr9xlsKxJccrczY4TsEDL7AncqGJMaEHWBzFyRbsGWpZmsedW0xIJg0cDSkXGt4xJ3lTN26_iL2qBwfAOarzDrtJ2uQtfOgoszexm-ICb8y8VY23Y7xlvo-6awGNFuZX8xKABbpaB9Q&u=https%3A%2F%2Fmta.openssl.org%2Fpipermail%2Fopenssl-dev%2F2016-May%2F007266.html).
>  
> 
> In nwhich release of OpenSSL, we can expect this fix?
> 

The thread you point to doesn't describe a bug in 1.0.2. The command
line provided to OpenSSL in that thread is in error. The hex string
provided for the key is too long (by 2 bytes) so OpenSSL is doing the
right thing by issuing an error message. It seems that this was
tolerated in older versions of OpenSSL (1.0.1) - but that behaviour can
probably be considered a bug in those older (out of support) versions.

Matt

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

[openssl-users] Open ssl error "hex string is too long invalid hex key value"

[shagun maheshwari]

Hi,

We are getting an error "OpenSSL error hex string is too long invalid
hex key value" . OpenSSL version we are using is openssl-1.0.2k-8.el7.
We have solved this issue by applying a patch in openssl package
suggested by openssl community
(https://clicktime.symantec.com/a/1/7Fg4lSHbjGfkPSCbaHTn0_5SA3g7jIxY1-VykXIdKu0=?d=xVjLv3Egby2iJQ8Pps44kijPDpVNeq--5cgHmJMSt7fSfApR2--2rIk1xvvBJSwGIglcjn61v6-JXGiiMB8XDbwUXh0ZdrcNxdLZpZ4iydtMyQvgDDeJdBqNF31hW_gGSt77P5_qmJ2yJH6Z5ycJqZO-sUXRgdvObuqYlAKoqdLqFCSzKnR5BTUYw7C8JvfSp3kLE-Zbr3DSGCEz0KwUBfdYWjeH8n10a4bsKfA8cgMmRr6o9pBR66fciTOnTNJISKm5XTy6SWr9xlsKxJccrczY4TsEDL7AncqGJMaEHWBzFyRbsGWpZmsedW0xIJg0cDSkXGt4xJ3lTN26_iL2qBwfAOarzDrtJ2uQtfOgoszexm-ICb8y8VY23Y7xlvo-6awGNFuZX8xKABbpaB9Q&u=https%3A%2F%2Fmta.openssl.org%2Fpipermail%2Fopenssl-dev%2F2016-May%2F007266.html).

In nwhich release of OpenSSL, we can expect this fix?

Please help.


Regards,

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

Re: [openssl-users] SSL error “inappropriate fallback” and TLS_FALLBACK_SCSV

[Florin Andrei]

On 2017-06-01 12:23, Michael Wojcik wrote:


On the other hand, this doesn't really answer Florin's question of why
the server sees so many clients falling back. If the load is bursty,
it might be listen-queue dumping. I don't know if Nginx lets you
configure the listen queue depth, but at some point the stack will
start dropping connections (either silently, in the BSD or "correct"
manner; or with a RST, in the Winsock or "patently wrong" manner) if
the sustained load is too high. But unless this is a pretty busy
server or has a really high variance in its load distribution, it's
probably an intermediary node that's to blame.


Aggregate traffic has a smooth profile, with daily increase towards the 
middle of the day, and decrease towards midnight. Client sessions are 
typically short (way under 1 minute, perhaps most of them under 15 
seconds).


I don't see any errors related to what you're saying.


Or the clients have a really short timeout, or the connection's being
aborted by the user and the client is incorrectly falling back when
that happens. Though then I'd assume Florin would see that in the
Nginx logs, assuming it logs ECONNRESET.


Well, I'm digging through the logs. The one thing I see often is:

client X.Y.Z.K closed keepalive connection

Not much other than that, and these are really "severity:info" events, I 
see them even with TLS termination at the ALB.


I see some amount of...

peer closed connection in SSL handshake while SSL handshaking

...also a "severity:info" event, at a rate about 4x less than the 
“inappropriate fallback” stuff.


(shrug) Seems normal.

As a more informal argument: We're using whatever Amazon deemed 
appropriate for their TLS policy for load balancers, in terms of 
protocol versions and ciphers. Surely if there was a problem with 
versions or ciphers, we'd hear about it, or they would change it 
quickly, just based on the amount of traffic they receive every day. 
That was the main reason why I've found hard to accept that this rate of 
TLS errors is somehow normal; but now I think I start to understand this 
aspect of the protocol thanks to the excellent explanations I've seen 
early in this discussion.


--
Florin Andrei
http://florin.myip.org/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] SSL error “inappropriate fallback” and TLS_FALLBACK_SCSV

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Salz, Rich via openssl-users
> Sent: Thursday, June 01, 2017 14:44
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] SSL error “inappropriate fallback” and 
> TLS_FALLBACK_SCSV
> 
> > Would clients actually attempt to send TLS_FALLBACK_SCSV even if the
> > previous connection attempt failed for reasons other than TLS? If, say, the
> > initial connection attempt failed at the TCP level? That sounds a little 
> > strange
> > to me.
> 
> Yes they do.

And they should, *if* they have actually fallen back to an older protocol 
version, because an attacker with the appropriate affordance (e.g. a 
compromised router along the path) could easily trigger a TCP failure by 
sending a RST. Any time the client falls back, it should include 
TLS_FALLBACK_SCSV in its cipher-suite list.

The question is whether a client that supports fallback (and there's much 
debate over whether clients should support fallback, particularly in the 
default configuration) ought to try falling back in response to a TCP failure. 
On the one hand, it's entirely possible that a broken old server would reject 
an unrecognized protocol version by simply aborting the connection. On the 
other, there are a lot of other reasons for a RST, and falling back as the 
first resort seems rather hasty.

Personally, I'd prefer clients not try to fall back at all, except perhaps 
clients that have a reasonable need to support broken servers, and even then 
only with some non-default configuration. Browser manufacturers will argue that 
they have to support fallback in order to support broken web servers, but I 
think that's dubious.

> There are many badly written clients out there.  Or poor libraries.

Very true.

On the other hand, this doesn't really answer Florin's question of why the 
server sees so many clients falling back. If the load is bursty, it might be 
listen-queue dumping. I don't know if Nginx lets you configure the listen queue 
depth, but at some point the stack will start dropping connections (either 
silently, in the BSD or "correct" manner; or with a RST, in the Winsock or 
"patently wrong" manner) if the sustained load is too high. But unless this is 
a pretty busy server or has a really high variance in its load distribution, 
it's probably an intermediary node that's to blame.

Or the clients have a really short timeout, or the connection's being aborted 
by the user and the client is incorrectly falling back when that happens. 
Though then I'd assume Florin would see that in the Nginx logs, assuming it 
logs ECONNRESET.

Really there are too many possibilities to make speculation worthwhile. But now 
that I've written all this I suppose I'll send it.

Michael Wojcik 
Distinguished Engineer, Micro Focus 


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

Re: [openssl-users] SSL error “inappropriate fallback” and TLS_FALLBACK_SCSV

[Salz, Rich via openssl-users]

> What I find surprising is the rate of these errors. For every 100 legitimate
> HTTP requests that make it to Nginx, I get 2.5 “inappropriate fallback” SSL
> errors. That's a lot of noise.
> 
> I guess I'll have to adjust my expectations.

That's not out of line with other measurements I've been told.
 
> Related question: assuming the lists of TLS protocol versions and ciphers I've
> enabled in Nginx are indeed exactly the same as the default TLS policy in an
> AWS ALB, the errors I see now logged by Nginx should be, more or less, the
> same population of errors I saw reflected in the ALB metrics before, right?

Not necessarily.  The network connectivity could be a very large influence.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] SSL error “inappropriate fallback” and TLS_FALLBACK_SCSV

[Florin Andrei]

On 2017-06-01 11:43, Salz, Rich via openssl-users wrote:

Would clients actually attempt to send TLS_FALLBACK_SCSV even if the
previous connection attempt failed for reasons other than TLS? If, 
say, the
initial connection attempt failed at the TCP level? That sounds a 
little strange

to me.


Yes they do.

There are many badly written clients out there.  Or poor libraries.


What I find surprising is the rate of these errors. For every 100 
legitimate HTTP requests that make it to Nginx, I get 2.5 “inappropriate 
fallback” SSL errors. That's a lot of noise.


I guess I'll have to adjust my expectations.

Related question: assuming the lists of TLS protocol versions and 
ciphers I've enabled in Nginx are indeed exactly the same as the default 
TLS policy in an AWS ALB, the errors I see now logged by Nginx should 
be, more or less, the same population of errors I saw reflected in the 
ALB metrics before, right? The whole point of this exercise is to 
temporarily work around the lack of a TLS error log in an ALB. The error 
rate does seem quite similar between ALB and Nginx. I'm just wondering 
if the ALB is doing something that my standard Ubuntu openssl libraries 
are not.


--
Florin Andrei
http://florin.myip.org/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] SSL error “inappropriate fallback” and TLS_FALLBACK_SCSV

[Salz, Rich via openssl-users]

> Would clients actually attempt to send TLS_FALLBACK_SCSV even if the
> previous connection attempt failed for reasons other than TLS? If, say, the
> initial connection attempt failed at the TCP level? That sounds a little 
> strange
> to me.

Yes they do.

There are many badly written clients out there.  Or poor libraries.

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

Re: [openssl-users] SSL error “inappropriate fallback” and TLS_FALLBACK_SCSV

[Florin Andrei]

On 2017-06-01 02:13, Matt Caswell wrote:


The presence of this error doesn't actually mean that you are under
attack. It just means that the client made an earlier connection 
attempt

with a higher version number and it failed. There could be many reasons
for the failure. For example, plausibly, if you have a lot of mobile
clients then you could imagine that a network glitch could cause an
earlier attempt to fail.


It's interesting how I see a constant stream of “inappropriate fallback” 
errors in the logs, but this is pretty much the only error from a TLS 
perspective. Sure, there's the occasional certificate failure, like once 
every few minutes or so, and then, rarely, there's some ancient app 
trying SSLv3 (which is not enabled). But looking at the Nginx error.log 
the “inappropriate fallback” is basically the only error I get a 
perpetual flow of.


If the TLS_FALLBACK_SCSV attempt is caused by a previously failed 
connection, that must have been something different from a TLS error, 
because “inappropriate fallback” is probably over 99% of the lines in 
error.log - it's the only thing I see as logs are scrolling up in my 
viewer.


Would clients actually attempt to send TLS_FALLBACK_SCSV even if the 
previous connection attempt failed for reasons other than TLS? If, say, 
the initial connection attempt failed at the TCP level? That sounds a 
little strange to me.


Again, our clients are a mix of the average mobile devices in general 
use these days.


--
Florin Andrei
http://florin.myip.org/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] SSL error “inappropriate fallback” and TLS_FALLBACK_SCSV

[Matt Caswell]

On 01/06/17 02:58, Florin Andrei wrote:
> It's a little puzzling because the exchange of crypto messages uses TLS
> 1.0 which the server definitely supports, and the client should be very
> likely to support too.
> 
> I've seen discussions online saying that the presence of the
> TLS_FALLBACK_SCSV cipher suite is an indication that this failed
> connection is related to anti-POODLE security measures, and the
> communication is likely to be retried again. Is that correct?

"Normal" TLS version negotiation works like this (ignoring TLSv1.3 which
isn't relevant for this discussion): the client sends the maximum TLS
version that it supports in its ClientHello message (this should not be
confused with the version number in the record header). The server
responds with a ServerHello containing the maximum version that it
supports and which is less than or equal to the client's maximum version
number.

For example, if the client supports TLSv1.2 but the server only supports
TLSv1.0, then the ClientHello version will be TLSv1.2 and the server
will respond with TLSv1.0. On the other hand if the client only supports
TLSv1.0 but the server supports TLSv1.2, then the ClientHello version
will be TLSv1.0 and the ServerHello version will also be TLSv1.0.

This is all fine but there are some servers out there which are buggy
and abort the connection if the ClientHello version is bigger than the
maximum version that the server supports. To work around this some
clients will do "fallback". So, they start with a ClientHello version of
TLSv1.2. If the connection aborts then they might send another one with
a version of TLSv1.1. If that aborts then TLSv1.0.

The problem with that approach is that it can be exploited by an
attacker. An attacker may be able to exploit some weakness in an earlier
TLS version which is fixed in a later version. The attacker may then be
able to modify the traffic to ensure that a TLSv1.2 ClientHello fails in
order to force the client to fallback to the earlier exploitable version.

The TLS_FALLBACK_SCSV ciphersuite is used as a counter measure to that
type of attack. A client will include it if it is sending a ClientHello
with a max version that is lower than the maximum that the client
actually supports (because an earlier attempt with the higher version
number failed). If a server receives a TLS_FALLBACK_SCSV ciphersuite in
a ClientHello and it supports a higher version than the one in the
ClientHello then there should have been no reason for the client to
fallback and you get the "inappropriate fallback" error.

The presence of this error doesn't actually mean that you are under
attack. It just means that the client made an earlier connection attempt
with a higher version number and it failed. There could be many reasons
for the failure. For example, plausibly, if you have a lot of mobile
clients then you could imagine that a network glitch could cause an
earlier attempt to fail.

Matt



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

[openssl-users] SSL error “inappropriate fallback” and TLS_FALLBACK_SCSV

[Florin Andrei]

A bit of context:

I have this endpoint behind an AWS ALB. I do SSL termination at the ALB. 
To my surprise, when looking at the client_tlsnegotiation_error_count 
metric for the ALB, I've noticed a substantial amount of failed 
connection attempts due to TLS negotiation errors - perhaps around 5% of 
total traffic but this estimate could be wrong by a substantial margin.


The clients are mostly an average cross-section of current mobile 
devices in use these days in the US.


The ALB is configured with the default TLS policy that Amazon provides:

| ssl-enum-ciphers:
|   TLSv1.0:
| ciphers:
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| compressors:
|   NULL
| cipher preference: server
|   TLSv1.1:
| ciphers:
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| compressors:
|   NULL
| cipher preference: server
|   TLSv1.2:
| ciphers:
|   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|   TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| compressors:
|   NULL
| cipher preference: server
|_  least strength: A

Unfortunately, ALBs do not provide error logs, so I could not directly 
identify why some clients are failing the SSL negotiation.


Instead, I've pushed SSL termination deeper into the stack, to the Nginx 
frontend, and replaced the ALB with a plain TCP-based ELB. Now 
connections to port 443 are forwarded directly to Nginx for SSL 
negotiation.


I've configured Nginx with the exact same protocol versions and ciphers 
like the ALB:


ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 
'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA';

ssl_prefer_server_ciphers on;

I've verified with nmap and I get the same ssl-enum-ciphers list from 
Nginx.


Now in the Nginx error log I get lots of lines like this:

    SSL_do_handshake() failed (SSL: error:140A1175:SSL 
routines:ssl_bytes_to_cipher_list:inappropriate fallback) while SSL 
handshaking


Still not very informative, so I've run tcpdump on port 443 on the Nginx 
instances. As expected, there's some amount of SSL errors like this:


Secure Sockets Layer
TLSv1 Record Layer: Alert (Level: Fatal, Description: 
Inappropriate Fallback)

Content Type: Alert (21)
Version: TLS 1.0 (0x0301)
Length: 2
Alert Message
Level: Fatal (2)
Description: Inappropriate Fallback (86)

In that same TCP stream there's this Client Hello packet:

Secure Sockets Layer
TLSv1 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 165
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 161
Version: TLS 1.0 (0x0301)
Random
GMT Unix Time: Jun  7, 2050 12:50:05.0 PST
Random Bytes: 
da03ff7045a5f76e78edf61c097c75e4e141df6649ef1861...

Session ID Length: 0
Cipher Suites Length: 28
Cipher Suites (14 suites)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA 
(0xc00a)
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_ECDHE_RSA_WITH_AES_256_CBC_SHA 
(0xc014)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_S

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  on behalf of Viktor 
Dukhovni 
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)
Length: 4
EC point formats Length: 3
 

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 (0x0019)

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: TLS handshake error : No shared cipher (SSL error 40)

[Francis GASCHET]

Hello,

Thank to both of you.

Best regards,
--
Francis
Le 17/09/2014 20:38, Dave Thompson a écrit :

From: owner-openssl-us...@openssl.org On Behalf Of Francis GASCHET
Sent: Wednesday, September 17, 2014 13:35
We use openSSL in OFTP2 implementation. The OFTP2 working group
decided
to strongly recommend to use preferably the cipher suites including PFS
(ephemeral Diffie Hellman).



To date*, in order to agree a DH-ephemeral or ECDH-ephemeral suite,
the server must be configured with "temporary" DH/ECDH parameters:
https://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html
tmp_ecdh* is similar but has no manpage. Is it?

For ECDHE, the temporary parameters must be a curve allowed by the
client's list of supported curves. For openssl clients (except RedHat)
all standard "named" curves are allowed, but other clients may differ.
P-256 and P-384, and maybe P-521, seem to be most widely supported,
and therefore probably the best choices in general.

* 1.0.2 is expected to have some more convenient options in this area.



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



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

RE: TLS handshake error : No shared cipher (SSL error 40)

[Dave Thompson]

> From: owner-openssl-us...@openssl.org On Behalf Of Francis GASCHET
> Sent: Wednesday, September 17, 2014 13:35

> We use openSSL in OFTP2 implementation. The OFTP2 working group
> decided
> to strongly recommend to use preferably the cipher suites including PFS
> (ephemeral Diffie Hellman).


To date*, in order to agree a DH-ephemeral or ECDH-ephemeral suite, 
the server must be configured with "temporary" DH/ECDH parameters:
https://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html
tmp_ecdh* is similar but has no manpage. Is it?

For ECDHE, the temporary parameters must be a curve allowed by the 
client's list of supported curves. For openssl clients (except RedHat) 
all standard "named" curves are allowed, but other clients may differ. 
P-256 and P-384, and maybe P-521, seem to be most widely supported,
and therefore probably the best choices in general.

* 1.0.2 is expected to have some more convenient options in this area.



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

Re: TLS handshake error : No shared cipher (SSL error 40)

[Viktor Dukhovni]

On Wed, Sep 17, 2014 at 07:34:44PM +0200, Francis GASCHET wrote:

> We use openSSL in OFTP2 implementation. The OFTP2 working group decided to
> strongly recommend to use preferably the cipher suites including PFS
> (ephemeral Diffie Hellman).

Preferably, does not mean exclusively.  You should probably not
exclude non-PFS cipher suites for interoperability reasons.

> So in our implementation (linked against openssl 1.0.1g) I limited the list
> of offered ciphers (client) and preferred ciphers (server) to:
>
>DHE-RSA-AES256-SHA,
>EDH-RSA-DES-CBC3-SHA
>DHE-RSA-AES128-SHA
>ECDHE-RSA-AES256-SHA
>ECDHE-RSA-DES-CBC3-SHA
>ECDHE-RSA-AES128-SHA,
>
> using SSL_CTX_set_cipher_list.
> 
> But on the legacy software side (linked against openSSL V0.9.8c),

Which does not support ECDHE, and probably is not configured with
DHE parameters, and hence does not support any of these.

> the server rejects the connection with the "No shared cipher" error.

As expected.

> On this site, the command "openssl ciphers" says that DHE-RSA-AES128-SHA and
> EDH-RSA-DES-CBC3-SHA are supported(among others).

These require configuration of server-side temp DH parameters.

> It is the same when I reverse the roles : the legacy binary becomes the
> client.In that case, wireshark shows TLS_DHE_RSA_WITH_AES_256_CBC_SHA and
> TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA in the offered list of cipher suites (among
> others).
>
> But the "restricted" binary rejects the connection with the same error.
> On this side, the same list of ciphers (listed above) are specified before
> accepting the connection (server)than before calling out (client).

Once again to use DHE, the server must set temp DH parameters, and
to use ECDHE must select a temp ECDH curve.

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

TLS handshake error : No shared cipher (SSL error 40)

[Francis GASCHET]

Hello,

We use openSSL in OFTP2 implementation. The OFTP2 working group decided 
to strongly recommend to use preferably the cipher suites including PFS 
(ephemeral Diffie Hellman).
So in our iplementation (linked against openssl 1.0.1g) I limited the 
list of offered ciphers (client) and prefered ciphers (server) to : 
"DHE-RSA-AES256-SHA:EDH-RSA-DES-CBC3-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-RSA-AES128-SHA:" 
using SSL_CTX_set_cipher_list.


On this "restricted" binary it looks fine : only these ciphers are 
presented in the client hello:

TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

But on the legacy software side (linked against openSSL V0.9.8c), the 
server rejects the connection with the "No shared cipher" error.
On this site, the command "openssl ciphers" says that DHE-RSA-AES128-SHA 
and EDH-RSA-DES-CBC3-SHA are supported(among others).

So 2 ciphersuites are shared...
BTW: In this version of the software, the default list is in use 
(SSL_CTX_set_cipher_list is not called).


It is the same when I reverse the roles : the legacy binary becomes the 
client.In that case, wireshark shows TLS_DHE_RSA_WITH_AES_256_CBC_SHA 
and TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHAin the offered list of cipher 
suites (among others).

But the "restricted" binary rejects the connection with the same error.
On this side, the same list of ciphers (listed above) are specified 
before accepting the connection (server)than before calling out (client).


So I'm lost !

Thank you in advance for help.

--
Francis

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

Re: SSL error after machine restart.

[Jakob Bohm]

On 31-07-2013 11:16, Rajeev Tomar wrote:

Hi
>
We are using openssl 0.9.8 in our application.
Things are working fine and suddenly we are having .
Linux awtah.dispatchserver1 3.6.11-1.fc16.i686 #1 SMP Mon Dec 17 
21:36:23 UTC 2012 i686 i686 i386 GNU/Linux
error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad 
record mac:s3_pkt.c:426:
error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version 
number:s3_pkt.c:288:
error:1408F096:SSL routines:SSL3_GET_RECORD:encrypted length too 
long:s3_pkt.c:346:

this error was random.
Even though application uses it’s own opnesssl 0.9.8 and M/C have 
1.0.0j-fips.

Two things to check:

- Use the command "cut -c 50- /proc//maps | uniq" (Change 50 to 74
on 64-bit kernels) to make sure your application is not loading a dynamic
libcrypt or libssl anyway.

- If your application uses the shared certificate trust store in
/etc/ssl/certs, note that OpenSSL 1 and OpenSSL 0.9 use incompatible
formats for the symlinks in that directory, so either you need to use
a different directory for your OpenSSL 0.9 applications or you need
some special tricks to set up a combined directory.


-bash-4.2# openssl version -a
OpenSSL 1.0.0j-fips 10 May 2012
built on: Tue May 15 18:44:01 UTC 2012
platform: linux-elf
options: bn(64,32) md2(int) rc4(8x,mmx) des(ptr,risc1,16,long) 
blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS 
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DL_ENDIAN -DTERMIO 
-Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 
-mtune=atom -fasynchronous-unwind-tables -Wa,--noexecstack 
-DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM 
-DWHIRLPOOL_ASM

OPENSSLDIR: "/etc/pki/tls"
engines: aesni dynamic
On reinstalling 1.0.0j-fips on this Machine error got fixed.
Now for the same application on Fedora 14, after reboot we have 
encountered the above problem.
Linux 3UPCAWT605 2.6.35.6-45.fc14.i686 #1 SMP Mon Oct 18 23:56:17 UTC 
2010 i686 i686 i386 GNU/Linux

Any pointer what is the root cause of this problem or how to fix this.
Open SSL installed on second M/C
built on: Wed Sep 7 18:59:14 UTC 2011
platform: linux-elf
options: bn(64,32) md2(int) rc4(8x,mmx) des(ptr,risc1,16,long) 
blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS 
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DL_ENDIAN -DTERMIO 
-Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 
-mtune=atom -fasynchronous-unwind-tables -Wa,--noexecstack 
-DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM 
-DWHIRLPOOL_ASM

OPENSSLDIR: "/etc/pki/tls"
engines: aesni dynamic



Enjoy

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

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

SSL error after machine restart.

[Rajeev Tomar]

Hi

We are using openssl 0.9.8 in our application.
Things are working fine and suddenly we are having .

Linux awtah.dispatchserver1 3.6.11-1.fc16.i686 #1 SMP Mon Dec 17 21:36:23 UTC 
2012 i686 i686 i386 GNU/Linux

error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record 
mac:s3_pkt.c:426:
error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:288:
error:1408F096:SSL routines:SSL3_GET_RECORD:encrypted length too 
long:s3_pkt.c:346:

this error was random.
Even though application uses it's own opnesssl 0.9.8 and M/C have 1.0.0j-fips.
-bash-4.2# openssl version -a
OpenSSL 1.0.0j-fips 10 May 2012
built on: Tue May 15 18:44:01 UTC 2012
platform: linux-elf
options:  bn(64,32) md2(int) rc4(8x,mmx) des(ptr,risc1,16,long) blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT 
-DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe 
-Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom 
-fasynchronous-unwind-tables -Wa,--noexecstack -DOPENSSL_BN_ASM_PART_WORDS 
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
-DMD5_ASM -DRMD160_ASM -DAES_ASM -DWHIRLPOOL_ASM
OPENSSLDIR: "/etc/pki/tls"
engines:  aesni dynamic

On reinstalling 1.0.0j-fips on this Machine error got fixed.


Now for the same application on Fedora 14, after reboot we have encountered the 
above problem.
Linux 3UPCAWT605 2.6.35.6-45.fc14.i686 #1 SMP Mon Oct 18 23:56:17 UTC 2010 i686 
i686 i386 GNU/Linux

Any pointer what is the root cause of this problem or how to fix this.
Open SSL installed on second M/C
built on: Wed Sep  7 18:59:14 UTC 2011
platform: linux-elf
options:  bn(64,32) md2(int) rc4(8x,mmx) des(ptr,risc1,16,long) blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT 
-DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe 
-Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom 
-fasynchronous-unwind-tables -Wa,--noexecstack -DOPENSSL_BN_ASM_PART_WORDS 
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
-DMD5_ASM -DRMD160_ASM -DAES_ASM -DWHIRLPOOL_ASM
OPENSSLDIR: "/etc/pki/tls"
engines:  aesni dynamic

Is there any configuration changes need to be done/service need to be restarted.
With Regards
Rajeev Tomar

Team Automation
"Turning Possibilities Into Realites"






===
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===

Re: SSL error: SSL error code 336151528 (a seemingly rare error/bug?)

[Marek . Marcola]

Hello,

$ echo "obase=16;336151528" | bc
140943E8
$ openssl errstr 140943E8
error:140943E8:SSL routines:SSL3_READ_BYTES:reason(1000)

Best regards,
--
Marek Marcola 

owner-openssl-us...@openssl.org wrote on 03/27/2012 01:09:56 AM:

> Blake Mizerany  
> Sent by: owner-openssl-us...@openssl.org
> 
> 03/27/2012 09:24 AM
> 
> Please respond to
> openssl-users@openssl.org
> 
> To
> 
> openssl-users@openssl.org
> 
> cc
> 
> Subject
> 
> SSL error: SSL error code 336151528 (a seemingly rare error/bug?)
> 
> While working on postgres driver in Go, I began getting these errors
> in my postgres logs:
> "SSL error: SSL error code 336151528"
> 
> I spoke with a postgres team member and they aren't sure exactly where
> this is coming from.
> A little more research on my side found someone else getting a very
> similar error on OS X:
> http://www.mail-archive.com/freebsd-questions@freebsd.org/msg14704.html
> 
> Triangulation of the error points to OpenSSL right now.
> 
> Any thoughts/help would be very much appreciated.
> I don't have a deep understanding of SSL so I'm not sure I'll be able
> to find the root of the problem; but will keep looking.
> 
> -blake
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager   majord...@openssl.org

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

SSL error: SSL error code 336151528 (a seemingly rare error/bug?)

[Blake Mizerany]

While working on postgres driver in Go, I began getting these errors
in my postgres logs:
"SSL error: SSL error code 336151528"

I spoke with a postgres team member and they aren't sure exactly where
this is coming from.
A little more research on my side found someone else getting a very
similar error on OS X:
http://www.mail-archive.com/freebsd-questions@freebsd.org/msg14704.html

Triangulation of the error points to OpenSSL right now.

Any thoughts/help would be very much appreciated.
I don't have a deep understanding of SSL so I'm not sure I'll be able
to find the root of the problem; but will keep looking.

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

RE: Please Help me out- SSL ERROR

[Dave Thompson]

> From: owner-openssl-us...@openssl.org On Behalf Of Mr.Rout
> Sent: Wednesday, 18 January, 2012 02:52

> root@1143726:/usr/bin# openssl s_client -connect 10.204.4.69:7003
> WARNING: can't open config file: /usr/ssl/openssl.cnf
> CONNECTED(0003)
> depth=0 C = IN, ST = Karnataka, L = Bangalore, O = Airvana, 
> CN = 10.204.4.69
> verify error:num=20:unable to get local issuer certificate

> Certificate chain
>  0 s:/C=IN/ST=Karnataka/L=Bangalore/O=Airvana/CN=10.204.4.69
>i:/C=IN/ST=Karnataka/L=Bangalore/O=Airvana/CN=Root CA

> My Set up looks like this.
>  e.g.  Certificate Chain  would be , ROOT- > Server ( I  
> keep ROOT at
> CLIENT and Server cert at SERVER). Am I right ?
> 
Yes, at least for server auth. If you use client auth,
which is not very common, then *also* have the client cert 
at the client and its root at the server. 

> [root@squidpc TEST]# openssl x509 -in root.pem -text


> Please let me know what is missing here & why i am getting 
> the above error.
> 
Either specify -CAfile root.pem on the s_client commandline
OR put that root cert in the default truststore which is used 
when you don't specify -CAfile and/or -CApath on the commandline.
The default truststore can be a single file or a directory with 
hashcode names or links or both, and is in a location that depends 
on your platform and the build options of your OpenSSL.


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

Please Help me out- SSL ERROR

[Mr.Rout]

ntext: 
http://old.nabble.com/Please-Help-me-out--SSL-ERROR-tp33159464p33159464.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

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

Re: Open SSL Error 14094412

[David Mitchell]

On 05/31/2011 03:02 PM, David Mitchell wrote:
> 
> On May 31, 2011, at 2:32 PM, Dave Thompson wrote:
> 
>>> From: owner-openssl-us...@openssl.org On Behalf Of David Mitchell
>>> Sent: Friday, 27 May, 2011 12:35
>>
>>> I'm having some problems with EAP-TLS in FreeRadius 2.1.10. I 
>>> have a client
>>> where authentication attempts always fail with the relatively generic
>>> error below. I've tried to figure out what it means with no 
>>> luck. A search
>>> of the source shows that the error code (ultimately 1042) is 
>>> defined but
>>> only used in one place, in ssl_err.c assigns the text version of the
>>> error code.  Can anybody point me to where in the code
>>> this error gets generated? Thanks in advance.
>>>
>> ssl3_read_bytes sets error 1000+alertnum for received fatal alerts.
>> alert 42 is "bad certificate" so error 1042 is "alert: bad certificate".
>>
>> The client is saying it doesn't like the cert the server is supplying.
>> Since other clients are working, the (a?) cert is clearly good.
>>
>> See if the client has more-detailed information in a log or something, 
>> and/or check client configuration especially the CA cert(s) it trusts. 
>> If your server has multiple certs/keys for different algorithms, 
>> check if this client is preferring the same algorithms/ciphersuites 
>> as the (other) clients that work.
> 
> Knowing that it is a client error and not a server error should help point us
> in the right direction. So far the client logs have been mostly worthless.
> That said, we have not been looking at possible trust issues with respect to
> the server certificate being accepted as valid on the client. We will look
> at that next. Thanks for your help.

The client did turn out to be rejecting the server's certificate due to
an unknown CA. Thanks again for your help,

-David Mitchell

> 
> 
> -
> | David Mitchell (mitch...@ucar.edu)   Network Engineer IV  |
> | Tel: (303) 497-1845  National Center for  |
> | FAX: (303) 497-1818  Atmospheric Research |
> -
> 
> 
> 
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager   majord...@openssl.org

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

Re: Open SSL Error 14094412

[David Mitchell]

On May 31, 2011, at 2:32 PM, Dave Thompson wrote:

>> From: owner-openssl-us...@openssl.org On Behalf Of David Mitchell
>> Sent: Friday, 27 May, 2011 12:35
> 
>> I'm having some problems with EAP-TLS in FreeRadius 2.1.10. I 
>> have a client
>> where authentication attempts always fail with the relatively generic
>> error below. I've tried to figure out what it means with no 
>> luck. A search
>> of the source shows that the error code (ultimately 1042) is 
>> defined but
>> only used in one place, in ssl_err.c assigns the text version of the
>> error code.  Can anybody point me to where in the code
>> this error gets generated? Thanks in advance.
>> 
> ssl3_read_bytes sets error 1000+alertnum for received fatal alerts.
> alert 42 is "bad certificate" so error 1042 is "alert: bad certificate".
> 
> The client is saying it doesn't like the cert the server is supplying.
> Since other clients are working, the (a?) cert is clearly good.
> 
> See if the client has more-detailed information in a log or something, 
> and/or check client configuration especially the CA cert(s) it trusts. 
> If your server has multiple certs/keys for different algorithms, 
> check if this client is preferring the same algorithms/ciphersuites 
> as the (other) clients that work.

Knowing that it is a client error and not a server error should help point us
in the right direction. So far the client logs have been mostly worthless.
That said, we have not been looking at possible trust issues with respect to
the server certificate being accepted as valid on the client. We will look
at that next. Thanks for your help.


-
| David Mitchell (mitch...@ucar.edu)   Network Engineer IV  |
| Tel: (303) 497-1845  National Center for  |
| FAX: (303) 497-1818  Atmospheric Research |
-



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

RE: Open SSL Error 14094412

[Dave Thompson]

> From: owner-openssl-us...@openssl.org On Behalf Of David Mitchell
> Sent: Friday, 27 May, 2011 12:35

> I'm having some problems with EAP-TLS in FreeRadius 2.1.10. I 
> have a client
> where authentication attempts always fail with the relatively generic
> error below. I've tried to figure out what it means with no 
> luck. A search
> of the source shows that the error code (ultimately 1042) is 
> defined but
> only used in one place, in ssl_err.c assigns the text version of the
> error code.  Can anybody point me to where in the code
> this error gets generated? Thanks in advance.
> 
ssl3_read_bytes sets error 1000+alertnum for received fatal alerts.
alert 42 is "bad certificate" so error 1042 is "alert: bad certificate".

The client is saying it doesn't like the cert the server is supplying.
Since other clients are working, the (a?) cert is clearly good.

See if the client has more-detailed information in a log or something, 
and/or check client configuration especially the CA cert(s) it trusts. 
If your server has multiple certs/keys for different algorithms, 
check if this client is preferring the same algorithms/ciphersuites 
as the (other) clients that work.



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

Open SSL Error 14094412

[David Mitchell]

Greetings,

I'm having some problems with EAP-TLS in FreeRadius 2.1.10. I have a client
where authentication attempts always fail with the relatively generic
error below. I've tried to figure out what it means with no luck. A search
of the source shows that the error code (ultimately 1042) is defined but
only used in one place, in ssl_err.c assigns the text version of the
error code. Beyond that I can't find any reference to this specific error
code. The function in question, ssl3_read_bytes(), has lots of places
it returns more specific error codes but I can't find any piece of code
where it returns this specific one. As a result I'm kind of stumped as to
what exactly is going wrong. Can anybody point me to where in the code
this error gets generated? Thanks in advance.

Fri May 27 10:17:51 2011 : Info: [tls] <<< TLS 1.0 Alert [length 0002], fatal 
bad_certificate  
Fri May 27 10:17:51 2011 : Error: TLS Alert read:fatal:bad certificate
Fri May 27 10:17:51 2011 : Error: TLS_accept: failed in SSLv3 read client 
certificate A
Fri May 27 10:17:51 2011 : Error: rlm_eap: SSL error error:14094412:SSL 
routines:SSL3_READ_BYTES:sslv3 alert bad certificate
Fri May 27 10:17:51 2011 : Error: SSL: SSL_read failed inside of TLS (-1), TLS 
session fails.
Fri May 27 10:17:51 2011 : Debug: TLS receive handshake failed during operation

-
| David Mitchell (mitch...@ucar.edu)   Network Engineer IV  |
| Tel: (303) 497-1845  National Center for  |
| FAX: (303) 497-1818  Atmospheric Research |
-



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

Re: SSL error no start line

[Victor Duchovni]

On Tue, Mar 29, 2011 at 10:15:04AM +0200, Aarno Syv?nen wrote:

> HI,
> 
> what would error OpenSSL: error:0906D06C:PEM routines:PEM_read_bio:no start 
> line mean ?

A PEM file was expected, but the input was not a PEM file, specifically,
it had no "-BEGIN ...-" line.

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

SSL error no start line

[Aarno Syvänen]

HI,

what would error OpenSSL: error:0906D06C:PEM routines:PEM_read_bio:no start 
line mean ?

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

Re: SSL error: parse tlsext

[Florent Georges]

Dr. Stephen Henson wrote:

> > > openssl s_client -connect xxx.org:443

> > > and it should say if secure renegotiation is supported in
> > > the output.

> >   Thanks for the tip!  I tried, but I am afraid I cannot tell
> > whether it is the case or not, based on this output.  I tried
> > on google.com:443 as well to be sure that was not because the
> > other server, but I didn't find neither such info.  Do you
> > know what I must look for in the output of -connect ?

> After the line saying "Server public key is xxx bit" you should
> see:

> Secure Renegotiation IS supported
> or
> Secure Renegotiation IS NOT supported

> you need OpenSSL 1.0.0 or 0.9.8m or later to do this.

  Thanks.  I had to compile a newer version than the one coming
with Snow Leopard (which is just 0.9.8l :-p).  And you're right,
the server does not support the secure renegotiation.  As Open
SSL on that server is part of the system package management, I
did prefer not to upgrade it by hand, but you put me on the
correct way...  I instead temporarily enabled SVN access through
HTTP (anyway the content is readable by anyone).

  Thanks for your help, regards,

-- 
Florent Georges
http://www.fgeorges.org























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

SSL error: parse tlsext

[Florent Georges]

  Hi,

  I am using openssl from within neon, itself used from within
Subversion.  During an svnsync, I receive the following error
message:

svnsync: PROPFIND of '/svn/xxx': SSL negotiation failed: SSL
error: parse tlsext (https://xxx.org)

  If I am right, this message comes from openssl.  Is it really
an error reported by openssl?  If it is, is there anything I can
do to either solve the problem or at least get more informations
about the context of the error?

  I am ready to compile myself the source packages if needed (and
actually I did to be sure the TLS extensions where enabled during
the build process, but still getting this error).  I am under Mac
OS X Snow Leopard.

  Thanks in advance, regards,

-- 
Florent Georges
http://www.fgeorges.org/



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

Re: SSL error: parse tlsext

[Dr. Stephen Henson]

On Wed, Apr 07, 2010, Florent Georges wrote:

> Dr. Stephen Henson wrote:
> 
>   Thanks for your fast response!
> 
> > That looks like it is only part of the actual error code.
> 
>   That's all I have.  I guess either Subversion or Neon truncates
> the error message.
> 
> > I suspect it is because the server doesn't support secure
> > renegotiation.  You can check this by doing:
> 
> > openssl s_client -connect xxx.org:443
> 
> > and it should say if secure renegotiation is supported in the
> > output.
> 
>   Thanks for the tip!  I tried, but I am afraid I cannot tell
> whether it is the case or not, based on this output.  I tried on
> google.com:443 as well to be sure that was not because the other
> server, but I didn't find neither such info.  Do you know what I
> must look for in the output of -connect ?
> 

After the line saying "Server public key is xxx bit" you should see:

Secure Renegotiation IS supported

or

Secure Renegotiation IS NOT supported

you need OpenSSL 1.0.0 or 0.9.8m or later to do this.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: SSL error: parse tlsext

[Florent Georges]

Dr. Stephen Henson wrote:

  Thanks for your fast response!

> That looks like it is only part of the actual error code.

  That's all I have.  I guess either Subversion or Neon truncates
the error message.

> I suspect it is because the server doesn't support secure
> renegotiation.  You can check this by doing:

> openssl s_client -connect xxx.org:443

> and it should say if secure renegotiation is supported in the
> output.

  Thanks for the tip!  I tried, but I am afraid I cannot tell
whether it is the case or not, based on this output.  I tried on
google.com:443 as well to be sure that was not because the other
server, but I didn't find neither such info.  Do you know what I
must look for in the output of -connect ?

  Regards,

-- 
Florent Georges
http://www.fgeorges.org






















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

Re: SSL error: parse tlsext

[Dr. Stephen Henson]

On Wed, Apr 07, 2010, Florent Georges wrote:

>   Hi,
> 
>   I am using openssl from within neon, itself used from within
> Subversion.  During an svnsync, I receive the following error
> message:
> 
> svnsync: PROPFIND of '/svn/xxx': SSL negotiation failed: SSL
> error: parse tlsext (https://xxx.org)
> 
>   If I am right, this message comes from openssl.  Is it really
> an error reported by openssl?  If it is, is there anything I can
> do to either solve the problem or at least get more informations
> about the context of the error?
> 
>   I am ready to compile myself the source packages if needed (and
> actually I did to be sure the TLS extensions where enabled during
> the build process, but still getting this error).  I am under Mac
> OS X Snow Leopard.
> 

That looks like it is only part of the actual error code. I suspect it is
because the server doesn't support secure renegotiation. You can check this by
doing:

openssl s_client -connect xxx.org:443

and it should say if secure renegotiation is supported in the output.

If it isn't supported the best fix is to upgrade the version of OpenSSL on the
server.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

SSL error: parse tlsext

[Florent Georges]

  Hi,

  I am using openssl from within neon, itself used from within
Subversion.  During an svnsync, I receive the following error
message:

svnsync: PROPFIND of '/svn/xxx': SSL negotiation failed: SSL
error: parse tlsext (https://xxx.org)

  If I am right, this message comes from openssl.  Is it really
an error reported by openssl?  If it is, is there anything I can
do to either solve the problem or at least get more informations
about the context of the error?

  I am ready to compile myself the source packages if needed (and
actually I did to be sure the TLS extensions where enabled during
the build process, but still getting this error).  I am under Mac
OS X Snow Leopard.

  Thanks in advance, regards,

-- 
Florent Georges
http://www.fgeorges.org/




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

SSL Error 140890B2

[Mark Jones]

Hi all I am a new user trying to setup OpenSSL with Freeradius. What I hope to 
accomplish is having laptops with certificates as being trusted on the network 
and be able to browse the Netware tree just like they would if they were wired 
in. The current Novell implementation of 802.1x does not allow for browsing so 
im hoping this will be my workaround. That said I have followed these two 
documents in my setup:  http://www.dslreports.com/forum/remark,9286052 
 
and
 
http://yb1zdx.arc.itb.ac.id/data/OWP/library-ref-eng/ref-eng-2/physical/wireless/802.1x/FreeRADIUS%20EAP-TLS%20HOWTO.htm
 ( I used the scripts from this site).
 
When my laptop boots up i get to the windows login screen (I have removed the 
Novell gina to keep it from being a source of problems until this part works) I 
see an exchange on radius with the last part showing this error:
 
rlm_eap_tls
 
Mark Jones, MCNE
Network Analyst

mjo...@hpsd48.ab.ca 

Office 523-2818 ext 182
Mobile 536-6641
 
Netware, because life is too short to reboot
: >>> TLS 1.0 Alert [length 0002], fatal certificate_unknown
TLS Alert write:fatal:certificate unknown
TLS_accept:error in SSLv3 read client certificate B
rlm_eap: SSL error error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no 
certificate returned
rlm_eap_tls: SSL_read failed in a system call (-1), TLS session fails.
  eaptls_process returned 13
  rlm_eap: Freeing handler
 
If I do a windows workstation login at that point I see another exchange that 
is successful and I am attached to my SSID and given an IP address. 
Can anyone give me some advice on what is or could be wrong with my setup?
 
Thanks in advance
Mark

This communication is intended for the use of the recipient to which it is 
addressed and may contain confidential, personal and/or privileged information. 
If you received this e-mail in error, please advise me (by return e-mail or 
otherwise) immediately.

RE: SSL Error and Info messages

[Shaw Graham George]

Hi,

This may or may not be helpful ... it depends on your code, and what
applications that you are talking to that lead to these errors:

(1) reminds me of a problem that can occur when using OpenSSL against
some Java implementations.  You can test it by using openssl s_client or
s_server using the -bugs option, and then check the man page for
SSL_CTX_set_options() which describes the various bug workarounds.

(2) reminds me of problems that OpenSSL has with IIS, and maybe other
Microsoft products.  They don't follow the SSL shutdown standard so you
just have to handle it in your code.

G.



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Weigang Gong
Sent: 25 February 2008 14:55
To: openssl-users@openssl.org
Subject: SSL Error and Info messages


Hi, openssl community,
 
My application calls some library functions, which uses OpenSSL. When my
appliction runs, I believe OpenSSL emitted some messages described
below. 
 
1. Sometimes, following Error messages will be emitted:
ERR-05255|8|04:26:25.540503|sslsocket.cpp[581] - SSL Error: Error on
Read SSL Error Stack: error:1408F455:SSL
routines:SSL3_GET_RECORD:decryption failed or bad record mac on 
...
ERR-05275|8|14:49:42.733798|sslsocket.cpp[566] - SSL Error: errno is
145: Connection timed out on 
...
 
Does anyone know what caused those error messages?
 
 
2. Also, following Info message will be emitted:
 
INF-05325|8|04:26:25.562401|sslsocket.cpp[538] - SSL Error: SSL_shutdown
EOF that violates SSL protocol 0 
 
Though it seems not affecting the functionality, those infom messages
are kind of annoying. Does anyone know how to turn them off ?
 
Thanks a lot !
 
 
Michael
 






Climb to the top of the charts! Play the word scramble challenge with
star power. Play now!
<http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_
jan>  
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: SSL Error and Info messages

[David Schwartz]

> My application calls some library functions, which uses
> OpenSSL. When my appliction runs, I believe OpenSSL emitted
> some messages described below.

Nope. Your application emitted them. OpenSSL detected them and reported
them, you chose to print them out.

> Does anyone know what caused those error messages?

They are normal errors. They can safely be ignored.

> Though it seems not affecting the functionality, those infom
> messages are kind of annoying. Does anyone know how to turn
> them off ?

Find the code in your application that generates them and comment it out or
suppress messages that are known to be harmless. You can try grep'ing your
code for "ERR_". If you have 'egrep', using "[^A-Z_]ERR_[a-z]" as the
regular expression will probably reduce the number of false positives.

DS


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

SSL Error and Info messages

[Weigang Gong]

Hi, openssl community,
 
My application calls some library functions, which uses OpenSSL. When my 
appliction runs, I believe OpenSSL emitted some messages described below. 
 
1. Sometimes, following Error messages will be emitted:
ERR-05255|8|04:26:25.540503|sslsocket.cpp[581] - SSL Error: Error on Read SSL 
Error Stack: error:1408F455:SSL routines:SSL3_GET_RECORD:decryption failed or 
bad record mac on 
...
ERR-05275|8|14:49:42.733798|sslsocket.cpp[566] - SSL Error: errno is 145: 
Connection timed out on 
...
 
Does anyone know what caused those error messages?
 
 
2. Also, following Info message will be emitted:
 
INF-05325|8|04:26:25.562401|sslsocket.cpp[538] - SSL Error: SSL_shutdown EOF 
that violates SSL protocol 0 
 
Though it seems not affecting the functionality, those infom messages are kind 
of annoying. Does anyone know how to turn them off ?
 
Thanks a lot !
 
 
Michael
 
_
Climb to the top of the charts! Play the word scramble challenge with star 
power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan

Re: SSL Error connecting to cia.gov

[Alex Lam]

Try this..

./openssl s_client -tls1 -connect www.cia.gov:443


On 10/24/07, Lutz Jaenicke <[EMAIL PROTECTED]> wrote:
>
> Isolating the problem is more or less simple:
>   openssl s_client -connect www.cia.gov:443
> shows the intermittent failures as well, so we can rule out all
> applications (curl, wget, ...). Has to be some basic thing.
>
> I tend to observe the failure with s_client not on the first attempt but
> on the nth attempt in a row. I would guess(!) that it may be some
> DoS protection measure that prevents too many new connections
> (from the same site).
> Firefox (and other browsers) would use session caching so that the
> server could see that it is actually the same client coming in again.
> This of course could only be seen after the client hello with a
> proposed session to be reused comes in and could not be done at
> the firewall level.
> Again: this is just a GUESS!
>
> Best regards,
> Lutz
>
> Alex Lam wrote:
> > That's TLSv1, not SSLv2.
> >
> > : 01 03 01 00 63 00 00 00 10 00 00 39 00 00 38 00 c..9..8.
> > 0010: 00 35 00 00 88 00 00 87 00 00 84 00 00 16 00 00 .5..
> > 0020: 13 00 00 0a 07 00 c0 00 00 33 00 00 32 00 00 2f .3..2../
> > 0030: 00 00 45 00 00 44 00 00 41 00 00 07 05 00 80 03 ..E..D..A...
> > 0040: 00 80 00 00 05 00 00 04 01 00 80 00 00 15 00 00 
> > 0050: 12 00 00 09 06 00 40 00 00 14 00 00 11 00 00 08 [EMAIL PROTECTED]
> > 0060: 00 00 06 04 00 80 00 00 03 02 00 80 c9 f7 89 ff 
> > 0070: 74 f1 92 59 c8 a0 f1 ba ab c0 dd 89 t..Y
> >
> > On 10/23/07, *Jake Goulding* <[EMAIL PROTECTED]
> > > wrote:
> >
> > Hey all:
> >
> > We use curl to retrieve webpages, and recently started receiving an
> > intermittent (40-60% of the time) error when retrieving a page
> > from the
> > CIA. About two weeks ago, they switched to running https only,
> > with the
> > http URLs being forwarded to the https equivalents.
> >
> > The error we receive is:
> >
> > $ curl 'https://www.cia.gov/about-cia/faqs/'
> > curl: (35) Unknown SSL protocol error in connection to
> > www.cia.gov:443 
> >
> > Using the --trace option, I see this:
> >
> > == Info: About to connect() to www.cia.gov 
> > port 443 (#0)
> > == Info:   Trying 198.81.129.100.. . == Info: connected
> > == Info: Connected to www.cia.gov 
> > (198.81.129.100 ) port 443 (#0)
> > == Info: successfully set certificate verify locations:
> > == Info:   CAfile: /etc/ssl/certs/ca- certificates.crt
> >   CApath: none
> > == Info: SSLv2, Client hello (1):
> > => Send SSL data, 124 bytes (0x7c)
> > : 01 03 01 00 63 00 00 00 10 00 00 39 00 00 38 00
> c..9..8.
> > 0010: 00 35 00 00 88 00 00 87 00 00 84 00 00 16 00 00
> > .5..
> > 0020: 13 00 00 0a 07 00 c0 00 00 33 00 00 32 00 00 2f
> .3..2../
> > 0030: 00 00 45 00 00 44 00 00 41 00 00 07 05 00 80 03
> ..E..D..A...
> > 0040: 00 80 00 00 05 00 00 04 01 00 80 00 00 15 00 00
> > 
> > 0050: 12 00 00 09 06 00 40 00 00 14 00 00 11 00 00 08
> [EMAIL PROTECTED]
> > 0060: 00 00 06 04 00 80 00 00 03 02 00 80 c9 f7 89 ff
> 
> > 0070: 74 f1 92 59 c8 a0 f1 ba ab c0 dd 89 t..Y
> > == Info: Unknown SSL protocol error in connection to
> > www.cia.gov:443 
> > == Info: Closing connection #0
> >
> > Unfortunately, I don't grok SSL hex  :-) .
> >
> > I have tried this and received the same error with the following
> > versions:
> > curl-7.12.1-8.rhel4 / openssl-0.9.7a-43.14
> > curl-7.12.1-11.el4 / openssl-0.9.7a-43.16
> > curl-7.16.1 / openssl-0.9.8e
> > curl-7.17.0 / openssl-0.9.8f
> >
> > Firefox does not seem to have any issues with this page.
> >
> > I asked the curl mailing list about this error, and got the
> following
> > response:
> >
> > > This is apparently has nothing to do with curl. I got the same
> > > intermittent errors with lynx, w3m, wget, you name it. I am using
> > > OpenSSL 0.9.8g 19 Oct 2007.
> >
> > Any help would be greatly appreciated. Please let me know if I can
> > provide more information.
> >
> > Thanks!
> >
> __
> >
> > 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

Re: SSL Error connecting to cia.gov

[Marek Marcola]

On Tue, 2007-10-23 at 22:02 -0700, Alex Lam wrote:
> That's TLSv1, not SSLv2.
> 
> : 01 03 01 00 63 00 00 00 10 00 00 39 00 00 38 00 c..9..8.
> 0010: 00 35 00 00 88 00 00 87 00 00 84 00 00 16 00
> 00 .5.. 
> 0020: 13 00 00 0a 07 00 c0 00 00 33 00 00 32 00 00 2f .3..2../
> 0030: 00 00 45 00 00 44 00 00 41 00 00 07 05 00 80 03 ..E..D..A...
> 0040: 00 80 00 00 05 00 00 04 01 00 80 00 00 15 00
> 00  
> 0050: 12 00 00 09 06 00 40 00 00 14 00 00 11 00 00 08 [EMAIL PROTECTED]
> 0060: 00 00 06 04 00 80 00 00 03 02 00 80 c9 f7 89 ff 
> 0070: 74 f1 92 59 c8 a0 f1 ba ab c0 dd 89 t..Y
This is SSL2 client_hello packet with TLS1 proposition.

Best regards,
-- 
Marek Marcola <[EMAIL PROTECTED]>

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

Re: SSL Error connecting to cia.gov

[Lutz Jaenicke]

Isolating the problem is more or less simple:
  openssl s_client -connect www.cia.gov:443
shows the intermittent failures as well, so we can rule out all
applications (curl, wget, ...). Has to be some basic thing.

I tend to observe the failure with s_client not on the first attempt but
on the nth attempt in a row. I would guess(!) that it may be some
DoS protection measure that prevents too many new connections
(from the same site).
Firefox (and other browsers) would use session caching so that the
server could see that it is actually the same client coming in again.
This of course could only be seen after the client hello with a
proposed session to be reused comes in and could not be done at
the firewall level.
Again: this is just a GUESS!

Best regards,
Lutz

Alex Lam wrote:
> That's TLSv1, not SSLv2.
>
> : 01 03 01 00 63 00 00 00 10 00 00 39 00 00 38 00 c..9..8.
> 0010: 00 35 00 00 88 00 00 87 00 00 84 00 00 16 00 00 .5..
> 0020: 13 00 00 0a 07 00 c0 00 00 33 00 00 32 00 00 2f .3..2../
> 0030: 00 00 45 00 00 44 00 00 41 00 00 07 05 00 80 03 ..E..D..A...
> 0040: 00 80 00 00 05 00 00 04 01 00 80 00 00 15 00 00 
> 0050: 12 00 00 09 06 00 40 00 00 14 00 00 11 00 00 08 [EMAIL PROTECTED]
> 0060: 00 00 06 04 00 80 00 00 03 02 00 80 c9 f7 89 ff 
> 0070: 74 f1 92 59 c8 a0 f1 ba ab c0 dd 89 t..Y
>
> On 10/23/07, *Jake Goulding* <[EMAIL PROTECTED]
> > wrote:
>
> Hey all:
>
> We use curl to retrieve webpages, and recently started receiving an
> intermittent (40-60% of the time) error when retrieving a page
> from the
> CIA. About two weeks ago, they switched to running https only,
> with the
> http URLs being forwarded to the https equivalents.
>
> The error we receive is:
>
> $ curl 'https://www.cia.gov/about-cia/faqs/'
> curl: (35) Unknown SSL protocol error in connection to
> www.cia.gov:443 
>
> Using the --trace option, I see this:
>
> == Info: About to connect() to www.cia.gov 
> port 443 (#0)
> == Info:   Trying 198.81.129.100.. . == Info: connected
> == Info: Connected to www.cia.gov 
> (198.81.129.100 ) port 443 (#0)
> == Info: successfully set certificate verify locations:
> == Info:   CAfile: /etc/ssl/certs/ca- certificates.crt
>   CApath: none
> == Info: SSLv2, Client hello (1):
> => Send SSL data, 124 bytes (0x7c)
> : 01 03 01 00 63 00 00 00 10 00 00 39 00 00 38 00 c..9..8.
> 0010: 00 35 00 00 88 00 00 87 00 00 84 00 00 16 00 00
> .5..
> 0020: 13 00 00 0a 07 00 c0 00 00 33 00 00 32 00 00 2f .3..2../
> 0030: 00 00 45 00 00 44 00 00 41 00 00 07 05 00 80 03 ..E..D..A...
> 0040: 00 80 00 00 05 00 00 04 01 00 80 00 00 15 00 00
> 
> 0050: 12 00 00 09 06 00 40 00 00 14 00 00 11 00 00 08 [EMAIL PROTECTED]
> 0060: 00 00 06 04 00 80 00 00 03 02 00 80 c9 f7 89 ff 
> 0070: 74 f1 92 59 c8 a0 f1 ba ab c0 dd 89 t..Y
> == Info: Unknown SSL protocol error in connection to
> www.cia.gov:443 
> == Info: Closing connection #0
>
> Unfortunately, I don't grok SSL hex  :-) .
>
> I have tried this and received the same error with the following
> versions:
> curl-7.12.1-8.rhel4 / openssl-0.9.7a-43.14
> curl-7.12.1-11.el4 / openssl-0.9.7a-43.16
> curl-7.16.1 / openssl-0.9.8e
> curl-7.17.0 / openssl-0.9.8f
>
> Firefox does not seem to have any issues with this page.
>
> I asked the curl mailing list about this error, and got the following
> response:
>
> > This is apparently has nothing to do with curl. I got the same
> > intermittent errors with lynx, w3m, wget, you name it. I am using
> > OpenSSL 0.9.8g 19 Oct 2007.
>
> Any help would be greatly appreciated. Please let me know if I can
> provide more information.
>
> Thanks!
> __
>
> 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: SSL Error connecting to cia.gov

[Alex Lam]

That's TLSv1, not SSLv2.

: 01 03 01 00 63 00 00 00 10 00 00 39 00 00 38 00 c..9..8.
0010: 00 35 00 00 88 00 00 87 00 00 84 00 00 16 00 00 .5..
0020: 13 00 00 0a 07 00 c0 00 00 33 00 00 32 00 00 2f .3..2../
0030: 00 00 45 00 00 44 00 00 41 00 00 07 05 00 80 03 ..E..D..A...
0040: 00 80 00 00 05 00 00 04 01 00 80 00 00 15 00 00 
0050: 12 00 00 09 06 00 40 00 00 14 00 00 11 00 00 08 [EMAIL PROTECTED]
0060: 00 00 06 04 00 80 00 00 03 02 00 80 c9 f7 89 ff 
0070: 74 f1 92 59 c8 a0 f1 ba ab c0 dd 89 t..Y

On 10/23/07, Jake Goulding <[EMAIL PROTECTED]> wrote:
>
> Hey all:
>
> We use curl to retrieve webpages, and recently started receiving an
> intermittent (40-60% of the time) error when retrieving a page from the
> CIA. About two weeks ago, they switched to running https only, with the
> http URLs being forwarded to the https equivalents.
>
> The error we receive is:
>
> $ curl 'https://www.cia.gov/about-cia/faqs/'
> curl: (35) Unknown SSL protocol error in connection to www.cia.gov:443
>
> Using the --trace option, I see this:
>
> == Info: About to connect() to www.cia.gov port 443 (#0)
> == Info:   Trying 198.81.129.100... == Info: connected
> == Info: Connected to www.cia.gov (198.81.129.100) port 443 (#0)
> == Info: successfully set certificate verify locations:
> == Info:   CAfile: /etc/ssl/certs/ca-certificates.crt
>   CApath: none
> == Info: SSLv2, Client hello (1):
> => Send SSL data, 124 bytes (0x7c)
> : 01 03 01 00 63 00 00 00 10 00 00 39 00 00 38 00 c..9..8.
> 0010: 00 35 00 00 88 00 00 87 00 00 84 00 00 16 00 00 .5..
> 0020: 13 00 00 0a 07 00 c0 00 00 33 00 00 32 00 00 2f .3..2../
> 0030: 00 00 45 00 00 44 00 00 41 00 00 07 05 00 80 03 ..E..D..A...
> 0040: 00 80 00 00 05 00 00 04 01 00 80 00 00 15 00 00 
> 0050: 12 00 00 09 06 00 40 00 00 14 00 00 11 00 00 08 [EMAIL PROTECTED]
> 0060: 00 00 06 04 00 80 00 00 03 02 00 80 c9 f7 89 ff 
> 0070: 74 f1 92 59 c8 a0 f1 ba ab c0 dd 89 t..Y
> == Info: Unknown SSL protocol error in connection to www.cia.gov:443
> == Info: Closing connection #0
>
> Unfortunately, I don't grok SSL hex  :-) .
>
> I have tried this and received the same error with the following versions:
> curl-7.12.1-8.rhel4 / openssl-0.9.7a-43.14
> curl-7.12.1-11.el4 / openssl-0.9.7a-43.16
> curl-7.16.1 / openssl-0.9.8e
> curl-7.17.0 / openssl-0.9.8f
>
> Firefox does not seem to have any issues with this page.
>
> I asked the curl mailing list about this error, and got the following
> response:
>
> > This is apparently has nothing to do with curl. I got the same
> > intermittent errors with lynx, w3m, wget, you name it. I am using
> > OpenSSL 0.9.8g 19 Oct 2007.
>
> Any help would be greatly appreciated. Please let me know if I can
> provide more information.
>
> Thanks!
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager   [EMAIL PROTECTED]
>

Re: SSL Error connecting to cia.gov

[Jake Goulding]

Marek Marcola wrote:
> I think that this is CIA webserver problem.
> You may test this with:
>  $ openssl s_client -connect www.cia.gov:443 -state -debug -msg [[-ssl3] 
> [-tls1]]
> and in any combination after some successful connection you will get failed 
> connections.
> For example:
>  $ openssl s_client -connect www.cia.gov:443 -state -debug -msg

[snip]

> As you see after sending client_hello remote server just quits connection,
> there is no alert information (for example about unsupported ciphers or 
> something)
> but simply connection is dropped:
>   -> read from 0x9b5bdb0 [0x9b61358] (7 bytes => 0 (0x0))
> 
> I think that error is in remote site.

Thanks for the evaluation! I will attempt to contact the site's
maintainers, but I guess I will not hold my breath.

-Jake

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

Re: SSL Error connecting to cia.gov

[Marek Marcola]

Hello,
> We use curl to retrieve webpages, and recently started receiving an
> intermittent (40-60% of the time) error when retrieving a page from the
> CIA. About two weeks ago, they switched to running https only, with the
> http URLs being forwarded to the https equivalents.
> 
> The error we receive is:
> 
> $ curl 'https://www.cia.gov/about-cia/faqs/'
> curl: (35) Unknown SSL protocol error in connection to www.cia.gov:443
> 
> Using the --trace option, I see this:
> 
> == Info: About to connect() to www.cia.gov port 443 (#0)
> == Info:   Trying 198.81.129.100... == Info: connected
> == Info: Connected to www.cia.gov (198.81.129.100) port 443 (#0)
> == Info: successfully set certificate verify locations:
> == Info:   CAfile: /etc/ssl/certs/ca-certificates.crt
>   CApath: none
> == Info: SSLv2, Client hello (1):
> => Send SSL data, 124 bytes (0x7c)
> : 01 03 01 00 63 00 00 00 10 00 00 39 00 00 38 00 c..9..8.
> 0010: 00 35 00 00 88 00 00 87 00 00 84 00 00 16 00 00 .5..
> 0020: 13 00 00 0a 07 00 c0 00 00 33 00 00 32 00 00 2f .3..2../
> 0030: 00 00 45 00 00 44 00 00 41 00 00 07 05 00 80 03 ..E..D..A...
> 0040: 00 80 00 00 05 00 00 04 01 00 80 00 00 15 00 00 
> 0050: 12 00 00 09 06 00 40 00 00 14 00 00 11 00 00 08 [EMAIL PROTECTED]
> 0060: 00 00 06 04 00 80 00 00 03 02 00 80 c9 f7 89 ff 
> 0070: 74 f1 92 59 c8 a0 f1 ba ab c0 dd 89 t..Y
> == Info: Unknown SSL protocol error in connection to www.cia.gov:443
> == Info: Closing connection #0
I think that this is CIA webserver problem.
You may test this with:
 $ openssl s_client -connect www.cia.gov:443 -state -debug -msg [[-ssl3] 
[-tls1]]
and in any combination after some successful connection you will get failed 
connections.
For example:
 $ openssl s_client -connect www.cia.gov:443 -state -debug -msg
CONNECTED(0003)
SSL_connect:before/connect initialization
write to 0x9b5bdb0 [0x9b5bdf8] (142 bytes => 142 (0x8E))
 - 80 8c 01 03 01 00 63 00-00 00 20 00 00 39 00 00   ..c... ..9..
0010 - 38 00 00 35 00 00 16 00-00 13 00 00 0a 07 00 c0   8..5
0020 - 00 00 33 00 00 32 00 00-2f 03 00 80 00 00 66 00   ..3..2../.f.
0030 - 00 05 00 00 04 01 00 80-08 00 80 00 00 63 00 00   .c..
0040 - 62 00 00 61 00 00 15 00-00 12 00 00 09 06 00 40   b..a...@
0050 - 00 00 65 00 00 64 00 00-60 00 00 14 00 00 11 00   ..e..d..`...
0060 - 00 08 00 00 06 04 00 80-00 00 03 02 00 80 e1 99   
0070 - 17 7c d8 8d 06 53 4e a1-cf 05 40 af 27 57 da e1   .|[EMAIL PROTECTED]'W..
0080 - 51 26 ea f1 50 f9 f6 ba-47 7d 70 74 00 35 Q&..P...G}pt.5
>>> SSL 2.0 [length 008c], CLIENT-HELLO
01 03 01 00 63 00 00 00 20 00 00 39 00 00 38 00
00 35 00 00 16 00 00 13 00 00 0a 07 00 c0 00 00
33 00 00 32 00 00 2f 03 00 80 00 00 66 00 00 05
00 00 04 01 00 80 08 00 80 00 00 63 00 00 62 00
00 61 00 00 15 00 00 12 00 00 09 06 00 40 00 00
65 00 00 64 00 00 60 00 00 14 00 00 11 00 00 08
00 00 06 04 00 80 00 00 03 02 00 80 e1 99 17 7c
d8 8d 06 53 4e a1 cf 05 40 af 27 57 da e1 51 26
ea f1 50 f9 f6 ba 47 7d 70 74 00 35
SSL_connect:SSLv2/v3 write client hello A
read from 0x9b5bdb0 [0x9b61358] (7 bytes => 0 (0x0))
4176:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake 
failure:s23_lib.c:188:

As you see after sending client_hello remote server just quits connection,
there is no alert information (for example about unsupported ciphers or 
something)
but simply connection is dropped:
  -> read from 0x9b5bdb0 [0x9b61358] (7 bytes => 0 (0x0))

I think that error is in remote site.

Best regards,
-- 
Marek Marcola <[EMAIL PROTECTED]>

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

SSL Error connecting to cia.gov

[Jake Goulding]

Hey all:

We use curl to retrieve webpages, and recently started receiving an
intermittent (40-60% of the time) error when retrieving a page from the
CIA. About two weeks ago, they switched to running https only, with the
http URLs being forwarded to the https equivalents.

The error we receive is:

$ curl 'https://www.cia.gov/about-cia/faqs/'
curl: (35) Unknown SSL protocol error in connection to www.cia.gov:443

Using the --trace option, I see this:

== Info: About to connect() to www.cia.gov port 443 (#0)
== Info:   Trying 198.81.129.100... == Info: connected
== Info: Connected to www.cia.gov (198.81.129.100) port 443 (#0)
== Info: successfully set certificate verify locations:
== Info:   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
== Info: SSLv2, Client hello (1):
=> Send SSL data, 124 bytes (0x7c)
: 01 03 01 00 63 00 00 00 10 00 00 39 00 00 38 00 c..9..8.
0010: 00 35 00 00 88 00 00 87 00 00 84 00 00 16 00 00 .5..
0020: 13 00 00 0a 07 00 c0 00 00 33 00 00 32 00 00 2f .3..2../
0030: 00 00 45 00 00 44 00 00 41 00 00 07 05 00 80 03 ..E..D..A...
0040: 00 80 00 00 05 00 00 04 01 00 80 00 00 15 00 00 
0050: 12 00 00 09 06 00 40 00 00 14 00 00 11 00 00 08 [EMAIL PROTECTED]
0060: 00 00 06 04 00 80 00 00 03 02 00 80 c9 f7 89 ff 
0070: 74 f1 92 59 c8 a0 f1 ba ab c0 dd 89 t..Y
== Info: Unknown SSL protocol error in connection to www.cia.gov:443
== Info: Closing connection #0

Unfortunately, I don't grok SSL hex  :-) .

I have tried this and received the same error with the following versions:
curl-7.12.1-8.rhel4 / openssl-0.9.7a-43.14
curl-7.12.1-11.el4 / openssl-0.9.7a-43.16
curl-7.16.1 / openssl-0.9.8e
curl-7.17.0 / openssl-0.9.8f

Firefox does not seem to have any issues with this page.

I asked the curl mailing list about this error, and got the following
response:

> This is apparently has nothing to do with curl. I got the same
> intermittent errors with lynx, w3m, wget, you name it. I am using
> OpenSSL 0.9.8g 19 Oct 2007.

Any help would be greatly appreciated. Please let me know if I can
provide more information.

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

Re: SSL ERROR on verifying Certificate

[Marek Marcola]

Hello,
> I am trying to verify a certificate with the folowing command line on a 
> windows 32 bit plateform:
> 
> C:\OpenSSL\bin> openssl verify -CAfile d:\cert.pem d:\cert2.pem
> 
> It replies me:
> 
> d:\cert2.pem: /C=FR/ST=Cote d Or/L=Saint Apollinaire/O=societe des AUTOROUTES 
> PARIS RHIN RHONE/OU=DTR/DRTM/RT/OU=Provided by TBS INTERNET 
> http://www.tbs-certificats.com//CN=preprod-gc.parisrhinrhone.fr error 20 at 0 
> depth lookup:unable to get local issuer certificate
> 
> What's wrong ?
Probably you do not have full certificate chain in cert.pem.

Look at issuer filed in cert2.pem and check that subject from cert.pem
matches (for top level CA (root CA) subject == issuer).
If not, you must get all certs from chain up to root CA and put
this certs in cert.pem.

Best regards,
-- 
Marek Marcola <[EMAIL PROTECTED]>

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

SSL ERROR on verifying Certificate

[MAMDY Stéphane]

Hi
I am trying to verify a certificate with the folowing command line on a windows 
32 bit plateform:

C:\OpenSSL\bin> openssl verify -CAfile d:\cert.pem d:\cert2.pem

It replies me:

d:\cert2.pem: /C=FR/ST=Cote d Or/L=Saint Apollinaire/O=societe des AUTOROUTES 
PARIS RHIN RHONE/OU=DTR/DRTM/RT/OU=Provided by TBS INTERNET 
http://www.tbs-certificats.com//CN=preprod-gc.parisrhinrhone.fr error 20 at 0 
depth lookup:unable to get local issuer certificate

What's wrong ?

Can you hel me ?

Thanks,
Stéphane Mamdy
Chef de projets Informatiques
Tél. : 03 80 77 64 52 - Fax : 03 80 77 67 20
[EMAIL PROTECTED]
 
Autoroutes Paris-Rhin-Rhône
Direction des Systèmes d'information Groupe / Département Etudes Informatiques
36 rue du Docteur Schmitt
21850 Saint-Apollinaire
www.parisrhinrhone.com
 
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Clean SSL Error queue

[Dinh, Thao V CIV NSWCDD, K72]

Hi all

What functions use  to clean up SSl Error Queue in Multithread
Applications ?? 

Thank You
TD

Re: SSL error (138): cipher or hash unavailable

[Johans Taboada]

2007/4/10, Johans Taboada <[EMAIL PROTECTED]>:


Hi list, I ask for help please.



Still waiting...



DatabaseError: SSL error: cipher or hash unavailable\n


...


OperationalError: SSL error: cipher or hash unavailable\n
...
What does it really mean '''cipher or hash unavailable'''? (SSL Error
#138, SSL_R_CIPHER_OR_HASH_UNAVAILABLE).
...
For a more detailed info, visit:
http://groups.google.com/group/trac-users/browse_thread/thread/901ef327b448b496?hl=en

Thanks,


Am I writing to the wrong mailing list?, if yes please tell me, thanks


Johans Marvin Taboada Villca-`^_^´-

Adm. Laboratorio de Desarrollo de Software
Carreras de Informática y Sistemas
UMSS, Cochabamba
Bolivia

SSL error (138): cipher or hash unavailable

[Johans Taboada]

Hi list, I ask for help please.

I have an apache server (2.0.59) built with OpenSSL 0.9.8b, it hosts a
python (2.4.4) based application (Edgewall's trac) wich access a PostgreSQL
SSL-secured server (8.2.3) throught DBI libraries (pyPgSQL/Psycopg2).

When I use directly trac (it has a lightweight server, tracd), it works with
no problems.

But when I use it throught apache2+mod_python, apache shows HTTP 500:

{{{
# error_log, using pyPgSQL
[Thu Apr 05 19:25:43 2007] [error] [client 192.168.2.52]
DatabaseError: SSL error: cipher or hash unavailable\n
[Thu Apr 05 19:25:43 2007] [debug] ssl_engine_kernel.c(1787): OpenSSL:
Write: SSL negotiation finished successfully
[Thu Apr 05 19:25:43 2007] [info] Connection to child 4 closed with
standard shutdown(server PCDCOM:443, client 192.168.2.52)
}}}

{{{
# error_log, using Psycopg2
[Mon Apr 09 22:03:32 2007] [error] [client 192.168.2.52]
OperationalError: SSL error: cipher or hash unavailable\n
[Mon Apr 09 22:03:33 2007] [debug] ssl_engine_kernel.c(1787): OpenSSL:
Write: SSL negotiation finished successfully
[Mon Apr 09 22:03:33 2007] [info] Connection to child 1 closed with
standard shutdown(server PCDCOM:443, client 192.168.2.52)
}}}

What does it really mean '''cipher or hash unavailable'''? (SSL Error
#138,SSL_R_CIPHER_OR_HASH_UNAVAILABLE).
The only thing I can guess is that ''apache2+mod_python'' (client-app role)
fails to access PostgreSQL+SSL (server role). Must be a missconfiguration in
apache2.


How do I configure Apache2 properly, to act as a SSL client, I have no
problem acting as SSL server role.

For a more detailed info, visit:
http://groups.google.com/group/trac-users/browse_thread/thread/901ef327b448b496?hl=en

Thanks,
Johans Marvin Taboada Villca

Re: lighttpd and ssl error

[Marek Marcola]

Hello,
> The problem is with my x509. What do I do to fix that?
> 
> On 8/23/06, Marek Marcola <[EMAIL PROTECTED] > wrote:
> Hello,
> >
> > Hi. I am new at this and at my wits end. I keep on
> getting the 
> > same error when I try and start lighttpd. I have
> rekeyed my
> > cert 2 times now so I am fairly certain that it is
> not a
> > problem there. I have redone the KEY and CSR as
> well. I do not 
> > know what to do. Please let me know if you have any
> ideas.
> >
> > [EMAIL PROTECTED]:/etc/lighttpd# lighttpd
> > -f /etc/lighttpd/lighttpd.conf
> > 2006-08-21 15:38:03: (network.c.362 ) SSL: Private
> key does not
> > match the certificate public key, reason:
> error:0906D06C:PEM
> > routines:PEM_read_bio:no start
> >
> line /www/app.tickspot.com/www*.simplethought.com.pem 
I don't use lighttpd but from doc this seems that you should put
PEM key and cert in one file:
$ cat key.pem crt.pem > host.pem
and use this file in ssl.pemfile directive.
Information "no start line ..." may indicate that x509 was not read
because, for example, there was no x509 cert in this file :-)

Best regards,
-- 
Marek Marcola <[EMAIL PROTECTED]>

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

Re: lighttpd and ssl error

[Timothy Wright]

The problem is with my x509. What do I do to fix that?On 8/23/06, Marek Marcola <[EMAIL PROTECTED]
> wrote:Hello,>> Hi. I am new at this and at my wits end. I keep on getting the
> same error when I try and start lighttpd. I have rekeyed my> cert 2 times now so I am fairly certain that it is not a> problem there. I have redone the KEY and CSR as well. I do not
> know what to do. Please let me know if you have any ideas.>> [EMAIL PROTECTED]:/etc/lighttpd# lighttpd> -f /etc/lighttpd/lighttpd.conf> 2006-08-21 15:38:03: (network.c.362
) SSL: Private key does not> match the certificate public key, reason: error:0906D06C:PEM> routines:PEM_read_bio:no start> line /www/app.tickspot.com/www*.simplethought.com.pem
SSL_CTX structure has private key and X509 certificate.After reading this data SSL_CTX_check_private_key() is calledto check if public key in certificate (numbers e,n) are the sameas in X509 certificate. In this case they are not.
This means that specified X509 certificate is not from yourprivate key.To check, display certificate:$  openssl x509 -in crt.pem -noout -textand private key:$ openssl rsa -in key.pem
 -noout -textand look at modulus and public_exponent values - this numbersshould be the same. If not, you have incompatible certificateor private key.Best regards,--Marek Marcola <
[EMAIL PROTECTED]>__OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.orgAutomated List Manager   [EMAIL PROTECTED]
-- Grace and Peace,Timothy G. Wright

Re: lighttpd and ssl error

[Marek Marcola]

Hello,
> 
> Hi. I am new at this and at my wits end. I keep on getting the
> same error when I try and start lighttpd. I have rekeyed my
> cert 2 times now so I am fairly certain that it is not a
> problem there. I have redone the KEY and CSR as well. I do not
> know what to do. Please let me know if you have any ideas. 
> 
> [EMAIL PROTECTED]:/etc/lighttpd# lighttpd
> -f /etc/lighttpd/lighttpd.conf
> 2006-08-21 15:38:03: (network.c.362) SSL: Private key does not
> match the certificate public key, reason: error:0906D06C:PEM
> routines:PEM_read_bio:no start
> line /www/app.tickspot.com/www*.simplethought.com.pem 
SSL_CTX structure has private key and X509 certificate.
After reading this data SSL_CTX_check_private_key() is called
to check if public key in certificate (numbers e,n) are the same
as in X509 certificate. In this case they are not.
This means that specified X509 certificate is not from your
private key.
To check, display certificate:
$  openssl x509 -in crt.pem -noout -text
and private key:
$ openssl rsa -in key.pem -noout -text
and look at modulus and public_exponent values - this numbers
should be the same. If not, you have incompatible certificate
or private key.

Best regards,
-- 
Marek Marcola <[EMAIL PROTECTED]>

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

Re: lighttpd and ssl error

[Timothy Wright]

I have done that. Any more ideas?On 8/23/06, Visolve Security Consulting Group <[EMAIL PROTECTED]
> wrote:






Hi Timothy,
 
Make sure the cert and the key are in exact order 
as key is first and the cert is second. Also make sure you have added the 
signing authority after this as
ssl.ca-file = "path to ca"
 
Thanks,ViSolve Security Consulting 
Group

  - Original Message - 
  
From: 
  Timothy Wright 
  
  To: 
openssl-users@openssl.org 
  Sent: Tuesday, August 22, 2006 1:26 
  AM
  Subject: lighttpd and ssl error

  Hi. I am new at this and at my wits end. I keep on getting the 
  same error when I try and start lighttpd. I have rekeyed my cert 2 times now 
  so I am fairly certain that it is not a problem there. I have redone the KEY 
  and CSR as well. I do not know what to do. Please let me know if you have any 
  ideas. [EMAIL PROTECTED]:/etc/lighttpd# lighttpd -f 
  /etc/lighttpd/lighttpd.conf2006-08-21 15:38:03: (network.c.362) SSL: 
  Private key does not match the certificate public key, reason: 
  error:0906D06C:PEM routines:PEM_read_bio:no start line 
  /www/app.tickspot.com/www*.simplethought.com.pem -- 
  Grace and Peace,Timothy G. Wright 
  
  

  No virus found in this incoming message.Checked by AVG Free 
  Edition.Version: 7.1.405 / Virus Database: 268.11.4/424 - Release Date: 
  8/21/2006

-- Grace and Peace,Timothy G. Wright

Re: lighttpd and ssl error

[Visolve Security Consulting Group]

Hi Timothy,
 
Make sure the cert and the key are in exact order 
as key is first and the cert is second. Also make sure you have added the 
signing authority after this as
ssl.ca-file = "path to ca"
 
Thanks,ViSolve Security Consulting 
Group

  - Original Message - 
  From: 
  Timothy Wright 
  
  To: openssl-users@openssl.org 
  Sent: Tuesday, August 22, 2006 1:26 
  AM
  Subject: lighttpd and ssl error
  Hi. I am new at this and at my wits end. I keep on getting the 
  same error when I try and start lighttpd. I have rekeyed my cert 2 times now 
  so I am fairly certain that it is not a problem there. I have redone the KEY 
  and CSR as well. I do not know what to do. Please let me know if you have any 
  ideas. [EMAIL PROTECTED]:/etc/lighttpd# lighttpd -f 
  /etc/lighttpd/lighttpd.conf2006-08-21 15:38:03: (network.c.362) SSL: 
  Private key does not match the certificate public key, reason: 
  error:0906D06C:PEM routines:PEM_read_bio:no start line 
  /www/app.tickspot.com/www*.simplethought.com.pem -- 
  Grace and Peace,Timothy G. Wright 
  
  

  No virus found in this incoming message.Checked by AVG Free 
  Edition.Version: 7.1.405 / Virus Database: 268.11.4/424 - Release Date: 
  8/21/2006

lighttpd and ssl error

[Timothy Wright]

Hi. I am new at this and at my wits end. I keep on getting the same error when I try and start lighttpd. I have rekeyed my cert 2 times now so I am fairly certain that it is not a problem there. I have redone the KEY and CSR as well. I do not know what to do. Please let me know if you have any ideas. 
[EMAIL PROTECTED]:/etc/lighttpd# lighttpd -f /etc/lighttpd/lighttpd.conf2006-08-21 15:38:03: (network.c.362) SSL: Private key does not match the certificate public key, reason: error:0906D06C:PEM routines:PEM_read_bio:no start line /www/app.tickspot.com/www*.simplethought.com.pem
-- Grace and Peace,Timothy G. Wright

Re: SSL Error

[Dr. Stephen Henson]

On Wed, Aug 09, 2006, Carlo Agopian wrote:

> Hello,
> 
> Has anybody seen the following runtime error message before?
> 
>   error::lib(0):func(0):reason(0)
> 

Yes. It normally means "no error has been placed on the queue and the the
application wrongly thinks it has and can print it out.." However I realise
that wont help you much :-)

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: SSL Error

[Andrew Dennison]

You can't reuse a socket for a TCP connection, but you certainly can reuse the same TCP socket for an arbitrary number of SSL connections as long as you don't compromise the TCP connection while you're doing it.  I suspect that is the intention here and from the sounds of things (if all he is getting is a 'no error' error), it is doing just that.

 
On 8/10/06, Usman Riaz <[EMAIL PROTECTED]> wrote:



sorry if I misunderstood you, but AFAIK, pure sockets API doesnt allow socket reuse as such. You have to have a new socket for every TCP connection, you can't "reuse" a socket.


From: "Carlo Agopian" <[EMAIL PROTECTED]>Reply-To: 
openssl-users@openssl.orgTo: <
openssl-users@openssl.org>CC: "Carlo Agopian" <[EMAIL PROTECTED]
>Subject: SSL ErrorDate: Wed, 9 Aug 2006 08:35:13 -0700

Hello, 
Has anybody seen the following runtime error message before? 
    error::lib(0):func(0):reason(0) 
It seems to be coming from the following openssl function: ERR_error_string(m_sslError, 0).  This error occurs in a C++ client application that sends SSL encrypted messages over TCP-IP.  The application is developed and executed in 
AIX5.2 O/S and uses 0.9.7d version of SSL.  The error occurs when I try to reuse a socket that I had previously opened.  After this error message I am able to open a fresh socket and successfully send a message.  The interesting thing is that this only happens on a certain server, and of course it is not the development server.  When I disable SSL encryption, the error does not occur.  I'm not readily able to do any debugging on this server so, before I go digging into all the difference between the 2 servers, I was wondering if anybody has seen this error message and can provide some clues.

Thank you,  
Carlo Agopian   
[EMAIL PROTECTED] 




Don't just search. Find. MSN Search Check out the new MSN Search! __ OpenSSL Project 
http://www.openssl.org User Support Mailing List 
openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] 

RE: SSL Error

[Usman Riaz]

sorry if I misunderstood you, but AFAIK, pure sockets API doesnt allow socket reuse as such. You have to have a new socket for every TCP connection, you can't "reuse" a socket.


From: "Carlo Agopian" <[EMAIL PROTECTED]>Reply-To: openssl-users@openssl.orgTo: CC: "Carlo Agopian" <[EMAIL PROTECTED]>Subject: SSL ErrorDate: Wed, 9 Aug 2006 08:35:13 -0700

Hello, 
Has anybody seen the following runtime error message before? 
    error::lib(0):func(0):reason(0) 
It seems to be coming from the following openssl function: ERR_error_string(m_sslError, 0).  This error occurs in a C++ client application that sends SSL encrypted messages over TCP-IP.  The application is developed and executed in AIX5.2 O/S and uses 0.9.7d version of SSL.  The error occurs when I try to reuse a socket that I had previously opened.  After this error message I am able to open a fresh socket and successfully send a message.  The interesting thing is that this only happens on a certain server, and of course it is not the development server.  When I disable SSL encryption, the error does not occur.  I'm not readily able to do any debugging on this server so, before I go digging into all the difference between the 2 servers, I was wondering if anybody has seen this error message and can provide some clues.
Thank you,  
Carlo Agopian   [EMAIL PROTECTED] Don't just search. Find. MSN Search Check out the new MSN Search!

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

Re: SSL Error

[Andrew Dennison]

This error is indicative that there is no error.  You have simply read the error buffer one more time than you should have.  There is absolutely nothing wrong with your application state if you see this reported.  In my experience it wont cause any application problems if you check the error queue while it's empty (likely, this was expected by the developers).  

 
I expect that you're entering the loop to get all errors from the error queue BEFORE you check ERR_get_error() for the first time.  When you finally check it, the response is almost certainly 0 (no error), and this is the textual valuation of 'no error' from ERR_error_string().  Check the value before you loop and this message will go away.

 
Andrew. 
On 8/9/06, Carlo Agopian <[EMAIL PROTECTED]> wrote:



Hello, 
Has anybody seen the following runtime error message before? 
    error::lib(0):func(0):reason(0) 
It seems to be coming from the following openssl function: ERR_error_string(m_sslError, 0).  This error occurs in a C++ client application that sends SSL encrypted messages over TCP-IP.  The application is developed and executed in 
AIX5.2 O/S and uses 0.9.7d version of SSL.  The error occurs when I try to reuse a socket that I had previously opened.  After this error message I am able to open a fresh socket and successfully send a message.  The interesting thing is that this only happens on a certain server, and of course it is not the development server.  When I disable SSL encryption, the error does not occur.  I'm not readily able to do any debugging on this server so, before I go digging into all the difference between the 2 servers, I was wondering if anybody has seen this error message and can provide some clues.

Thank you,  
Carlo Agopian   
[EMAIL PROTECTED]  

SSL Error

[Carlo Agopian]

Title: SSL Error






Hello,


Has anybody seen the following runtime error message before?


    error::lib(0):func(0):reason(0)


It seems to be coming from the following openssl function: ERR_error_string(m_sslError, 0).  This error occurs in a C++ client application that sends SSL encrypted messages over TCP-IP.  The application is developed and executed in AIX5.2 O/S and uses 0.9.7d version of SSL.  The error occurs when I try to reuse a socket that I had previously opened.  After this error message I am able to open a fresh socket and successfully send a message.  The interesting thing is that this only happens on a certain server, and of course it is not the development server.  When I disable SSL encryption, the error does not occur.  I'm not readily able to do any debugging on this server so, before I go digging into all the difference between the 2 servers, I was wondering if anybody has seen this error message and can provide some clues.

Thank you,  



Carlo Agopian   

[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]

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]

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 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.
> 
> 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

Oops! Although my previous reply is valid it isn't the cause of this specific
error. The problem here is the private key format is the OpenSSL "traditional"
form which uses MD5 (a prohibited algorithm) to derive the keys. You need to
convert the key to PKCS#8 format using:

openssl pkcs8 -in key.pem -topk8 -v2 des3 -out pkcs8key.pem

BTW the "user document" is also now online at:

http://www.openssl.org/docs/fips/UserGuide-1.0.pdf

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

[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]

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]

Re: CVSNT sserver SSL error

[Kyle Hamilton]

On 1/31/06, Jason Williard <[EMAIL PROTECTED]> wrote:
>
> I considered this as a possibility.  The part that doesn't make sense is
> that I was under the belief that OpenSSL v0.9.7i supports both SSLv2 &
> SSLv3.  Is this correct?

It does, yes, but by default there's no ciphers or protocol versions
enabled.  (It also supports TLSv1.)  They have to be explicitly
enabled -- and a server certificate installed on the server -- before
SSL can be used at all.

You need to check the documentation for cvsNT to see how to properly
configure it.

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

RE: CVSNT sserver SSL error

[Jason Williard]

> Your client is trying to use SSLv2, or SSLv3, and the server is
> configured to not allow that protocol.  (Or, the server isn't
> configured to use any protocol.)
> 
> I don't know the specifics of how to configure what you're doing, but
> I do know that there are environment variables available to specify
> what protocol versions to accept.
> 
> -Kyle H
> 
> On 1/31/06, Jason Williard <[EMAIL PROTECTED]> wrote:
> > I just installed CVSNT 2.5.03.2151 on a Red Hat Enterprise 4 server.
> OpenSSL
> > was previously installed with prefix /usr.  When I attempt to connect
> using
> > TortoiseCVS, I get the following error:
> >
> > SSL connection failed (-1): error:1408F10B:SSL
> > routines:SSL3_GET_RECORD:wrong version number cvs.exe [import aborted]:
> > Connection to server failed
> >
> > Does anyone know what could be wrong?
> >
> >
> > 
> > Thank You,
> > Jason Williard


I considered this as a possibility.  The part that doesn't make sense is
that I was under the belief that OpenSSL v0.9.7i supports both SSLv2 &
SSLv3.  Is this correct?  



Thank You,
Jason Williard


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

Re: CVSNT sserver SSL error

[Kyle Hamilton]

Your client is trying to use SSLv2, or SSLv3, and the server is
configured to not allow that protocol.  (Or, the server isn't
configured to use any protocol.)

I don't know the specifics of how to configure what you're doing, but
I do know that there are environment variables available to specify
what protocol versions to accept.

-Kyle H

On 1/31/06, Jason Williard <[EMAIL PROTECTED]> wrote:
> I just installed CVSNT 2.5.03.2151 on a Red Hat Enterprise 4 server. OpenSSL
> was previously installed with prefix /usr.  When I attempt to connect using
> TortoiseCVS, I get the following error:
>
> SSL connection failed (-1): error:1408F10B:SSL
> routines:SSL3_GET_RECORD:wrong version number cvs.exe [import aborted]:
> Connection to server failed
>
> Does anyone know what could be wrong?
>
>
> 
> Thank You,
> Jason Williard
>
>
>
>
> __
> 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]

CVSNT sserver SSL error

[Jason Williard]

I just installed CVSNT 2.5.03.2151 on a Red Hat Enterprise 4 server. OpenSSL
was previously installed with prefix /usr.  When I attempt to connect using
TortoiseCVS, I get the following error:

SSL connection failed (-1): error:1408F10B:SSL
routines:SSL3_GET_RECORD:wrong version number cvs.exe [import aborted]:
Connection to server failed

Does anyone know what could be wrong?

 

Thank You,
Jason Williard




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

SSL error: decryption failed or bad record mac (pg as Samba backend)

[Fernando Schapachnik]

Hi,

I posted the following message to the PostgreSQL mailing list, and one 
of the main developers answered:

I think you need to find some SSL hackers; this is below libpq's level too.

- Original message -
I'm trying to use an SSL-enabled (OpenSSL 0.9.7d) Postgres 7.3.9 as database 
backend to Samba 3.0.11. On startup Samba opens a connection, and passes it to 
every fork()ed process. On some scenarios (consistenly, when somebody tries to 
log into a workstation after reboot), Samba spits:

SELECT ... (details ommited)
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.

And the server log says:
[24129]  LOG:  SSL error: decryption failed or bad record mac
[24129]  LOG:  pq_recvbuf: recv() failed: Connection reset by peer

There is no problem when not using SSL. The Samba code doesn't have any 
SSL-specifics, leaving it to libpq. Any ideas?
- End of message -

So I'm asking here. Any clues? Thanks in advance!


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

Re: SSL error: no cipher list

[Dr. Stephen Henson]

On Mon, Jan 24, 2005, Yuriy Synov wrote:

> In fact I'm not using OpenSSL library directly. I use an open source library
> Indy which in turn makes use of OpenSSL. I discovered that POP3 servers that
> use DES-CBC3-SHA work correctly with my program, and the server that fails
> uses RC4-SHA. I got what you had said about Diffie-Hellman parameters, but
> it means that I will need to modify Indy (the lib I'm using) which is not a
> very simple task. I will report to this list if I get any positive results.
> 

DH parameters are set on the server so this will make no difference.

You can try using OpenSSL s_server as a test and connecting to it using your
program. The -cipher option can be used to restrict the ciphers available to
see if that's the problem.

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: SSL error: no cipher list

[Yuriy Synov]

In fact I'm not using OpenSSL library directly. I use an open source library
Indy which in turn makes use of OpenSSL. I discovered that POP3 servers that
use DES-CBC3-SHA work correctly with my program, and the server that fails
uses RC4-SHA. I got what you had said about Diffie-Hellman parameters, but
it means that I will need to modify Indy (the lib I'm using) which is not a
very simple task. I will report to this list if I get any positive results.

- Original Message -
From: "mclellan, dave" <[EMAIL PROTECTED]>
To: 
Sent: Sunday, January 23, 2005 3:12 PM
Subject: RE: SSL error: no cipher list


> On my first SSL implementation, I struggled with this specific error.  The
> Diffie-Hellman parameters for key exchange must be initialized, and if I
> remember correctly they weren't in my case.
>
> You must set up a callback to your code where it initializes DH parms.
Call
> SSL_CTX_set_tmp_dh_callback to establish your callback.  In order to see
> what to do inside it, visit the www.openssl.org/docs/ssl/ssl.html.
There's
> an example here:
>
> http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html#
>
> I hope this doesn't steer you off the course.
>
> Dave McLellan - Consulting Software Engineer
> EMC Corporation
> 228 South St.
> Hopkinton MA 01748
> phone: 508-249-1257
> fax 508-497-8030
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Henry Su
> Sent: Friday, January 21, 2005 3:11 PM
> To: openssl-users@openssl.org
> Subject: RE: SSL error: no cipher list
>
> No sure if you have set it or not. If not, you can try following example:
>
> #define CIPHER_LIST "ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH"
>
> SSL_CTX_set_cipher_list(ctx, CIPHER_LIST) ;
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Yuriy Synov
> Sent: Friday, January 21, 2005 6:15 AM
> To: openssl
> Subject: SSL error: no cipher list
>
>
> Dear All,
>
> I get this error with one POP3 server when I call function SSL_connect:
>
> error:1406D0B8:SSL routines:GET_SERVER_HELLO:no cipher list
>
> Could someone tell me what it means and how I can get rid of it? TIA
>
> Best regards,
>
> Yuriy Synov.
>
> __
> 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]
> __
> 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: SSL error: no cipher list

[Dr. Stephen Henson]

On Mon, Jan 24, 2005, Yuriy Synov wrote:

> > See if you can connect to the server using the s_client test program. For
> > example:
> >
> > openssl s_client -conntect hostname:995
> >
> > (use whatever port it uses for POP4+SSL, 995 is standard).
> 
> Output from 'openssl s_client' follows:
> 
> [EMAIL PROTECTED] /]# openssl s_client -connect
> ipostoffice.worldnet.att.net:995
> CONNECTED(0005)
> depth=1 /C=US/O=RSA Data Security, Inc./OU=Secure Server Certification
> Authority
> verify error:num=19:self signed certificate in certificate chain
> verify return:0
> No client certificate CA names sent
> ---
> +OK <[EMAIL PROTECTED]> (mtiwpxc03) Maillennium POP3/PROXY
> server
>  #2
> 
> and after that I can enter POP3 commands.
> 

That shows that the server is OK and OpenSSL can comminicate with it properly.
There must be a bug in your program somewhere.

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: SSL error: no cipher list

[Yuriy Synov]

> See if you can connect to the server using the s_client test program. For
> example:
>
> openssl s_client -conntect hostname:995
>
> (use whatever port it uses for POP4+SSL, 995 is standard).

Output from 'openssl s_client' follows:

[EMAIL PROTECTED] /]# openssl s_client -connect
ipostoffice.worldnet.att.net:995
CONNECTED(0005)
depth=1 /C=US/O=RSA Data Security, Inc./OU=Secure Server Certification
Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/C=US/ST=New
Jersey/L=Middletown/O=AT&T/OU=WorldNet/CN=ipostoffice.worldnet
.att.net
   i:/C=US/O=RSA Data Security, Inc./OU=Secure Server Certification
Authority
 1 s:/C=US/O=RSA Data Security, Inc./OU=Secure Server Certification
Authority
   i:/C=US/O=RSA Data Security, Inc./OU=Secure Server Certification
Authority
---
Server certificate
-BEGIN CERTIFICATE-
MIIDxzCCAzSgAwIBAgIQePDFqFMk1AlFDRG1iBFXWzANBgkqhkiG9w0BAQUFADBf
MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4x
LjAsBgNVBAsTJVNlY3VyZSBTZXJ2ZXIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
HhcNMDQwNTA2MDAwMDAwWhcNMDUwNTA2MjM1OTU5WjCBgDELMAkGA1UEBhMCVVMx
EzARBgNVBAgTCk5ldyBKZXJzZXkxEzARBgNVBAcUCk1pZGRsZXRvd24xDTALBgNV
BAoUBEFUJlQxETAPBgNVBAsUCFdvcmxkTmV0MSUwIwYDVQQDFBxpcG9zdG9mZmlj
ZS53b3JsZG5ldC5hdHQubmV0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDl
bCW+xGGUN+ZIzU8yv7GTDdOs65VWmA41ud0ds4wIbWgL3sJb6fhFc5gdG6BvpwTb
nYRAxTY8bGwdK2Lg4SIINtvztSEAknArhkEcRokLQDGU19AEyu3sFVh9ZXmXQho0
yz9E2kyhaHqGGIXxuD5WcW4gOPuNThfT757NR4Le/wIDAQABo4IBZDCCAWAwCQYD
VR0TBAIwADALBgNVHQ8EBAMCBaAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL2Ny
bC52ZXJpc2lnbi5jb20vUlNBU2VjdXJlU2VydmVyLmNybDBEBgNVHSAEPTA7MDkG
C2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWdu
LmNvbS9ycGEwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMDQGCCsGAQUF
BwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMG0G
CCsGAQUFBwEMBGEwX6FdoFswWTBXMFUWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoE
FI/l0xqGrI2Oa8PPgGrUSBgsexkuMCUWI2h0dHA6Ly9sb2dvLnZlcmlzaWduLmNv
bS92c2xvZ28uZ2lmMA0GCSqGSIb3DQEBBQUAA34AIUYu0VU0LawRz2Q1n2YMtdoK
m9tv5M9ITwUwol4H8WcyF8R5nGk6bxUNtRciNVhIjRiwD0n+A/OAV1d3jDCrX+LH
MjgKRrELnFLc48WRrSTaK7PT50yvbWF+BaimQc0IOBhHfuk4d4wVF5UStyeZ6n6s
bNIq4dp8oSfR9ME=
-END CERTIFICATE-
subject=/C=US/ST=New
Jersey/L=Middletown/O=AT&T/OU=WorldNet/CN=ipostoffice.world
net.att.net
issuer=/C=US/O=RSA Data Security, Inc./OU=Secure Server Certification
Authority
---
No client certificate CA names sent
---
SSL handshake has read 1692 bytes and written 310 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 1024 bit
SSL-Session:
Protocol  : TLSv1
Cipher: RC4-SHA
Session-ID:
227FD6BC3D6953F53EFB198EEC8B2280349FF1BB5D41CDC9E8260CEF3C5C8177
Session-ID-ctx:
Master-Key:
917594C0A1347D67F83D554B1A35A77A39166F7152B71BD306BBF84C483C5D84
2FE561021BD6B782E032552F40A54392
Key-Arg   : None
Start Time: 1106569919
Timeout   : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
+OK <[EMAIL PROTECTED]> (mtiwpxc03) Maillennium POP3/PROXY
server
 #2

and after that I can enter POP3 commands.

- Original Message -
From: "Dr. Stephen Henson" <[EMAIL PROTECTED]>
To: 
Sent: Saturday, January 22, 2005 2:19 PM
Subject: Re: SSL error: no cipher list


> On Sat, Jan 22, 2005, Yuriy Synov wrote:
>
> > > No sure if you have set it or not. If not, you can try following
example:
> > >
> > > #define CIPHER_LIST "ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH"
> > >
> > > SSL_CTX_set_cipher_list(ctx, CIPHER_LIST) ;
> >
> > I tried to set that cipher list, and now I get the following error:
> >
> > error:140650B5:SSL routines:CLIENT_HELLO:no ciphers available
> >
> > I also tried "ALL" and some other cipher lists, and I always get one of
> > these errors:
> >
> > 1) error:140650B5:SSL routines:CLIENT_HELLO:no ciphers available
> > 2) error:1406D0B8:SSL routines:GET_SERVER_HELLO:no cipher list
> >
> > Microsoft Outlook Express 6.0 and Nokia 9500 smartphone messaging client
do
> > work with the POP3 server that causes the trouble. Is it possible, that
the
> > server does not conform to SSL standards, and these softwares ignore it,
but
> > the OpenSSL library is more strict?
> >
>
> See if you can connect to the server using the s_client test program. For
> example:
>
> openssl s_client -conntect hostname:995
>
> (use whatever port it uses for POP4+SSL, 995 is standard).
>
> 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
> __

RE: SSL error: no cipher list

[mclellan, dave]

On my first SSL implementation, I struggled with this specific error.  The
Diffie-Hellman parameters for key exchange must be initialized, and if I
remember correctly they weren't in my case.  

You must set up a callback to your code where it initializes DH parms. Call
SSL_CTX_set_tmp_dh_callback to establish your callback.  In order to see
what to do inside it, visit the www.openssl.org/docs/ssl/ssl.html.  There's
an example here: 

http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html#

I hope this doesn't steer you off the course. 

Dave McLellan - Consulting Software Engineer
EMC Corporation
228 South St. 
Hopkinton MA 01748
phone: 508-249-1257
fax 508-497-8030



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Henry Su
Sent: Friday, January 21, 2005 3:11 PM
To: openssl-users@openssl.org
Subject: RE: SSL error: no cipher list

No sure if you have set it or not. If not, you can try following example:

#define CIPHER_LIST "ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH"

SSL_CTX_set_cipher_list(ctx, CIPHER_LIST) ;

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Yuriy Synov
Sent: Friday, January 21, 2005 6:15 AM
To: openssl
Subject: SSL error: no cipher list


Dear All,

I get this error with one POP3 server when I call function SSL_connect:

error:1406D0B8:SSL routines:GET_SERVER_HELLO:no cipher list

Could someone tell me what it means and how I can get rid of it? TIA

Best regards,

Yuriy Synov.

__
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]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: SSL error: no cipher list

[Dr. Stephen Henson]

On Sat, Jan 22, 2005, Yuriy Synov wrote:

> > No sure if you have set it or not. If not, you can try following example:
> >
> > #define CIPHER_LIST "ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH"
> >
> > SSL_CTX_set_cipher_list(ctx, CIPHER_LIST) ;
> 
> I tried to set that cipher list, and now I get the following error:
> 
> error:140650B5:SSL routines:CLIENT_HELLO:no ciphers available
> 
> I also tried "ALL" and some other cipher lists, and I always get one of
> these errors:
> 
> 1) error:140650B5:SSL routines:CLIENT_HELLO:no ciphers available
> 2) error:1406D0B8:SSL routines:GET_SERVER_HELLO:no cipher list
> 
> Microsoft Outlook Express 6.0 and Nokia 9500 smartphone messaging client do
> work with the POP3 server that causes the trouble. Is it possible, that the
> server does not conform to SSL standards, and these softwares ignore it, but
> the OpenSSL library is more strict?
> 

See if you can connect to the server using the s_client test program. For
example:

openssl s_client -conntect hostname:995

(use whatever port it uses for POP4+SSL, 995 is standard).

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: SSL error: no cipher list

[Yuriy Synov]

> No sure if you have set it or not. If not, you can try following example:
>
> #define CIPHER_LIST "ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH"
>
> SSL_CTX_set_cipher_list(ctx, CIPHER_LIST) ;

I tried to set that cipher list, and now I get the following error:

error:140650B5:SSL routines:CLIENT_HELLO:no ciphers available

I also tried "ALL" and some other cipher lists, and I always get one of
these errors:

1) error:140650B5:SSL routines:CLIENT_HELLO:no ciphers available
2) error:1406D0B8:SSL routines:GET_SERVER_HELLO:no cipher list

Microsoft Outlook Express 6.0 and Nokia 9500 smartphone messaging client do
work with the POP3 server that causes the trouble. Is it possible, that the
server does not conform to SSL standards, and these softwares ignore it, but
the OpenSSL library is more strict?

- Original Message -
From: "Henry Su" <[EMAIL PROTECTED]>
To: 
Sent: Friday, January 21, 2005 10:10 PM
Subject: RE: SSL error: no cipher list


> No sure if you have set it or not. If not, you can try following example:
>
> #define CIPHER_LIST "ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH"
>
> SSL_CTX_set_cipher_list(ctx, CIPHER_LIST) ;
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Yuriy Synov
> Sent: Friday, January 21, 2005 6:15 AM
> To: openssl
> Subject: SSL error: no cipher list
>
>
> Dear All,
>
> I get this error with one POP3 server when I call function SSL_connect:
>
> error:1406D0B8:SSL routines:GET_SERVER_HELLO:no cipher list
>
> Could someone tell me what it means and how I can get rid of it? TIA
>
> Best regards,
>
> Yuriy Synov.
>
> __
> 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]
>

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

RE: SSL error: no cipher list

[Henry Su]

No sure if you have set it or not. If not, you can try following example:

#define CIPHER_LIST "ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH"

SSL_CTX_set_cipher_list(ctx, CIPHER_LIST) ;

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Yuriy Synov
Sent: Friday, January 21, 2005 6:15 AM
To: openssl
Subject: SSL error: no cipher list


Dear All,

I get this error with one POP3 server when I call function SSL_connect:

error:1406D0B8:SSL routines:GET_SERVER_HELLO:no cipher list

Could someone tell me what it means and how I can get rid of it? TIA

Best regards,

Yuriy Synov.

__
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]

SSL error: no cipher list

[Yuriy Synov]

Dear All,

I get this error with one POP3 server when I call function SSL_connect:

error:1406D0B8:SSL routines:GET_SERVER_HELLO:no cipher list

Could someone tell me what it means and how I can get rid of it? TIA

Best regards,

Yuriy Synov.

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

SSL Error

[Castillo, Mike]

 Hello All,

 

I am getting an error in my Apache log:

 

Mod_ossl: Unable to establish SSL protocol (server name)

Mod_ossl: SSL call to NZ function nzos_Handshake failed with
error 28864

 

 

Any idea why this is happening?

 

 

 

Thanks

 

_

 

Michael
A.Castillo

Database Specialist

University of Texas
at El Paso

Ph:915-747-5167

El Paso,Texas  79968

_

 

 

 

 

SSL Error re pass phrase

[H. Carter Harris]

I'm trying to get two vhosts on separate public IPs using separate secure
certificates working on an apache server (mods and version in log below).
The operating system is Mandrake 10.  The sites work perfectly without the
secure certificates as IP based vhosts.

I've been playing with the Vhosts.conf trying to get the directives right
but haven't figured out the problem.  I now have the SSL directives
commented out on one of the sites and I'm getting the following errors in
error_log on my apache server on the other site when I try to do a graceful
restart:

-- Snip Begin
[Fri Aug 13 21:52:32 2004] [notice] Graceful restart requested, doing
restart
[Fri Aug 13 21:52:41 2004] [notice] Digest: generating secret for digest
authentication ...
[Fri Aug 13 21:52:41 2004] [notice] Digest: done
[Fri Aug 13 21:52:41 2004] [error] Init: Unable to read pass phrase [Hint:
key introduced or changed before restart?]
[Fri Aug 13 21:52:41 2004] [error] SSL Library Error: 218710120
error:0D094068:lib(13):func(148):reason(104)
[Fri Aug 13 21:52:41 2004] [error] SSL Library Error: 218529960
error:0D0680A8:lib(13):func(104):reason(168)
[Fri Aug 13 21:52:41 2004] [error] SSL Library Error: 218595386
error:0D07803A:lib(13):func(120):reason(58)
[Fri Aug 13 21:52:41 2004] [error] SSL Library Error: 218734605
error:0D09A00D:lib(13):func(154):reason(13)

[Fri Aug 13 21:55:53 2004] [notice] suEXEC mechanism enabled (wrapper:
/usr/sbin/apache2-suexec)
[Fri Aug 13 21:55:53 2004] [notice] Digest: generating secret for digest
authentication ...
[Fri Aug 13 21:55:53 2004] [notice] Digest: done
[Fri Aug 13 21:55:53 2004] [notice] Apache-AdvancedExtranetServer/2.0.48
(Mandrake Linux/6mdk) mod_perl/1.99_11 Perl/v5.8.3 mod_ssl/2.0.48
OpenSSL/0.9.7c PHP/4.3.4 configured -- resuming normal operations
-- Snip End

It appears that I have damanged the certificates in some way.  I've googled
for all the keywords in SSL Library Errors and "Unable to read pass phrase"
but can't seem to find an answer.  A document that discusses multiple secure
certs on a single server would be welcome.

The Vhosts.conf for the site that is generating the erros has the following
SSL directives:


DocumentRoot /home/domainname_com/public_html
ServerName www.domainname.com
SSLEngine on
SSLCertificateFile /etc/httpd/2.0/conf/ssl.crt/www.domainname.com.cer
SSLCertificateKeyFile /etc/httpd/2.0/conf/ssl.key/www.domainname.com.key
SSLCertificateChainFile /etc/httpd/2.0/conf/ssl.crt/sf_issuing.cer
RewriteEngine On
RewriteOptions inherit
Alias /awstatsicons "/home/domainname_com/public_html/icon/"
ScriptAlias /awstats/ "home/domainname_com/public_html/cgi-bin/"
Setenv VLOG /home/domainname_com/logs
# ErrorLogs /home/domainname_com/logs/test2-error_log


I'm at a loss and would appreciate any guidance.


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

SSL Error SSL3_GET_MESSAGE

[McLeod Rodney V Contr HQ SSG/BICE]

Title: SSL Error SSL3_GET_MESSAGE







I have an error in the SSL logs that I don't know how to fix.  From the research I've done this is caused by a cert larger than 1024 bits.

Upgrade is not an option at this time because of the application


My configuration is 


NT 4.0

Oracle 9ias application server with Apache 1.2.19 (win32)

Mod_ssl 2.8.1

Open_ssl 0.9.5a



[19/Feb/2004 10:13:00 00229] [error] SSL handshake failed (server x.x.com:443, client xxx.xxx.xxx.xxx) (OpenSSL library error follows) 

[19/Feb/2004 10:13:00 00229] [error] OpenSSL: error:1408E098:SSL routines:SSL3_GET_MESSAGE:excessive message size 


Thanks for any help you can provide

Rodney

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]

Re: SSL error status: error:1408F455:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac

[Lutz Jaenicke]

On Wed, Dec 04, 2002 at 01:56:12PM -0500, Will Day wrote:
> >I tried to verify my cert using:
> >error 20 at 0 depth lookup:unable to get local issuer certificate
> >
> >What does error 20 mean?  The cert works when using https, imaps, pop3s,
> >etc.

unable to get local issuer certificate means that the chain verification
failed. Use the -CAfile option to supply the corresponding root CA
certificate(s).

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