Checking for RSA private key (/etc/ipsec.secrets) [DISABLED]
Hi all! When I use the x509 certification to connection two network, For I have set the password for private key, So I add the line : RSA /etc/ipsec.d/private/right.key passwd to /etc/ipsec.secrets file. After that , I restart ipsec service , and checked the ipsec status by command ipsec verify. Then: Checking your system to see if IPsec got installed and started correctly: Version check and ipsec on-path[OK] Linux Openswan U2.6.20/K2.6.18-92.1.22.el5 (netkey) Checking for IPsec support in kernel[OK] NETKEY detected, testing for disabled ICMP send_redirects [OK] NETKEY detected, testing for disabled ICMP accept_redirects [OK] Checking for RSA private key (/etc/ipsec.secrets) [DISABLED] Checking that pluto is running [OK] Two or more interfaces found, checking IP forwarding [OK] Checking NAT and MASQUERADEing Checking for 'ip' command [OK] Checking for 'iptables' command [OK] Is there any question in my openswan or it's normal. Best regards! Shawn
Re: Checking for RSA private key (/etc/ipsec.secrets) [DISABLED]
This is certainly a configuration issue with S/WAN. I've never even heard of this. -Kyle H On Tue, Mar 31, 2009 at 11:50 PM, shawnlau net17shawn...@gmail.com wrote: Hi all! When I use the x509 certification to connection two network, For I have set the password for private key, So I add the line : RSA /etc/ipsec.d/private/right.key “passwd” to /etc/ipsec.secrets file. After that , I restart ipsec service , and checked the ipsec status by command ipsec verify. Then: Checking your system to see if IPsec got installed and started correctly: Version check and ipsec on-path [OK] Linux Openswan U2.6.20/K2.6.18-92.1.22.el5 (netkey) Checking for IPsec support in kernel [OK] NETKEY detected, testing for disabled ICMP send_redirects [OK] NETKEY detected, testing for disabled ICMP accept_redirects [OK] Checking for RSA private key (/etc/ipsec.secrets) [DISABLED] Checking that pluto is running [OK] Two or more interfaces found, checking IP forwarding [OK] Checking NAT and MASQUERADEing Checking for 'ip' command [OK] Checking for 'iptables' command [OK] Is there any question in my openswan or it’s normal. Best regards! Shawn
Memory Leaks on every connection
Hi!
I have the problem, that I get a pair of 12 bytes and 396 bytes memory leak
for every connection even if they are closed successfully.
They look like this:
{57741} normal block at 0x035EB310, 12 bytes long.
Data: @ n 3 40 16 6E 03 00 00 00 00 F0 33 01 00
{57740} normal block at 0x036E1640, 396 bytes long.
Data: B0 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00
For 126 connections I get 252 of this leaks.
After creating a socket I create a BIO and SSL handle like this:
m_pSSLCommand = SSL_new(m_pCTX);
m_pBIOCommand = BIO_new_socket((int)m_SockCommand, BIO_NOCLOSE);
SSL_set_bio(m_pSSLCommand, m_pBIOCommand, m_pBIOCommand);
and initialize a handshake with:
SSL_accept(m_pSSLCommand);
When closing the connection I call:
SSL_shutdown(m_pSSLCommand);
SSL_free(m_pSSLCommand);
closesocket(m_SockCommand);
I saw, that some other have the same problem, but I didn't find any
solution. Has anybody an idea why these leaks occurr?
regards
Alex
P.S.: For the creation of the CTX I reference to a certificate which is used
for handshake, maybe this has some influence:
SSL_library_init();
meth = SSLv23_method();
ctx = SSL_CTX_new(meth);
/* Set up a callback for each state change so we can see what's going on */
SSL_CTX_set_info_callback(ctx, apps_ssl_info_callback);
/* Load our keys and certificates*/
SSL_CTX_use_certificate_chain_file(ctx, pchKeyFile);
SSL_CTX_set_default_passwd_cb(ctx, password_cb);
if(!(SSL_CTX_use_PrivateKey_file(ctx, pchKeyFile, SSL_FILETYPE_PEM))) {
return(ERROR);
}
/*Make sure the key and certificate file match*/
if (!SSL_CTX_check_private_key(ctx)) {
return(ERROR);
}
--
View this message in context:
http://www.nabble.com/Memory-Leaks-on-every-connection-tp22805904p22805904.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Difference between RSA_sign and CryptSignHash signature
I finally managed to get the same result with RSA_sign as with CryptSignHash. The problem was I used the wrong algorithm, nid_SHA1WithRSA instead of nid_SHA1. When I sign an XML using this signature it also validates. Thanks to everyone for explaining me everything and helping me with the stupid C++ mistakes I made! Goblin_Queen wrote: OK, I got your point, I'll ask what they meant by the same results then. You're saying that I'm not competent for this task. As I said before, I'm a student, and I'm doing this project to get my master degree. Everything security related is still very new to me, especially because it's in C++, which I'm not very familiar with. But it is obvious that I'm not the last person who will be working on this project. The company asked me to do this, so I'll set the start for this project, but after me, many others will check my code and optimise it. It's important for them because it's security related so it should be really safe and bug free, and they also realize that. The people who will work on it after me are experts on the case, I just have to get as far as possible. I also find it annoying that I have to ask these stupid questions, but where else should I seek help? This forum is meant for people who are using OpenSSL, and I'm just trying to learn how. But thanks for your time anyway. David Schwartz wrote: David, When I sign the same hash with the same certificate I should get the same signature. That sounds pretty logical to me. Really? So if you sign the same contract twice, the two signatures will be precisely identical? The company I'm doing this project for also told me that I should get the same result as the one CryptSignHash gives me, that's why I'm trying to get 2 identical results. By the same result, I hope that they mean the same logical result. You will not get the exact same value. Suppose, for example, there were certain hash values that could weaken RSA keys. If I create a document that you have to sign, I can engineer the document so that the hash you wind up signing is one of those hash values. (Because I know the hash you are going to sign.) Adding random padding means an attacker, even if he chooses the plaintext you sign, cannot chose the hash you sign. Is this serious? No. But algorithms are not deliberately designed with vulnerabilities just because those vulnerabilities are not serious. If you are comparing the two signatures for literal equality, what you are doing makes no sense. One more point, and I apologize for having to bring this up. You are doing a security-related task for which you are not competent. Even if your code appears to work in simple test cases, there is a serious chance that it will have vulnerabilities that could compromise security. For example, if you had used 'strlen', an attacker could trivially create multiple documents that appear to have the same hash simply by choosing documents whose hashes all begin with a zero byte. If anyone is going to rely on your code, you are doing the equivalent of building a suspension bridge that will carry traffic. That takes an expert. That's just a fact. If you blunder you way through it, you will make every mistake. And some of them will leave code that appears to work. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org - Stephanie -- View this message in context: http://www.nabble.com/Difference-between-RSA_sign-and-CryptSignHash-signature-tp22575898p22821136.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
CSR public exposure
Hello, Is there any reason why one needs to protect CSR (e.g. encrypting it) from public view? I was under impression that is the key that needs to be protected not the CSR? Thank you, Farid __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: CSR public exposure
The private key is what needs to be protected. The CSR contains information that you may consider proprietary, but the only *really* important piece of it is the public key, which is going to be in the issued certificate anyway. -Kyle H On Tue, Mar 31, 2009 at 1:15 PM, fhd...@unm.edu wrote: Hello, Is there any reason why one needs to protect CSR (e.g. encrypting it) from public view? I was under impression that is the key that needs to be protected not the CSR? Thank you, Farid __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-us...@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 doubt SSL_Write
If SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE are returned, the arguments *must* be *exactly* the same. This includes the data pointed to by the buffer. There is a way to set a mode on the SSL connection to allow a moving buffer, but that's it. SSL will not buffer the data passed to it. If SSL_write returns SSL_ERROR_WANT_READ, then just call SSL_write again. (Usually, in this case, you can select() on the underlying socket to determine if there's any pending data to be read from the socket.) If SSL_read returns SSL_ERROR_WANT_WRITE, just call SSL_read again. (You might try to select() to see if the socket is writable.) -Kyle H On Tue, Mar 31, 2009 at 10:50 AM, Balaji Kannadassan balaj...@nortel.com wrote: Hi All! I've have some doubts regarding SSL_write in non blocking mode.. 1. if SSL_write returned SSL_ERROR_WANT_WRITE, it is mentioned that the call has to be repeated with the same arguments. Does this means the same buffer to be used again?? or the data passed in the initial SSL_write call will be buffered by the SSL layer? 2. In case of SSL_write returning SSL_ERROR_WANT_READ due to re-negotiation, What are the steps to be followed? Is there any wait needed before the repeated SSL_write call? Does the application need to take care of the re-negotiation? Does the application need to wait for the re-negotiation to complete before repeating the SSL_write? Thanks in advance Balaji Kamal Kannadassan __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-us...@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 doubt SSL_Write
Hi All! I've have some doubts regarding SSL_write in non blocking mode.. 1. if SSL_write returned SSL_ERROR_WANT_WRITE, it is mentioned that the call has to be repeated with the same arguments. Does this means the same buffer to be used again?? or the data passed in the initial SSL_write call will be buffered by the SSL layer? 2. In case of SSL_write returning SSL_ERROR_WANT_READ due to re-negotiation, What are the steps to be followed? Is there any wait needed before the repeated SSL_write call? Does the application need to take care of the re-negotiation? Does the application need to wait for the re-negotiation to complete before repeating the SSL_write? Thanks in advance Balaji Kamal Kannadassan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
答复: Checking for RSA private key (/etc/ipsec.secrets) [DISABLED]
Thanks you ! But How to deal with this problem? The configure followed from
openswan.pdf handbook. Because my private key has password protected. When this
error occurred, The ipsec auto --listall command shows like below:
Apr 01 15:53:23 2009, 1024 RSA Key AwEAAdOVn (has private key), until Mar 31
17:29:00 2010 ok
-邮件原件-
发件人: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
代表 Kyle Hamilton
发送时间: 2009年4月1日 15:59
收件人: openssl-users@openssl.org
主题: Re: Checking for RSA private key (/etc/ipsec.secrets) [DISABLED]
This is certainly a configuration issue with S/WAN. I've never even
heard of this.
-Kyle H
On Tue, Mar 31, 2009 at 11:50 PM, shawnlau net17shawn...@gmail.com wrote:
Hi all!
When I use the x509 certification to connection two network, For I have set
the password for private key, So I add the line
: RSA /etc/ipsec.d/private/right.key “passwd” to /etc/ipsec.secrets file.
After that , I restart ipsec service , and checked the ipsec status by
command ipsec verify. Then:
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path[OK]
Linux Openswan U2.6.20/K2.6.18-92.1.22.el5 (netkey)
Checking for IPsec support in kernel[OK]
NETKEY detected, testing for disabled ICMP send_redirects
[OK]
NETKEY detected, testing for disabled ICMP accept_redirects
[OK]
Checking for RSA private key (/etc/ipsec.secrets)
[DISABLED]
Checking that pluto is running [OK]
Two or more interfaces found, checking IP forwarding
[OK]
Checking NAT and MASQUERADEing
Checking for 'ip' command [OK]
Checking for 'iptables' command [OK]
Is there any question in my openswan or it’s normal.
Best regards!
Shawn
:Irض
ZK+1x˥[zZ
fyҲӝfz{
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: 答复: Checking for RSA private key (/etc/ipsec .secrets) [DISABLED]
This is not an openswan support list. I have no idea, and unless one
of the other lurkers here has knowledge of openswan, you're most
likely not going to be able to find an answer here. :/
-Kyle H
On Wed, Apr 1, 2009 at 1:34 AM, shawnlau net17shawn...@gmail.com wrote:
Thanks you ! But How to deal with this problem? The configure followed from
openswan.pdf handbook. Because my private key has password protected. When
this error occurred, The ipsec auto --listall command shows like below:
Apr 01 15:53:23 2009, 1024 RSA Key AwEAAdOVn (has private key), until Mar 31
17:29:00 2010 ok
-邮件原件-
发件人: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
代表 Kyle Hamilton
发送时间: 2009年4月1日 15:59
收件人: openssl-users@openssl.org
主题: Re: Checking for RSA private key (/etc/ipsec.secrets) [DISABLED]
This is certainly a configuration issue with S/WAN. I've never even
heard of this.
-Kyle H
On Tue, Mar 31, 2009 at 11:50 PM, shawnlau net17shawn...@gmail.com wrote:
Hi all!
When I use the x509 certification to connection two network, For I have set
the password for private key, So I add the line
: RSA /etc/ipsec.d/private/right.key “passwd” to /etc/ipsec.secrets file.
After that , I restart ipsec service , and checked the ipsec status by
command ipsec verify. Then:
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path [OK]
Linux Openswan U2.6.20/K2.6.18-92.1.22.el5 (netkey)
Checking for IPsec support in kernel [OK]
NETKEY detected, testing for disabled ICMP send_redirects
[OK]
NETKEY detected, testing for disabled ICMP accept_redirects
[OK]
Checking for RSA private key (/etc/ipsec.secrets)
[DISABLED]
Checking that pluto is running [OK]
Two or more interfaces found, checking IP forwarding
[OK]
Checking NAT and MASQUERADEing
Checking for 'ip' command [OK]
Checking for 'iptables' command [OK]
Is there any question in my openswan or it’s normal.
Best regards!
Shawn
:Irض
ZK+1x˥[zZ
fyҲӝfz{
__
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-us...@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
migrating from bsafe to openSSL
I'm looking to migrate AES encryption code from BSAFE to openSSL. As a test, I encrypted a string using BSAFE AES tried to decrypt using AES of openSSL. The openSSL manages to decrypt, but it adds some junk (mostly unprintable characters) in the end. For example, if my input is 1234, the decrypted output in hex form is [313233340c0c0c0c0c0c0c0c0c0c0c0c], (31323334 is 1234 in hex form). For 12345 - [31323334350b0b0b0b0b0b0b0b0b0b0b] For 123456 - [3132333435360a0a0a0a0a0a0a0a0a0a] Basically, the junk after the decrypted text is 16 - (string length of decrypted text) For example, 1234's length is 4, 16 - 4 = 12 = 0c in hex so it gets filled with that. (313233340c0c0c0c0c0c0c0c0c0c0c0c) For example, 12345's length is 5, 16 - 5 = 11 = 0b in hex so it gets filled with that.(31323334350b0b0b0b0b0b0b0b0b0b0b) So what needs to be done to prevent openSSL API [I'm using AES_cbc_encrypt()] to prevent it from writing this strange junk at the end? Thanks -Mahesh
答复: 答复: Checking for RSA private key (/etc/ipsec.secrets) [DISAB LED]
I'm so sorry about that! I made a big mistake about the mailing-list! So sorry
-邮件原件-
发件人: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
代表 Kyle Hamilton
发送时间: 2009年4月1日 16:52
收件人: openssl-users@openssl.org
主题: Re: 答复: Checking for RSA private key (/etc/ipsec.secrets) [DISABLED]
This is not an openswan support list. I have no idea, and unless one
of the other lurkers here has knowledge of openswan, you're most
likely not going to be able to find an answer here. :/
-Kyle H
On Wed, Apr 1, 2009 at 1:34 AM, shawnlau net17shawn...@gmail.com wrote:
Thanks you ! But How to deal with this problem? The configure followed from
openswan.pdf handbook. Because my private key has password protected. When
this error occurred, The ipsec auto --listall command shows like below:
Apr 01 15:53:23 2009, 1024 RSA Key AwEAAdOVn (has private key), until Mar 31
17:29:00 2010 ok
-邮件原件-
发件人: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
代表 Kyle Hamilton
发送时间: 2009年4月1日 15:59
收件人: openssl-users@openssl.org
主题: Re: Checking for RSA private key (/etc/ipsec.secrets) [DISABLED]
This is certainly a configuration issue with S/WAN. I've never even
heard of this.
-Kyle H
On Tue, Mar 31, 2009 at 11:50 PM, shawnlau net17shawn...@gmail.com wrote:
Hi all!
When I use the x509 certification to connection two network, For I have set
the password for private key, So I add the line
: RSA /etc/ipsec.d/private/right.key “passwd” to /etc/ipsec.secrets file.
After that , I restart ipsec service , and checked the ipsec status by
command ipsec verify. Then:
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path[OK]
Linux Openswan U2.6.20/K2.6.18-92.1.22.el5 (netkey)
Checking for IPsec support in kernel[OK]
NETKEY detected, testing for disabled ICMP send_redirects
[OK]
NETKEY detected, testing for disabled ICMP accept_redirects
[OK]
Checking for RSA private key (/etc/ipsec.secrets)
[DISABLED]
Checking that pluto is running [OK]
Two or more interfaces found, checking IP forwarding
[OK]
Checking NAT and MASQUERADEing
Checking for 'ip' command [OK]
Checking for 'iptables' command [OK]
Is there any question in my openswan or it’s normal.
Best regards!
Shawn
:Irض
ZK+1x˥[zZ
fyҲӝfz{
__
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: migrating from bsafe to openSSL
On Wed, Apr 01, 2009, m r wrote: I'm looking to migrate AES encryption code from BSAFE to openSSL. As a test, I encrypted a string using BSAFE AES tried to decrypt using AES of openSSL. The openSSL manages to decrypt, but it adds some junk (mostly unprintable characters) in the end. For example, if my input is 1234, the decrypted output in hex form is [313233340c0c0c0c0c0c0c0c0c0c0c0c], (31323334 is 1234 in hex form). For 12345 - [31323334350b0b0b0b0b0b0b0b0b0b0b] For 123456 - [3132333435360a0a0a0a0a0a0a0a0a0a] Basically, the junk after the decrypted text is 16 - (string length of decrypted text) For example, 1234's length is 4, 16 - 4 = 12 = 0c in hex so it gets filled with that. (313233340c0c0c0c0c0c0c0c0c0c0c0c) For example, 12345's length is 5, 16 - 5 = 11 = 0b in hex so it gets filled with that.(31323334350b0b0b0b0b0b0b0b0b0b0b) So what needs to be done to prevent openSSL API [I'm using AES_cbc_encrypt()] to prevent it from writing this strange junk at the end? Block ciphers can only encrypt a multiple of the block length which for AES is 16 bytes. Padding is added to ubambiguously represent the true length. The standard OpenSSL EVP routines (see manual pages) automatically remove this padding (which BSAFE is adding, not OpenSSL) whereas the low level AES routines decrypt the raw data including padding. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: migrating from bsafe to openSSL
The 'junk' on the end is PKCS padding. Since AES is a block cipher, it needs to operate on multiples of the block size (16 bytes, or 128 bits). PKCS padding specifies that the final set of bytes are each set to the number of bytes of padding -- in the 0c case, that's 12 bytes of padding; in the 0b case, that's 11 bytes of padding; in the 0a case, that's 10 bytes of padding. If the number of bytes of padding specified by the last byte is repeated that number of times prior (including itself), then those are all padding bytes. 31 32 33 34 35 36 37 38 39 30 06 06 06 06 06 06 That would be: 1234567890[pad*6] However: 30 31 32 33 34 35 36 37 38 39 03 03 03 01 06 05 would be: 0 1 2 3 4 5 6 7 8 9 ^c ^c ^c ^a ^f ^e because the last 5 bytes don't match. (In such a case, there will often -- but not always -- be a full block of padding afterward: 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f This is to prevent a truncation attack.) I'm pretty sure there's a way to disable this form of padding, but the block must be padded with *something* (either NUL bytes [0x00], or the number of bytes of padding inserted) or else the block cannot be encrypted. -Kyle H On Apr 1, 2009, at 3:37 AM, m r wrote: I'm looking to migrate AES encryption code from BSAFE to openSSL. As a test, I encrypted a string using BSAFE AES tried to decrypt using AES of openSSL. The openSSL manages to decrypt, but it adds some junk (mostly unprintable characters) in the end. For example, if my input is 1234, the decrypted output in hex form is [313233340c0c0c0c0c0c0c0c0c0c0c0c], (31323334 is 1234 in hex form). For 12345 - [31323334350b0b0b0b0b0b0b0b0b0b0b] For 123456 - [3132333435360a0a0a0a0a0a0a0a0a0a] Basically, the junk after the decrypted text is 16 - (string length of decrypted text) For example, 1234's length is 4, 16 - 4 = 12 = 0c in hex so it gets filled with that. (313233340c0c0c0c0c0c0c0c0c0c0c0c) For example, 12345's length is 5, 16 - 5 = 11 = 0b in hex so it gets filled with that.(31323334350b0b0b0b0b0b0b0b0b0b0b) So what needs to be done to prevent openSSL API [I'm using AES_cbc_encrypt()] to prevent it from writing this strange junk at the end? Thanks -Mahesh smime.p7s Description: S/MIME cryptographic signature
OpenSSL 1.0.0 beta 1 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.0 Beta 1 OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL is currently in a release cycle. The first beta is now released. The beta release is available for download via HTTP and FTP from the following master locations (the various FTP mirrors you can find under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The file names of the beta are: o openssl-1.0.0-beta1.tar.gz MD5 checksum: 49f265d9dd8dc011788b34768f63313e SHA1 checksum: 89b4490b6091b496042b5fe9a2c8a9015326e446 The checksums were calculated using the following command: openssl md5 openssl-1.0.0-beta1.tar.gz openssl sha1 openssl-1.0.0-beta1.tar.gz Please download and test them as soon as possible. This new OpenSSL version incorporates 107 documented changes and bugfixes to the toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES). Reports and patches should be sent to openssl-b...@openssl.org. Discussions around the development of OpenSSL should be sent to openssl-...@openssl.org. Anything else should go to openssl-us...@openssl.org. The best way, at least on Unix, to create a report is to do the following after configuration: make report That will do a few basic checks of the compiler and bc, then build and run the tests. The result will appear on screen and in the file testlog. Please read the report before sending it to us. There may be problems that we can't solve for you, like missing programs. Oh and to those who have noticed the date... the joke is that it isn't a joke. Yours, The OpenSSL Project Team... Mark J. Cox Ben Laurie Andy Polyakov Ralf S. Engelschall Richard Levitte Geoff Thorpe Dr. Stephen Henson Bodo Möller Ulf Möller Lutz JänickeNils Larsch -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEVAwUBSdNEV6LSm3vylcdZAQIc4gf+Ki9AQzfwES4Up5QRKJCONzIvgIzHpajQ laGz0L6QQXcMrSrLxubSMfYnnXqX/BfY67C28dLaefEK9xygZMxvbS5d56hm3+3m SWLWXqHsCrxp4LWm3Kr7senmhBl06LCTYX1AC2VP0ph/UfouQPu15UkuMCt6eDV7 SEUkYDk6TA8Wr7C0nMHnTOQdqx6r/N7OnPEaCCWkMzsMC5KxTkCP9/SGrDam29dt xV6P5+AntSgNbr9tXYAiQHgMvut9o1O8pTaGdlv2TJ/Ua2ynvmd8hsaO7Ptl3Tpt Bkaghk+rV3qZgLzWAiHjeebEWyXTSGvMPKM6r5mi8vrqjfbSF4zUKA== =qESg -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
答复: How to make X.509v3 digital certificate?
Thanks very much! I am a newbie to use openssl! -邮件原件- 发件人: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 代表 Kyle Hamilton 发送时间: 2009年3月30日 15:37 收件人: openssl-users@openssl.org 主题: Re: How to make X.509v3 digital certificate? Oh man, newbie question, which means that someone doesn't understand how X.509 is supposed to work. The simplest answer is this: 'openssl req' and 'openssl x509', along with 'openssl ca', will create X.509v3 certificates (we don't bother with the 'digital', because there's only one case where we've needed to deal with a physical certificate in all the years I've been on this list -- and that was the FIPS validation certificate). However, this isn't even scratching the surface, because X.509 (all of the versions, v3 being the latest) is a way of creating a trusted path -- meaning, a verified path of trust that started at a trusted entity. You can always trust yourself (unless you can't, but that's a problem FAR beyond the technical realm and into the psychotheraputic realm), but who else can you trust? Fortunately (or unfortunately), different companies have decided different sets of companies that most users trust by default, in their browsers. These are known as Certifying Authorities, or CAs. Mozilla's list of CAs is different from Microsoft's list is different from Apple's list is different from Opera's list is different from KDE's list is different from Ubuntu's list is different from Debian's list is different from... and on and on and on. (No, I don't have a list of the subset of all CAs which is trusted by all of them.) Depending on your application, you may not actually need to worry about CAs, since you might be doing as Linden Lab (and others) have done, creating your own CA and issuing certificates to your own internal entities. If this is the case, great! OpenSSL can (most likely) serve your purpose entirely, with a bit/lot of configuration on your part. If you need to create a certificate for a webserver that's going to be open to the public, 'openssl req' will be able to help you, and will create a certificate signing request (CSR, or req) that you can send to the CA that you choose, and receive an X.509v3 certificate from them which will verify to be on a trusted path. (This, combined with the private key that only you possess, will provide verification that your webserver is actually yours.) Now, a word as to what a certificate is NOT: The keysize of a certificate IS NOT a way to gauge the strength of the encryption process used. (This is why SSL has terms like RSA-AES256-SHA1 -- the first is the type of public key (in the certificate) used to authenticate the connection, the second is the type of symmetric cipher in use, and the third is the type of hashing algorithm used to verify that the data hasn't been modified in-transit.) In general, longer keysizes on AES are considered to be 'more secure' (read, 'less likely to have the plaintext recovered, and less likely to have the key recovered') -- and you should not be using DES at all. (3DES, though, is okay -- at least for now.) For more information on X.509 and its relationship to cryptography in general, I recommend the Wikipedia articles: http://en.wikipedia.org/wiki/X.509 http://en.wikipedia.org/wiki/Public_key_certificate For more information on public-key cryptography in general (which is the technology which allows X.509 certificates to be verified and trusted as authentic, in a mathematical way that these words in your email box cannot): http://en.wikipedia.org/wiki/Category:Public-key_cryptography And, for SSL/TLS: http://en.wikipedia.org/wiki/Transport_Layer_Security This should provide you with enough information to at the least understand the depth of the problem, the scope of the problem, and the breadth of the problem. (The problem that X.509 is supposed to resolve is *authentication* -- making sure that the signature on the content is authentic. It only provides security as far as knowing who signed it provides security. You must still make an independent trust decision about whether you trust any given authenticated entity for any given thing that it is asking for permission to do.) -Kyle H On Sun, Mar 29, 2009 at 9:00 PM, shawnlau net17sharp...@163.com wrote: Hi all! I just want to know how to make the X.509v3 digital certificate with openssl-0.9.8j, if it’s impossible ? Thanks a lot and Best regards! Shawn __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ NOD32 3979 (20090331) Information __ This message was checked by NOD32 antivirus system. http://www.nod32cn.com __ OpenSSL Project
RE: openssl smime ... [-md digest] ... seems to be unknown option ontle last version openssl
Thank you, after modification crypto/pkcs7/pk7_smime.c (calling EVP_sha256 instead EVP_sha1 on PKCS7_sign()) signature really containts digest by sha256 and verification of this signature is successful. Great. It is the simplest way how to still use openssl by command line only. -- But what about the future? Digest algorithm SHA-1 will be marked as unusable on EU from 1.1.2010 (because security experts expects breaking SHA-1 soon). Will non-modified openssl on command line still create only SHA-1 signatures (PKCS#7)? Or will non-modified openssl on command line offer choosing digest algorithm e.g. by implementation -md option what is mentioned on http://www.openssl.org/docs/apps/smime.html#? Thanks, V. Benes -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Paul Allen Sent: Tuesday, March 31, 2009 7:38 PM To: openssl-users@openssl.org Subject: Re: openssl smime ... [-md digest] ... seems to be unknown option ontle last version openssl On Tue, 2009-03-31 at 08:50 -0700, Beneš Vladimír wrote: Hi, there is mentioned command option -md on official documentation - http://www.openssl.org/docs/apps/smime.html# SYNOPSIS openssl smime ... [-md digest] ... ... COMMAND OPTIONS ... -md digest digest algorithm to use when signing or resigning. If not present then the default digest algorithm for the signing key will be used (usually SHA1). ... But if I try to use it (in the latest version - OpenSSL 0.9.8k 25 Mar 2009), it seems that this is quite unknown option (it only puts into stderr available options - without -md option). So how option -md could by used in openssl smime? Or - how could be created and verificated PKCS#7 signatures with the sha512 (or sha256) message digest algorithm? As you have noticed, apps/smime.c doesn't implement the -md command-line switch. The bit of code that actually specifies the message digest to use for signing is in PKCS7_sign() in crypto/pkcs7/pk7_smime.c. It is hard-coded to use SHA1. I changed EVP_sha1 to EVP_sha256 in the call to PKCS7_add_signature(), and it seems to work fine. (By that, I mean SHA256 is actually getting used and signatures verify OK.) There's almost certainly a better way to go about this, but I didn't need a general solution to the command-line problem. Paul __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org smime.p7s Description: S/MIME cryptographic signature
RE: openssl smime ... [-md digest] ... seems to be unknown option ontle last version openssl
Thank you, after modification crypto/pkcs7/pk7_smime.c (calling EVP_sha256 instead EVP_sha1 on PKCS7_sign()) signature really containts digest by sha256 and verification of this signature is successful. Great. It is the simplest way how to still use openssl by command line only. -- But what about the future? Digest algorithm SHA-1 will be marked as unusable on EU from 1.1.2010 (because security experts expects breaking SHA-1 soon). Will non-modified openssl on command line still create only SHA-1 signatures (PKCS#7)? Or will non-modified openssl on command line offer choosing digest algorithm e.g. by implementation -md option what is mentioned on http://www.openssl.org/docs/apps/smime.html#? Thanks, V. Benes -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Paul Allen Sent: Tuesday, March 31, 2009 7:38 PM To: openssl-users@openssl.org Subject: Re: openssl smime ... [-md digest] ... seems to be unknown option ontle last version openssl On Tue, 2009-03-31 at 08:50 -0700, Beneš Vladimír wrote: Hi, there is mentioned command option -md on official documentation - http://www.openssl.org/docs/apps/smime.html# SYNOPSIS openssl smime ... [-md digest] ... ... COMMAND OPTIONS ... -md digest digest algorithm to use when signing or resigning. If not present then the default digest algorithm for the signing key will be used (usually SHA1). ... But if I try to use it (in the latest version - OpenSSL 0.9.8k 25 Mar 2009), it seems that this is quite unknown option (it only puts into stderr available options - without -md option). So how option -md could by used in openssl smime? Or - how could be created and verificated PKCS#7 signatures with the sha512 (or sha256) message digest algorithm? As you have noticed, apps/smime.c doesn't implement the -md command-line switch. The bit of code that actually specifies the message digest to use for signing is in PKCS7_sign() in crypto/pkcs7/pk7_smime.c. It is hard-coded to use SHA1. I changed EVP_sha1 to EVP_sha256 in the call to PKCS7_add_signature(), and it seems to work fine. (By that, I mean SHA256 is actually getting used and signatures verify OK.) There's almost certainly a better way to go about this, but I didn't need a general solution to the command-line problem. Paul __ 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 1.0.0 beta 1 released
OpenSSL wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.0 Beta 1 OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL is currently in a release cycle. The first beta is now released. The beta release is available for download via HTTP and FTP from the following master locations (the various FTP mirrors you can find under http://www.openssl.org/source/mirror.html): Oh and to those who have noticed the date... the joke is that it isn't a joke. Yours, The OpenSSL Project Team... The problem is that I was under the distinct impression 0.9.9 was the next release and 1.0.0 was a pipe dream a few years down the road (at least). Given these conditions, no one is going to believe you just because it IS April 1st. Awfully legitimate looking though. You really should have waited a whole 24 hours for this announcement, assuming it is legit. If this is legit, you're going to have to re-announce it tomorrow (and change the release date on the website). Releasing and announcing real software on April Fool's is a no-no in any marketing book. Releasing fake software would definitely take April Fool's Day jokes to a whole new level. -- Thomas Hruska Shining Light Productions Home of BMP2AVI, Nuclear Vision, ProtoNova, and Win32 OpenSSL. http://www.slproweb.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0 beta 1 released
I will simply remind you of the following piece of the (signed) announcement: Oh and to those who have noticed the date... the joke is that it isn't a joke. -Kyle H __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: migrating from bsafe to openSSL
Thanks for your help. I appreciate the prompt response. On Wed, Apr 1, 2009 at 3:27 PM, Dr. Stephen Henson st...@openssl.orgwrote: On Wed, Apr 01, 2009, m r wrote: I'm looking to migrate AES encryption code from BSAFE to openSSL. As a test, I encrypted a string using BSAFE AES tried to decrypt using AES of openSSL. The openSSL manages to decrypt, but it adds some junk (mostly unprintable characters) in the end. For example, if my input is 1234, the decrypted output in hex form is [313233340c0c0c0c0c0c0c0c0c0c0c0c], (31323334 is 1234 in hex form). For 12345 - [31323334350b0b0b0b0b0b0b0b0b0b0b] For 123456 - [3132333435360a0a0a0a0a0a0a0a0a0a] Basically, the junk after the decrypted text is 16 - (string length of decrypted text) For example, 1234's length is 4, 16 - 4 = 12 = 0c in hex so it gets filled with that. (313233340c0c0c0c0c0c0c0c0c0c0c0c) For example, 12345's length is 5, 16 - 5 = 11 = 0b in hex so it gets filled with that.(31323334350b0b0b0b0b0b0b0b0b0b0b) So what needs to be done to prevent openSSL API [I'm using AES_cbc_encrypt()] to prevent it from writing this strange junk at the end? Block ciphers can only encrypt a multiple of the block length which for AES is 16 bytes. Padding is added to ubambiguously represent the true length. The standard OpenSSL EVP routines (see manual pages) automatically remove this padding (which BSAFE is adding, not OpenSSL) whereas the low level AES routines decrypt the raw data including padding. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0 beta 1 released
Kyle Hamilton wrote: I will simply remind you of the following piece of the (signed) announcement: Oh and to those who have noticed the date... the joke is that it isn't a joke. -Kyle H Doesn't matter if it is signed (I noticed that, BTW). April 1st is all about looking as legit as possible and pulling the big one. The team will still have to re-announce tomorrow. Releasing legitimate news of a product on April 1 (or any holiday for that matter) is a marketing/advertising snafu of gigantic proportions. The entire week that follows a legit April 1 announcement is wasted cleaning up the mess created in its wake. Waiting 24 hours to make such a big release and announcement probably wouldn't kill the team. I wouldn't believe a 0.9.9 release today either, but it would have been less of a stretch of the imagination. -- Thomas Hruska Shining Light Productions Home of BMP2AVI, Nuclear Vision, ProtoNova, and Win32 OpenSSL. http://www.slproweb.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
ssl_connect() fails going to 0.9.8j/k from any previous version with same server/cert
Hi, I looked through the archives and didn't find a similar message. Issue: ssl_connect() now fails with error to same server when changing to 0.9.8j (or 0.9.8k) from any previous version. Server: Tomcast v6018, using self-signed, also tried with Versign-signed Fail message test message decoded to ascii: EOF was observed that violates the protocol. The client probably provided invalid authentication information. NOTE: we are using gSoap v2.7.6c and have asked them. However, we tracked the issue down to ssl_connect() just behaving differently and thought we'd ask here also. Questions/Help: what changed in 0.9.8j that would cause this? Can't find any real mentioned. Any clues to get around this problem? Thanks for any help, Mark Laubach __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ssl_connect() fails going to 0.9.8j/k from any previous version with same server/cert
On Wed, Apr 01, 2009, Mark Laubach wrote: Hi, I looked through the archives and didn't find a similar message. Issue: ssl_connect() now fails with error to same server when changing to 0.9.8j (or 0.9.8k) from any previous version. Server: Tomcast v6018, using self-signed, also tried with Versign-signed Fail message test message decoded to ascii: EOF was observed that violates the protocol. The client probably provided invalid authentication information. NOTE: we are using gSoap v2.7.6c and have asked them. However, we tracked the issue down to ssl_connect() just behaving differently and thought we'd ask here also. Questions/Help: what changed in 0.9.8j that would cause this? Can't find any real mentioned. Any clues to get around this problem? Possibly TLS extensions. You can turn these off at compile time or runtime. See previous discussions for more info. They were enabled by default in 0.9.8j onwards which chokes some broken servers (including ancient versions of OpenSSL). Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
What allocates and what doesn't
Are there any hard and fast rules regarding which openssl functions allocate memory which they expect the caller to then manage and which ones just return a pointer to an existing structure? I'm thinking about things like X509_get_issuer_name, X509_get_subject_name (which, I think, return pointers), and X509_get_serialNumber (which seems to return a copy).
Re: What allocates and what doesn't
On Wed, Apr 01, 2009, Rene Hollan wrote: Are there any hard and fast rules regarding which openssl functions allocate memory which they expect the caller to then manage and which ones just return a pointer to an existing structure? I'm thinking about things like X509_get_issuer_name, X509_get_subject_name (which, I think, return pointers), and X509_get_serialNumber (which seems to return a copy). Well newer functions with a '1' in them allocate, ones with a '0' do not. Some older functions were written before this convention though. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0 beta 1 released
On Wednesday 01 April 2009 09:05:05 Thomas J. Hruska wrote: The problem is that I was under the distinct impression 0.9.9 was the next release and 1.0.0 was a pipe dream a few years down the road (at least). The choice of a 1.0 release is to clearly mark the fact that openssl is shifting to a common base platform, namely Java. Platform independence is going to make future development much easier, but represents a significant enough change to warrant the new major version. This decision has been driven by increasing demands to support as-yet unsupported platforms; primarily Amiga, Z80, Casiotone, and Windows. Regards, Geoff -- Un terrien, c'est un singe avec des clefs de char... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL 1.0.0 beta 1 released
This is an April Fools' joke, right? -Original Message- From: owner-openssl-us...@openssl.org on behalf of Geoff Thorpe Sent: Wed 4/1/2009 12:11 PM To: openssl-users@openssl.org Subject: Re: OpenSSL 1.0.0 beta 1 released On Wednesday 01 April 2009 09:05:05 Thomas J. Hruska wrote: The problem is that I was under the distinct impression 0.9.9 was the next release and 1.0.0 was a pipe dream a few years down the road (at least). The choice of a 1.0 release is to clearly mark the fact that openssl is shifting to a common base platform, namely Java. Platform independence is going to make future development much easier, but represents a significant enough change to warrant the new major version. This decision has been driven by increasing demands to support as-yet unsupported platforms; primarily Amiga, Z80, Casiotone, and Windows. Regards, Geoff -- Un terrien, c'est un singe avec des clefs de char... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org winmail.dat
SSL_CTX_use_certificate_file with UTF8 certificate file name
I have generated programatically a certificate using _tfopen and PEM_write_X509 in order to support unicode for certificate file names. How can I load a certificate in this case? SSL_CTX_use_certificate_file doesn't work in my case. Thanks in advance. -- View this message in context: http://www.nabble.com/SSL_CTX_use_certificate_file-with-UTF8-certificate-file-name-tp22829318p22829318.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_CTX_use_certificate_file with UTF8 certificate file name
On Wed, Apr 01, 2009, AnneB wrote: I have generated programatically a certificate using _tfopen and PEM_write_X509 in order to support unicode for certificate file names. How can I load a certificate in this case? SSL_CTX_use_certificate_file doesn't work in my case. You can read the certificate into an X509 structure using PEM_read_X509() and then SSL_CTX_use_certificate(). Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Openssl doubt SSL_Write
Hi All! I've have some doubts regarding SSL_write in non blocking mode.. 1. if SSL_write returned SSL_ERROR_WANT_WRITE, it is mentioned that the call has to be repeated with the same arguments. Does this means the same buffer to be used again?? or the data passed in the initial SSL_write call will be buffered by the SSL layer? The arguments must be exactly the same in the default mode. If you set 'accept moving write buffer' (which you should) then only the data needs to be the same, the pointer can be different. 2. In case of SSL_write returning SSL_ERROR_WANT_READ due to re-negotiation, What are the steps to be followed? It depends what you want to do. All you know is that the state of the SSL connection is data must be read from the socket before a read of application data will succeed. Is there any wait needed before the repeated SSL_write call? That's up to you. You can call SSL_write immediately again if you want, but it is unlikely to succeed and will probably waste some CPU. But it's legal. Does the application need to take care of the re-negotiation? Yes and no. Then OpenSSL library will not do anything unless you tell it to. But you don't have to call any special do the re-negotiation function. In fact, technically, you don't really know it's negotiation that's needed. All you know is that *something* is needed. When you call SSL_read or SSL_write, it will do whatever's needed, whether or not that's a re-negotiation. Does the application need to wait for the re-negotiation to complete before repeating the SSL_write? If it does, it will be waiting a long time. Since OpenSSL can't do anything until the application calls one of its functions. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
