RE: OpenSSL & "Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542)"
> From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm > Sent: Wednesday, 29 February, 2012 15:51 > I do not know why MS KB2643584 does not mention changing TLS 1.1 > and/or TLS 1.2 behavior, maybe someone familiar with the attack > described in CVE2011-3389 knows a reason. > Well, at least with the description. AFAICS they didn't release some of the details needed for the actual attack. (Which probably was wise.) TLS1.1 changes CBC mode to randomize the IV per record instead of chaining as SSL/TLS1.0 did, and thus is immune (if correctly implemented, as always). (And TLS1.2 keeps this improvement.) > My general guess at this time is that the MS workaround of > artificially splitting certain unspecified SSL records is not the > only way to fix CVE2011-3389 and that this particular workaround > has not been tested by the OpenSSL core team. > The fix simply sends two appdata records, first with length=1 and second with length=N-1. OpenSSL returns them separately, which applications might not handle (choice #3 in your list). SSL/TLS always promised "stream not guaranteeing boundaries" service like TCP which it was/is intended to substitute for. TCP apps do encounter splitting and joining in the real net and have had to cope with it or be limited to backwaters. But SSL/TLS implementations mostly *did* preserve boundaries before this fix (they have to do record-level processing anyway, while TCP does segments directly on IP) and apps/programmers have tended to rely on it by mistake or laziness. OpenSSL some years back tried sending a record with length=0 and then the real one (length=N), which also defeats the attack but is more debatable and certainly counterintuitive and was found to cause problems with other implementations. It might work better now; I haven't heard that an effort has been made to re-check -- it would probably need many volunteers to cover the gamut. See SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS . > I hope that now that we have apparently tracked this to a general > MS implementation change which is unrelated to the restricted CAC > hardware, that figuring out the OpenSSL compatibility issue will > be a lot easier than when only USG employees and contractors with > a CAC card could do the testing. > As Dr. Henson's replies indicate, there must be some other factor here. Yes if it can be reproduced openly that should help. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
SSL3_GET_SERVER_HELLO:wrong cipher returned
We have experienced what appears to be a thread-safety issue with ssl3_get_server_hello(). It works for the most part but then after traffic starts to increase on the server utilizing OpenSSL... we get the error: [Wed Feb 29 12:00:01 2012] [info] SSL Library Error: 336142597 error:14092105:SSL routines:SSL3_GET_SERVER_HELLO:wrong cipher returned Here is our version of OpenSSL on this Rhel5 server: rpm -qa | grep openssl openssl-0.9.8e-12.el5_4.6 openssl-devel-0.9.8e-12.el5_4.6 What can we do to work-around this problem? More about our use case: We have Apache/2.2.21 (Unix) mod_ssl/2.2.21 OpenSSL/0.9.8e-fips-rhel5 configured. The HTTPD Server has reverse proxy set up to communicate back and forth between Apache and an VIP of an F5 load balancer. The server has good healthy operations until suddenly openSSL seems to break down with the error above. -- View this message in context: http://old.nabble.com/SSL3_GET_SERVER_HELLO%3Awrong-cipher-returned-tp33424606p33424606.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
openssl smime CLI using password for encryption
Hi All, Does openssl smime CLI supports encryption using password, instead of using recepient certificate? Thanks, Erwin
Re: Problem with chaining certs and CRLS
Never mind, I found an extremely ugly solution: 1) I split the signature extracted (signers.tmp) in single signature files (signer1.tmp e signer2.tmp) by python script 2) I test them both with the following command, using as CAfile the complete one: openssl verify -verbose -CRLfile "chain.tmp" -CAfile "signers.tmp" -CApath ./cadir -crl_check_all "signer1.tmp" "signer2.tmp" this way it works and recognizes correctly if a certificate has been revoked.. If anyone comes up with a cleaner solution I'd really like to hear about it! Mario Il giorno 01/mar/2012, alle ore 15.58, Jakob Bohm ha scritto: > On 3/1/2012 12:41 PM, mario piccinelli wrote: >> Hi everyone >> >> I'm stuck with a situation about openssl and I really don't know how to get >> out.. >> >> What I'm trying to do is build a three level chain to sign files: >> - a root cert >> - an user cert >> - and end cert >> >> At the user level a revocation list can be produced to revoke the user's end >> certs. >> I create a PEM file with a detached signature, and I include in that the >> user cert and the end cert. >> >> After receiving the file, I do the following: >> - concatenate all the CRLs AND the root cert in a single file named chain.tmp >> - extract the certs from the SMIME message: >> openssl pkcs7 -print_certs -in "data.p7m" -out "signers.tmp" >> >> then I try to verify the signers' certs (user cert and end cert) in >> signers.tmp with the CRLs and root cert in chain.tmp: >> >> openssl verify -CAfile "chain.tmp" -crl_check "signers.tmp" > What makes you think the CRLs should be in the file passed as -CAfile > argument? >> but I always get the error: unable to get certificate CRL >> >> I'm sure the CRL is correctly included in chain.tmp.. what am I doing wrong? >> I noticed that if I remove the root cert from chain.tmp it (obviously) >> complains about the lack of issuer certificate.. but it seems unable to see >> the CRL in the same file! >> >> Thanks to anyone who took the time even for reading through all of this :-) >> > > -- > Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com > Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10 > > This message is only for its intended recipient, delete if misaddressed. > 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 Mario Piccinelli --- "Dreamers come and go, but a dream's forever Freedom for all minds, let us go together Neverending ways, got to roam forever Always carry on!" --- Mail/Gtalk: mario.piccine...@gmail.com (GNUPG Key id: EE74003E) MSN: iamtheheroyoutr...@email.it Web: http://www.mariopiccinelli.it Blog: http://piccimario.wordpress.com Skype: piccimario Mobile (NEW!!!): 392-2488673 --- Proud & Happy Mac (and Linux) User --- Confidentiality Notice: This message, together with its annexes, contains strictly confidential information and is destined only to the addressee(s) identified above who only may use it under his/their responsibility. Anyone who receives this message by mistake or reads it without entitlement is forewarned that keeping, copying, disseminating or distributing this message to persons other than the addressee(s) is strictly forbidden. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Problem with chaining certs and CRLS
Thanks for the answer.. in fact nothing, but I found nothing about that in the documentation, and I made an experiment which seemed to prove that: I verified an end certificate using as CAfile a chain made of root cert, user cert and user CRL... and it worked correctly, before and after the revocation.. Do you know something else I don't? Could you suggest me a different approach? Thanks! Mario Il giorno 01/mar/2012, alle ore 15.58, Jakob Bohm ha scritto: > On 3/1/2012 12:41 PM, mario piccinelli wrote: >> Hi everyone >> >> I'm stuck with a situation about openssl and I really don't know how to get >> out.. >> >> What I'm trying to do is build a three level chain to sign files: >> - a root cert >> - an user cert >> - and end cert >> >> At the user level a revocation list can be produced to revoke the user's end >> certs. >> I create a PEM file with a detached signature, and I include in that the >> user cert and the end cert. >> >> After receiving the file, I do the following: >> - concatenate all the CRLs AND the root cert in a single file named chain.tmp >> - extract the certs from the SMIME message: >> openssl pkcs7 -print_certs -in "data.p7m" -out "signers.tmp" >> >> then I try to verify the signers' certs (user cert and end cert) in >> signers.tmp with the CRLs and root cert in chain.tmp: >> >> openssl verify -CAfile "chain.tmp" -crl_check "signers.tmp" > What makes you think the CRLs should be in the file passed as -CAfile > argument? >> but I always get the error: unable to get certificate CRL >> >> I'm sure the CRL is correctly included in chain.tmp.. what am I doing wrong? >> I noticed that if I remove the root cert from chain.tmp it (obviously) >> complains about the lack of issuer certificate.. but it seems unable to see >> the CRL in the same file! >> >> Thanks to anyone who took the time even for reading through all of this :-) >> > > -- > Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com > Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10 > > This message is only for its intended recipient, delete if misaddressed. > 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 Mario Piccinelli __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Problem with chaining certs and CRLS
On 3/1/2012 12:41 PM, mario piccinelli wrote: Hi everyone I'm stuck with a situation about openssl and I really don't know how to get out.. What I'm trying to do is build a three level chain to sign files: - a root cert - an user cert - and end cert At the user level a revocation list can be produced to revoke the user's end certs. I create a PEM file with a detached signature, and I include in that the user cert and the end cert. After receiving the file, I do the following: - concatenate all the CRLs AND the root cert in a single file named chain.tmp - extract the certs from the SMIME message: openssl pkcs7 -print_certs -in "data.p7m" -out "signers.tmp" then I try to verify the signers' certs (user cert and end cert) in signers.tmp with the CRLs and root cert in chain.tmp: openssl verify -CAfile "chain.tmp" -crl_check "signers.tmp" What makes you think the CRLs should be in the file passed as -CAfile argument? but I always get the error: unable to get certificate CRL I'm sure the CRL is correctly included in chain.tmp.. what am I doing wrong? I noticed that if I remove the root cert from chain.tmp it (obviously) complains about the lack of issuer certificate.. but it seems unable to see the CRL in the same file! Thanks to anyone who took the time even for reading through all of this :-) -- Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10 This message is only for its intended recipient, delete if misaddressed. 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
Problem with chaining certs and CRLS
Hi everyone I'm stuck with a situation about openssl and I really don't know how to get out.. What I'm trying to do is build a three level chain to sign files: - a root cert - an user cert - and end cert At the user level a revocation list can be produced to revoke the user's end certs. I create a PEM file with a detached signature, and I include in that the user cert and the end cert. After receiving the file, I do the following: - concatenate all the CRLs AND the root cert in a single file named chain.tmp - extract the certs from the SMIME message: openssl pkcs7 -print_certs -in "data.p7m" -out "signers.tmp" then I try to verify the signers' certs (user cert and end cert) in signers.tmp with the CRLs and root cert in chain.tmp: openssl verify -CAfile "chain.tmp" -crl_check "signers.tmp" but I always get the error: unable to get certificate CRL I'm sure the CRL is correctly included in chain.tmp.. what am I doing wrong? I noticed that if I remove the root cert from chain.tmp it (obviously) complains about the lack of issuer certificate.. but it seems unable to see the CRL in the same file! Thanks to anyone who took the time even for reading through all of this :-) Mario Piccinelli __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL & "Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542)"
On Thu, Mar 01, 2012, Jakob Bohm wrote:
> On 2/29/2012 11:43 PM, Dr. Stephen Henson wrote:
> >On Wed, Feb 29, 2012, Tammany, Curtis wrote:
> >
> >>I had brought this issue up earlier ("Windows 7/IE8 CAC enabled sites").
> >>With SSL 3.0 only checked on IE8 (in windows 7), I could make a connection
> >>to my site that had OpenSSL 1.0.0g. With both SSL 3.0 AND TLS 1.0 checked, I
> >>could not make a connection. We rolled back versions of OpenSSL until we got
> >>to 0.9.8r which could make a connection with both protocols enabled on the
> >>browser...
> >>
> >>Will there be a version that will address MS12-006? TLS1.1? TLS1.2?
> >>
> >>
> >At present I cannot reproduce the issues with MS12-006 so I can only guess as
> >to the cause. If I can or I can get appropriate feedback I can work on a fix,
> >assuming it isn't fixed already: see below. TLS 1.1 and 1.2 will only ever
> >appear in OpenSSL 1.0.1 and later as new features don't appear in stable
> >releases: just bug fixes. That is currently in beta and a few issues remain
> >to
> >be resolved before the full release.
> Please read that again. He wrote that 1.0.0 did NOT work, but 0.9.8 works.
He mentioned rolling back to 0.9.8r. I was double checking that no 1.0.0
release actually worked. My reason is that a change introduced in 0.9.8s
related to SGC could break some operations with MSIE unrelated to SGC:
specifically renegotiation, which client authentication makes use of.
> >
> >So a few guesses:
> >
> >If the problem is no longer present in OpenSSL 0.9.8r then 1.0.0e may also
> >work. The only known problem with later versions is the SGC DoS fix has a bug
> >in it which may affect renegotiation in some circumstances. This bug *should*
> >be fixed in the latest snapshots of OpenSSL: please see if they work OK for
> >you.
> Please refer to my initial literature check higher up in this thread.
>
> MS12-006 is Microsoft's name for CVE-2011-3389, which you hopefully
> know better than I do.
>
> Microsoft KB2643584 et al is Microsoft's patch for CVE-2011-3389.
>
> According to Microsoft, their patch selectively fragments some of the
> SSL and TLS records in order to prevent the attack. They claim that
> this fragmentation is the most likely cause of interoperability issues
> and point to specific clauses in the SSL 3.0 and TLS 1.0 RFC's as
> justification for saying that any incompatible software (which might
> include OpenSSL 1.0.0) is buggy for not being compatible with their
> change, although that might just be BS.
>
Well OpenSSL should cleanly deal with fragments. In fact it is other
implementations that have had issues with OpenSSL using empty fragments
that cause problems. Ironically it was as a work around for this very issue.
So while fragmentation is a possible cause I'd consider it unlikely and I
can't think of any changes after 0.9.8r that would have broken that.
The use of TLS 1.1 and 1.2 in MSIE might have an effect: if there are
interop problems with MS TLS 1.1,1.2 and older versions of OpenSSL. Though I
don't know why the OP would also need to disable TLS 1.0.
Since I can't reproduce this I'm wondering if the CAC cards introduce an
additional element. I can see two possible reasons why they might:
1. Client authentication requires renegotiation if it is enabled on certain
webpages and not across the whole site. The was a problem with version numbers
in premaster secrets with IIS which has been fixed: I wonder if there is a
similar one with MSIE which affects OpenSSL servers.
2. Renegotiation might trigger the SGC bug.
However none of these precisely fits the facts: I'd expect both to give some
characteristic errors in the log and not affect TLS 1.0.
Anyway to answer the OPs earlier request about s_server. It can behave like a
mini test webserver and can print out useful diagnostics. A command like:
openssl s_server -cert cert.pem -www
Will start it and you can then access this at port 4433 i.e.:
https://www.host.com:4433/
That by default will not request client authentication. If you include -verify
9 on the command line it will.
I'd be interested to know if you can connect to that server with or without
client authentication.
That isn't a complete test though as it doesn't include an option to
selectively request client authentication on certain web pages: which I
suspect the website causing problems does.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: OpenSSL & "Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542)"
On 2/29/2012 11:43 PM, Dr. Stephen Henson wrote:
On Wed, Feb 29, 2012, Tammany, Curtis wrote:
I had brought this issue up earlier ("Windows 7/IE8 CAC enabled sites").
With SSL 3.0 only checked on IE8 (in windows 7), I could make a connection
to my site that had OpenSSL 1.0.0g. With both SSL 3.0 AND TLS 1.0 checked, I
could not make a connection. We rolled back versions of OpenSSL until we got
to 0.9.8r which could make a connection with both protocols enabled on the
browser...
Will there be a version that will address MS12-006? TLS1.1? TLS1.2?
At present I cannot reproduce the issues with MS12-006 so I can only guess as
to the cause. If I can or I can get appropriate feedback I can work on a fix,
assuming it isn't fixed already: see below. TLS 1.1 and 1.2 will only ever
appear in OpenSSL 1.0.1 and later as new features don't appear in stable
releases: just bug fixes. That is currently in beta and a few issues remain to
be resolved before the full release.
Please read that again. He wrote that 1.0.0 did NOT work, but 0.9.8 works.
So a few guesses:
If the problem is no longer present in OpenSSL 0.9.8r then 1.0.0e may also
work. The only known problem with later versions is the SGC DoS fix has a bug
in it which may affect renegotiation in some circumstances. This bug *should*
be fixed in the latest snapshots of OpenSSL: please see if they work OK for
you.
Please refer to my initial literature check higher up in this thread.
MS12-006 is Microsoft's name for CVE-2011-3389, which you hopefully
know better than I do.
Microsoft KB2643584 et al is Microsoft's patch for CVE-2011-3389.
According to Microsoft, their patch selectively fragments some of the
SSL and TLS records in order to prevent the attack. They claim that
this fragmentation is the most likely cause of interoperability issues
and point to specific clauses in the SSL 3.0 and TLS 1.0 RFC's as
justification for saying that any incompatible software (which might
include OpenSSL 1.0.0) is buggy for not being compatible with their
change, although that might just be BS.
--
Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10
This message is only for its intended recipient, delete if misaddressed.
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
Re: CAC card, SMIME signing, Verification failure "header too long"
From: "cam" I'm having a problem generating a signed SMIME message. I have to interface with a CAC card reader that implements a subset of the pkcs11 standard. I pass the message to the card API and it returns a signed digest and now I need to pass this signed digest to openSSL to create the SMIME message. This is the card reader we're using: http://www.biometricassociates.com/reader.html Communication on CAC issues and associaterd software should be done within DoD PKI protected systems, NOT on public systems. Please communicate with DISA. http://iase.disa.mil/pki-pke/ Many software projects and discussions are on http://forge.mil/ -- Dave Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk http://www.pctipp.ch/downloads/dl/35905.asp __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL0.9.8e-12.el5_4.6 Getting SSL3_GET_SERVER_HELLO:wrong cipher returned during SSL handshake
We have experienced what appears to be a thread-safety issue with ssl3_get_server_hello(). It works for the most part but then after traffic starts to increase on the server utilizing OpenSSL... we get the error: [Wed Feb 29 12:00:01 2012] [info] SSL Library Error: 336142597 error:14092105:SSL routines:SSL3_GET_SERVER_HELLO:wrong cipher returned Here is our version of OpenSSL on this Rhel5 server: rpm -qa | grep openssl openssl-0.9.8e-12.el5_4.6 openssl-devel-0.9.8e-12.el5_4.6 What can we do to work-around this problem? More about our use case: We have Apache/2.2.21 (Unix) mod_ssl/2.2.21 OpenSSL/0.9.8e-fips-rhel5 configured. The HTTPD Server has reverse proxy set up to communicate back and forth between Apache and an VIP of an F5 load balancer. The server has good healthy operations until suddenly openSSL seems to break down with the error above. -- View this message in context: http://old.nabble.com/OpenSSL0.9.8e-12.el5_4.6-Getting-SSL3_GET_SERVER_HELLO%3Awrong-cipher-returned-during-SSL-handshake-tp33416364p33416364.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
