Cross compiling openssl-fips-1.2 for arm-linux
I'm trying to build openssl-fips-1.2 for an Arm XSCALE 255 running a debian-based linux filesystem. Build system is an x86-Knoppix machine. I've applied the openssl-fips-1.2.crossbuild.patch as advised in the User Manual and Security Policy. After setting $CROSS_COMPILE and $HOSTCC as needed, I am running into a problem during the build where fipsld is trying to generate a signature. Here's the error:make[2]: Entering directory`/hda1/softw-local/uadmas/openssl/openssl-build/openssl-fips-1.2'fips/fipsld: line 121: fips/../fips/fips_premain_dso: cannot execute binaryfileThe file openssl-fips-1.2/fips/fipsld was patched with the following snippet to allow cross-compiling: # generate signature...! if [ -z "${FIPS_SIG}" ]; then! SIG=`"${THERE}/fips/fips_premain_dso" "${TARGET}"`! else! SIG=`"${FIPS_SIG}" -dso "${TARGET}"`! fiNow I'm pretty sure that fips_premain_dso is the wrong path because it is built for the ARM target. I'm having trouble figuring out what $FIPS_SIG should be set to? Do I build an x86 version of fips_premain_dso and point $FIPS_SIG to it? Thanks,Jim/*Jim Rowe*/__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
can TLS be used securely or it is flawed by design not allowing to use it securely (was: Re: Re-negotiation handshake failed: Not accepted by client!?)
Hi, thank you for your detailed explanations. The main thing I still not understood is whether TLS by design enforces the `bad behavior', meaning TLS cannot be used securely at all by anyone, - or - if TLS just does not enforce to use is securely, meaning that TLS relies on application code implementing and using it correctly and reasonable. I moved this topic up to have this question first (or almost first, following right after this paragraph) in the hope to get an answer to it; the rest of this mail unfortunately got so long that it cannot be read because probably it's a waste of time :( [move up from the end] * David Schwartz wrote on Mon, Jan 11, 2010 at 09:06 -0800: If this would be true, this means the information firefox shows up when clicking the lock icon does not tell anything about the data I will sent; at most it can tell about the past, how the page was loaded, but not reliable, because maybe it changed for the last part of the page. Where is my mistaking in thinking? Correct, and to the extent TLS permits a renegotiation to reduce the security parameters without confirming the intention to reduce those parameters at the current level, TLS is broken. Is TLS broken or is it just used in an unreasonable way? With OpenSSL, for example, I could configure to accept only SHA1 and 3DES (or stronger) and I would be safe to renegotiate to 40 bit something. Isn't it a bug in the application when it does not allow me (its user) to configure it? As far as I know there is no way to tell Firefox i.e. not to accept 40 bit. That is, if the two ends negotiate 1,024-bit RSA and 256-bit AES, then an attacker should not be able to renegotiate a lower (or different) security within that connection without having to break either 1,024-bit RSA, 256-bit AES, or one of the hard algorithms inside TLS itself (such as SHA1). TLS permitted an attacker to do this, and so was deemed broken. Is it possible for an application to use an ideal TLS implementation in a way to at least detect this? Like having some OpenSSL callback be called reliably on (right after?) each renegiotation - where a webserver could force to shutdown the connection if the new parameters are not acceptable? [original start of mail] * David Schwartz wrote on Mon, Jan 11, 2010 at 09:06 -0800: I think since TLS should be considered a layer, its payload should not make any assumptions to it (or vice versa). But in the moment some application `looks to the TLS state' and tries to associate this information to some data in some buffer, I think it makes a mistake. Well then TLS is basically useless. A secure connection whose properties I cannot trust is not particularly useful. If I receive foo over the connection and cannot ever know where the middle o came from, what can I do with the foo? Anser -- nothing. I think `trust' is not an absolute but a relative thing. Someone may trust rapidSSL certified 40 bit key connections sufficient to login into myspace via her own Wifi network, but not at all sufficient for online banking. Someone could expect whenever a browers window or `tab' is operating in some extended validation mode. If a server uses TLS to authenticate a client, a client certificate is needed. If the server delegates the authentication and authorisation both to TLS (which means, that such a server or HTTPS server port could not be used without a valid client certificate), as far as I understood no renegiotation attack would be possible. Did I understand correctly (or could client-certificate-based authentication be attacked as well)? As far as I understood the renegiotation attack bases on the fact that the server does not TLS-authenticate the client but relies on the assumption that it will talk to the same client during the whole connection / HTTP session. (I assume that the server is able to detect when a client certificate changes within renegiotation, if a client certificate change is possible at all - and is able to refuse that. So if a server does not perform client authenticate [using client certificates as TLS offers] the server cannot know the the middle o came from.). I think with TLS-authentication this type or renegiotation attack won't work or would at least be detectable because the client certificates Subject/CN or key changes. Is this correct? When using HTTP over IPSec, I think no one ever had the idea to open or block URLs based on the currently used IPSec certificate... I'm not sure I get the point of your analogy. ohh sorry. I hope I wasn't too confused. Or I'm just wrong. Unfortunately I need a longer explanation trying to tell what I mean: Similar, as I understood, the idea to the requirement for a client certificate on an existing connection when the higher layer protocol or higher application level demands that, for example, when HTTP browsing a specific sub directory. As I understand it, this is like trying to add security retroactively.
impact of client certificates to re-negotiation attack (was: Re: Re-negotiation handshake failed: Not accepted by client!?)
Hi, thank you too for the detailed explanation. But the impact on the client certificates (and its correct validation etc) is not clear to me (so I ask inline in the second half of this mail). * Kyle Hamilton wrote on Mon, Jan 11, 2010 at 14:28 -0800: The most succinct answer is this: the server and client cryptographically only verify the session that they renegotiate within at the time of initial negotiation, and never verify that they're the same two parties that the session was between at the time of renegotiation. [...] The worst thing about this attack is that it provides no means for either the client or server to detect it. As I understood, TLS implementations are not responsible to authorize a peer, just to cryptographically ensure that the identification of it is authentic. This is the same question I asked in my other reply to David's mail: Is it by design impossible to make an application using (optionally a future version of) OpenSSL to verify that e.g. the `Subject' of the peer's certificate remains constant (and authorized for the requested service)? The client will receive the server's correct certificate, the same way it expects to. The server will receive either the client's correct certificate or no certificate (as the client decides) the same way it expects to. There is no way to identify this attack at the TLS protocol level. But how can this be, wouldn't the TLS protocol level need to see and verify the client certificate? On renegiotation, no callbacks with the new subject are possible to check if this client certificate (authenticated by TLS implementation) is authorized? I thought this data injection attack fails when client certificates would be used correctly. Does it fail or is it possible? But then an attacker needs a valid client certificate, right? But then in turn, by definition, a user presenting a valid client certificate (and who is authorized) is not an attacker but a valid user, isn't she? (alternatively, when it relies on the server not requiring client certificates I think it would not be an TLS design flaw but a missuse: if the client is not authenticated it means the server talks to anyone. If the server talks to anyone, anyone can send [inject] data. In this case I think it would not be a TLS design flaw but a missuse, caused by lazyness and that Twitter registration sends a password by mail or some confirmation link or whatever, but not a generated client certificate [with key]). oki, Steffen -- --[end of message]-8=== About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL Ca
Hi, I'm trying to create a private CA with openssl for my enterprise. I have generated the CA private key and certificate. I have created a key pair and a certificate signing request from a windows pc using kleopatra (key management utility that comes with winpgp). I signed the request with the CA's key and sent the signed certificate to the windows pc and imported the certificate. I exported the public key which I sent to my laptop. I imported the certificate of my CA into my mail client and trusted it. I then imported the public key as exported from the windows pc. It is imported but instead of being put into the People category it's sent in the Others section as it apparently does not fit in any of the other categories. I am therefore unable to send encrypted mail to the windows pc using it's public key as my client will not use it to encrypt. The following are the commands I used in order to get to this point: In order to generate the private key and ca certificate: # openssl req -config openssl.my.cnf -new -x509 -extensions v3_ca -keyout private/myca.key -out certs/myca.crt -days 1825 I converted the request from DER to PEM format using: openssl req -in datareq.p10 -inform der -out datareq.csr In order to sign the request: # openssl ca -config openssl.my.cnf -policy policy_anything -in datareq.csr I'm at a loss at the moment so any help would be appreciated. Thanks , Anton
Re: OpenSSL Ca
Hi, What mail client are you using under Windows? Each mail client has its own storage for private keys (Thunderbird uses local NSS key storage, Outlook uses CSP and IE certificate store). So, since you generated the key outside the scope of the mail client, you will certainly have to create a PKCS#12 file (called also PFX under Windows) containing your private key and its signed certificate and then import this file into your mail client's key storage (for Outlook, you'll have to install the PFX by double-clicking on it). So, everything depends on your mail client and how it will access your private key. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr On 1/12/2010 12:35 PM, Anton Xuereb wrote: Hi, I'm trying to create a private CA with openssl for my enterprise. I have generated the CA private key and certificate. I have created a key pair and a certificate signing request from a windows pc using kleopatra (key management utility that comes with winpgp). I signed the request with the CA's key and sent the signed certificate to the windows pc and imported the certificate. I exported the public key which I sent to my laptop. I imported the certificate of my CA into my mail client and trusted it. I then imported the public key as exported from the windows pc. It is imported but instead of being put into the People category it's sent in the Others section as it apparently does not fit in any of the other categories. I am therefore unable to send encrypted mail to the windows pc using it's public key as my client will not use it to encrypt. The following are the commands I used in order to get to this point: In order to generate the private key and ca certificate: # openssl req -config openssl.my.cnf -new -x509 -extensions v3_ca -keyout private/myca.key -out certs/myca.crt -days 1825 I converted the request from DER to PEM format using: openssl req -in datareq.p10 -inform der -out datareq.csr In order to sign the request: # openssl ca -config openssl.my.cnf -policy policy_anything -in datareq.csr I'm at a loss at the moment so any help would be appreciated. Thanks , Anton -- -- Mounir IDRASSI IDRIX http://www.idrix.fr __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Ca
The Client im trying to import the public key into is Thunderbird 3 on linux. The client on windows is MS outlook with winpgp installed for pgp encryption. The problem is being presented with thunderbird at the moment as I'm trying to import the public key in order to be able to send encrypted emails to the windows machine. Thanks, Anton 2010/1/12 Mounir IDRASSI mounir.idra...@idrix.net Hi, What mail client are you using under Windows? Each mail client has its own storage for private keys (Thunderbird uses local NSS key storage, Outlook uses CSP and IE certificate store). So, since you generated the key outside the scope of the mail client, you will certainly have to create a PKCS#12 file (called also PFX under Windows) containing your private key and its signed certificate and then import this file into your mail client's key storage (for Outlook, you'll have to install the PFX by double-clicking on it). So, everything depends on your mail client and how it will access your private key. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr On 1/12/2010 12:35 PM, Anton Xuereb wrote: Hi, I'm trying to create a private CA with openssl for my enterprise. I have generated the CA private key and certificate. I have created a key pair and a certificate signing request from a windows pc using kleopatra (key management utility that comes with winpgp). I signed the request with the CA's key and sent the signed certificate to the windows pc and imported the certificate. I exported the public key which I sent to my laptop. I imported the certificate of my CA into my mail client and trusted it. I then imported the public key as exported from the windows pc. It is imported but instead of being put into the People category it's sent in the Others section as it apparently does not fit in any of the other categories. I am therefore unable to send encrypted mail to the windows pc using it's public key as my client will not use it to encrypt. The following are the commands I used in order to get to this point: In order to generate the private key and ca certificate: # openssl req -config openssl.my.cnf -new -x509 -extensions v3_ca -keyout private/myca.key -out certs/myca.crt -days 1825 I converted the request from DER to PEM format using: openssl req -in datareq.p10 -inform der -out datareq.csr In order to sign the request: # openssl ca -config openssl.my.cnf -policy policy_anything -in datareq.csr I'm at a loss at the moment so any help would be appreciated. Thanks , Anton -- -- Mounir IDRASSI IDRIX http://www.idrix.fr __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: trying to understand ECDHE operations
Dave, I think I have been getting ahead of myself and need to do some more reading. More quick questions, if you don't mind me asking. I have included an answer you gave me months ago regarding Yc. For a 192bit curve, the number of bytes is 50. I imagine one of the bytes is if the point is compressed or uncompressed. (Is that right?) What is the length prefix? Is that what is referred to as PublicValueEncoding in RFC4492? Where can I read about that and how it is set? Thanks for your help, I really appreciate it. Mike First, a caveat: I set up a test to verify my understanding, and found (to my surprise) that s_server at least doesn't try to use the same curve for kECDHE as for aECDSA; it's a separate choice, and defaults to sectp163r2. Are you sure either your server or your client is selecting (forcing) prime192r1 for keyagreement AS WELL AS signing/authentication? That said, I get *49* bytes of ECDH data (Yc), plus a 1-byte length prefix totalling 50, in a ClientKeyExchange message totalling 54, in a (clear) handshake record totalling 59. Combined with other records/messages into a TCP segment etc. If that's not what you got, you did something different. --- On Mon, 1/11/10, Dave Thompson dave.thomp...@princetonpayments.com wrote: From: Dave Thompson dave.thomp...@princetonpayments.com Subject: RE: trying to understand ECDHE operations To: openssl-users@openssl.org Date: Monday, January 11, 2010, 5:48 PM From: owner-openssl-us...@openssl.org On Behalf Of Michael D Sent: Friday, 08 January, 2010 08:53 Based on the old message snippet below, two questions: 1) Are the session keys then used by the symmetric cipher going forward? Or is there another step used to get those keys. Session keys are for symmetric data cipher AND data HMAC. (TLS actually calls the HMAC secret parameter secret although RFC 2104 and IME most other usage calls it key.) For example, if I am using 192 bit ECC, and using AES-128, what do I use for the 128 bit key? Two specified 128bit chunks of TLSPRF(master,otherstuff) where master = TLSPRF(premaster,otherstuff). See RFC 4346 8.1 and 6.3 (and 5) as modified by 4492 5.10. If I used AES 256, would I need a larger number of bits in the ECC curve? You don't NEED it. TLS key derivation generates enough key material, regardless of the size of premaster. However, premaster must contain enough entropy to support the desired security; per Kerckhoff (sp?) everything else is knowable by the attacker. 128bit symmetric is plenty for many years; like Schneier's stake it's stronger than the rest of your system. So AES256 versus 128 should only be needed for interop and/or buzzword compliance -- which can be useful, and (here) doesn't hurt. If you really want 128bit or more security level, you do need to use for keyagreement an EC curve big enough to provide that security level. According to NIST in SP 800-57, EC of 2N bits is roughly equivalent to symmetric of N bits, so even for full AES128 you should be using EC=256. But you may find other experts with different judgements. And you must also have enough good random-data generation involved (in ECDHE transients, or as noted static-ECDH nonces). I believe in practice this has more often been a weakness (and successful attack) than actual cryptography. But it's harder to analyze and basically impossible to prove. 2) The last part of the Where can I read about how SSL makes session unique with a nonce, how is that done and or where can I read about it? Much of RFC 4346. Static aka fixed ECDH (or DH) does use the certified key as the server part of keyagreement. Client similarly if client auth i.e. cert is used, which it usually isn't; but even though that gives a fixed (EC)DH result, SSL still makes the sessionkeys unique by adding per-session/handshake nonces. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-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
PKCS#7 enveloped message
Hello,
I need to generate a pkcs#7 certificate with a enveloped message
inside it. As far as I understand this message (X509) will be
encrypted with a random generated TDES key.
This is my snippet, but it is still incomplete and some comments
regarding my doubts, I hope someone could help me!!
//Load rsa key above
data=BIO_new_file(file.txt,r);
recipient=PEM_read_bio_X509(data,NULL,NULL,NULL);
PKCS7_set_type(p7, NID_pkcs7_enveloped);
PKCS7_add_recipient(p7, recipient);
EVP_PKEY_assign_RSA(pkey, rsa); //how will this RSA key be used??
pkey = EVP_PKEY_new();
EVP_PKEY_assign_RSA(pkey, rsa);
PKCS7_set_cipher(p7, EVP_des_ede3_cbc()); //TDES generated here
/*
BIO_puts(data, Hello World!); //so here is my data?
if ((p7bio = PKCS7_dataInit (p7,NULL)) == NULL) goto err;
for (;;){
i=BIO_read(data,buf,sizeof(buf));
if (i = 0) break;
BIO_write(p7bio,buf,i);
}
BIO_flush(p7bio);
PKCS7_dataFinal(p7, p7bio);*/
PEM_write_PKCS7(stdout,p7);
Thanks,
[]s
Douglas Gemignani
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: OpenSSL Ca
Ok - several things: 1: Does the certificate contain both an email address, and EKU of emailProtection? 2: Did you import the CA certificate chain before trying to import the certificate? 3: I presume this certificate is so that you can perform S/MIME encryption - do you have the correct values in Key Usage? ( keyEncipherment, dataEncipherment) What does your openssl.cnf section say for the type of certificate generated? What does your CA Certificate look like? If you want help setting up a CA that just works for most of these different kinds of certificates, you can grab our OpenSSL CA Setup guide (http://www.carillon.ca/library/openssl_testca_howto_1.2.pdf) - it's for the more complex environment of CertiPath/US Federal Bridge interoperability, but it gives you a good idea of what is required for the various profiles of certificates to have them work in various use cases (one size most definitely does NOT fit all, and the stock openssl.cnf isn't sufficient :) Have fun! Patrick. On January 12, 2010 08:23:18 am Anton Xuereb wrote: The Client im trying to import the public key into is Thunderbird 3 on linux. The client on windows is MS outlook with winpgp installed for pgp encryption. The problem is being presented with thunderbird at the moment as I'm trying to import the public key in order to be able to send encrypted emails to the windows machine. Thanks, Anton 2010/1/12 Mounir IDRASSI mounir.idra...@idrix.net Hi, What mail client are you using under Windows? Each mail client has its own storage for private keys (Thunderbird uses local NSS key storage, Outlook uses CSP and IE certificate store). So, since you generated the key outside the scope of the mail client, you will certainly have to create a PKCS#12 file (called also PFX under Windows) containing your private key and its signed certificate and then import this file into your mail client's key storage (for Outlook, you'll have to install the PFX by double-clicking on it). So, everything depends on your mail client and how it will access your private key. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr On 1/12/2010 12:35 PM, Anton Xuereb wrote: Hi, I'm trying to create a private CA with openssl for my enterprise. I have generated the CA private key and certificate. I have created a key pair and a certificate signing request from a windows pc using kleopatra (key management utility that comes with winpgp). I signed the request with the CA's key and sent the signed certificate to the windows pc and imported the certificate. I exported the public key which I sent to my laptop. I imported the certificate of my CA into my mail client and trusted it. I then imported the public key as exported from the windows pc. It is imported but instead of being put into the People category it's sent in the Others section as it apparently does not fit in any of the other categories. I am therefore unable to send encrypted mail to the windows pc using it's public key as my client will not use it to encrypt. The following are the commands I used in order to get to this point: In order to generate the private key and ca certificate: # openssl req -config openssl.my.cnf -new -x509 -extensions v3_ca -keyout private/myca.key -out certs/myca.crt -days 1825 I converted the request from DER to PEM format using: openssl req -in datareq.p10 -inform der -out datareq.csr In order to sign the request: # openssl ca -config openssl.my.cnf -policy policy_anything -in datareq.csr I'm at a loss at the moment so any help would be appreciated. Thanks , Anton -- -- Mounir IDRASSI IDRIX http://www.idrix.fr __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Ca
Hi Anton, I don't know if my article can help you, but you can find what I wrote here about OpenSSL CA and Thunderbird (I am sorry for my poor English) here: http://www.homeworks.it/Html/OpenSSL_PKI_Articolo_Eng.html#InstEMailCert Bye, Alex Anton Xuereb wrote: Hi, I'm trying to create a private CA with openssl for my enterprise. I have generated the CA private key and certificate. I have created a key pair and a certificate signing request from a windows pc using kleopatra (key management utility that comes with winpgp). I signed the request with the CA's key and sent the signed certificate to the windows pc and imported the certificate. I exported the public key which I sent to my laptop. I imported the certificate of my CA into my mail client and trusted it. I then imported the public key as exported from the windows pc. It is imported but instead of being put into the People category it's sent in the Others section as it apparently does not fit in any of the other categories. I am therefore unable to send encrypted mail to the windows pc using it's public key as my client will not use it to encrypt. The following are the commands I used in order to get to this point: In order to generate the private key and ca certificate: # openssl req -config openssl.my.cnf -new -x509 -extensions v3_ca -keyout private/myca.key -out certs/myca.crt -days 1825 I converted the request from DER to PEM format using: openssl req -in datareq.p10 -inform der -out datareq.csr In order to sign the request: # openssl ca -config openssl.my.cnf -policy policy_anything -in datareq.csr I'm at a loss at the moment so any help would be appreciated. Thanks , Anton -- Alessandro Tani Email: alessandro.t...@gmail.com Personal Web Page: http://www.homeworks.it Follow me on Twitter: http://twitter.com/Alessandro_Tani __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: PKCS#7 enveloped message
On Tue, Jan 12, 2010, Douglas Gemignani wrote:
Hello,
I need to generate a pkcs#7 certificate with a enveloped message
inside it. As far as I understand this message (X509) will be
encrypted with a random generated TDES key.
This is my snippet, but it is still incomplete and some comments
regarding my doubts, I hope someone could help me!!
//Load rsa key above
data=BIO_new_file(file.txt,r);
recipient=PEM_read_bio_X509(data,NULL,NULL,NULL);
PKCS7_set_type(p7, NID_pkcs7_enveloped);
PKCS7_add_recipient(p7, recipient);
EVP_PKEY_assign_RSA(pkey, rsa); //how will this RSA key be used??
pkey = EVP_PKEY_new();
EVP_PKEY_assign_RSA(pkey, rsa);
PKCS7_set_cipher(p7, EVP_des_ede3_cbc()); //TDES generated here
/*
BIO_puts(data, Hello World!); //so here is my data?
if ((p7bio = PKCS7_dataInit (p7,NULL)) == NULL) goto err;
for (;;){
i=BIO_read(data,buf,sizeof(buf));
if (i = 0) break;
BIO_write(p7bio,buf,i);
}
BIO_flush(p7bio);
PKCS7_dataFinal(p7, p7bio);*/
PEM_write_PKCS7(stdout,p7);
Look at the PKCS7_encrypt() manual page and demos/smime/smenc.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
Re: OpenSSL Ca
Ok - several things: 1: Does the certificate contain both an email address, and EKU of emailProtection? 2: Did you import the CA certificate chain before trying to import the certificate? 3: I presume this certificate is so that you can perform S/MIME encryption - do you have the correct values in Key Usage? ( keyEncipherment, dataEncipherment) What does your openssl.cnf section say for the type of certificate generated? What does your CA Certificate look like? If you want help setting up a CA that just works for most of these different kinds of certificates, you can grab our OpenSSL CA Setup guide (http://www.carillon.ca/library/openssl_testca_howto_1.2.pdf) - it's for the more complex environment of CertiPath/US Federal Bridge interoperability, but it gives you a good idea of what is required for the various profiles of certificates to have them work in various use cases (one size most definitely does NOT fit all, and the stock openssl.cnf isn't sufficient :) Have fun! Patrick. On January 12, 2010 08:23:18 am Anton Xuereb wrote: The Client im trying to import the public key into is Thunderbird 3 on linux. The client on windows is MS outlook with winpgp installed for pgp encryption. The problem is being presented with thunderbird at the moment as I'm trying to import the public key in order to be able to send encrypted emails to the windows machine. Thanks, Anton 2010/1/12 Mounir IDRASSI mounir.idra...@idrix.net Hi, What mail client are you using under Windows? Each mail client has its own storage for private keys (Thunderbird uses local NSS key storage, Outlook uses CSP and IE certificate store). So, since you generated the key outside the scope of the mail client, you will certainly have to create a PKCS#12 file (called also PFX under Windows) containing your private key and its signed certificate and then import this file into your mail client's key storage (for Outlook, you'll have to install the PFX by double-clicking on it). So, everything depends on your mail client and how it will access your private key. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr On 1/12/2010 12:35 PM, Anton Xuereb wrote: Hi, I'm trying to create a private CA with openssl for my enterprise. I have generated the CA private key and certificate. I have created a key pair and a certificate signing request from a windows pc using kleopatra (key management utility that comes with winpgp). I signed the request with the CA's key and sent the signed certificate to the windows pc and imported the certificate. I exported the public key which I sent to my laptop. I imported the certificate of my CA into my mail client and trusted it. I then imported the public key as exported from the windows pc. It is imported but instead of being put into the People category it's sent in the Others section as it apparently does not fit in any of the other categories. I am therefore unable to send encrypted mail to the windows pc using it's public key as my client will not use it to encrypt. The following are the commands I used in order to get to this point: In order to generate the private key and ca certificate: # openssl req -config openssl.my.cnf -new -x509 -extensions v3_ca -keyout private/myca.key -out certs/myca.crt -days 1825 I converted the request from DER to PEM format using: openssl req -in datareq.p10 -inform der -out datareq.csr In order to sign the request: # openssl ca -config openssl.my.cnf -policy policy_anything -in datareq.csr I'm at a loss at the moment so any help would be appreciated. Thanks , Anton -- -- Mounir IDRASSI IDRIX http://www.idrix.fr __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
[FWD] RE: Help Request
Forwarded to openssl-users for public discussion.
Best regards,
Lutz
- Forwarded message from Vincenzo Giarratana
vincenzo.giarrat...@gmail.com -
From: Vincenzo Giarratana vincenzo.giarrat...@gmail.com
To: r...@openssl.org
Subject: RE: Help Request
Date: Tue, 12 Jan 2010 17:57:02 +0100
Thread-Index: AcqToX9nGNbClrvkRoCvNYvYVzWmuQAABiAgAABPPXA=
In-Reply-To:
Hi,
following my previous request, let me add a fragment of the VLC source code,
the line where I got the compiler error is:
dialog_Fatal( p_input, _(Streaming / Transcoding failed), %s,
_(VLC could not open the packetizer module.) );
this is the function containing the line:
decoder_t *input_DecoderNew( input_thread_t *p_input,
es_format_t *fmt, input_clock_t *p_clock,
sout_instance_t *p_sout )
{
decoder_t *p_dec = NULL;
int i_priority;
#ifdef ENABLE_SOUT
/* If we are in sout mode, search for packetizer module */
if( p_sout )
{
/* Create the decoder configuration structure */
p_dec = CreateDecoder( p_input, fmt, VLC_OBJECT_PACKETIZER, p_sout
);
if( p_dec == NULL )
{
msg_Err( p_input, could not create packetizer );
dialog_Fatal( p_input, _(Streaming / Transcoding failed),
%s,
_(VLC could not open the packetizer module.) );
return NULL;
}
}
..
Thank you for your help
Vincenzo Giarratana
vincenzo.giarrat...@gmail.com
_
From: Vincenzo Giarratana [mailto:vincenzo.giarrat...@gmail.com]
Sent: martedì 12 gennaio 2010 17.11
To: 'r...@openssl.org'
Subject: Help Request
Hi,
I am doing a VLC 1.0.4 build under Ubuntu 9.10.
I did first
sudo apt-get install libssl-dev
then I inserted the following line into VLC decoder.c souce code
#include openssl/des.h
Then I run
./configure LDFLAGS='-lssl -lcrypto'
make
and I got the following error:
input/decoder.c: In function input_DecoderNew:
input/decoder.c:292: error: implicit declaration of function _
input/decoder.c:292: warning: passing argument 2 of dialog_Fatal makes
pointer from integer without a cast
../include/vlc_dialog.h:43: note: expected const char * but argument is of
type int
input/decoder.c:292: warning: format %s expects type char *, but
argument 4 has type int
If I do the make without inserting #include openssl/des.h the compilation
is successfull.
Why this include causes the error: implicit declaration of function _
Is it a bug in the openssl/des.h or in the VLC ?
Thank you for your help
Vincenzo Giarratana
vincenzo.giarrat...@gmail.com
- End forwarded message -
--
Lutz Jaenicke jaeni...@openssl.org
OpenSSL Project http://www.openssl.org/~jaenicke/
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Cross compiling openssl-fips-1.2 for arm-linux
I'm trying to build openssl-fips-1.2 for an Arm XSCALE 255 running a
debian-based linux filesystem. Build system is an x86-Knoppix machine.
I've applied the openssl-fips-1.2.crossbuild.patch as advised in the User
Manual and Security Policy.
After setting $CROSS_COMPILE and $HOSTCC as needed, I am running into a
problem during the build where fipsld is trying to generate a signature.
Here's the error:
make[2]: Entering directory
`/hda1/softw-local/uadmas/openssl/openssl-build/openssl-fips-1.2'
fips/fipsld: line 121: fips/../fips/fips_premain_dso: cannot execute
binary
file
The following section of openssl-fips-1.2/fips/fipsld was patched when I
applied the openssl-fips-1.2.crossbuild.patch:
# generate signature...
! if [ -z ${FIPS_SIG} ]; then
! SIG=`${THERE}/fips/fips_premain_dso ${TARGET}`
! else
! SIG=`${FIPS_SIG} -dso ${TARGET}`
! fi
Now I'm pretty sure that fips_premain_dso is the wrong path because it is
built for the ARM target. I'm having trouble figuring out what $FIPS_SIG
should be set to? Do I build an x86 version of fips_premain_dso and point
$FIPS_SIG to it?
Thanks,
Jim Rowe
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [FWD] RE: Help Request
On Tue, Jan 12, 2010 at 06:19:18PM +0100, Lutz Jaenicke wrote:
Forwarded to openssl-users for public discussion.
Best regards,
Lutz
- Forwarded message from Vincenzo Giarratana
vincenzo.giarrat...@gmail.com -
From: Vincenzo Giarratana vincenzo.giarrat...@gmail.com
To: r...@openssl.org
Subject: RE: Help Request
Date: Tue, 12 Jan 2010 17:57:02 +0100
Thread-Index: AcqToX9nGNbClrvkRoCvNYvYVzWmuQAABiAgAABPPXA=
In-Reply-To:
Hi,
following my previous request, let me add a fragment of the VLC source code,
the line where I got the compiler error is:
dialog_Fatal( p_input, _(Streaming / Transcoding failed), %s,
_(VLC could not open the packetizer module.) );
Maybe the culprit is in openssl/des_old.h:
#ifdef _
#undef _
#endif
try defining OPENSSL_DISABLE_OLD_DES_SUPPORT before
including openssl/des.h
Christian
this is the function containing the line:
decoder_t *input_DecoderNew( input_thread_t *p_input,
es_format_t *fmt, input_clock_t *p_clock,
sout_instance_t *p_sout )
{
decoder_t *p_dec = NULL;
int i_priority;
#ifdef ENABLE_SOUT
/* If we are in sout mode, search for packetizer module */
if( p_sout )
{
/* Create the decoder configuration structure */
p_dec = CreateDecoder( p_input, fmt, VLC_OBJECT_PACKETIZER, p_sout
);
if( p_dec == NULL )
{
msg_Err( p_input, could not create packetizer );
dialog_Fatal( p_input, _(Streaming / Transcoding failed),
%s,
_(VLC could not open the packetizer module.) );
return NULL;
}
}
..
Thank you for your help
Vincenzo Giarratana
vincenzo.giarrat...@gmail.com
_
From: Vincenzo Giarratana [mailto:vincenzo.giarrat...@gmail.com]
Sent: marted? 12 gennaio 2010 17.11
To: 'r...@openssl.org'
Subject: Help Request
Hi,
I am doing a VLC 1.0.4 build under Ubuntu 9.10.
I did first
sudo apt-get install libssl-dev
then I inserted the following line into VLC decoder.c souce code
#include openssl/des.h
Then I run
./configure LDFLAGS='-lssl -lcrypto'
make
and I got the following error:
input/decoder.c: In function ?input_DecoderNew?:
input/decoder.c:292: error: implicit declaration of function ?_?
input/decoder.c:292: warning: passing argument 2 of ?dialog_Fatal? makes
pointer from integer without a cast
../include/vlc_dialog.h:43: note: expected ?const char *? but argument is of
type ?int?
input/decoder.c:292: warning: format ?%s? expects type ?char *?, but
argument 4 has type ?int?
If I do the make without inserting #include openssl/des.h the compilation
is successfull.
Why this include causes the error: implicit declaration of function ?_?
Is it a bug in the openssl/des.h or in the VLC ?
Thank you for your help
Vincenzo Giarratana
vincenzo.giarrat...@gmail.com
- End forwarded message -
--
Lutz Jaenicke jaeni...@openssl.org
OpenSSL Project http://www.openssl.org/~jaenicke/
__
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: PKCS#7 enveloped message
This looks like a recent change in the v1.0.0 beta
*) Update PKCS#7 enveloped data routines to use new API. This is now
supported by any public key method supporting the encrypt operation. A
ctrl is added to allow the public key algorithm to examine or modify
the PKCS#7 RecipientInfo structure if it needs to: for RSA this is
a no op.
[Steve Henson]
I'm still using version 0.9.8k. I rather not use beta editions!
I noticed the magic in the API is encapsulated here now:
in = BIO_new_file(encr.txt, r);
if (!in)goto err;
/* encrypt content */
p7 = PKCS7_encrypt(recips, in, EVP_des_ede3_cbc(), flags);
It probably setups the p7 struct and calls PKCS7_dataInit and PKCS7_dataFinal
[]s
Douglas Gemignani
On Tue, Jan 12, 2010 at 2:59 PM, Dr. Stephen Henson st...@openssl.org wrote:
On Tue, Jan 12, 2010, Douglas Gemignani wrote:
Hello,
I need to generate a pkcs#7 certificate with a enveloped message
inside it. As far as I understand this message (X509) will be
encrypted with a random generated TDES key.
This is my snippet, but it is still incomplete and some comments
regarding my doubts, I hope someone could help me!!
//Load rsa key above
data=BIO_new_file(file.txt,r);
recipient=PEM_read_bio_X509(data,NULL,NULL,NULL);
PKCS7_set_type(p7, NID_pkcs7_enveloped);
PKCS7_add_recipient(p7, recipient);
EVP_PKEY_assign_RSA(pkey, rsa); //how will this RSA key be used??
pkey = EVP_PKEY_new();
EVP_PKEY_assign_RSA(pkey, rsa);
PKCS7_set_cipher(p7, EVP_des_ede3_cbc()); //TDES generated here
/*
BIO_puts(data, Hello World!); //so here is my data?
if ((p7bio = PKCS7_dataInit (p7,NULL)) == NULL) goto err;
for (;;){
i=BIO_read(data,buf,sizeof(buf));
if (i = 0) break;
BIO_write(p7bio,buf,i);
}
BIO_flush(p7bio);
PKCS7_dataFinal(p7, p7bio);*/
PEM_write_PKCS7(stdout,p7);
Look at the PKCS7_encrypt() manual page and demos/smime/smenc.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 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: PKCS#7 enveloped message
On Tue, Jan 12, 2010, Douglas Gemignani wrote: This looks like a recent change in the v1.0.0 beta *) Update PKCS#7 enveloped data routines to use new API. This is now supported by any public key method supporting the encrypt operation. A ctrl is added to allow the public key algorithm to examine or modify the PKCS#7 RecipientInfo structure if it needs to: for RSA this is a no op. [Steve Henson] I'm still using version 0.9.8k. I rather not use beta editions! That's an enhancement to the PKCS7 API which you wont need for your purposes. The support in OpenSSL 0.9.8k and earlier should suffice. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: memory growing when using SSL connections
After running my app for a couple of iterations for over an hour, I get the following: [11:45:42]10 file=stack.c, line=125, thread=15418, number=20, address=20077768 [11:45:47] 8711 file=lhash.c, line=193, thread=15418, number=12, address=20093E38 [11:45:42] 5 file=stack.c, line=125, thread=15418, number=20, address=20077508 [11:45:47] 8180 file=stack.c, line=127, thread=15418, number=16, address=20089848 [11:45:47] 8709 file=stack.c, line=125, thread=15418, number=20, address=20093B48 [11:45:42]23 file=lhash.c, line=193, thread=15418, number=12, address=20077C78 [11:45:42]35 file=ex_data.c, line=304, thread=15418, number=12, address=20088BE8 [11:45:42]12 file=lhash.c, line=193, thread=15418, number=12, address=20077848 [11:45:47] 8181 file=lhash.c, line=193, thread=15418, number=12, address=200898B8 [11:45:42] 7 file=lhash.c, line=193, thread=15418, number=12, address=200775E8 [11:45:42]36 file=stack.c, line=125, thread=15418, number=20, address=20088C58 [11:45:47] 8710 file=stack.c, line=127, thread=15418, number=16, address=20093BB8 [11:45:42]37 file=stack.c, line=127, thread=15418, number=16, address=20088CC8 [11:45:42]22 file=lhash.c, line=121, thread=15418, number=64, address=20077D58 thread=15418, file=err_def.c, line=346, info=int_thread_get (err.c) [11:45:42] 9 file=ex_data.c, line=304, thread=15418, number=12, address=200776F8 [11:45:47] 8178 file=ex_data.c, line=304, thread=15418, number=12, address=20089768 [11:45:47] 8708 file=ex_data.c, line=304, thread=15418, number=12, address=200938C8 [11:45:42]20 file=err_def.c, line=629, thread=15418, number=396, address=200779F8 [11:45:42]38 file=lhash.c, line=193, thread=15418, number=12, address=20088D38 [11:45:42] 4 file=ex_data.c, line=304, thread=15418, number=12, address=20077498 [11:45:42]21 file=lhash.c, line=119, thread=15418, number=96, address=20077C98 thread=15418, file=err_def.c, line=346, info=int_thread_get (err.c) [11:45:47] 8179 file=stack.c, line=125, thread=15418, number=20, address=200897D8 [11:45:42]11 file=stack.c, line=127, thread=15418, number=16, address=200777D8 [11:45:42] 6 file=stack.c, line=127, thread=15418, number=16, address=20077578 868 bytes leaked in 24 chunks However, I get the same info over and over again (same time stamps), no matter the amount of iterations. I believe this shows that there is no continuous memory leak in SSL. The 868 bytes reported as a leak by CRYPTO_mem_leaks_fp() appears to be some initial memory that has been allocated for the life of the application. Thanks, David -- From: Dr. Stephen Henson st...@openssl.org Sent: Monday, January 11, 2010 7:17 PM To: openssl-users@openssl.org Subject: Re: memory growing when using SSL connections On Mon, Jan 11, 2010, David wrote: Kevin, Valgrind apparently is a Linux based tool, but I'm having this problem on AIX. I actually have a simple memory leak finder that showed that SSL did not have an obvious memory leak. It looks like most, if not all memory management functions for SSL goes thru CRYPTO_malloc(), CRYPTO_realloc() and CRYPTO_free() and their variants. I found a couple of calloc()s elsewhere, but it looks like everything else got covered in these functions. So pretty much, when memory is allocated (or reallocated) I put it on a linked list. When it is freed, I remove it from the list. After all my sessions have stopped, I see that my linked list hasn't grown from the previous run. I'm a bit suspicious about the realloc()s, since this is can be a source of memory fragmentation. However, what is curious is that I don't see this problem on Solaris. IBM has a product called PURIFYPLUS for detecting memory leaks. Perhaps I'll see if I can run it with the application and see if it shows up anything. OpenSSL has some built in leak detection. If you call something like: MemCheck_start(); before a leaking section then: CRYPTO_mem_leaks_fp(stderr); after you think you've freed everything up you should get some useful results if the leak is internal to OpenSSL. The output takes a bit of getting used to (I usually run it twice setting breakpoints) but can be very useful. 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: impact of client certificates to re-negotiation attack (was: Re: Re-negotiation handshake failed: Not accepted by client!?)
Responses inline. :) On Tue, Jan 12, 2010 at 3:12 AM, Steffen DETTMER steffen.dett...@ingenico.com wrote: Hi, thank you too for the detailed explanation. But the impact on the client certificates (and its correct validation etc) is not clear to me (so I ask inline in the second half of this mail). * Kyle Hamilton wrote on Mon, Jan 11, 2010 at 14:28 -0800: The most succinct answer is this: the server and client cryptographically only verify the session that they renegotiate within at the time of initial negotiation, and never verify that they're the same two parties that the session was between at the time of renegotiation. [...] The worst thing about this attack is that it provides no means for either the client or server to detect it. As I understood, TLS implementations are not responsible to authorize a peer, just to cryptographically ensure that the identification of it is authentic. This is correct. The problem is that there is an MITM capability that the protocol allows for, which it should not have, and the reason is that the prior cryptographic session is not cryptographically authenticated by the new credentials. This is the same question I asked in my other reply to David's mail: Is it by design impossible to make an application using (optionally a future version of) OpenSSL to verify that e.g. the `Subject' of the peer's certificate remains constant (and authorized for the requested service)? No, for a couple reasons. 1) The IETF has issued a Last Call for the renegotiation-indication proposed standard. 2) It is possible to register a callback function in the SSL or SSL_CTX object, which will iterate every certificate that is presented during a renegotiation. #1 means that the next version of OpenSSL will almost certainly fix the prefix-injection attack scenario. #2 means that you can see *all* of the certificates that the peer presents, and the return value of the function tells the library what to do now that you've seen it -- continue the connection, or abort it. The client will receive the server's correct certificate, the same way it expects to. The server will receive either the client's correct certificate or no certificate (as the client decides) the same way it expects to. There is no way to identify this attack at the TLS protocol level. But how can this be, wouldn't the TLS protocol level need to see and verify the client certificate? On renegiotation, no callbacks with the new subject are possible to check if this client certificate (authenticated by TLS implementation) is authorized? The problem is this: The attacker makes a connection to a TLS-enabled server, sending no certificate. It sends a command that, for whatever reason, needs additional privilege (in Apache's case, Directory and Location clauses can require additional security above what the default VirtualHost configuration negotiates). Then, it just starts proxying packets between the client and the server. When the server receives the request for a higher-authentication-required resource, it sends a ServerHello to initiate a renegotiation. The packets, as they are proxied as-is to the client, are not modified by the attacker in any way. This means that the ServerHello renegotiation is going to negotiate for a client certificate, and the client can't going to know that there's any problem in doing so. One way to deal with this would be to enforce that all access to resources on the same webserver require the same security cloak -- that is, have the server demand a certificate during the initial negotiation, so that *all* data that comes in is authenticated as being from that identity. I thought this data injection attack fails when client certificates would be used correctly. It does, in the event that the server configuration does not allow for non-client-certificated connections in any manner, in any way, for any purpose. THAT is when client certificates are used correctly. Does it fail or is it possible? This attack fails in the presence of client certificates if and only if there is no means to make a connection with no authentication, submit data, and then have the server request additional authentication. But then an attacker needs a valid client certificate, right? If the server requires a valid client certificate on initial negotiation, and the attacker has a valid client certificate, then the attacker is limited to the privileges authorized to that identity and would have the same access privileges as a legitimate user. This attack is used and is useful in the event that different resources on the same server require different levels of authentication, *including no authentication*. If you get rid of the 'allow non-authenticated SSL clients' part of the policy on that server, you do away with the problem. But then in turn, by definition, a user presenting a valid client certificate (and who is authorized) is not an attacker but a
Re: can TLS be used securely or it is flawed by design not allowing to use it securely (was: Re: Re-negotiation handshake failed: Not accepted by client!?)
Responses inline, again. :) On Tue, Jan 12, 2010 at 2:53 AM, Steffen DETTMER steffen.dett...@ingenico.com wrote: The main thing I still not understood is whether TLS by design enforces the `bad behavior', meaning TLS cannot be used securely at all by anyone, - or - if TLS just does not enforce to use is securely, meaning that TLS relies on application code implementing and using it correctly and reasonable. You cannot simply add a security module and expect that your system is secure. The entire application, from the ground up, needs to be security-aware. This means that TLS cannot enforce that it is used correctly -- it can only negotiate keys between itself and its peer, and enforce that the cryptographic signatures on the packets are correct to prevent any mid-stream injection. (It was supposed to prevent any pre-stream injection, too, but the Apache configuration options make it possible to violate that constraint at the request of the application.) I moved this topic up to have this question first (or almost first, following right after this paragraph) in the hope to get an answer to it; the rest of this mail unfortunately got so long that it cannot be read because probably it's a waste of time :( [move up from the end] * David Schwartz wrote on Mon, Jan 11, 2010 at 09:06 -0800: If this would be true, this means the information firefox shows up when clicking the lock icon does not tell anything about the data I will sent; at most it can tell about the past, how the page was loaded, but not reliable, because maybe it changed for the last part of the page. Where is my mistaking in thinking? Correct, and to the extent TLS permits a renegotiation to reduce the security parameters without confirming the intention to reduce those parameters at the current level, TLS is broken. Is TLS broken or is it just used in an unreasonable way? With OpenSSL, for example, I could configure to accept only SHA1 and 3DES (or stronger) and I would be safe to renegotiate to 40 bit something. Isn't it a bug in the application when it does not allow me (its user) to configure it? As far as I know there is no way to tell Firefox i.e. not to accept 40 bit. about:config, search for 'ssl' and 'tls'. By default, Firefox 3.0+ disable 40- and 56-bit ciphers, and I know that either Firefox 3.0 or 3.5 disabled SSLv2 by default. SSLv3 and TLSv1 do not use those ciphers. That is, if the two ends negotiate 1,024-bit RSA and 256-bit AES, then an attacker should not be able to renegotiate a lower (or different) security within that connection without having to break either 1,024-bit RSA, 256-bit AES, or one of the hard algorithms inside TLS itself (such as SHA1). TLS permitted an attacker to do this, and so was deemed broken. No, TLS did not allow an attacker to renegotiate a lower security. TLS didn't even allow for a version rollback attack to force the use of weaker ciphers. TLS *is* allowed to renegotiate to a different level of authentication, and even though I can't think of any time when it's ever used, it's possible to reduce the level of cloaking. What happened is that TLS permitted an attacker to inject arbitrary bytes at the beginning of a connection, and the HTTP servers compounded this problem by allowing different security cloaks on different resources within the same server space. Is it possible for an application to use an ideal TLS implementation in a way to at least detect this? There is currently no way for even an ideal TLS implementation to detect this issue. This is why the IETF is working on the Secure Renegotiation Indication TLS extension, which is close to finally being released. Like having some OpenSSL callback be called reliably on (right after?) each renegiotation - where a webserver could force to shutdown the connection if the new parameters are not acceptable? Yes. Please see SSL_CTX_set_info_callback(3ssl). [original start of mail] * David Schwartz wrote on Mon, Jan 11, 2010 at 09:06 -0800: I think since TLS should be considered a layer, its payload should not make any assumptions to it (or vice versa). But in the moment some application `looks to the TLS state' and tries to associate this information to some data in some buffer, I think it makes a mistake. Well then TLS is basically useless. A secure connection whose properties I cannot trust is not particularly useful. If I receive foo over the connection and cannot ever know where the middle o came from, what can I do with the foo? Anser -- nothing. I think `trust' is not an absolute but a relative thing. Someone may trust rapidSSL certified 40 bit key connections sufficient to login into myspace via her own Wifi network, but not at all sufficient for online banking. I define 'trust' as: you expose some point of vulnerability to the peer, with the belief and expectation that they will not abuse that vulnerability. Someone could expect whenever a browers
Re: Cross compiling openssl-fips-1.2 for arm-linux
On Tue, Jan 12, 2010, jim.r...@sncorp.com wrote:
I'm trying to build openssl-fips-1.2 for an Arm XSCALE 255 running a
debian-based linux filesystem. Build system is an x86-Knoppix machine.
I've applied the openssl-fips-1.2.crossbuild.patch as advised in the User
Manual and Security Policy.
After setting $CROSS_COMPILE and $HOSTCC as needed, I am running into a
problem during the build where fipsld is trying to generate a signature.
Here's the error:
make[2]: Entering directory
`/hda1/softw-local/uadmas/openssl/openssl-build/openssl-fips-1.2'
fips/fipsld: line 121: fips/../fips/fips_premain_dso: cannot execute
binary
file
The following section of openssl-fips-1.2/fips/fipsld was patched when I
applied the openssl-fips-1.2.crossbuild.patch:
# generate signature...
! if [ -z ${FIPS_SIG} ]; then
! SIG=`${THERE}/fips/fips_premain_dso ${TARGET}`
! else
! SIG=`${FIPS_SIG} -dso ${TARGET}`
! fi
Now I'm pretty sure that fips_premain_dso is the wrong path because it is
built for the ARM target. I'm having trouble figuring out what $FIPS_SIG
should be set to? Do I build an x86 version of fips_premain_dso and point
$FIPS_SIG to it?
During a normal build (i.e. not cross compiling) OpenSSL would initially run
the executable or run fips_dso against a shared library. This would output the
signature to standard output and that signature would be used to relink the
target.
When cross compiling this can't be done because you need to run an executable
on the target system to get the signature. So fips_dso is correct but it just
can't be run on the host.
You have two options here.
One is to write a script that copies the files to the target system, executes
them and then returns the signature. The script should be set in the
environment variable FIPS_SIG and usage is:
$FIPS_SIG -dso target_share_library
$FIPS_SIG -exe target_exectutable
Since that process will vary from one system to another we can't write a
general solution for OpenSSL.
The other is to download the incore script from:
http://www.openssl.org/docs/fips/incore.gz
This attempts to do everything on the host system. It should work but during
testing the offset value did need changing sometimes. If you get signature
errors on the target system that's the most likely cause.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: memory growing when using SSL connections
Jeremy, The application still grows intermittently by multiples of 4KB although the memory leak tools provided by SSL and myself shows no memory leaks. The start for the checking of the memory leaks is before the SSL_new() and the actual check is after SSL_free(). It should be noted that on AIX, the process grows quickly initially and then slows down after many iterations and hours, but I need to verify if it actually comes to a halt. On the Solaris platform, the memory size of the process is bigger, but it stops growing almost immediately (after 2 iterations of 124 sessions stopped and restarted) On the AIX platform, it doesn't get that big as quickly, but keeps on growing slowly after many iterations. The pagesize on Solaris is 8192 bytes whereas the pagesize on AIX 4096 bytes which may explain the diff in the memory sizes. Perhaps, as you say, I should use a more general tool for checking this stuff. Thanks, David -- From: Jeremy Hunt jere...@optimation.com.au Sent: Tuesday, January 12, 2010 6:14 PM To: danny33...@bellsouth.net; openssl-users@openssl.org Subject: Re: memory growing when using SSL connections David wrote: [safeTgram (safetgram-in) receive status: NOT encrypted, NOT signed.] After running my app for a couple of iterations for over an hour, I get the following: [11:45:42]10 file=stack.c, line=125, thread=15418, number=20, address=20077768 ... 868 bytes leaked in 24 chunks However, I get the same info over and over again (same time stamps), no matter the amount of iterations. I believe this shows that there is no continuous memory leak in SSL. The 868 bytes reported as a leak by CRYPTO_mem_leaks_fp() appears to be some initial memory that has been allocated for the life of the application. Thanks, David David, I am a bit confused by what you say .. Initially you said the application was growing intermittently in 4KB multiples. Do you see this behaviour when you add Dr Henson's calls? If so then where have you added the calls? I presume inside the loop after SSL_new() and SSL_free(), if all you did previously was remove CRYPTO_cleanup_all_ex_data(). If both of these statements are correct then either CRYPTO_mem_leaks_fp() missed the leak or it really isn't in your SSL code. Yet you say that without the SSL code you get no memory leaks, ... and you get no memory leaks on the Solaris platform. Looks like you may need a more general tool. Valgrind 3.3 does work on some versions of AIX on some hardware (experimentally, apparently), you could try to find a copy of the source, approach the developers or try to build the latest version on AIX. And there is purify or insure++. Some other thoughts that you may have already considered: How large does the memory leak manifest itself? Are there any broken connections hanging around that might keep memory until they timeout? There isn't some AIX kernel tuning parameter that keeps memory that has been freed reported as allocated until another process needs it is there, in other words tuning for a delayed memory cleanup algorithm? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
