Re: Re[6]: Using a 'secret' SSL client certificate from Mozilla
Konstantin Andreev andr...@swemel.ru wrote in message news:qvgdnspmvaho3hvrnz2dnuvz_jsdn...@mozilla.org... On 08/28/10 02:36, Michael Smith wrote: Rather than the normal case of a client certificate belonging to the user, and just added to the certificate store, we want to have a certificate that nominally belongs to the application, and is secret from the user (strange, but that's what I'm stuck with). The specific requirements are that we not store it unencrypted in the filesystem - and simply setting a password on the key db isn't an option, as that would interfere with the _user's_ use of the key db for any of their certificates, and that it must not be available in the UI (so we want to somehow hide it from the 'View Certificates' UI - or at least not be exportable from there). Hello, Michael. Would this work ? 1) hardcode the cert. and the priv. key into your app. binary (maybe hidden/masked/...) 2) at run time, import them into NSS softoken as ephemeral (session) objects. Maybe that is what his client wants but if they revoke the certificate or want to change the key the binary becomes useless and must be updated. I guess they want to create job security for programmers. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re[6]: Using a 'secret' SSL client certificate from Mozilla
On 08/28/10 02:36, Michael Smith wrote: Rather than the normal case of a client certificate belonging to the user, and just added to the certificate store, we want to have a certificate that nominally belongs to the application, and is secret from the user (strange, but that's what I'm stuck with). The specific requirements are that we not store it unencrypted in the filesystem - and simply setting a password on the key db isn't an option, as that would interfere with the _user's_ use of the key db for any of their certificates, and that it must not be available in the UI (so we want to somehow hide it from the 'View Certificates' UI - or at least not be exportable from there). Hello, Michael. Would this work ? 1) hardcode the cert. and the priv. key into your app. binary (maybe hidden/masked/...) 2) at run time, import them into NSS softoken as ephemeral (session) objects. Regards, -- Konstantin. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using a 'secret' SSL client certificate from Mozilla
On Sep 7, 6:55 am, Konstantin Andreev andr...@swemel.ru wrote: On 08/28/10 02:36, Michael Smith wrote: Rather than the normal case of a client certificate belonging to the user, and just added to the certificate store, we want to have a certificate that nominally belongs to the application, and is secret from the user (strange, but that's what I'm stuck with). The specific requirements are that we not store it unencrypted in the filesystem - and simply setting a password on the key db isn't an option, as that would interfere with the _user's_ use of the key db for any of their certificates, and that it must not be available in the UI (so we want to somehow hide it from the 'View Certificates' UI - or at least not be exportable from there). Hello, Michael. Would this work ? 1) hardcode the cert. and the priv. key into your app. binary (maybe hidden/masked/...) 2) at run time, import them into NSS softoken as ephemeral (session) objects. Konstantin, That looks like pretty much what I want to do - but I've been unable to figure out how to do part (2) there. Many of the NSS APIs are not terribly well documented. Any pointers to sample code or even just to the relevant functions would be very helpful. Mike -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using a 'secret' SSL client certificate from Mozilla
On 2010-08-30 11:04 PDT, Michael Smith wrote: On Aug 28, 10:08 am, Nelson Bolyard nonelsons...@nobolyardspam.me wrote: What is the real underlying objective of this? Is it to authenticate the individual user of the product to the servers? Is it to ensure that the client applications of the network service are genuinely those made by your partner, and not some other client that has been made by some third party who reverse engineered your protocol? (e.g. as AOL used to try to ensure that only genuine AOL clients accessed the AOL Instant Messenger servers?) Yes, the intent is to ensure that the client application is a legitimate application, and to prevent others (even if the _user_ is appropriately authenticated with username/password) from accessing the servers. [snip] Any advice you can give would be greatly appreciated! The attack against which you're trying to guard is that someone reverse engineers your protocols and creates a substitute client that talks to your servers. Presumably, someone does that by reverse engineering your client. Anyone who can do that can find the private key and the client certificate, which will be embedded in your client binary somewhere, and aren't very big, and use them in their substitute client, also. So, embedding a key and cert in your binary really doesn't offer much protection, IMO. In some sense, the problem is that the info that the attacker must replicate is too small and too easily replicated, if it is merely a key and cert, or for that matter, if it is merely the static content of an executable program file. I know of a company (:-) whose products had a protocol whereby the server asked the client give me the contents of your memory starting at this address for this many bytes, which was an address in the code portion of the program, as a means of authenticating the client program. The idea was that this made the entire program file the data that must be kept, no tiny subset of it was enough to fool the server. The attackers simply shipped a copy of the original program along with their replacement, and their replacement program answered those requests by reading the original program file to find the answers. If you assume that the attacker has full access to every bit of data that the server shares with the client, then trying to distinguish between a legitimate client and a replacement becomes a game of testing the limits to which the attacker is willing to go to emulate the original. But you can go quite far in that direction, producing results that require quite a bit of emulation to replicate. It requires demanding results that depend on quite a bit of dynamic data, and not merely depending on static data that can be gotten from the original program file. And it can all be overcome with enough reverse engineering. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using a 'secret' SSL client certificate from Mozilla
On Aug 28, 10:08 am, Nelson Bolyard nonelsons...@nobolyardspam.me wrote: On 2010-08-27 16:48 PDT, Michael Smith wrote: We're not really looking for a couldn't be compromised solutions - this is a requirement from a company we're partnering with, not our idea, and they basically just want it to not be simple (for some value of that) to compromise. So: serialising it to disk without some sort of encryption isn't ok, and exposing it in exportable form in the browser UI isn't ok. What is the real underlying objective of this? Is it to authenticate the individual user of the product to the servers? Is it to ensure that the client applications of the network service are genuinely those made by your partner, and not some other client that has been made by some third party who reverse engineered your protocol? (e.g. as AOL used to try to ensure that only genuine AOL clients accessed the AOL Instant Messenger servers?) Sorry for not being clearer. Yes, the intent is to ensure that the client application is a legitimate application, and to prevent others (even if the _user_ is appropriately authenticated with username/password) from accessing the servers. i.e. Standard HTTP authentication is used to authenticate the user, and an SSL client certificate is used to authenticate the application binary. This is why I want to keep the certificate secret from the user; it logically belongs to the application, rather than the more typical use of client authentication, where the private key logically belongs to the _user_. Is it something else? The use of public key certificates may not be the best way to accomplish your objective, or even an appropriate way at all, but we cannot determine that until we know what that objective is. I'm pretty unconvinced that this is a sensible way to accomplish the real objective, but unfortunately I've been given no choice - the partner insists on this being the only acceptable way to access their servers. Any advice you can give would be greatly appreciated! Mike -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using a 'secret' SSL client certificate from Mozilla
On 2010-08-27 16:48 PDT, Michael Smith wrote: We're not really looking for a couldn't be compromised solutions - this is a requirement from a company we're partnering with, not our idea, and they basically just want it to not be simple (for some value of that) to compromise. So: serialising it to disk without some sort of encryption isn't ok, and exposing it in exportable form in the browser UI isn't ok. What is the real underlying objective of this? Is it to authenticate the individual user of the product to the servers? Is it to ensure that the client applications of the network service are genuinely those made by your partner, and not some other client that has been made by some third party who reverse engineered your protocol? (e.g. as AOL used to try to ensure that only genuine AOL clients accessed the AOL Instant Messenger servers?) Is it something else? The use of public key certificates may not be the best way to accomplish your objective, or even an appropriate way at all, but we cannot determine that until we know what that objective is. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Using a 'secret' SSL client certificate from Mozilla
Hi all, In our (mozilla/xulrunner-based) application, we're trying to set up a secure connection to a server that requires a client certificate. Rather than the normal case of a client certificate belonging to the user, and just added to the certificate store, we want to have a certificate that nominally belongs to the application, and is secret from the user (strange, but that's what I'm stuck with). The specific requirements are that we not store it unencrypted in the filesystem - and simply setting a password on the key db isn't an option, as that would interfere with the _user's_ use of the key db for any of their certificates, and that it must not be available in the UI (so we want to somehow hide it from the 'View Certificates' UI - or at least not be exportable from there). Can anyone suggest an approach to implementing this? Thanks, Mike Smith Songbird -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using a 'secret' SSL client certificate from Mozilla
On 08/27/2010 06:36 PM, Michael Smith wrote: Hi all, In our (mozilla/xulrunner-based) application, we're trying to set up a secure connection to a server that requires a client certificate. Rather than the normal case of a client certificate belonging to the user, and just added to the certificate store, we want to have a certificate that nominally belongs to the application, and is secret from the user (strange, but that's what I'm stuck with). The specific requirements are that we not store it unencrypted in the filesystem - and simply setting a password on the key db isn't an option, as that would interfere with the _user's_ use of the key db for any of their certificates, and that it must not be available in the UI (so we want to somehow hide it from the 'View Certificates' UI - or at least not be exportable from there). Can anyone suggest an approach to implementing this? System services (e.g. daemons) have a very similar requirement for accessing their security information and being able to operate unattended. The usual solution for system services is to create a system user (typically a uid less 1024, but that varies by OS). The security information is placed in a file only that user can read. Upon start up the process will switch it's effective uid to that uid. However if your application is a normal user process running under the uid of the user that won't work. It works in the case of a system service because those processes start with root privileges and can drop privileges to the daemon uid after they've begun executing. Very much akin to what I described above are the requirements for storing a host certificate for machine authentication when joining a domain. But once again the storage of that cert is protected by root level privileges. Another possible approach would be akin to what Cyrus SASL saslauthd does. saslauthd is a tiny root daemon process who purpose is to access authentication information on behalf of an unprivileged process. The unprivileged process sends a request to saslauthd which is running with root privileges and requests it perform an authentication on it's behalf. In fact the basic concept is not all that different from RADIUS. If your application is a normal user application running under the uid of the user who started and you have no way to install and start a system daemon then I can't think of a mechanism that couldn't be compromised and/or wouldn't require user intervention. Anybody else have better ideas? -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using a 'secret' SSL client certificate from Mozilla
On Aug 27, 4:30 pm, John Dennis jden...@redhat.com wrote: On 08/27/2010 06:36 PM, Michael Smith wrote: Hi all, In our (mozilla/xulrunner-based) application, we're trying to set up a secure connection to a server that requires a client certificate. Rather than the normal case of a client certificate belonging to the user, and just added to the certificate store, we want to have a certificate that nominally belongs to the application, and is secret from the user (strange, but that's what I'm stuck with). The specific requirements are that we not store it unencrypted in the filesystem - and simply setting a password on the key db isn't an option, as that would interfere with the _user's_ use of the key db for any of their certificates, and that it must not be available in the UI (so we want to somehow hide it from the 'View Certificates' UI - or at least not be exportable from there). Can anyone suggest an approach to implementing this? System services (e.g. daemons) have a very similar requirement for accessing their security information and being able to operate unattended. The usual solution for system services is to create a system user (typically a uid less 1024, but that varies by OS). The security information is placed in a file only that user can read. Upon start up the process will switch it's effective uid to that uid. However if your application is a normal user process running under the uid of the user that won't work. It works in the case of a system service because those processes start with root privileges and can drop privileges to the daemon uid after they've begun executing. Very much akin to what I described above are the requirements for storing a host certificate for machine authentication when joining a domain. But once again the storage of that cert is protected by root level privileges. Another possible approach would be akin to what Cyrus SASL saslauthd does. saslauthd is a tiny root daemon process who purpose is to access authentication information on behalf of an unprivileged process. The unprivileged process sends a request to saslauthd which is running with root privileges and requests it perform an authentication on it's behalf. In fact the basic concept is not all that different from RADIUS. If your application is a normal user application running under the uid of the user who started and you have no way to install and start a system daemon then I can't think of a mechanism that couldn't be compromised and/or wouldn't require user intervention. Anybody else have better ideas? John, Thanks for your description. Our application (Songbird) is a desktop client app - think of it as a mozilla-based web browser, for the purposes of this discussion. I have a fairly solid working understanding of how system daemons typically do this sort of thing - and like you said, this doesn't really apply here, since this is an unprivileged user application. We're not really looking for a couldn't be compromised solutions - this is a requirement from a company we're partnering with, not our idea, and they basically just want it to not be simple (for some value of that) to compromise. So: serialising it to disk without some sort of encryption isn't ok, and exposing it in exportable form in the browser UI isn't ok. Something that is difficult to hack whilst not truly secure would be fine. I understand the limitations of this approach (and were it up to me, I would not 'secure' this stuff using such a mechanism). Ultimately, we're trying to hide from the actual human user something that must be readable by the user's process. The intended approach would be to hide the certificate/key inside our application binary (probably obfuscated in some way) - the bit that I'm looking for some help with is how to hook this into the mozilla HTTPS layer _without_ exposing it to the certificate UI. Thanks, Mike Smith Songbird -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
