Re: problem with SSLv23_method()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 suneel musunuru wrote: ... another question that belongs to openssl-users... | My Server program has been implemented using the method | "SSLv23_method()" . So, by using this method my expectation is to accept | connections from TLS1, SSLv2 and SSLv3. | But When i tried with SSLv2 alone from Internet Explorer the server is | throwing the below error, Why do you do that ? SSLv2 is broken and shouldn't be used in a server unless it is really needed for legacy applications. | Error 23 fault: SOAP-ENV:Server [no subcode], | "SSL_ERROR_SSL | error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol", | Detail: SSL_accept() failed in soap_ssl_accept(). Is your server build with SSLv2 enabled and configured to accept SSLv2 ? AFAIK newer versions of OpenSSL have SSLv2 disabled by default. Bye Goetz - -- DMCA: The greed of the few outweighs the freedom of the many -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKtoOu2iGqZUF3qPYRArywAJ0RIqPyvVRNFhJo48+pxU5pSTLoagCff4mW FlH5jLuQGtbbDQ9BtNF5QOc= =WsfI -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: TLS CA Certificate Loading in DER format
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chaitra Shankar wrote: | So I wanted to know whether there is a way to load CA certificates | in DER format using any SSL APIs. | My search till now for such an API has been unfruitful. Yes, directly loading DER encoded certificates into an SSL_CTX is not supported. But you can load certificates manually and add them to the SSL_CTX using the SSL_CTX_add_extra_chain_cert() function. Goetz - -- DMCA: The greed of the few outweighs the freedom of the many -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKqqrb2iGqZUF3qPYRAoyaAJ4hD5FQ0S5ZuIEdFzBN7Su+FNjBHwCfX0UY oEfBBfgUiZR/zsuao7NKQ8Y= =X/f2 -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: server authentication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bill Schoolfield wrote: | Hello, Hello Bill, | I have a legacy app that I converted to use ssl encryption. I have | everything working, except server authentication. | | I'm trying to test the host name in the server's cert post | handshake. Using: [...] | I tried adding a call to SSL_CTX_set_verify() thinking this would | make the server's cert available, but all this did was generate the | following error on the server: | | SSL accept error | 23956:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert | unknown ca:s3_pkt.c:1053:SSL alert number 48 | | The server's certificate was self signed. What am I | missing? Several things. The first is: This is a question concerning the usage of OpenSSL. Such questions are to be posted in openssl-users. openssl-dev is for discussing the development of the OpenSSL library itself. To give a start for all the other things you and the servers administrator did do wrong please answer the following question: How does the client know that the certificate the server presents belongs to the server you want to connect ? A hint: checking the commonName field to contain the name of the host you want to connect is not sufficient, since everybody could generate a cert with this name in the commonName field. Bye Goetz - -- DMCA: The greed of the few outweighs the freedom of the many -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKewh82iGqZUF3qPYRAg6fAJ4/kSeDytN1ggrNkcxzMwexJZfo2ACffqi0 zs4gWreLbVmxjRZhvBEjHDo= =e9Ec -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: warning: data definition has no type or storage class
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 omronz wrote: | hmm, so you mean that these are function call statements? or is it a function | prototype? Yes, i was aware about the data type of the function prototype, | but since I never tried OpenSSL before, so i just try and see the error is. | Silly me :-) | | I tried to put the statement in the main block, but then an error message | displayed "undefined reference to 'OpenSSL_add_all_algorithm" and "undefined | reference to 'SSL_load_error_strings' | | Is there any linkage i forgot to put? Anyway, thanks for the reply. OpenSSL_add_all_algorithms() needs libcrypto, SSL_load_error_strings() needs libssl, which needs libcrypto. So at least with gcc the link line should contain -lssl -lcrypto And please, this thread belongs into openssl-users... Goetz - -- DMCA: The greed of the few outweighs the freedom of the many -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKeFVZ2iGqZUF3qPYRAmjoAJ9FCs+fiKMEAsQ3UgK5KHxOiNaJCQCdGF4B owqzzG/2ePO9aegThFYaC+U= =18Ok -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: RAND_screen() thread safety and RAND_poll() initialization
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tanguy Fautré wrote: | Hi, | | Using OpenSSL 0.9.8j via LibCurl 7.19.5, we've discovered some random crashes and deadlocks that, | after further investigations, led us to a call to RAND_screen() from LibCurl. | | Two things puzzles me about the implementation of RAND_screen(), | hinting that it could maybe be a thread safety issue. | Hopefully, someone around here can enlighten me on the situation. | | 1. RAND_screen() is not protected by locks. | 2. RAND_screen() does not check whether RAND_poll() was already called before. | | This seems to go against what most functions in OpenSSL do. | One of the best example is ssleay_rand_status() located in crypto/rand/md_rand.c. | This function protects the call to RAND_poll() by locks and ensures RAND_poll() is called once and only once. RAND_screen() is part of the OpenSSL initialization code. All these functions are to be called just once at startup and MUST NOT be called in a situation where they could be called from several threads. Doing that is considered a illegal use of the OpenSSL library and the usual help you get here is a "fix your initialization code". Bye Goetz - -- DMCA: The greed of the few outweighs the freedom of the many -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKaNDj2iGqZUF3qPYRAuzwAJ9hqukHaiA8YH6jqp58P0zXrN33sgCff24F q/Jug4R4c/W45/V8S+7doi8= =SFmo -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [CVS] OpenSSL: openssl/ README openssl/crypto/ opensslv.h
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dr. Stephen Henson wrote: Hello Steve, did you see some pigs flying around your house ? ;-) | Log: | Nothing to see here... move along Goetz - -- DMCA: The greed of the few outweighs the freedom of the many -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJz59E2iGqZUF3qPYRAsPHAJ4wyGsd17Q1XEShimq9/Elt0Vyv9wCdHgGo MI7o6B0ADnJiuqcbfyy+uBs= =sY9L -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: valgrind and openssl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik de Castro Lopo schrieb: | Theodore Tso wrote: | |> On Thu, May 15, 2008 at 11:09:46AM -0500, John Parker wrote: |>> What I was hoping for was a -DNO_UNINIT_DATA that wouldn't be the |>> default, but wouldn't reduce the keyspace either. |> -DPURIFY *does* do what you want. | | But thats a compile time option. I would prefer not to have to compile | my own version of OpenSSL just to be able to valgrind my program which | links against openssl. Then configure your valgrind to ignore this uninitialized use of data. Normally usage of uninitialized data is an oversight done by the programmer that may cause unintended consequences. Because of that valgrind complains about them. But here the use of this uninitialized data is intentional and the programmer are very well aware of what they did. Perhaps it would be a good idea to add a README.valgrind containing a description of what happens and how to configure valgrind to ignore the uninitialized reads ? (Perhaps people that won't read the FAQ will read that) Goetz - -- DMCA: The greed of the few outweighs the freedom of the many -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFILKt52iGqZUF3qPYRAtkIAJ47deAtIXtN0DKJGN61CtZyimI3jACfUPDJ ddRbnQn5NF5h0Y6P6pLUHP4= =8wkC -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: 117 Character Limit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Sierchio wrote: | Goetz Babin-Ebell wrote: | |> RSA has some weaknesses against chosen plain text attacks. | | Anyway, why would someone use RSA for encryption? ;-) ... because they don't know what they are doing ? ;-) (that's what my mail was about: ~ You _can_ use RSA for encryption, but you really have ~ to know what you are doing. ~ And if you have to ask why RSA only supports encryption ~ to a given length, you don't.) Goetz - -- DMCA: The greed of the few outweights the freedom of the many -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH6/Kp2iGqZUF3qPYRAlnRAJ4xDWh2J/jPZ8H+/TX4Rw48lafUAwCfX3gF a1VcJYh9Y+hTW5WHzaeS6Qg= =8ps5 -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: 117 Character Limit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Sierchio wrote: | robert2007 wrote: |> I noticed that using RSA with OpenSSL places a 117 character limit when |> encrypting messages. Would anyone happen to know the reason for this? | | 1) It doesn't | | 2) Do you mean with a 1024-bit modulus the encryption block size | is 936? Because of padding. Additionally it is an feature to keep people from unintentionally doing something that may lead to key compromise: RSA has some weaknesses against chosen plain text attacks. If you don't know why this limit exist, you usually don't want to use RSA directly (or shouldn't want to). Instead you want to use RSA in combination with symmetric ciphers (with the EVP interface). Bye Goetz - -- DMCA: The greed of the few outweights the freedom of the many -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH6t7S2iGqZUF3qPYRAo0RAJ4wVxFKABkVRlOTXRZiRbrFqh0XSwCcDkmL IT2WMDKkEzoavhx13hvvOPc= =WwVd -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Patch: save/load state of SHA1 - v2
--On Jun 12, 2007 18:28:49 +0200 Nanno Langstraat <[EMAIL PROTECTED]> wrote:
v2 of the SHA save patch.
Is there a special reason to limit it to SHA ?
Why not a EVP_MD_CTX_{load|save} ?
Goetz
--
DMCA: The greed of the few outweights the freedom of the many
pgpFVb5vOyptj.pgp
Description: PGP signature
Re: Format of X509 Certificate Validity
--On May 22, 2007 16:01:41 -0700 Richard Kao <[EMAIL PROTECTED]> wrote: Hope someone can help me understand the validity date and time format of x509. For example, when connecting to https://401k.fidelity.com/, my IE shows it's cert validity is Valid from: August 30, 2006 5:00:00 PM Valid to:August 31, 2007 4:59:59 PM Ethereal shows the same fields of the x509 cert as: decoded notBefore: 0 6 0 8 3 1 0 0 0 0 0 0 Z (hex: 30 36 30 38 33 31 30 30 30 30 30 30 5A) decoded notAfter:0 7 0 8 3 1 2 3 5 9 5 9 Z (hex: 30 37 30 38 33 31 32 33 35 39 35 39 5A) It's staightfoward that 0 6 0 8 3 match 2006 08 3*, 0 7 0 8 3 match 2007 08 3*; 0 0 0 0 Z match 00:00, 5 9 5 9 Z match 59:59, but I found it's a bit confusing to decode the middle digits of notBefore and notAfter. The format of universalTime (time format for certificate times before 2050) is YYMMDDHHMMSS followed by the time zone (Z means Zulu time (GMT)) IE translates that into the your local time. Bye Goetz -- DMCA: The greed of the few outweights the freedom of the many pgpan7AcUSGnr.pgp Description: PGP signature
Re: [CVS] OpenSSL: openssl/crypto/rand/ rand_lib.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Lutz,
why not...
Lutz Jaenicke wrote:
> patch -p0 <<'@@ .'
> Index: openssl/crypto/rand/rand_lib.c
>
> $ cvs diff -u -r1.16 -r1.17 rand_lib.c
> --- openssl/crypto/rand/rand_lib.c 30 Jan 2003 17:39:23 - 1.16
> +++ openssl/crypto/rand/rand_lib.c 2 Mar 2007 17:54:51 - 1.17
> @@ -154,6 +154,7 @@
>int RAND_bytes(unsigned char *buf, int num)
> {
> const RAND_METHOD *meth = RAND_get_rand_method();
> if (meth && meth->bytes)
> return meth->bytes(buf,num);
+ memset(buf, 0, num);
> return(-1);
> @@ -162,6 +163,7 @@
>int RAND_pseudo_bytes(unsigned char *buf, int num)
> {
> const RAND_METHOD *meth = RAND_get_rand_method();
> if (meth && meth->pseudorand)
> return meth->pseudorand(buf,num);
+ memset(buf, 0, num);
> return(-1);
This way memset() will only be called in error case.
In the normal case the (not needed) memset will
not waste processor cycles...
This is a workaround for people that use debuging tools
that generate results they can't understand.
Bye
Goetz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFF6IG82iGqZUF3qPYRAsxeAKCD8YmCuSeZtWafatkPzTucLfeJEACfQZks
IYF84gloJki7bH4uYidlbrs=
=P0Kp
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: STARTTLS patch for imap and ftp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Lutz, Lutz Jaenicke wrote: > Goetz Babin-Ebell wrote: >> Lutz Jaenicke wrote: >> [...] >> Do you want something like the attached patch ? >> (untested, I'm off to bed...) > Ok, I have reworked this section as discussed by using a buffering BIO and > have committed everything to CVS. I would be most pleased if somebody would > also cross-test it (the part with the multi-line IMAP response may require > some more digging as the termination should be the "." at the beginning > of the response line, not the number of chars being less than 3!?) Testet against cyrus imapd 2.1.18 and exim 4.50: OK. You may drop the test for mbuf_len>3 in the while() for the IMAP ". CAPABILITY" response. Has anyone seen a SMTP server return more than one line in the SMTP opening message ? Bye Goetz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFF3twx2iGqZUF3qPYRAscBAJ9/JrYHEqPOcLfgDShP8onKeRLYFgCffg7+ YqGeshjiakpwo4f9gDtPJa0= =HzVN -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: STARTTLS patch for imap and ftp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lutz Jaenicke wrote:
> Goetz Babin-Ebell wrote:
[...]
>> * in SMTP doing a STARTTLS without previous EHLO
>> will return a
>> 503 STARTTLS command used when not advertised
>> * in IMAP doing a STARTLS requires a
>> . CAPABILITY
>> first.
>>
>> In both cases the server response should be parsed for
>> the string "STARTTLS"...
>>
> This statement is technically correct. As the s_client tool is however
> intended for testing purposes only (you remember that a capital
> "R" at the beginning of the line will start a renegotiation instead
> of being transferred to the server :-) adding the EHLO and .CAPABILITY
> should be sufficient and the more complex parsing of the response
> might be omitted...
Do you want something like the attached patch ?
(untested, I'm off to bed...)
Bye
Goetz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFF2lTq2iGqZUF3qPYRAirhAJ9+e7H1qRzUH7RZAuHKBGpqUDrVfwCfb2A2
B7Z713+mhzGcIx5/VZHtBNA=
=ABXa
-END PGP SIGNATURE-
Index: apps/s_client.c
===
RCS file: /home/gbe/data/cvs/openssl/openssl/apps/s_client.c,v
retrieving revision 1.100
diff -u -r1.100 s_client.c
--- apps/s_client.c 18 Feb 2007 18:21:57 - 1.100
+++ apps/s_client.c 20 Feb 2007 01:47:50 -
@@ -914,12 +914,27 @@
/* This is an ugly hack that does a lot of assumptions */
if (starttls_proto == PROTO_SMTP)
{
+ int foundit=0;
/* wait for multi-line response to end from SMTP */
do
{
mbuf_len = BIO_read(sbio,mbuf,BUFSIZZ);
}
while (mbuf_len>3 && mbuf[3]=='-');
+ /* STARTTLS command requires EHLO... */
+ BIO_printf(sbio,"EHLO openssl.client.net\r\n");
+ /* wait for multi-line response to end EHLO SMTP response */
+ do
+ {
+ mbuf_len = BIO_read(sbio,mbuf,BUFSIZZ);
+ if (strstr(mbuf,"STARTTLS"))
+foundit=1;
+ }
+ while (mbuf_len>3 && mbuf[3]=='-');
+ if (!foundit)
+ BIO_printf(bio_err,
+ "didn't found starttls in server response,"
+ " try anyway...\n");
BIO_printf(sbio,"STARTTLS\r\n");
BIO_read(sbio,sbuf,BUFSIZZ);
}
@@ -931,8 +946,23 @@
}
else if (starttls_proto == PROTO_IMAP)
{
+ int foundit=0;
BIO_read(sbio,mbuf,BUFSIZZ);
- BIO_printf(sbio,"0 STARTTLS\r\n");
+ /* STARTTLS command requires CAPABILITY... */
+ BIO_printf(sbio,". CAPABILITY\r\n");
+ /* wait for multi-line CAPABILITY response */
+ do
+ {
+ mbuf_len = BIO_read(sbio,mbuf,BUFSIZZ);
+ if (strstr(mbuf,"STARTTLS"))
+foundit=1;
+ }
+ while (mbuf_len>3);
+ if (!foundit)
+ BIO_printf(bio_err,
+ "didn't found STARTTLS in server response,"
+ " try anyway...\n");
+ BIO_printf(sbio,". STARTTLS\r\n");
BIO_read(sbio,sbuf,BUFSIZZ);
}
else if (starttls_proto == PROTO_FTP)
Re: STARTTLS patch for imap and ftp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Richard, Richard Levitte - VMS Whacker wrote: > In message <[EMAIL PROTECTED]> on Thu, 15 Feb 2007 10:34:23 -0800, > Kees Cook <[EMAIL PROTECTED]> said: > > kees> 3 years ago, I wrote a patch[1] (and did the TSU[2]) for adding > kees> these features to s_client. Can this please be applied to CVS? > > Yes. Done. Thank you, and sorry you had to wait 3 years for this to > happen. The problem (not only I have) with the patch is that at least in SMTP and IMAP it is illegal to start TLS before an initial protocol handshake is done: * in SMTP doing a STARTTLS without previous EHLO will return a 503 STARTTLS command used when not advertised * in IMAP doing a STARTLS requires a . CAPABILITY first. In both cases the server response should be parsed for the string "STARTTLS"... Bye Goetz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFF1xsY2iGqZUF3qPYRAreLAJ9MF6ht6pP2nnzx5pL5x7kTwuOsuACeLyZb QAA8Z0W0Wd6biFEb0K4D0SA= =72Vc -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #980] "-starttls smtp" not standard compliant and leads to misleading "unknown protocol" error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kurt Roeckx wrote: > On Sat, Dec 16, 2006 at 08:03:43PM +0100, Goetz Babin-Ebell wrote: >> -BEGIN PGP SIGNED MESSAGE- >> via RT wrote: >>> [EMAIL PROTECTED] ~]$ openssl s_client -connect mail.buu.ch:25 >>> -starttls smtp -debug >> [...] >> >> I have a patch for s_client which allows arbitrary (textual) handshake >> before the TLS handshake starts... > > The SMTP protocol requies you to send the EHLO command before you > send STARTTLS. I'm aware of that. My patch was originally to do some tests on an IMAP server. But it is an generalized approach allowing you to do any textual handshake before you setup TLS. > See http://www.mail-archive.com/openssl-dev@openssl.org/msg20600.html > for a patch that adds an -ehlo option. > > (It also has some discussion of you about a more generalized way of > doing it.) Oups... Yes it has. Time flies like an arrow... My idea from last year still is good, but my patch is a first step do it... > Anyway, s_client's -starttls currently takes 2 protocols as argument, > smpt or pop3. I think it should just properly implement those > protocols. For SMTP that would mean sending the EHLO before STARTTLS. Fixing the SMTP case would be good, but allowing arbitrary textual handshake before TLS starts wides the area of possible uses... Bye Goetz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFhaWF2iGqZUF3qPYRAkDIAJ0YwH65A2oDzVE/Y5rKeqfDVvYgKwCfS2c3 rw4FQTcc2+9aCP59fZIFeRY= =ewY4 -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #980] "-starttls smtp" not standard compliant and leads to misleading "unknown protocol" error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Ralf, via RT wrote: > [EMAIL PROTECTED] ~]$ openssl s_client -connect mail.buu.ch:25 > -starttls smtp -debug [...] I have a patch for s_client which allows arbitrary (textual) handshake before the TLS handshake starts... If somebody is interested in it... Bye Goetz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFhEMP2iGqZUF3qPYRAvYlAJ9yKvdEJBr52Y11s3ZG/7rxzDL1wwCfX36A 97TZoL/cD29X2If9MaANZjg= =Z9F1 -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: openssl/apps/ dgst.c enc.c s_client.c s_server.c openss...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nils Larsch schrieb: > Moin Goetz, Moin Nils, > Goetz Babin-Ebell wrote: > .. >>> Index: openssl/crypto/bio/bio.h >>> >>> >>> >>> $ cvs diff -u -r1.69 -r1.70 bio.h >>> --- openssl/crypto/bio/bio.h18 Dec 2005 19:11:36 -1.69 >>> +++ openssl/crypto/bio/bio.h29 Nov 2006 20:54:55 -1.70 >> [...] >>> @@ -246,14 +250,14 @@ >>>#define BIO_cb_pre(a)(!((a)&BIO_CB_RETURN)) >>>#define BIO_cb_post(a)((a)&BIO_CB_RETURN) >>> -#define BIO_set_callback(b,cb)((b)->callback=(cb)) >>> -#define BIO_set_callback_arg(b,arg)((b)->cb_arg=(char *)(arg)) >>> -#define BIO_get_callback_arg(b)((b)->cb_arg) >>> -#define BIO_get_callback(b)((b)->callback) >>> -#define BIO_method_name(b)((b)->method->name) >>> -#define BIO_method_type(b)((b)->method->type) >>> +long (*BIO_get_callback(const BIO *b)) (struct bio_st *,int,const >>> char *,int, long,long); >>> +void BIO_set_callback(BIO *b, +long (*callback)(struct >>> bio_st *,int,const char *,int, long,long)); >> >>> +char *BIO_get_callback_arg(const BIO *b); >> ^^ >>> +void BIO_set_callback_arg(BIO *b, char *arg); >>^ >> I think these should be void * > > I agree that a void pointer would be more appropriate here but IMHO > the type used to set a value should be the same type used in the > structure which is currently a char pointer (which is the same type > as the second parameter of the bio callback ...). Since a void* is better than a char*, we also should change the type in the structure and the callback. It is not the first instance in the library where a char* is used in a place a void* is more appropriately... At least the head is supposed to break compatibility if that improves the general usability... Bye Goetz - -- DMCA: The greed of the few outweighs the freedom of the many -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFbpci2iGqZUF3qPYRAiiaAJ4vJ5PTQtw3RxwVHhwC0Heudg+yfwCbBv0X Dc96qTtTsLE9tUKgjUiXan0= =v43k -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: openssl/apps/ dgst.c enc.c s_client.c s_server.c openss...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nils Larsch schrieb: Hello Nils, > Server: cvs.openssl.org Name: Nils Larsch > Root: /v/openssl/cvs Email: [EMAIL PROTECTED] > Module: openssl Date: 29-Nov-2006 21:54:57 > Branch: HEAD Handle: 2006112920545403 [...] > Log: > replace macros with functions [...] > Index: openssl/crypto/bio/bio.h > > $ cvs diff -u -r1.69 -r1.70 bio.h > --- openssl/crypto/bio/bio.h18 Dec 2005 19:11:36 - 1.69 > +++ openssl/crypto/bio/bio.h29 Nov 2006 20:54:55 - 1.70 [...] > @@ -246,14 +250,14 @@ >#define BIO_cb_pre(a) (!((a)&BIO_CB_RETURN)) >#define BIO_cb_post(a) ((a)&BIO_CB_RETURN) > > -#define BIO_set_callback(b,cb) ((b)->callback=(cb)) > -#define BIO_set_callback_arg(b,arg)((b)->cb_arg=(char *)(arg)) > -#define BIO_get_callback_arg(b)((b)->cb_arg) > -#define BIO_get_callback(b)((b)->callback) > -#define BIO_method_name(b) ((b)->method->name) > -#define BIO_method_type(b) ((b)->method->type) > +long (*BIO_get_callback(const BIO *b)) (struct bio_st *,int,const char > *,int, long,long); > +void BIO_set_callback(BIO *b, > + long (*callback)(struct bio_st *,int,const char *,int, long,long)); > +char *BIO_get_callback_arg(const BIO *b); ^^ > +void BIO_set_callback_arg(BIO *b, char *arg); ^ I think these should be void * Bye Goetz - -- DMCA: The greed of the few outweighs the freedom of the many -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFbf+72iGqZUF3qPYRApLUAJ9c9RuBveWXOrk4ygLxr5aIlA9HiACfRAL3 rFTOzYLrAiY6gmdvGPoSkTE= =smfm -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: problems with 098b's "DSO support routines", the "gmp"engine, & a TLS implementation in cyrus -- related?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard schrieb: > hi all, Hello Richard, > i'm thinking this needs "big brain" attention on the dev list ... No. It doesn't > i've 0.9.8b built from src on OSX 10.4.7. > > when i test the server's install with: > > % openssl s_client -connect mail.testdomain.com:993 -showcerts > > i get: > > 16458:error:25066067:DSO support routines:DLFCN_LOAD:could not load the > shared library:dso_dlfcn.c:162:filename(libz.so): dlopen(libz.so, 2): ^^^ openssl wants to load libz.so, but can't find it... > image not found > 16458:error:25070067:DSO support routines:DSO_load:could not load the > shared library:dso_lib.c:244: > CONNECTED(0003) > ... Bye Goetz - -- DMCA: The greed of the few outweighs the freedom of the many -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE2lrg2iGqZUF3qPYRApdYAJwLxiIkdMeT8CXsGO0daCBR2cfFbgCfZD5u Ad+3Cao5LICGXwEUjiQBUZA= =q0Vo -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: openssl/ CHANGES openssl/crypto/asn1/ x_crl.c x_x509.c ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dr. Stephen Henson schrieb: > patch -p0 <<'@@ .' > Index: openssl/CHANGES > > $ cvs diff -u -r1.1342 -r1.1343 CHANGES > --- openssl/CHANGES 18 Jul 2006 12:36:17 - 1.1342 > +++ openssl/CHANGES 24 Jul 2006 12:39:20 - 1.1343 > @@ -4,6 +4,12 @@ > > Changes between 0.9.8b and 0.9.9 [xx XXX ] > > + *) New function X509_CRL_match() to check if two CRLs are identical. > Normally > + this would be called X509_CRL_cmp() but that name is already used by > + a function that just compares CRL issuer names. Cache several CRL > + extensions in X509_CRL structure and cache CRLDP in X509. > + [Steve Henson] Wouldn't it be adviseable to rename the old X509_CRL_cmp() to something like X509_CRL_cmp_issuer(), define a macro for the old name and flag it as deprecated ? After some grace time the old macro is removed and after some other grace time the X509_CRL_match() becomes X509_CRL_cmp() ? Bye Goetz - -- DMCA: The greed of the few outweighs the freedom of the many -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFExRPB2iGqZUF3qPYRAraEAJ4/vg0NxJd9umLLWSCUkLN9CEIswgCeOH51 fUAstjCsgATTRx5pERQyPs4= =cMM/ -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] `s_client -starttls smtp' fails if not using EHLO
Pavel Gorshkov wrote: On Sat, Dec 31, 2005 at 04:26:46PM +0100, Goetz Babin-Ebell wrote: This patch solves only smtp. But there are many more protocols using STARTTLS Has anybody thought about a plugin interface or a different way to handle the startup ? I agree that it would be better to have a generalized approach. Here's a relevant excerpt from gnutls-cli(1): -s, --starttls Connect, establish a plain session and start TLS when EOF or a SIGALRM is received. Seems usable. But what if you want to use s_client with -starttls in a script ? this looks like a perfect solution except maybe when dealing with a tricky binary protocol requiring you to perform multiple authentication steps before a . For these cases (and others) my -startcmd is the best way. but normally starttls is used in sane (clear text) protocols... (sorry for mentioning gnutls on this list) It's OK, you didn't say "Jehovah" (which would lead to your stoning... ;-) ) By the way: Hapy new year...) Bye Goetz -- DMCA: The greed of the few outweighs the freedom of the many smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH] `s_client -starttls smtp' fails if not using EHLO
Pavel Gorshkov wrote: Some SMTP servers require a HELO/EHLO command before a STARTTLS, e.g.: [...] The attached patch (against openssl-0.9.8a) adds the `-ehlo' option to s_client: -ehlo hostname - use the EHLO smtp command before issuing STARTTLS (to be used in conjunction with -starttls smtp) with this patch, s_client successfully connects and shows the certificate: This patch solves only smtp. But there are many more protocols using STARTTLS Has anybody thought about a plugin interface or a different way to handle the startup ? Either a -manualstart command that opens the socket, forwards stdin to the socket and data from the socket to stdout, and starts TLS after it receives the given starttext from stdin. Or the -startcmd command, that calls the specified command to do the initial handshake (and starts TLS if the command returns without error... Bye Goetz -- DMCA: The greed of the few outweighs the freedom of the many smime.p7s Description: S/MIME Cryptographic Signature
apps/s_client.c: 2 changes in initial handshake
Hallo,
this patch has 2 changes for s_client:
* It adds the command line param -Verify to terminate the
ssl handshake if peer verify fails.
* It adds the additional flag "manual" to the param -starttls,
giving the complete initial handshake in user hands,
For example exim4 needs at least the EHLO command
before it accepts the STARTTLS command.
It would be good if anybody would have a look into this patch
and would apply it to the head...
Bye
Goetz
--
DMCA: The greed of the few outweighs the freedom of the many
Index: s_cb.c
===
RCS file: /home/gbe/data/cvs/openssl/openssl/apps/s_cb.c,v
retrieving revision 1.17
diff -u -r1.17 s_cb.c
--- s_cb.c 5 Apr 2005 19:11:18 - 1.17
+++ s_cb.c 13 Jun 2005 20:24:02 -
@@ -136,15 +136,19 @@
X509_NAME_oneline(X509_get_subject_name(err_cert),buf,sizeof buf);
BIO_printf(bio_err,"depth=%d %s\n",depth,buf);
+ verify_error=err;
if (!ok)
{
BIO_printf(bio_err,"verify error:num=%d:%s\n",err,
X509_verify_cert_error_string(err));
if (verify_depth >= depth)
{
- ok=1;
- verify_error=X509_V_OK;
- }
+ if (depth > 0)
+ {
+ok=1;
+verify_error=X509_V_OK;
+ }
+}
else
{
ok=0;
Index: s_client.c
===
RCS file: /home/gbe/data/cvs/openssl/openssl/apps/s_client.c,v
retrieving revision 1.81
diff -u -r1.81 s_client.c
--- s_client.c 4 Nov 2005 09:30:54 - 1.81
+++ s_client.c 10 Nov 2005 22:27:54 -
@@ -167,6 +167,7 @@
static void sc_usage(void);
static void print_stuff(BIO *berr,SSL *con,int full);
+static int do_pressl(BIO *sbio, int starttls_proto);
static BIO *bio_c_out=NULL;
static int c_quiet=0;
static int c_ign_eof=0;
@@ -180,6 +181,7 @@
BIO_printf(bio_err," -connect host:port - who to connect to (default is %s:%s)\n",SSL_HOST_NAME,PORT_STR);
BIO_printf(bio_err," -verify arg - turn on peer certificate verification\n");
+ BIO_printf(bio_err," -Verify arg - turn on mandatory peer certificate verification\n");
BIO_printf(bio_err," -cert arg - certificate file to use, PEM format assumed\n");
BIO_printf(bio_err," -certform arg - certificate format (PEM or DER) PEM default\n");
BIO_printf(bio_err," -key arg - Private key file to use, in cert file if\n");
@@ -217,7 +219,7 @@
BIO_printf(bio_err," -starttls prot - use the STARTTLS command before starting TLS\n");
BIO_printf(bio_err," for those protocols that support it, where\n");
BIO_printf(bio_err," 'prot' defines which one to assume. Currently,\n");
- BIO_printf(bio_err," only \"smtp\" and \"pop3\" are supported.\n");
+ BIO_printf(bio_err," only \"smtp\", \"pop3\" and \"manual\" are supported.\n");
#ifndef OPENSSL_NO_ENGINE
BIO_printf(bio_err," -engine id- Initialise and use the specified engine\n");
#endif
@@ -337,6 +339,13 @@
verify_depth=atoi(*(++argv));
BIO_printf(bio_err,"verify depth is %d\n",verify_depth);
}
+ else if (strcmp(*argv,"-Verify") == 0)
+ {
+ verify=SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT;
+ if (--argc < 1) goto bad;
+ verify_depth=atoi(*(++argv));
+ BIO_printf(bio_err,"verify depth is %d (mandatory)\n",verify_depth);
+ }
else if (strcmp(*argv,"-cert") == 0)
{
if (--argc < 1) goto bad;
@@ -462,6 +471,8 @@
starttls_proto = 1;
else if (strcmp(*argv,"pop3") == 0)
starttls_proto = 2;
+ else if (strcmp(*argv,"manual") == 0)
+starttls_proto = 3;
else
goto bad;
}
@@ -712,17 +723,13 @@
sbuf_off=0;
/* This is an ugly hack that does a lot of assumptions */
- if (starttls_proto == 1)
- {
- BIO_read(sbio,mbuf,BUFSIZZ);
- BIO_printf(sbio,"STARTTLS\r\n");
- BIO_read(sbio,sbuf,BUFSIZZ);
- }
- if (starttls_proto == 2)
+ if (starttls_proto > 0)
{
- BIO_read(sbio,mbuf,BUFSIZZ);
- BIO_printf(sbio,"STLS\r\n");
- BIO_read(sbio,sbuf,BUFSIZZ);
+ if (!do_pressl(sbio, starttls_proto))
+ {
+ SHUTDOWN(SSL_get_fd(con));
+ goto end;
+ }
}
for (;;)
@@ -1210,3 +1217,52 @@
BIO_flush(bio);
}
+static int do_pressl(BIO *sbio, int starttls_proto)
+ {
+ char buf[BUFSIZZ+1];
+
+ switch(starttls_proto)
+ {
+ case 1:
+ BIO_read(sbio,buf,BUFSIZZ);
+ BIO_printf(sbio,"STARTTLS\r\n");
+ BIO_read(sbio,buf,BUFSIZZ);
+ return 1;
+ case 2:
+ BIO_read(sbio,buf,BUFSIZZ);
+ BIO_printf(sbio,"STLS\r\n");
+ BIO_read(sbio,buf,BUFSIZZ);
+ return 1;
+ case 3:
+ {
+ int i;
+ printf("please input data (input \"__STARTTLS__\" in single line to start tls)\n");
+ while(1)
+{
+i = BIO_read(sbio,buf,BUFSIZZ);
+if (i > 0)
+ {
+ buf[i] = 0x00;
+ printf("%s",buf);
+ i = raw_read_stdin(buf,BUFSIZZ/2);
+ if (i > 0)
+ {
+ while( i >= 0 &&
+ (buf[i-1] == '
Re: [openssl.org #1052]: New patch for subjectAltName
[EMAIL PROTECTED] via RT wrote: In the rt now is a new patch for openssl HEAD (of 20051108) that handles the subjectAltName generation. This patch allows users to set all types of generalNames from data provided in the DN of the request. Bye Goetz -- DMCA: The greed of the few outweighs the freedom of the many smime.p7s Description: S/MIME Cryptographic Signature
Re: openssl 0.9.8 - ssl tests fails still report says tests passed ...
Dharmesh Vyas wrote: Hello Group... Hello Dharmesh Vyas, (1) If I run the tests and perform 'make report', the output generated shows 'Test passed.' But from the log file i found that in the section [...] and there are a few of this types which shows the same ERROR in CLIENT, Is this error fine?? Since as per what i have got from other users is that if any of the tests of openssl test fails it stops performing other tests and shows '[test] Error'. But all tests gets performed and the the report says that tests passed . So does that mean that my openssl is properly not installed or it means that some thing is wrong with the configuration of the tool. Without looking in the test cases myself: Especially in security environments tests aren't done without performing some test that must fail (expected fails),,, Bye Goetz -- DMCA: The greed of the few outweighs the freedom of the many smime.p7s Description: S/MIME Cryptographic Signature
Re: [ANNOUNCE] OpenSSL version 0.9.7i released
Richard Levitte - VMS Whacker wrote: OpenSSL version 0.9.7i released === OpenSSL 0.9.7h caused crashes when the shared libcrypto was upgraded. This release fixes that problem. For those who want or have to stay with the 0.9.7 series of OpenSSL instead of using the 0.9.8 series, we strongly recommend that you upgrade to OpenSSL 0.9.7h soon as possible. For a complete list of changes, please ^ Oups... ;-) Bye Goetz -- DMCA: The greed of the few outweighs the freedom of the many smime.p7s Description: S/MIME Cryptographic Signature
Re: d2i_[RD]SAPublicKey problem
[EMAIL PROTECTED] wrote: Hi, Hello Mike, The problem is that calling the d2i functions with a length of 0 somehow corrupted my TLS connection and I would get protocol errors that required shutting down the connection. Note that the RSA and DSA objects are in no way connect- ed to the TLS connection. I modified my code to only call the d2i functions when the length of the key is non-zero, and the protocol errors have gone away. Without looking in the code I would think the d2i_functions set an error code and the SSL connection stumbles about it the next time you do an SSL operation. Try an ERR_clear_error() after an failed decode and see if the SSL problem goes away... On the long term it could be good for the SSL structure to have an own error stack and stumble only about errors that are in it... But with that you would have to pass th pointer to this stack to every function that is called in the SSL protocol. So seems to be a bad idea... Bye Goetz -- DMCA: The greed of the few outweighs the freedom of the many smime.p7s Description: S/MIME Cryptographic Signature
Re: Missing documentation
Richard Levitte - VMS Whacker wrote: In message <[EMAIL PROTECTED]> on Wed, 29 Jun 2005 06:42:59 +0200, Karsten Ohme <[EMAIL PROTECTED]> said: widerstand> will there be some day, when the the OpenSSL source code widerstand> is documented in a some way? In all source files, widerstand> explanations to the functions, the parameters and comments widerstand> in the code what is done are missing. We're well aware the documentation is lacking. We are adding some all the time. I wish we had the possibility to do *only* that for a while, but that's not what reality looks like. In the Open Source spirit, there's nothing stopping you from helping out. I think before the call for source code documentation is done, the team should decide which format to use. I would suggest doxygen... Bye Goetz -- DMCA: The greed of the few outweighs the freedom of the many smime.p7s Description: S/MIME Cryptographic Signature
Re: [CVS] OpenSSL: openssl/ Configure TABLE
Nils Larsch wrote: Goetz Babin-Ebell wrote: (BTW: I still get an out of memory in bn_test if I build OpenSSL with efence on linux... :-( ) I thought the problem was in ectest ? It's on my todo list but it's not really trivial to resolve (well one could disable the ec mult pre-computation but that's not a real solution). Ough. ElectricFence Exiting: mprotect() failed: Cannot allocate memory make[1]: *** [test_ec] Fehler 255 Naturally the error is in test_ec... I think for today I've lost the right to complain about stupid users... ;-) Bye Goetz -- DMCA: The greed of the few outweighs the freedom of the many smime.p7s Description: S/MIME Cryptographic Signature
Re: [CVS] OpenSSL: openssl/ Configure TABLE
Nils Larsch wrote: Hello Nils, OpenSSL CVS Repository http://cvs.openssl.org/ Modified files: openssl Configure TABLE Log: replace the deprecated "-m486" gcc option with "-march=i486" PR: 1049 I did a test and the compiler warnings are gone. It seems you can close 1049... Bye Goetz (BTW: I still get an out of memory in bn_test if I build OpenSSL with efence on linux... :-( ) -- DMCA: The greed of the few outweighs the freedom of the many smime.p7s Description: S/MIME Cryptographic Signature
Re: [ANNOUNCE] OpenSSL 0.9.8 beta 4 released
Richard Levitte - VMS Whacker wrote: OpenSSL version 0.9.8 Beta 4 Would it be possible to remove the annoying compiler warning about the deprecated gcc option -m486 by replacing -m486 with the new -march=i486 in configure and TABLE ? (an possible patch is in TT#1049) Bye Goetz -- DMCA: The greed of the few outweighs the freedom of the many smime.p7s Description: S/MIME Cryptographic Signature
Re: [ANNOUNCE] OpenSSL 0.9.8 beta 1 released
Hello Nils, Nils Larsch wrote: Goetz Babin-Ebell wrote: Richard Levitte - VMS Whacker wrote: OpenSSL version 0.9.8 Beta 1 There is still an old bugfix about some potential memory leaks in crypto/pkcs7/pk7_smime.c that I sent last year. New version of patch attached... patch applied. TNX. By the way: doing make test with enabled debug (linux + efence) the test runs out of memory in test_ec. I've attached the last 50 lines of output. The complete nohup.out is > ls -l nohup.out -rw--- 1 gbe users 1224295295 2005-05-20 09:29 nohup.out So I'm sure you don't want it ;-) Bye Goetz -- DMCA: The greed of the few outweighs the freedom of the many OpenSSL self-test report: OpenSSL version: 0.9.9-dev Last change: ... Options: --prefix=/home/gbe/openssl no-gmp no-krb5 no-mdc2 no-rc5 no-shared no-zlib no-zlib-dynamic OS (uname): Linux hal 2.6.8-24.14-default #1 Tue Mar 29 09:27:43 UTC 2005 i686 athlon i386 GNU/Linux OS (config): i686-whatever-linux2 Target (default): linux-elf Target: debug-linux-elf Compiler: Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada --disable-checking --libdir=/usr/lib --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux Thread model: posix gcc version 3.3.4 (pre 3.3.5 20040809) Test skipped. Starting BN_CTX_start (41976fd4): : Ending BN_CTX_start (41976fd4): : ^^ Starting BN_CTX_get (41976fd4): : ^^ Starting BN_CTX_get (41976fd4): 24 : ^^ Starting BN_CTX_get (41976fd4): 24 24 : ^^ Starting BN_CTX_get (41976fd4): 24 24 28 : ^^ Starting BN_CTX_get (41976fd4): 24 24 28 12 : ^^ Starting BN_CTX_get (41976fd4): 24 24 28 12 24 : ^^ Starting BN_CTX_get (41976fd4): 24 24 28 12 24 24 : ^^ Starting BN_CTX_get (41976fd4): 24 24 28 12 24 24 24 : ^^ Starting BN_CTX_end (41976fd4): 24 24 28 12 24 24 24 1a : ^^ Ending BN_CTX_end (41976fd4): : .Starting BN_CTX_start (41976fd4): : Ending BN_CTX_start (41976fd4): : ^^ Starting BN_CTX_get (41976fd4): : ^^ ElectricFence Exiting: mprotect() failed: Cannot allocate memory make[1]: *** [test_ec] Fehler 255 make[1]: Leaving directory `/data/gbe/develop/openssl/test' make: *** [tests] Fehler 2 smime.p7s Description: S/MIME Cryptographic Signature
Re: [ANNOUNCE] OpenSSL 0.9.8 beta 1 released
Richard Levitte - VMS Whacker wrote:
OpenSSL version 0.9.8 Beta 1
There is still an old bugfix about some potential memory leaks
in crypto/pkcs7/pk7_smime.c that I sent last year.
New version of patch attached...
Bye
Goetz
--
DMCA: The greed of the few outweighs the freedom of the many
Index: crypto/pkcs7/pk7_smime.c
===
RCS file: /cvs/openssl/openssl/crypto/pkcs7/pk7_smime.c,v
retrieving revision 1.24
diff -u -r1.24 pk7_smime.c
--- crypto/pkcs7/pk7_smime.c 17 May 2005 05:52:24 - 1.24
+++ crypto/pkcs7/pk7_smime.c 19 May 2005 21:10:39 -
@@ -88,6 +88,7 @@
if (!(si = PKCS7_add_signature(p7,signcert,pkey,EVP_sha1( {
PKCS7err(PKCS7_F_PKCS7_SIGN,PKCS7_R_PKCS7_ADD_SIGNATURE_ERROR);
+ PKCS7_free(p7);
return NULL;
}
@@ -105,6 +106,7 @@
{
if(!(smcap = sk_X509_ALGOR_new_null())) {
PKCS7err(PKCS7_F_PKCS7_SIGN,ERR_R_MALLOC_FAILURE);
+ PKCS7_free(p7);
return NULL;
}
#ifndef OPENSSL_NO_DES
@@ -130,6 +132,7 @@
if (!(p7bio = PKCS7_dataInit(p7, NULL))) {
PKCS7err(PKCS7_F_PKCS7_SIGN,ERR_R_MALLOC_FAILURE);
+ PKCS7_free(p7);
return NULL;
}
@@ -139,10 +142,12 @@
if (!PKCS7_dataFinal(p7,p7bio)) {
PKCS7err(PKCS7_F_PKCS7_SIGN,PKCS7_R_PKCS7_DATASIGN);
+ PKCS7_free(p7);
+ BIO_free_all(p7bio);
return NULL;
}
-BIO_free_all(p7bio);
+ BIO_free_all(p7bio);
return p7;
}
smime.p7s
Description: S/MIME Cryptographic Signature
Re: SSL per session memory usage
Prashant Kumar wrote: Hello Group, Hello Prashant, The workaround of freeing s3->rbuf and s3->wbuf after the handshake is complete and after SSL_read, SSL_write, SSL_shutdown and so on returns success really seems to work. I have tested it running openssl as a SSL client and as a server. Taking a closer look at the code it looks like these buffers just act as a scratch buffers. With this change I could reduce the memory usage per SSL session significantly. I just want to make sure that this does not cause any other problem. Any advice from OpenSSL Guru's is really appreciated. I am not a OpenSSL Guru but I think you should test a Renogiation after You freed the buffers and see what happens... Bye Goetz -- DMCA: The greed of the few outweighs the freedom of the many smime.p7s Description: S/MIME Cryptographic Signature
openssl ca: generate subjectAltName from config
Hello,
is there a special reason that openssl ca has only
functionality to copy the emailAddress from the subject name
to the subjectAltName extension ?
Or would something like the attached patch acceptable ?
This patch extends the syntax of the subjectAltName entry
of the config file section with the extensions in the way
that the flags "copy" and "move" are recognized for all
names.
Additionally it allows to specify the name entry type
in the subject name that is moved/copied.
for example:
In my local openssl.cnf I have the entry:
subjectAltName = DNS:copy:commonName,DNS:mydyndnsorgdomain.dyndns.org
An issued certificate gets 2 subjectAltNames:
1. a copy of the common name (inserted as dnsDomain name)
2. the general dnsDomain name mydyndnsorgdomain.dyndns.org.
This allows me to access the host with the external and the internal
host name without the accessing program generating an error message
about a mismatching domain name.
Bye
Goetz
--
DMCA: The greed of the few outweighs the freedom of the many
Index: crypto/x509v3/v3_alt.c
===
RCS file: /cvs/openssl/crypto/x509v3/v3_alt.c,v
retrieving revision 1.33
diff -u -r1.33 v3_alt.c
--- crypto/x509v3/v3_alt.c 27 Dec 2003 14:40:01 - 1.33
+++ crypto/x509v3/v3_alt.c 22 Apr 2005 13:52:11 -
@@ -63,7 +63,9 @@
static GENERAL_NAMES *v2i_subject_alt(X509V3_EXT_METHOD *method, X509V3_CTX *ctx, STACK_OF(CONF_VALUE) *nval);
static GENERAL_NAMES *v2i_issuer_alt(X509V3_EXT_METHOD *method, X509V3_CTX *ctx, STACK_OF(CONF_VALUE) *nval);
-static int copy_email(X509V3_CTX *ctx, GENERAL_NAMES *gens, int move_p);
+static int copy_name(X509V3_EXT_METHOD *method, X509V3_CTX *ctx,
+ GENERAL_NAMES *gens,
+ const char *type, const char *field, int move_p);
static int copy_issuer(X509V3_CTX *ctx, GENERAL_NAMES *gens);
static int do_othername(GENERAL_NAME *gen, char *value, X509V3_CTX *ctx);
static int do_dirname(GENERAL_NAME *gen, char *value, X509V3_CTX *ctx);
@@ -304,6 +306,7 @@
{
GENERAL_NAMES *gens = NULL;
CONF_VALUE *cnf;
+ const char *value;
int i;
if(!(gens = sk_GENERAL_NAME_new_null())) {
X509V3err(X509V3_F_V2I_GENERAL_NAMES,ERR_R_MALLOC_FAILURE);
@@ -311,17 +314,23 @@
}
for(i = 0; i < sk_CONF_VALUE_num(nval); i++) {
cnf = sk_CONF_VALUE_value(nval, i);
- if(!name_cmp(cnf->name, "email") && cnf->value &&
- !strcmp(cnf->value, "copy")) {
- if(!copy_email(ctx, gens, 0)) goto err;
- } else if(!name_cmp(cnf->name, "email") && cnf->value &&
- !strcmp(cnf->value, "move")) {
- if(!copy_email(ctx, gens, 1)) goto err;
- } else {
- GENERAL_NAME *gen;
- if(!(gen = v2i_GENERAL_NAME(method, ctx, cnf)))
- goto err;
- sk_GENERAL_NAME_push(gens, gen);
+ if (cnf->value && cnf->value[0]) {
+ if (!name_cmp(cnf->value,"copy")) {
+value = cnf->value+4;
+if (value[0] == '.' || value[0] == ':')value++;
+if(!copy_name(method,ctx,gens,cnf->name,value,0))
+ goto err;
+ } else if (!name_cmp(cnf->value,"move")) {
+value = cnf->value+4;
+if (value[0] == '.') value++;
+if(!copy_name(method,ctx,gens,cnf->name,value,1))
+ goto err;
+ } else {
+GENERAL_NAME *gen;
+if(!(gen = v2i_GENERAL_NAME(method, ctx, cnf)))
+ goto err;
+sk_GENERAL_NAME_push(gens, gen);
+ }
}
}
return gens;
@@ -330,44 +339,76 @@
return NULL;
}
-/* Copy any email addresses in a certificate or request to
+/* Copy any fields of given type in a certificate or request to
* GENERAL_NAMES
*/
-static int copy_email(X509V3_CTX *ctx, GENERAL_NAMES *gens, int move_p)
+static int copy_name(X509V3_EXT_METHOD *method, X509V3_CTX *ctx,
+ GENERAL_NAMES *gens,
+ const char *type, const char *field, int move_p)
{
X509_NAME *nm;
- ASN1_IA5STRING *email = NULL;
X509_NAME_ENTRY *ne;
- GENERAL_NAME *gen = NULL;
+ CONF_VALUEcv = { NULL,(char*)type,NULL };
+ GENERAL_NAME *gen = NULL;
+ unsigned char*str = NULL;
+ int nid = 0;
+ int len;
int i;
if(ctx->flags == CTX_TEST) return 1;
- if(!ctx || (!ctx->subject_cert && !ctx->subject_req)) {
+if(!ctx || (!ctx->subject_cert && !ctx->subject_req)) {
X509V3err(X509V3_F_COPY_EMAIL,X509V3_R_NO_SUBJECT_DETAILS);
goto err;
}
- /* Find the subject name */
+/* get the type of name entry to operate on in the DN */
+ if (field && field[0]) {
+ nid = OBJ_txt2nid(field);
+ if (!nid) {
+ X509V3err(X509V3_F_COPY_EMAIL,X509V3_R_INVALID_EXTENSION_STRING);
+ goto err;
+ }
+ }
+ if (!nid) {
+ if (!name_cmp(type, "email")) nid = NID_pkcs9_emailAddress;
+#if 0
+ else if(!name_cmp(type, "URI" )) nid = NID_commonName;
+ else if(!name_cmp(name, "DNS" )) nid = NID_commonName;
+ else if(!name_cmp(name, "RID" )) nid = NID_commonName;
+ else if(!name_cmp(name, "IP" )) nid = NID_commonName;
+#endif
+ else nid = NID_commonName;
+ }
+if (!nid) {
+ X509V3err(X509V3_F_COPY_EMAIL,X509V3_R_INVALID_OBJECT_IDENTIFIER );
+ goto err;
+}
+/* Fi
Re: X509_verify_cert(): verify with time and CRL
Hello Steve, Dr. Stephen Henson wrote: On Wed, Sep 15, 2004, Goetz Babin-Ebell wrote: Dr. Stephen Henson wrote: On Tue, Sep 14, 2004, Goetz Babin-Ebell wrote: I still would propose the following logic: a) CRL is valid (regarding issuance time) if thisUpdate >= checkTime and thisUpdate <= now. b) CRL is considered to be able to deliver revocation information if thisUpdate <= notAfter from the certificate (because after that time the certificate might be removed from the CRL). That could certainly be added as a verify flag but I'm a bit wary of doing that by default. Would something like the attached patch be acceptable ? (please ignore versin info in the diff) This patch also adds checking of the revokation time against the checkTime I'm not sure about that last bit and timezones. Although RFC3280 et al prohibit CAs from using timezones its not clear whether an implementation has to process them correctly. Since the CA that issued the CRL is the same that issued the cert, would it be that wrong to assume that they would use the same time format in the CRL and the cert ? The only problem I see here is the one hour in spring and fall at the sumer time / winter time switch. Would it be acceptable to add the code with a big remark like "This needs a proper ASN1_TIME_cmp() because..." Bye Goetz -- Goetz Babin-Ebell, software designer, TC TrustCenter AG, Sonninstr. 24-28, 20097 Hamburg, Germany Office: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 www.trustcenter.de www.betrusted.com smime.p7s Description: S/MIME Cryptographic Signature
Re: PKCS7: sign data without keeping it in the memory
Hello Mathias, Mathias Brossard wrote: On Tue, 2004-10-05 at 17:44, Goetz Babin-Ebell wrote: PKCS7_sign() has the disadvantage that all signed data must be kept in memory. [...] /* we got the digest of the data, now create a PKCS#7 detached signed object... */ p7 = PKCS7_signHash(signer, key, other, pMD, caDigest, flags); I'm a little disappointed your solution only works for PKCS7_sign for detached signatures. It is a quickfix for a problem I had: sign some (potentially really big) data I don't know the length of at the moment I start the signing. I know BER allows that but then I would have to do all the BER encoding myself instead of using OpenSSL. I didn't want to go into that hell... Bye Goetz -- Goetz Babin-Ebell, software designer, TC TrustCenter AG, Sonninstr. 24-28, 20097 Hamburg, Germany Office: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 www.trustcenter.de www.betrusted.com smime.p7s Description: S/MIME Cryptographic Signature
[openssl.org #953] PKCS7: sign data without keeping it in the memory
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
PKCS7: sign data without keeping it in the memory
Hello folks,
I sent this mail in July but it was dropped (my email address changed...):
PKCS7_sign() has the disadvantage that all signed data must be
kept in memory.
My patch addes a PKCS7_signHash() that allows
cereating of a PKCS7 signed object just from the
digest of the data.
Intendet usage:
EVP_MD_CTXsCTX;
const EVP_MD *pMD = EVP_sha1(); /* or any other alg...) */
char caDigest[EVP_MAX_MD_SIZE];
int nDLen = EVP_MAX_MD_SIZE;
[...]
EVP_DigestInit(&sCTX,pMD);
while(data_available())
{
char caBuffer[buffsize];
int nBuffLen = FillBuffWithData(caBuffer,buffsize);
EVP_DigestUpdate(&sCTX,caBuffer,nBuffLen);
}
EVP_DigestFinal(&sCTX,caDigest,&nDLen);
/* we got the digest of the data,
now create a PKCS#7 detached signed object... */
p7 = PKCS7_signHash(signer, key, other, pMD, caDigest, flags);
Better would be a real PKCS7_signInit / _signUpdate / SignFinal,
but that requires more work...
Bye
Goetz
--
Goetz Babin-Ebell, software designer,
TC TrustCenter AG, Sonninstr. 24-28, 20097 Hamburg, Germany
Office: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
www.trustcenter.de www.betrusted.com
diff -ur openssl-SNAP-20040704/crypto/pkcs7/pk7_smime.c
openssl-SNAP-20040704_changed/crypto/pkcs7/pk7_smime.c
--- openssl-SNAP-20040704/crypto/pkcs7/pk7_smime.c 2004-03-28 00:00:14.0
+0100
+++ openssl-SNAP-20040704_changed/crypto/pkcs7/pk7_smime.c 2004-07-10
21:36:06.0 +0200
@@ -63,8 +63,148 @@
#include
#include
-PKCS7 *PKCS7_sign(X509 *signcert, EVP_PKEY *pkey, STACK_OF(X509) *certs,
- BIO *data, int flags)
+PKCS7 *PKCS7_signHash(X509 *signcert, EVP_PKEY *pkey, STACK_OF(X509) *certs,
+ const EVP_MD *pMD, const unsigned char *digest,
+ int flags)
+{
+ PKCS7 *p7;
+ ASN1_OCTET_STRING *os=NULL;
+
+ PKCS7_SIGNER_INFO *si;
+ STACK_OF(PKCS7_SIGNER_INFO) *si_sk=NULL;
+
+ EVP_MD_CTX ctx_tmp;
+
+ BUF_MEM *buf=NULL;
+ unsigned char *abuf=NULL;
+ unsigned int alen;
+ ASN1_OCTET_STRING *digeststr;
+
+ if (!pMD) return NULL;
+
+#ifndef OPENSSL_NO_DSA
+ if (pkey->type == EVP_PKEY_DSA && pMD != EVP_dss1()) {
+ if (pMD != EVP_sha1()) {
+ PKCS7err(PKCS7_F_PKCS7_DATASIGN,PKCS7_R_DIGEST_FAILURE);
+ return NULL;
+ }
+ pMD = EVP_dss1();
+ }
+#endif
+#ifndef OPENSSL_NO_ECDSA
+ if (pkey->type == EVP_PKEY_EC && pMD != EVP_ecdsa()) {
+ if (pMD != EVP_sha1()) {
+ PKCS7err(PKCS7_F_PKCS7_DATASIGN,PKCS7_R_DIGEST_FAILURE);
+ return NULL;
+ }
+ pMD = EVP_ecdsa();
+ }
+#endif
+
+ p7 = PKCS7_sign2(signcert, pkey, certs, pMD,
+NULL, flags | PKCS7_STREAM );
+ if (!p7) return NULL;
+
+ PKCS7_set_detached(p7, 1);
+ /* detached data -> the content is excluded */
+ os=p7->d.sign->contents->d.data;
+ M_ASN1_OCTET_STRING_free(os);
+ p7->d.sign->contents->d.data = NULL;
+
+ p7->state=PKCS7_S_HEADER;
+
+ si_sk=p7->d.sign->signer_info;
+ if (!si_sk || sk_PKCS7_SIGNER_INFO_num(si_sk) < 1)
+ {
+ PKCS7err(PKCS7_F_PKCS7_DATASIGN,PKCS7_R_NO_SIGNERS);
+ PKCS7_free(p7);
+ return NULL;
+ }
+ si=sk_PKCS7_SIGNER_INFO_value(si_sk,0);
+ if (!si || !si->pkey)
+ {
+ PKCS7err(PKCS7_F_PKCS7_DATASIGN,PKCS7_R_NO_SIGNERS);
+ PKCS7_free(p7);
+ return NULL;
+ }
+
+ p7->state=PKCS7_S_HEADER;
+
+ /* Add digest */
+ digeststr=M_ASN1_OCTET_STRING_new();
+ M_ASN1_OCTET_STRING_set(digeststr,digest, EVP_MD_size(pMD));
+ PKCS7_add_signed_attribute(si, NID_pkcs9_messageDigest,
+ V_ASN1_OCTET_STRING,digeststr);
+
+ /* Add signing time if not already present */
+ if (!PKCS7_get_signed_attribute(si, NID_pkcs9_signingTime))
+ {
+ ASN1_UTCTIME *sign_time=X509_gmtime_adj(NULL,0);
+ PKCS7_add_signed_attribute(si, NID_pkcs9_signingTime,
+ V_ASN1_UTCTIME,sign_time);
+ }
+
+ if ((buf=BUF_MEM_new()) == NULL)
+ {
+ PKCS7err(PKCS7_F_PKCS7_DATASIGN,ERR_R_BIO_LIB);
+ PKCS7_free(p7);
+ return NULL;
+ }
+ if (!BUF_MEM_grow_clean(buf,EVP_PKEY_size(pkey)))
+ {
+ PKCS7err(PKCS7_F_PKCS7_DATASIGN,ERR_R_BIO_LIB);
+ BUF_MEM_free(buf);
+ PKCS7_free(p7);
+ return NULL;
+ }
+
+ if (!si->auth_attr)
+ {
+ PKCS7err(PKCS7_F_PKCS7_DATASIGN,ERR_R_BIO_LIB);
+ BUF_MEM_free(buf);
+ PKCS7_free(p7);
+ return
Re: [PATCH] util/cygwin.sh: Install docs under /usr/share/doc
Hi,
Goetz Babin-Ebell wrote:
Hello Richard,
Richard Levitte - VMS Whacker wrote:
In message <[EMAIL PROTECTED]> on Tue, 28 Sep
2004 11:55:56 +0200, Corinna Vinschen <[EMAIL PROTECTED]> said:
vinschen> would some kind person from the core developer team mind to
vinschen> apply the following patch to the util/cygwin.sh file? A
vinschen> while ago, Cygwin moved from installing documentation under
vinschen> /usr/doc to /usr/share/doc. The below patch accomodates
vinschen> that. This patch should go into 0.9.7 and into mainline.
Applied in all active branches.
This will break openssl with older version of cygwin.
Perhaps something like
[...]
function doc_install()
{
if test -d ${INSTALL_PREFIX}/usr/share/doc
then
DOC_DIR=${INSTALL_PREFIX}/usr/share/doc/openssl
elif test -d ${INSTALL_PREFIX}/usr/doc
DOC_DIR=${INSTALL_PREFIX}/usr/doc/openssl
else
DOC_DIR=${INSTALL_PREFIX}/doc/openssl
fi
[...]
function create_cygwin_readme()
{
if test -d ${INSTALL_PREFIX}/usr/share/doc
then
README_DIR=${INSTALL_PREFIX}/usr/doc/Cygwin
else
README_DIR=${INSTALL_PREFIX}/usr/share/doc/Cygwin
fi
[...]
Oups...
function create_cygwin_readme()
{
if test -d ${INSTALL_PREFIX}/usr/share/doc
then
README_DIR=${INSTALL_PREFIX}/usr/share/doc/Cygwin
else
README_DIR=${INSTALL_PREFIX}/usr/doc/Cygwin
fi
[...]
Bye
Goetz
--
Goetz Babin-Ebell, software designer,
TC TrustCenter AG, Sonninstr. 24-28, 20097 Hamburg, Germany
Office: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
www.trustcenter.de www.betrusted.com
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [PATCH] util/cygwin.sh: Install docs under /usr/share/doc
Hello Richard,
Richard Levitte - VMS Whacker wrote:
In message <[EMAIL PROTECTED]> on Tue, 28 Sep 2004 11:55:56 +0200, Corinna Vinschen
<[EMAIL PROTECTED]> said:
vinschen> would some kind person from the core developer team mind to
vinschen> apply the following patch to the util/cygwin.sh file? A
vinschen> while ago, Cygwin moved from installing documentation under
vinschen> /usr/doc to /usr/share/doc. The below patch accomodates
vinschen> that. This patch should go into 0.9.7 and into mainline.
Applied in all active branches.
This will break openssl with older version of cygwin.
Perhaps something like
[...]
function doc_install()
{
if test -d ${INSTALL_PREFIX}/usr/share/doc
then
DOC_DIR=${INSTALL_PREFIX}/usr/share/doc/openssl
elif test -d ${INSTALL_PREFIX}/usr/doc
DOC_DIR=${INSTALL_PREFIX}/usr/doc/openssl
else
DOC_DIR=${INSTALL_PREFIX}/doc/openssl
fi
[...]
function create_cygwin_readme()
{
if test -d ${INSTALL_PREFIX}/usr/share/doc
then
README_DIR=${INSTALL_PREFIX}/usr/doc/Cygwin
else
README_DIR=${INSTALL_PREFIX}/usr/share/doc/Cygwin
fi
[...]
Bye
Goetz
--
Goetz Babin-Ebell, software designer,
TC TrustCenter AG, Sonninstr. 24-28, 20097 Hamburg, Germany
Office: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
www.trustcenter.de www.betrusted.com
smime.p7s
Description: S/MIME Cryptographic Signature
Re: X509_verify_cert(): verify with time and CRL
Hi Steve, Dr. Stephen Henson wrote: On Wed, Sep 15, 2004, Goetz Babin-Ebell wrote: Would something like the attached patch be acceptable ? (please ignore versin info in the diff) This patch also adds checking of the revokation time against the checkTime I'm not sure about that last bit and timezones. Although RFC3280 et al prohibit CAs from using timezones its not clear whether an implementation has to process them correctly. Ough. OK, better safe than sorry... The current code does by virtue of the way it can add and subtract timezone offsets from the check time. However something better would be needed to compare two ASN1_TIME structures. Has anybody done an ASN1_TIME_cmp() already ? I'll look into it... Bye Goetz -- Goetz Babin-Ebell, software designer, TC TrustCenter AG, Sonninstr. 24-28, 20097 Hamburg, Germany Office: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 www.trustcenter.de www.betrusted.com smime.p7s Description: S/MIME Cryptographic Signature
Re: X509_verify_cert(): verify with time and CRL
Hi Steve,
Dr. Stephen Henson wrote:
On Tue, Sep 14, 2004, Goetz Babin-Ebell wrote:
I still would propose the following logic:
a) CRL is valid (regarding issuance time)
if thisUpdate >= checkTime and thisUpdate <= now.
b) CRL is considered to be able to deliver revocation
information if thisUpdate <= notAfter from the certificate
(because after that time the certificate
might be removed from the CRL).
That could certainly be added as a verify flag but I'm a bit wary of doing
that by default.
Would something like the attached patch be acceptable ?
(please ignore versin info in the diff)
This patch also adds checking of the revokation time against the checkTime
Bye
Goetz
--
Goetz Babin-Ebell, software designer,
TC TrustCenter AG, Sonninstr. 24-28, 20097 Hamburg, Germany
Office: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
www.trustcenter.de www.betrusted.com
Index: x509_vfy.c
===
RCS file: /usr/cvsroot/openssl/crypto/x509/x509_vfy.c,v
retrieving revision 1.11
diff -u -r1.11 x509_vfy.c
--- x509_vfy.c 2004/03/17 16:37:10 1.11
+++ x509_vfy.c 2004/09/15 16:35:17
@@ -587,9 +587,14 @@
if (i > 0)
{
- ctx->error=X509_V_ERR_CRL_NOT_YET_VALID;
- ok = ctx->verify_cb(0, ctx);
- if (!ok) goto err;
+ if ( !(ctx->flags & X509_V_FLAG_USE_CHECK_TIME) ||
+!(ctx->flags & X509_V_FLAG_ACCEPT_NEWER_CRL) ||
+(X509_cmp_time(X509_CRL_get_lastUpdate(crl), NULL)>=0) )
+ {
+ ctx->error=X509_V_ERR_CRL_NOT_YET_VALID;
+ ok = ctx->verify_cb(0, ctx);
+ if (!ok) goto err;
+ }
}
if(X509_CRL_get_nextUpdate(crl))
@@ -621,10 +626,11 @@
/* Check certificate against CRL */
static int cert_crl(X509_STORE_CTX *ctx, X509_CRL *crl, X509 *x)
{
- int idx, ok;
+ int idx, ok, cmp;
X509_REVOKED rtmp;
STACK_OF(X509_EXTENSION) *exts;
X509_EXTENSION *ext;
+ ASN1_TIME *crltime, *certtime;
/* Look for serial number of certificate in CRL */
rtmp.serialNumber = X509_get_serialNumber(x);
idx = sk_X509_REVOKED_find(crl->crl->revoked, &rtmp);
@@ -633,7 +639,46 @@
*/
if(idx >= 0)
{
- ctx->error = X509_V_ERR_CERT_REVOKED;
+ /* now check the revocation date (if available) */
+ X509_REVOKED *ptmp = sk_X509_REVOKED_value(crl->crl->revoked,idx);
+ cmp = 1;/* default: assume revoked before date */
+ if (ctx->flags & X509_V_FLAG_USE_CHECK_TIME &&
+ ptmp && ptmp->revocationDate)
+ {
+ time_t *ptime = &ctx->check_time;
+ cmp = X509_cmp_time(ptmp->revocationDate, ptime);
+ if (cmp > 0)cmp = 0; /* revoked after check time */
+ elsecmp = 1; /* revoked before check time*/
+ }
+ if (cmp > 0)
+ {
+ ctx->error = X509_V_ERR_CERT_REVOKED;
+ ok = ctx->verify_cb(0, ctx);
+ if (!ok) return 0;
+ }
+ }
+
+ // if crl.ThisUpdate > certificate.notValidAfter the serial number may have
been removed from CRL
+ // -> do not trust
+ certtime = X509_get_notAfter(x);
+ crltime = X509_CRL_get_lastUpdate(crl);
+ if (certtime->type == crltime->type)
+ cmp = ASN1_STRING_cmp(crltime, certtime);
+ else
+ {
+ ASN1_GENERALIZEDTIME *certt=
ASN1_TIME_to_generalizedtime(certtime,NULL);
+ ASN1_GENERALIZEDTIME *crlt = ASN1_TIME_to_generalizedtime(crltime,
NULL);
+ if (certt && crlt)
+ cmp = ASN1_STRING_cmp(crlt, certt);
+ else
+ cmp = 1;
+ if (certt) ASN1_GENERALIZEDTIME_free(certt);
+ if (crlt) ASN1_GENERALIZEDTIME_free(crlt);
+ }
+
+ if (cmp > 0)
+ {// this CRL is too old, we are not able to get the right one
+ ctx->error= X509_V_ERR_UNABLE_TO_GET_CRL;
ok = ctx->verify_cb(0, ctx);
if (!ok) return 0;
}
Index: x509_vfy.h
===
RCS file: /usr/cvsroot/openssl/crypto/x509/x509_vfy.h,v
retrieving revision 1.7
diff -u -r1.7 x509_vfy.h
--- x509_vfy.h 2004/03/17 16:37:10 1.7
+++ x509_vfy.h 2004/09/15 16:35:17
@@ -324,6 +324,8 @@
#defineX509_V_FLAG_IGNORE_CRITICAL 0x10
/* Disable work
Re: X509_verify_cert(): verify with time and CRL
Hi Steve, Dr. Stephen Henson wrote: On Mon, Sep 13, 2004, Goetz Babin-Ebell wrote: ther might be a problem in X509_verify_cert() (at least 0.9.7d): if you set a verification time and the CRL was not yet valid at this time, the error X509_V_ERR_CRL_NOT_YET_VALID will be generated. (see check_crl() in x509_verify.c) It seems to me that a logic like: If check_time (and X509_V_FLAG_USE_CHECK_TIME) are set: accept the CRL if it is (now or after the check_time) valid. And if the certificate is set in the CRL, return X509_V_ERR_CERT_REVOKED if no revocationDate is set or if it is older than the check_time. (in cert_crl() in x509_verify.c) But this opens another can of worms: If the certificate expired before the CRL was issued the revocation entry might be dropped from the CRL... Any Ideas how to handle this ? There are other issues as well. I know of one CA can suspend a certificate in a CRL and later remove the suspension. For this we (and OpenSSL) would have to keep all CRLs issued by this CA to check the validity of a certificate at a given check_time. Ignoring the gigabytes of disk space and RAM needed to do this for a bigger list of CAs, I don't think that OpenSSL is able to handle more than one CRL for one CA. A certificate listed in a CRL is either revoked or put on hold. So if the suspension is removed, the certificate can be regarded as valid even during the period where it was set on hold in the CRL. So I don't think we have a problem here. I still would propose the following logic: a) CRL is valid (regarding issuance time) if thisUpdate >= checkTime and thisUpdate <= now. b) CRL is considered to be able to deliver revocation information if thisUpdate <= notAfter from the certificate (because after that time the certificate might be removed from the CRL). Bye Goetz -- Goetz Babin-Ebell, software designer, TC TrustCenter AG, Sonninstr. 24-28, 20097 Hamburg, Germany Office: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 www.trustcenter.de www.betrusted.com smime.p7s Description: S/MIME Cryptographic Signature
X509_verify_cert(): verify with time and CRL
Hello folks, ther might be a problem in X509_verify_cert() (at least 0.9.7d): if you set a verification time and the CRL was not yet valid at this time, the error X509_V_ERR_CRL_NOT_YET_VALID will be generated. (see check_crl() in x509_verify.c) It seems to me that a logic like: If check_time (and X509_V_FLAG_USE_CHECK_TIME) are set: accept the CRL if it is (now or after the check_time) valid. And if the certificate is set in the CRL, return X509_V_ERR_CERT_REVOKED if no revocationDate is set or if it is older than the check_time. (in cert_crl() in x509_verify.c) But this opens another can of worms: If the certificate expired before the CRL was issued the revocation entry might be dropped from the CRL... Any Ideas how to handle this ? Bye Goetz -- Goetz Babin-Ebell, software designer, TC TrustCenter AG, Sonninstr. 24-28, 20097 Hamburg, Germany Office: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 www.trustcenter.de www.betrusted.com smime.p7s Description: S/MIME Cryptographic Signature
dso: loading libraries self containing
Hello folks,
Loading a library that has symboles that are exported
in the actual program causes a mixup of the symbol names
and the called functions.
Some unix systems have the flag RTLD_GROUP to fix this.
Please include the folowing patch to allow this feature
in OpenSSL.
> cvs diff -u
? lib
cvs server: Diffing .
Index: dso.h
===
RCS file: /usr/cvsroot/openssl/crypto/dso/dso.h,v
retrieving revision 1.3
diff -u -r1.3 dso.h
--- dso.h 2003/04/25 15:59:01 1.3
+++ dso.h 2004/06/25 11:54:32
@@ -102,6 +102,14 @@
*/
#define DSO_FLAG_GLOBAL_SYMBOLS0x20
+/* This flag loads the library self containing.
+ * Meaning: no symbols from the program are exported to the library.
+ * This is usefull if the library has symbols that are used
+ * and exported in the program (and libraries loaded by it)
+ * At the moment only implemented in unix.
+ */
+#define DSO_FLAG_GROUP_SYMBOLS 0x40
+
typedef void (*DSO_FUNC_TYPE)(void);
typedef struct dso_st DSO;
Index: dso_dlfcn.c
===
RCS file: /usr/cvsroot/openssl/crypto/dso/dso_dlfcn.c,v
retrieving revision 1.5.4.1
diff -u -r1.5.4.1 dso_dlfcn.c
--- dso_dlfcn.c 2004/06/25 11:54:12 1.5.4.1
+++ dso_dlfcn.c 2004/06/25 11:54:32
@@ -152,6 +152,10 @@
if (dso->flags & DSO_FLAG_GLOBAL_SYMBOLS)
flags |= RTLD_GLOBAL;
#endif
+#ifdef RTLD_GROUP
+ if (dso->flags & DSO_FLAG_GROUP_SYMBOLS)
+ flags |= RTLD_GROUP;
+#endif
ptr = dlopen(filename, flags);
if(ptr == NULL)
Bye
Goetz
{
--
Goetz Babin-Ebell, software designer,
TC TrustCenter AG, Sonninstr. 24-28, 20097 Hamburg, Germany
Office: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
www.trustcenter.de www.betrusted.com
smime.p7s
Description: S/MIME Cryptographic Signature
parameter handling in apps
Hello, On a private project I am working on a module that does program command line argument parsing. (It must be the 658293rd implementation available ;-) ) My module allows to generate and print the help message from the data that is used to parse the program arguments. Is the community interrested in doing OpenSSLs command line parsing with such a module and the integration of my module in OpenSSL ? The primary functions are: * Generate a handle to keep the data: ParseArg_t *ParseArg_New(...); * Initialize an existing handle: long ParseArg_Init(...); * free all dynamically allocated data for a handle: void ParseArg_Free(...); * add an command line parameter: long ParseArg_AddEntry(...); * add an command line parameter with a function that is called if the parameter is found in the command line: long ParseArg_AddEntryFct(...); * parse the command line arguments: long ParseArg_Parse(...); * check if all required parameters are given: long ParseArg_CheckReq(...); * print a help message: long ParseArg_PrintHelp(...); It still needs more testing and some minor stuff but the functionality is implemented. (Hey, I started this sunday night... ;-) ) Bye Goetz -- Goetz Babin-Ebell, software designer, TC TrustCenter AG Sonninstr. 24-28, 20097 Hamburg, Germany Office: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 www.trustcenter.de www.betrusted.com smime.p7s Description: S/MIME Cryptographic Signature
minor bug in apps/apps.c
Hello folks,
there seems to be a minor bug
in the pasword getter:
Bye
Goetz
Index: apps/apps.c
===
RCS file: /usr/cvsroot/openssl/apps/apps.c,v
retrieving revision 1.73
diff -u -r1.73 apps.c
--- apps/apps.c 2003/10/29 14:25:50 1.13
+++ apps/apps.c 2003/11/14 14:54:45
@@ -501,7 +501,7 @@
{
const char *password =
((PW_CB_DATA *)UI_get0_user_data(ui))->password;
- if (password[0] != '\0')
+ if (password && password[0] != '\0')
{
UI_set_result(ui, uis, password);
return 1;
@@ -525,7 +525,7 @@
{
const char *password =
((PW_CB_DATA *)UI_get0_user_data(ui))->password;
- if (password[0] != '\0')
+ if (password && password[0] != '\0')
return 1;
}
default:
--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
smime.p7s
Description: S/MIME Cryptographic Signature
Re: NISCC ASN.1 test suite available ?
Hello Jostein, Jostein Tveit wrote: Goetz Babin-Ebell <[EMAIL PROTECTED]> writes: is the NISCC test suite that found the ASN.1 bugs in OpenSSL somewhere available ? This was the answer I got when I contacted NISCC some days after the ASN.1 bug was discovered: : NISCC has a policy of only releasing the test-suite to recognised : developers of products that provide SSL/TLS services and therefore may be : vulnerable to the generic problems discovered. Unfortunately this means : that we will not be able to release the material to you. :-( Does anybody know of a test suite that tests an ASN.1 implementation for known bugs and is public available ? Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 smime.p7s Description: S/MIME Cryptographic Signature
NISCC ASN.1 test suite available ?
Hallo folks, is the NISCC test suite that found the ASN.1 bugs in OpenSSL somewhere available ? We want to include it in our internal test environment... Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 smime.p7s Description: S/MIME Cryptographic Signature
[openssl.org #747] -pre and -post cmd line params for openssl cmds
And here is the text: Hello Folks, Since the rt dropped the message text, I send it to the list: for those of us using engines: this patch adds the -pre -and -post params to all openssl commands that let you set an engine. At the moment it is in the state "untested", but I had an similar patch that worked as intended... So please have a look... Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 smime.p7s Description: S/MIME Cryptographic Signature
[openssl.org #747] -pre and -post cmd line params for openssl cmds
Hello Folks, Since the rt dropped the message text, I send it to the list: for those of us using engines: this patch adds the -pre -and -post params to all openssl commands that let you set an engine. At the moment it is in the state "untested", but I had an similar patch that worked as intended... So please have a look... Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 smime.p7s Description: S/MIME Cryptographic Signature
Re: [CVS] OpenSSL: openssl/crypto/des des.h des_old.h
Richard Levitte wrote: Hello Richard, OpenSSL CVS Repository http://cvs.openssl.org/ Server: cvs.openssl.org Name: Richard Levitte Root: /e/openssl/cvs Email: [EMAIL PROTECTED] ^^ Is that really a good idea ? Module: openssl Date: 11-Dec-2002 07:59:18 Branch: HEAD Handle: 2002121106591600 Modified files: openssl/crypto/des des.h des_old.h Log: Since HEADER_DES_H has been the protector of des.h since libdes (before SSLeay, maybe?), it's better to have that macro protect the compatibility header des_old.h. In the new des.h, let's use a slightly different protecting macro. [...] Index: openssl/crypto/des/des.h $ cvs diff -u -r1.42 -r1.43 des.h --- openssl/crypto/des/des.h 26 Mar 2002 14:28:04 - 1.42 +++ openssl/crypto/des/des.h 11 Dec 2002 06:59:16 - 1.43 @@ -56,8 +56,8 @@ * [including the GNU Public Licence.] */ -#ifndef HEADER_DES_H -#define HEADER_DES_H +#ifndef HEADER_NEW_DES_H +#define HEADER_NEW_DES_H [...] I think it would be better to use something like: #ifndef HEADER_OPENSSL_DES_H #define HEADER_OPENSSL_DES_H No other module could use this protector unintentionally... Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 smime.p7s Description: S/MIME Cryptographic Signature
Re: Crypto library problems
2069446 wrote:
> READ DATA
>
> EVP_EncryptInit(...)
> for(;;)
> {
> EVP_EncryptUpdate(...)
> /* until end of data*/
> }
>
> EVP_EncryptFinal(...)
If the data can be large something other would be better:
EVP_EncryptInit()
while(Read_Data_Block())
{
EVP_EncryptUpdate()
}
EVP_EncryptFinal()
> It seems to work good only with some sizes of data blocks.
> Our question;
Only for small blocksizes...
(Meaning: one loop...)
> Encrypt Init has to be called every time we call EncyptUpdate?
No It has te be called once to generate the symetric key...
By
Goetz
--
Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Question about cryptographic method
Jan Mikosiñski wrote: Hello Jan, > I create a system which uses openssl and GemPlus card - GemSafe > I try create sign with thic card ( I'm using GemPlus pk2priv.dll whith > PKCS#11 interface implemented) and verify it with OpenSSL . > To create sign I use CKM_RSA_PKCS ( PKCS#11) algoritm. To decrypt sign with Please read the PKCS#11 standard more carefully. CKM_RSA_PKCS is RSA with PKCS#1 (V1.5) padding... How do you calculate the digest with PKCS#11, how do you verify the result with OpenSSL ? By Goetz -- Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CRLs and self-signed root certs.
Peter Gutmann wrote: > > Goetz Babin-Ebell <[EMAIL PROTECTED]> writes: > > >Everybody can issue a CRL. > > Only a CA with CRL signing enabled can issue a CRL. Everybody who can generate a certificate with the propper flags can generate a CRL. But he has to find a way to let the user trust him in issuing the CRL... > >A CA can issue a CRL with own revokated certificates but it can issue a CRL > >with revoked certificates of other CAs (at least in X509v3...) > > A CA can't revoke another CA's certificates, only certificates which it has > issued. ?? ITU-T X509 (06/97): 11.2 Management of certificates [...] (page 25:) - The CA shall maintain: [...] b) a time-stamped list of revoked certificates of all CAs known to the CA, certified by the CA. 2 possible meanings: - It maintains a CRL of certificates issued by other CAs. - It maintains a CRL of certificates issued by CAs that use certificates that this CA issued. But in the definition of a CRL I didn't find anything saying that it can only revoke own certificates... By Goetz -- Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CRLs and self-signed root certs.
Frank Balluffi wrote: > > I can imagine a scenario whereby an organization might choose to sign a > death notice before going out of business. For example, suppose a > commercial CA decided to go out of business, there might be benefits to > their signing a CRL including their root certificate. The question is: Has the CA issued certs and are they valid at the point of the revokation of the CA cert ? Who maintains these certs ? At least in Germany a public CA that goes out of bussines has to find another CA that maintains the valid issued certificates. And this new CA has a CRL, where it can publish the revokation of the old root cert of the old CA. By Goetz -- Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CRLs and self-signed root certs.
Mats Nilsson wrote: > Goetz Babin-Ebell <[EMAIL PROTECTED]> wrote: > >You can generate a new root certificate and use it to > >sign the new CRL which lists the old root certificate as revoked... > > I'm not sure one should recognize the new root ca to be a legitimate > revoker of the orignal certificate. Isn't it so, that only the issuer of a > certificate can revoke a certificate? (where being an "issuer" is > equivalent to holding the private key) No. Everybody can issue a CRL. A CA can issue a CRL with own revokated certificates but it can issue a CRL with revoked certificates of other CAs (at least in X509v3...) When you revoke your root certificate, you could issue a CRL and ask another CA to include your root certificate in their CRL. By Goetz -- Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CRLs and self-signed root certs.
Mats Nilsson wrote: > > Hi list. Hallo Mats, > Some philosophical questions: > > Should a self-signed root certificate ever need to be revoked, shall it > list itself in its usual CRL(s), as the last thing it does before it is > thrown away, or is it sufficient (from its users' standpoint) that it > simply ceases to issue more CRLs? Since the root certificate is at this time invalid, you can't use it to sign the CTL... You can generate a new root certificate and use it to sign the new CRL which lists the old root certificate as revoked... Every root cert needs an own serial number ! (but this is a wise decission anyway...) By Goetz -- Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: new engine
Dr S N Henson wrote:
> The idea behind this is that a simple engine aware application could
> then just call ENGINE_load_config("filename.cnf") and forget about any
> other details.
Would carve the way to store the engine configuration in stone...
By
Goetz
--
Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: new engine
Ben Laurie wrote: > > Geoff Thorpe wrote: > > > > On Tue, 31 Oct 2000, Libor Krystek wrote: > > > > > I'am creating new engine for other hardware. This hardware must be > > > initialized before using but for its initialization I need input some > > > parameters (e.g. hostname, username, password). > > > Function ENGINE_init(ENGINE *e) call engine function init() and it have > > > no input parameters. > > > How can I do it? Do you have any conception? > > > > ENGINE_ctrl(); > > > > make your "init()" handler fail (setting an explanatory error) unless > > ENGINE_ctrl() has already been called to pass in everything you need. [...] > Leaves me with one - if specific engines have to be initialised "by > hand", then we haven't got much in the way of abstraction, have we? Is > there a better way? Config files? External programs? something like [ENGINE_ENTRY_xyz] ctrl_0 = 1234,LONG:42 ctrl_1 = 0xff,DATA: [...] resulting in something like: ... ENGINE_ctrl(engine,1234,42,0,0); ENGINE_ctrl(engine,0xff,0,data,0); ... By Goetz -- Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
domainComponent
Hallo, could it be possible to add the domainComponent (defined in RFC 2247) to OpenSSL ? #define SN_domainComponent "DC" #define LN_domainComponent "domainComponent" #define NID_domainComponent181 #define OBJ_domainComponent0L,9L,2342L,19200300L,100L,1L,25L By Goetz -- Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: problem with command make.
Jesus Ferreira wrote: > > Dear all, > We have Apache server 1.3.6 over a Solaris 2.6 systmen, and we are > trying to install openssl and apache_1.3.6+ssl_1.39 but we have found > problems when we tried to execute the "make" command. You have a problem with the "ar" command: > ar r ../libcrypto.a cryptlib.o mem.o mem_dbg.o cversion.o ex_data.o tmdiff.o >cpt_err.o ebcdic.o > make[1]: ar: Command not found > make[1]: *** [lib] Error 127 > make[1]: Leaving directory `/opt/isroot4/openssl-0.9.5/crypto' > make: *** [all] Error 1 make can't find it. check your PATH... By Goetz -- Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
How to solve linking errors (was Re: Repost...Linker errors)
Braun Brelin wrote: > Hello, Hello, > I originally posted to openssl-users, but > I've just realized that there exists and > openssl-dev mailing list and this question > is more on-topic for the dev list anyway. It isn't. It is a general C/ linking problem You can solve it reading the build line and the error messages. (and a short look at the content of your librares.) > ERRORS FOLLOW- > /usr/local/bin/gcc client.o infernet_c_connect.o infernet_c_disconnect.o inferne > t_c_receive.o infernet_c_send.o infernet_ssl_c_connect.o infernet_ssl_c_setup.o > -o client -L/usr/local/ssl/lib -g -lcrypto -lssl -lxnet -I/usr/local/ssl/includ > e you link the libraries libcrypto.a and libssl.a in this order. Remember: the linker binds every .o to the program and starts looks in the libraries for unresolved symbols. > Undefined first referenced > symbol in file > BIO_f_buffer/usr/local/ssl/lib/libssl.a(ssl_lib.o) [...] meaning: while binding ssl_lib.o from libssl.a the linker had an symbol it wasn't able to resolve. It was the symbol BIO_f_buffer. OK. you have to find a library containing the symbol BIO_f_buffer and link it after libssl.a to your program. Have you a library with this symbol ? After a short search you should find the library libcryto.a. You must list libcrypto.a after libssl.a. the link line should have been: /usr/local/bin/gcc client.o infernet_c_connect.o infernet_c_disconnect.o \ infernet_c_receive.o infernet_c_send.o infernet_ssl_c_connect.o \ infernet_ssl_c_setup.o \ -o client -L/usr/local/ssl/lib -g -lssl -lcrypto -lxnet Must be somewhere in the GCC FAQ... By Goetz -- Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Harmonising OpenSSL UI handling...
Richard Levitte - VMS Whacker wrote: Hallo Richard, > From: Goetz Babin-Ebell <[EMAIL PROTECTED]> > gbe> Richard Levitte - VMS Whacker wrote: > gbe> Agree, > gbe> but a seperate function for user autentification would be good... > > Exactly what do you mean? If it's the separation between strings, > passphrases and file (and whatever), it's still just a string, with > the only real difference that prompting for a password requires no > echo. It is more a logical than a technical difference. Autentication is a special and very importand dialog. I wanted to seperate it from the normal flow of IO at the earliest possible moment. > gbe> But will the generated string fit the output ? > gbe> A PIN Pad with a 16x2 LCD requires another layout than a GUI... > Hmm, good point. Perhaps one should have the applicatoin check the > maximum size and have it adapt? Best place for these checks is the UI... ;-) > gbe> > gbe> > - a "wrong" string (eh, "That was the wrong password", f. >example?) > gbe> > gbe> should be handled in the UI (another call ?) > gbe> > > gbe> > Really? And how would it determine if something was previously wrong? > gbe> > I was thinking of the UI as a pretty stateless thingy. A bit > gbe> > according to the KISS principle. > gbe> Another Message ? > gbe>UI_GetAut(TXT_AUT_CLIENT,...) > gbe>UI_GetAut(TXT_AUT_LASTTRY,...) > > I'm not sure I got that. For example, you might want to include an > error text in a prompt dialog box, a little like the default XDM login > screen works (it will say that you weren't authenticated and at the > same time prompt again). That's why I think the prompting routines > need to know about that info as well... The UI should be stateless. But the message could have a state. UI_GetAut(TXT_AUT_CLIENT,...) -> "please enter user/passphrase" UI_GetAut(TXT_AUT_RETRY,...) -> "authentication failed. please retry:" > gbe> > gbe> const char *UI_GetTextFor(MessageCode,SubCode); > gbe> > > gbe> > Eeeep, localization... Just the thought... No, it's not a bad idea, > [...] > gbe> I know... > gbe> But the UI seems to be a good place to start... > > Hmm, true... Gotta learn how those things work (is there a standard > at all?) One ? ... > gbe> 1. user authentication (pass phrase, PIN,...) > Check. > gbe> 2. new user authentification (new pass prase, with verify) > Ah... check. > gbe> 3. give some information about the current state > Check. > > gbe> What else ? > > Doesn't have to be decided all at once, there's room for extensions... Wan't my intention. But missing something now... By Goetz -- Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Harmonising OpenSSL UI handling...
Richard Levitte - VMS Whacker wrote:
Hallo Richard,
> From: Goetz Babin-Ebell <[EMAIL PROTECTED]>
> gbe> 1. InsertString: ask the user for a string
> gbe> 1.1InsertPass: special case: ask for a passphrase
> gbe> (1.2 InsertFile: special case: ask for file name, could be handled
>with
> gbe> 1.)
[...]
>
> Hmm, I thought this would be handled inside the general function,
> depending on the command number... But hey, matter of taste...
Agree,
but a seperate function for user autentification would be good...
> gbe> > - a prompt string
> gbe> should be generated in the UI
>
> I disagree, there's no way to get it general enough. A simple string
> completely generated by the caller is a better way to maximise
> generality. Otherwise, I can almost guarantee that we will see some
> ugly tweaking, or this part being hacked into until clumsiness is
> irrevocably reached. Seen it too many times already...
But will the generated string fit the output ?
A PIN Pad with a 16x2 LCD requires another layout than a GUI...
> gbe> > - a "wrong" string (eh, "That was the wrong password", f. example?)
> gbe> should be handled in the UI (another call ?)
>
> Really? And how would it determine if something was previously wrong?
> I was thinking of the UI as a pretty stateless thingy. A bit
> according to the KISS principle.
Another Message ?
UI_GetAut(TXT_AUT_CLIENT,...)
UI_GetAut(TXT_AUT_LASTTRY,...)
> gbe> > - a pointer to user data
> gbe> A Pointer to function specific data would be better...
>
> Well, actually, I was thinking that this data would just be pass on to
> the callback function that the user might define. You know, a little
> like we do with a bunch of other callbacks in OpenSSL :-) (the current
> password prompting callback among others...).
typedef struct
{
unsigned long type; /* type == UI_TYPE_AUTHDATA means is
UI_AuthData */
unsigned int minAuthLen;
unsigned int maxAuthLen;
char *authBuffer; /* will contain user authentication */
int verify;
const char *AuthIDName; /* contains name of key */
void *userData;
} UI_AuthData;
> gbe> const char *UI_GetTextFor(MessageCode,SubCode);
>
> Eeeep, localization... Just the thought... No, it's not a bad idea,
> but for consistency's sake, there are lots of things that need being
> changed to localize OpenSSL. Think of all the error messages! And
> the way it's currently structured is not locale-friendly, believe me
> :-/.
I know...
But the UI seems to be a good place to start...
> gbe> Perhaps a list of required user interactions could help ?
>
> Absolutely.
Let's start:
UI is needed for:
1. user authentication (pass phrase, PIN,...)
(should be able to give a name/ID for the requested authentification)
2. new user authentification (new pass prase, with verify)
3. give some information about the current state
(only print/log some data, don't wait for input)
What else ?
By
Goetz
--
Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Harmonising OpenSSL UI handling...
Richard Levitte - VMS Whacker wrote: Hello Richard, > From: Dr Stephen Henson <[EMAIL PROTECTED]> > drh> So, any thoughts on the matter? Could clear up some stuff... > Hmm, a general UI function in OpenSSL that takes the following > parameters: I don't think that one UI function is a good solution: There should be more than UI function: 1. InsertString: ask the user for a string 1.1 InsertPass: special case: ask for a passphrase (1.2InsertFile: special case: ask for file name, could be handled with 1.) 2. Confirm:ask to confirm some action (eg. accept a certificate in handshake) 3. InsertNumber: ask for a number 4. Ough: give a error message ... > - a command number (GIVE_PASSWD, HANDLE_CARD, ...) +1 > - a prompt string should be generated in the UI > - a "wrong" string (eh, "That was the wrong password", f. example?) should be handled in the UI (another call ?) > - a return buffer (double pointer, so we might allocate it in > that function) > - a return buffer size (pointer to int, so we might fill it in > ourselves) depending on UI function. (perhaps give a BUF_MEM ?) > - a pointer to user data A Pointer to function specific data would be better... contends should depend on > This function would then do a default thing or call an application-supplied > callback that does the right thing. perhaps a function table that normally points to some internal functions ? To keep it localizeable we should introduce another function: const char *UI_GetTextFor(MessageCode,SubCode); like: const char *ClientMsg = UI_GetTextFor(TXT_ENTER_PASSWD,TXT_SUB_CLIENT); (returns "please enter passphrase for client key") const char *Name = GetSomehowTheNameForThePrivateKey(); (returns "for internal use") const char *Prompt= UI_GetTextFor(TXT_ENTER_PASSWD,TXT_PROMPT); (returns "passphrase:") would result: please enter passphrase for client key : passphrase: > In any case, this would probably become a new directory under crypto/, > don't you think? crypto/ui/? 1+ > [it should be plain visible that I was a bit inspired from the > HWCryptoHook stuff :-)] Perhaps a list of required user interactions could help ? By... Goetz -- Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Adding Object domainComponent
Hallo,
could the Object domainComponent be added to the objects.h ?
( from rfc 1274 / 2247:)
#define SN_domainComponent "DC"
#define LN_domainComponent "domainComponent"
#define NID_domainComponent 181
#define OBJ_domainComponent 0L,9L,2342L,19200300L,100L,1L,25L
or:
#define OBJ_ccitt 0L
#define OBJ_dataOBJ_ccitt,9L
#define OBJ_pss OBJ_data,2342L
#define OBJ_ucl OBJ_pss,19200300L
#define OBJ_pilot OBJ_ucl,100L
#define OBJ_pilotAttributeType OBJ_pilot,1L
#define SN_domainComponent "DC"
#define LN_domainComponent "domainComponent"
#define NID_domainComponent 181
#define OBJ_domainComponent OBJ_pilotAttributeType,25L
(from:
ccitt OBJECT IDENTIFIER ::= {0}
data OBJECT IDENTIFIER ::= {ccitt 9}
pss OBJECT IDENTIFIER ::= {data 2342}
ucl OBJECT IDENTIFIER ::= {pss 19200300}
pilot OBJECT IDENTIFIER ::= {ucl 100}
pilotAttributeType OBJECT IDENTIFIER ::= {pilot 1}
)
By
Goetz
--
Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: SSL_SESSION copying
At 10:02 08.03.00 +0100, you wrote:
>On Tue, Mar 07, 2000 at 05:22:55PM -0800, Seetharama Sarma Ayyadevara wrote:
>> If I run this I am getting this error
>>
>> ERROR : error:0D067007:asn1 encoding
>> routines:ASN1_COLLATE_PRIMITIVE:expecting an asn1 sequence
>>
>> Session len : 119 value : 0u
>>
>> Can any one throw some light on what I am doing wrong.
>>
>> int foo (SSL_SESSION * ssl_session)
>> {
>> char buf1[1024], buf [1024 * 10], *p;
>> int retval;
>> SSL_SESSION * new_session;
>>
>> memset ((void *)buf, '\0', 1024 * 10);
>> p = &buf;
I thtink that should be
p = buf;
p and buf are pointer to char (but buf has some valid data assigned...)
>> retval = i2d_SSL_SESSION (ssl_session, &p);
>
>Here, you path "p" to retval called by reference. I don't know why this
>is done, but "p" is altered during the call, such that after the
>i2d_SSL_SESSION p!=&buf.
Because p is a moving pointer, so you can convert more than one
element:
retval = i2d_SSL_SESSION (ssl_session1, &p);
retval = i2d_SSL_SESSION (ssl_session2, &p);
...
>> if (!retval)
>> return (-1);
>> printf ("Session len : %d value : %s\n", retval, buf);
buf contains binary data (DER encoded session data),
printing it to terminal won't produce human rewadable data...
>Here, prepare another
> p = &buf;
>and it should work.
and again
p = buf;
>> new_session = d2i_SSL_SESSION (&new_session, &p, retval);
By
Goetz
--
Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Sadistic C compiler...
At 17:31 20.01.00 +0100, Richard Levitte - VMS Whacker wrote: Hallo Richard, I fear we don't solve the problem but try to tweak a broken implementation until it works. I think we should seperate the functions handling values and the functions handling callbacks: int BIO_ctrl_callback(BIO *bp,int cmd,long larg,int (*cb)()); Is not nice, requires changing of some structures but seems to be the best save way... By Goetz -- Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Function naming convention.
At 08:00 11.01.00 +0200, Arne Ansper wrote: > > >> So any preferences or alternative suggestions? > >peek for iget and copy for rget peek is OK. copy is bad, suggesting you get a independent copy you can modify. link(ed) ? By Goetz -- Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Certificate verification
At 12:43 04.01.00 +0200, you wrote: >Hello all! Hello, >For each certificate in chain I do next: > >i = X509_verify(x, X509_get_pubkey(x)); >For many sites (www.chase.com, www.ubs.com, ...) I have that first certificate >in chain has unmatched signature (i == 0). Only last certificate (from RSA ) >has good signature. Is it possible or I do something wrong? i = X509_verify(x,X509_get_pubkey(issuercert)); The last certificate is a self signed certificate. A X509_verify(x,X509_get_pubkey(cacert)) on a self signed cert (meaning X509_verify(x,X509_get_pubkey(x))) will only test against transmission errors. But to test against modifications by a untrusted third party (malice) you must verify the certificate against other, external data. You should have a store of verified (root) certificates and reject all certificates you can't verify with one of the certificates from this store. By Goetz -- Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: them bugs ...
At 18:16 01.12.99 +, you wrote: >On 30 Nov 1999 [EMAIL PROTECTED] wrote: > >> Geoff Thorpe <[EMAIL PROTECTED]> wrote: >> > great. BIO_nprintf? > >The whole point had been that snprintf (and vsnprintf) don't exist on all >platforms, they're GNU extensions. BIO_printf currently has a fixed 2k >buffer (see crypto/bio/b_print.c) ... if we can obtain portable snprintf >code then a buffer-safe BIO_??printf?? function could be introduced. >Mallocing, freeing and remallocing is something many aren't happy to do - >so I think an snprintf-style function (where you provide the buffer and >buffer-size as arguments) would be preferable to an all-singing >all-dancing dynamic BIO_printf that handles anything. > >But this would require a new function as the argument list would differ >from BIO_printf. At least we should fix BIO_printf() to truncate the data at the end of the buffer... By Goetz -- Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
possible crash in BIO_printf()
Hallo,
I have a problem with BIO_printf:
It is possible to crash a program using BIO_printf passing data
resulting in a very long (> 1024*2 char) string.
We should fix this by using vsnprintf() instead of vsprintf().
(and snprintf instead of sprintf)
But on some systems there is no (v)snprintf.
There we must use (v)sprintf().
(And hope this will be fixed soon...)
Sorry, I didn't look in the configuration scripts how to set the macro...
By
Goetz
int BIO_printf (BIO *bio, ...)
{
va_list args;
char *format;
int ret;
MS_STATIC char hugebuf[1024*2]; /* 10k in one chunk is the limit */
va_start(args, bio);
format=va_arg(args, char *);
hugebuf[0]='\0';
hugebuf[sizeof(hugebuf)-1] = '\0';
#ifdef HAS_VSNPRINTF
vsnprintf(hugebuf,sizeof(hugebuf)-1),format,args);
#else
vsprintf(hugebuf,format,args);
#endif
ret=BIO_write(bio,hugebuf,strlen(hugebuf));
va_end(args);
return(ret);
}
--
Goetz Babin-Ebell mailto:[EMAIL PROTECTED]
TC Trust Center GmbHhttp://www.trustcenter.de
Sonninstr. 24-28 / 20097 Hamburg / Germany Tel.:+49-(0)40 80 80 26 -0
Fax:-126
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: SV: X509_NAME_ENTRY problems
At 08:38 17.11.99 +0100, you wrote: >X509_NAME_ENTRY *pX509NameEntry = NULL; >X509_REQ *pRequest = X509_REQ_new(); >X509_NAME *pX509Name = X509_NAME_new(); > >// Setup Country >X509_NAME_ENTRY_create_by_NID(&pX509NameEntry, NID_countryName, >V_ASN1_PRINTABLESTRING, (unsigned char *) "DK", 2); >X509_NAME_add_entry(pX509Name, pX509NameEntry, 1, 1); >X509_NAME_ENTRY_free(pX509NameEntry); > >// Setup Organisation >X509_NAME_ENTRY_create_by_NID(&pX509NameEntry, >NID_organizationName,V_ASN1_PRINTABLESTRING,(unsigned char *) "ACME", 4); > > The call above cause an access violation. Why ??? > If I set pX509NameEntry=NULL before I make the call I have no problems. it causes access violation because you give X509_NAME_ENTRY_create_by_NID() a pointer to an invalid X509_NAME_ENTRY. pX509NameEntry must be NULL or must point to a valid X509_NAME_ENTRY. you could do it: 1. X509_NAME_ENTRY *pX509MameEntry = NULL; X509_NAME *pX509Name = X509_NAME_new(); /* Setup Country */ X509_NAME_ENTRY_create_by_NID(&pX509NameEntry, NID_countryName, V_ASN1_PRINTABLESTRING, (unsigned char *) "DK", 2); X509_NAME_add_entry(pX509Name, pX509NameEntry, 1, 1); X509_NAME_ENTRY_free(pX509NameEntry); pX509NameEntry = NULL; /* Setup Organisation */ X509_NAME_ENTRY_create_by_NID(&pX509NameEntry, NID_organizationName,V_ASN1_PRINTABLESTRING, (unsigned char *) "ACME", 4); 2. X509_NAME_ENTRY *pX509MameEntry = NULL; X509_NAME *pX509Name = X509_NAME_new(); /* Setup Country */ X509_NAME_ENTRY_create_by_NID(&pX509NameEntry, NID_countryName, V_ASN1_PRINTABLESTRING, (unsigned char *) "DK", 2); X509_NAME_add_entry(pX509Name, pX509NameEntry, 1, 1); /* Setup Organisation */ X509_NAME_ENTRY_create_by_NID(&pX509NameEntry, NID_organizationName,V_ASN1_PRINTABLESTRING, (unsigned char *) "ACME", 4); Use the source, Luke... (crypto/x509/x509name.c) By Goetz -- Goetz Babin-Ebell mailto:[EMAIL PROTECTED] TC Trust Center for Security http://www.trustcenter.de in Data Networks GmbH Tel.: +49-40-80 80 26-0 Sonninstr. 24-28 / 20097 Hamburg / Germany Fax.: +49-40-80 80 26-126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Communicator Address Book, LDAP over SSL and client certificates
At 20:17 21.07.99 +0200, you wrote: >Hi, Hallo, >I am a member of the OpenLDAP core and I have been glueing together the >OpenLDAP slapd (the standalone LDAP server) with OpenSSL. It was easy >and most complications came from it being a multithreaded program that >also does non-blocking I/O, that is, a real pig. Fine... >OK, now I have run into a problem. I don't manage to convince Netscape >Communicator to send the client certificate when using LDAP. The same >certificate is sent correctly to Apache/mod_ssl. All that said, >everything would point at my direction, right? Well, I have been for >several days fighting this and I am not so sure. If I tell the Address >Book that my LDAP server is my Apache/mod_ssl, then it fails too for >the same reason: > >[error] OpenSSL: error:140890C7:SSL >routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate >[Hint: No CAs known to server for verification?] You must specify a list of CA certificates. Only if Netscape has a client certfificate signed by one of the certificates in the list, it will send a client certificate... Should be in the FAQ... By Goetz -- Goetz Babin-Ebell mailto:[EMAIL PROTECTED] TC Trust Center for Security http://www.trustcenter.de in Data Networks GmbH Tel.: +49-40-766 29 3301 Am Werder 1 / 21073 Hamburg / Germany Fax.: +49-40-766 29 577 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Aiiggggghhh - I cannot take it anymore (autoconf cometh?!)
At 11:09 09.07.99 +0200, you wrote: >On Fri, Jul 09, 1999, Lenny Foner wrote: > >> autoconf work I've got, SSLeay compiled effortlessly under HPUX 9 and >> 10, Solaris, NetBSD, Linux (4.2 and 5.1), Irix (32 and 64 bit), Alphas >> (64 bit, or course) and probably some other OS's I'm forgetting---all >> simply by typing ./configure and then make. > >With OpenSSL, you type ./config and then make. :) > >Most of the actual problems we have been having are caused by compiler >bugs in the Sun, IRIX and HPUX compilers. I don't think autoconf would >really have helped there. Correct me if I'm wrong, though. I really would like to have the system dependant data (modufied files and objects) in system specific sub directories. This allowing the same source trees for more than one system. E.g. to have in the openssl root directory directores like ./i486-linux-gnu ./i486-linux-gnu-dbg ./sparc-solaris ./sparc-solaris-dbg ./i486-winnt ./i486-winnt-dbg ./i486-winnt-dbgbc ... for M$ it is there but not for *nix By Goetz -- Goetz Babin-Ebell mailto:[EMAIL PROTECTED] TC Trust Center for Security http://www.trustcenter.de in Data Networks GmbH Tel.: +49-40-766 29 3301 Am Werder 1 / 21073 Hamburg / Germany Fax.: +49-40-766 29 577 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: R: Certificate - LDAP Mapping
At 20:38 12.06.99 +0200, you wrote:
>"William M. Perry" wrote:
>> It can be useful, but I think people are exposing entirely too much
>> information in their certificate names nowadays. Things like your title or
>> division can expose too much information about you to an attacker. If
>> someone wants to get at the financial info of aventail, and our CFO had
>> 'Chief Financial Officer' as his title whereas I just had 'Unix Dweeb' or
>> nothing, they would know who to concentrate on. :)
>>
>> Of course, this same info is available on your business card, but... :)
>
>I think that a certificate with your name and e-mail/org/ou will not hurt
>anyone: ou can be set to something like a code useful to you (not necessary
>you have to put "Project Manager" just use 01PJS456 ...)
This is security by obscurity.
When information has only local meaning,
why include it in the certificate at all ?
In your local environment it is simple to create a lookup from
certificate to Title ("Project Manager...)
By
Goetz
--
Goetz Babin-Ebell mailto:[EMAIL PROTECTED]
TC Trust Center for Security http://www.trustcenter.de
in Data Networks GmbH Tel.: +49-40-766 29 3301
Am Werder 1 / 21073 Hamburg / Germany Fax.: +49-40-766 29 577
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Adding parameters to passphrase callbacks.
At 10:26 09.06.99 +0100, you wrote: >Dr Stephen Henson wrote: >> >I think 3 is too disgusting to contemplate. 1 is OK with me: we >regularly break all existing code, anyway (speaking of which, I tried to >get demos/selfsign.c going the other day, but X509v3 support has changed >so drastically I couldn't easily figure out how!). If you are concerned >about existing code, then I'd vote for 2, but I'm not hugely keen on the >precedent or the bloat. > >The other possibility I can think of is to add an "extra data" pointer >to EVP_PKEY instead. But this way you couldn't do PKey = PEM_read_PrivateKey(fp,NULL,cb) and let PEM_read_PrivateKey() handle the allocation for you By Goetz -- Goetz Babin-Ebell mailto:[EMAIL PROTECTED] TC Trust Center for Security http://www.trustcenter.de in Data Networks GmbH Tel.: +49-40-766 29 3301 Am Werder 1 / 21073 Hamburg / Germany Fax.: +49-40-766 29 577 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Adding parameters to passphrase callbacks.
At 21:54 08.06.99 +0100, you wrote: Hallo, >>From time to time someone needs to pass a parameter to a passphrase >callback. For example the prompt for the password can be set to a >meaningful phrase or the passphrase itself could be set by this method. >Currently this isn't directly possible and the only solutions are messy. >2. Add a set of extra functions: > >EVP_PKEY *PEM_read_PrivateKey_ex(FILE *fp,EVP_PKEY **x, >pem_password_cb_ex *, void *arg); >int pem_password_cb_ex(char *buf, int size, int rwflag, void *arg); > >This might be considered overkill, would double the number of PEM >functions needed and have lots of PEM 'legacy' functions using the old >method that would have to stay. It would however retain compatability >with existing code. We could do domething like #define PEM_read_PrivateKey(fp,pkeyp,callback)\ PEM_read_PrivateKey_ex(fp,pkeyp,callback,NULL) Would be no overkill, cause we still have only one set of functions I would prefer that... (I myself planned to do something like that...) >3. Do something evil with the cb parameter... > >EVP_PKEY *PEM_read_PrivateKey(FILE *fp,EVP_PKEY **x, void *x);# [...} >This needs a bit more explanation. Any function calling >PEM_read_PrivateKey() in the "old way" will end up calling the >default_pem_callback() which retains the old behaviour: treating 'x' as >a passphrase callback in the "old way". Anything that wants to pass >parameters to the callback can replace the default_pem_callback() and >interpret the 'x' parameter in any appropriate way. > >This does however lose typechecking of the 'x' parameter and is a bit >awkward to use. Interpreting a void * as a function pointer might also >be a potential problem. No please ! By Goetz -- Goetz Babin-Ebell mailto:[EMAIL PROTECTED] TC Trust Center for Security http://www.trustcenter.de in Data Networks GmbH Tel.: +49-40-766 29 3301 Am Werder 1 / 21073 Hamburg / Germany Fax.: +49-40-766 29 577 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: no unlock in bio/b_sock.c
At 17:52 07.06.99 +0200, you wrote:
>Hallo,
>
>I think in b_sock.c I've stumbled into some error cases in which some locking
>isn't undone:
sorry, wrong diff...
*** OpenSSL/crypto/bio/b_sock.c Mon Apr 26 19:00:12 1999
--- OpenSSL/crypto/bio/b_sock.fixed.c Mon Jun 7 17:46:45 1999
***
*** 247,253
MemCheck_off();
ret=(struct hostent *)Malloc(sizeof(struct hostent));
! if (ret == NULL) return(NULL);
memset(ret,0,sizeof(struct hostent));
for (i=0; a->h_aliases[i] != NULL; i++)
--- 247,254
MemCheck_off();
ret=(struct hostent *)Malloc(sizeof(struct hostent));
! if (ret == NULL)
! goto err;
memset(ret,0,sizeof(struct hostent));
for (i=0; a->h_aliases[i] != NULL; i++)
***
*** 349,356
BIO_ghbn_miss++;
ret=gethostbyname(name);
! if (ret == NULL) return(NULL);
! if (j > 128) return(ret); /* too big to cache */
/* else add to cache */
if (ghbn_cache[lowi].ent != NULL)
--- 350,360
BIO_ghbn_miss++;
ret=gethostbyname(name);
! if (ret == NULL || j > 128) /* not found or too big to
cache */
! {
! CRYPTO_w_unlock(CRYPTO_LOCK_BIO_GETHOSTBYNAME);
! return(ret);
! }
/* else add to cache */
if (ghbn_cache[lowi].ent != NULL)
By
Goetz
--
Goetz Babin-Ebell mailto:[EMAIL PROTECTED]
TC Trust Center for Security http://www.trustcenter.de
in Data Networks GmbH Tel.: +49-40-766 29 3301
Am Werder 1 / 21073 Hamburg / Germany Fax.: +49-40-766 29 577
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
no unlock in bio/b_sock.c
Hallo,
I think in b_sock.c I've stumbled into some error cases in which some locking
isn't undone:
> diff b_sock.c b_sock.fixed.c
250c250,251
< if (ret == NULL) return(NULL);
---
> if (ret == NULL)
> goto err;
352,353c353,357
< if (ret == NULL) return(NULL);
< if (j > 128) return(ret); /* too big to cache */
---
> if (ret == NULL || j > 128) /* not found or too big to
cache */
> {
> CRYPTO_w_unlock(CRYPTO_LOCK_BIO_GETHOSTBYNAME);
> return(ret);
> }
By
Goetz
--
Goetz Babin-Ebell mailto:[EMAIL PROTECTED]
TC Trust Center for Security http://www.trustcenter.de
in Data Networks GmbH Tel.: +49-40-766 29 3301
Am Werder 1 / 21073 Hamburg / Germany Fax.: +49-40-766 29 577
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: US paranoia...
At 11:57 03.06.99 +0200, you wrote: >I've just received the suggestion to make sure the VMS installation >scripts make the executables execute-only. The corresponding on the >Unixly side would be to give the binaries the protection 711 instead >of 755. The reason would be that on a multiuser system, lusers >wouldn't be able to copy the binaries and (in?)advertadly export them >from the US. >I'm looking for more arguments to cover my refusal to make that kind >of change. Do you have any to offer? :-) Write a script that turns the executables readonly. Given the paths of the files this would be simple... By Goetz -- Goetz Babin-Ebell mailto:[EMAIL PROTECTED] TC Trust Center for Security http://www.trustcenter.de in Data Networks GmbH Tel.: +49-40-766 29 3301 Am Werder 1 / 21073 Hamburg / Germany Fax.: +49-40-766 29 577 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: The last word on version numbers?
At 11:35 18.05.99 +0100, you wrote: >Richard Levitte - VMS Whacker wrote: >> ben> OK, I propose that we follow the Apache version numbering scheme, which, >> ben> I quote: >> ben> >> ben> /* Numeric release version identifier: MMNNFFRBB: major minor fix final >> ben> beta >> >> I assume "final" means "release"... > >Yes, 0 for beta, 1 for release. 2-f could be used for something else, >but I can't think what :-) 2 for next beta, 3 for a interim release, 4 for the betas based on 3 ... By Goetz -- Goetz Babin-Ebell mailto:[EMAIL PROTECTED] TC Trust Center for Security http://www.trustcenter.de in Data Networks GmbH Tel.: +49-40-766 29 3301 Am Werder 1 / 21073 Hamburg / Germany Fax.: +49-40-766 29 577 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: #include or #include ?
;:"");
! $cflags.=$outaddms.$out_dir."/OpenSSL" if !$outaddms eq "";
! }
! else
! {
!
$out_dir=(defined($VARS{'OUT'}))?$VARS{'OUT'}:$out_def.($debug?".dbg":
"");
!
$tmp_dir=(defined($VARS{'TMP'}))?$VARS{'TMP'}:$tmp_def.($debug?".dbg":
"");
! }
$inc_dir=(defined($VARS{'INC'}))?$VARS{'INC'}:$inc_def;
$bin_dir=$bin_dir.$o unless ((substr($bin_dir,-1,1) eq $o) ||
($bin_dir eq ''));
$cflags.=" -DNO_IDEA" if $no_idea;
Index: pl/VC-32.pl
===
RCS file: /usr/pcshare/tc//cvsroot/openssl/util/pl/VC-32.pl,v
retrieving revision 1.1.2.1
diff -c -r1.1.2.1 VC-32.pl
*** VC-32.pl1999/04/07 15:09:34 1.1.2.1
- --- VC-32.pl 1999/04/23 13:33:02
***
*** 12,19
# C compiler stuff
$cc='cl';
! $cflags=' /MD /W3 /WX /G5 /Ox /O2 /Ob2 /Gs0 /GF /Gy /nologo -DWIN32
- -DWIN32_LEAN_AND_MEAN -DL_ENDIAN';
! $lflags="/nologo /subsystem:console /machine:I386 /opt:ref";
$mlflags='';
$out_def="out32";
- --- 12,20
# C compiler stuff
$cc='cl';
! #$cflags=' /MD /W3 /WX /G5 /Ox /O2 /Ob2 /Gs0 /GF /Gy /nologo -
DWIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN';
! $cflags=' /W3 /WX /G5 /Ox /O2 /Ob2 /Gs0 /GF /Gy /nologo -DWIN32 -
DWIN32_LEAN_AND_MEAN -DL_ENDIAN';
! $lflags=" /nologo /subsystem:console /machine:I386 /opt:ref";
$mlflags='';
$out_def="out32";
***
*** 22,33
if ($debug)
{
! $cflags=" /MDd /W3 /WX /Zi /Yd /Od /nologo -DWINDOWS -DWIN32 -
D_DEBUG -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DDEBUG";
$lflags.=" /debug";
$mlflags.=' /debug';
}
$cflags .= " -DWINNT" if $NT == 1;
$obj='.obj';
$ofile="/Fo";
- --- 23,37
if ($debug)
{
! # $cflags=" /MDd /W3 /WX /Zi /Yd /Od /nologo -DWINDOWS -DWIN32 -
D_DEBUG -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DDEBUG";
! $cflags=" /W3 /WX /Zi /Yd /Od /nologo -DWINDOWS -DWIN32 -D_DEBUG -
DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DDEBUG";
$lflags.=" /debug";
$mlflags.=' /debug';
}
$cflags .= " -DWINNT" if $NT == 1;
+ $cflags.=" /M".($multithread?"D":"L").($debug?"d":"");
+
$obj='.obj';
$ofile="/Fo";
***
*** 93,99
$tmp_def="tmp32dll";
}
! $cflags.=" /Fd$out_def";
sub do_lib_rule
{
- --- 97,104
$tmp_def="tmp32dll";
}
! $outaddms=" /Fd";
! #$cflags.=" /Fd$out_def";
sub do_lib_rule
{
And here is my do_ms.bat:
perl util\mkfiles.pl >MINFO
rem perl util\mk1mf.pl VC-MSDOS no-sock >ms\msdos.mak
rem perl util\mk1mf.pl VC-W31-32 >ms\w31.mak
rem perl util\mk1mf.pl VC-W31-32 dll >ms\w31dll.mak
perl util\mk1mf.pl VC-WIN32 no-asm >ms\nt.mak
rem perl util\mk1mf.pl VC-WIN32 no-asm dll >ms\ntdll.mak
perl util\mk1mf.pl VC-WIN32 no-asm debug >ms\ntdbg.mak
rem perl util\mk1mf.pl VC-WIN32 no-asm debug dll >ms\ntdbgdll.mak
perl util\mk1mf.pl VC-WIN32 no-asm debugbc >ms\ntdbgbc.mak
rem perl util\mk1mf.pl VC-WIN32 no-asm debugbc dll >ms\ntdbgbcdll.mak
perl util\mk1mf.pl VC-WIN32 no-asm multithread >ms\nt.m.mak
rem perl util\mk1mf.pl VC-WIN32 no-asm multithread dll
>ms\ntdll.m.mak
perl util\mk1mf.pl VC-WIN32 no-asm multithread debug >ms\ntdbg.m.mak
rem perl util\mk1mf.pl VC-WIN32 no-asm multithread debug dll
>ms\ntdbgdll.m.mak
perl util\mk1mf.pl VC-WIN32 no-asm multithread debugbc
>ms\ntdbgbc.m.mak
rem perl util\mk1mf.pl VC-WIN32 no-asm multithread debugbc dll
>ms\ntdbgbcdll.m.mak
perl util\mkdef.pl 16 libeay > ms\libeay16.def
perl util\mkdef.pl 32 libeay > ms\libeay32.def
perl util\mkdef.pl 16 ssleay > ms\ssleay16.def
perl util\mkdef.pl 32 ssleay > ms\ssleay32.def
hope it helps...
By
Goetz
-BEGIN PGP SIGNATURE-
Version: PGP for Personal Privacy 5.0ic
Charset: noconv
iQEVAwUBNyCmQ8ApCwQ4XNEHAQFQDwgAojE8IMm8vBiYnqofbwpoLL1qqAghA1bg
vyitH/wDJKpQhyGMD0pCdiLOL1V/1V3krR7uQ++ak9xyc6269ymDFQC1DcLd5EhI
yBugZG0Shze73kRL/pNdyL1kx0+EUI+GgLBZyGlIB3lTh9t8lMEEG++YjYnTAetN
EwzQA2Jpxq1ynf6ckUyiuAfbMcj2kXDBQCWPqdQCSTrjcd1AESMD1INj2DleOSX1
DspCwQSv55JNhJvEBIftvtkxxs49CvnRqx7xQMkb8MCCgizAiKPxfQciVWHOh7YB
KkId+39foxmpJE5YfEKR5l3U++xdJsEKqc5Lqh5zMOLbYE+GLhRdAg==
=OC5P
-END PGP SIGNATURE-
--
Goetz Babin-Ebell mailto:[EMAIL PROTECTED]
TC Trust Center for Security http://www.trustcenter.de
in Data Networks GmbH Tel.: +49-40-766 29 3301
Am Werder 1 / 21073 Hamburg / Germany Fax.: +49-40-766 29 577
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: solving those data type problems
At 01:01 23.04.99 +0200, you wrote: >>Any comments / additions ? > >The question is what to do about name conflicts with applications. >For example an application might also definite "bool". Drop it ? Since it is only defined on sun/sparc it seems to be a bad idea to define it at all... By Goetz -- Goetz Babin-Ebell mailto:[EMAIL PROTECTED] TC Trust Center for Security http://www.trustcenter.de in Data Networks GmbH Tel.: +49-40-766 29 3301 Am Werder 1 / 21073 Hamburg / Germany Fax.: +49-40-766 29 577 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: solving those data type problems
At 00:26 22.04.99 -0700, you wrote: >Hi, Hallo, >I like the idea, can you include a Win32 platform >in the head file. Whatever we do, we should decide to do it quickly. There seem to be hiding a lot of size dependencies in the code... The file has some disadvantages: 1. There are no processor dependencies (Linux on X86 is different than linux on Alpha,...) 2. Not every processor supports 64 bit So we need somethiong to do: #ifdef HAS_64_BITS ... 64 bit code ... #else ... 32b bit code ... #endif I did a little bit of rewriting: #ifndef ossize_H #define ossize_H /* Typedefs */ typedef unsigned char UInt8; typedef signed char SInt8; typedef unsigned short UInt16; typedef signed shortSInt16; typedef unsigned long UInt32; typedef signed long SInt32; typedef float Float32; typedef short doubleFloat64; typedef unsigned long FourCharCode; typedef FourCharCodeOSType; /* Platform-specific components */ #if __FreeBSD__ /* Defines */ #define HAVE_64BIT_PRINTF 1 #define HAVE_64BIT_PRINTF_AS_LL 0 #define HAVE_64BIT /* Includes */ #include /* Constants */ #define QT_PATH_SEPARATOR '/' /* Typedefs */ typedef signed long longSInt64; typedef unsigned long long UInt64; #elif __MACOS__ /* Defines */ #define HAVE_64BIT_PRINTF 0 #define HAVE_64BIT_PRINTF_AS_LL 0 /* Constants */ #define QT_PATH_SEPARATOR ':' /* Typedefs */ #if 0 typedef signed long longSInt64; typedef unsigned long long UInt64; #endif #elif __MacOSX__ /* Defines */ #define HAVE_64BIT_PRINTF 1 #define HAVE_64BIT_PRINTF_AS_LL 0 #define HAVE_64BIT /* Includes */ #include /* Constants */ #define QT_PATH_SEPARATOR '/' /* Typedefs */ typedef signed long longSInt64; typedef unsigned long long UInt64; #elif defined(sun) && defined(sparc) /* Defines */ #define HAVE_64BIT_PRINTF 1 #define HAVE_64BIT_PRINTF_AS_LL 1 #define HAVE_64BIT /* Includes */ #include #include /* Constants */ #define QT_PATH_SEPARATOR '/' /* Typedefs */ typedef unsigned char bool; #define true1 #define false 0 typedef signed long longSInt64; typedef unsigned long long UInt64; #endif #endif /* ossize_H */ Any comments / additions ? By Goetz -- Goetz Babin-Ebell mailto:[EMAIL PROTECTED] TC Trust Center for Security http://www.trustcenter.de in Data Networks GmbH Tel.: +49-40-766 29 3301 Am Werder 1 / 21073 Hamburg / Germany Fax.: +49-40-766 29 577 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: LP64: blowfish woes
At 17:45 20.04.99 +0200, you wrote: >> I myself would vote for the first alternative unless someone can either: >> >> - confirm that *(unligned long *)((unsigned char *)p+i&~7) generates the >> unwanted unaligned load instruction on Alpha; >> - confirm that the library compiles and works under MS-DOS and the >> development team *cares* about it; > >I am making if #ifdef WIN16 for now. > >We really should define a 32 bit data type globally. Perhaps we should clear sizes of data types. Perhaps something like: typedef char int8; typedef unsigned char uint8; typedef short int16; typedef unsigned short uint16; typedef long int32; typedef unsigned long uint32; #ifdef WHATEVER #define HAS_INT_64 typedef long long int64; typedef unsigned long long uint64; #endif and in the c files: #ifdef HAS_INT_64 code for 64 bits #else code for 32 bits #endif This way we are allways shure about the sizes of the used data But most: We really should use it... By Goetz -- Goetz Babin-Ebell mailto:[EMAIL PROTECTED] TC Trust Center for Security http://www.trustcenter.de in Data Networks GmbH Tel.: +49-40-766 29 3301 Am Werder 1 / 21073 Hamburg / Germany Fax.: +49-40-766 29 577 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
test with M$
-BEGIN PGP SIGNED MESSAGE- Hallo, I'm working on openssl + NT. I have some diffs for the test environment. By Goetz Index: test.bat === RCS file: /usr/pcshare/tc//cvsroot/openssl/ms/test.bat,v retrieving revision 1.1.1.1 diff -r1.1.1.1 test.bat 3c3 < set test=p:\work\ssleay\ms - --- > set test=..\ms 5a6 > set ssleayname=openssl 66c67 < call %test%\testenc ssleay - --- > call %test%\testenc %ssleayname% 70c71 < call %test%\testpem ssleay - --- > call %test%\testpem %ssleayname% 75c76 < ssleay verify -CAfile cert.tmp ..\certs\*.pem - --- > %ssleayname% verify -CAfile cert.tmp ..\certs\*.pem 78c79 < call %test%\testss ssleay - --- > call %test%\testss %ssleayname% Index: testenc.bat === RCS file: /usr/pcshare/tc//cvsroot/openssl/ms/testenc.bat,v retrieving revision 1.1.1.1 diff -r1.1.1.1 testenc.bat 3c3 < path=p:\work\ssleay\ms;%path% - --- > path=..\ms;%path% 5,8c5,8 < set input=p:\work\ssleay\ms\testenc.bat < set tmp1=p:\work\ssleay\ms\cipher.out < set out1=p:\work\ssleay\ms\clear.out < set cmp=perl p:\work\ssleay\ms\cmp.pl - --- > set input=..\ms\testenc.bat > set tmp1=..\ms\cipher.out > set out1=..\ms\clear.out > set cmp=perl ..\ms\cmp.pl 10a11 > Index: testpem.bat === RCS file: /usr/pcshare/tc//cvsroot/openssl/ms/testpem.bat,v retrieving revision 1.1.1.1 diff -r1.1.1.1 testpem.bat 12c12 < call tpem.bat req ..\test\testreq.pem - --- > call tpem.bat req ..\test\testreq.pem -config ..\test\test.cnf 15c15 < call tpem.bat req ..\test\testreq2.pem - --- > call tpem.bat req ..\test\testreq2.pem -config ..\test\test.cnf Index: tpem.bat === RCS file: /usr/pcshare/tc//cvsroot/openssl/ms/tpem.bat,v retrieving revision 1.1.1.1 diff -r1.1.1.1 tpem.bat 3,4c3,4 < echo test %1 %2 < %ssleay% %1 -in %2 -out %tmp1% - --- > echo test %1 %2 %3 %4 > %ssleay% %1 -in %2 -out %tmp1% %3 %4 -BEGIN PGP SIGNATURE- Version: PGP for Personal Privacy 5.0ic Charset: noconv iQEVAwUBNu54IsApCwQ4XNEHAQFgWwf7BsJ1HdV6B0IZW3kAEzypvG1gGls2K7d5 JMSlY5UuKvMXg0hE1UcJiEwa9Oa0TOa3Kxdc+hmm/FSts8poOO5vJ9+/iX9UFoIj iTdOu8dWlWVzyF5k60RGCt/SC/x4nqr0O5QmxbcOFvc/7srlmvQEJzSkuS+KH3gC pU2rQftSPGmJKKdwS8DYPplO+a5X2TLMM1tEjfR52pV4LxKujWDRlXQMBQ8kfQSq hxSuKH4RP3oO/nrB50f3eDMpoyyl3H0T0xlh+AJbSt0cxZlaR+UrOQkjsXPnLbI2 FfZVUJw5/oQqixXWX4U2NE//Tcb0CSKewYvFF1LVwk6ifGMigRIdhA== =zWEO -END PGP SIGNATURE- -- Goetz Babin-Ebell mailto:[EMAIL PROTECTED] TC Trust Center for Security http://www.trustcenter.de in Data Networks GmbH Tel.: +49-40-766 29 3301 Am Werder 1 / 21073 Hamburg / Germany Fax.: +49-40-766 29 577 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
