Re: Accessing encrypted messages after cert expires
On Sun, Mar 16, 2008 at 10:57 PM, Michael Sierchio [EMAIL PROTECTED] wrote: David Schwartz wrote: If you can't trust the system that generates and stores your private key, you're screwed anyway. So I don't see that this argument has any validity. A timestamp is not an attribute of a private key. It's utterly irrelevant. If your purpose is to require that new certificates bound to an entity upon expiration of old certs have a different key, do that. Multiplying your misunderstanding by zero does not improve matters, even for large values of zero. - M A key's lifetime is, cryptographically speaking, the amount of time for which it can be expected to provide a sane level of security in relation to the value of the data which it protects. Of course, cryptography is just a means of applying a policy to a piece of data. If you share a means of decryption, you also share a piece of trust with whomever you share that means with that they won't violate that policy, even though the policy is advisory (i.e., non-enforceable) once the data is decrypted. A 'creation time' is an attribute of a private key, but it is an attribute which only the key generator and possibly the CA have any reason to find useful. A CA imposes a policy of maximum usage period upon a given identity binding for that key (and puts this in the certificate of identity binding). A key generator imposes a policy of maximum usage period upon a given key, regardless of the valid period of identity binding. Having the timestamp associated with the private key, then, is something that the generator has an interest in. Not having this field as part of PKCS#12 (since, arguably, only the key generator or someone authorized to act on the key generator's behalf has any reason to look at an actual decrypted pkcs12 structure) is, thus, a failure of the format. -Kyle H __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Accessing encrypted messages after cert expires
Kyle Hamilton wrote: On Sun, Mar 16, 2008 at 10:44 PM, David Schwartz [EMAIL PROTECTED] wrote: If you can't trust the system that generates and stores your private key, you're screwed anyway. So I don't see that this argument has any validity. The issue is 'who is trusting what?' David's apparent statement is the person trusting the time is the person generating the key. Michael's apparent idea is if you're generating it and including it in the key format, then you're making an assertion which must trustable by people other than the person generating the key. My point is that number theory and TAI64n aren't related. Certificate policy and matters of key reuse probably need to take both into account. Look, all RSA keypairs are of a given pubkey len are finite in number, and already exist mathematically. I hereby give them a timestamp of zero. Oh, did you mean when YOU started using them? What's the point of that? To prevent reuse? Who cares about that? Perhaps your CA has a policy about key lifespan for encryption, or for signing purposes? Perhaps your CA requires that private keys used for signing never leave the device they are generated on? All quite reasonable, and none of which argue for a change in either of the common forms of representing private keys. - M __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Accessing encrypted messages after cert expires
David's apparent statement is the person trusting the time is the person generating the key. Michael's apparent idea is if you're generating it and including it in the key format, then you're making an assertion which must trustable by people other than the person generating the key. -Kyle H You have to have absolute trust in any entity that will generate or store your private key. Thus you can trust any information in it -- anyone who could put in bogus information could give away your key to strangers. (By absolute trust, I mean with respect to anything you would use that private key for.) DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Accessing encrypted messages after cert expires
David Schwartz wrote: You have to have absolute trust in any entity that will generate or store your private key. Thus you can trust any information in it -- anyone who could put in bogus information could give away your key to strangers. (By absolute trust, I mean with respect to anything you would use that private key for.) Pick a keypair, any keypair. It has existed in a mathematical sense since mathematics has existed, or longer, if your a mathematical idealist. What do you have in mind? I give them all a creation date of 0. NotValidBefore and NotValidAfter are perfectly fine concepts that do not violate the laws of modularity, and are where they belong. These come from the signing authorities policy, which also may preclude key reuse after expiry (you can't sign with the private key after expiration, but verification of any messages signed in the validity window succeeds). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Accessing encrypted messages after cert expires
On Sun, Mar 16, 2008 at 11:27 PM, Michael Sierchio [EMAIL PROTECTED] wrote:
David Schwartz wrote:
You have to have absolute trust in any entity that will generate or store
your private key. Thus you can trust any information in it -- anyone who
could put in bogus information could give away your key to strangers. (By
absolute trust, I mean with respect to anything you would use that private
key for.)
Pick a keypair, any keypair. It has existed in a mathematical sense
since mathematics has existed, or longer, if your a mathematical
idealist. What do you have in mind? I give them all a creation date of 0.
Since it's infeasable to store all of the possible keypairs in the
number of atoms in the universe, your assertion holds no water. They
may have existed 'forever', but since every new keypair usage requires
a new exhaustive search, realistically it can be viewed as 'generated
on' the date that the person locating the two huge primes and then
performing the appropriate calculations to convert them into related
keys set them down.
NotValidBefore and NotValidAfter are perfectly fine concepts that do not
violate the laws of modularity, and are where they belong. These come
from the signing authorities policy, which also may preclude key reuse
after expiry (you can't sign with the private key after expiration, but
verification of any messages signed in the validity window succeeds).
I've already shown that what the CA applies ('NotValidBefore' and
'NotValidAfter') do not refer to the keys themselves, but to the
binding of the identity to the public key. This is a different
concept than the useful and valuable lifetime of the keypair, which
is a piece of policy data that arguably shouldn't be made public (and
thus included in the certification).
-Kyle H
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Accessing encrypted messages after cert expires
Kyle Hamilton wrote: A key's lifetime is, cryptographically speaking, the amount of time for which it can be expected to provide a sane level of security in relation to the value of the data which it protects. Right, which is a matter of consensus best practice, we hope... Of course, cryptography is just a means of applying a policy to a piece of data. If you share a means of decryption, you also share a piece of trust with whomever you share that means with that they won't violate that policy, even though the policy is advisory (i.e., non-enforceable) once the data is decrypted. I think you need to be more careful about what is trusted. In the case of a signed message, our trust depends on a number of things -- that the message was signed during the validity period of the signer's cert, that the cert declares the key to be valid for that use, and perhaps trust in the CAs policy enforcement and revocation methods, CRL publication, etc. We trust that, absent a key revocation for any reason, including expiry, that a private key remains under the exclusive control of the signer. Signatures might require third party digest timestamps for non-repudiation of the validity of the signature wrt time of signing prior to a trusted date. Anyway, in the case of RSA keypairs we don't manufacture them, we discover them. They're already there, we just search for our p's and q's in the appropriate range and rely on chance starting conditions to find some not in use. I suggested, but not entirely in jest, giving them all a timestamp of 0. Creation date is a useless concept. Not valid before and Not valid after attributes make enormous sense, and are where they ought to be. The trust conferred on a signature derives from signature validation, which requires certificate validation. One part of the validation is that the message in question was signed during the validity period as defined by certificate policy. You may argue, and get me to agree, that cert reissue/resigning with the same SubjectPubkeyData is a bad idea. Make 'em generate keypairs. Keep a list forever of pubkeys seen in certs and reject any that appear in CSRs. Your storage requirements won't rival that of Youporn, or Wikipedia. b __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Accessing encrypted messages after cert expires
Michael Sierchio wrote: Anyway, in the case of RSA keypairs we don't manufacture them, we discover them. They're already there, we just search for our p's and q's in the appropriate range and rely on chance starting conditions to find some not in use. I suggested, but not entirely in jest, giving them all a timestamp of 0. Creation date is a useless concept. Not valid before and Not valid after attributes make enormous sense, and are where they ought to be. Nonsense. An attacker can start trying to break your key as soon he has your public key. You can put an earliest-possible bound on this -- he cannot have started before you generated the key. A creation timestamp on the private key that's placed by whatever generated the private key would serve as an earliest bound for when at attempt may have been made to break the key. The not valid before and not valid after attributes specify the outer bounds by which the certificate can be used to bind the private key to a name. This must be the lesser of the validity interval for the key itself and the validity interval for the binding. Often the binding is less, so this does not tell you a safe validity interval for the key (other than that it's valid at least as long as the certificate is). The certificate validity period tells you something different from the validity interval for the key. Plus, a single key may be associated with any number of certificates all of which have different validity intervals. A key may be associated with no certificate at all, if it doesn't need to be bound to an identity in that way. In all these cases, a creation timestamp in the public key would serve to inform of the expected validity interval of the key. An alternative way to accomplish the same thing (that some might like better) is to store public keys with self-signed (by the corresponding private key) certificates, with the validity of that certificate being the key's validity. I've done this, but it feels kind of like a hack. The trust conferred on a signature derives from signature validation, which requires certificate validation. One part of the validation is that the message in question was signed during the validity period as defined by certificate policy. Sure. But another part should (at least in some cases) be that the validation is performed during the key's validity interval. After all, you would be foolish to trust a 512-bit RSA key signature from five years ago in twenty years. (But that's another issue entirely, I suppose.) You may argue, and get me to agree, that cert reissue/resigning with the same SubjectPubkeyData is a bad idea. Make 'em generate keypairs. Keep a list forever of pubkeys seen in certs and reject any that appear in CSRs. Your storage requirements won't rival that of Youporn, or Wikipedia. It's sometimes a bad idea and sometimes a good idea. Sometimes it even makes sense to issue multiple certificates for the same keypair. X.500 is not just for TLS. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Accessing encrypted messages after cert expires
David Schwartz wrote: ... An attacker can start trying to break your key as soon he has your public key. Issuance date of the cert suffices. It's still not an attribute of the private key. In any case, you may of course need to validate an old signature, and the mechanics for that have been elaborated here. You don't need to perform the validation during the period defined by the cert, you have that absolutely wrong. A signature with a timestamp outside the valid dates of the cert is invalid, but you may have a need to validate signatures long after a cert expires. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Please take me off
Take me off this list please Thank you This is my busnesses mailbox, I didn,t how much mail comes in John Pawlicki New York Technical Support 212-775-2690 [EMAIL PROTECTED]
Re: Accessing encrypted messages after cert expires
Hi, interesting thread. I also think that secret and shared keys have attributes as creation or validation date. One very important attribute I would like to mention is the is revoked attribute. Of course certificates also can be revoked, but this is something different. Revoked certificates can be renewed but revoked keys cannot be (would not be reasonable). Of course peers must trust (`believe') that the peer stores its key correctly and securely depending on the policy, that it is kept secret and that it is replaced by a different key if needed and that much entropy is used and so on and so forth. All this IMHO is independent whether a CA or some certificates are used at all. Also, someone could implement some key continuity management (or however the correct term was) like e.g. SSH does. For initial key exchange maybe a certificate was used, but the key can be trusted independently of it as long as it is know to be authentic. Beside storing certificates, someone could simply store the key hash (together with attributes - and here it is!) in some trust.db file or so. If the requirement is to replace a key each 365 days, I think it obviously is a key attribute but not a certificate attribute. I think, a certificate is to bind a public key to some `human understandable' identity (or a `machine verifyable' such as some DNS name in some CN field, but I doubt that this is really `clean'; it seems a little bit pragmatic. For the human user at least a DNS name is not interesting. It is interesting whether it really is e.g. ebay, whatever DNS name they use.). Also, the security levels can be different. For instance, you could have a cacert.org email-verified certificate for a high secured key which is stored on a hardware security module in a safe in Fort Knox. Someone could trust the cert, others may not but could trust the key by other means. Also, a third could create a CA, certify this key with any certificate attributes. If the hardware security module automatically erases the key after lets say 12 month the certificates will still exists. A peer seeing an expired certifcate usually cannot determine whether the key can be trusted or not (maybe some other certificate exists). The peer may not trust the key (or tolerate the expired certificate for some days or reload the appropriate CRL or ask some user). This `not trusting the key' IMHO must not be persistent, especially in case of expiry of a CA or self signed certificate (but in practice, many CAs have root certificates valid for 20 years or so). All of that IMHO has no impact on the key itself, its validity definition/requirement/policy remains unaffected. About the subject `Accessing encrypted messages after cert expires' I think this is perfectly OK. This is a complex topic of course. Theoretically, even if the key was compromised there may be cases where the message can be trusted anyway (if it is known/ensured that the message was received before the key was compromised). I think in general when a key or all its certificates are revoked, usually the messages signed by it remain valid. Otherwise I think it would be some logical dilemma... David wrote: An alternative way to accomplish the same thing (that some might like better) is to store public keys with self-signed (by the corresponding private key) certificates, with the validity of that certificate being the key's validity. I've done this, but it feels kind of like a hack. For me this also feels like a kind of hack. I guess key attributes simply were `forgotten' in some key exchange standards. I guess, in X.509 environments, lets say SSL secured web, usually, they don't matter as it is used (i.e. no key continutiy management but browsers including lots of CAs not directly known to the user, maybe audited or maybe not even with a public accessible policy, but noone seems to care). In other environments this may be different. Maybe keys are transferred encrypted under strong transport keys which are transferred independently - with attributes like key hash, validity dates, usage purpose but also some identifier or `key name'. The trust conferred on a signature derives from signature validation, which requires certificate validation. One part of the validation is that the message in question was signed during the validity period as defined by certificate policy. Sure. But another part should (at least in some cases) be that the validation is performed during the key's validity interval. After all, you would be foolish to trust a 512-bit RSA key signature from five years ago in twenty years. (But that's another issue entirely, I suppose.) BTW, why shouldn't a CA certify 512 bit RSA keys for 20 years? If the security level of the policy is more or less just for transport reliability or for some very limited embedded environment, I think it could be certified that this (weak) key belongs to the named identity. A peer may trust the CA and the CA may use a 4096 bit
Re: Please take me off
me too On 3/17/08, Pawlicki, John (NY) [EMAIL PROTECTED] wrote: Take me off this list please Thank you This is my busnesses mailbox, I didn,t how much mail comes in John Pawlicki New York Technical Support 212-775-2690 [EMAIL PROTECTED]
RE: Accessing encrypted messages after cert expires
Steffen Dettmer wrote: You may argue, and get me to agree, that cert reissue/resigning with the same SubjectPubkeyData is a bad idea. Make 'em generate keypairs. Keep a list forever of pubkeys seen in certs and reject any that appear in CSRs. (CSR? Is this like a CRL or something logically equivalent meant?) Your storage requirements won't rival that of Youporn, or Wikipedia. I think this is wrong. A CRL entry revokes a certificate, not the key. Maybe the certificate was revoked because of formal reasons (forgotten critical extension CA:FALSE or omitted key usage information or whatever). Maybe other valid certificates exist for this valid key. A certificate may be revoked because the key was compromised. But it could also be revoked simply because the identity is no longer associated with the key. In this case, the key is still perfectly good. It would create a *massive* security loophole for a CA to be able to revoke a *key* just by revoking a certificate that certified that key. What I think Michael Sierchio was saying, though, was something different. He's not saying to treat a certificate as revoked, he's saying not to issue a certificate. Basically, he's saying a CA could refuse to issue a certificate for any key that it had ever seen before in any other context. I think this would be a mistake for a lot of reasons, not the least being the hit-or-miss aspect of having previously seen the key. The only scenario I can imagine where this might help is a case where a person accidentally generates the CSR with the wrong key, and by luck the CA happens to have seen this key before. And, of course, there are so many other ways to screw up generating a CSR that this seems like a pretty small help. (Failing to secure the private key, for example.) I also think there are perfectly legitimate reasons for using the same key in many certificates. An obvious one is if you have a large number of certificates that establish different external identities for the same logical entity. This isn't a common way to use a PKI, but X.509 and PKI exist for much more than just TLS and the Internet. (Although presumably Michael wasn't suggesting you should impose this rule where it was obviously inappropriate.) DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
OpenSSL on WM5 (V2)
Apologies if this has managed to get to the list twice as I was subscribing and not sure if it made it. Anyway: His has probably been covered a lot but I can't find much to show for it. I'm trying to build OpenSSL 0.9.8g for WM5 and have trouble. I've built it for Pocket PC 2003 OK for WM5, WCECOMPAT does not build. Is there a resource that provides built versions of OpenSSL for WM5 or a more up to date version of WCECOMPAT? Sorry if these are obvious questions and the answer is fix it yourself but I have just started mobile development (3 days in) and am still at the stupid question stage. Thanks Andy Andy Murphy Senior Software Developer http://www.tbsmobility.com/ Office Reception: +44 1773 596900 Fax: +44 1773 596901 Skype: andyleemurphy Web: www.tbsmobility.com http://www.tbsmobility.com/ Email: [EMAIL PROTECTED] image001.jpg
Re: Accessing encrypted messages after cert expires
On Mon, Mar 17, 2008 at 12:14 AM, Michael Sierchio [EMAIL PROTECTED] wrote: Kyle Hamilton wrote: A key's lifetime is, cryptographically speaking, the amount of time for which it can be expected to provide a sane level of security in relation to the value of the data which it protects. Right, which is a matter of consensus best practice, we hope... You are arguing with yourself; I'll approach why I state this later on. Of course, cryptography is just a means of applying a policy to a piece of data. If you share a means of decryption, you also share a piece of trust with whomever you share that means with that they won't violate that policy, even though the policy is advisory (i.e., non-enforceable) once the data is decrypted. I think you need to be more careful about what is trusted. I'm starting from zero-principles in my approach. Your argument is wrapped up in terminology, in concepts that have obscured the actual 'meaning' behind their creation and consensual agreement. In the case of a signed message, our trust depends on a number of things -- that the message was signed during the validity period of the signer's cert, that the cert declares the key to be valid for that use, and perhaps trust in the CAs policy enforcement and revocation methods, CRL publication, etc. We trust that, absent a key revocation for any reason, including expiry, that a private key remains under the exclusive control of the signer. Signatures might require third party digest timestamps for non-repudiation of the validity of the signature wrt time of signing prior to a trusted date. What 'trusts'? All of the things that you mention -- the validity period of the certificate, the CA's policy enforcement (and thus our ability to form a policy that can rely on that policy enforcement), the CA's revocation methods, CRL publication, etc -- are means of deciding, via policies, whether to trust or distrust the assertion made. They are a means of associating policy with data, and are not independent ends of their own. A statement of identity binding -- a certificate -- must be signed, by policy and practice. Policy may not allow you to accept that statement, however, unless it is signed by a specific key that has been bound to the identity of an organization which has policies that you choose to trust. This signing is a use of cryptography to associate data (the identity in the certificate) with policy (that the organization's rules -- its policies -- have been followed, such as 'I have verified that the identity named in this certificate is in fact the entity that presented me with this key to certify'). Following that, the use of that certificate to encrypt a message to the identity it states is, in effect, the communication of the message with the following policy: My policy is that only the identity bound in the certificate I'm encrypting to is allowed to see the contents of this message in a perceivable form. You attempt to enforce this policy by using the cryptographic key bound to the identity -- but once that person receives the message, that person can do whatever they want with that message. You cannot enforce that that person not disclose the contents of that message to anyone else; thus your use of that key to communicate your policy is purely advisory. (This is the trap that has allowed DRM, for example, to be applied and then broken -- DRM relies on the ability to enforce a policy that is communicated. It is also the trap that Windows system policies have fallen into -- they rely on the ability of the System security identifier to make arbitrary changes to the environment in the registry or in the filesystem, without recognizing that the System SID can be blocked from making those changes by anyone who has absolute authority (i.e., local Administrator) access to the machine.) Anyway, in the case of RSA keypairs we don't manufacture them, we discover them. They're already there, we just search for our p's and q's in the appropriate range and rely on chance starting conditions to find some not in use. I suggested, but not entirely in jest, giving them all a timestamp of 0. Creation date is a useless concept. Not valid before and Not valid after attributes make enormous sense, and are where they ought to be. They exist, certainly -- but nobody has mapped them all. By your logic, the generation of a 128-bit or 256-bit symmetric key (since the keyspace is finite) also has no 'creation date', thus requiring that they all be timestamped to 0 as well. However, each and every context that a key is used in is different. Within each and every context, to discover the secret key we must start over from square 1, start over from zero-knowledge. The useful life of a key starts on the date when it was first either 'generated'/'discovered' or 'used in context'. (Since 'context' is a tricky thing to quantify, in order to make it most likely that
Use of certificates
Hello, I have to setup an SSL communication between a client and a server. I have bought the OpenSSL book and I have downloaded the last OpenSSL release version. I think the first think to do is to set up my certification authority following these steps: Create an environment for my CA Build an OpenSSL configuration file Create a self signed root certificate Issue a certificate Within the book, I don't find the OpenSSL commands to perform these operations. Could you help me? Thank you Best Regards Driss El Hachimi - Envoyé avec Yahoo! Mail. La boite email la plus appreciée au monde.
Re: Use of certificates
Do you want to do it inline or not. If not I can send the commands. EL HACHIMI Driss wrote: Hello, I have to setup an SSL communication between a client and a server. I have bought the OpenSSL book and I have downloaded the last OpenSSL release version. I think the first think to do is to set up my certification authority following these steps: 1. Create an environment for my CA 2. Build an OpenSSL configuration file 3. Create a self signed root certificate 4. Issue a certificate Within the book, I don't find the OpenSSL commands to perform these operations. Could you help me? Thank you Best Regards Driss El Hachimi Envoyé avec Yahoo! Mail http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52420/*http://fr.docs.yahoo.com/mail/overview/index.html. La boite email la plus appreciée au monde. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE : Re: Use of certificates
I'd like to do it with the commands - Envoyé avec Yahoo! Mail. La boite email la plus appreciée au monde.
RE : Re: Use of certificates
I'll do it with the commands David Hostetter [EMAIL PROTECTED] a écrit : Do you want to do it inline or not. If not I can send the commands. EL HACHIMI Driss wrote: Hello, I have to setup an SSL communication between a client and a server. I have bought the OpenSSL book and I have downloaded the last OpenSSL release version. I think the first think to do is to set up my certification authority following these steps: 1. Create an environment for my CA 2. Build an OpenSSL configuration file 3. Create a self signed root certificate 4. Issue a certificate Within the book, I don't find the OpenSSL commands to perform these operations. Could you help me? Thank you Best Regards Driss El Hachimi Envoyé avec Yahoo! Mail . La boite email la plus appreciée au monde. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] - Envoyé avec Yahoo! Mail. La boite email la plus appreciée au monde.
Re: is TLS-PSK already implemented in opensssl
Dear Sekhar, I checked for the PSK in the two files you listed in your last mail but there is nothing on psk. Could you please give me reference to the openSSL version that supports psk? regards, Charles Kurapati Raja Sekhar a écrit : Yes It is already implemented in openssl. Go to apps directory and see the example programs s_client.c and s_server.c. */gopinath ethiraja [EMAIL PROTECTED]/[EMAIL PROTECTED]/* wrote: is TLS-PSK already implemented in opensssl __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] Did you know? You can CHAT without downloading messenger. Click here http://in.rd.yahoo.com/tagline_webmessenger_2/*http://in.messenger.yahoo.com/webmessengerpromo.php
SSL negotiation failure when proprietary application is turned on
Hi all, I can not check out code from a subversion repository when a proprietary application is turned on, and get SSL negotiation failed: Secure connection truncated error message. And as soon as I turned off this application, I can successfully check out code. If this is a openSSL issue and not a subversion one, where should I start looking at where the problem is? Thanks, Andre Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Please take me off
On Monday 17 March 2008, navneet Upadhyay wrote: me too On 3/17/08, Pawlicki, John (NY) [EMAIL PROTECTED] wrote: Take me off this list please Thank you This is my busnesses mailbox, I didn,t how much mail comes in John Pawlicki New York Technical Support 212-775-2690 [EMAIL PROTECTED] Why do you both send a message to the M/L bot: [EMAIL PROTECTED], asking it to unsubscribe you? Start a new message, and only enter this in the body: unsubscribe openssl-users [EMAIL PROTECTED] Your address is not necessary if you are sending the message using the email address that you originally subscribed to the list with. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: Please take me off
Are you saing that the message shouldn't be send to majordomo? Here's the welcome message I got from majordomo: * Welcome to the openssl-users mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, you can send mail to [EMAIL PROTECTED] with the following command in the body of your email message: unsubscribe openssl-users or from another account, besides [EMAIL PROTECTED]: ** unsubscribe openssl-users [EMAIL PROTECTED] I think that's quite clear. On 3/17/08, Mick [EMAIL PROTECTED] wrote: On Monday 17 March 2008, navneet Upadhyay wrote: me too On 3/17/08, Pawlicki, John (NY) [EMAIL PROTECTED] wrote: Take me off this list please Thank you This is my busnesses mailbox, I didn,t how much mail comes in John Pawlicki New York Technical Support 212-775-2690 [EMAIL PROTECTED] Why do you both send a message to the M/L bot: [EMAIL PROTECTED], asking it to unsubscribe you? Start a new message, and only enter this in the body: unsubscribe openssl-users [EMAIL PROTECTED] Your address is not necessary if you are sending the message using the email address that you originally subscribed to the list with. -- Regards, Mick
Re: Please take me off
On Monday 17 March 2008, mikel paskual wrote: Are you saing that the message shouldn't be send to majordomo? Sorry, fat fingers first thing in the morning . . . should have typed: why don't you send a message to [EMAIL PROTECTED] . . . Hope this helps Here's the welcome message I got from majordomo: * Welcome to the openssl-users mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, you can send mail to [EMAIL PROTECTED] with the following command in the body of your email message: unsubscribe openssl-users or from another account, besides [EMAIL PROTECTED]: ** unsubscribe openssl-users [EMAIL PROTECTED] I think that's quite clear. On 3/17/08, Mick [EMAIL PROTECTED] wrote: On Monday 17 March 2008, navneet Upadhyay wrote: me too On 3/17/08, Pawlicki, John (NY) [EMAIL PROTECTED] wrote: Take me off this list please Thank you This is my busnesses mailbox, I didn,t how much mail comes in John Pawlicki New York Technical Support 212-775-2690 [EMAIL PROTECTED] Why do you both send a message to the M/L bot: [EMAIL PROTECTED], asking it to unsubscribe you? Start a new message, and only enter this in the body: unsubscribe openssl-users [EMAIL PROTECTED] Your address is not necessary if you are sending the message using the email address that you originally subscribed to the list with. -- Regards, Mick -- Regards, Mick signature.asc Description: This is a digitally signed message part.
How to transfer a socket with SSL already initialized
In my Linux application, previously I transferred a socket from a host application to a spawned exec()'d application in a new process by passing the socket handle on the command line. The child application would then continue reading on the socket like normal. However, now I need to pass this socket with SSL initialized on the host program and picked up by the spawned application. The spawned application needs to continue to read and write encrypted packets just like the host application was doing. The vague idea I've gotten so far is that I need to somehow transfer the SSL_SESSION to the new process. Examining the output of SSL_SESSION_print_fp() I see that the session ID and master key change every time SSL is initialized, so simply reinitializing the SSL library in the new process won't do. What do I have to do to let the child process use the host application's secure socket? Is there some way I can dump the session to a file -- or perhaps even fwrite SSL_SESSION itself -- and and load it up in the new process, or do I need to do something else? -- Jorge Rodriguez Email: [EMAIL PROTECTED] Phone: (919) 757-3066
RE: How to transfer a socket with SSL already initialized
The vague idea I've gotten so far is that I need to somehow transfer the SSL_SESSION to the new process. Examining the output of SSL_SESSION_print_fp() I see that the session ID and master key change every time SSL is initialized, so simply reinitializing the SSL library in the new process won't do. What do I have to do to let the child process use the host application's secure socket? Is there some way I can dump the session to a file -- or perhaps even fwrite SSL_SESSION itself -- and and load it up in the new process, or do I need to do something else? The short answer is no, there is no good/easy way to do this. You have three choices: 1) Extend OpenSSL to provide this support. This is a complex and tricky thing to do for a variety of reasons. 2) Use another SSL library that offers this feature instead of OpenSSL. 3) Use a proxy, with whatever listens to the SSL socket proxying data to and from a pipe or socket that you can hand off. I think it would be a good thing to extend OpenSSL so that it can output everything that's necessary to support a given SSL session as a DER object and to allow an SSL session to be initialized from a socket and a DER object, but that's not currently possible. As I understand it, there are quite a few thorny obstacles involved. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
