Re: Open SSL errors increase in Linux compared with Solaris
I'm no expert, but doesn't connection reset by peer mean that the other side of the connection is hanging up? So maybe the error is with whatever you are talking to? Andrew On Wed, Jan 22, 2014 at 11:24:07AM +, Thirumal, Karthikeyan wrote: Dave, Thanks for your response. Please find the response for your queries below. 1. Yes, we are trying to upgrade it. But before that we are trying it in our testbeds and all possible options for the fix. 2. The errno is 104 and it is Connection reset by peer 3. Can you help us with the above errno and our next step will be to take the tcpdump / network trace. 4. We will check on the iptables and the setup. Thanks Regards Karthikeyan Thirumal ADD-Web-NXP-India, Application Development Delivery iNautix Technologies India Private Limited, an affiliate of Pershing LLC, a subsidiary of The Bank of New York Mellon Corporation http://www.inautix.co.in VOIP: 612-15112 Email: kthiru...@inautix.co.inmailto:kthiru...@inautix.co.in Information Classification: Internal Use Only From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Tuesday, January 07, 2014 4:08 AM To: openssl-users@openssl.org Subject: RE: Open SSL errors increase in Linux compared with Solaris 1: 0.9.8a is VERY old, and contains quite a few security flaws that have been fixed since. Even if your application(s) can't accept the fairly small changes needed to move to 1.0.0 or better 1.0.1, try at least to move up to or near 0.9.8y. 2: whenever you get ERROR_SYSCALL you should always look at errno on Unix (or [WSA}GetError() on Windows). What is it? 3: there are various TCP or (mostly) IP level errors that can cause a TCP connection initiation (also called handshake, but not to be confused with the SSL/TLS handshake) to fail. It wouldn't surprise me if the Linux stack returns errors to the application process in some cases that Solaris does not - or vice versa. If the errno value isn't specific enough, get a network trace on the Linux box (with tcpdump) or a machine very close: I like wireshark on Windows, also available for MacOSX, and usually one of those either exists or can be temporarily put on the desired network segment. 4: it is also possible there are actually more errors. Are you sure the Linux box's network adapter and cable are solidly good? Do any other applications (especially inbound) on that box get errors? Linux or at least most versions have iptables which functions as an IP firewall - is yours set in a way that interferes with some (or even all?) desired TCP connections? From: owner-openssl-us...@openssl.orgmailto:owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Arjunan, Karthikeyan Sent: Thursday, January 02, 2014 06:14 To: openssl-users@openssl.orgmailto:openssl-users@openssl.org Cc: Arjunan, Karthikeyan Subject: Open SSL errors increase in Linux compared with Solaris Hi, We have migrated from openssl-0.9.8a Solaris to Linux version. We find that there is a drastic increase in the SSL_ERROR_SYSCALL in Linux openssl version compared to Solaris. I am using SSL_accept which returns a negative value . The return code for SSL_get_error is 5. Please advise how to reduce the increase in error . Thanks, Karthikeyan Arjunan ** This message and any files or attachments sent with this message contain confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute, copy or use any part of this email. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return Email. Email transmission cannot be guaranteed to be secure or error-free as information can be intercepted, corrupted, lost, destroyed, late, incomplete or may contain viruses. The sender, therefore, does not accept liability for any errors or omissions in the contents of this message, which arise as a result of email transmission. ** ** This message and any files or attachments sent with this message contain confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute, copy or use any part of this email. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return Email. Email transmission cannot be guaranteed to be secure or error-free as information can be intercepted, corrupted, lost, destroyed, late, incomplete or may contain viruses. The sender, therefore,
Re: Verisign Problem with smtp tls
i am not following this in any detail, but if you look at the certificate you included in your original email it expired in 2008. just look at it with openssl -text -in some file sorry if i'm jumping into something i've misunderstood, andrew On Fri, Dec 27, 2013 at 01:47:47PM -0600, Bobber wrote: On 12/27/2013 01:29 PM, Viktor Dukhovni wrote: On Fri, Dec 27, 2013 at 12:59:11PM -0600, Bobber wrote: I recently upgraded my companies' mail server to 64 Debian Wheezy. I am using the Openssl package which is version 1.0.1e-2. I am having problems when trying to send a message to one of our business partners. The SMTP session appears to shut down and it appears that my server is rejecting their certificate. Here is the openssl command I am giving to diagnose the problem and it's output. Can anyone suggest a solution? It appears to me that I may be lacking an intermediary certificate. How do I fix this if this is the case? openssl s_client -CApath /etc/ssl/certs/ -crlf -starttls smtp -connect mail.thelawrencegroup.com:25 The posttls-finger(1) utility, included with Postfix 2.11 snapshot source code, does a much better job of mail server TLS diagnostics. Their certificate is expired. Your MTA really ought to log the error reason. Consider a better MTA! :-) I don't see anywhere that it says expired other than this utility. How can I verify that it is really expired? These guys do business with lots of other people but have not noticed anything except with us. The openssl error code 20 indicates an improper intermediate CA from what I can find. Also using this site indicates no problem: http://www.checktls.com/testreceiver.html Is there another way to verify the expiration? $ posttls-finger [mail.thelawrencegroup.com] posttls-finger: Connected to mail.thelawrencegroup.com[206.16.127.29]:25 posttls-finger: 220 mail.thelawrencegroup.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.4675 ready at Fri, 27 Dec 2013 13:13:52 -0600 posttls-finger: EHLO amnesiac.example posttls-finger: 250-mail.thelawrencegroup.com Hello [192.0.2.1] posttls-finger: 250-TURN posttls-finger: 250-SIZE posttls-finger: 250-ETRN posttls-finger: 250-PIPELINING posttls-finger: 250-DSN posttls-finger: 250-ENHANCEDSTATUSCODES posttls-finger: 250-8bitmime posttls-finger: 250-BINARYMIME posttls-finger: 250-CHUNKING posttls-finger: 250-VRFY posttls-finger: 250-TLS posttls-finger: 250-STARTTLS posttls-finger: 250-X-EXPS GSSAPI NTLM LOGIN posttls-finger: 250-X-EXPS=LOGIN posttls-finger: 250-AUTH GSSAPI NTLM LOGIN posttls-finger: 250-AUTH=LOGIN posttls-finger: 250-X-LINK2STATE posttls-finger: 250-XEXCH50 posttls-finger: 250 OK posttls-finger: STARTTLS posttls-finger: 220 2.0.0 SMTP server ready posttls-finger: mail.thelawrencegroup.com[206.16.127.29]:25 Matched CommonName mail.thelawrencegroup.com posttls-finger: server certificate verification failed for mail.thelawrencegroup.com[206.16.127.29]:25: certificate has expired posttls-finger: mail.thelawrencegroup.com[206.16.127.29]:25: subject_CN=mail.thelawrencegroup.com, issuer_CN=VeriSign Class 3 Secure Server CA, fingerprint=58:83:F8:69:1B:45:53:BA:21:36:19:01:B4:C9:7A:A9:54:62:79:57, pkey_fingerprint=84:43:0D:55:D9:F8:D3:C5:59:D3:9D:33:42:B3:2E:A4:9B:FE:96:4D posttls-finger: Untrusted TLS connection established to mail.thelawrencegroup.com[206.16.127.29]:25: unknown with cipher RC4-MD5 (128/128 bits) posttls-finger: EHLO amnesiac.example posttls-finger: 250-mail.thelawrencegroup.com Hello [192.0.2.1] posttls-finger: 250-TURN posttls-finger: 250-SIZE posttls-finger: 250-ETRN posttls-finger: 250-PIPELINING posttls-finger: 250-DSN posttls-finger: 250-ENHANCEDSTATUSCODES posttls-finger: 250-8bitmime posttls-finger: 250-BINARYMIME posttls-finger: 250-CHUNKING posttls-finger: 250-VRFY posttls-finger: 250-X-EXPS GSSAPI NTLM LOGIN posttls-finger: 250-X-EXPS=LOGIN posttls-finger: 250-AUTH GSSAPI NTLM LOGIN posttls-finger: 250-AUTH=LOGIN posttls-finger: 250-X-LINK2STATE posttls-finger: 250-XEXCH50 posttls-finger: 250 OK posttls-finger: QUIT posttls-finger: 221 2.0.0 mail.thelawrencegroup.com Service closing transmission channel -- Bob Wooldridge bob...@kc0dxf.net Blog: http://kc0dxf.net/blog/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project
Re: ASN1_item_sign from 1.0.0k to 1.0.1
Argh, OK, the attribute is called sign. So it's correct, I just had the wrong name in my notes. Andrew On Tue, Dec 17, 2013 at 03:51:04PM -0300, Andrew Cooke wrote: I should have also said that this is called by X509_REQ_sign. So, in short, the EVP_MD.digest atrtibute is not used to do signing when passed to X509_REQ_sign. You know, it's only writing that the word digest has jumped out at me. Is that even the right place for doing signing? Or is it meant o just calculate a digest (hash)? So that confusion may not be helping things. Sorry. Andrew On Tue, Dec 17, 2013 at 03:45:46PM -0300, Andrew Cooke wrote: Hi, I realise the 1.0.0 to 1.0.1 transition happened some time ago, but it only hit Centos recently (with the 6.5 release). Some of our code broke, and while I suspect the problem is too low-level / detailed for anyone to say anything useful, I thought I better ask, just in case... (if you can help, thanks in advance). What the code is doing is intercepting signing during the creation of an X509 request. It does this by creating an EVP_MD via EVP_dss1 and then assigning the digest attribute (a function pointer). In 1.0.0, this was then somehow called to do the signing, at which point our library leapt into action and delegated the work to a hardware token. In 1.0.1, however, the digest attribute is not being called. Instead some default routine for signatures is used, which segfaults because there is no private key (the segfault is in the multiplication of large integers when a NULL value - the key - is dereferenced). In both cases, it seems that some kind of context object is constructed, which is then used in the signing. What seems to differ is how that is constructed (and so what procedure is called to do the signing). If I use gdb then the code for the two versions diverges when ASN1_item_sign (in crypto/asn1/a_sign.c) is called: In 1.0.0k this is a fairly long routine that creates the context, and then calls EVP_SignInit_ex, EVP_SignUpdate and EVP_SignFinal. In 1.1.1 that is replaced with EVP_DigestSignInit (in crypto/evp/m_sigver.c) and then ASN1_item_sign_ctx. It seems like the logic in those two paths, constructing the context, is different (the code certainly looks different). I haven't yet worked through the details, but if the above sounds familiar to anyone and there's an obvious fix, I'd love to know (this is very old code that I didn't write - if I were working on it now, I would probably use an engine, but what I describe is what I have to work with). Thanks, Andrew PS Is there any way to see the patches that were applied? Perhaps reading the relevant patch would make more sense... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ASN1_item_sign from 1.0.0k to 1.0.1
Yes, that's how my more recent engine-based code works. Maybe the best thing is to merge those two code bases and get rid of this old stuff. Thanks, Andrew On Tue, Dec 17, 2013 at 07:56:46PM +0100, Dr. Stephen Henson wrote: On Tue, Dec 17, 2013, andrew cooke wrote: I should have also said that this is called by X509_REQ_sign. So, in short, the EVP_MD.digest atrtibute is not used to do signing when passed to X509_REQ_sign. You know, it's only writing that the word digest has jumped out at me. Is that even the right place for doing signing? Or is it meant o just calculate a digest (hash)? So that confusion may not be helping things. Sorry. The usual way to intercept public key operations is by writing an appopriate ALGORITHM_METHOD for your implementation. For example in DSA_METHOD you can write a function that takes the raw digest to sign with as input and outputs the signature. This is normally part of an ENGINE. That technique will work with all versions of OpenSSL. There are examples in the engines directory. One makes use of CryptoAPI under Windows to redirect RSA and DSA signing operations, see e_capi.c. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ASN1_item_sign from 1.0.0k to 1.0.1
I should have also said that this is called by X509_REQ_sign. So, in short, the EVP_MD.digest atrtibute is not used to do signing when passed to X509_REQ_sign. You know, it's only writing that the word digest has jumped out at me. Is that even the right place for doing signing? Or is it meant o just calculate a digest (hash)? So that confusion may not be helping things. Sorry. Andrew On Tue, Dec 17, 2013 at 03:45:46PM -0300, Andrew Cooke wrote: Hi, I realise the 1.0.0 to 1.0.1 transition happened some time ago, but it only hit Centos recently (with the 6.5 release). Some of our code broke, and while I suspect the problem is too low-level / detailed for anyone to say anything useful, I thought I better ask, just in case... (if you can help, thanks in advance). What the code is doing is intercepting signing during the creation of an X509 request. It does this by creating an EVP_MD via EVP_dss1 and then assigning the digest attribute (a function pointer). In 1.0.0, this was then somehow called to do the signing, at which point our library leapt into action and delegated the work to a hardware token. In 1.0.1, however, the digest attribute is not being called. Instead some default routine for signatures is used, which segfaults because there is no private key (the segfault is in the multiplication of large integers when a NULL value - the key - is dereferenced). In both cases, it seems that some kind of context object is constructed, which is then used in the signing. What seems to differ is how that is constructed (and so what procedure is called to do the signing). If I use gdb then the code for the two versions diverges when ASN1_item_sign (in crypto/asn1/a_sign.c) is called: In 1.0.0k this is a fairly long routine that creates the context, and then calls EVP_SignInit_ex, EVP_SignUpdate and EVP_SignFinal. In 1.1.1 that is replaced with EVP_DigestSignInit (in crypto/evp/m_sigver.c) and then ASN1_item_sign_ctx. It seems like the logic in those two paths, constructing the context, is different (the code certainly looks different). I haven't yet worked through the details, but if the above sounds familiar to anyone and there's an obvious fix, I'd love to know (this is very old code that I didn't write - if I were working on it now, I would probably use an engine, but what I describe is what I have to work with). Thanks, Andrew PS Is there any way to see the patches that were applied? Perhaps reading the relevant patch would make more sense... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
ASN1_item_sign from 1.0.0k to 1.0.1
Hi, I realise the 1.0.0 to 1.0.1 transition happened some time ago, but it only hit Centos recently (with the 6.5 release). Some of our code broke, and while I suspect the problem is too low-level / detailed for anyone to say anything useful, I thought I better ask, just in case... (if you can help, thanks in advance). What the code is doing is intercepting signing during the creation of an X509 request. It does this by creating an EVP_MD via EVP_dss1 and then assigning the digest attribute (a function pointer). In 1.0.0, this was then somehow called to do the signing, at which point our library leapt into action and delegated the work to a hardware token. In 1.0.1, however, the digest attribute is not being called. Instead some default routine for signatures is used, which segfaults because there is no private key (the segfault is in the multiplication of large integers when a NULL value - the key - is dereferenced). In both cases, it seems that some kind of context object is constructed, which is then used in the signing. What seems to differ is how that is constructed (and so what procedure is called to do the signing). If I use gdb then the code for the two versions diverges when ASN1_item_sign (in crypto/asn1/a_sign.c) is called: In 1.0.0k this is a fairly long routine that creates the context, and then calls EVP_SignInit_ex, EVP_SignUpdate and EVP_SignFinal. In 1.1.1 that is replaced with EVP_DigestSignInit (in crypto/evp/m_sigver.c) and then ASN1_item_sign_ctx. It seems like the logic in those two paths, constructing the context, is different (the code certainly looks different). I haven't yet worked through the details, but if the above sounds familiar to anyone and there's an obvious fix, I'd love to know (this is very old code that I didn't write - if I were working on it now, I would probably use an engine, but what I describe is what I have to work with). Thanks, Andrew PS Is there any way to see the patches that were applied? Perhaps reading the relevant patch would make more sense... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Somewhat conflicting configuration and strange behaviour
it dpends how many characters differ when sorted. in this case: ECDHE-ECDSA-DES-CBC3-SHA - 3AABDDDHHSSS * *** ** ECDHE-ECDSA-3DES-EDE-SHA - 3AACCEEHHSSS you can see (marked by *) that 6 characters don't match. now 6 is a triangular number, but the length of the entire cipher suite is 24, which isn't triangule (the closest is 21). so they're only going to inter-operate on tuesdays. andrew On Fri, Dec 13, 2013 at 07:30:02PM +0100, Walter H. wrote: On 12.12.2013 14:16, Erwann Abalea wrote: It's not strange. You removed the RSA-* from client side, the result is that the server can't match anything in common between what the client proposed and what the server accepts. The error you get has been sent by the server. The server is capable of ciphers DHE-* and others; the list is quite longer than the avaiable ciphers of the client ..., so I think this is quite strange ... openssl ciphers -V shows e.g. ECDHE-ECDSA-DES-CBC3-SHA the site https://cc.dcsec.uni-hannover.de/ shows this: ECDHE-ECDSA-3DES-EDE-SHA are these the same cipher suites but two confusing names? Walter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Somewhat conflicting configuration and strange behaviour
sorry, that was a bad joke i now regret sending. andrew On Fri, Dec 13, 2013 at 04:01:23PM -0300, Andrew Cooke wrote: it dpends how many characters differ when sorted. in this case: ECDHE-ECDSA-DES-CBC3-SHA - 3AABDDDHHSSS * *** ** ECDHE-ECDSA-3DES-EDE-SHA - 3AACCEEHHSSS you can see (marked by *) that 6 characters don't match. now 6 is a triangular number, but the length of the entire cipher suite is 24, which isn't triangule (the closest is 21). so they're only going to inter-operate on tuesdays. andrew On Fri, Dec 13, 2013 at 07:30:02PM +0100, Walter H. wrote: On 12.12.2013 14:16, Erwann Abalea wrote: It's not strange. You removed the RSA-* from client side, the result is that the server can't match anything in common between what the client proposed and what the server accepts. The error you get has been sent by the server. The server is capable of ciphers DHE-* and others; the list is quite longer than the avaiable ciphers of the client ..., so I think this is quite strange ... openssl ciphers -V shows e.g. ECDHE-ECDSA-DES-CBC3-SHA the site https://cc.dcsec.uni-hannover.de/ shows this: ECDHE-ECDSA-3DES-EDE-SHA are these the same cipher suites but two confusing names? Walter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Somewhat conflicting configuration and strange behaviour
well, i realised i couldn't answer the question seriously... what is ECDHE-ECDSA-3DES-EDE-SHA ? the only reference i can find on the web is to google chrome and firefox accepting it (a grep of openssl 1.0.1e fails to find it). does any server actually provide it? if so, what mode does it use (EDE is saying something about DES - how to build 3DES from DES - rather than giving a mode, isn't it?)? andrew On Fri, Dec 13, 2013 at 08:51:44PM +0100, Erwann Abalea wrote: Don't regret it, it wasn't that bad ;) -- Erwann ABALEA Le 13/12/2013 20:39, andrew cooke a écrit : sorry, that was a bad joke i now regret sending. andrew On Fri, Dec 13, 2013 at 04:01:23PM -0300, Andrew Cooke wrote: it dpends how many characters differ when sorted. in this case: ECDHE-ECDSA-DES-CBC3-SHA - 3AABDDDHHSSS * *** ** ECDHE-ECDSA-3DES-EDE-SHA - 3AACCEEHHSSS you can see (marked by *) that 6 characters don't match. now 6 is a triangular number, but the length of the entire cipher suite is 24, which isn't triangule (the closest is 21). so they're only going to inter-operate on tuesdays. andrew On Fri, Dec 13, 2013 at 07:30:02PM +0100, Walter H. wrote: On 12.12.2013 14:16, Erwann Abalea wrote: It's not strange. You removed the RSA-* from client side, the result is that the server can't match anything in common between what the client proposed and what the server accepts. The error you get has been sent by the server. The server is capable of ciphers DHE-* and others; the list is quite longer than the avaiable ciphers of the client ..., so I think this is quite strange ... openssl ciphers -V shows e.g. ECDHE-ECDSA-DES-CBC3-SHA the site https://cc.dcsec.uni-hannover.de/ shows this: ECDHE-ECDSA-3DES-EDE-SHA are these the same cipher suites but two confusing names? Walter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Somewhat conflicting configuration and strange behaviour
well, not really, because in practice the name has to match, so you are stuck (as the earlier answer says). i guess the answer is somewhere in the nss code... andrew On Fri, Dec 13, 2013 at 10:04:52PM +0100, Walter H. wrote: On 13.12.2013 21:16, andrew cooke wrote: well, i realised i couldn't answer the question seriously... what is ECDHE-ECDSA-3DES-EDE-SHA ? the only reference i can find on the web is to google chrome and firefox accepting it (a grep of openssl 1.0.1e fails to find it). does any server actually provide it? if so, what mode does it use (EDE is saying something about DES - how to build 3DES from DES - rather than giving a mode, isn't it?)? andrew exact this is my problem - I need a ciphersuite from the OpenSSL list, that matches one of the FF list and doesn't make use of RSA for key exchange ... Thanks, Walter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: private key in hardware ssl
You can write your own engine that calls the routines you have. You can also write a shim library that wraps the library you have and presents it as PKCS#11. Then you can use a PKCS#11 engine. The first approach is easiest but the second gives you more options down the line (you don't need to implement the entire interface, just enough to get things working...) What is your hardware? I've done the above with Spyrus Links II (I can't remember the details, but I think the PKCS#11 wrapper was actually for openssh; for openSSL I used the first approach). It's easiest if you start with an existing engine as a template. Andrew On Tue, Nov 05, 2013 at 06:33:55PM +0200, 133mmx runner wrote: Hi All, I am using openssl library. I have succeded establishing ssl connection with pfx files. But we will keep private key in hardware. Our hardware has no engine library or pkcs#11 library. There are sign and encryption functions that i can use. Is there a way in openssl to manipulate RSA operation. Thanks in advance. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Curves from http://safecurves.cr.yp.to/
Hi, I'm doing some work for a client who has a requirement to use ECDSA. However, I am having a hard time working out which curves I should enable. This site - http://safecurves.cr.yp.to/ - seems to be the current state-of-the-art on which curves to use. It recommends five: Curve2213, Curve1174, Curve25519, Curve383187 and Curve3617. But I don't see any of those in OpenSSL 1.0.1e: openssl ecparam -list_curves | egrep '(2213|1174|25519|38317|3617)' Am I overlooking something? Will more curves be added soon? Is there some way to specify a raw curve? Thanks, Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Differences on output between OpenSSL and CryptoTool
why not use -nopad when calling openssl enc, and add the zero padding yourself? echo -n '' topsecret.txt head -c8 /dev/zero topsecret.txt xxd topsecret.txt 000: 6161 6161 6161 6161 openssl enc -des-cbc -K 0101010101010101 -iv \ -nosalt -in topsecret.txt -nopad | xxd 000: f90a ba97 690c af10 6161 6161 6161 6161 i... which matches your other tool, i think? :o) but something seems very wrong. your encrypted result contains your plaintext. i feel very stupid, but i do not undersand why. that ciphertext should be the padding xored with the previous block, encrypted. what am i missing? andrew On Tue, Oct 29, 2013 at 03:54:50PM +0100, Luis Rocha wrote: Ok so I read more about it and for DES a block consists of 64 bit = 16 hex characters The X.923 padding attaches to a complete message block another block of zeros: A = 00 00 00 00 00 00 00 00 so I created a text file with 64 bits (16 hex characters) $echo -n '' topsecret.txt $xxd topsecret.txt 6161 6161 6161 6161 Then encrypted it with a weak key and iv = 0. openssl enc -des-cbc -K 0101010101010101 -iv -nosalt -in topsecret.txt | xxd f90a ba97 690c af10 ea3b c77a e91d efe2 Made the same exercise in the tool: In the tool (GUI) using DES CBC mode with the same key '0101010101010101' the output is: F90A BA97 690C AF10 6161 6161 6161 6161 Much better now...the first block matchesso I think the differences are due to the padding. Does it sound right? On Tue, Oct 29, 2013 at 3:18 PM, Luis Rocha luiscro...@gmail.com wrote: Thank you Victor! In the cryptool I'm only able to introduce the 8 bytes key and not the IV. The documentation from CrypTool says CBC mode is used with zero initialization vector and X.923 padding. user@debian:~$ openssl enc -des-cbc -K 0101010101010101 -iv -nosalt -in topsecret.txt | xxd 8a08 216b 7f88 7ec4 In the tool (GUI) using DES CBC mode with the same key '0101010101010101' the output is '255B DF6C 2E64 E96A' but I didnt figure out what they mean by zero initialization vector and X.923 padding. btw: the tool is quite amazing for learning crypto stuff https://www.cryptool.org/images/ct1/presentations/CrypToolPresentation-en.pdf Best, Luis On Tue, Oct 29, 2013 at 12:40 AM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Mon, Oct 28, 2013 at 11:48:22PM +0100, Luis Rocha wrote: + Filename topsecret.txt which only contains the character 'a' + Encrypt it with DES using CBC mode with key and iv = 0 produces the result '32ea a0fa 4f77 fb92' user@debian:~$ openssl enc -des-cbc -K 0 -iv 0 -nosalt -in topsecret.txt 000: 32ea a0fa 4f77 fb92 2...Ow.. Note, 0 is not a valid DES key, nor a valid DES iv. To be a valid key it needs to be 8 bytes with the right parity bits. So I don't believe that you can expect well-defined behaviour with the specified inputs. If I use the cryptool 1.4.31 to do the same exercise the result is '0C29 5D71 8258 D464' What does same mean? What is the syntax for key/iv in that utility? I also noticed that openssl generates the same output for different modes of des e.g. user@debian:~$ openssl enc -des-ecb -K 0 -iv 0 -nosalt -in topsecret.txt | xxd For a single block with a zero IV, the output of ECB and CBC is naturally the same. If you use a non-zero IV, you'll observe that CBC and ECB produce different results. While if I do the same in Cryptool the output for the ECB mode is: '841B D8A4 2931 FCF5' Which shows that this tool is not in fact using a zero IV, likely because your input is invalid. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Strange loading issue(?) with libcrypto
Well, for the record, the hardware (PKCS11) library we were using wraps and
exposes some ancient version of OpenSSL. And was being linked first, blocking
libcrypto.
Andrew
On Tue, Mar 26, 2013 at 12:17:39PM -0300, Andrew Cooke wrote:
I admit that this is probably not an OpenSSL-specific issue, but perhaps some
experienced C dev here has seen this before and would be kind enough to
explain? Apologies in advance, but (as I hope I can show) it's very odd...
So, I have a dynamic engine. One that works with openssl from the command
line like this:
$ openssl engine dynamic -pre
SO_PATH:/usr/lib/openssl/engines/libengine_spyrus.so -pre ID:spyrus -pre
LOAD
-pre MODULE_PATH:/usr/local/ssi_extra/lib/libssi_spyrus.so
(dynamic) Dynamic engine loading support
[Success]: SO_PATH:/usr/lib/openssl/engines/libengine_spyrus.so
[Success]: ID:spyrus
[Success]: LOAD
[Success]: MODULE_PATH:/usr/local/ssi_extra/lib/libssi_spyrus.so
Loaded: (spyrus) SPYRUS LYNKS Series II USB card
But when I do the same from within a C program, using ENGINE_ctrl_cmd_string,
I see:
$ /usr/local/ssi/bin/token_cert -f ./skm_spyrus.par -vvvUsing param file
./skm_spyrus.par
Using key names testAwaitingCertDSA_PrivateKey,
testAwaitingCertDSA_PublicKey
can't load dynamic engine params
6914:error:260B6091:lib(38):func(182):reason(145):eng_dyn.c:399:
WARNING: failed to create certificate request!
Where that error is from the LOAD command.
BUT if I specify libcrypto explicitly then it LOADs (the failure below is from
later in the code because the HW is missing):
$ LD_PRELOAD=/usr/lib/libcrypto.so.10 /usr/local/ssi/bin/token_cert -f
./skm_spyrus.par -vvvUsing param file ./skm_spyrus.par
Using key names testAwaitingCertDSA_PrivateKey,
testAwaitingCertDSA_PublicKey
opening SPYRUS device 0 failed. No Spyrus device found
can't init dynamic engine
WARNING: failed to create certificate request!
Note that the error above is different and occurs after the engine was loaded.
YET ldd shows that the library being used is /usr/lib/libcrypto.so.10:
$ ldd /usr/local/ssi/bin/token_cert | grep crypto
libcrypto.so.10 = /usr/lib/libcrypto.so.10 (0x0489)
libk5crypto.so.3 = /lib/libk5crypto.so.3 (0x001fc000)
so LD_PRELOAD should make no difference, right?
A similar problem occurs inside gdb. Without LD_PRELOAD I am unable to step
into ENGINE_ctrl_cmd_string - it simply returns success on the first few
calls, before failing on LOAD. But if I use LD_PRELOAD then I can step into
libcrypto source! WHY?!?!?? In both cases the gdb command info share shows
that the /usr/lib/libcrypto.so.10 is loaded!
I admit I do have a second openssl installed in /usr/local. And if I
explicitly select that with LD_PRELOAD it also works. And this basic problem
(although not all the details) was happening before I installed that second
copy (as part of debugging). SO th eproblem doe snot seem to be a confusion
between the two libraries, since either works when explicitly selected.
There is also a system 0.9.8 openssl install, but the above is the 1.0.0
version:
$ sudo find / -name libcrypto.so* -exec ls -l \{} \;
lrwxrwxrwx. 1 root root 18 Mar 18 17:42 /usr/lib/libcrypto.so -
libcrypto.so.1.0.0
-rwxr-xr-x. 1 root root 1358276 Apr 24 2012 /usr/lib/libcrypto.so.0.9.8e
lrwxrwxrwx. 1 root root 24 Mar 19 10:14
/usr/lib/debug/usr/lib/libcrypto.so.debug - libcrypto.so.1.0.0.debug
lrwxrwxrwx. 1 root root 24 Mar 19 10:14
/usr/lib/debug/usr/lib/libcrypto.so.10.debug - libcrypto.so.1.0.0.debug
-r--r--r--. 1 root root 4329128 Mar 4 19:17
/usr/lib/debug/usr/lib/libcrypto.so.1.0.0.debug
lrwxrwxrwx. 1 root root 19 Mar 18 17:15 /usr/lib/libcrypto.so.6 -
libcrypto.so.0.9.8e
lrwxrwxrwx. 1 root root 18 Mar 18 17:41 /usr/lib/libcrypto.so.10 -
libcrypto.so.1.0.0
-rwxr-xr-x. 1 root root 1610028 Mar 4 19:17 /usr/lib/libcrypto.so.1.0.0
lrwxrwxrwx. 1 root root 18 Mar 25 15:47 /usr/local/ssl/lib/libcrypto.so -
libcrypto.so.1.0.0
lrwxrwxrwx. 1 root root 12 Mar 25 11:49 /usr/local/ssl/lib/libcrypto.so.10
-
libcrypto.so
-r-xr-xr-x. 1 root root 4802798 Mar 25 15:47
/usr/local/ssl/lib/libcrypto.so.1.0.0
lrwxrwxrwx. 1 ssi ssi 18 Mar 25 15:46 /home/ssi/openssl-1.0.0k/libcrypto.so
- libcrypto.so.1.0.0
-rwxrwxr-x. 1 ssi ssi 4802798 Mar 25 15:46
/home/ssi/openssl-1.0.0k/libcrypto.so.1.0.0
This is all on CentoOS 6 in a VM (installed as 6.2 but it seems to update to
6.3 via a 6 repo). The debug package for openssl 1.0.0 is also installed.
The programs in question are built by a large tree of automake scripts (large
package), which seem to be using dynamic (not static) libraries.
I hope the above is clear. Any suggestions as to what might be causing the
program to fail without LD_PRELOAD would be much appreciated.
Thanks,
Andrew
Strange loading issue(?) with libcrypto
I admit that this is probably not an OpenSSL-specific issue, but perhaps some
experienced C dev here has seen this before and would be kind enough to
explain? Apologies in advance, but (as I hope I can show) it's very odd...
So, I have a dynamic engine. One that works with openssl from the command
line like this:
$ openssl engine dynamic -pre
SO_PATH:/usr/lib/openssl/engines/libengine_spyrus.so -pre ID:spyrus -pre LOAD
-pre MODULE_PATH:/usr/local/ssi_extra/lib/libssi_spyrus.so
(dynamic) Dynamic engine loading support
[Success]: SO_PATH:/usr/lib/openssl/engines/libengine_spyrus.so
[Success]: ID:spyrus
[Success]: LOAD
[Success]: MODULE_PATH:/usr/local/ssi_extra/lib/libssi_spyrus.so
Loaded: (spyrus) SPYRUS LYNKS Series II USB card
But when I do the same from within a C program, using ENGINE_ctrl_cmd_string,
I see:
$ /usr/local/ssi/bin/token_cert -f ./skm_spyrus.par -vvvUsing param file
./skm_spyrus.par
Using key names testAwaitingCertDSA_PrivateKey, testAwaitingCertDSA_PublicKey
can't load dynamic engine params
6914:error:260B6091:lib(38):func(182):reason(145):eng_dyn.c:399:
WARNING: failed to create certificate request!
Where that error is from the LOAD command.
BUT if I specify libcrypto explicitly then it LOADs (the failure below is from
later in the code because the HW is missing):
$ LD_PRELOAD=/usr/lib/libcrypto.so.10 /usr/local/ssi/bin/token_cert -f
./skm_spyrus.par -vvvUsing param file ./skm_spyrus.par
Using key names testAwaitingCertDSA_PrivateKey, testAwaitingCertDSA_PublicKey
opening SPYRUS device 0 failed. No Spyrus device found
can't init dynamic engine
WARNING: failed to create certificate request!
Note that the error above is different and occurs after the engine was loaded.
YET ldd shows that the library being used is /usr/lib/libcrypto.so.10:
$ ldd /usr/local/ssi/bin/token_cert | grep crypto
libcrypto.so.10 = /usr/lib/libcrypto.so.10 (0x0489)
libk5crypto.so.3 = /lib/libk5crypto.so.3 (0x001fc000)
so LD_PRELOAD should make no difference, right?
A similar problem occurs inside gdb. Without LD_PRELOAD I am unable to step
into ENGINE_ctrl_cmd_string - it simply returns success on the first few
calls, before failing on LOAD. But if I use LD_PRELOAD then I can step into
libcrypto source! WHY?!?!?? In both cases the gdb command info share shows
that the /usr/lib/libcrypto.so.10 is loaded!
I admit I do have a second openssl installed in /usr/local. And if I
explicitly select that with LD_PRELOAD it also works. And this basic problem
(although not all the details) was happening before I installed that second
copy (as part of debugging). SO th eproblem doe snot seem to be a confusion
between the two libraries, since either works when explicitly selected.
There is also a system 0.9.8 openssl install, but the above is the 1.0.0
version:
$ sudo find / -name libcrypto.so* -exec ls -l \{} \;
lrwxrwxrwx. 1 root root 18 Mar 18 17:42 /usr/lib/libcrypto.so -
libcrypto.so.1.0.0
-rwxr-xr-x. 1 root root 1358276 Apr 24 2012 /usr/lib/libcrypto.so.0.9.8e
lrwxrwxrwx. 1 root root 24 Mar 19 10:14
/usr/lib/debug/usr/lib/libcrypto.so.debug - libcrypto.so.1.0.0.debug
lrwxrwxrwx. 1 root root 24 Mar 19 10:14
/usr/lib/debug/usr/lib/libcrypto.so.10.debug - libcrypto.so.1.0.0.debug
-r--r--r--. 1 root root 4329128 Mar 4 19:17
/usr/lib/debug/usr/lib/libcrypto.so.1.0.0.debug
lrwxrwxrwx. 1 root root 19 Mar 18 17:15 /usr/lib/libcrypto.so.6 -
libcrypto.so.0.9.8e
lrwxrwxrwx. 1 root root 18 Mar 18 17:41 /usr/lib/libcrypto.so.10 -
libcrypto.so.1.0.0
-rwxr-xr-x. 1 root root 1610028 Mar 4 19:17 /usr/lib/libcrypto.so.1.0.0
lrwxrwxrwx. 1 root root 18 Mar 25 15:47 /usr/local/ssl/lib/libcrypto.so -
libcrypto.so.1.0.0
lrwxrwxrwx. 1 root root 12 Mar 25 11:49 /usr/local/ssl/lib/libcrypto.so.10 -
libcrypto.so
-r-xr-xr-x. 1 root root 4802798 Mar 25 15:47
/usr/local/ssl/lib/libcrypto.so.1.0.0
lrwxrwxrwx. 1 ssi ssi 18 Mar 25 15:46 /home/ssi/openssl-1.0.0k/libcrypto.so
- libcrypto.so.1.0.0
-rwxrwxr-x. 1 ssi ssi 4802798 Mar 25 15:46
/home/ssi/openssl-1.0.0k/libcrypto.so.1.0.0
This is all on CentoOS 6 in a VM (installed as 6.2 but it seems to update to
6.3 via a 6 repo). The debug package for openssl 1.0.0 is also installed.
The programs in question are built by a large tree of automake scripts (large
package), which seem to be using dynamic (not static) libraries.
I hope the above is clear. Any suggestions as to what might be causing the
program to fail without LD_PRELOAD would be much appreciated.
Thanks,
Andrew
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Substitute requests [Was: Practical CA problem - modified requests]
At 10:03 PM 8/24/01 +0200, you wrote: On Fri, Aug 24, 2001 at 05:28:43PM +0100, Andrew Cooke wrote: What I should have asked is how to detect a *substitute* request. It will be self-consistent, but will not match the correct private key. One solution is to show that the certificate and private key are consistent after signing, but there does not seem to be a way of doing this using openssl. For example, Alice generates a request, sending it to Bob. Mallory intercepts the message and substitutes a different request. Bob sign's Mallory's request and returns it to Alice. Alice thinks she has a certificate that matches her key and distributes it. Mallory then sends data in Alice's name and people verify it against what is apparently Alice's certificate. This is an organizational issue in the first place. The CA (you name it Bob) must make sure that it only signs the correct request. Your security concept is void, if you allow Bob to sign the request without checking it to be authentic. In our university the scenario is as follows. Alice creates the request, then creates a fingerprint (e.g. MD5) of the request. She then sends the How does she create the fingerprint? - I looked and could not find a way to do it with openssl (only fingerprints for certificates seem to be supported). I agree with everything else you write (snipped) - I just cannot find any support in the tools that helps (either fingerprint or later cross-checking). The best I can come up with is using PGP to send in the request, which of course just pushes the problem back a level, but fingerprinting is available for PGP requests (I believe). Thanks, Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Substitute requests [Was: Practical CA problem - modified requests]
Damn! Thanks! I was looking at openssl req (because openssl x509 or something similar does print a fingerprint). With that, I can fix things... Thanks again, Andrew At 08:50 AM 8/25/01 +0200, you wrote: On Sat, Aug 25, 2001 at 07:41:08AM +0100, Andrew Cooke wrote: How does she create the fingerprint? - I looked and could not find a way to do it with openssl (only fingerprints for certificates seem to be supported). openssl md5 filename (or openssl sha1 fingerprint) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Practical CA problem - modified requests
Hi, How do I detect whether a certificate request (in particular, the public key) has been modified before signing? The only solutions I can see are: - doing an explicit test using private and public key - checking the public key data in request and certificate by eye I cannot see any way of detecting this using openssl as a standalone tool - there is no support (that I can see) for request fingerprints and no automated test to compare request and certificate, or certificate and private key. Note that fingerprints after signing do not detect modifications before signing and the openssl verify command checks CA chains, not certificate/key pairs. Also, are there any known attacks (apart from denial of service) that can exploit this? Sorry if this has an obvious solution that I've missed, Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Substitute requests [Was: Practical CA problem - modified requests]
At 05:17 PM 8/24/01 +0200, you wrote: Just verify the signature of request with : openssl -req -verify -in requestfile Thank-you, but I made a mistake asking the question. What you are suggesting will detect a modified request (which is what I wrote), but not someone substituting a different certificate request (that is signed consistently, but is the wrong certificate completely). What I should have asked is how to detect a *substitute* request. It will be self-consistent, but will not match the correct private key. One solution is to show that the certificate and private key are consistent after signing, but there does not seem to be a way of doing this using openssl. For example, Alice generates a request, sending it to Bob. Mallory intercepts the message and substitutes a different request. Bob sign's Mallory's request and returns it to Alice. Alice thinks she has a certificate that matches her key and distributes it. Mallory then sends data in Alice's name and people verify it against what is apparently Alice's certificate. That scenario isn't exactly what I'm worried about, but it illustrates the problem. Thanks again, Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Substitute requests [Was: Practical CA problem - modified requests]
At 05:28 PM 8/24/01 +0100, you wrote: At 05:17 PM 8/24/01 +0200, you wrote: Just verify the signature of request with : openssl -req -verify -in requestfile Thank-you, but I made a mistake asking the question. I was supposed to say Sorry too, at that point! __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: how to verify certificate against private key.
If there's a solution using existing code (ie the openssl utility) then I'm asking the same questions (in effect) in the Practical CA problem threads, so you might want to look at any answers that appear there (hopefully!) too. (You could also encrypt and then decrypt some data - if you get the same data out that you put in then they are consistent, of course. Also, depending on the algorithm, you can check the expected mathematical relation between the keys - for RSA, iirc, one is a factor of the other.) Andrew At 05:48 PM 8/24/01 -0400, you wrote: I looked through the apps and could not find any which did this. I have a X509 * and EVP_PKEY * structure and want to be sure that they do in fact match. So if they are invalid I can just not install them for use in the server and throw an error. I'm using RSA keys if that makes a difference. thanks, -James -- James A. Russo Systems Engineer Verio, Inc. [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: keytool error: java.security.cert.CertificateException: IOException: Sequence tag error
Are you trying to import the certificate from a file that contains a human-readable certificate before the -BEGIN CERTIFICATE line? If so, delete everything up to (but not including) that line and try again. Andrew At 12:33 PM 8/24/01 -0500, you wrote: I am getting an error keytool error: java.security.cert.CertificateException: IOException: Sequence tag error when i try to import s sign certificate into the keystore (JDK 1.3 on Solaris 8) keytool. I have seen a lot of posting on this on the web but no resolution Can anyone help please Ilya --- This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. ABN AMRO Bank N.V. (including its group companies) shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. ABN AMRO Bank N.V. (or its group companies) does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. --- __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Bug? no_tmp_rsa flag ignored in s_server
Hi, I'm using 0.9.5a, but this should be easy to check in 0.9.6: The no_tmp_rsa flag in s_server is ignored. There is an "#if 1" that forces a callback to be used (which ignores the flag), blocking the code that would test the flag before setting a value. Simply grep for no_tmp_rsa in s_server.c and you'll see the problem, it's obvious. The simplest fix (imho) is to make setting the callback conditional on the flag - if the callback is not set then corresponding ciphers suites are not used. Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Why is mod_ssl OK with NN 4.5?!
Thanks. I eventually reduced the problem to s_server running against a stripped-down version of my server, all on a newly installed OS (to avoid DLL confusion). After adding trace statements to the code I found that I was missing a callback in my code to calculate a temporary RSA key (yes, I could have spotted it from s_server output further down the page if I had thought more clearly; yes I could have spotted it by comparing source if I had concentrated better...!) Cheers, Andrew At 12:10 PM 2/16/01 +0100, Lutz Jaenicke wrote: On Fri, Feb 16, 2001 at 10:56:47AM +, Andrew Cooke wrote: Thanks for two good suggestions. Although I was using neither, they don't change much: - I am now using SSLv23_method and SSL_OP_ALL - The connection fails unless SSL_OP_NO_SSLv3 is included (ie SSLv3 is excluded) - The error is now "No common cipher" (handshake B; no handshake A) "No common cipher" suggests *very* strongly that I have an error in my compilation/linking/library that is excluding some cipher suite. However, when I list the available ciphers from within the code everything seems correct and the same libraries work with SSLv2 (or rather, with SSLv3 disabled) and with other browsers. I don't have a NN 4.5 available by now, it is quite old, isn't it. The "No common cipher" seems a bit strange to me. Let me suggest two more things: - Set up s_server and try to connect to it. s_server will probably more comparable to your code. (With or without bug workarounds, see the list of options.) - There is a difference to mod_ssl in that mod_ssl also restricts the ciphers allowed by removing the EXPORT56 ciphers. There is a IE bug with them, I am not aware that Netscape should also be affected, but it is well worth a try. If this applies, the first test should have failed :-) Check out the default cipherstring used in mod_ssl and use it for s_server. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Why is mod_ssl OK with NN 4.5?!
[Copied to Lutz + openssl - looks like you set follow up there] Hi, Thanks for two good suggestions. Although I was using neither, they don't change much: - I am now using SSLv23_method and SSL_OP_ALL - The connection fails unless SSL_OP_NO_SSLv3 is included (ie SSLv3 is excluded) - The error is now "No common cipher" (handshake B; no handshake A) "No common cipher" suggests *very* strongly that I have an error in my compilation/linking/library that is excluding some cipher suite. However, when I list the available ciphers from within the code everything seems correct and the same libraries work with SSLv2 (or rather, with SSLv3 disabled) and with other browsers. I am checking the mod_ssl code - it is difficult to make direct comparisons as it is arranged differently to my code (it is server only, while much of my code is server/client generic), but I have not found any significant differences yet. Thanks again - for a while you made me very hopeful that I had a solution! Cheers, Andrew At 06:10 PM 2/15/01 +0100, you wrote: Do you try to set SSL_OP_ALL as of http://www.openssl.org/docs/ssl/SSL_CTX_set_options.html ? [...] Without checking the mod_ssl source, I would rather recommend you to use SSLv23_method and SSL_OP_NO_SSLv2 if you don't want to allow SSLv2. See http://www.openssl.org/docs/ssl/SSL_CTX_new.html I expect this second point to be your problem. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: localhost certificate (no, really!)
[Sorry for the long gap before replying] As far as I can tell, the following might work: - get a certificate with an arbitrary domain name (say foo.bar.com) - configure DNS to return 127.0.0.1 when clients want to convert for.bar.com to an address - supply the foo.bar.com certificate to the browser from localhost Security on the local machine isn't really an issue - if the machine is compromised then (as you say) there are much worse attacks than snooping local data flow. The aim is to avoid browser warnings in a sequence of transactions (which, when to remote machines, do need to be secure). However, there is at least one attack I can think of if the client software is widely distributed: the foo.bar.com certificate and key will also become widely distributed and DNS spoofing would allow someone to divert the connection to a malicious machine (ie not localhost). Any comments, anyone? (thanks for previous replies; apologies again for not replying for some time), Andrew Greg Stark wrote: Andrew, Ha, that's a good one. Seriously, I'd imagine they might be reluctant to issue it because the DN would not be unique. Does Verisign / Thawte insist on unique DN's? I would think they'd have to. That's what the D in DN is all about, right? You could add other unique information to the DN to solve this problem, like include an second CN with a real internet hostname. I have seen certs with multiple CN's. Would it work? It would be subject to a MITS (man-in-the-stack) attack, but you've got bigger problems if you got a man in your stack ;) Greg Stark, [EMAIL PROTECTED] Ethentica, Inc. www.ethentica.com - Original Message - From: "Andrew Cooke" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 12, 2001 12:39 PM Subject: localhost certificate (no, really!) Hi, Is it possible to buy a "localhost" certificate from any of the major suppliers? Is there any reason why it wouldn't work? (It's for an application that will run on arbitrary machines that needs a web browser to make a local connection as part of a sequence of secure connections - supplying a certificate will stop any security warning from the browser telling the user that they are insecure...) Thanks, Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Sessions persisting without connections
I didn't use the code below verbatim, as I already had my own, but I've
finally tracked down why I wasn't getting the performance/session reuse
I expected, and I think the same bug is in this example code (which is
otherwise very clear and useful). So I'm posting a fix in case anyone
does use this as a reference, and also to check that it is correct.
All that is wrong is that you must call SSL_shutdown(ssl) before calling
SSL_free. Otherwise the session is invalidated by the SSL_free call.
This may be obvious if you're controlling memory yourself. It drove me
nuts because SSL_free was being called when the Java GC cleaned up Java
objects that shadowed C objects. Since these persisted for random times
before GC, I was getting sporadic session re-use
Phew!
Andrew
PS There's a performance hack in s_server that suggests SSL_shutdown may
be slow.
Geoff Thorpe wrote:
On Thu, 24 Feb 2000, Andrew Cooke wrote:
[...]
Looking at the code, it seems that SSL_free only deletes the session if
the reference count is zero. So can I keep an SSL_SESSION simply by
incrementing the reference count and saving a pointer? Obviously this
won't work if the program exits, but would (should) it still work after
all connections with the client had been closed?
[...]
The technique I prefer;
SSL_SESSION *to_resume = NULL;
app_start:
/* insert code ... Get the SSL structure ready to connect */
if(to_resume)
SSL_set_session(ssl, to_resume);
/* insert code ... Connect */
if( /* handshake complete */ )
{
/* insert code ... Grab peer certificate and other details */
/* Choose the just-agreed session for resuming next time */
if(to_resume)
SSL_SESSION_free(to_resume);
to_resume = SSL_get1_session(ssl);
}
/* insert code ... Use the SSL */
SSL_shutdown(ssl) ; /* Need this, I think */
SSL_free(ssl);
if( /* want to keep going */ )
goto app_start;
if(to_resume)
SSL_SESSION_free(to_resume);
That psuedo-code hopefully illustrates the picture. The alternative is to
just use SSL_get_session (equivalent to SSL_get0_session) and serialise
the session to an ASN encoded blob. This (obviously) doesn't involve any
reference counts, and when it comes time to try and resume the session
(using SSL_set_session) you can deserialise the ASN blob into a new
SSL_SESSION, set the SSL's session to it, and free the SSL_SESSION you
just created (which won't deallocate it, but leave the SSL with the only
remaining reference). This is exactly how SSL session caches work on
servers, except that they index the sessions in the cache so that they can
do lookups when a client requests a resume. NB: I haven't tried this
myself, but in theory it should be fine. This uses i2d_SSL_SESSION and
d2i_SSL_SESSION (i=internal, d=DER - which gives your ASN1 blob).
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: RSA flier?
I was under the impression that Dr Stephen Henson, who posts regularly to this list, does paid consulting/support. But looking at a recent sig of his, maybe he has a real job now... (Just in case he doesn't want to advertise himself :-) Andrew Andy Moskoff wrote: On Mon, 7 Feb 2000, Mike Hoegeman wrote: i'm liable to get flamed here but... who "supports" openssl? I've never seen that on this list so far... i think one can make a credible case that openssl is currently unsupported no? developed, yes... earnestly supported, no.. Guess it depends on your definition of support... This group has answered a couple of my questions pretty well. And the FAQ archive is filled with info, you just have to rummage through it. i'd love to proven wrong and be pointed at someone who can provide some openssl support. Didn't see your question on the list...Did you post? Post again and I'm sure someone will answer... --- Andy Moskoffe-mail: [EMAIL PROTECTED] Senior Software Engineer Symark Software __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: DSA Certs CA - help!
I haven't used s_server and s_client, but to do this you would need to call SSL_CTX_set_verify with SSL_VERIFY_NONE on the server and SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT (that's a binary or) on the client. If no-one else replies, you should be able to work backwards from the code to see how to do this with the s_ apps. Andrew Skye Poier wrote: [...] I only want to verify the server authentication. Remeber I'm being my own CA here. [...] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: DSA Certs CA
Sorry. I said something stupid. You are right. Somehow I assumed that you were also giving the client a certificate and key (these are needed if you tell the server to do client authentication). Andrew Skye Poier wrote: OK this is a source of some of my confusion. I thought the client only needed the public key of the server, signed by the CA? Skye Word on the street is that Andrew Cooke said: Skye Poier wrote: I think I might have it figured out. 1. Do steps at http://www.intertrader.com/library/SSLeay/no_rsa.cfm to generate DSA Certificate 2. Server side, do the equivalent of: openssl s_server -key privkey.pem -cert signed.pem -CAfile demoCA/cacert.pem 3. Client side, do the equivalent of: openssl s_client -CAfile signed.pem Is this right??? Gets so confusing after a while. Looks OK. Stating the obvious: you are using the same certificate for both client and server. Usually, with them being on different machines, they have separate certificates (and keys). You might also want to look at changing the settings in openssl.cnf so that the CA flag is not set for client certificates. Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- Clarity of thought should be accompanied by clarity of technique - Mondriaan Powered by ffwd internet division [ http://www.ffwd.com/ ] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: DLL problem
Hi, I've compiled 0.9.4 using VC5 and haven't had any problems. As far as I remember, I just followed the instructions in INSTALL.W32. In particular, I don't remember specifying anything about threads (although the makefile ms\ntdll.mak does include the MD flag). The library is used in multithreaded code and has not had any problems (as S Henson says, the calling code must also be compiled with the MD flag). However, I do call CRYPTO_set_locking_callback with a routine that I lifted from mttest.c (according to the comments in my code). I have no idea whether the library will work without this (it sets up a bunch of mutexes for locking). Andrew Lucia Bonelli wrote: Hi all. I succefully compiled openssl0.9.4 on VC++6.0 with the /MD option (for multithreading). Then, I built another DLL (also with the /MD option) wich uses the libeay32.dll, particularly the PEM I/O routines. At run time, everytime my DLL calls such routines (for example PEM_ASN1_write ) an exception of access violation occurs. Can anybody help me? Thanks in advance, Lucia -- Lucia Bonelli Engineering Ingegneria Informatica SpA Laboratorio Ricerca Sviluppo Viale del Castro Pretorio, 116 00185 Roma Italia Tel. +39 06 44741123 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Question on generating DH certificate (or signed DH parameter)
There's a summary that's out-of-date, but still more-or-less OK at http://www.intertrader.com/library/SSLeay/no_rsa.cfm (Ignore the instructions on building the code and note that revoking a certificate is now possible with the openssl ca command) Andrew Jun-Hua Li wrote: Hi, I am new at security, if any stupid question, please forgive me . Currently I am trying to do SSL with EDH cipher suite.After generate a DH parameter and load it, I think I need something for authentication, but what is that to be ? DH parameter signed by a CA ? I've tried to use CA.sh -sign to sign a DH parameter but it fail to recognize its format. Or should I use a seperate certificate ? If so, how to generate this certificate ? Thanks! Junhua __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: How to install openssl after download the tar file ?
"Leland V. Lammert" wrote: At 02:08 PM 1/6/00 , you wrote: - You must unpack the tar file (which is like a zip file) using something like PkZip or WinZip (or tar -xvf filename in Cygwin bash). I would assume that if someone download a tar file, .. they would have downloaded, perhaps, a UNIX file?? In any case, a tarball is typically source code, .. which is a REAL pain to compile on Win32. OpenSSL builds from source on NT (I have done it) - as far as I remember I used a tar file (I don't think there is a separate source distribution for NT). A far better approach would be to acquire one of the pre-build binaries. I didn't know these existed until your last post and I agree they are more useful, especially for new users (I wasn't trying to say otherwise, just making clear that the tar file does work too). OTOH, the source is invaluable if you are trying to do anything even slightly non-trivial and I, personally, would be wary of using security critical code I didn't have the source for. But neither can I claim I have read all the source and checked there is no security hole Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem with OpenSSL 0.9.4 on MS Windows NT 4
[For the list archives] I think this is now cleared up - openssl by default uses \n rather than \r\n. However, it is possible to change the format using a simple perl script (or, apparently, by emailing certificates). Whether lines end with \n or \r\n does not affect certificate use. Andrew PS: unix-msdosperl -pi.bak -e 's/\n/\r\n/' foo.pem msdos-unixperl -pi.bak -e 's/\r\n/\n/' foo.pem Raul Gutierrez Rodriguez wrote: [...] Raul Gutierrez Rodriguez wrote: All the file in text format that OpenSSL write create in the unix text file format. What can i do so that create all the file in msdos text file format? __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: How to install openssl after download the tar file ?
Hi, I'm not sure that's right - I don't know if there is a zip file and anyway PkZip can handle tar files. In my previous reply I assumed that the person asking knew what a tar file was - if not: - You must unpack the tar file (which is like a zip file) using something like PkZip or WinZip (or tar -xvf filename in Cygwin bash). Andrew "Leland V. Lammert" wrote: At 02:44 PM 1/5/00 , you wrote: Does anyone have idea ? After I download the tart file, how to install openssl into NT machine ? Jason Jason, The first thing you have to do is download the correct file - tar files are for UNIX machines. Lee Leland V. Lammert[EMAIL PROTECTED] Chief Scientist Omnitec Corporation Network/Internet Consultants www.omnitec.net __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Questions on client certificates
Flemming Jans wrote: I'm using openssl 0.9.4 on Sparc Solaris 2.6/2.7 for a webserver like process which must recognize customers from a simple username/password scheme or from a client certificate. The customer 'subscription' is stored in a database where the username is the unique identifier. 1) When using a client certificate I guess the unique username must be stored in the certificate right ? Is the field Common Name (CN) used for this purpose ? Am I guaranteed that this field is unique or is this up to the CA issuing the certificate? Since openssl is both open source and can generate certificates, I can't think of a mechanism that could possibly guarantee that CNs were unique! The simplest solution might be to use the hash of the certificate (SSL_get_peer_certificate; x509_digest) - for all practical purposes, this is unique. 2) My server uses the call SSL_CTX_load_verify_locations(ssl_ctx, CAfile, CApath) to load the CAs. Is it correct that this function loads the CAs that my client certificates can be signed by, meaning that these are the CAs I trust? If the CA which signed the client certificate is not in this list, the client will be rejected, right ? Yes, more-or-less. For details see the discussion on certificate chaining in December. Basically, the client may supply intermediate certificates (so you might have a CA that signed X's certificate, and X signed the client's certificate, and the client supplies both the client certificate and the certificate of X). To avoid this, make sure that a chain length other than one is rejected in the callback set with SSL_CTX_set_verify using X509_STORE_CTX_get_error_depth (maybe this is done by default - I do not know). When setting CAfile to NULL and CApath to e.g. "openssl-0.9.4/certs/" it works fine and the server can read the client certificate. I would however like to use the CAfile argument to specify a file instead. It works well if I use "openssl-0.9.4/certs/vsign1.pem" (I am using a test cert from Verisign). Can I just concatenate a file with all the CAs I would like to support ? Is there such an official file within the openssl distribution or can anyone make one ? This works fine - just cat the files together. Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Millenium and 37 bug
Hi, Not really a open-ssl bug, but it's interesting and I'm curious to hear how people will be dealing with it: has anyone tried to make a certificate that lasts for the next century? We tried (just because we were fed up with test certificates expiring) and found that we couldn't get past 2037, presumably because that's when "unix time" runs out of bits (although this was on NT). Presumably the fix is to link against a library which has t_time defined as something larger (or at least unsigned) - does such a library exist? As CRLs and certificate chaining become more popular, it seems, to me, that having long-lasting certificates will be more important - so I don't think ignoring the problem is the best solution Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL CA as trusted CA in Netscape browser - help
I guess I could if I knew what a Netscape plug-in was (I use OpenSSL to communicate between components within our own software - I don't have much experience of browsers etc). Andrew Michael Pogrebisky wrote: The method uses Netscape plug-in, so you can make your conclusions. From: Andrew Cooke [mailto:[EMAIL PROTECTED]] Michael Pogrebisky wrote: We've found a way to add any arbitrary CA certificate into certificate database of Netscape Communicator (on Win32 only) in a way completely transparent to users. I mean, no UI warnings or questions at all. If anyone is interested, I can e-mail the code. Across a network, or locally? __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Certificate Revocation
Massimiliano Pala wrote: Mario Fabiano wrote: openssl ca -revoke asks for the CA key protection password, but the CA key should be needed only to issue the CRL thst must be signed. NO. As the CA, from now on will consider the certificate REVOKED and in every CRL issued will mark it as R. Only the CA operator who knows the ca key passwd should be able do revoke certificates. [First - thanks for writing this] My comment is an observation, rather than an argument for changing: You are imposing a security model on users that a malicious party can circumvent by changing the code. This isn't really acceptable as part of a library (which may be assembled by others for a variety of security models), but then this is code in the apps directory, rather than in the library itself. In other words, I understand your argument, but if this was part of the SSL library I would argue that it is up to people using the library to put this kind of check in. But your code is in the ca utility rather than the library. If people want to use the utility routines as a "library" to build their own CA scripts, then it would be better, for example, to provide a separate routine that checks that they know the CA password. In that way the person writing the script has the choice of following your security model, or not. As I said, I am not arguing either way - I can see why you have done this, but I hope I have also explained why people who are using the apps as a library to use in their own scripts may object. Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL CA as trusted CA in Netscape browser - help
Michael Pogrebisky wrote: We've found a way to add any arbitrary CA certificate into certificate database of Netscape Communicator (on Win32 only) in a way completely transparent to users. I mean, no UI warnings or questions at all. If anyone is interested, I can e-mail the code. Across a network, or locally? Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: How to Use openssl ca command
Hi, There's an old web page at http://www.intertrader.com/library/SSLeay/no_rsa.cfm#use that I wrote. Much is out of date (it is for SSLeay; in particular there is a ca-revoke and no need for patches with OpenSSL), but the description of how to generate certificates is still valid - I think it has the info you need. Andrew "P.K.B. Hari Gopal" wrote: Hello, How to use the openssl ca command on Windows environment? I have installed Opensa on WinNT and trying to use Apache with SSL. How to create my server certificate? I have created the certificate signing request with openssl. How to get it signed by my CA? It is giving the following error with c:\open ca -in server.csr command. error while loading serial number 1312:error:0D065085:asn1 encoding routines:a2i_ASN1_INTEGER:short line:D:\MyProj ects\Applications\OSA_0.1\openssl-0.9.4\crypto\asn1\f_int.c:210: How can I resolve this error and please give all the necessary steps to issue the certificates using openssl. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Certificate Revocation
Andrew Cooke wrote: [...] PS OpenSSL seems better than SSLeay (even more comments in the code!) - thank-you to everyone who has contributed. I just realised that could be read two ways, one of which only makes sense as sarcasm - I meant "more comments in the code, even"... :-) __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Bug/Request: NT + no-rsa no-idea
Yes they do. I will do it again to make sure (recording exactly what I type) and post back. Andrew Ulf Möller wrote: On Thu, Dec 09, 1999 at 06:10:51PM +, Andrew Cooke wrote: - Ichange NSTALL.W32 to mention this. Something like "If you use any of the -no-XXX options in Configure to exclude ciphers you will have to remove entries from libeay32.def and ssleay32.def in the ms directory before link will work. INSTALL.W32 tells you to run Configure first, and ms\do_ms (or one of the other scripts) after that. If you do that, the definition files don't contain the excluded ciphers, right? __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Bug/Request: NT + no-rsa no-idea
As you can see below, this bug is for real (unless I've done something stupid - please check the record below!). Please tell me if I can help in some way (it is not a big problem, I just thought it might confuse people with no experience of NT). Here's a record of my session (can't cut n paste from NT terminal windows, so excuse typos as I'm typing a copy myself!). comments in [...] tar -xvf archive for 0.9.4 [this within a bash shell, but following within MSDOS] cd openssl-0.9.4 perl Configure VC-WIN32 no-asm no-rsa no-idea [the output from this looked like you'd expect - in particular, it did include -DNO_ASM -DNO_RSA and -DNO_IDEA in CFLAG and perl\util\mkdef.pl was run (with no args other than 32) to create the def files] ms\do_ms [the following was in a shell rather than within VC - I source VCVARS32.BAT on startup, so the shell has the correct environment] nmake -f ms\ntdll.mak [long pause for build, with no errors I noticed] ***[error LNK2001: unresolved external symbol for a pile of routines - see diff later] [but I saved the version I made earlier :-) with those deleted] copy ..\libeay32.def ms\ nmake -f ms\ntdll.mak [link now OK - builds libeay32.dll] [more compilation] ***[same link errors, now for ssleay32] copy ..\ssleay32.def ms\ nmake -f ms\ntdll.mak [success!] [well, I assume it's success - the tests fail immediately because they start with RSA ;-] diffs for the two def files follow: libeay32.def: 400a401,402 EVP_OpenFinal @277 EVP_OpenInit@278 417a420,421 EVP_SealFinal @287 EVP_SealInit@288 536a541,543 PEM_SealFinal @371 PEM_SealInit@372 PEM_SealUpdate @373 555a563,564 PEM_read_RSAPrivateKey @390 PEM_read_RSAPublicKey @947 567a577,578 PEM_read_bio_RSAPrivateKey @400 PEM_read_bio_RSAPublicKey @943 580a592,593 PEM_write_RSAPrivateKey @410 PEM_write_RSAPublicKey @949 593a607,608 PEM_write_bio_RSAPrivateKey @420 PEM_write_bio_RSAPublicKey @944 728a744,746 RSAPrivateKey_asn1_meth @480 RSAPrivateKey_dup @481 RSAPublicKey_dup@482 1083a1102,1105 d2i_RSAPrivateKey_bio @751 d2i_RSAPrivateKey_fp@752 d2i_RSAPublicKey_bio@945 d2i_RSAPublicKey_fp @952 1240a1263,1266 i2d_RSAPrivateKey_bio @854 i2d_RSAPrivateKey_fp@855 i2d_RSAPublicKey_bio@946 i2d_RSAPublicKey_fp @954 ssleay32.def: 52a53 SSL_CTX_set_tmp_rsa_callback@177 57a59,61 SSL_CTX_use_RSAPrivateKey @25 SSL_CTX_use_RSAPrivateKey_ASN1 @26 SSL_CTX_use_RSAPrivateKey_file @27 145a150 SSL_set_tmp_rsa_callback@186 156a162,164 SSL_use_RSAPrivateKey @102 SSL_use_RSAPrivateKey_ASN1 @103 SSL_use_RSAPrivateKey_file @104 162a171,176 SSLv23_client_method@110 SSLv23_method @111 SSLv23_server_method@112 SSLv2_client_method @113 SSLv2_method@114 SSLv2_server_method @115 Cheers, Andrew Ulf Möller wrote: On Thu, Dec 09, 1999 at 06:10:51PM +, Andrew Cooke wrote: - Ichange NSTALL.W32 to mention this. Something like "If you use any of the -no-XXX options in Configure to exclude ciphers you will have to remove entries from libeay32.def and ssleay32.def in the ms directory before link will work. INSTALL.W32 tells you to run Configure first, and ms\do_ms (or one of the other scripts) after that. If you do that, the definition files don't contain the excluded ciphers, right? __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[Fwd: Re: Bug/Request: NT + no-rsa no-idea]
[This was refused and I don't understand why - am posting again] As you can see below, this bug is for real (unless I've done something stupid - please check the record below!). Please tell me if I can help in some way (it is not a big problem, I just thought it might confuse people with no experience of NT). Here's a record of my session (can't cut n paste from NT terminal windows, so excuse typos as I'm typing a copy myself!). comments in [...] tar -xvf archive for 0.9.4 [this within a bash shell, but following within MSDOS] cd openssl-0.9.4 perl Configure VC-WIN32 no-asm no-rsa no-idea [the output from this looked like you'd expect - in particular, it did include -DNO_ASM -DNO_RSA and -DNO_IDEA in CFLAG and perl\util\mkdef.pl was run (with no args other than 32) to create the def files] ms\do_ms [the following was in a shell rather than within VC - I source VCVARS32.BAT on startup, so the shell has the correct environment] nmake -f ms\ntdll.mak [long pause for build, with no errors I noticed] ***[error LNK2001: unresolved external symbol for a pile of routines - see diff later] [but I saved the version I made earlier :-) with those deleted] copy ..\libeay32.def ms\ nmake -f ms\ntdll.mak [link now OK - builds libeay32.dll] [more compilation] ***[same link errors, now for ssleay32] copy ..\ssleay32.def ms\ nmake -f ms\ntdll.mak [success!] [well, I assume it's success - the tests fail immediately because they start with RSA ;-] diffs for the two def files follow: libeay32.def: 400a401,402 EVP_OpenFinal @277 EVP_OpenInit@278 417a420,421 EVP_SealFinal @287 EVP_SealInit@288 536a541,543 PEM_SealFinal @371 PEM_SealInit@372 PEM_SealUpdate @373 555a563,564 PEM_read_RSAPrivateKey @390 PEM_read_RSAPublicKey @947 567a577,578 PEM_read_bio_RSAPrivateKey @400 PEM_read_bio_RSAPublicKey @943 580a592,593 PEM_write_RSAPrivateKey @410 PEM_write_RSAPublicKey @949 593a607,608 PEM_write_bio_RSAPrivateKey @420 PEM_write_bio_RSAPublicKey @944 728a744,746 RSAPrivateKey_asn1_meth @480 RSAPrivateKey_dup @481 RSAPublicKey_dup@482 1083a1102,1105 d2i_RSAPrivateKey_bio @751 d2i_RSAPrivateKey_fp@752 d2i_RSAPublicKey_bio@945 d2i_RSAPublicKey_fp @952 1240a1263,1266 i2d_RSAPrivateKey_bio @854 i2d_RSAPrivateKey_fp@855 i2d_RSAPublicKey_bio@946 i2d_RSAPublicKey_fp @954 ssleay32.def: 52a53 SSL_CTX_set_tmp_rsa_callback@177 57a59,61 SSL_CTX_use_RSAPrivateKey @25 SSL_CTX_use_RSAPrivateKey_ASN1 @26 SSL_CTX_use_RSAPrivateKey_file @27 145a150 SSL_set_tmp_rsa_callback@186 156a162,164 SSL_use_RSAPrivateKey @102 SSL_use_RSAPrivateKey_ASN1 @103 SSL_use_RSAPrivateKey_file @104 162a171,176 SSLv23_client_method@110 SSLv23_method @111 SSLv23_server_method@112 SSLv2_client_method @113 SSLv2_method@114 SSLv2_server_method @115 Cheers, Andrew Ulf Möller wrote: On Thu, Dec 09, 1999 at 06:10:51PM +, Andrew Cooke wrote: - Ichange NSTALL.W32 to mention this. Something like "If you use any of the -no-XXX options in Configure to exclude ciphers you will have to remove entries from libeay32.def and ssleay32.def in the ms directory before link will work. INSTALL.W32 tells you to run Configure first, and ms\do_ms (or one of the other scripts) after that. If you do that, the definition files don't contain the excluded ciphers, right? __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Bug/Request: NT + no-rsa no-idea
Hi, This doesn't compile without deleting unused routines from the .def files for the libraries. It's not a problem if you know about it but could either: - Ichange NSTALL.W32 to mention this. Something like "If you use any of the -no-XXX options in Configure to exclude ciphers you will have to remove entries from libeay32.def and ssleay32.def in the ms directory before link will work. Follow the instructions below until linking and then, when that fails, delete references to the missing routines - you'll have to do this twice, once for each file." - someone cleverer/with more time than me could automate this in some way? - Maybe there os another solution (I'm no NT expert). Cheers, Andrew (I can supply versions of the .def files for no-rsa no-idea, but they are probably specific to the release) __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Idiot's summary of [Re: Certificate chaining]
Jan Meijer wrote: You could have a point here. I was fooling around with a test certificate that is signed by our root CA (the SURFnet PCA). With this test-certificate I signed client certs and I had problems verifying the client certs. The troubles went away after including the PCA certificate in the chain (which basically tells me openssl does not trust anything unless the final root CA cert is included. Think I could argue this reasoning ;). Basically our CA will always put the correct subject line into a client/server cert, as will the PCA (in a CA's cert). I think it all depends on how the actual clients and servers handle chain-checking when deciding what might be usefull for the Openssl verify function to act like. I tried to use it when something failed with my netscape browser, and since that is a pretty closed environment I went to openssl for help. There's the history of my initial question. Thanks for the answer, I'll have a look at the docs :) I've just finished sorting out our code and checking with the posts here. Since the above seemed a bit confused (no offence, but this post seems to imply that you knew less than your previous post :-) and since it will help me get things straight in my head, this is a simple summary. If anything contradicts posts from S Henson then believe him - I learnt everything I say here from his posts and playing with our code (home grown Java/C stuff that uses 0.9.4). IF ANYTHING BELOW IS WRONG PLEASE CORRECT ME! Thanks. - I will discuss the case where one party, which I call "client" submits a certificate to another party, which I'll call "server". Those names aren't intended to imply that one party initiated the connection, or that verification will not also occur in the other direction. - So, the client submits a certificate. - The server's aim is to find a self-signed certificate that signed that certificate, or a self-signed certificate that signed a certificate that signed that certificate, or a self-signed certificate that signed a certificate that signed a certificate that... - I'll call the self-signed certificate the "root certificate" and the certificates between it and the client's certificate "intermediate certificates". - All intermediate certificates must be present, but they need not all be present on the server side. The client may supply some intermeditae certificates. This occurs during the SSL handshake. - In my experiments the intermediate certificates were used if they were preent in the client's CAfile or the server's CAfile. Presumable CA directories would also work. - The root certificate must be present on the server - the server will not (successfuly) use a root certificate supplied by the client. - This procedure is open to abuse because you may not trust people that are trusted by people you do trust(!). For example, you may trust A. A may trust B, but you may not trust B. Intermediate certificates can force you to trust B. This is a security hole. - This occurs as follows: You sign A's certificate with your root certificate. A then signs B's certificate with A's certificate. When B connects to your server, B may include A's certificate. Your server will then verify B, using A's certificate as an intermediate certificate. - At the moment (0.9.4) this can be avoided by refusing to accept a depth greater than 1 in the verification process. - Checking the depth is done in our code (and I believe this is normal) within verify_callback. This routine is supplied to SSL using SSL_CTX_set_verify. I can't post our code (sorry), but you would simply return 0 if depth is greater than 1. - This same callback can also be used to implement CRLs. - One way to avoid the problem above is to use the CA flag in basicConstraints. This is a small piece of data within the certificate that indicates whether the certificate is a CA certificate or not (remember that information in the certificate, once signed, cannot be changed, or it will break the signature). - In the past it was recommended that people not bother with this piece of data for compatibility. However, it is need to solve the problem above. - The security hole above can be closed by only signing other people's certificates if the CA flag is false and then checking that all intermediate certificates have a true CA flag. - This allows you to implement a hierarchy of certificates. You can have a root CA whose private key is used to sign some "working CA certificates" (CA flag true) and then hidden away. By keeping the root key off-network and off-site you can be pretty sure that it will not be compromised. - The working CA certificates are used, as intermediate certificates, to sign other people's certificates. But only certificates where the CA flag is false are signed. - Let's return to A and B. A now has a CA=false certificate. A signs B's certificate. B connects, using A's certificate as an intermediate certificate. Because
Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement
EKR wrote: Andrew Cooke [EMAIL PROTECTED] writes: EKR wrote: Andrew Cooke [EMAIL PROTECTED] writes: Nicolas Roumiantzeff wrote: Does anybody know why both IE and Netscape browser implement exclusively RSA certificates? I have no idea, but one reason might be the need for good random number seeds when doing DH key exchange. It is difficult to get 1K of random bytes without trusting your user to follow instructions (and presumably they want "idiot proof" software). I don't think so. [...] 2. 1024 bits of random data are more than enough to generate a strong DH key. I seem to be having a hard time typing the right thing on this list. Yes, I meant bits - but I don't really see how this changes my argument. 1024 bits is a lot of bits. Yes, it is, but as I said in the section of my message you deleted, you need an equivalent number of random bits in order to perform the RSA key exchange, so DH is no worse from this perspective. I didn't mean to selectively edit anything - I thought there was a quantitative difference in the quality of random number needed for the two cases. On the other hand, I am involved in writing software for servers as well as clients and I *think* that it is the server side that is critical for random numbers with DH exchange (so this is not so serious for browsers acting as clients). If I recall correctly, you can expose the server's private key by simply using the same random number twice... When you're doing DSS/DHE, there are three places where you need random numbers (ignoring ServerRandom and ClientRandom): 1. The server's generation of its ephemeral DH key. 2. The server's DSA signature. 3. The client's generation of its ephemeral DH key. If the server botches (2) then it can reveal its DSA private key. Botching the random number generation for (1) and (2) simply allows compromise of per-connection keys. I've dug out the nearest I can get to what made me think random numbers were critical for DH key exchange and it's here: http://remus.prakinf.tu-ilmenau.de/ssl-users/archive9809/0124.html - the last quoted section (the main post is from me - I can't find the post I was replying to). It's talking about two things (afaik) - is the first (2) above? Cheers, Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL/TLS Security (FW - Tom Weinstein)
Vin McLellan wrote: Date: Mon, 29 Nov 1999 14:11:47 -0800 From: Tom Weinstein [EMAIL PROTECTED] Organization: Geocast Network Systems Sender: [EMAIL PROTECTED] Jaroslav Pinkava wrote: Where can I get the last informations about present SSL security status? I seek more detailed information than contented in the following report: http://webdevelopersjournal.com/articles/is_ssl_dead.html That article describes an attack against the link between URLs and certificates. Neither Netscape nor MSIE are vulnerable to this attack. In fact, I know of no browser that is vulnerable to this attack. This article is mostly just a free advertisement for Digital Bond. David Wagner and Bruce Schneier have performed an excellent analysis of SSL 3.0 which is available from http://www.counterpane.com/ssl.html This paper is three years old now, but I believe it still accurately reflects current knowledge of SSL 3.0's security. The TLS working group has addressed some of the potential weaknesses mentioned in the paper and I'd encourage you to use TLS if you have that option. Thanks for the pointer to the paper - I have skimmed it and it looks very good, wish I had known of it months ago. However, the original post referred to an article that said most attacks agains SSL were social engineering rather than technical. The Wagner/Schneier paper seems to be concerned only with technical attacks. As far as I know, one of the attacks described in the original article - spoofing a whole site with an *apparently* acceptable certificate (they give the example of a CN of miicrosoft) is feasible. With SSL you are guaranteed to be talking to the person whose certificate you get. Whether that person is the person you expect depends ultimately on whether you and the CA are in agreement. I don't understand how any browser can protect against this - how does the browser know that you were expecting microsoft and not miicrosoft? Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ca/cert key gen?
Skye Poier wrote: [...] Also, what files do I need to generate for the server and client (certificates? CA? private/public keys?) for those ciphers and what are the steps for doing that? I think I can be my own CA, also neither the client nor the server are checking certificates, we're just using the encryption for now. Although much of the info is now out-of-date, the stuff about being your own CA at http://www.intertrader.com is still useful. Can't remember the full URL, but follow links to "Library", SSL, and then a link to a faq on SSLeay without patent problems. The second half of that page contains details about being your own CA without using CA.sh. Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement
This isn't quite true - you can compile OpenSSL to be copyright free.
However, as far as I know (and my knowledge is a bit out-of-date, so
this may have changed), this then leaves SSL with cipher suites which
are not supported by the common browsers. So you can only write secure
applications that do not talk to browsers. But you can still use SSL,
if both ends of the connection have a comprehensive (ie OpenSSL)
implementation.
Sorry if this repeats stuff - I've just re-subscribed to the list after
having not read it for a long time (since SSLeay, I guess).
Andrew
"Aaron D. Turner" wrote:
After about 2 weeks worth of research (talking to this list, RSA,
our lawyers, etc) I found that if your a company in the US, and you
want SSL to talk to IE or Netscape, you have to either:
- Break the law
or
- Buy a license from RSA (very expensive)
or
- Buy a commercial SSL implimentation (not cheap, but about 100 times
cheaper than getting a license from RSA)
Using only des/des3 won't work because you need a PK algorithm to
exchange the des/des3 keys.
--
Aaron Turner[EMAIL PROTECTED] 650.237.0300 x252
Security Engineer Vicinity Corp.
Cell: 408-314-9874 Pager: 650-317-1821 http://www.vicinity.com
On Wed, 24 Nov 1999, Tim Riker wrote:
OK, so what is a distributor to do? ;-)
In short: Is it possible to build OpenSSL without and code that is
patent infringed, and still have it talk to Netscape and M$IE? What if I
did:
./Configure --prefix=/usr --openssldir=%{openssldir} linux-elf \
no-bf no-idea no-rc2 no-rc4 no-rc5 no-rsa no-sha
to get just des/des3, is that enough? (the astute will notice that this
will not build, but hey) It should be ok to leave in blowfish, but
M$IE/Netscape do not have blowfish anyway right?
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Certificate chaining
Hi, I've been looking around and can't see an answer to this, but if one exists, please point me to it rather than posting again... I have been playing with certificate chaining (signing certs that are signed by a certificate signed by a certificate signed by ... a self-signed certificate) and have got OpenSSL working with a chain by supplying all the certificates to the code doing the verifying (eg by placing them all in the CA certificate file - I could also have used the hashed directory methods). However, it seems to me that it would be better if the verifier had only the root CA certificate, and the verifiee supplied not just its certificate, but the intermediate certs in the chain. In this way, the verifier would not need updating if intermediate certs changed (the verifiee would have to get new certs anyway, if an intermediate cert was revoked). Is this possible? And if not, is there a good reason why not (like it's a gaping security hole)? Thanks, Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Socket closure not detected on NT (intermittent bug?)
As the person who started this thread can I suggest that you look at s_client.c in the apps directory. There is some sample code there that shows how to handle SSL_read (just search for SSL_read) - it's pretty clear what the code is trying to do. Andrew Stefan Pedersen wrote: Ok... NOW I'm confused. SSL_read returning 0 and connection not closed by peer? This would break the traditional unix like behaviour. Could you please explain what you mean? And I don't really see the parallell with HTTP either. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Socket closure not detected on NT (intermittent bug?)
[copied to private email as well as the list] Thank-you very much! That's exactly what I needed. I must also apologise on two accounts: 1: I thought I had based my code on s_client, and can't see now how I ended up so confused. 2: I have already replied to another email of yours asking about select and have no idea how to stop it from going out when I dial-up (I have just started using email via the telephone, having moved away from the office, and am still learning how to live with a slow, expensive, and intermittent link to the internet...) - the answer to my question is that select is necessary (for emulating blocking read) because there is insufficient data, but it is possible for select to indicate data and SSL to still return -1 with WANT_READ, in which case I need to select again (until a full block has been read into the SSL buffer). Cheers, Andrew Bodo Moeller wrote: On Tue, Apr 13, 1999 at 12:00:00AM +, Andrew Cooke wrote: I am reading across the network, using SSLeay-0.9.0.b, and have an intermittent problem - the sending socket is being closed, but this is not always being detected by the receiving SSL. In particular, SSL_read(ssl, buffer, length) is returning zero rather than -1. The return value zero means that the connection has been closed (well, unless you called read() with length == 0, which does not make too much sense). Look at s_client.c: First there's the call k = SSL_read(con, ...), and then there's switch (SSL_get_error(con, k)). The definition of SSL_get_error is in ssl/ssl_lib.c: SSL_ERROR_NONE is returned if k 0. If k == -1, either an error code is chosen, or SSL_ERROR_WANT_WRITE / SSL_ERROR_WANT_READ is returned (there are a few more special cases that I'll omit here). These SSL_ERROR_WANT_... return values are only used for non-blocking I/O. They tell the calling program that it should wait until the socket is writable or readable, respectively, and then call the library function again. If k == 0, either SSL_ERROR_ZERO_RETURN or SSL_ERROR_SYSCALL will be returned. If it's SSL_ERROR_ZERO_RETURN, s_client closes its connections immediately. This seems to be a bug, possibly connected with non-blocking reads. So is there a fix and/or can anyone describe how to do blocking reads [...] Look at s_client.c and s_server.c. A return value of 0 has nothing to do with non-blocking I/O: For non-blocking sockets, the return value of un unsuccesful SSL_read() is -1 (as it is for OS level sockets), and the error code tells the application that it should wait until the I/O operation can take place (the program should use select() or poll() for this). Different from standard read() which returns EAGAIN aka EWOULDBLOCK if there's no data available for non-blocking I/O [1], SSL_read() has two different possibilities: The system call that could not be completed may either have been a read()/recv() or -- if a handhsake is taking place -- a write()/send(). This is indicated by SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE, respectively. [1] This is POSIX O_NONBLOCK semantics. There's also the old System V O_NDELAY semantics where read() might return 0 and you cannot tell if this means EOF or that you should just wait. That's broken by design. PS. Further info: BIO_eof(SSL_get_rbio(ssl)) is also returning zero For sockets, BIO_eof is just a dummy function. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Good Crypto Book
This may be the same book... on a similar vein (good intro, but no maths) try the Nutshell book with the shark on the front. Can't remember the title or author and it looks like someone has "borrowed" it Andrew At 12:13 PM 2/19/99 +, you wrote: On Fri 19 Feb, John wrote: Hi guys, Do you advise any good cryptography book? I got Bruce Schneier second edition of Applied Cryptography, but still looking for something else. For a higher level read try 'Internet Cryptography' by Richard E Smith. It is aimed at managers and other people who want to understand the issues but don't need to know the maths. Simon. -- Simon Middleton, Principal Software Engineer, Custom Engineering Element 14 LtdTel: +44 (0) 1223 725576 645 Newmarket RoadFax: +44 (0) 1223 725676 Cambridge, CB5 8PB, United KingdomWWW: http://www.e-14.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Good Crypto Book
Found it - Web Security and Commerce is a very good intro to security issues. By Garfinkel and Spafford, pub by O'Reilly. Andrew At 02:17 PM 2/19/99 +, you wrote: This may be the same book... on a similar vein (good intro, but no maths) try the Nutshell book with the shark on the front. Can't remember the title or author and it looks like someone has "borrowed" it Andrew At 12:13 PM 2/19/99 +, you wrote: On Fri 19 Feb, John wrote: Hi guys, Do you advise any good cryptography book? I got Bruce Schneier second edition of Applied Cryptography, but still looking for something else. For a higher level read try 'Internet Cryptography' by Richard E Smith. It is aimed at managers and other people who want to understand the issues but don't need to know the maths. Simon. -- Simon Middleton, Principal Software Engineer, Custom Engineering Element 14 LtdTel: +44 (0) 1223 725576 645 Newmarket RoadFax: +44 (0) 1223 725676 Cambridge, CB5 8PB, United KingdomWWW: http://www.e-14.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Diffie-Hellman Documentation
I think I mention DH in the docs at http://www.intertrader.com/library/SSLeay/no_rsa.cfm Andrew At 02:59 PM 2/9/99 +0800, you wrote: Hi, I want to use the Diffie-Hellman part in OpenSSL, but I can't find a relevant documentation in the "openssl-0.9.1c\doc" directory. Anyone who knows could please lend me a hand? Thank you in advance. Regards, Wayne [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
List configuration - reply to user, not list [was Re: Diffie-Hellman Documentation]
Whoa! Why isn't this list configured so that if I hit reply it goes to the original sender by default, and not the list? ssl-users workled like that, as does another mailing list I use. It was a bit of a surprise to see a message I thought I had just dashed off to one person arrive on the list! Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
