Re: [openssl.org #842] [PATCH] Reduce probability of duplicate serial numbers
If you want to address incorrect cookbooks, you could error out on zero or you could replace zero with the current time. Or you could pester the cookbook authors. I'm not sure a warning would help much. In any case, it would be nice if someone could check in the patches so far. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: New OpenSSL releases fix denial of service attacks [17 March 2004]
Question: How can s->s3->tmp.new_cipher be NULL at this point? Wouldn't the cipher-negotiation code have precluded this from happening? ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-04:05/openssl.patch -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark J Cox Sent: Wednesday, March 17, 2004 5:13 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: New OpenSSL releases fix denial of service attacks [17 March 2004] 1. Null-pointer assignment during SSL handshake === Testing performed by the OpenSSL group using the Codenomicon TLS Test Tool uncovered a null-pointer assignment in the do_change_cipher_spec() function. A remote attacker could perform a carefully crafted SSL/TLS handshake against a server that used the OpenSSL library in such a way as to cause OpenSSL to crash. Depending on the application this could lead to a denial of service. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0079 to this issue. All versions of OpenSSL from 0.9.6c to 0.9.6k inclusive and from 0.9.7a to 0.9.7c inclusive are affected by this issue. Any application that makes use of OpenSSL's SSL/TLS library may be affected. Please contact your application vendor for details. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
EBCDIC patches for 0.9.7c
Because Evan Jennings asked in openssl-users for EBCDIC patches for the 0.9.7 branch, i post here my collection of EBCDIC patches for 0.9.7c. This collection comprises also the (slightly extended) patches from Howard Chu posted here some months ago. Because requests for the EBCDIC patches occur regularly, i would appreciate their incorporation into the official OpenSSL sources. We tested them in conjunction with an Apache web server and FTP/Telnet client and server. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH ebcdic-patch.tar.gz Description: GNU Zip compressed data
Re: Fw: PKCS7 signature process standard question
On Wed, Mar 17, 2004, [EMAIL PROTECTED] wrote:
> from Pk7_doit.c
>
>if ((sk != NULL) && (sk_X509_ATTRIBUTE_num(sk) != 0))
> {
> unsigned char md_data[EVP_MAX_MD_SIZE], *abuf=NULL;
> unsigned int md_len, alen;
> ASN1_OCTET_STRING *digest;
> ASN1_UTCTIME *sign_time;
> const EVP_MD *md_tmp;
>
> /* Add signing time if not already present */
> if (!PKCS7_get_signed_attribute(si,
>NID_pkcs9_signingTime))
> {
> sign_time=X509_gmtime_adj(NULL,0);
> PKCS7_add_signed_attribute(si,
> NID_pkcs9_signingTime,
> V_ASN1_UTCTIME,sign_time);
> }
>
> /* Add digest */
> md_tmp=EVP_MD_CTX_md(&ctx_tmp);
> EVP_DigestFinal_ex(&ctx_tmp,md_data,&md_len);
> digest=M_ASN1_OCTET_STRING_new();
> M_ASN1_OCTET_STRING_set(digest,md_data,md_len);
> PKCS7_add_signed_attribute(si,
> NID_pkcs9_messageDigest,
> V_ASN1_OCTET_STRING,digest);
>
> /* Now sign the attributes */
> EVP_SignInit_ex(&ctx_tmp,md_tmp,NULL);
>
>
> Seems that EVP_DigestFinal_ex and then EVP_SignInit_ex reinitialize MD
> calculation.
> Then
>
> alen = ASN1_item_i2d((ASN1_VALUE *)sk,&abuf,
>ASN1_ITEM_rptr(PKCS7_ATTR_SIGN));
> if(!abuf) goto err;
> EVP_SignUpdate(&ctx_tmp,abuf,alen);
>
> calculate digest only on attributes.
>
> Where is my error?
>
If attributes are present the mesageDigest attribute contains the digest of
the message content. The encoding of the attributes is then signed. That was
always the intention (and what the various interop tests used) but the wording
sometimes didn't make it clear.
See for example RFC3369 5.4:
"When the field [signedAttrs] is present, however, the result is the message
digest of the complete DER encoding of the SignedAttrs value
contained in the signedAttrs field. Since the SignedAttrs value,
when present, must contain the content-type and the message-digest
attributes, those values are indirectly included in the result."
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
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Fw: PKCS7 signature process standard question
from Pk7_doit.c
if ((sk != NULL) && (sk_X509_ATTRIBUTE_num(sk) != 0))
{
unsigned char md_data[EVP_MAX_MD_SIZE], *abuf=NULL;
unsigned int md_len, alen;
ASN1_OCTET_STRING *digest;
ASN1_UTCTIME *sign_time;
const EVP_MD *md_tmp;
/* Add signing time if not already present */
if (!PKCS7_get_signed_attribute(si,
NID_pkcs9_signingTime))
{
sign_time=X509_gmtime_adj(NULL,0);
PKCS7_add_signed_attribute(si,
NID_pkcs9_signingTime,
V_ASN1_UTCTIME,sign_time);
}
/* Add digest */
md_tmp=EVP_MD_CTX_md(&ctx_tmp);
EVP_DigestFinal_ex(&ctx_tmp,md_data,&md_len);
digest=M_ASN1_OCTET_STRING_new();
M_ASN1_OCTET_STRING_set(digest,md_data,md_len);
PKCS7_add_signed_attribute(si,
NID_pkcs9_messageDigest,
V_ASN1_OCTET_STRING,digest);
/* Now sign the attributes */
EVP_SignInit_ex(&ctx_tmp,md_tmp,NULL);
Seems that EVP_DigestFinal_ex and then EVP_SignInit_ex reinitialize MD
calculation.
Then
alen = ASN1_item_i2d((ASN1_VALUE *)sk,&abuf,
ASN1_ITEM_rptr(PKCS7_ATTR_SIGN));
if(!abuf) goto err;
EVP_SignUpdate(&ctx_tmp,abuf,alen);
calculate digest only on attributes.
Where is my error?
Francesco Petruzzi
[EMAIL PROTECTED]
The information contained in this electronic message and any attachments
(the "Message") is intended for one or more specific individuals or
entities, and may be confidential, proprietary, privileged or otherwise
protected by law. If you are not the intended recipient, please notify the
sender immediately, delete this Message and do not disclose, distribute, or
copy it to any third party or otherwise use this Message. Electronic
messages are not secure or error free and can contain viruses or may be
delayed, and the sender is not liable for any of these occurrences. The
sender reserves the right to monitor, record and retain electronic messages.
Le informazioni contenute in questo messaggio e gli eventuali allegati (il
"Messaggio") si intendono inviate a uno o piú specifici destinatari. Il
contenuto del Messaggio puó essere confidenziale, riservato e comunque
protetto dalla legge applicabile. Se non siete i destinatari del Messaggio,
siete pregati di informare immediatamente il mittente, cancellare questo
Messaggio, non rivelarlo, non distribuirlo ne' inoltrarlo a terzi, non
copiarlo né farne alcun uso. I messaggi di posta elettronica non sono sicuri
e sono soggetti ad alterazioni, possono essere trasmettitori di Virus
informatici o soggetti a ritardi nella distribuzione. Il mittente del
Messaggio non puó essere in alcun modo considerato responsabile per queste
evenienze. Il mittente si riserva il diritto di archiviare, ritenere e
controllare i messaggi di posta elettronica.
- Original Message -
From: "Dr. Stephen Henson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 17, 2004 5:53 PM
Subject: Re: Fw: PKCS7 signature process standard question
> On Wed, Mar 17, 2004, [EMAIL PROTECTED] wrote:
>
> > >From RFC2630:
> >
> > 5.4 Message Digest Calculation Process
> >
> >The message digest calculation process computes a message digest on
> >either the content being signed or the content together with the
> >signed attributes. In either case, the initial input to the message
> >digest calculation process is the "value" of the encapsulated content
> >being signed. Specifically, the initial input is the
> >encapContentInfo eContent OCTET STRING to which the signing process
> >is applied. Only the octets comprising the value of the eContent
> >OCTET STRING are input to the message digest algorithm, not the tag
> >or the length octets.
> > The result of the message digest calculation process depends on
> >whether the signedAttributes field is present. When the field is
> >absent, the result is just the message digest of the content as
> >described above. When the field is present, however, the result is
> >the message digest of the complete DER encoding of the
> >SignedAttributes value contained in the signedAttributes field.
> >
> >
> > Is this the standard?
>
> Yes.
>
> > Why openssl use only the authenticated attributes for digest
calculation?
> >
>
> It doesn't. What makes you think it does?
>
> 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
> Development Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
__
OpenSSL Project http://www.openssl.org
Development Mailing List
Re: Fw: PKCS7 signature process standard question
On Wed, Mar 17, 2004, [EMAIL PROTECTED] wrote: > >From RFC2630: > > 5.4 Message Digest Calculation Process > >The message digest calculation process computes a message digest on >either the content being signed or the content together with the >signed attributes. In either case, the initial input to the message >digest calculation process is the "value" of the encapsulated content >being signed. Specifically, the initial input is the >encapContentInfo eContent OCTET STRING to which the signing process >is applied. Only the octets comprising the value of the eContent >OCTET STRING are input to the message digest algorithm, not the tag >or the length octets. > The result of the message digest calculation process depends on >whether the signedAttributes field is present. When the field is >absent, the result is just the message digest of the content as >described above. When the field is present, however, the result is >the message digest of the complete DER encoding of the >SignedAttributes value contained in the signedAttributes field. > > > Is this the standard? Yes. > Why openssl use only the authenticated attributes for digest calculation? > It doesn't. What makes you think it does? 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 Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Fw: PKCS7 signature process standard question
From RFC2630: 5.4 Message Digest Calculation Process The message digest calculation process computes a message digest on either the content being signed or the content together with the signed attributes. In either case, the initial input to the message digest calculation process is the "value" of the encapsulated content being signed. Specifically, the initial input is the encapContentInfo eContent OCTET STRING to which the signing process is applied. Only the octets comprising the value of the eContent OCTET STRING are input to the message digest algorithm, not the tag or the length octets. The result of the message digest calculation process depends on whether the signedAttributes field is present. When the field is absent, the result is just the message digest of the content as described above. When the field is present, however, the result is the message digest of the complete DER encoding of the SignedAttributes value contained in the signedAttributes field. Is this the standard? Why openssl use only the authenticated attributes for digest calculation? Francesco Petruzzi [EMAIL PROTECTED] The information contained in this electronic message and any attachments (the "Message") is intended for one or more specific individuals or entities, and may be confidential, proprietary, privileged or otherwise protected by law. If you are not the intended recipient, please notify the sender immediately, delete this Message and do not disclose, distribute, or copy it to any third party or otherwise use this Message. Electronic messages are not secure or error free and can contain viruses or may be delayed, and the sender is not liable for any of these occurrences. The sender reserves the right to monitor, record and retain electronic messages.Le informazioni contenute in questo messaggio e gli eventuali allegati (il "Messaggio") si intendono inviate a uno o piú specifici destinatari. Il contenuto del Messaggio puó essere confidenziale, riservato e comunque protetto dalla legge applicabile. Se non siete i destinatari del Messaggio, siete pregati di informare immediatamente il mittente, cancellare questo Messaggio, non rivelarlo, non distribuirlo ne' inoltrarlo a terzi, non copiarlo né farne alcun uso. I messaggi di posta elettronica non sono sicuri e sono soggetti ad alterazioni, possono essere trasmettitori di Virus informatici o soggetti a ritardi nella distribuzione. Il mittente del Messaggio non puó essere in alcun modo considerato responsabile per queste evenienze. Il mittente si riserva il diritto di archiviare, ritenere e controllare i messaggi di posta elettronica.
C code structure at OpenSSL
I´m writting this again, cause the date to do this work is getting close... I need a reference text about each directory in openssl-0.9.7c. Like: apps - here is the directory of applications: - .c do this - .h make part of thar library.. MacOS - . ssl - If someone can help-me.. cause I didn´t find any documentation like this. thanks for you all. -- Reginaldo de Oliveira Santos BRAZIL - UNESP - BAURU BCC 2003 -- Mensagem enviada pelo Webmail da Faculdade de Ciências __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
New OpenSSL releases fix denial of service attacks [17 March 2004]
-BEGIN PGP SIGNED MESSAGE- OpenSSL Security Advisory [17 March 2004] Updated versions of OpenSSL are now available which correct two security issues: 1. Null-pointer assignment during SSL handshake === Testing performed by the OpenSSL group using the Codenomicon TLS Test Tool uncovered a null-pointer assignment in the do_change_cipher_spec() function. A remote attacker could perform a carefully crafted SSL/TLS handshake against a server that used the OpenSSL library in such a way as to cause OpenSSL to crash. Depending on the application this could lead to a denial of service. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0079 to this issue. All versions of OpenSSL from 0.9.6c to 0.9.6k inclusive and from 0.9.7a to 0.9.7c inclusive are affected by this issue. Any application that makes use of OpenSSL's SSL/TLS library may be affected. Please contact your application vendor for details. 2. Out-of-bounds read affects Kerberos ciphersuites === Stephen Henson discovered a flaw in SSL/TLS handshaking code when using Kerberos ciphersuites. A remote attacker could perform a carefully crafted SSL/TLS handshake against a server configured to use Kerberos ciphersuites in such a way as to cause OpenSSL to crash. Most applications have no ability to use Kerberos ciphersuites and will therefore be unaffected. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0112 to this issue. Versions 0.9.7a, 0.9.7b, and 0.9.7c of OpenSSL are affected by this issue. Any application that makes use of OpenSSL's SSL/TLS library may be affected. Please contact your application vendor for details. Recommendations - --- Upgrade to OpenSSL 0.9.7d or 0.9.6m. Recompile any OpenSSL applications statically linked to OpenSSL libraries. OpenSSL 0.9.7d and OpenSSL 0.9.6m are available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): ftp://ftp.openssl.org/source/ The distribution file names are: o openssl-0.9.7d.tar.gz MD5 checksum: 1b49e90fc8a75c3a507c0a624529aca5 o openssl-0.9.6m.tar.gz [normal] MD5 checksum: 1b63bfdca1c37837e9f1623498f9 o openssl-engine-0.9.6m.tar.gz [engine] MD5 checksum: 4c39d2524bd466180f9077f8efddac8c The checksums were calculated using the following command: openssl md5 openssl-0.9*.tar.gz Credits - --- Patches for these issues were created by Dr Stephen Henson ([EMAIL PROTECTED]) of the OpenSSL core team. The OpenSSL team would like to thank Codenomicon for supplying the TLS Test Tool which was used to discover these vulnerabilities, and Joe Orton of Red Hat for performing the majority of the testing. References - -- http://www.codenomicon.com/testtools/tls/ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0079 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0112 URL for this Security Advisory: http://www.openssl.org/news/secadv_20040317.txt -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUBQFhNTO6tTP1JpWPZAQGayAP/TpKP7CKrRR65w5+zr2/Nlw+Cz6UbY0Rd G1Po5mgZjaP4V63d2TD11IvvZLbjeIeGQj7GxKupcYCn2CxI83xjhwM71vsS6rvQ pQZAhM5IVvb4HERbGI0hryO10rd1V+fCTzxfB0pBsG1VtEL2jTULyuWgwsA/z0/j Ez3jSlsbRRA= =wvAZ -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
